GWorkspace future

I don't know which part it is that I should reply to, but what I am
missing is a Dock like part of the Workspace.

If I dock Preferences on the Window Maker Dock and double click the app
icon I have a clock on my desktop.
If I dock Preferences to Fiend and double click the app icon I get a
clock on the bottom of my screen with all other icons.

And yes I think this omni-present Dock should hold the recycler. It's
probably not very NeXT like, but I love having different Workspaces like
WindowMaker has (and almost any wm). So a Dock that is omni-present with
certain apps available on any workspace (fileviewer, preferences,
recycler) would be nice and a Fiend for apps on a certain workspace.

Maybe I am way off of what you are asking and I really appreciate all
the work you have put into GWorkspace. But somehow your e-mail triggert
a train of thought :)

Greetings,

Dennis Leeuw

Post by Enrico Sersale
I would to split GWorkspace in some applications.
Please, let me know what you think about this.
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).
A window containing something like the actual Contents Inspector.
Besides the usual content viewers (files contents and pasteboard data),
Inspector should also accept bundles sent as NSData by applications,
that is, an app will be able to add a viewer for a type of data.
The Finder; but with many new features.
The GWorkspace and the GWNet viewers in a single application + the fiend
and the recycler (on the fiend?)
The app that performs the file operations ans shows their progress.
A daemon that notify the registered applications when the contents of a
directory have changed. Actually, this feature is implemented in GWLib,
in the FSWatcher class.
(fswatcher is already on CVS and works much better than the old solution)
_______________________________________________
Discuss-gnustep mailing list
http://mail.gnu.org/mailman/listinfo/discuss-gnustep

Lars Sonchocky-Helldorf

2004-02-03 14:52:50 UTC

Post by Enrico Sersale
I would to split GWorkspace in some applications.

I like this idea very much, it enables the user to create a desktop
enivronment from components of her/his choice. (Btw. this is also good for
porting Gworkspace to Cocoa since some of the funtionality already
existing there does not need to be doubled (the Dock for instance).)

Post by Enrico Sersale
Please, let me know what you think about this.
The actual desktop window, the tabbed shelf and a trash.

The tabbed shelf is something with a dock licke funtionality or I am wrong
here? If so, I think the shelf/dock should be a component of it's own.

Post by Enrico Sersale
Already having the shelfs of the viewers, the tabbed shelf and the

fiend, the desktop would represent a place in the file system (probably

Post by Enrico Sersale
$GNUSTEP_USER_ROOT/.Desktop).

Agreed. But why should the Destop be invisible in browser windows (I asume
that's what you like to express with the leading period)? On Mac OS X the
Desktop is also visible in the browser window, this is good if you employ
the list view (like visible here:
Loading Image...

) to sort the files by Name,
Date modified, size, filetype ... whatever column you click. I use this
regulary on Mac OS X to clean up my Desktop (which is also my downloads
folder) for instance to put all pdfs in one folder or to detect the worst
disk space eaters.

Btw. Gworkspace should also have a list view.

Post by Enrico Sersale
A window containing something like the actual Contents Inspector.

Besides the usual content viewers (files contents and pasteboard data),

Post by Enrico Sersale
Inspector should also accept bundles
sent as NSData by applications, that is, an app will be able to add a

viewer for a type of data.

Post by Enrico Sersale
The Finder; but with many new features.
The GWorkspace and the GWNet viewers in a single application + the fiend

and the recycler (on the fiend?)

Post by Enrico Sersale
The app that performs the file operations ans shows their progress.
A daemon that notify the registered applications when the contents of a

directory have changed. Actually, this feature is implemented in GWLib, in

Post by Enrico Sersale
the FSWatcher class.
(fswatcher is already on CVS and works much better than the old solution)

greetings, Lars

Jim Fowler

2004-02-04 00:04:42 UTC

Hi everybody.

I noticed that NSNumberFormatter is still unimplemented (and this was
noted on this mailing list last year). If this hasn't been
implemented already by someone, can I submit my patch somewhere?

tilde,
jim

Sheldon Gill

2004-02-04 05:34:58 UTC

Post by Enrico Sersale
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.

Post by Enrico Sersale
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.

Post by Enrico Sersale
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 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

Aredridel

2004-02-04 07:49:59 UTC

Post by Enrico Sersale
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.

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!)

Post by Sheldon Gill
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.

Post by Enrico Sersale
The app that performs the file operations ans shows their progress.

Yeah.. one more daemon seems a bother.

Post by Sheldon Gill
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.

Post by Sheldon Gill
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!

Post by Sheldon Gill
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.

Post by Sheldon Gill
Regards,
Sheldon
_______________________________________________
Discuss-gnustep mailing list
http://mail.gnu.org/mailman/listinfo/discuss-gnustep

Enrico Sersale

2004-02-04 12:08:37 UTC

Post by Enrico Sersale
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.

