The Gnome 2.2-RC2 (2.1.91) is released. This is the last test version before the final version is to get released next week. Also, the Gnome Summary of this week is published for your reading pleasure.
GNOME 2.2 Desktop Release Candidate 2 Available
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
ok guys, I need to go and sleep. It is 1:30 AM here and tomorrow morning I need to go for my French lesson. It was a good discussion overall.
‘Night.
Oh, one last thing, does anybody else think that actually the stock gnome artwork is much prettier than these SVG themes? They seem kind of messy and lacking the subtle details that I love from the bitmap artwork.
I guess it’s just that SVG themes are still in their infancy.
Understood. What I don’t understand is how it is easily modifiable from the command line. I personally don’t like editting xml. I guess that’s my only concern. Need to admin these things.
“You don’t understand. /usr/bin HAS to stay there, otherwise you lose POSIX compatibility!”
Which goes back to what was said about a separate dir for app binaries.
Refresh my memory; what exactly is /opt for? Isn’t it for programs? So why not have something like /opt/bin? Just a thought. Something to keep apps seperate from basic OS utilities. God forbid we put /opt to much use
.
Also, UNIX being made for the computers it originally was made for, I can understand having such a focus on multiple users. But how many of you honestly share your computer with several other people? Personally, there are three accounts on my computer- root, nko (my initials), and user (which I use to dink around in). Notice the lack of other people using my *Personal Computer*. Of course, I like the idea of multiple users, and I like that it’s supported much better and in a much more meaningful way than in Windows, but I think some emphasis could stand to be taken off of it since we’re talking about a desktop Linux. Not take it away, not dumb it down, just not focus on it so much. For example, if Phoenix is open and I click its icon again in GNOME, it tries to ask me which user wants to open it. K, bad example, but I hope I got my point across. It’s a light difference I would like to see
.
> On the other hand, editing stuff using the file manager is exactly what MacOS does, and I don’t hear any bitching about that?
Yes, and I find it wrong. Especially the fact that ALL the apps are in the /Applications directory which is a big stupidity. I have often said that OSX has problems. This IS one of them.
When I was talking about DnD, I was mostly reffering to the Dock.
>You don’t need to style or transform .desktop files
It is much better to be XML, because you can much easier write an app that can parse these files and create a UI for you to manipulaet these values.
>No end users should see the system directories at all.
But… I agree on that!
>Sorry Eugenia, but dragging files from there into the menu is a dumb idea
What are you talking about? Have you READ what I wrote???
I never said that is acceptable to dnd from /usr/bin/.
> Yes, splitting things out into separate files is fine. It lets you smoothly integrate applications from multiple locations into the same menu, with varying levels of administrator control.
Right. And can you please tell me where this is useful on a USER system? I think that feature is completely useless. Why would I want my icon for my binary to live in a server in Alaska and the binary to live on my box?
> It lets you invoke a program from the command line, or the menu, or the new “smart” run dialog box. It lets you retheme application icons if you like, and generally makes the whole process more transparent. AppFolders have lots of disadvantages which I’ve gone into time and time again, and so far nobody has really convinced me otherwise.
The system I would like to use does NOT hold you back from ANY of these issues. Have you ever used BeOS? I think not.
Goodnight.
Oi, I think we’re all in agreement here. Requiring the user to open a folder of any kind just to launch a program is pretty innane. Might as well be running every program from an xterm.
G’night, Eugenia!
“When I was talking about DnD, I was mostly reffering to the Dock.”
Oh, ok. I think you can drag menu entries from the menu onto the panel, maybe there is a bug on that, not sure.
“It is much better to be XML, because you can much easier write an app that can parse these files and create a UI for you to manipulaet these values.”
Not really. Writing parsers is a programmers bread and butter, they aren’t difficult. I don’t see how using XML would make it easier to write a GUI for it, afaik there is no generic XML->GTK/Qt binding framework, and anyway specific guis are better than generic ones in this case.
“What are you talking about? Have you READ what I wrote???
I never said that is acceptable to dnd from /usr/bin/. ”
Meh? I’m confused! I thought you said:
“This is one of the reasons why drag-n-drop wouldn’t work directly from /usr/bin/ to your Gnome menu and automatically get its icon and everything. These are the times I say that the whole Linux experience needs to be re-thought”
.. and … “And I am not talking about drag it to the app folder. I am talking about dragging it to the menu directly.”
You mean, dragging a package directly into the menu? If so then we’ve considered this, it’s certainly possible to do, regardless of the underyling structure.
Anyway, filing systems will be databases soon anyway
So, what, are we going to let the users browse the data structures from Nautilus? No… better to let them forget about how the underlying structure is organized.
“Right. And can you please tell me where this is useful on a USER system? I think that feature is completely useless.”
The user need never know it even exists! Once we have the various bugs and packaging problems ironed out, it will Just Work ™ and that feature will be there for when admins need it, and the rest of the time users won’t need to care.
“Why would I want my icon for my binary to live in a server in Alaska and the binary to live on my box? ”
It’s more a case of, what if you want different icons for the binary, like high-contrast/low-contrast icons? Or you have a nice big icon theme. Or you want to store icons in multiple formats etc.
“The system I would like to use does NOT hold you back from ANY of these issues. Have you ever used BeOS? I think not. ”
(sigh) No, I have not. I did try, but the download constantly corrupted. I’ve yet to find an explanation of exactly how BeOS managed menus and packages and stuff. I’d guess using an AppFolders style system. I’ll have a look for such an explanation, but if you have any urls or screenies that’d be good…
“Goodnight.”
Sleep well
Come to think of it, if all the settings that the user should be able to manipulate were in XML files, we could easily have two great ways to edit preferences and settings: by hand in a text editor, or in some universal program that pretty much just loads an XML file as a table… sort of thing. To change an attribute, just find it and change its value. XML is really useful for stuff like that, and a program that could load any of this new GNU/Linux system’s XML settings files would be relatively easy to make. Just impliment a parser and have it spit out options and values in a nice, clean interface. Another of my “just a thought” posts.
Or, I guess that idea basically just got shared before I posted it! ๐
> I thought you said:
“This is one of the reasons why drag-n-drop wouldn’t work directly from /usr/bin/ to your Gnome menu and automtically get its icon and everything.
That was in the beginning of our discussion here, and the highlight in the sentence is about the dnd and the icons, not the /usr/bin/ in particular. I could have used /bin/ there as the example. The /usr/bin/ in that sentence was just the context so people would understand what I was saying about Dnd and icons. Later, I CLEARLY explained about how gui apps should not be stored there.
>You mean, dragging a package directly into the menu?
Possible yes. But it won’t get its icon automatically. Are you talking about packages though, or apps?
> It’s more a case of, what if you want different icons for the binary, like high-contrast/low-contrast icons? Or you have a nice big icon theme. Or you want to store icons in multiple formats etc.
No, none of these reasons is good enough to make me wanna have a .desktop file, lying on my ~home and getting itself broken when the admin deletes the binary.
Different icons can be changed by editing the resources or the package. BeOS did it the best way. It is really easy to do so.
> [BeOS] I’d guess using an AppFolders style system.
Nope. Bad guess. Re-download Max Edition from BeBits please.
And now _really_ I have to go to sleep.
3) No end users should see the system directories at all. Sorry Eugenia, but dragging files from there into the menu is a dumb idea, the entries should appear in the menu when you install and disappear when you uninstall. If you want to remove them, just delete the entries. Why make the user perform extra actions?
Is there *any* need for things to be more complicated than this? I should be able to drag an icon from a web-browser or from a cdrom, or wherever, to my menu/dock/etc and have it install. When I delete that icon from the menu/dock/etc, the program uninstalls. Library dependencies are fine, if done correctly (e.g. debian).
Yes, Eugenia is right, using applications:/// to edit menus is a bit sucky,
You are not supposed to write “applications:///” on nautilus to edit your menu. You are supposed to go to “Start Here” on your desktop, and then to “applications”. It’s not as fast as doing it in the menu directly, but works quite well.
3) No end users should see the system directories at all. Sorry Eugenia, but dragging files from there into the menu is a dumb idea, the entries should appear in the menu when you install and disappear when you uninstall. If you want to remove them, just delete the entries. Why make the user perform extra actions?
I agree. It’s the way it should be. Most of the problem lies on the installation of new apps.
Apps can be easily installed with installer like the one found on loki games. They just make you click a couple of times, and then they create a menu entry for KDE and Gnome.
If they need to use they own libraries, the just create a /opt/fooapp/lib that will be used for the program library. Then a symlink from /opt/fooapp/bin is created to /usr/bin.
Users dont even need to know that a /usr/bin directory exists. They just need to worry about the installation program.
“Apps can be easily installed with installer like the one found on loki games….”
Exactly! That’s how easy it should be, and it should work like that, creating its own set of libs that it ships with.
I may have exaggerated a bit in my examples, but I really did not misunderstand.
What I meant is this: if you have a nice wonderful Linux Desktop OS, as you envisioned, you won’t be compiling things for it. People get, and need to get, ready, easily installable packages (binaries).
And those binaries won’t run or install on Linux… on real Linux, you’d grap the sources and compile, fine, no problem.
But to get those ready packages for the desktopux, you need someone to make them. Are the developers of all the famous and most productive free/open source software ready to jump ships from their good ole tarballs and just start supporting the new way.
Well, if they aren’t, you are going to need a third party to keep the whole thing going. The same role as the distros are doing these days. And it’ll come to be a brand new mess.
The fact is that Linux is too open source, open everything. It is very fragmented, and I have a hard time envisioning anything central, and heavily supported + used, controlling all this, and doing it in free+open source tradition (which would, more or less, be the whole point of having Linux on desktop; you didn’t answer why otherwise something like that should be needed?).
But anyway, what do I care, I wouldn’t be using anything like that, as I don’t use Linux even now.
I am sure that you know, Eugenia, who and in what situation designed and created UNIX.
From that knowledge, it is true that UNIX was never designed for desktop, but “it is a server architecture” is a bit of a stretch, if we are talking about the design of UNIX.
UNIX was mostly an ad-hoc creation, 30 years ago, to serve as a multi*user* operating system . And UNIX was the thing people did run on their “desktops” of the time. Of course “desktop” then was just the commandline at a terminal, but really, the people who used it were Joe or Mary Users, writing documents and so on.
And what is it in UNIX design that makes it a server, not a desktop capable?
And besides, I have the feeling that all one would need to do is: make the GUI work. Make it really work. This does not require changes in the kernel, or the standard file hierarchy. Changes can, and perhaps should be, introduced to the file organization, it is not such a big deal. But, you can hide it all with the GUI.
What I mean is: you gave an example about the Mac OS X packaging system, and how the things are integrated in the package (you spoke about file deletion, and so on). What I want to know: if you go to terminal, and start mucking around with files that belong to some application package, does everything work as nicely as if you were in Finder.
(My guess: no. Therefore: the complexities are hidden in the GUI, the OS doesn’t really care.)
Eugenia, might I suggest you write up your thoughts as an entirely separate article. This would give a clear and concise method to distribute them to all of the *NIX UI developers (hey, *BSD and kin use the same GUI systems and similar file hierachies and structures). Also, I would suggest you only write this document in terms of features you wish to have: “DnD binaries to menus, automatic selection of icons, ability to *transparently* run applications from their own folders, etc.” My basic suggestion is to focus on describing and evangelizing the features you desire and not the underlying means of implimentation. For the end user you are describing, such implimentation details are grossly unimportant as long as the UI does what he or she expects consistently. Personally, I don’t think so many radical changes are necessary, but that’s implimentation, let the coders and hackers figure it out, just let us do the things we want in peace.
As an implimentation detail, I agree that the BeOS way sounds really useful, i.e. looking first for libraries in the vicinity of the binary, then using system libraries. Automated, I know of at least one application this for which this will not work (Intel C++ and Fortran compilers) because their directories are not <app>/bin, <app>/lib, but they are exceptions. As stated several times, this can be “faked” using runme.sh style scripts to setup binary and library paths and then run the application. At the moment, i.e. lacking mor e transparent implimentations, this is the easiest way to simulate AppFolders. I think this can be made even easier as a switch in rpm or deb (or other package) based systems. A command line switch (can be set on by default in a distro) will trigger the rpm to change the install directory from “/” to “/opt/<app>” or somesuch. Next, for each binary present in “/opt/<app>/bin” the rpm command can then *transparently* create the runme.sh scripts. I would also suggest (implimentation detail) that each script is given the full version numbering of its package, and that a symlink is created by rpm to (1) first such script installed, leaving other user callable, or (2) the latest in the case of package upgrades, or (3) to the version specified by the package author. Users can alter this decision without any additions to rpm by removing the symlink and using their own. Sound reasonable?
Oh, let’s try a bit
Eugenia: These are the times I say that the whole Linux experience
needs to be re-thought and even break multiple compatibilities with
older crap, just to retool things to work as they suppose to work on an
OS that wants to get to the desktop (as Linus said yesterday) in the
year 2003.
GNOME (KDE also) runs on multiple OSes. If you break things in Linux,
you’ll probably have to break things in Solaris, Free/Net/OpenBSD
(although I wonder if anyone uses OpenBSD as a GNOME/KDE desktop ๐ etc
etc etc.
bsdrocks: Nope, no change in 2.2.. I think, it’s going to be in 2.3
or so. I don’t see anything wrong with file dialogs, thought. ๐
GNOME/GTK file dialogs simply sucks real big time. Ximian ones are
better, but not that much. Every GTK/GNOME developer knows that, but
unfortunately no clear winner has arrived.
dealing_death: Noone needs a PATH for GUI apps.
That’s why people invented applications menus, start buttons and so on,
right? ๐
Mike Hearn: I guess it’s just that SVG themes are still in their infancy.
SVG is something really new, it’ll be a
Nathan O.: Might as well be running every program from an xterm.
…because sometimes fire an xterm and type a name is sooo faster than
opening a menu, opening another menu etc
“The /usr/bin/ in that sentence was just the context so people would understand what I was saying about Dnd and icons.”
OK, so you want icons to be included as part of the binary. Fine, but that removes flexibility for….. for what? I still don’t understand how having the icons separate from the binary is a hack.
“Possible yes. But it won’t get its icon automatically. Are you talking about packages though, or apps? ”
To me they are one and the same. I meant if you find a package file, to install it you just drag it to the Apps menu and drop. It’d categorise itself automatically. If you wanted to override that category, you could drag it to some other folder (or the applications:// folder). One idea I had was to create a new XML namespace for plugging into XDND, and then a Gecko plugin for it, so app developers could “embed” the package into their web page. The package would obviously have the icon of the application. Users just visit the webpage and drag the package out of the page onto their menu, or the panel, or whatever they use to launch apps. The package is then downloaded and installed transparently via the resolver network.
I guess if you wanted you could drag it into a file browser and have it just act as a normal download too, but I think this would be a very easy way to manage software – google for it, drag on, drag off.
Once all the links to the app in the menu/panel for all users have gone, the package can be uninstalled automatically by a cron job or something, so users don’t have to worry about explicitly uninstalling packages, they just remove the links to them from their desktop.
“No, none of these reasons is good enough to make me wanna have a .desktop file, lying on my ~home and getting itself broken when the admin deletes the binary. ”
Admins shouldn’t and don’t just delete binaries. For starters, doing it manually leaves the shared data and libs lying around. No admin I know uninstalls software manually, they either use the package manager or “make uninstall”. Bear in mind the .desktop files are completely hidden from the user, they need never know about them.
” Different icons can be changed by editing the resources or the package. BeOS did it the best way. It is really easy to do so. ”
Ack! Sounds hard if you want to do them in bulk. You’d have to track down every binary and do edits inside them. That’s hard, and asking for file corruption.
“Nope. Bad guess. Re-download Max Edition from BeBits please.
”
Aw suck. Maybe if it runs in VMWare, I’ve completely run out of space on my own machine.
@Shifted: Yes, I thought of the same thing about a month ago. It’s most certainly possible, but it needs some careful thought and good integration. Obviously you’d need to patch the rendering engines too. In fact we can make it more generic, so it’s not just packages that can be dragged off of web pages, but any files/objects. You can already do this with images afaik.
@NathanO: “Exactly! That’s how easy it should be, and it should work like that, creating its own set of libs that it ships with.”
Not that easy I’m afraid, you can’t ship the entirety of gnome2 around with every gnome app
@OoSync: “A command line switch (can be set on by default in a distro) will trigger the rpm to change the install directory from “/” to “/opt/<app>” or somesuch. Next, for each binary present in “/opt/<app>/bin” the rpm command can then *transparently* create the runme.sh scripts.”
Unfortunately many Linux packages aren’t relocateable, they must be installed to the same location they were built for. We’re trying to solve that by convincing people to link against libprefixdb, which allows apps to locate their datafiles from the package database at runtime, but this is a bit hacky. It’s fine for now, but for the long term I think a better solution is to move to a system more like Windows, where apps have their shared data/libs in the same directory. The mods needed would be small, but the old way has advantages too that you’d lose. So I’m not really sure if that’ll happen.
“Users can alter this decision without any additions to rpm by removing the symlink and using their own. Sound reasonable?”
Yes, that’s basically what autopackage does
If there is already a binary with that name in the path (for home user installs, not sure if we currently do it for global installs as well) then we setup symlinks that will take precedance. I don’t think we do this for global installs actually, fiddling the path gets complex. For non-root installs though we do this.
I personally install all my self-compiled programs in
/opt/<program-name-and-version> and use the excellent ‘stow’ command (btw does anyone know of any distro that installs it by default??) to make symbolic links to /usr/local. This way I only need to add /usr/local/bin to my PATH and /usr/local/lib to ld.so.conf.
It also enables me to have multiple versions of the same program installed (for trying a new version for instance); just unstow the old and stow the new. If the new version buggs or is crappy, unstow, rm -r <new-version>, stow <old-version>.
Just make an app installer that when you click on a package it installs it the way you said. You can write a script and hide it you don’t need to rewrite anything but the top level interface for executing an install.
OSX hides it
Windows hides it
Linux can hide it
its called automation.
If you want to change it that much then it won’t be linux anymore because it really won’t be compatible. The new distro would have to compete. If you made it into KDE and gnome all distros could benefit
Hmm, seems to use a centralised package manager, something similar to RPM? Software Valet, then you choose where you want to install it, no fixed location etc. Icons are compiled into the binary like in Windows.
Just got Gnome 2.2 RC2 installed and what can I say… I absolutely love it. For all Gentoo people there are ebuilds in the forums (Final will be in Portage though).
Don’t know if it’s the new version or because I changed compiler flags since RC1 but damn, this thing is flying, especially Metacity, resizing opaque windows is close to BeOS performance… me likey.
Give this release a go if you’re a Gnome, and report any bugs you encounter so we can make sure Final is the best product possible.
until it looks like and acts like either osX or windowsXP. anyway – i think i stop reading osnews. its just too well … nevermind.
Just another comment on the Menu Editing from me:
KDE has a menu editor, not such a good idea. However, the AppFinder presents a list of all found apps, you can mark all that you want to add to the menu (by default only apps like Gimp are marked) and after OK everything is done.
There’s a perfectly good solution to all this crap about files and menus…
packaging.
I run Mandrake. Mandrake packages a close approximation of all the Linux applications under the sun, and when you install one that you’re likely to run from the GNOME or KDE menus…it gets a menu entry. Your end-luser doesn’t need to *know* where the binary is. They install the program and hey, there it is on the menu. No fuss, no mess.
To clarify…have you seen how the average luser uses Windows? Have you seen one actually *add* an entry to the start menu? Hell no. They let the installer do it for them. There’s no reason Linux shouldn’t work the same way.
Quote:
The most sensible way to do it is very close to the way MS does it.
You need a directory called ~/gnome_menu (or somesuch). In that are
subdirectories: Extras, System_Tools, System_Settings, Games, etc…
One for each label you want to show up in the menu.
Using nautilus, right click and drag apps from /usr/bin (or wherever)
and drop them into these folders choosing to create symlinks. Bang.
They should then show up in the menus.
And *that*, my friends, is the way it should work.
Response:
The great thing about computers is that there are multiple ways of doing things. However, whether you are accessing a program from a menu, or from a file browser, it should be just as intuitive either way, and you shouldn’t have to relearn anything to do one way or the other. Here is the solution:
As Eugenia hinted, the “way it should work” is that the *nix desktop idea needs to be re-evaluated. 1) store all user applications in one “applications” folder. 2) Make a symlink from the well-organized applications folder to the menu.
Now the user follows the same path (e.x. , Internet, Mozilla) no matter if the applications are accessed from a menu or from the file browser (e.x. nautilus). The user still knows that Mozilla is in the applications directory under internet.
Note that I’ve replaced applications with menu, as it is more intuitive (and quicker!) to have a two-level menu than a three-level one.
This is the most logical, intuitive way I can think of to do this. Of course, it’s probably the hardest to impliment because you might break compatibility, or at the very least you would have to abstract the unix filesystem (/usr, /bin, /etc…) from the user.
As Eugenia hinted, the “way it should work” is that the *nix desktop idea needs to be re-evaluated. 1) store all user applications in one “applications” folder. 2) Make a symlink from the well-organized applications folder to the menu.
[ddipaolo@quinn ~]# ls /usr/share/applications
archive-generator.desktop gnome-sound-recorder.desktop
drwright.desktop gnome-stones.desktop
eog.desktop gnome-system-log.desktop
file-roller.desktop gnome-system-monitor.desktop
–snip–
Like that? And menus are generated according to the contents of these .desktop files. So, what you are asking for has been done already.
In the summer, it happened that I thought about a new directory structure for Linux too… It is possible to implement it as a new *distro*, I think.
1) All system tools are in /usr/bin and/usr/sbin.
2) There are fixed versions of the default libraries. /usr/lib/glibc.so.2 always points to a certain version.
3) You have a /opt directory. /opt/<your-PC> for local programs, but you can also add /opt/tex-server and /opt/app-server and so on. IT IS VERY IMPORTANT that this folder is called the same on EVERY PC in the network! An app might be compiled to store its config in /opt/app-server/tex/fonts.list, hardcoded!
4) In each of these servers, there is /bin. Contains just symlinks to the programs. Only place user programs here.
5) Programs live in /opt/server/app/bin. App-depend libraries in /opt/server/app/lib and so on. If the app needs to install a certain library, it is allowed to install it. Say it needs glibc-2.2.2-22, it can install it in /opt/server/lib. In this manner, if two programs use the same non-standard library, it only needs to be installed once. Call this file indeed glibc.so.2.2.2-22, so different versions do not conflict.
6) A conjob might look for changes in /opt/*/bin and add all files to /opt/bin.
Compiled programs will in this way be hard-coded with a certain server. This might be solved by using an environment variabele, set when you start the program. Maybe it is possible to write a helper utility, say /usr/bin/start, that looks up on which server the program is, sets $SERVER to it, then runs the program.
If this works:
1) You can install apps very easily
2) Joe User can find apps easily, he just needs to look in /opt/bin for it, because this dir only has the user apps. System apps are in /usr/bin.
3) The system still supports running apps via network, just like a NFS-mounted /usr. Additionally, in this way it is possible to use apps from different servers at the same time.
It is not POSIX, but should work, as almost all programs have ./configure –prefix= To make it POSIX it is allways possible to use links…
/System/
/User/
What more is it to it?
Forget about opt,usr,etc,proc,var,local,lib,dev,tmp,sbin,boot,sbin and what have you. It’s all shit!
And that crap about following posix standards? Bah! Linux might just aswell follow the danish toilet standard.
> What more is it to it?
Well, the ability to mount applications remote. In this way the “desktop Linux” is also suitable for companies etc.
Ah, a war between the pro-2000-files-in-/usr/bin and the pro-every-app-it-its-own-folder people. Ho! Wait! Stop!
Eugenia, you said you don’t want to search for photoshop in a dir with 2000 files. I understand that, but ask yourself this: WHY would you want to search for the binary anyway? The best way to launch Photoshop is to use the menus. Browsing to C:Program FilesAdobePhotoshop is *not* userfriendly.
/usr/bin is a mess. That’s great. But why are you bothered by this? Desktop applications should be started using a menu, *not* by browsing to /usr/bin. Creating shortcuts on your desktop/panel involves dragging the menu item to the desktop/panel, *not* by browsing to /usr/bin.
Why should the user care about the app’s internals? Why should he know where it is installed? It works, and you launch it by using the menus, *that’s* what matters. Why do you want to install every app to it’s own directory if all you’re supposed to be interacting with is the menus/icons anyway?
And that crap about following posix standards? Bah! Linux might just aswell follow the danish toilet standard.
You do realise that there are significant problems with Apple doing it this way? What if you don’t speak English? /etc may not mean much to you, but /System/Library will mean just as little, and if you understand English but want it in your own language, it’ll just piss you off.
IANAUID (I am not a UI designer), but here goes nothing.
I think a lot of things could be done on a filesystem level if you used a filesystem that enables metadata for all files. An installer (be it GUI-based or something like emerge or apt-get) should put files the same places it puts them now, but add metadata to the executable, libraries and data files. I imagine something along the line of this:
/usr/X11R6/bin/pr0nview (executeable) has the following metadata:
Application == pr0nview
FriendlyName == pr0nview (Image viewer)
Version == 0.1.0
/usr/share/pr0nview/* (application data) has the following metadata:
Application == pr0nview
Version == 0.1.0
/etc/Desktop/menu/multimedia/pronview (symlink to /usr/X11R6/bin/pr0nview) should have the same metadata as the file it points to (automatically).
The idea would be that when you uninstall pr0nview, you search the filesystem for items that have the correct “Application” metadata and just delete those files. Another advantage as I see it is that it would be relatively easy to find applications. All you need is a tool that reads and searches through the metadata of files in /usr/bin and/or /usr/X11R6/bin.
Does XFS support a thing like this, or would we need to roll our own?
>Nathan 0. : I think someone would do well to take the Linux kernel, the GNU utilities, and X, do whatever they wanna do to them, and put it out as a whole new thing- not a new distro, but a new linux, mostly incompatible with today’s Linux, but not untirely difficult to port to.
Such a project exists, see http://www.blueeyedos.com . To be short, it’s Linux kernel + a reduced version of XFree86 + BeOs API; shorter, BeOS with a Linux kernel.
As far as I know, helps and contributions are welcome.
My opinion: GNU/Linux is missing a “benevolent dictator” like Guido van Rossum is for Python.
I suppose I was a little over the top by telling you to shut the hell up, I apologise for that.
No problem.
This is exactly what MS seem to be doing at the moment. Grabbing a clean sheet of paper and rethinking the whole OS. Not scrapping everything. Rethinking things and then using existing work to form something completely new. However I think this is more from the pressure of knowing that people aren’t going to keep on buying the same old again and again, even more so with the advances Linux has made.
I don’t think it hurts to take this approach, indeed Nintendo actually develop their games this way. First they build their game and then they scrap the whole thing. They then start again but using all the experience they gained the first time round.
I certainly think that starting with a clean sheet of paper is good because it allows people to think outside the box. Otherwise you are bound to thinking, ‘Oh no, scrap that, it’ll break compatibility with so and so’.
Is there a real interest here in developing a viable Desktop OS, based on GNU/Linux?
In a word, yes. In two words, hell yeah! In three, I’d say so. Okay, so that was 4 dumbed down to three with a conjunction. Yes, there’s an interest, at least from me!
The above link to the Blue Eyed OS looks like it might be neat, but all the links I click on load the same page. All I’ve learned of the project is that Guillaume Maillard has commited his changes to app_server… is there a little more in-depth page on this, or is my browser broken, or hmm?
Wait, the page is working now. Looks pretty cool! Aside from the seeming tendancy to aim for Linux compatibility, I think this is exactly what we’re discussing. I’d like to hear Eugenia’s take on Blue Eyed OS, and how the idea discussed here differs from that project.
Please have a better name than Blue Eyed OS… Seems to be going too much the BeOS route instead of linux, though?
BlueEyedOS is indeed a BeOS-related project. It was created in order to recreate the BeOS experience. It doesn’t start in with a clean sheet. However, it is the closest to what we are talking about here.
And a few days ago I was arguing with its main developer over ICQ regarding UI issues. Not exactly what I would call open minded person regarding UIs… ๐
He would argue that using the keyboard for different actions, is enough for a media player to be “usable” and “user friendly”. I did tell him that when the key “B” of the keyboard is used as b, B and for only one application as “go forward to the video timeline”, is not exactly my idea of “user friendly”. Of course, having keyboard shortcuts is imperative, but he was arguing that having ONLY keyboard shortcuts is enough to control a medial player, even if the app won’t give you any other UI controls! He could not understand that a media player is an application that it would be used by whoever, computer-illeterate or not, so it has to be as easy to use as possible. The developer is a friend of mine, but what we would try to achieve, it would never fly with Guillaume in the helm. Guillaume is a _great_ developer, but not very good in usability issues.
I wasn’t gonna say anything, but yeah, BlueEyedOS is a really lame name for an OS. In the system we’re talking about, though, I think excluding the words “GNU/Linux” from the title would be a good idea, something like how Xandros isn’t “Xandros GNU/Linux.” Windows wouldn’t be as “user friendly” if it was called NT/WindowXPSP1.
Yes. Look at microsoft. They have SIMPLE names like :
Windows
Office
Word
Money
Bookshelf
Can’t the ubergeeks use SIMPLE names that mean something? instead of these, just for cd burning apps:
KonCD
CDBakeOven
XCDroast
GToaster
Personally, I really like this discussion and would love to see it develop in to a project all its own. The idea of a keyboard only media player is a pretty broken idea from the get-go. I don’t think it’s been mentioned, but what we’re talking about here *could* easily go head to head with Windows in a few areas. You always hear about how Linux is making its way to the desktop. You never hear about a single part of the desktop experience that *IS* complete and usable by Joe User without the help of the neighborhood geek.
Since this newspost is going a ways down, can we move the discussion? I’ve started a little discussion in the Linux forum. It probably wont last long there, either, but wanna take it over there for the time being? I’d hate to see this discussion disappear with time. It’d be another one of those “well it’da been a good idea except no one bothered with it” things. Shame.
Hello,
@Eugenia: What is *.doc? Microsoft Word text or Atari 1st wordplus text? Speak clearly, please.
Referring to drag&drop from/to a launch menu, I object that a desktop OS need not to offer such a menu. E. g. on my Apple Performa with System 7, I get all useful apps as file links in a dir with subdirs always open on the desktop and like it.
@shawn: In the German usenet linux forums calling the users there “snobby” is even friendly. I have never met so arrogant people with such few knowledge. If they run out of arguments or facts they flame “go back to Windows” even if you don’t have a MS Win System at home. Queer.
Of course, I sometimes become definite, too ๐
However, I bought a Linux distro some weeks ago and some fixes are already promised. The GNOME 2.2 screenshots look well.
regards, Ludwig
Yes. Look at microsoft. They have SIMPLE names like :
Windows
Office
Word
Money
Bookshelf
Can’t the ubergeeks use SIMPLE names that mean something? instead of these, just for cd burning apps:
KonCD
CDBakeOven
XCDroast
GToaster
cdrecord is too vague?
Quote: “Like that? And menus are generated according to the contents of these .desktop files. So, what you are asking for has been done already.”
No, not like that at all. Those are nice xml files that only work with gnome. Make a symlink, which any app understands (because its handled at a lower level that user-space applications. Then it will not matter if a package creator makes the package install menu items – they will show up, because the “menu” is just a symlink to an applications folder. It will also not matter which desktop the user runs, kde or gnome or whatever, they will have items in their menu.
I’ve set up my macos 9 and beos installations this way, but it isn’t something I can do in linux. I must create .desktop files, and move them around. Then when I install a new app, if it doesnt create the menu item, I must do it manually. If the “menu” is a symlink to a common “application” directory, no problem.
It was early when I wrote my first post, and now I’m boaderline braindead after an 11 hour shift at work…I hope this all makes sense.
Mike Hearn:
No end users should see the system directories at all.
Eugenia concurs:
But… I agree on that!
You’re both very evil people.
But you can’t really be blamed. You’re both aiming at making UNIX userfriendly and desktop-oriented, which seems to lead to two paths:
1. Either throwing most of the innards out, keeping only core components. BlueEyedOS is a good example. It goes for core technologies but doesn’t pay the userland much attention, instead implementing a metaphore entirely of its own. This is obviously not what Eugenia intends. She’d like to keep the toolkits, the POSIX compatibility (why?) and so on.
2. Hide the system from the user. If you want to keep the UNIX, the inherent complexity of the system must be hidden. So no insight into the directory structure. As a “power user”, I find that a horrible suggestion. Windows does this, declaring C:WINDOWS and C:PROGRAM FILES as off-limits. MacOS X does this to a certain extent, but as always with a bit more spit and polish than the competitors. The original MacOS didn’t do this, though. My mother isn’t particularly afraid of the System Folder. Whether things are hidden or not is indiscernible to just about every user. It just works, and unlike Windows, there are (were) no droves of files with incoherent 1981-era names.
I, just like my mother, like to know my way around the system. But I don’t like UNIX file system organisation one bit. It’s not friendly. The multitude of /*/bin/ directories containing innumerable files is just one example. The naming of files is another one.
If a little though was spent on file system layout in the first place, even amateurs could find themselves at ease, and the developers wouldn’t need to worry about the user getting lost inside the filesystem.
I prefer full transparency in a system, and I think that that appeals to most users, both newbies and pros. But for that transparency to have any meaning, the underlying mechanisms (such as the filesystem) must be clearly thought out and laid out. This isn’t the case with Linux, but rather than declaring areas of the system off-limits, one should consider how one could make it more user-friendly.
I’m amazed that Eugenia, who claims to be a UI designer, doesn’t think so. After all, don’t you agree that predictable UIs are preferable over those which get in the way of the user, so-called intelligent UIs? Hiding underlying structures is the same thing. Make a UI predictable, and people will quickly reach a working pace.
This is also a kind of consistency question. A filesystem is a UI of itself.
“As a “power user”, I find that a horrible suggestion.”
Exactly: as a “power user”. But we’re not targeting power users here, we’re targeting “average users”.
Why should average users have to know about the underlying structure? Heck, why do they even want to know? They just want to work with the computer, not trying to learn how the engine works. The menus and icons, that’s what they should use. Is there any good reason why Joe Average should touch the underlying system structure?
Giving the system directory “easy” names only encourages Joe Sixpack to fsck his system because he *thinks* he understand it.
If Joe Average doesn’t touch the underlying structure, then advanced users who know how to use the commandline (developers and power users) will. The advantage of the current structure for them:
– Easy to type (I can type /usr faster that you can type /System Resources)
– Easier to remember for non-English people (what’s easier to remember if you’re Chinese? /lib or /System Libraries?).
– Easy to understand. No you won’t understand by just looking at it, but you just have to read a document for 3 minutes to understand what all those directories are! Yes, *3* minutes, at most.
My idea was to “hide” the system filesystem hieriarchy the way OSX and AtheOS and BeOS does it. When opening a terminal, you would be able to see and manipulate wdhat you want in the system (and even via file manager’s path input box if you know what to type). The OS we are trying to describe doesn’t “take away” from you ANY of the power Unix has. However, for the average user, he doesn’t have to see all these “useless” for him system directories. So, when he normally navigates in his disk with his file manager, these dirs would be hidden. This abstraction works well with OSX and BeOS and AtheOS and has never created any problems to anyone. And power users still get to keep their flexibility they want. So, I really don’t see your problem.
Why should average users need to know about the underlying directory structure, you say?
So that they feel in control. I believe that that’s one of the reasons people don’t like Windows and would like to hear about alternatives. It’s a complaint I hear often enough. They don’t feel like they’re in control. The system is so much more complex than the surface might reveal.
One problem I have with OSX is that Apple implemented such a polished GUI on top of a relatively untouched UNIX userland. It’s very unlike Apple, who have previously gone for a more thorough approach. It presents a very uneven learning curve. It’s easy up to a certain point, and when you cross that certain border, you end up in a very alien environment. I don’t know if they might have fixed it yet (though an interview with Apple’s BSD guru featured recently on OSnews makes me believe that that isn’t the case), but a year ago, Apple’s command-line utilities were so rough in the edges that they weren’t even aware of Mac metadata, which meant that the “mv” (a command used to move or rename files) command could cripple your files. That’s what I mean.
If you decide to remain blissfully ignorant of the underlying structures for the rest of your life, you could get on with even today’s Linux desktop distros without any problems. Just run GTK or GNOME apps, just install using the officially sanctioned package system, and ignore that XTerm icon. But this is no different from a Windows user experience. Perhaps not quite as polished, and it might even turn out that the user feels more in control in the Windows environment, but the difference is minute. But unlike the Windows desktopification developers, I’ve never been advocating that Windows might serve as a good model for a desktop environment. Most non-Linux desktop developers would seem to agree.
A sufficiently clear system layout isn’t threatened by Joe Average. Classic Mac users seldom cause their systems permanent damage. I don’t know how much magic the Mac system involves, it might be a whole lot, but it certainly looks easy enough to the user, and even a technical user as I haven’t been able to scratch much on its surface. That’s perhaps an important difference. No matter how hard you beat on MacOS, once you’ve reached the perceivable bottom, you can’t go any further. Thus, I can’t make any broad statements about how much of MacOS which actually is hidden from the user, because if it does hide anything, it’s bloody well hidden.
Really, if all the user is supposed to use are the menus and icons provided, the Linux desktop user experience is just about finished as we speak; only the video players are yet lacking, according to last week’s usability rant. But we aren’t providing them with anything which they hadn’t got on Windows in that case, and I think that it’d arouse much the same claustrophobic feeling which so many Windows users already speak of. One should at least induce a sense of clarity to the user at all levels, and a correspondingly even learning curve. Peak his curiousity, don’t scare him away from venturing further. It’s a question of demystification of the computer. Many – perhaps most – may prefer to just regard it as a tool, but if the user can be made more self-sufficient, that is a large stride in an often forgotten usability department, one which could become a strong selling point. Feeling is something which keeps people with the Macintosh (N.B.: I’m no Mac user, I just happen to know several.), and it’s IME not just a question of familiarity, but a sense of control.
Besides, Eugenia isn’t a Joe Average user either, and I don’t think that she intended FooBarOS to be aimed only at that segment. In that case, I don’t think that she’d have proposed such radical alterations to the current Linux architecture.
The power user might be a niche not quite catered to by Linux. Power users are, as someone else wrote a while ago in an OSnews article, non-programmers who still have much computer knowledge and are demanding about their environment and applications. It’s a bit like the difference between M$ Publisher and Quark XPress. One is for the amateur, the other is for the power user. While overall system elegance might not matter much to the casual word processing and web surfing user, and while the programmer will have a programmer’s mindset and be forgiving when it comes to obscure technicalities which show up, the power user treads the middle road, without the programmer’s patience or the amateur’s blissful ignorance.
As for the practical points:
-All modern systems, save BSD and HPUX, have tab-completion as standard. And you could use links or assigns to ease the burden on your typing fingers.
Besides, I see this as a general fallacy of UNIX. When I once complained that UNIX shell syntax was overly complex, requiring too much man(ual) reading, someone replied that I should just make an alias or a script.
That’s an reverse approach compared to normal learning mechanisms, in which case the standard syntax were verbose to cater for newcomers, and then supplemented by briefer syntax or user-created aliases/scripts. GNU has actually done something in this direction, with its single-dash and double–dash arguments (though I personally find the dashes pointless).
-Easier to remember for non-English people. Quite probably. I’m not English either, and the laxness towards i18n in the open-source world is one thing which makes me steer clear of using its products more than necessary. But that’s what i18n and localisation is for. Both the Mac and Windows have localised directory structures. It needn’t be that difficult. Just make the standard directory names into localisation data. That way, a Japanese or Chinese system would have a directory name /ยยงโxลฝโโยฟ or something like that.
-I don’t find the myriad of /something/bin easy to understand. And rather disorganised as well. This despite ten years as a computer user and running several BSD machines at home. I belong to the “keep all related things under on roof” wing. This makes installation and deinstallation so much easier as well. Once again, my preference for clarity in filesystems and related mechanisms shows.
Besides, saying that something is easy to understand after reading for 3 minutes doesn’t mean that it is easy. If it were really transparent, one wouldn’t have to read so much.
BeOS didn’t support metadata transfer with cp and mv either. And BeOS’ main feature was the metadata. Instead, it provided another command line util, called cpattr which did the job.
As I explained, the system dirs and files will be accessible to whoever is willing to do something with them. For the rest of the users, there is no reason to clutter their file manager for absolutely no reason. Don’t forget that all operations should be done via the gui, so there will be little incentive for the average user to open a terminal and hack around the directories found under his filesystem abstraction threshhold.
@Eugenia
If the standard UNIX filesystem layout weren’t so chaotic, that wouldn’t be much of a problem. In this case, I see the flat layout, which usually is beloved by UNIX users, as a disturbance in the low-end user’s experience.
There is no separation of functionality, that classic modernist concept. You have an all-unifying slash, which for some reason is stuffed with dirs of little consequence to the end-user, such as /usr, /bin, /etc, /opt, /old, /lost+found and what have you. These should really have all been stuffed into a /sys directory when single-user UNIXes first showed up, to keep the root tidy.
An example of this separation of functionality is the standard AmigaOS set-up, with a System and a Work partition. The System partition contains the system in its entirety, with its usual directory structure. Work is a clean slate for the user to populate (or pre-populated with applications). There is no need for the user to venture outside the Work partition in his day-to-day activities. Even Windows strives to do this by, albeit traditionally a one-partition set-up, isolating the mess it calls a system in a C:WINDOWS directory. The same goes for the Mac and its System Folder. Even UNIX seems to have strived for something similar, traditionally splitting the hard drive into a root and a usr partition, though this concept is put out of order by its cluttering of the root directory with system directories.
BTW, have you used the Amiga, Eugenia? It has an interesting solution to your idea of separation of relevant and irrelevant files. There are files with and without icons. Open a program drawer (folder, directory…), and it will at first display only relevant files such as the binary and its documentation. Choosing the “Show all files” option will however reveal all those files lacking icons, such as support libraries, plugins, locale files or data files. This makes the file system appear both as tidy for the experienced user and as accessible to the inexperienced one. It’s a bit similar to the AppFolder approach of RISCOS or MacOSX.
I still think that even experienced users would prefer a clearer filesystem layout, though. And keep learning curves in mind. Many current OSes are like two alien parts welded together, but with an ugly seam apparent. Unlike systems designed with a GUI from the start, there is little rapport (excuse the francophony ๐ between the upper and nether regions in older systems (to which I count UNIX and MS-DOS derivatives).
This has been really interesting to read. I think designing a new Linux kernel OS with usibility first and foremost in mind is a really good idea. Perhaps this discussion could be continued elsewhere?
Yeah… Like Joe User would use cdrecord every day?
Talking about the file system, I’m still having a lot of trouble trying to get KDE 3.1 started on my RH8 box. RH says something to put into /etc/sysconfig/desktop, whereas KDE says something else, and both don’t work at all! Now you tell me, installing something should never leave this file-hunting job to me…
As it mention here, the case of video players will be soon closed. Take a look at totem http://www.hadess.net/totem.php3
An once gstreamer will be released (I mean a stable release as they said) everybody will be happy.
>> Why should average users need to know about the underlying directory structure, you say?
>>
>> So that they feel in control.
No, what you’re actually saying here is that _you_ want to feel like you’re in control.
(there’s nothing wrong with that btw, but you’ll have the CLI for that)
The average user doesn’t care about that as long as it works.
(and that’s my own experience with newbies / average users)
the birth of Eunix. :>
Hey, it sounds good as well!
Presenting……………………..
EUNIX
There’s a thread about this in the Linux forum for now, to keep it going until it can move to another place
Actually, I was saying that the average user wants to feel in control. As I stated, many users I’ve met regularly complain that their system is doing things without asking first, and they have no idea how to correct it.
Naturally, I, too, want to feel in control. And I like consistency. I don’t think that there’s any need to have the GUI behave in one way and the CLI in another, when they both make claims to being part of one system. That’s inconsistent.
Hey, great thread!
On the practical side, I would like to try an experiment
and if someone more knowledgeable wants to join, you are more than WELCOME!
Today I use Gentoo and my first experiment involves having applications, each with its own folder, in a common directory.
The scenario here is:
– When the user does ’emerge’ the package,
he always finds the program (as a folder) in a common
dir (/opt/<package name> to stay with the standard).
Eventually, to make things really intuitive (dumb? ๐
I would like to provide an /apps or /applications
linking to /opt.
This of course involves passing –prefix=/opt/<app>
to the configure.
– For the CLI to work seamlessly, links in the system
directories would be set using ‘stow’
(thanks Peder, I was not aware of that tool!).
By sys directories I would use /usr/bin, /usr/lib,
/usr/libexec, /usr/share, /usr/doc… am I forgetting any?
Now the question:
If you know portage, how difficult would this be to implement so that it’s transparent to the user and
automatically available for all packages, without requiring
changes to the ebuilds?
Well, this in my idea for a first step, just drop me a line
if you feel like helping. Thanks
Tom
Just as an after-tought, why don’t we keep this comments on a TWiki somewhere, so that the thread can go on and possibly expand?
Hey, http://www.eunix.org is still available! ๐
Actually, jokes apart, the name fits particularly well, Eu means “good” in Greek, eunix, the “good Unix” ๐
Nite everybody!