[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chad Hardin
Subject: Re: DirectFB backend, I'm going for it!
Date: Fri, 9 Jan 2004 16:35:27 -1000

On Jan 9, 2004, at 2:06 AM, address@hidden wrote:

Selon Chad Hardin <address@hidden>:

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?


Nicolas Roard

reply via email to

[Prev in Thread] Current Thread [Next in Thread]