[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

DirectFB backend, I'm going for it!

From: Chad Hardin
Subject: DirectFB backend, I'm going for it!
Date: Thu, 8 Jan 2004 18:39:58 -1000

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]