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

[Banlu Kemiyatorn]

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 :)