GNOME.org
 

Re: spatial stuff detail

Am 24.09.2003 01:36:24 schrieb(en) Mike Hearn:

On Tue, 23 Sep 2003 23:08:00 +0200, Sir Guido Schimmels scribed thus:
> That must be why Gnome users for so long have whined about the state 
of
> menu-editing, because they have no interest at all to customize the
> menu. But users outside the corporate desktop obviously are
irrelevant
> now. Nice sentiment.

You can't simply use appfolders for the menu without running into a
whole
load of easy to forget but important problems, like
internationalization.
Desktop files and vFolders have some fairly big advantages, like:

* They automatically appear in the users native language


Like "Erleuchtung" (Epiphany)?
In ROX-Filer resting the pointer over an appdir shows a localised tooltip, explaining what you can do with the particular application. That's better than giving applications arbitrary generic names in the menu to help a user over the first hour with the system. 


* They allow for icon theming
Show me where I can download a theme with icons for every single application. In 5 years we might be talking of >10000 icons for such theme. I'm not holding my breath. I'd be glad if there was even a single quality icon for many of the less popular apps, for a start. Of course a 4-line bash script good do the trick for appdirs as well, if not per user, admittetly. 


* They integrate well with the package management technology of today
Which is well designed to keep the OS itself up to date. But as it requires a central authority it doesn't scale. Appdirs don't need to fit into a package management system, because they are supposed to be self-contained. Of course this can only work with a defined set of standard libraries. A base system of less than 300M can easily satisfy the dependencies of most applications. 


* They integrate well with multi user/root scenarios, so allowing
admins to
nicely control the menus in network scenarios.


That's not really the kind of environment I put much attention into.
You would have to get a bit more specific before I can comment on this.


Now of course you can embed most of this info "within" the appfolder,
but
then you just reinvented the .desktop file and made it harder to do
Appdirs are much older than .desktop files (nitpicking about your choice of the world "reinvented". 


things
like the superfast auto-complete run dialog GNOME now has.
Haven't used that. But in ROX auto-complete works identical for applications and shell tools. Can't imagine how Gnome can improve on that. 


> No you have __one__: The file-manager. You obviously never used the
> Finder or ROX-Filer. The start menu is redundant when you do it like 
> that. Plain in simple.

I've used both the Finder and ROX-Filer, and if you think running
these
programs suddenly automagically makes the start menu redundant then
you
have some more thinking to do. Last time I checked, ROX did not suck
up
all the entries from the start menu and overlay them onto your
Applications directory.
Mixing the two paradigmas will suck how ever you put it. Yeah scripts have been written to create application wrappers out of .desktop files. But that's only because no fully appdir based distro exists yet. 



Of course you can produce wrappers for every single app, but then
you've
just recreated a menu system but using lots of files and directories.

> And you don't need much categorisation either.
/Applications/Utilities
> /Applications/Internet
> Applications/Games
> and the rest goes flat into /Applications. What's the point of
digging
> through submenus all the time?

$ ls /usr/share/applications /usr/local/share/applications | wc -l
    135

Now I rarely use all of them, but I think I've run about 80% of the
items
in my menu at least once. They are there when I need them. Having them 
all
in a few folders like MacOS does it would be crazy. They are totally
different worlds, you can't treat them the same.
Add /Developer/Applications to the mix and substract everything redhat-foobar (some 30 items), which goes extra too and then count again. You won't have more then 30-40 items in every folder. 60 apps in each folder are still usable. More usable than a menu category with 30 items for sure. And nothing can stop you from creating more subfolders. How ever you try to twist it. You can't beat the file- manager in its domain - which is efficiently navigate hierarchical filesystems of arbitrary size - with a simple static fake representation of the disk-content.
The windows start-menu is not exactly known for scaling well. The categories which the Gnome and KDE menus use help to a certain degree, I presume. 



Apples usability engineers aren't the world respected experts they
once
were, if you noticed. They seem to play second fiddle to eye candy
these
days.
But what we are talking about has stand the test of time. We didn't touch any recent developments with regards to MacOS. 

It's also ridiculous to think that what "works" for MacOS can work
for GNOME, and entirely different project, developed in a different
way,
that works under an entirely different set of constraints.


I've yet to hear a convincing argument why it can't work for Linux.
I understand the different culture. But a lot of it has to change,
independently from our little project, or I really don't want to see Linux succeed on a wider scale, frankly. 
For the industry Linux is SuSE and RedHat and the rest doesn't exist.
Everyone who wants this mentality to spread into the consumer space, just keep on fighting platform consolidation. In the end everyone will have to clone RedHat or have no users beyond today's geeks. 



> When I joined the thread, I wanted to inform the Gnome community we
are
> working on such a system and that it can be done, because I have
already
> such an environment right here on my desktop (posting this from a
> relocatable Balsa appdir). That's all.

Well done. Once you've figured out:

* a way to make this work on the systems being used today
 that doesn't require users to replace large chunks of their distro
Simple. LSB may be sufficient for the server. For the desktop it is a joke. The Linux community has to agree on a reasonable set of libraries and tools which have to be present on every (desktop) system. Thus creating a stable platform for application developers to build upon. Unless this happens you can wait for a native Photoshop until you get blue in the face.
All we can do is create a great Linux OS and attract enough users so people take notice. Your autopackage project has some of the same goals as ROX. You try to deal with the mess. Which is honourable. We try to clean up. Probably you will have more success. In the short term in any case. I'm doing what I'm doing because I think it is the right thing. Realistically what I'm working on won't ever become any more popular than 290 of the 300 Linuxes out there. That's life. 


* viable conversion and backwards compatability plans for the
community


RedHat and SuSE can't offer this remotely. How should we then?
* an answer to dependencies that doesn't involve "local exploits don't
Yeah. I've been a bit silly about that. A lousy defense against what I feel is a large stinking hering. I have enough experience to say that most users will end up having to download a lot less to keep their libraries and applications up to date and secure. It can happen that it bites you and a Debian user get's away with 100k download at some point, while my users face a 10M download. Shit happens. But this will be the exception. 


matter" nor "i am the authority on which libraries are important
enough to
share and which aren't"
It would never occur to me to claim any authority outside our project. If we wanted to lead at all, then by example. If we attract enough users, the community will take notice. No further plans. 




* how to get the benefits of systems like scrollkeeper
I haven't yet worked on a scrollkeeper replacement. The help files can be accessed from within the application like normal or directly from the appdir from the file-manager. If we decide this is not good enough, 
MacOS X shows how to improve on that.
Generally these things are the job of the file-manager. Just like the GConf system creates a registry vom flat files in a number of default locations, so can the file-manager with appdirs. 


GConf etc with
appdir style systems

then maybe I shall be more interested.


It can work just like normal. Tell me where you would expect problems.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]