[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: |
Sat, 10 Jan 2004 16:03:05 +0700 |
On 2004-01-10 09:16:30 +0700 Chad Hardin <address@hidden> wrote:
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?
GSDisplayServer you mean? Kinda, once create an NSWindow, an extra window should
be created along. Since the reparent shouldn't be use, it could be good to make
a logical
window device that contains more than one actual device, like one logical
window can
have a subwindow for titlebar, context view and toolbar :D so, when you create
a window,
it is logical in displayserver , and 2-3 windows were created and will appear
on the appkit-side.
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.
If you use nsgraphiccontext to draw, there shouldn't be a problem.
Write a GSWindowTitleView or something, put it on a logical window mentioned
above.
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.
[...]
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?
When you are moving a window you may want to know other windows' geometries
so you can do something like docking or edge resistancy.
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.
Cool :)