[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DirectFB backend, I'm going for it!
From: |
Banlu Kemiyatorn |
Subject: |
Re: DirectFB backend, I'm going for it! |
Date: |
Fri, 09 Jan 2004 23:33:39 +0700 |
User-agent: |
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 |
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)
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 :)
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.
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.
id