OSDev.org

Im just starting this project. and i finished a simple kernel that im still working on and making it a little bigger. but i was wondering how would i design the GUI (Graphical User Interface). i know there are some out there but im not shure how to design it. do i need a certain program. or need to know another language like java.

welll there is vesa for all i know, some people use that as a start

James T. Klik.

Also, your mentioning of requiring java begs the question: have you ever done GUIs in your OS development language? It might be a better idea to practice that in the more comfortable space outside of your TodoOS

Hm, you can design GUIs in any graphical program. Implementing GUIs is a different topic; and can be several layers of software (Thus there is no one right answer.)

If you do now have a basic driver that interfaces with the computers video hardware (VESA driver, VGA or SVGA etc driver) then I would start there.

Hi,

dannyboy997 wrote:Im just starting this project. and i finished a simple kernel that im still working on and making it a little bigger. but i was wondering how would i design the GUI (Graphical User Interface). i know there are some out there but im not shure how to design it. do i need a certain program. or need to know another language like java.

I'd invent some type of "video protocol", that's used for everything from "widgets" to applications to GUIs to virtual terminals to video drivers.

For example, imagine if the "video protocol" was a list of commands (a "video script") that can be used to create areas to draw on (a canvas) and commands for graphics primitives (drawTriangle, drawPolygon, drawBitmap, etc) used for drawing stuff on a canvas. Things like icons, scroll bars, buttons, etc would be small video scripts that describe small canvases; and an application could combine these small video scripts into a larger video script that describes a large canvas (the application's window); and the GUI could combine the video scripts from several applications (plus it's own video scripts for the desktop, start menu, etc) to create one big video script that describes the entire virtual screen.

Eventually the full video script that describes the entire screen (which includes lots of smaller scripts that describe smaller canvases) would be sent to the video driver, which would do *all* of the drawing. The video driver could cache smaller scripts and canvases to avoid recreating each canvas from the smaller script if the smaller script hasn't changed, and could use full 2D/3D acceleration to draw everything that did change.

However, I'd be very tempted to do everything in 3D. For example, a script might create a volume (rather than a flat canvas), then have commands that draw other things in this volume (e.g. "drawTriangle(x1, y1, z1, x2, y2, z2, x3, y3, z3, colour)"), including the ability to draw one volume inside another volume (with translation/rotation/scaling/clipping). I'd also use virtual coordinates (e.g. all coordinates range 0.0 to 1.0, or maybe from 0x00000000 to 0xFFFFFFFF); and use a standardized representation for colours (rather than whatever the video card happens to be using).

Once you've got the "video protocol" worked out, you'd invent something for "input devices" (keyboard, mouse, touchscreen, joystick, etc), which uses the same coordinate system, where translation/rotation/scaling is done in reverse (so that if you click on something at (x,y,0) with the mouse, then this might correspond to (x', y', z') in one of the smaller volumes).


Cheers,

Brendan

Does you kernel have the ability to load applications (dynamic libraries would be useful too), multitasking and some kind of storage drivers (hard drive or CD). That's about the point where I think it's useful to start thinking about writing a GUI. Before that, it's a bit of a hopeless pursuit (I know from experience). I'm still nowhere near that point and I've been working on a few different kernels on and off for the last eight years...

If your up to that, then I'd suggest you start writing a VESA driver (and a PS2 mouse driver, which is pretty simple), port zlib, libpng, and libjpeg so you can use nice graphics, and then try to start some kind of display server and/or window manager.

I'd tell the application when it starts what colour format to use (let the application and it's draw libraries handle the most optimized way of drawing, and avoid colour conversion in the window manager), and I'd also use shared memory mapped into both the application and the window manager for drawing memory too. The application need not know when the window has been moved, though messages like it has been minimized/restored will help (e.g. there's no reason a computationally heavy video decoder must keep decoding and rendering video if minimized), aswell as loosing/gaining focus (e.g. a game can pause).

Personally, I'm going to port either Qt or OpenGL for my OS's graphical functions. I'm more likely to choose OpenGL. There's an example on this forum of a member who's already done it. I think it was Combuster.

gravaera wrote:Personally, I'm going to port either Qt or OpenGL for my OS's graphical functions. I'm more likely to choose OpenGL. There's an example on this forum of a member who's already done it. I think it was Combuster.

You do realize that Qt and OpenGL are 2 entirely different things.. right?

YUP ^_^ And I'm gonna use them for two different purposes, but OpenGL is more convenient for what I wanna do.

You could port both. QT draws to a 2D texture, OpenGL renders onto the screen.

Actually, I like the idea of using OpenGL throughout the entire window manager.

For 2D vector graphics and image manipulation I prefer Cairo.