GUI design
GUI design
Hi Mates
I've been out some time.. but now i'm back with my OS. And I'm trying to build a GUI uppon my kernel. And I read in the past some threads about this. My question is more an architecture than algoritmic, how you exposed you graphical API to user applications?
Do you use RPC? IPC? socket? (which is faster?) I know it depends on the core desing of my GUI: I don't have completed it yet, and i am wondering about this. As it will be event driven (the gui part), should the kernel/gui core control anything or the app?
Thanks!
Alberich
I've been out some time.. but now i'm back with my OS. And I'm trying to build a GUI uppon my kernel. And I read in the past some threads about this. My question is more an architecture than algoritmic, how you exposed you graphical API to user applications?
Do you use RPC? IPC? socket? (which is faster?) I know it depends on the core desing of my GUI: I don't have completed it yet, and i am wondering about this. As it will be event driven (the gui part), should the kernel/gui core control anything or the app?
Thanks!
Alberich
Re: GUI design
I have not started my GUI yet, but in my opinion, a directly callable interface (syscall, etc), plus IPC mechanism for uploading "texture", and then build a socket proxy on top of that if remote desktop is needed.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: GUI design
Asynchronous communication has a much better performance potential compared to synchronous ones as both the client and the server/driver can perform in parallel in such a design. However, this is very OS specific and need not at all be visible to the user.
In addition, you want to transmit the least amount of data without spending time generating that data from actual implementations. The functions, states and operations that come from there are what actually define your API as visible to the end user. How those are mapped to system calls, socket writes or memory buffers is typically performed by a library, which is also the place that deals with making remote screens and such transparent to the user.
In addition, you want to transmit the least amount of data without spending time generating that data from actual implementations. The functions, states and operations that come from there are what actually define your API as visible to the end user. How those are mapped to system calls, socket writes or memory buffers is typically performed by a library, which is also the place that deals with making remote screens and such transparent to the user.
Re: GUI design
I suggest to study X11 protocol. It cloud look hard for the first time, but later it will pay out. (Not to mention compatiblity).
Basic scheme is this:
1. client calls drawing functions in userspace library that generates buffered tokens
2. tokens are sent from client buffer to server with a syscall, just like fread/fwrite (can be socket, pipe, IPC, RPC whatever)
3. server decodes tokens and applies to a hidden pixelmap
4. if the pixelmap is the focused window, it also exposes it to screen via video device driver
It can also be used other way (user input or window resize for example) to inform the client about events on server side.
Basic scheme is this:
1. client calls drawing functions in userspace library that generates buffered tokens
2. tokens are sent from client buffer to server with a syscall, just like fread/fwrite (can be socket, pipe, IPC, RPC whatever)
3. server decodes tokens and applies to a hidden pixelmap
4. if the pixelmap is the focused window, it also exposes it to screen via video device driver
It can also be used other way (user input or window resize for example) to inform the client about events on server side.
Re: GUI design
Only if you study its downsides, too.turdus wrote:I suggest to study X11 protocol.
Every good solution is obvious once you've found it.
Re: GUI design
But of course. I never said that tokens were carefully chosen or elegant in X11 For example the fact that a display and visual are black and white by default is ridiculous nowdays. I meant the way an application, the gui server and the video driver communicate with each other.Solar wrote:Only if you study its downsides, too.turdus wrote:I suggest to study X11 protocol.
Re: GUI design
Sorry, I moved to a new flat and i was without internet.
X11 is an option, but as it is the only one I know i was trying research in other ways to do it.
But I was interested in something more asyncronous, like comsbuster said.
Any idea on how could I get soma basic interface exposed to end user? (without details, for the moment i want the ideas)
How windows, beos and mac do that?
Thanks!
X11 is an option, but as it is the only one I know i was trying research in other ways to do it.
I didn't understand what you mean, sorry.Combuster wrote: In addition, you want to transmit the least amount of data without spending time generating that data from actual implementations. The functions, states and operations that come from there are what actually define your API as visible to the end user. How those are mapped to system calls, socket writes or memory buffers is typically performed by a library, which is also the place that deals with making remote screens and such transparent to the user.
But I was interested in something more asyncronous, like comsbuster said.
Any idea on how could I get soma basic interface exposed to end user? (without details, for the moment i want the ideas)
How windows, beos and mac do that?
Thanks!
-
- Member
- Posts: 81
- Joined: Wed Nov 09, 2011 2:21 am
- Location: Behind a keyboard located in The Netherlands
Re: GUI design
alberich i could send you a electronic copy of some of the Amiga Documentation or the Copland documentation if your interested.(both are well over a decade old...)
It seems only the file system on BeOS was very well documented, since i cannot find the rest.(perhaps i am looking in the wrong places)
X11 is a interesting system the original Unix creators see it as a hack on, hence Plan9.
It seems only the file system on BeOS was very well documented, since i cannot find the rest.(perhaps i am looking in the wrong places)
X11 is a interesting system the original Unix creators see it as a hack on, hence Plan9.
Re: GUI design
What means direct? which mechanisms they are using?berkus wrote:Windows and BeOS are pretty direct. MacOS uses Core Graphics (also Quartz, Core Animation) - you can read about those in Apple documentation.
You read about PicoGUI, Fresco/Berlin and other experimental servers, too. Use Wikipedia.
Cool, if you don't mind send me please. [email protected]CrypticalCode0 wrote:alberich i could send you a electronic copy of some of the Amiga Documentation or the Copland documentation if your interested.(both are well over a decade old...)
It seems only the file system on BeOS was very well documented, since i cannot find the rest.(perhaps i am looking in the wrong places)
X11 is a interesting system the original Unix creators see it as a hack on, hence Plan9.
I looked for haiku instead of beos, as beos filesystem only has dominic's book and in some ocasions is not quite acurated.
But for the moment i'm only look for ideas and different ways of doing it.
thanks boths for the reply
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: GUI design
In other words, you might want to do some actual research into how all current platforms work. That's much faster than being able to ask two simple questions a day and getting short answers because the people don't have more time than you.
Re: GUI design
Thanks for the answers
Just for the record, I was not planning to get the magical solution from here.. only people opinions.
things like you feel rpc better? rpc into the kernel, outside? etc...
or more concrete ones: what do you thing about controlling a window render buffer? application has the buffer which is copied by the manager? or the manager has it, and makes it available to the app?
Just opinions,.. not magical answers. I'm not here for you to build my os, i'm here becouse i like doing this kind of research and exchanging info.
sorry if it seems the opposite.
Alberich
Just for the record, I was not planning to get the magical solution from here.. only people opinions.
things like you feel rpc better? rpc into the kernel, outside? etc...
or more concrete ones: what do you thing about controlling a window render buffer? application has the buffer which is copied by the manager? or the manager has it, and makes it available to the app?
Just opinions,.. not magical answers. I'm not here for you to build my os, i'm here becouse i like doing this kind of research and exchanging info.
sorry if it seems the opposite.
Alberich
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: GUI design
Anything synchronous has unavoidable scaling issues. For the rest, the implementation of the data transfer is a detail and does not really influence neither performance nor how a programmer sees it. Every fancy term you see is just another description of IPC - either synchronous or asynchronous - and therefore is not a meaningful discussion.
Many of the buffer things are the same thing. In all cases data has to be transferred from one end to the other. If this happens efficiently people are happy. How this happens under the hood is something end users don't really want to care about.
Many of the buffer things are the same thing. In all cases data has to be transferred from one end to the other. If this happens efficiently people are happy. How this happens under the hood is something end users don't really want to care about.