[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