Hello,
I’m doing some research on what it would take to create an entire
desktop environment based on SDL. My initial thought is that it would
need to be broken into two major components. The first would be
something like a “window manager” in X, i.e. it would initialize the
screen, possibly draw the background, perform window management and
broker mouse and keyboard events. We can call that SWM for now. The
second part would be a widget toolkit for drawing all the buttons,
labels, etc. and responding to the events generated by the “window
manager”. We can call that STK for now.
My first question would be how to handle the events. It would seem
to me that since SDL receives the actual events from the user, I would
have to come up with some way to expose those to the individual client
programs which utilize the widget toolkit. I’m thinking of something
like a publish-subscribe model here, but I’m not really sure. How
does this work with X and GTK for example?
Second, how would my “client” programs get a reference to the SDL
screen surface? A program using the “STK” would be running in a whole
separate process from the window manager so would a call to
"SDL_GetVideoSurface()" retrieve the correct surface (or any surface
at all)?
Last question. Is SDL too high-level for something like this?
Would OpenGL or some other lower level library be more appropriate?
In the end, I would like to have a hardware accelerated GUI that does
not depend on X.
Any input would be greatly appreciated. Thanks!–
Clayton Hicklin @Clayton_Hicklin
I’ve also been working on a desktop environment on a smaller scale. I would definitely use OpenGL where possible (as I am). The trend is for modern I ended up using X for input and setting window properties of the actual Desktop and Dock application.
As far as how you expose the events to the consumer of your toolkit, it seems that most toolkits implement callbacks do achieve this. I don’t think you could do immediate mode events. It may be possible to do a queued event system and let that queue be accessed by the consumer (which is what I’m doing).
hope that helps.> ----- Original Message -----
From: Clayton Hicklin
To: sdl at lists.libsdl.org
Sent: Monday, March 24, 2008 9:29:06 AM
Subject: [SDL] SDL desktop environment
Hello,
I’m doing some research on what it would take to create an entire
desktop environment based on SDL. My initial thought is that it would
need to be broken into two major components. The first would be
something like a “window manager” in X, i.e. it would initialize the
screen, possibly draw the background, perform window management and
broker mouse and keyboard events. We can call that SWM for now. The
second part would be a widget toolkit for drawing all the buttons,
labels, etc. and responding to the events generated by the “window
manager”. We can call that STK for now.
My first question would be how to handle the events. It would seem
to me that since SDL receives the actual events from the user, I would
have to come up with some way to expose those to the individual client
programs which utilize the widget toolkit. I’m thinking of something
like a publish-subscribe model here, but I’m not really sure. How
does this work with X and GTK for example?
Second, how would my “client” programs get a reference to the SDL
screen surface? A program using the “STK” would be running in a whole
separate process from the window manager so would a call to
"SDL_GetVideoSurface()" retrieve the correct surface (or any surface
at all)?
Last question. Is SDL too high-level for something like this?
Would OpenGL or some other lower level library be more appropriate?
In the end, I would like to have a hardware accelerated GUI that does
not depend on X.
So, would you recommend keeping X and maybe using GLUT to handle the
windows, events and input and then using OpenGL to create the widget
toolkit? Would this really provide any performance benefits over,
say, Gtk or QT? Do you think there is any benefit to taking X out of
the mix? I was thinking of something like Apple’s Quartz where the
display system relies heavily on OpenGL and isn’t tied to X.> Date: Mon, 24 Mar 2008 13:39:07 -0700 (PDT)
From: Kevron Rees
Subject: Re: [SDL] SDL desktop environment
To: “A list for developers using the SDL library. (includes
SDL-announce)”
Message-ID: <629234.57490.qm at web1004.biz.mail.sp1.yahoo.com>
Content-Type: text/plain; charset=us-ascii
I’ve also been working on a desktop environment on a smaller scale. I would definitely use OpenGL where possible (as I am). The trend is for modern I ended up using X for input and setting window properties of the actual Desktop and Dock application.
As far as how you expose the events to the consumer of your toolkit, it seems that most toolkits implement callbacks do achieve this. I don’t think you could do immediate mode events. It may be possible to do a queued event system and let that queue be accessed by the consumer (which is what I’m doing).
hope that helps.
----- Original Message ----
From: Clayton Hicklin <@Clayton_Hicklin>
To: sdl at lists.libsdl.org
Sent: Monday, March 24, 2008 9:29:06 AM
Subject: [SDL] SDL desktop environment
Hello,
I’m doing some research on what it would take to create an entire
desktop environment based on SDL. My initial thought is that it would
need to be broken into two major components. The first would be
something like a “window manager” in X, i.e. it would initialize the
screen, possibly draw the background, perform window management and
broker mouse and keyboard events. We can call that SWM for now. The
second part would be a widget toolkit for drawing all the buttons,
labels, etc. and responding to the events generated by the “window
manager”. We can call that STK for now.
My first question would be how to handle the events. It would seem
to me that since SDL receives the actual events from the user, I would
have to come up with some way to expose those to the individual client
programs which utilize the widget toolkit. I’m thinking of something
like a publish-subscribe model here, but I’m not really sure. How
does this work with X and GTK for example?
Second, how would my “client” programs get a reference to the SDL
screen surface? A program using the “STK” would be running in a whole
separate process from the window manager so would a call to
"SDL_GetVideoSurface()" retrieve the correct surface (or any surface
at all)?
Last question. Is SDL too high-level for something like this?
Would OpenGL or some other lower level library be more appropriate?
In the end, I would like to have a hardware accelerated GUI that does
not depend on X.
Hello,
I’m doing some research on what it would take to create an entire
Last question. Is SDL too high-level for something like this?
Would OpenGL or some other lower level library be more appropriate?
In the end, I would like to have a hardware accelerated GUI that does
not depend on X.
For that you will need hardware acceleration at the kernel level. As far
as I know only X knows how to speak “accelerated” in the graphic chips.
fbcon is just a dump framebuffer but of course it is a good solution
for systems with limited resources in order to avoid X.
Just throwing this out there in case people are interested in this
system. I’m currently too busy to work actively on this project myself.
Agar (http://libagar.org/) implements an internal window manager and it
can render itself using either pure OpenGL or SDL. We have a small proof
of concept “standalone” window manager called agarwm in our development
branch (http://dev.csoft.org/agar/branches/agar14), but it is in very
early development stages (more details in agarwm/README).
The idea is to have applications communicate with the window manager
through a Unix socket or TCP connection. Most of the GUI logic executes
in the window manager process, so your application is not rendering
things, processing mouse events or anything of the sort. This also
improves performance for applications running over the network (local,
GUI-intensive applications on multiprocessor systems also benefit from
this). Sure, we could stream framebuffers, rendering data and input
events over the network but that would be reinventing the wheel, X
already does that.
In an application, you would create a “remote window” and your GUI code
would look similar to a traditional GUI code, with some restrictions
(you cannot pass pointer arguments to your event handlers for instance).
To accomodate visualization of dynamic structures that reside in the
application process, low-level rendering instructions can be sent (for
things like vector drawing), or shared memory can be used (for things
like video).> On Mon, Mar 24, 2008 at 10:29:06AM -0500, Clayton Hicklin wrote:
Hello,
I’m doing some research on what it would take to create an entire
desktop environment based on SDL. My initial thought is that it would
need to be broken into two major components. The first would be
something like a “window manager” in X, i.e. it would initialize the
screen, possibly draw the background, perform window management and
broker mouse and keyboard events. We can call that SWM for now. The
second part would be a widget toolkit for drawing all the buttons,
labels, etc. and responding to the events generated by the “window
manager”. We can call that STK for now.
My first question would be how to handle the events. It would seem
to me that since SDL receives the actual events from the user, I would
have to come up with some way to expose those to the individual client
programs which utilize the widget toolkit. I’m thinking of something
like a publish-subscribe model here, but I’m not really sure. How
does this work with X and GTK for example?
Second, how would my “client” programs get a reference to the SDL
screen surface? A program using the “STK” would be running in a whole
separate process from the window manager so would a call to
"SDL_GetVideoSurface()" retrieve the correct surface (or any surface
at all)?
Last question. Is SDL too high-level for something like this?
Would OpenGL or some other lower level library be more appropriate?
In the end, I would like to have a hardware accelerated GUI that does
not depend on X.