Hi,
I'm not a DirectFB hacker neither, but I would be interested too. There
have been some emails during November/December discussing this issue.
I think starting from scracth could be a good idea. "Unique" could be
useful just for having some ideas at the beginning of development.
I think that a good starting point could be having a kind of wish-list of
the things we want the DFB WM to do and how it will do it.
A first draft could be the this list (points 4 and 5 were taken from Mike
Emmel emails).
These are only some fuzzy ideas that need a lot of work to make them real:
1. Provide a light, fast and reliable windowing system for DirectFB.
2. Provide transparently the benefits of DirectFB
- It's fast
- It's light
- It's stable
- It has a small size
3. Capable to be used in embedded devices:
- Reduced resources usage, specially memory and processor
- Small foot-print
- Support of small resolutions
- Support of a full-screen windowing system
4. Refactor the code so all of the current wm is loaded as a shared
library. Once this is done its up to the WM to provide the DFBWindow
interface implementation.
5. Consider expanding the concept of a window to be two parts:
First a region for events.
Next consider the current back buffer flip only one operation that can
be performed to show a window.
The operator is a chain of primitives that is executed to show a window.
The default operator is to flip a back buffer but other operations are
possbile. The only restriction is that any needed resources such as images
would need to allocated in shared memory. The base set of operators would
be all the core drawing ops of directfb.
For "secure" apps one operator would be a custom callback that exists
in a shared library loaded into the root process.
Libraries like cairo could be used to generate advanced drawing/blitting
chains.
6. Support for GTK+
If Cairo is the graphics rendering engine and the other GTK+ libs
are available (Glib, ATK, ...) support can be provided for GTK+
taskbars, statusbar, panels, icons and potentially Gnome apps
7. Support of virtual desktops
In embedded devices it could become a full-screen windowing system
I hope in the following days to start working on it (as time and my
real-job allow).
Pedro Aguilar
> Hi
>
> I would like to give a WindowManager for DirectFB a shot.
> Could anyone give me a few pointers or things I should be aware of.
> Have a little experience with DirectFB, but not too much.
> Should I use the "default" or "unique" WM as stating point or none?
>
> How does DirectFB select a WM?
> What kind of functions/API must the WM facilitate ?
>
> Regards Martin Lütken
>
>
>
> _______________________________________________
> directfb-dev mailing list
> [email protected]
> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
>
>
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