I've no intention of make it invisible. I wrote that period without thinking...
(for Lars: ok, I'll write the list view :-) )

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.

Post by Enrico Sersale
The app that performs the file operations ans shows their progress.

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, etc.

Post by Sheldon Gill
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 notifications.

Post by Sheldon Gill
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 surrogate.

Post by Sheldon Gill
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.

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...

Sheldon Gill

2004-02-05 00:31:45 UTC

Post by Enrico Sersale
I've no intention of make it invisible. I wrote that period without
thinking... (for Lars: ok, I'll write the list view :-) )

That's easy, then.

Post by Sheldon Gill
I'd suggest it's better to separate the "Desktop" from shelf/fiend/dock

Ok. Then I'll write a protocol to be used for writing bundles that the app

We'll see the code and (hopefully) make useful comments/contributions...

Post by Sheldon Gill
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
notifications.

I realise this. At the moment FSWatcher watchFile does it's work by polling
the whole list. There are more efficient mechanisms on some platforms.

We can add more code and features to FSWatcher to improve things, or use fam
if it's available and get features for free.

Regards,
Sheldon

(My 10 cents. My 2 cents is free...)

Dennis Leeuw

2004-02-05 10:23:41 UTC

Post by Enrico Sersale
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...

I entered the GWNet directory and simply typed:
make GNUSTEP_INSTALLATION_DIR=$GNUSTEP_SYSTEM_ROOT install

And ended up with:
Handlers/SMBHandler.m:25:27: warning: SMBKit/SMBKit.h: No such file or
directory

Then I searched the GWorkspace-0.6.3 directory... no SMBKit found.

Ideas, suggestions?

Dennis

Enrico Sersale

2004-02-05 10:46:47 UTC

Post by Dennis Leeuw

Post by Enrico Sersale
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...

make GNUSTEP_INSTALLATION_DIR=$GNUSTEP_SYSTEM_ROOT install
Handlers/SMBHandler.m:25:27: warning: SMBKit/SMBKit.h: No such file or
directory
Then I searched the GWorkspace-0.6.3 directory... no SMBKit found.
Ideas, suggestions?

You need SMBKit, it is in dev-libs.

Larry Cow

2004-02-04 12:35:18 UTC

Post by Sheldon Gill
This is basically fam integration. Do we need a separate daemon to wrap it?

The problem is that fam is Linux-only, IIRC. At least, it is
Unix-only. If we really want GNUstep to be platform-independent, we
should at least provide some portable framework to deal with file
alteration. And it would be this framework's responsibility to dialog
with whatever exists on the platform to monitor files (famd on linux,
win32 APIs on windows, some homemade daemon elsewhere).

My .2 eurocents.

--
Larry Cow

Enrico Sersale

2004-02-04 14:53:52 UTC

Post by Larry Cow

Post by Sheldon Gill
This is basically fam integration. Do we need a separate daemon to wrap it?

fswatcher has nothing to do with fam. And there is no linux-specific code in GWorkspace.
GWorkspace and fswatcher run on OS X, too. GWorkspace could be considered "ported" to OS X since about a year if Apple would had not destroyed the NSWorkspace class. (leaving the old documentation, moreover!)

Post by Larry Cow
The problem is that fam is Linux-only, IIRC. At least, it is
Unix-only. If we really want GNUstep to be platform-independent, we
should at least provide some portable framework to deal with file
alteration. And it would be this framework's responsibility to dialog
with whatever exists on the platform to monitor files (famd on linux,
win32 APIs on windows, some homemade daemon elsewhere).
My .2 eurocents.

Sheldon Gill

2004-02-05 00:16:16 UTC

Post by Larry Cow

Post by Sheldon Gill
This is basically fam integration. Do we need a separate daemon to wrap it?

fswatcher has nothing to do with fam. And there is no linux-specific code
[snip]

Post by Larry Cow
The problem is that fam is Linux-only, IIRC. At least, it is
Unix-only. If we really want GNUstep to be platform-independent, we

[snip]

Just for the record, fam actually came from IRIX and it not linux specific. I
referred to it specifically because it's IMHO the best solution around for
POSIX platforms:

* It's quite portable and available on a number of platforms already
* It supports the Linux DNOTIFY mechanism (more efficient than polling)
* It supports other mechanisms where available
* It's being used by those 'other' free desktops
* It's actively developed and maintained.

One feature which should shortly be working well is inter-fam networking. The
daemon on your machine can ask to be notified for changes on another machine.

In short, using fam on POSIX systems gives us the best features for the least
work. It seems to me that, at the moment, fswatcher is just like fam with

That said, by 'basically' I meant a concrete instance of a concept and not
that GWorkspace should use fam exclusively. Win32 uses entirely different
concepts so requires quite a different approach...

My point was that 'fswatcher' is only a part of what is required. Consider:

* icon changes
* preferred application for file type mapping changes
* mount/unmount
* appearance changes (colours, widgets, font size etc)
* service addition/removal

I'm advocating we architect a solution which can encompass all these things.

Regards,
Sheldon

Adam Fedor

2004-02-04 13:34:29 UTC

-----Original Message-----
From: Jim Fowler
I noticed that NSNumberFormatter is still unimplemented (and this was
noted on this mailing list last year). If this hasn't been
implemented already by someone, can I submit my patch somewhere?

Sure! send it to bug-***@gnu.org

Alex Perez

2004-02-04 21:11:05 UTC

-----Original Message-----
From: Jim Fowler

Jim,

Many thanks for the patch, it's nice to see folks submitting!