Visible files and Bundles

[Bastien Nocera <hadess hadess net>]

Hi,

Under this very cryptic subject, I'll try to explain the idea I have for
file hierarchy in the Gnome Desktop.

User-files:
- Nautilus should use a user-visible directory as the desktop folder.
~/Desktop is the best one, visible directly when opening any
application, including legacy apps. And it's also what KDE uses.
Nautilus should support KDE launchers and special directories in there.
I think that pretty much everybody will agree with this.

Data, plugins and themes:
- These should be visible to the user browsing under normal condition.
You can see how NeXTStep does it by checking the way Window Maker does
it. Under ~/GNOME for example, you would have a Library/ directory
containing sub-directories for each type of extension possible.

What comes to mind immediatly is the themes: instead of having themes
under ~/.themes for GTK+, ~/.sawfish/themes/ for sawfish etc. you'd have
~/GNOME/Library/Themes/GTK+ ~/GNOME/Library/Themes/Sawfish
Same goes for all the data, like custom pixmaps, menu items,
automatically saved Playlists, font files, plugins, etc.

This is something that is achievable by GNOME 2.0, quite easily.

Onto the Bundles now, I'll point you to this description of the
App-Wrapper in NeXTStep:
http://www.chat.net/~jeske/unsolicitedDave/next_wrapper_description.html

I've done work last year on getting a couple of apps to support this and
I can say that it _is_ possible.

The main reason for this scheme is that Unix-like operating systems are
known not to be application-focused. How many of you start applications
by going with your file-manager in a bin/ directory and double-clicking
on the icon ? Nobody does that. With the current organisation it's only
possible to have a document-centric interface.

Using bundles, that include App-Wrappers for applications, Frameworks
for libraries and development files (static libraries and headers) it
will be possible to have a more flexible environment.

I won't discuss the technical/implementation part of the project, but
shell scripts, LD_LIBRARY_PATH and some modifications to the existing
applications, would make this possible.

Here is an example:
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/
openapp.in file

This is not an idea for GNOME 2.0, rather for 3.0 (or whatever the next
milestone after 2.0 will be called)

I'm ready to discuss whichever problem you think might occur. As I told
you I've successfully ported a couple of applications to use this scheme
last year.

Cheers

-- 
/Bastien Nocera
http://hadess.net