Chad Hardin wrote:
[snip]
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?
I don't think there'd be any technical problems (at least none that
couldn't be solved fairly easily). It would make your server part
depend
on your graphics part, but you might not have a problem with that.
That said, I (still) have a TODO for implementing window decoration
drawing in -gui that could be used in backends that don't have any
"native" window decorations. In short, the plan is to have a
-(BOOL)handlesWindowDecorations in GSDisplayServer. If the backend
returns NO, things behave like they do now. If it returns YES, -gui
will
include window decorations in the window, and will handle movement,
resizing, etc. by itself.
[snip]
About Two: It seems that there will HAVE to be some type of
inter-process communication going on for this,
Yes.
probably NSDistributedNotificationCenter?
Depending on what you actually need to do, distributed notifications,
DO, something dfb-specific, or something completely different may be
the
most appropriate. :)
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.
-gui will do some of this for you, so you should just have to watch the
masks and do the Right Thing with those kinds of windows. There are
many
possible ways of doing this, so unless directfb restricts it, how is up
to you.