Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Hello folks;
As you notice, I'm trying to write a hobbyOS and I have some doubts and concern about "Desktop" issue.
I have finished, tasking, vesa, etc... So, I have a graphical desktop BUT ! I need "window"'s. how should I manage this things ?? moreover, In which way the kernel make callbacks to user programs ???
That's my major problem, acutally I've a little confision too, Intel have a new timer chip as called "HPET", Is it worth to change current codes ?(ACPI is a annoying )
The long answer is: There are disagreements about where the GUI should be implemented: Kernel mode or as a user process. The census here seems to be userspace, (look at X.org for an example... note that that's probably 20 time more complex than you need, but a good example nonetheless)
On the other hand, at least one successful OS uses a kernel-mode GUI: Windows. Whether or not that's a good example is up for debate, and the author of this post refuses to take a side.
So, getting back to your question, the traditional way is to have an array (or list, or some other data structure) of some kind of window descriptor, which describes the height, width, position, type (toolbox, main window, sub-window...), state (minimized, maximized, rolled up, ...), layer (Always on top, etc) and other data describing a window. To actually draw to a window, there are traditionally calls like "draw line", "fill box", "draw circle", etc. If you also have a widget toolkit builtin (which handles buttons, checkboxes, textboxes, etc), you'd also need functions for that: "create button", "create checkbox", "create menu", etc.
It is open for debate whether callbacks or polling is better for handling events, with polling being more flexible, but usually used to implement a callback-based system, while callbacks are easier to work with, but somewhat less flexible.
Disclaimer: I have not actually implemented a GUI, so this is all theoretical. If my suggestions work, then I'm better at pulling authoritative-sounding verbiage out of my @$$ than I thought. If it doesn't work, at least it was a learning experience.
Heh.
(note, volume 2 will come when I actually do implement a working GUI)...
Phoenix wrote:I have finished, tasking, vesa, etc... So, I have a graphical desktop BUT ! I need "window"'s. how should I manage this things ?? moreover, In which way the kernel make callbacks to user programs ???
I'd implement some sort of generic communication system, and use that to deliver "GUI events" (and any other communication between tasks, parts of the kernel, device drivers, etc).
Phoenix wrote:That's my major problem, acutally I've a little confision too, Intel have a new timer chip as called "HPET", Is it worth to change current codes ?(ACPI is a annoying )
How many computers have a HPET (AFAIK only "recent" Intel chipsets support it), how hard is it to add support for it to your OS, and what benefits would it provide to your OS?
If you had a list of things that you want your OS to support, would HPET be at the top of the list, at the bottom, or somewhere in the middle?
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
TheQuux wrote:
The long answer is: There are disagreements about where the GUI should be implemented: Kernel mode or as a user process.
Exatcly, that my delimma
Brendan wrote:Hi,
I'd implement some sort of generic communication system, and use that to deliver "GUI events" (and any other communication between tasks, parts of the kernel, device drivers, etc).
It seems so, I think I should write a IPC first. I have already shared mem. but It's not enough.
However one thing is certain. There is lots of struct needed for windows...
Thank for you TheQuux, Brendan
