Bug 71927

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc2)
Gecko/20020512 Netscape/7.0b1

Description of problem:
Hi,

I'm not sure who should I send this e-mail to, someone that have some strengh in
the LSB definition I suppose. So I tell you and you decide who should you send
it to.

Please, send me a copy everytime you forward this message to
eduardp, so I can keep track of the message.

This is a proposal to take advange of a huge idea that is being used in MAC OS
X, the application folders.

In Mac OS X Acqua environment applications are not program files, but folders.
Every application folder contains an internal contents folder, and this one have
a well defined interface. There is a file, for example, that tells you what icon
is using the application on the acqua interfase, what's the correct executable
file and were to find the translated resources for the program.

The goodness of this structure is that the browser knows about it, so when it
finds an application folder it shows it like an application, with the Icon,
tooltip, ect that it found inside the folder.

The huge of this orientation is that you can make all graphical programs
accessibe to the user, this way, with a very easy install feature.

The biggest problem in Linux environments at the moment is that you need brain
memory. 

It is normal in Linux that you need an specific software and you download it.
Then you install it and use it. Excellent. But next day you wanna use the same
exact program and you cannot. Why? Because you don't remember its name, and
without its name it is absolutely impossible to bring it back!!! (I asume nobody
makes links on the desktop because we all are always in a hurry).

Ok. Windows' solution is to encapsulate the program with its icon and tooltip
data, so explorer can extract that information and show you a graphical look of
the file.

That is not very convenient althought, as it creates huge restrictions to the
way programs can be created to work properly on an environment.

But Mac's solution is excellent. An Applications directori is created in the
root of the system that contains all the application files. Adding a new
application to your interface is as easy as browsing to the applications
directory and drag and drop the program from there.

The huge of this approach in front of an standard KDE or Gnome link is that as
the application is in reallity a folder, it can contain as many configuration
files as you want. And here it comes my idea:

Wouldn't it be excellent for everybody that Open Source comunity used the same
structure Mac is using and made an standard from it? The folder lets you put
different configuration files for every environment there, so every program can
have its correct configuration for any environment without entering in conflict
with the others!!!

For example, a gnome 2.0 application configuration file could have the icon,the
program location, the applet related with the program that start when the
program starts, the selecton of icons that represent events...all the
information needed to run that application in a gnome environment.
And at the same time, on the same directory structure, you'll find another file
with the characteristiques of the application in kde or enlightment. The program
you run is probably the same, but the applet related is probably different in
our example. Or we possibly created both an specmfic compilation for kde and
another for gnome, and we have diferent programs to be called depending on the
environment (that applies to different versions of the environment, kde 2 or 3
and gnome 1.4 or 2). 

Any of this information can be easily added by a software installation, with
independence of were the real program folder is. So we avoid to navigate inside
thousands of bin directories or create our own links. We just click the
applications button in our browser, and the browser, that actually happens to
know what environment it is working for, will present the information in the
smoothest way possible.


I feel it should be studied very fast, because it could break the desktop barrier.

Regards,

Eduard Pertmqez i Juncosa
eduardp



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Think about it
2.It could be great
3.You can have even particular options for Nautilus, Konqueror or Sawfish
	

Actual Results:  It is not hard to implement and can have magnificient results.

Expected Results:  Standaritzation

Additional info:

You'll see