discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GWorkspace future


From: Aredridel
Subject: Re: GWorkspace future
Date: Wed, 4 Feb 2004 00:49:59 -0700
User-agent: Mutt/1.4.1i

On Wed, Feb 04, 2004 at 01:34:58PM +0800, Sheldon Gill wrote:
> On Tue, 3 Feb 2004 21:25, Enrico Sersale wrote:
> > I would to split GWorkspace in some applications.
> > Please, let me know what you think about this.
> 
> I think this is absolutely the right way to go.

Ditto.  Smaller apps == easier to test. Compare Evolution to
Pine+ical+whatnot.

> 
> > - Desktop:
> > The actual desktop window, the tabbed shelf and a trash.
> > Already having the shelfs of the viewers, the tabbed shelf and the fiend,
> > the desktop would represent a place in the file system (probably
> > $GNUSTEP_USER_ROOT/.Desktop).
> 
> I would think "Desktop" rather than ".Desktop".  Having it browsable is a 
> good 
Ditto. I hate the clutter, but "Desktop" sorts nicely and isn't that
bad. (as opposed to evolution's use of my homedir's namespace, for a
single app!)

> I'd suggest it's better to separate the "Desktop" from shelf/fiend/dock 
> entirely. That way it's easier to experiment with different implementations 
> of those elements which the desktop layer remains.

Absolutely.

> > - Operation:
> > The app that performs the file operations ans shows their progress.
> 
> Again, the right approach. I would think, though, that we'd need to develop 
> some reasonably clever architecture to do this well. If the operation is 
> quick then the overhead of creating a new process, opening a new windows and 
> trying to display progress will slow things unacceptably.
> 
> > - fswatcher:
> 
> This is basically fam integration. Do we need a separate daemon to wrap it? 
> Given the other Workspace notifications we're interested in I'm thinking that 
> it's best done within the "main" app, probably the one responsible for the 
> desktop itself as it'll need to receive such information and add to it (icon 
> changes, labelling, mounting/unmounting and so on)

Yeah.. one more daemon seems a bother.

> 
> FIEND, SHELF AND DOCK
> =================
> 
> I think that the "fiend/miniwindow" as we have it shouldn't be part of 
> gnustep-gui but rather a feature of the workspace in which the application 
> runs.
> 
> I believe it should be the responsibility of the <desktop environment> to 
> display the mini-window/fiend in a way appropriate for it.

Yes.  One of my dreams for my copious free time is to write a GNOME dock
for GNUstep apps and others to use. Moving that way would be great.

> The current situation is that the backend is responsible for deciding if 
> miniwindows should be handled by the application itself.  So it's all or 
> nothing for a particular display server.  It's enabled for X, so you get 
> miniwindows under all window managers. I think it's time it became a separate 
> thing so those using (eg. Window Maker) can have the same old but those using 
> different desktops can have something more appropriate.

Yes, please!

> All the miniwindow handling is dead code for Windows. We can clean things up. 
> 
> There's another reason, here, too.
> One long term goal for GNUstep is flexible themes.  This is going to be an 
> issue for applications which direct changes to their mini-window. Planning 
> the architecture now is probably the right time as you're looking at the 
> whole picture.

Yeah. For sure.

> 
> 
> Regards,
> Sheldon
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep




reply via email to

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