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

[Chad Hardin]

On Jan 9, 2004, at 2:06 AM, nicolas@roard.com wrote:

> Selon Chad Hardin <cehardin@mac.com>:
>
> > 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.
>
> good !

Thx, :-)
> > 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.
>
> In my opinion, the L&F has nothing to do with it. What is needed imho
> are distributed notifications for some of the window's actions --
> iconification comes to mind for example.
> And it's not a problem limited to your DirectFB backend; the problem
> is the same with others backends. For the moment, the only Dock which
> works well is the WindowMaker's one, because it deals directly with
> WindowMaker. If we want others well-working docks, we need a 
> cooperation
> between the Dock and the window manager or whatever fits that role on
> others backends; another (more direct) method to get the needed i
> nformations, instead of a window manager cooperation, is effectively
> for gnustep apps to send distributed notifications. It has nothing
> to do with the type of Dock (eg, a NeXT-like dock, an OSX dock, or
> even a panel)...

I can see that.  Putting in notifications at the -gui level for 
everytime something like a window creation, minimize app launch, etc 
happens.  The dock, of whatever sort, can listen to these notifications 
and respond somehow.
I guess this would mean a new daemon or an extension of an existing 
one.  I guess it wouldn't affect anything if the apps are pumping out 
these messages, they can just be ignored I suppose, and windowmaker, 
kppanel, etc can just keep on doing what they do.


Speaking of a new deamon, last time I looked,  [NSWorkspace 
-launchedApplications] only returned the applications which were 
launched *after* the calling app waas launched.  (It's supposed to 
return all launched applications).  This looks like daemon material.

Or maybe the original NeXT way was for the actual WorkspaceManager.app 
itself keep track of these things and provide all these services we can 
get through NSWorkspace?

I ran into this problem way back when when I made GSDock.  If the dock 
crashed and was rerun, it was no longer aware of any Apps which were 
started previously.


> So what's needed is to identify the different notifications needed and
> implement them... two obvious ones are iconification and 
> deiconification,
> we could also have one when the program is ready (eg, to be able to
> reproduce the bouncing icon of OSX's dock) after launch, and I guess
> another notification could be emitted when the program is terminated.
> Others ideas of notifications ?

I think so to, but thinking and doing are two completely different 
concepts in open source.  :-)
Even if I wanted to go ahead and started to put these notifications, 
someone would probably (likely rightly) disagree with the way I did it. 
 That is why I'm hoping this can start a thread discussing this.  
Assuming many people even end up reading this... :-)

icon/deicon.  We can already find out when a program is ready..it 
already broadcasts when this happens.

that's is why GSDock can do "shrinking/growing" (like bouncing, but 
kept in a Tile) apps when they are launched.

Some other things?

hmm, how about when an app changes it's AppIcon?  That should be 
something to share as well.




> BTW that doesn't answers another problem, which is how can we provide
> "animated" iconapp -- currently the iconapp is simply a NSWindow and
> you could draw in it, but that's doable because WindowMaker's Dock
> directly handles the window ...

i guess the app can broadcast that it changed the icon and then whoever 
cares can query what the new icon is?


Chad


> --
> Nicolas Roard