Free UI design for your OS

[cheapskate01]

Hi, I'm Cheapskate01. A few of you have met me in private chats or IRC or whatever the heck you use. I've been working on my OS a bit, and I still do, but I'm a lot more UI oriented than code oriented. I can do both. I just wanted to know if anybody a) Has a working gui system with a line drawing system or a rectangle system and b) Needs a more modern User Interface. I will gladly help anybody with the UI design as a side project. I just don't want to be part or JUST another linux distro. If anybody has an OS with bad UI, message me and I'd gladly help out. Thanks for reading

~Cheapskate01

[BrightLight]

I'm the exact opposite. I usually get bored with UI development, and focus more on core things.

[SpyderTL]

I wouldn't mind help with my graphical UI when I get back into working on it. Right now I'm trying to get my USB code working, so it'll probably be a month or so before I get back into the graphics stuff.

My OS is a complete reinvent the wheel, start from scratch deal, so no windows and no Linux influence at all. Up until now, I've been more focused on the command line shell functionality, but I do have a simple rectangle button, mouse pointer proof of concept up and running.

Eventually, I was thinking about doing an animated UI, with radial menus, rather than rectangles, but I really just want something different, unique, flashy and simple to comprehend.

I can currently render images to the screen, and draw and fill lines and rectangles in 32-bit color. Next task would be to rotate and scale images, which shouldn't be too difficult, as I've already got the math working for doing 4x4 matrix transforms.

[BrightLight]

I have alpha blending, double buffering, rectangles (solid and transparent), lines (solid and transparent), mouse cursor support, BMP image rendering, and many other things in both 32-bit and 24-bit graphics modes, transparently to the user.

[cheapskate01]

Well, I'd be more than happy to help either of you. Just give me a message when you're ready!

[osdever]

I have alpha blending, double buffering, rectangles (solid and transparent), lines (solid and transparent), mouse cursor support, BMP image rendering, and many other things in both 32-bit and 24-bit graphics modes, transparently to the user.

Almost all of them, but no alpha blending and DB. I'll do GUI only in autumn or summer, because I need a good kernel for the start.

[zlixine]

I'm the exact opposite. I usually get bored with UI development, and focus more on core things.

totally disagree the Ui always is the top of OS developing.

[Roman]

I'm the exact opposite. I usually get bored with UI development, and focus more on core things.

totally disagree the Ui always is the top of OS developing.

If you want a yet another GUI, you should be better writing software for an existing OS.

[cheapskate01]

Yeah, I find that the core of an operating system is first and foremost in a good operating system. That's why I haven't implemented gui in my OS, it's got a weak core (for now).

[MollenOS]

I'm building my GUI in OpenGL, but I've spent the last few months improving stability and robustness of the core itself. So I guess I would agree a strong core comes before GUI.

[zaval]

I'm building my GUI in OpenGL, but I've spent the last few months improving stability and robustness of the core itself. So I guess I would agree a strong core comes before GUI.

I'm a total noobass in graphics so I'm not ashamed to ask. Is that OpenGL suitable for GUI at all? Isn't it a 3D API? Even if it's a matter of subsetting (2D is a subset of 3D), it's going to be a huge overkill - to implement that monstrous API (that is getting outdated yet!), intended for drawing complex 3D objects (games, CAD etc) just for using its small subset of functions/objects/concepts. GUI is hell of complexity, but it's not 3D at all! And there is yet a question - will it be so efficient made this way? The very same standardization body, produced loads of other specifications, that tell about themselves as a 2D stuff, specifically targetting this area, GUI. Like what that OpenVG is for? EGL? Aren't these more suitable for GUI. Here, from this page they talk about it as exactly the thing for GUI:

Code: Select all

Target Applications
...
Scalable User Interfaces
    OpenVG may be used to render scalable user interfaces, particularly for applications
    that wish to present users with a unique look and feel that is consistent across different screen resolutions.

Low-Level Graphics Device Interface
    OpenVG may be used as a low-level graphics device interface. Other graphical toolkits,
    such as windowing systems, may be implemented above OpenVG.

Kinda this thing, eh? What one can do with OpenGL for Windowing?

[MollenOS]

I'm building my GUI in OpenGL, but I've spent the last few months improving stability and robustness of the core itself. So I guess I would agree a strong core comes before GUI.

I'm a total noobass in graphics so I'm not ashamed to ask. Is that OpenGL suitable for GUI at all? Isn't it a 3D API? Even if it's a matter of subsetting (2D is a subset of 3D), it's going to be a huge overkill - to implement that monstrous API (that is getting outdated yet!), intended for drawing complex 3D objects (games, CAD etc) just for using its small subset of functions/objects/concepts. GUI is hell of complexity, but it's not 3D at all! And there is yet a question - will it be so efficient made this way? The very same standardization body, produced loads of other specifications, that tell about themselves as a 2D stuff, specifically targetting this area, GUI. Like what that OpenVG is for? EGL? Aren't these more suitable for GUI. Here, from this page they talk about it as exactly the thing for GUI:

Code: Select all

Target Applications
...
Scalable User Interfaces
    OpenVG may be used to render scalable user interfaces, particularly for applications
    that wish to present users with a unique look and feel that is consistent across different screen resolutions.

