[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GWorkspace future
From: |
Sheldon Gill |
Subject: |
Re: GWorkspace future |
Date: |
Wed, 4 Feb 2004 13:34:58 +0800 |
User-agent: |
KMail/1.6.50 |
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.
> - 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
thing and I can see no reason to inhibit that. Where desktop databases and
additional meta-information go is probably a separate thread...
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.
> - 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)
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.
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.
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.
Regards,
Sheldon