I am in the process of implementing an LCARS like operating system.
This project consists
1) of my base os, which is is being designed to be posix-ish.
2) the LCARS GUI.
The gui I am developing under linux, then as the os development completes a dependency, i port that part of the gui over.
Dont have anything perty, yet. but it is coming along.
If any one is interested in LCARS, pm me.
I will share.
LCARS GUI
Re: How did you / will you be implementing your GUI?
exactly.
I had never seen that site, so thanks for the link, but that is exactly like what I am doing.
I have a semi-functional interface build for Linux.
I am using that as the basis for the interface for my os.
As far as I could tell, no one has yet to actually create an OS based on LCARS.
If I am wrong, please let me know.
I had never seen that site, so thanks for the link, but that is exactly like what I am doing.
I have a semi-functional interface build for Linux.
I am using that as the basis for the interface for my os.
As far as I could tell, no one has yet to actually create an OS based on LCARS.
If I am wrong, please let me know.
-
carbonBased
- Member
- Posts: 382
- Joined: Sat Nov 20, 2004 12:00 am
- Location: Wellesley, Ontario, Canada
- Contact:
Re: How did you / will you be implementing your GUI?
I wrote a GUI/windowing system for a high-school project many moons ago, and I'll likely draw upon experiences in that while designing the GUI for my OS.
From a system's level point of view, the GUI will be maintained by a userland application, as all services of my OS are. The application will interface with the graphics driver (which is also a userland application which has requested ownership of the framebuffer hardware (and so will need to be allowed access to them)).
Applications will request windows from the GUI-server application through a messaging API. From the window object, the application can get a pointer to a region of memory which it can use to construct it's display using whatever means it so chooses. This region of memory is mapped into both the application and the GUI-server application's memory space. The GUI server then displays the window and handles any overlapping, etc, logic.
This system means that every window will have it's own back-buffer, which consumes more memory then most windowing systems (this would be roughly the equivalent of having all applications on an X11 system using the MIT XSHM extension), but given the complexity of application appearances now-a-days, I don't think communicating graphics primitives (lines, poly's, etc) through a messaging system is very efficient anymore (there would be so many individual pixel plots, and extra meta-data sent for shading and transparency options, etc).
With this system, the application need-not know anything about the windowing system itself (ie, there is no need for a "redraw" event, for example, when a section of window becomes exposed. The GUI-server can handle this simply by copying over that portion of the application's backbuffer to the screen).
This system also isn't far off from a compositing window manager, and so could easily support multiple levels of transparency or various other compositing effects, if desired (eg. wobbly windows, desktop cubes, etc).
Nothing much new here, but that's my current thoughts on the topic.
From a system's level point of view, the GUI will be maintained by a userland application, as all services of my OS are. The application will interface with the graphics driver (which is also a userland application which has requested ownership of the framebuffer hardware (and so will need to be allowed access to them)).
Applications will request windows from the GUI-server application through a messaging API. From the window object, the application can get a pointer to a region of memory which it can use to construct it's display using whatever means it so chooses. This region of memory is mapped into both the application and the GUI-server application's memory space. The GUI server then displays the window and handles any overlapping, etc, logic.
This system means that every window will have it's own back-buffer, which consumes more memory then most windowing systems (this would be roughly the equivalent of having all applications on an X11 system using the MIT XSHM extension), but given the complexity of application appearances now-a-days, I don't think communicating graphics primitives (lines, poly's, etc) through a messaging system is very efficient anymore (there would be so many individual pixel plots, and extra meta-data sent for shading and transparency options, etc).
With this system, the application need-not know anything about the windowing system itself (ie, there is no need for a "redraw" event, for example, when a section of window becomes exposed. The GUI-server can handle this simply by copying over that portion of the application's backbuffer to the screen).
This system also isn't far off from a compositing window manager, and so could easily support multiple levels of transparency or various other compositing effects, if desired (eg. wobbly windows, desktop cubes, etc).
Nothing much new here, but that's my current thoughts on the topic.
Re: LCARS GUI
Hi ,
Most of the common UI frameworks make use of the model view controller . Find some good discussion here
--Thomas
Most of the common UI frameworks make use of the model view controller . Find some good discussion here
--Thomas
Re: LCARS GUI
Moved to correct subforum.