DirectFB backend, I'm going for it!

[Chad Hardin]

This email is just an announcement that I'm starting work on a new 
directfb backend for GNUstep, plus some issues I'd like to bring up.

After a short discussion with the directfb people, i have decided that 
directfb would be a good way to go for a desktop-based gnustep backend. 
 I had concerns with it before concerning each app needing to 
cooperatively lock resources, but I don't think this will be much of a 
problem now.

I've got GSDisplayServer and WIN32Server all figured out and I think 
that I will use WIN32Server as a guide for the new backend.  The model 
of a directfb backend seems more similar to the windows way of doing 
things than the X11 way.

There will be some issues though, I'd like to discuss there:

One:  There is no concept of a window manager in directfb.  All clients 
need to draw and handle events for their window decorations

Two: Since there is no central controlling window manager, there is no 
built-in way of handling proper placement of appIcons and miniwindows.  
As miniwindows are made, they should form a nice neat row on the bottom 
of the screen, that requires some type of inter-app cooperation and/or 
a manager of some sort.

Three:  Layers, directfb has no concept of layers.  I noticed that the 
WIN32Server just ignores layers and I'm wondering how well this works.  
For example, do menus get covered up by windows, etc?

I think I can handle One by simply putting in window decoration code 
and handling in DirectFBServer.  However, in order to actually draw to 
the screen it would need to use the other half of the backend, call it 
DirectFBLib.  So I'm wondering if there will be problems with the 
server side of the backend drawing to the screen and hence relying on 
the graphics side of the backend.  What do you all think, will there be 
a problem with this type of thing?  If there will be, I can simply do 
the window decoration drawing using native direcfb graphics calls 
rather than GNUstep graphics calls, but that is obviously not the 
preferred route.

About Two:  It seems that there will HAVE to be some type of 
inter-process communication going on for this, probably 
NSDistributedNotificationCenter?  The question is then, who will handle 
this?  Maybe a dock something like Apple's dock which swallows appicons 
and miniwindows?  I was thinking something along the lines that 
whenever an app is supposed to create an appIcon and when it's windows 
are supposed to become miniwindows they instead tell the Dock (or 
whatever is handling it) to do it instead.

This would be a big break from current GNUstep L&F, that's why I'm 
asking about it.  If the idea of an Apple like dock is disturbing to 
many people, I can set up some type of inter-app negotiation so that 
they properly place their appicons and miniwindows the GNUstep way, 
without covering each other up.


Thanks!

Chad