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
I think it's fair to say that this is too large a change, breaks too much stuff, and there are other approaches to the same problem. I don't think the change would be feasible. If nothing else the LSB and FHS sort of preclude it.
I would like to say that it is not a soo big change, and it is absolutely progressive. For example, on the first step the information contained into the directory could be a file named .gnome-application that contains an enter kind of: [Application Link] application.link That's all. Then, you copy the application.link files you already have in the gnome menu to these application folders and Nautilius and Sawfish includes a code similar to this: If file_I_am_showing_is_a_directory if exists_a_file_inside_called(.gnome-application) look_inside_for_the_link_file() show_the_link's_bitmap endif endif Similar code to change the doubleclick reaction, and that's all!!! I don't see any dificulty on this. With time, the .gnome-application file can get more specialized.