[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GWorkspace future
Re: GWorkspace future
Wed, 04 Feb 2004 14:08:37 +0200
On 2004-02-04 07:34:58 +0200 Sheldon Gill <address@hidden> 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.
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
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've no intention of make it invisible. I wrote that period without thinking...
(for Lars: ok, I'll write the list view :-) )
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.
Ok. Then I'll write a protocol to be used for writing bundles that the app will
load only from, say, $GNUSTEP_USER_ROOT/Library/Desktop.
The tabbed shelf will be a default element (you can anyway remove its bundle).
This because it simulates transparency between the tabs using a NSImage taken
from the undelying NSView.
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.
This is exactly what actually already happens in the main application; take a
look in GWorkspace/GWorkspace.m, in
-performFileOperation:source:destination:files:tag: and in
GWorkspace/FileOperations/FileOperation.m. In this case the progress windows
belong to the main threrad, while the operation itself is run in an other
thread, To put all this stuff in a separate app should not represent a overhead.
The need of a separate app comes from the fact that it is the dnd taget to
start the operation. And, with the proposed solution, we'll have such objects
in more of one application; in the file viewer, in the desktop, in the finder,
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)
Again, this feature is part of GWorkspace since years. I wrote the daemon (it
is already on CVS), because there will be many apps intrested in these
FIEND, SHELF AND DOCK
Omni-present docks, multiple workspaces, mini-windows. These all are things
that imply access to the backend/window manager. GWorkspace is only a GNUstep
application and can't do anything for them. The actual fiend is only a
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
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
BTW In my last mail I've written also about an integration of the GWorkspace
and GWNet viewers but, till now, I've had no report regarding GWNet. Does it
work? Problems? Bugs? It is a new application (tested only by me) and I can't
think that it has no problems...