Re: DirectFB backend, I'm going for it!

[Chad Hardin]

On Jan 9, 2004, at 6:28 AM, Banlu Kemiyatorn wrote:

> Chad Hardin wrote:
>
> > 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.
>
> I think you can also draw the window decoration using NSView by
> making 2 views to share a single window, the content view
> and the titlebar view. The titlebar view should know to draw itself
> outside the window geometry that excluded the titlebar's height.
> (I suggested the use of NSView so you can share the drawing code
> with the graphic context backend)

Now this is where I get a bit perplexed.  By looking at GSDisplayLayer 
I get the impression that it was designed so that subclasses of itself 
draw all the decorations.  Are you suggesting changing NSWindow so that 
it can optionally draw its own decorations?

Also, will handling dealing with NSViews at the backend-server side 
level even work?  It's this side of the backend which tells the app 
what it's content rectangle is.  Or maybe the bigger question is:  
should I handle the window decorations using regular directfb calls in 
the server side of the backend or somehow nudge them into the display 
side of the backend?  Sorry about the questions, but it's kinda 
confusing to me the best way to go about this.

I'm starting to think the simplest solution is to handle the window 
decorations in the server-side of the backend, using directfb calls.  
I'm open to other ideas but at this point I'm not really sure how to 
implement the window decorations using NSViews.


> > 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.
>
> Or you can just write a small windowing system base on directfb,
> but i have suggested that serveral times so it seems you don't like
> the idea :)

Hehe, because it would run counter to the way the direcfb API works.


> Using NSDistributedNotificationCenter is quite expensive and possibly 
> unneccessary operation. Having a server that act like a window manager
> that allow you to access other apps' geometries would be cheaper.

I had not even though about apps wanting info from each other.  Would 
this be needed?  My thinking was more along the line of each app 
talking to a single manager of some sort (like a Dock), not to each 
other.  Because of this, the only times I could foresee any 
communication going on would be for window creation/destruction and 
window iconification/deiconification.  These things don't happen enough 
for the speed of the communications to be an issue.

Then again, maybe there's something I'm missing here:  maybe it will be 
necessary for apps to broadcast the geometries as they are moved around 
and such?




> ie. why would you broadcast a recent geometry of the window that you 
> are
> moving to other apps that shouldn't concerned of it? It would be less
> complicate to have a single server controller that each app can 
> register
> themselves only for the neccessary information.


This is what I was thinking, a single app.  whether it be a gnustep 
daemon, a dock, or a combination (the apps tell the daemon, the daemon 
passes it to the dock, or whoever registers to listen).

> id



Either way, I think I can go ahead and start blasting out the more 
basic parts of the code for both sides of the backend.  I'm sure there 
will have to be some adjusting down the line though.


Chad