OSDev.org

The Place to Start for Operating System Developers
It is currently Wed Sep 19, 2018 4:45 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: How did you / will you be implementing your GUI?
PostPosted: Sat Oct 25, 2003 10:57 am 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 11:33 pm
Posts: 3860
Location: Eindhoven
The simple question. Since this is an OS dev board (for I assume full OS'es), and since the CLI-only idea has been let go by just about all (including Linus Torvalds), I assume all OS'es (except for the most minimal) want to have a GUI. I'm wondering, how will you be doing that?

As for my own plan, I want to have a small part of it in the kernel. The kernel itself (or in fact, a driver-like part of the kernel) handles the video screen, the default pointer device and the default keyboard (assigned to it through configuration), and on the other side only handles the window-objects themselves. It does handle which window is raised when and why, but it does not handle drawing of ANYTHING that is even remotely connected to a window. It only supports registering of window-like objects that can draw themselves. These window-like objects register themselves with the kernel as to be called for an area that is theirs. The client is responsible for redraw-actions and things like that (interface to be determined). The kernel part of the gui is only responsible for reading from the clients (through functions) what they want to do with their window(s), updating the visible part of the screen to reflect that, keeping track of what window is active, and sending key and pointer events to the active window. It is also responsible for passing special video card functions (such as 3d functionality) through to the client applications. I'm not completely sure how to do this safely but I'll think about it.

The client part of the GUI exists from a number of objects in a C++ hierarchy (Of course, if you don't like C++ you can use the plain interface of the kernel which is also represented in C style functions). Since it's not obligatory to use these classes, other sorts of windows (think game windows, special theme windows etc) can easily be made without regard to the client part of the GUI. On the other hand, support for things like skins is present in the client part, so each conforming application can be skinned along with the rest. You can always extend the class hierarchy to include your own favorites as it should.

Now, I wonder. How do you want to do your GUI?


Top
 Profile  
 
 Post subject: Re:How did you / will you be implementing your GUI?
PostPosted: Sat Oct 25, 2003 2:11 pm 
Offline
Member
Member

Joined: Wed Oct 18, 2006 11:59 am
Posts: 1600
Location: Vienna/Austria
look at my thread about flickering windows and sorts.

there I elaborate about my own intentiions regarding GUI design.

And since I am doing a true microkernel with a message passing system I call store and forward - it is asyncronous, unlike what is presented in the Minix-Book. (yes, I 've read it and then I've run my brain over it and found out that I didn't like Mr. Tanenbaums approach That much to take it over for my design, I have to keep several things in mind: Who is responsible for what? Who manages, who executes; what is to be considered execution task and what is a management task?

Hm ... I consider those things management things which involve searching elements, sorting elements, deleting/closing elements, adding elements , drawing elements and so forth - time consuming tasks you don't need to recognize. A execution task I consider flushing buffers to the screen, moving windows, moving the mouse pointer, forwarding input to the different requestors, prnting out output to the locations indicated by the server - the management part.

Finally, throu' a library, the user processes may send commands (messages) to the different part of the kernel to tell what they want to have done. the kernel does the rest.

Hope this helps

stay safe

_________________
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image


Top
 Profile  
 
 Post subject: Re:How did you / will you be implementing your GUI?
PostPosted: Mon Oct 27, 2003 3:40 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 2:31 am
Posts: 5964
Location: In a galaxy, far, far away
Well, as usual, i want something that'll sound completely crazy ;)

The GUI will be managed by the GUI server (microkernel design), but it will not follow the usual 'low-level drawing commands' ? la X-window nor the 'pre-built widget kit' ? la Java (i will not try to compare to what Wind0z do as i'm pretty ignorant of the bits beyond the main event function).

The concept is that the GUI can host several renderers which are each specialized to a given task and use a given communication protocol with the clients. For instance, you'll have a Font Renderer that will be able to draw text you give it, but also a Html- Renderer that could handle tables, colors, etc. (optionnally using the font renderer to make its work simpler), etc.

You can also envision PixRenderer that would be able to decode jpg, png, gif and other stuff, or a FlashRenderer ... All these renderers are sort of plug-ins that will loaded on demand by the GUI server. They might be separated from each other by segmentation if necessary.

Finally, a dedicated language should allow user-defined server-handled widgets: instead of sending every mouse movement back to the client for processing, the client will have the oportunity of
1. send a description of the window topology (so the server can execute the redraw itself)
2. name some specific widgets on a window and receive control socket to these (so that the client can tell the server to change the properties of a given button without having to repaint everything)
3. send a description of how 'common' events should be processed. For instance, a client would not receive any event when the user is navigating a popup menu as long as no item has been selected. The server would have received the code (or bytecode or script ... still uncertain of this) that do the menu popup and navigation (highlight selected entries) even if it's not a default widget ...

Cherry-on-Cake: dialog boxes and other configuration forms should be described in a XML-derivate and processed by a PromptRenderer that will create the required box, wait for user input, check user input validity and send back an XML document (or something more packed ...)

Details on what it should look like are already available .:here:.

_________________
Image May the source be with you.


Top
 Profile  
 
 Post subject: Re:How did you / will you be implementing your GUI?
PostPosted: Tue Oct 28, 2003 1:48 am 
Offline
Member
Member

Joined: Wed Oct 18, 2006 11:59 am
Posts: 1600
Location: Vienna/Austria
Hmm...

Two more approaches/weird ideas come into my mind,
forcing me to finally faciliate threads in my kernel land. Oh, of course, they are possible for I already use kernel threads (the drivers). but it would need something more to run them in USER space. But that's another spoon of sugar.

The first approach is the following: the window contents are drawn by the application via the gui library. It gets a drawing box, and there it draws its controls, menus, text and graphic objects. The application keeps its controls in a pivate list. then it sends the window data to the server, which copies it via a pipe and draws it onto the window buffer.

the second approach is having the windowing server keeping one thread for each application (which is represented by one window or more). this server thread and the application know from each other and can send messages thro' and forth: f. ex. redraw area, mouse clicked et cetera... . as usual it is a policy and protocol thing.

I could imagine these two approaches fitting smoothly together. I also could imagine to have Pypes approach of different "Rendering engines" implemented in this scenario. It would lead to a very multithreaded application and server thing.

widgets --- it could be that these kind of controls are drawn by library functions in user space --- and managed by some library functions linked to the user program. The server won't need to know about them. I am still unsure, because what troubles me is how to handle the text input/output correctly. Several scenarios come into my mind, like Connecting one "console" structure, which represents one input/output stream to one graphical text input/output area - just some coordinates where to draw on. Hm. It sounds so clumsy...

stay safe. Hope, I didn't confuse everything :-)

_________________
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image


Top
 Profile  
 
 Post subject: Re:How did you / will you be implementing your GUI?
PostPosted: Tue Oct 28, 2003 6:52 am 
OK, this is how I've implemented my latest GUI.

All the GUI is in user mode. The window manager runs in its own process, WINMGR.EXE, which creates a port object*. The base GUI API consists of a set of C functions, which, on the client side, send messages to the window manager. The C API is then wrapped with a set of classes.

Each control is a separate window inside the window manager, so clipping etc. works, but only the client knows how to draw controls and process input for them. In theory, you could get a different look and feel by replacing GUI.DLL with a different implementation which drew controls differently, but I think I'd prefer to stick with one theme and make that work.

Video drivers are implemented partly in kernel mode. Frame buffer drivers (i.e. 256 colours and above) consist of just mode switching; the driver provides the window manager with the name of a memory area representing the frame buffer. Drivers which require kernel code (at the moment just 16-colour modes) do all the drawing from kernel mode. The window manager batches together drawing commands and sends them all to the driver when the client flushes the queue (i.e. when it's finished processing a paint message). Hardware acceleration would be implemented this way.

Input devices are also implemented in kernel mode, using the standard keyboard and mouse drivers. The window manager has dedicated threads for each keyboard and mouse in use (you can have multiple mice, but they will share one pointer). The input threads call a central function, which could also be called by other programs (e.g. for remote control).

--
* Ports in Mobius work like sockets. A server creates a port and listens on it. When a client connects, a pipe is created and the ends are given to the client and the server. Typically the server will start a new thread for the client while the main server thread starts listening again.


Top
  
 
 Post subject: Re:How did you / will you be implementing your GUI?
PostPosted: Tue Oct 28, 2003 9:52 am 
I'll keep this short and simple. I plan to create a GUI that is based off the same ideas that AmigaOS used. The OS it's self will have a built in window manager with CLI windows (like a X window term) and if the user wants, he/she can load the desktop manager (like Workbench under AmigaOS) from CLI either through a startup script or by command. Most the GUI elements will be fixed for speed. This is a drawback for those "I want to modify every window element" kind of people, but it will make most operations much faster. Still, more items can be changed in looks, feel, ect. more than MS-Windows can :p Okay, I'll stop here to keep it short and simple. :-X


Top
  
 
 Post subject: Re:How did you / will you be implementing your GUI?
PostPosted: Tue Oct 28, 2003 10:47 am 
I was thinking that I'd just use the X Window System.

My plan is that once I get the base system up, I'll concentrate on getting the network driver working and supporting TCP/IP. After that it should just be a matter of loading CLX and connecting to a remote display.

Yes, this means that I will eventually have to write an X server in order to run a fully self-contained system, but it also means that I can leverage a large amount of work on existing libraries and whatnot.


Top
  
 
 Post subject: Re:How did you / will you be implementing your GUI?
PostPosted: Tue Dec 23, 2003 11:02 am 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 11:33 pm
Posts: 3860
Location: Eindhoven
I've been thinking about GUI stuff a little more lately, and wrote a bit of patronising rant. Hope it contains some ideas for you, here it is.

[attachment deleted by admin]


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group