Low-Level Graphics Device Interface
    OpenVG may be used as a low-level graphics device interface. Other graphical toolkits,
    such as windowing systems, may be implemented above OpenVG.

Kinda this thing, eh? What one can do with OpenGL for Windowing?

It's completly true that using OpenGL could be considered 'overkill' to create a GUI, but who said that a GUI had to be 2D? However I don't just have OpenGL to create a GUI, I have OpenGL available for everything, which means I can get a lot of graphical software ported without having to do that much.

And yes, I agree that performance is a consideration, and one I'm still trying to figure out might be a problem with a software renderer. Currently I'm using llvmpipe as my software renderer and it gives me enough performance for now, but I am considering switching to OpenSWR as the backend renderer instead of llvmpipe as that should be faster.

Using other vector graphic libraries are a good choice if you don't wish to port both LLVM and mesa to your platform, and it would give you a much simpler API to use, but my recommandation is not to use OpenVG as that is obsolete by now. The standard is back from 2008 and noone seem to implement it anywhere, it was meant for embedded environments it seem, and has been superseeded by OpenGL ES, which again is meant for embedded environments. So the only real alternative is OpenGL itself, even though Vulkan is working hard to replace it. (But I don't have to care, as mesa both provide OpenGL and Vulkan environments for me!)

[zaval]

OpenVG is supported by the current GPUs on ARM SoCs, especially those found in significantly cheaper than their smartphone counterparts SBCs, whereas support of Vulkan is a looong way to go. Even OpenGL ES support is lagging behind*, especially for linux. I didn't know OpenVG was obsoleted, since Khronos still advertizes it.
I didn't mean ignoring OpenGL, I questioned its relevance to the GUI implementation. Basically I just don't understand how it's supposed to be used for this task.

* - For example, a so frequently found in SBCs Mali 400:
Vulkan - NO
OpenGL ES - 2.0
OpenVG - 1.1
The same goes to Mali 450.

Pricier and newer things like RockPro64 or Odroid-N2 (Mali T860 and Mali G52 resp.):
Vulkan - 1.0 (T860), 1.1 (G52)
OpenGL ES - 3.2
OpenVG - 1.1

But for example those opensource dudes (and ladies), that try to bring opensauce ARM GPU support for linux, are struggling with delivering OpenGL ES 2.0 only for now (panfrost project). So Vulkan is unavailable even if it is there, even OpenGL ES 3.x isn't.

[Korona]

And yes, I agree that performance is a consideration, and one I'm still trying to figure out might be a problem with a software renderer. Currently I'm using llvmpipe as my software renderer and it gives me enough performance for now, but I am considering switching to OpenSWR as the backend renderer instead of llvmpipe as that should be faster.

Interesting. I'm currently using softpipe; I plan to switch to llvmpipe but so far, I didn't have to time to finish my llvm port. Were there any obstacles with getting llvmpipe to work on your OS, or does it simply work once llvm works?

[MollenOS]

OpenVG is supported by the current GPUs on ARM SoCs, especially those found in significantly cheaper than their smartphone counterparts SBCs, whereas support of Vulkan is a looong way to go. Even OpenGL ES support is lagging behind*, especially for linux. I didn't know OpenVG was obsoleted, since Khronos still advertizes it.
I didn't mean ignoring OpenGL, I questioned its relevance to the GUI implementation. Basically I just don't understand how it's supposed to be used for this task.

* - For example, a so frequently found in SBCs Mali 400:
Vulkan - NO
OpenGL ES - 2.0
OpenVG - 1.1
The same goes to Mali 450.

Pricier and newer things like RockPro64 or Odroid-N2 (Mali T860 and Mali G52 resp.):
Vulkan - 1.0 (T860), 1.1 (G52)
OpenGL ES - 3.2
OpenVG - 1.1

But for example those opensource dudes (and ladies), that try to bring opensauce ARM GPU support for linux, are struggling with delivering OpenGL ES 2.0 only for now (panfrost project). So Vulkan is unavailable even if it is there, even OpenGL ES 3.x isn't.

Exactly, hardware support for OpenVG is mostly targetted against embedded. And to clarify my earlier statement about no implementations, I meant software implementations. Once Mesa3D project had it, but they dropped it as it wasn' being used anymore. So against all odds, for generic desktop platforms, OpenGL is still a great choice. OpenGL can do both 2d and 3d, and at a great performance. I selected OpenGL as it makes a lot of sense when I have it available anyway.

And yes, I agree that performance is a consideration, and one I'm still trying to figure out might be a problem with a software renderer. Currently I'm using llvmpipe as my software renderer and it gives me enough performance for now, but I am considering switching to OpenSWR as the backend renderer instead of llvmpipe as that should be faster.

Interesting. I'm currently using softpipe; I plan to switch to llvmpipe but so far, I didn't have to time to finish my llvm port. Were there any obstacles with getting llvmpipe to work on your OS, or does it simply work once llvm works?

Surprisingly, once you've written the support layer for LLVM and made cmake play nice against your OS environment, porting LLVM was actually a breeze. I can definitately recommend it, you should see some good speedups against softpipe, and if the target processors has AVX/AVX2 then i recommend using OpenSWR pipe