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
I love gnome! I can’t wait for 2.2 final
I’ll wait for a proper .ebuild with all dependencies and stuff checked before I install it but reading their Bugzilla they have really overhauled it this release, and I’ve run RC1 since it’s release and had no Gnome related problems/bugs at all.
For those uninvited with 2.2 changes here is a (somewhat outdated actually but still good) list thingy w/ screenshots etc :
http://www.gnome.org/start/2.1/
>I love gnome! I can’t wait for 2.2 final
You would be more useful to the Gnome project though if you actually install the RC-2 and debug it. If everyone waits for the final release, they will get no bug reports…
what’s new in gnome 2.2?
Not a Gnome menu editing tool.
doesnt nautilus work for you??
How much of an editor do you want? Going to “applications://” in Nautilus provides me with all I need + the fact that you can right click items and choose among a bunch of options there (remove, help, propertise, etc).
How is the KDE menu edited? It was quite some time ago I ran KDE so I can’t remember (back when first 3.0 beta came out I think).
>doesnt nautilus work for you??
No. It is a cumbersome way, not user friendly. “applications//” you say. pfff…
>How much of an editor do you want?
How about true drag-n-drop support for remove/insert, as in MacOSX, huh?
But of course you can’t do that (true dnd on the menus), because on Linux, icons and binaries are not assosiated together. 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 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.
Troll as much as you want. I am not changing my mind on the subject.
I wanted to ask this in the KDE thread, but didn’t get a chance to before it got flooded.
Once Gnome 2.2 comes out, which is the best distro to get ‘pure’ versions of Gnome/KDE? What I mean by pure is one that hasn’t been ‘panzored’ by some distro maker. Though I understand that a distro maker’s touches may actually improve the desktop enviroments, I want to see the ‘unmodified’ versions so that I can fully appreciate/understand what changes distro makers have made to them.
Which distro will let me do this that is reasonably easy to install and upgrade Gnome/KDE to their latest incarnations?
I was hopeing for a screenshot of new Open and Save dialogs . . .
sorry – but applications:// is actually the way – it _should_ work. if you build up another app to just handle menu-editing its just bullsh**t – with nautilus you got the drag and drop support you want. once you know how it works, you wont want to startup some cheesy menu editor anymore – instead you just add launchers/groups/scripts there
Have they actually put them in the CVS already? They were still designing them and changing them daily just 2 months ago… Not sure if the new file dialogs are in 2.2. If they are, that would be good (at last).
>sorry – but applications:// is actually the way – it _should_ work
> if you build up another app to just handle menu-editing its just bullsh**t
Sweetheart, did I write anywhere about building another application?? I talked about DnD, not about any new suck a$$ application.
There are two ways to edit menu that I know so far, right click mouse on the menu or use Nautilus. I am very happy with right click mouse on the menu, because I always do that in Windows too.
And when I am talking about DnD, I am talking about it working seemlessly across all the gnome panels, not just the menu.
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. 😉
>I don’t see anything wrong with file dialogs, thought
This might help you see more:
http://osnews.redpulse.com/img/1280/gnome4.jpg
>No. It is a cumbersome way, not user friendly. “applications//” you say. pfff…
I didnt say I like it:P
I generally use key-bindings for most applications anyhow, then the run dialog or *term for the rest. I dont like to click and hunt.
>How about true drag-n-drop support for remove/insert, as in MacOSX, huh?
What.. browse to /usr/bin and then drag the app to apps folder? I personally dont think it would be any faster. But thats me.
> What.. browse to /usr/bin and then drag the app to apps folder? I personally dont think it would be any faster. But thats me.
First of all, this is why I say that a lot has to be re-thought regarding “unix on the desktop”. Applications (as opposed to services or command line tools) should not be in the /usr/bin/ in the first place. A new system should be in place, where a user will be able to install any application for himself, *or* for the rest of the users as well. Having 7,000 binaries in a single dir, is just not practical on the desktop.
And I am not talking about drag it to the app folder. I am talking about dragging it to the menu directly.
Updated CVSGnome to build GNOME 2.2 RC can be found here. It’s able to build from Tarballs OR CVS depending what you want.
http://gnomesupport.org/forums/viewtopic.php?t=1898
A bookmark ability is really needed in the GTK file dialogs. I do, however, think that the two paned MC like view is best for navigation. I would like to see a real tree widget for the left pane and optional column view with dates, sizes etc. to the right. I think it would be cool if the file dialogs could see the bookmarks set in Nautilus or ROX rather then the space wasting stack of location icons like in KDE and XP.
This might help you see more:
http://osnews.re dpulse.com/img/1280/gnome4.jpg
Oh, people want like this feature what KDE and Windows have? That’s fine with me, I always use drop-menu instead touch the side option on Windows. But, I agree it would be looks more professional and pretty if Gnome change the file dialogs.
smoke wrote:
> sorry – but applications:// is actually the way – it
> _should_ work. if you build up another app to just
> handle menu-editing its just bullsh**t – with nautilus
> you got the drag and drop support you want. once you
> know how it works, you wont want to startup some cheesy
> menu editor anymore – instead you just add launchers/
> groups/scripts there
Ahh… and there’s the hook. “Once you know how it
works. Maybe there’s a more obvious way to do it…?
Eugenia replied:
> Sweetheart, did I write anywhere about building another
> application?? I talked about DnD, not about any new
> suck a$$ application.
Exactly.
> And I am not talking about drag it to the app folder.
> I am talking about dragging it to the menu directly.
Doh! You just lost me.
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.
you may not have perferct english grammar… but your wit is dead on.
There is no reason why the menu should be in a directory. It could be XML files, as it is today.
Having them in a dir, and then DnD from a huge dir (like /usr/bin/) requires not only to make manual work (remember, the icons are not set automatically either and you will still need to answer a dialog if you want to move or copy or link the file) but it requires the user to _know_ that there is a directory called gnome_menu, somewhere hidden maybe in a bigger directory structure. And then, the user will have two representations of the menu, one in his gnome menu and one inside Nautilus. And that doesn’t make sense, because it is duplication and for a computer agnostic user is not logical the fact that his gnome menu somehow can be viewed within another application.
DnD is the best option for menus, the way BeOS and MacOSX does it (actually, BeOS has the best of both worlds – a directory with all the menu entries somewhat “hidden” from public eyes on /home/config/applications/ I think, and also supports DnD as of R5).
I can’t find any actual file selection prototype for GNOME2 (I know of older ones for GNOME1). This is an interesting thread from July 2002 about file dialogs and customizable toolbars –> http://mail.gnome.org/archives/gnome-devel-list/2002-July/msg00001….
It seems there isn’t any prototype implemented yet. Quoting Pennington: “No, no one has started yet. There is some work on an icon list in libegg.”
There are many screenshots to be found from the file selector prototype on previous issues of the Gnome Summary. Just check the archives of 1-3 months ago, and you will find them.
>First of all, this is why I say that a lot has to be re-thought regarding “unix on the desktop”.
Maybe for people that just want it to work. But then why not use an os geared toward that?
>Applications (as opposed to services or command line tools) should not be in the /usr/bin/ in the first place.
Why not? I honestly dont see a problem with it.
>A new system should be in place, where a user will be able to install any application for himself, *or* for the rest of the users as well.
Hmm…
# su
#./configure && make && make install
# rpm -Uvh *.rpm
works fine … not user friendly as a wizard though
Let not get into changing the Unix security model in favor of Windows.
> Having 7,000 binaries in a single dir, is just not practical on the desktop.
I hope your joking.
>And I am not talking about drag it to the app folder. I am talking about dragging it to the menu directly.
sorry thats what i meant
>But then why not use an os geared toward that?
Because none of these “desktop” distros do the necessary steps. They are small companies with very few employees, they don’t have the money and resourers to recreate the Linux *platform* geared for the desktop. The only company that has money and partners to help it, is Red Hat. The rest struggle, there is no way we can see the kind of innovation I am talking about from the rest.
>Why not? I honestly dont see a problem with it.
Because you don’t want to try to find your photoshop binary among a gazillion other command line utils and other crap stuff that you usually find in there. The app binary dir should be clean and well thought.
>Let not get into changing the Unix security model in favor of Windows
No my friend. We change the unix model in favor of the race for the dekstop. Linus said yesterday that he wants his linux to get to the desktop. Well, I just provide him with some clues.
The example you gave me, only works for instrallation ONLY if you are root. How about installing this app, just for you and not the rest of the users?
>I hope your joking.
i am not. usr/bin/ is a mess. There are hundrends of files in there. It is just not practical to have user apps there and then use them to put them easily in menus. It is just not practical. Remember: we are trying to do things that do not require us to use the terminal.
GNOME Summary – 2002-09-29 – 2002-10-05
5. New GNOME File Selector? ( http://developer.gnome.org/news/summary/2002_September29-October05…. )
Prototype —> http://home.wanadoo.nl/sbm/
It looks great if you ask me, next Red Hat beta?
this other older one doesn’t appear to have bookmarks:
http://snorp.coreyo.net/~snorp/fileselector-test.png
I like it. I think that the icon on the Save dialog should be DnD enabled for RISC/ROX style drag and drop saving.
>>But then why not use an os geared toward that?
>Because none of these “desktop” distros do the necessary steps.
Im talking about a different OS, not a different distro.
>Because you don’t want to try to find your photoshop binary among a gazillion other command line utils and other crap stuff that you usually find in there. The app binary dir should be clean and well thought.
So instead of trying to find it in /usr/bin with the other 7,000 _files_ you can search through /usr/<applications> among the other 6,999 _folders_??
I just dont see the big deal.
>No my friend. We change the unix model in favor of the race for the dekstop. Linus said yesterday that he wants his linux to get to the desktop. Well, I just provide him with some clues.
Thats all fine and dandy. Since he is responsible for the kernel. I dont see how he will influence the applications.
>The example you gave me, only works for instrallation ONLY if you are root. How about installing this app, just for you and not the rest of the users?
Greedy arent we:) Install into your home directory I suppose.
> i am not. usr/bin/ is a mess. There are hundrends of files in there. It is just not practical to have user apps there and then use them to put them easily in menus. It is just not practical. Remember: we are trying to do things that do not require us to use the terminal.
Does it really matter if your installation program does its job?
But wait selecting create shorcut- browse – /usr/bin/ – scroll down to p – ah there it is <photoshop> – is too damn hard. Im not convinced
> There is no reason why the menu should be in a directory. It could be XML files, as it is today.
> Having them in a dir, and then DnD from a huge dir (like /usr/bin/) requires not only to make manual work
Well if there was an XML based filesystem this could probably be done. And even if there is such an FS these environments are still going to need some kind of registry-like system to associate icons with applications for dealing with filesystems without such abilities.
And actually having the menu be a directory isn’t, necessarilly a bad idea. A directory is just a file after all and the OS knows how to talk to directories really speedy. The DnD system is going to have to be smart. When fidding with a menu, you aren’t moving files from one place to another, you’re just pushing symbolic links around. Personally I would just make something registry-like which dumped it’s user configurations into ~/.gui or something.
I do not see the need for more mucking with the FHS. Especially for something like this. The *nix file hierarchy has been mucked with too much as it is.
Also:
> i am not. usr/bin/ is a mess. There are hundrends of files in there.
“Hundreds”?! Mere “hundreds”? You aren’t trying hard enough.
🙂
$ls /usr/bin |wc -l
1705
> So instead of trying to find it in /usr/bin with the other 7,000 _files_ you can search through /usr/<applications> among the other 6,999 _folders_??
Hehe, not at all. You can either have pre-created directories that are specific for video, multimedia, productivity etc OR, you can do it my way, which is an attributed file system which keeps track of what gets installed, where, how many times it was launched etc. And then you have a special app launcher application (not a menu with a zillion submenus) that shows you several different choices:
1. You can browse apps by category (visit http://www.bebits.com and check their system)
2. You can browse apps by popularity (most launched)
3. You can browse apps by last installed
4. You can browse apps by most recently used
There should not be more than 10 apps listed for cases 2 to 4.
Now, THAT works. For everyone. And while it would be better the binaries to not all be on /usr/bin/, it would still work if they were there. But for uninstallation purposes, it would be better to have a special folder for “user” graphical apps.
>Im not convinced
I am. The current model is not nice for me. Loading on Nautilus or Konqueror the /usr/bin/ takes about 10-12 seconds here! That’s damned too slow (and a no-no situation for the idea I present up there), because there are too many files in there! And then, you have to actually FIND the app name, scrolling a zillion files. Hardly intuitive.
So, at least I have some ideas on improving the damn thing. I have worked on it and I have even mockups.
You seem to represent the old school “don’t touch my unix” kind of thing. Which if you continue having this attitude and not open your mind to alternatives that are FOR the desktop, then the Linux is going nowhere for that desktop. Currently, Linux is a great small server, but it is hardly any innovating in the dekstop/DE side. It is a copycat of what we already got. No innovation at all. I am proposing ideas to make changes that can be at least different. Who is listening though?
>But then why not use an os geared
>> toward the desktop
Windows started life as DOS, which , from the viewpoint of comtemporary OSes, was definitely not a “desktop” system. The entire windows line evolved from that humble begining. And look how many years it took.
OS X, too, is built on top of unix. Surprise! We must not forget, folks, that progress is cumulative.
>> 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
<<
Maybe. But in the real world, that kind of radical change rarely happens. Progress is almost always incremental. You take it one small step at a time. In my opinion, the linux desktop is already making huge strides. Linux has gotten to the point where ordinary folks can actually do work with it. I personally don’t see any need for radical change.
Oh, and there are many ways to change things. Writing RFCs is not one of them!
But wait selecting create shorcut- browse – /usr/bin/ – scroll down to p – ah there it is <photoshop> – is too damn hard. Im not convinced
Of course you’re not, because you like the Linux way of doing things, which is not really desktop friendly.
On my computer, there are about 25 different folders in Program Files, with God only knows how many files in each one. I would much rather search through 25 folders to find what I’m looking for than through thousands of files in a single folder. Hell, by your logic, they should just dump every damn file of the OS in a single directory, and then you could just scroll to find the one you’re looking for.
But the bottom line is, Linux lovers want to know what it would take to get Linux on the desktop in full force, and so we tell them, and they stick their noses up at us because what we expect of a desktop OS is not the same as what that expect. To us, using Linux is like a man trying to read a romance novel – it just doesn’t make any sense at all.
So, the choice is really easy .. either make Linux user friendly (not Unix friendly) or remain a niche OS.
>Progress is almost always incremental. You take it one small step at a time.
Not for Apple. They took BSD and Mach and they did their thing. The way it made sense for them. I wish someone would do the same with Linux or FreeBSD and X. They get the kernel, destroy compatibility ANYWHERE that it is _needed_ in order to INNOVATE and go from there.
Creating similar, compatible distros and throw 500 packages in them and sell them, is hardly innovation. It is just a living for me.
>Oh, and there are many ways to change things. Writing RFCs is not one of them!
I won’t provide anything else other than mockups, ideas and points. I don’t have the need to do so, neither the drive to write code anymore. It is up to the developers to fix their own applications.
>Writing RFCs is not one of them!
What I already do here, is already _enough_. I used to do UI design for a living, so that’s my best quality, so that’s what I am offering. For free.
I stopped reading my French (I am trying to learn french since last week) just to participate in this discussion and give the X DEs pointers and ideas.
The AppDir spec for ROX is very flexable, keeps all of a program in a single directory that is represented as an icon in the file browser. AppDirs contain the src and compile/optimize the binary the forst time its run. Also an AppDir program can be ‘installed’ localy or system wide depending if its under /usr/apps/ or under a user’s home.
A great solution to the /usr/bin/ issue
Ok… Let’s talk about it…
so there is to much file into /usr/bin .. well… I think whe should compare that directory with c:winntsystem32 … and then ask ourself: which one is the biggest mess???
Also, the files into /usr/bin have a clear name, easy to understand. hoo.. and by the way, why should I search for winword when I want to load word?
ciao!
> so there is to much file into /usr/bin .. well… I think whe should compare that directory with c:winntsystem32 … and then ask ourself: which one is the biggest mess???
Unix’s of course!!
The system32 is a SYSTEM’s directory. We are talking about user applications! System32 does not have user applications. The equivelant for Linux is this:
/bin/
/lib/
/usr/bin/
/usr/lib/
/usr/local/lib/
/usr/local/bin/
As you can see there are SIX directories on Linux, that do the same job as c:windowssystem32 does. And as if this was not enough, they throw the USER applications on /usr/bin/ along with all the rest of the crap that the user 90% of the times, doesn’t need to know about.
/usr/bin/ was designed FOR the user application, but with the years, it has become a big piece of mess and it really needs cleaning up. Or do it the Apple OSX way.
So, to answer your question: The biggest mess remains Linux. Not Windows, in this situation.
>Also, the files into /usr/bin have a clear name, easy to understand. hoo
Same goes for the applications on c:Program Files. What’s your point?
>and by the way, why should I search for winword when I want to load word?
Because no one is searching for the binary of Word. Is always there, everpresent, either on the menu, or on the program files dir, or by just double clicking a .doc file, or when you right click to a .doc file. In all my life, I have never had the NEED to search for the name of that binary. So, even if they call it Eugenia’sWord, it would still not matter. While it would certainly matter under Linux, because I would need to _search_ for it. But on Windows, there is not such need for this.
Next time, please do your homework before you start talking about usability issues.
GNOME is really kicking ass. I thought that it was dead a year ago, but they have come a long way.
I do also think that non-system programs should go some place like /opt/<appname>/ and be clearly seperate from the system level. But with advanced packaging solutions abstracting the details of application installation what does the install directory really matter? The .desktop standard for application metadata will also help a lot with this problem – basicly the same as Window’s menus.
> You can either have pre-created directories that are specific for video, multimedia, productivity etc …
Let’s keep /usr/bin and then let’s create a directory systemwide where links to this apps are classified in the way you satated above. And then let the user have the choice of creating links from this directory or directly from /usr/bin. This directory must be easily aviable for any desktop user.
I have read through the posts and, though I agree with Eugenia that there is too much under /usr/bin in most Linux distros, the current Unix filesystem is great is you have multiple users on one system.
I am not going to go into great detail on the history of Unix filesystems and what each directory means, but the Unix filesystem is tried and true and is amazingly scalable if used right. I work on systems that have hundreds of users connected to each, each user with a different account, and each machine with multiple levels of administration. There are also, with the users, multiple developers writing code in their own environments. I could not see how you could do this on any other environment.
As far as navigation around Unix, this is where abstraction should come in. The user really shouldn’t have to even know there is a filesystem, or learn the hierarchy, to be able to use a computer. OSX does a pretty good job at this, while still maintaining a robust scalable Unix backend.
I, for one, would rather have all my executables in one or a couple places rather than having a path that is a several thousand characters long. These are my options as command-line-using throwback…
Hmmm… I can see it now…:
C:/Program Files/mkdir
C:/Program Files/ls
C:/Program Files/grep
C:/Program Files/gcc
C:/Program Files/sh
>> I stopped reading my French (I am trying to learn french since last week) just to participate in this discussion and give the X DEs pointers and ideas.
<<
That’s why OSNEWS is bublling again
. You can see the obvious difference. Anyway, I thought you had come back fulltime.
> Eugenia
>You seem to represent the old school “don’t touch my unix” kind of thing. Which if you continue having this attitude and not open your mind to alternatives that are FOR the desktop, then the Linux is going nowhere for that desktop. Currently, Linux is a great small server, but it is hardly any innovating in the dekstop/DE side. It is a copycat of what we already got. No innovation at all. I am proposing ideas to make changes that can be at least different. Who is listening though?
> Darius
>But the bottom line is, Linux lovers want to know what it would take to get Linux on the desktop in full force, and so we tell them, and they stick their noses up at us because what we expect of a desktop OS is not the same as what that expect. To us, using Linux is like a man trying to read a romance novel – it just doesn’t make any sense at all.
So, the choice is really easy .. either make Linux user friendly (not Unix friendly) or remain a niche OS.
Please dont categorize me. I honeslty dont care if linux makes it on the desktop. Whatever making it on the desktop means. I dont represent the old school “don’t touch my unix”. I represent it works for me and happen to enjoy my computing experience crowd(independent of OS). If you cant swallow that then tough.
I always hear about these snobby Linux users. I havent meet one yet.
Unix’s of course!!
The system32 is a SYSTEM’s directory. We are talking about user applications! System32 does not have user applications. The equivelant for Linux is this:
/bin/
/lib/
/usr/bin/
/usr/lib/
/usr/local/lib/
/usr/local/bin/
As you can see there are SIX directories on Linux, that do the same job as c:windowssystem32 does. And as if this was not enough, they throw the USER applications on /usr/bin/ along with all the rest of the crap that the user 90% of the times, doesn’t need to know about.
Do you have any idea if you prefix gimp to /usr/local/gimp, Apache to /usr/local/apache and etc? The result would be..
/bin/
/etc/
/lib/
/usr/bin/
/usr/lib/
/usr/local/gimp/
/usr/local/gimp/bin/
/usr/local/gimp/etc/
/usr/local/gimp/lib/
/usr/local/apache/
/usr/local/apache/bin/
/usr/local/apache/etc/
/usr/local/apache/lib/
/usr/local/mysql/
/usr/local/mysql/bin/
/usr/local/mysql/etc/
/usr/local/mysql/lib/
goes on..
Now, the questions is which worst? Well, it is making a lot worst by a lot of duplication of effort and wasted directory entries. Not to mention, your PATH becomes extremely long, or you end up with a centralised tree structure full of symlinks. I call it non-standard, so FreeBSD’s hier(7) and FHS agree too.
/bin/
/lib/
/usr/bin/
/usr/lib/
/usr/local/lib/
/usr/local/bin/
/usr/X11R6/lib/
/usr/X11R6/bin/
It makes perfect sense.
/usr/bin/ was designed FOR the user application, but with the years, it has become a big piece of mess and it really needs cleaning up.
I am sure, you use FreeBSD as firewall, so check man 7 hier. The /usr/local/ and /usr/X11R6/ (for X apps) should be the directories that where SysAdmins install the apps. The /usr/ is for the system that came with by default. Your idea about change the file system hierarchy will taking a quiet lot of time to finish and change a lot of stuff. Don’t forget, *nix have a lot of libraries, apps and etc, so it’s more pain in ass to check each directories, just to edit the configure files or else.
…will be an unholy hybrid of Sawfish, Emacs, and Rox. We’ll call it Zod. “Kneel before Zod!”
theBare, bsdrocks, & others are missing the point. There is no need to move /usr/bin & friends. OSX does not. The model works well for CLI apps.
What needs changing is the method of accessing GUI applications. Noone needs a PATH for GUI apps. OSX gets it right by using an /Applications directory. It also bundles each app into a single icon, for easy launching, installation and uninstallation (although older Carbon apps do not always do this).
IMHO Windows falls down here too; C:Program Files is a mess, athough not as big as /usr/bin. MS even tries to prevent users from mucking about in that directory, telling them to use the Start menu and Add/Remove programs instead.
Creating greater levels of abstraction on top of the FS to make nice menus and easy installation adds a lot of unnecessary complexity, when the FS could be simplified and used directly.
The system32 is a SYSTEM’s directory. We are talking about user applications! System32 does not have user applications.
Hearts, Solitaire, MSPaint, Calc, etc are all in system32.
Seriously though, Eugenia, have you taken a look at LinuxStep ( http://www.linuxstep.org/ )? I read their mailing list awhile back and I think I remember them wanting to apply a more user-friendly directory structure and make other changes to some of the user-unfriendly conventions as well. The site has been stagnant for awhile, but the lists still see some traffic.
Could we maybe get an interview?
LOL!!!
>What needs changing is the method of accessing GUI applications.
Exactly.
/bin/
/lib/
/usr/bin/
/usr/lib/
/usr/local/lib/
/usr/local/bin/
/usr/X11R6/lib/
/usr/X11R6/bin/
It makes perfect sense.
Um, makes sense to who? I don’t give a damn what planet you’re fom .. when you see those manes for the first time, you’re not going to have any idea what the hell it means. ESPECIALLY usr/X11R6 …
Even if you know what X11 is, what th f**k is R6? It’s certainly not apparent by the directory name.
Now, I’m not saying any of this to defend anything that Windows does differently (or similarly), but when you say the above directory names/structure makes sense, that’s a pretty good indication to me that you need to lay off the crackpipe
>>What needs changing is the method of accessing GUI applications.
>Exactly.
The specifications on http://freedesktop.org for the .desktop file is a good start in this direction.
ESPECIALLY usr/X11R6 …
Even if you know what X11 is, what th f**k is R6? It’s certainly not apparent by the directory name.
No comment, I agree with you. At first, I wonder why the hell they called it as X11R6 rather than X11. But, it doesn’t matter if you rename it to X11 or whatever. It still makes sense to keep GUI apps seperate from non-GUI apps.
that’s a pretty good indication to me that you need to lay off the crackpipe
Ok, sounds good! Are you buying? 😉
Oh btw: dealing_death and Eugenia, sorry I guess I am still missing the point. Because, I never have touch and use MacOS X, BeOS or whatever what OS that have you like. So, stuff is perfect sense to me. 🙂 If you have any urls about it, show it me to see if it will clear the cloud in my head.
I agree that while GNU/Linux and UNIX are great, they’re in dire need of a workout if they wanna be desktop players. They’re set up in a very good way, as far as servers go. 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.
Ya know, something like that *is* legal.
Of course it is a big undertaking. Hey, I smell a new community project brewing
. Another job for SourceForge, maybe? “It’s too much for anyone to get done” sure would be a lame answer from the community that has made Linux what it is today.
>The specifications on http://freedesktop.org for the .desktop file is a good start in this direction.
http://www.freedesktop.org/standards/desktop-entry-spec/desktop-ent…
First of all, this is not XML (much more prefered). Second, I find the OSX way much better than this mess that the FreeDesktop suggests. You see, a .desktop file will be stored somewhere in your home, and it will launch a binary somewhere else and it will load a png icon somewhere else. If your admin deletes the binary, you are left with a non-working .desktop.
MacOSX and Windows, still do it better. In fact, OSX does it even better than Windows in this regard. The “configuration” file for the binary is inside the package (the whole app is one big file, which in reality is a package of files) and the equivelant .desktop file is an XML file. And if you delete the binary, you delete its .desktop and icon automatically, as all these live inside the package you just deleted.
On Windows, some of this infromation live inside the binary and some other info lives in the registry.
On BeOS, some lives in the binary file, and you could populate more information via its attributes feature found on its unique filesystem.
But on Unix, because you have all this 30 year legacy behind you, you create more and more hacks. That .desktop thing SOMEWHAT HIDES the problem, but it does NOT solve it. And it has its own issues in the first place. This supposed to be a “new solution” and it is still not better than the 5 year old BeOS, 7 year old Windows and 3 year old OSX.
Who talked about innovation in the linux desktop? None? Ah, ok.
Peace.
>use MacOS X, BeOS or whatever what OS that have you like
Believe it or not, I am not a huge fan of OSX. OSX has other issues.
OSX has fixed most user-important stuff, but they have other shit waiting to be fixed.
BeOS was good, could be better. But it is still pretty good. It is free to download, it is only 50 MB. Give it a try and if you have a problem, let me know and I will help you setup it.
Nathan O. you indeed “got” what I was saying. We need no new distros. We need innovation. We need a project that takes the kernel, gnu stuff, x and kde/gnome libs and change them in as many ways are _necessary_, breaking as many binary or other compatibilities of any kind as _necessary_ to make sure that you create a legacy-free (but *still* posix compliant) OS, that can match up OSX in ease of use.
Apple did it. They took a unix and while they are still posix compliant, they changed so many stuff, because it made sense to do so, for their customers. This is what it needs to be done wiht Linux as well. It IS a big undertaking, we are talking about the design of a new OS, but based on existing tools with modifications, so instead of taking 10 years, it should not take more than 2.
Believe it or not, I am not a huge fan of OSX. OSX has other issues.
Hehe, I know what you mean. 😉 I love M$ for made Office product, but I dislike M$ for create Windows. 😛
BeOS was good, could be better. But it is still pretty good. It is free to download, it is only 50 MB. Give it a try and if you have a problem, let me know and I will help you setup it.
I already downloaded that BeOS5 PE MaxEdition 2.1, but I just need to delete Linux partition and install BeOS on family box. It will be dual boot between WinXP Home and BeOS, but what kind of boot manage would you recommend?
Eugenia, what you are proposing would best be done if resource forks were supported in the ELF format natively (which, afaik, they aren’t). So, it’s not a DE problem, it’s a binary format problem.
I, personally, think that the .desktop format is fine. XML would have been better, but as is it can do everything you’ve said if coupled with good package management.
>So, it’s not a DE problem, it’s a binary format problem.
I know. This is why I suggest you scrap the existing legacy and create a linux experience that works for the desktop, by making as many changes are needed.
Talk about getting far afield… by the time I read the previous comment, I had to go back and reread what the actual article was about…
For what its worth, I agree with Eugenia 90%. We need /Apps or at least /usr/bin/Apps for GUI stuff.
MacOS X is just Darwin with a lot of heavy customization, no? So if someone were to take Linux and do the same thing…
Seriously, is anyone here interested in participating in such a project? I’ve only taken a couple basic C++ classes myself, and am not much of a programmer, but hey, I’d love to do what *I* could for such a project! So yeah, concensus, how many people here, active and posting, would like to be involved in such a project? For that matter, how many people wouldn’t / don’t think they could contribute, but whould love such a project?
Just a thought, but I’d love something that could fit on a mini-CD. I love those things! And then maybe another ISO made for a big CD with extra apps. Aside from mini-CDs being neat, a smaller target size always keeps out the cruft!
And of course, use something like bz2 or rar for compression for the *custom* package management tool for your new OS, and you will be able to fit in 1 CD apps that need 2 CDs under Linux with conventional packaging methods.
I would like to see such a project, but I am afraid that without a person leading the UI and user experience, and most importantly, the developers to do _exactly_ what the ui person asks, the project would be “just another hacking experience”. You see, the problem with today’s DEs is also that the devs don’t listen to the UI people (I know that this is the case in Gnome; I was told that from a Gnome person). So for that project, the UI/User experience person should be someone that others lean on.
Don’t know ’bout y’all, but I’ve been giving this some thought over the years. The directory heirarchy is excellent for managing an OS, all user data and just about anything. In fact in unix everything is a file. So what I recommend is a system designed around forward and backward compatibility, where incompatibilities are hard linked and require specific packages.
/usr/bin/XFree86-4.2.0
/usr/bin/XFree86-4.3.0
/usr/bin/XFree86 -> XFree86-4.3.0
/usr/X11R6 -> bin/XFree86
/usr/man -> doc/man
/usr/doc
/usr/doc/html
/usr/doc/info
/usr/share – for extra data
/usr/icons
/usr/icons/nautilus/themeblablabla-left-arrow.png
/usr/pics/Wallpapers
$HOME/Wallpapers -> /usr/pics/Wallpapers and set as the default desktop background ( I set mine as a collection of nice gnome/kde backgrounds for each of my 8 vts to choose from )
/usr/pics/gif89a or tif or bmp for unique files
/usr/av – for system/app sounds and multimedia
/pictures -> /usr/pics
/audio – user audio content
/video – video content
/html – perhaps local webcache or a symlink to /var/www/html
Store metadata, possibly in xml, about a heirarchy of symlinks in each user’s home directory:
$HOME/.startmenu/Programs/
/Applications/Notepad -> /usr/bin/gedit
$HOME/.startmenu/Settings
The metadata could easily be stored in $HOME/.startmenu/.metadata and tell the system not to read hidden files as apps. Then if an application doesn’t have any metadata, but was just dragged into the start menu it would get the default icon but could easily be modified later by the user, such as for DnD operations.
If no .startmenu directory exists it can create a new one by reading a default /usr/.startmenu or /etc/.startmenu. But I would not recommend splitting the default apps and user apps like NT2k did. A user should have full control over the applications and the layout of their menus.
Drag and drop becomes easy, a quick symlink or copy of a symlink and launch a program to add an entry for its metadata. Installing packages can add the metadata for their apps to include icons, etc. The system could even use icons from /usr/icons/startmenu that match the name of the symlink by default.
I think startmenu is a silly name, and some of this needs expanding upon, but that will probably be similar to how I do things when I get around to it.
( http://www.jwz.org/doc/worse-is-better.html )
That is the so called “New Jersey” approach so carefully followed by the Unix creed, a complete consistent solution is not important, what it is most important for Unix and the likes is to have any half baked very simple to implement solution (it doesn’t matter if the interface is hairball-complex for the user) that spreads like a virus. So if mutants don’t interfere, most probably there will be something like .desktop on Linux
>>So, it’s not a DE problem, it’s a binary format problem.
>I know. This is why I suggest you scrap the existing legacy >and create a linux experience that works for the desktop, by >making as many changes are needed.
But all this just complicates things more and more.
I believe that you know that you are demanding a bit too much to get all this accepted into standard Linux kernels and distros, or the *BSDs (which don’t have DEs, except those provided by third parties).
So, you end up with a partial rewrite of the whole OS for Linux, scrapping ELF, scrapping this, scrapping that, making new things and so on.
Then what do you have, out comes new GIMP 2.0, Mozilla 2.0 or whatever, for Linux. Uh-oh, which Linux, the new rewrite, or the old one. The program won’t work for both.
I don’t see what the idea is of making such a rewrite on top of Linux kernel. While Linux kernel quite frankly is a pretty nice piece of work, why is it so important to build the new things on top of it? And why is it important to build and rebuild on top of the UNIX-world at all.
Just hack up a complete new OS, or use some existing good desktop OS, is what I say.
That Vector Linux that was reviewed a few articles back sounds like a good start to a less-is-more Linux for desktop users
I know that a project is under way to create a Linux that is ment for running ROX and use AppDirs as its native application packaging system. AppDirs illiminate the need for “resource forks” as the entire directory is treated as a unit. It may also be interesting to make AppDirs a single file by using VFS to access an archive as a directory.
A package manager like RPM would still make sense at the system level and a first time “install” script in each AppDir could interface with a package manager tool to fetch dependencies APT style.
You have misunderstood.
When a new Mozilla and Gimp comes out, an afternoon’s work should be enough to “port” them to the new system.
The system we recommend _is_ a linux-based system, with X, and KDE-libs (but not with kicker or the KDE desktop as you know it) and with Gnome libs and GTK+ (but not wiht Nautilus and Gnome panels the way you know them). It is a new system, it plays with “new rules”, it doesn’t have legacy (while remains POSIX), and introduces a lot of new things differently, that would make the experience better.
But by doing all that, does NOT MEAN that you break source compatibility. You might indeed break a few things here and there, but overall, porting a GTK+, X or Qt app to the new system should be TRIVIAL.
So, your argument does not hold up. You haven’t understood what we are saying. We say to build a Linux experience that works for the joe user, but based on existing tools and toolkits. Porting gui apps should be trivial, EVEN if the whole system and desktop might look and interact differently.
What do the specifics of the system level directories matter to the end user if some automagical system like APT deals with where things are put?
With symlinks if you are careful about using relative paths instead of abolute paths you can easily pull tricks like mounting /usr/bin from another system or flat out copying entire applications over a network using sftp/scp/ssh or whatever floats your boat. Could all be scripted into the package management system. I think P2P is the best way to distribute updates and Apps.
With the system I meantioned above you could even use metadata to describe apps that were symlinked to a lUFS mount from another system and ran chroot in that environment, for example.
> A package manager like RPM would still make sense at the system level and a first time “install” script in each AppDir could interface with a package manager tool to fetch dependencies APT style.
No. In the system that we would like to build, there should not be, and developers would not be encouraged to release anything that require 100 libraries to work. Everything WILL HAVE to work. As in BeOS. As in OSX. As in Windows.
If the system has the required libs, that’s fine. If not, the app should distribute its dependancies on its own package (this way, you can install a different version of the lib on your /usr/lib/ and still have that application running with your custom version, like in BeOS), or link to them statically. Dependancies are out of the question. They are the menace of the Linux/Unix today. Remember, we try to build a new system, a new OS. It just *happens* to be based on Linux. It might as well be based on FreeBSD! It doesn’t matter! One thing is for sure, it won’t be a yet-another-Linux-distro. It wouldn’t even be binary compatible. It would be a new OS.
You got to be kidding.
I have a quick question Eugenia.. whats with your obsession with Joe User?
Does *everything* have to be designed for Joe User? Would we, as a whole, benefit if everything was so completely and utterly dumbed down? Instead of comparing things like the Gnome Menu editting system to OSX’s why not a fresh idea? If you like that system so much, it wouldn’t be difficult for you to d/l the code and implement it yourself.. and by yourself.. I mean you’re gonna be the only one using it since the current system is fine for me, and my Joe User dad.
>But by doing all that, does NOT MEAN that you break source compatibility. You might indeed break a few things here and there, but overall, porting a GTK+, X or Qt app to the new system should be TRIVIAL.
Existing distro like to break compatability already . . .
I mean subtle differences can make it a real gamble trying to use an RPM compiled on a different distro or even an earlier version of the distro your using.
> whats with your obsession with Joe User?
It is not my obsession. It is my job. I used to be working as an interface designer in UK.
> Does *everything* have to be designed for Joe User?
Of course. The fact that YOU can go around badly designed UIs, doesn’t make the specific UI design any better. It is still shit. It just happens that YOU know how to go around it. But it doesn’t make it better. I am tryign to MAKE it better.
> Would we, as a whole, benefit if everything was so completely and utterly dumbed down?
Yes. See above. And it won’t be “dumbed down”. It would be more intuitive, even for you.
> Instead of comparing things like the Gnome Menu editting system to OSX’s why not a fresh idea?
I already have. Read my previous message regarding the app launcher.
> If you like that system so much, it wouldn’t be difficult for you to d/l the code and implement it yourself..
While I am a programmer, I don’t have the incentive to go hacking code. I don’t do it nowdays. My main job was web developer and UI interface designer. That’s what I do best. And this is what I offer over here. Solutions.
Someone else will have to do the coding I am afraid.
> and by yourself.. I mean you’re gonna be the only one using it since the current system is fine for me, and my Joe User dad.
Haha, you assume too much.
>> whats with your obsession with Joe User?
>It is not my obsession. It is my job. I used to be working as an interface designer in UK.
You didn’t get fired did you?
What you mean is that “FoobarOS based on Linux” has the libraries it ships with and developers should be expected to compile against the specific versions rather then the latest and greatest version of each library. That could work as a sort of “stabalized” linux. Developers and the existing Linux community can continue to do things in the chaotic bleding edge way as always but their progress could then be “backported” to this more stable Linux based platform.
>You didn’t get fired did you?
Why this hostility Andrew? Why? I have worked my ass on usability with both the KDE and Gnome developers the last few months, and even the Synaptic guy, and I even worked on another OS project about UIs which I can’t mention because I am bound by an NDA. So, I DO something for your beloved OS. I recommend ways to make it BETTER. But you, are just hostile! You are really low on my eyes right now.
To answer your question, no, I was never fired on any of my jobs in my life.
I stopped working in UK, because I got married and moved to USA. Happy now?
Yes, you are now starting to getting it.
And remember: If a developer really needs to ship his app with the latest and greatest libs, he STILL can as I explained earlier, *without* breaking the system!
On BeOS, you just create a library folder in the folder where the binary lives, and the OS will FIRST try to load the libs found there for the given launched binary and if the OS won’t find them there, ONLY then it will load the system library one!
So, when I used to port SDL games on BeOS, the <my game folder>/lib/libpng.so was a newer version than the one shipping with BeOS, and it would work with the binary I was releasing on the <my game folder>/mybinary, without breaking the OS!
This BeOS style of library overriding can be done now in Linux, possibly using the AppRun script in an AppDir, by loading the LD_LIBRARY_PATH with your app’s library directory. In fact the script could probe the machine type so that the same package could contain binary + libs for multiple architectures.
Yes, but you are talking about scripts. I am talking about architecture here. I am talking about things that would work out of the box, as you expect them to, and not when and if a user runs weird scripts and load library paths manually.
The solution you offer is no better than the FreeDesktop one: It is a hack to ease the pain of the 30 years of Unix legacy.
This is not the way to go to the desktop. Unix was never designed for the desktop, it is a server architecture. To make Unix user-friendly, you will _have_ to throw away some of the legacy and certainly hacks like scripts and .desktop files are not the answer. Neither that terrible thing called “configure” which is also a script to figure out things for you, but it has end up to be a bloated piece of sh*t in which there is no way you can edit it by hand (scripts are supposed to be editing-friendly).
The Linux experience needs not only evolution at this point, needs revolution as well. I will bow to the one who’s got the guts to do what Apple did with BSD.
I think one of the differences between Linux and commerical OS’s is that in Linux, most people just hand out the binaries from their home server, or from something like rpmfind.com. That’s cool, cuz it’s all free, but at the same time, it’s harder that way to find dependancies. In a Windows app, all the dependancies are (usually) included on the nice CD you bought. I’m sure that if Linux apps more commonly came in boxes, people would tend to be better about dependancies.
However, since I likes me my free software, I think we’ll stick with the idea of downloading everything for free
. I think we’re talking about a new Linux, and not a new distro, correct? Of course it’s correct. It’s a lot like the difference between FreeBSD and NetBSD, I think. Maybe a little more stark. Basing it on Linux, I think, is a good idea, simply because of the hardware support.
There are probably 3 main things that need to change- the UI, dependancy hell, and packaging.
UI needs to be intuitive, of course. Features are great, but one of the reasons I don’t use KDE is because I want my desktop to work for me- I don’t wanna spend all day learning the ins and outs of all the features that my DE offers, and how it interacts with my GUI server when something breaks and I need to fix it. I want it simple. I use IceWM. Not horribly many features, but it stays out of my way while offering decent power. Of course, there’s a lot of room for improvement over my favorite WM.
Packaging is a toughy. I hate RPM. I decided a while back that I’d exclusively use RPM to install anything, in order to keep things simple. Needless to say, I’ve abandoned that idea. Packages and dependancy hell are, needless to say, a nightmare! I have a lot of great ideas for packaging solutions that would eliminate dependancy hell once and for all for Linux, but of course these ideas would only work if developers flocked to it in droves. I’m sure all who read this could come up with similar solutions given even 20 seconds to formulate the entire system.
“Unix was never designed for the desktop, it is a server architecture. To make Unix user-friendly, you will _have_ to throw away some of the legacy and certainly hacks like scripts and .desktop files are not the answer.”
Absolutely!!!!
And what’s wrong with making an intuitive desktop that can also be a power-user system as well? I think a lot of people don’t realize, it *can* be done. I’ve only used MacOS X a couple of times, so I’m no expert, but I hear that underneith its beautiful exterior (which can be used by Joe User with relative ease) lies a UNIX system. One day, I walked in to my school’s computer lab, sat down at a Mac, poked around, and within 1 minute was using a shell prompt!
I think that if power users would relax and open their minds to it, they’d realize that a well plotted UI can be good for productivity. To anyone who questions this, I ask: what do you use your computer for?
Computers are for computing. I use mine for 2 main things: poking around and learning about computers, and getting stuff done. A good UI is what Linux needs. I don’t need more fluff. I don’t need more features. I need a UI that helps me get more done faster.
It seems like OSX will be copied and is accepted by both sides.
I don’t want to have /usr/bin/programdir2:/usr/bin/programdir2
or even /usr/bin/Multimedia:/usr/bin/web/:ad infinum
I understand that /usr/bin is confusing for a newbie, or anybody for that matter with so many binaries. Perhaps the path could be /usr/bin/* which may or may not search all the directories. HOWEVER:::::
Sometimes breaking compatibility will break more than you bargain for. If you change this directory structure, it will be popular for a very small segment. It would end up dying because it would be so much trouble to work with.
Not that it was a bad idea, Eugenia, but it’s just not feasable. The old way is too entrenched. It also has it’s reason for being.
However, I have no problem with a $HOME/Multimedia:$HOME/Web:$HOME/Graphics ad infinum that link to /usr/bin (which I guess is what OSX has, or close to it). You get the best of both worlds. The Gui will show the $Home organization, while the /usr/bin structure stays for CLI and other compatibility (aka as ooops, that’s why it was like that).
Anyways Joe User should not be looking in /usr/bin (Should as in most likely will not, not bad Joe user, go to your room. Think about what you just did Kids today are so disrespectful). On the other hand, I tried putting applications:// in the address bar in nautilus and got “applications: is not a valid location. (I’m using XFCE, not Gnome if that matters. I’ll try it in Gnome later). BUT, according to the Gnome guide in nautilus under help, there is Drag and Drop. I’m so confused, I’ll stick to satire.
>There are probably 3 main things that need to change- the UI, dependancy hell, and packaging.
Hmm, actually, there are more.
The fact that the LD loader doesn’t like C++ is a big minus and needs fixing ASAP. Problem is that there are not many hackers working on this, neither has a hard clue how to fix it, as it is a hard problem. So, this is one that really needs to be fixed.
Then, it is the whole issue of NOT breaking binary compatibility on each Linux kernel version for the drivers. This is _unacceptable_ for companies who write closed source drivers for your system. So, you will need to modify the Linux kernel to make sure that it can easily install new drivers, unload others, and keep compatibility for many years to come. That means, that you _might_ have to fork the Linux kernel (however that would be a very “soft” forking, as you would still send back your fixes to the main kernel tree, and you would still populate yours with their new stuff).
Adding a few good file system additions, changing the policy for the drivers etc etc, changing the loader, optimizing or even usign the freebsd glibc instead of this terrible GNU glibc, will make you lose binary compatibility with the rest of the distros, and it will require you maintain large and DIFFICULT chunks of code, all by your team. Remember: This is so tough because we are talking on creating a new OS, a new platform. Not yet another distro where we are throwing stuff in it.
And then, you will need to optimize and change X to be user friendly and then do the UI and stuff. And you will also need to take care the filesystem (I would recommend XFS with full attribute support and live queries as in BeOS). And you will need to work on different parts of the fs hieriarchy as well…
As you can see, this is not trivial. It is not a “let’s fix the obvious things that we don’t like today”. Remember: it has to be done right the FIRST time. Because if you do something wrong, a bad design decision in vesrion 1.0, and then you want to fix it in version 2.0 and that might change your architecture or break older applications, this would be a NO-GO, because user-oriented OSes, are known for being compatible for years. If we want to break compatibility with ourselves every 6 months, you better stay with your current Linux distro and forget this whole project.
Now, who’s got the guts to do all that? 😉
>Sometimes breaking compatibility will break more than you bargain for.
You don’t understand. /usr/bin HAS to stay there, otherwise you lose POSIX compatibility! Nobody said to erase the /usr/bin. But you DO hide it. System tools will be in the $PATH, while gui apps will be elsewhere. But the /usr/bin all its sister dirs will be there, because no matter what, POSIX compatibility SHOULD BE maintained AT ALL costs!
>You got to be kidding.
I hesitate to comment again.
Please explain why you think I’m joking or how your method would differ and how it would integrate into UNIX. I cannot foresee a Linux without UNIX, except perhaps in the smallest embedded environments, but even PDAs keep most of the filesystem intact.
Perhaps you have stumbled upon some revolutionary new idea to organizing an OS. If so then maybe I just didn’t understand what I read. Again, I appoligize for expressing my opinions.
Eugenia, you responded to my post faster than I could view it!!!
I personally would like to do more research. I guess I’m not seeing the full picture.
For me, all guis are pretty similar. Click. Click. Click. Type. Click. Click. Click. Drag. Click. Click.
I’m not sure the best way to do this. Where’s the best place to look to see everybody’s opinion on guis and DE’s/WM’s? (XP vs OSX vs KDE vs Gnome vs TVWM etc). Otherwise my only contribution to Linux will be telling people I can write funny stories about it.
Did I mention click?
Oh, and you might need to create a new binary format, or maybe an ELF that supports more advanced stuff, like resources.
As you can see, this is real OS design here, we are not talking about a “distro”. We are talking on creating a new modern OS. It just “happens” to be using the Linux kernel. You have to think of it this way, in order to understand how big of a job really is. And you need to decide how you lay out your /etc/ and if you want to be more unix compatible or more Linux compatible in your /etc/rc dirs etc etc. There are a lot of things to be brought back to the drawing board. Take nothing for granded. Everything can be changed if it is needed.
>I have a lot of great ideas for packaging solutions that would eliminate dependancy hell once and for all for Linux, but of course these ideas would only work if developers flocked to it in droves. I’m sure all who read this could come up with similar solutions given even 20 seconds to formulate the entire system.
**sigh** that is so true.
You hit the nail on the head on this point. I try to keep to only installing from APT-RPM or RPMs too but always find something that is only in a source tar ball that I must have
@Eugenia:
I don’t see the ROX approch as hackish. Most Linux programs I have compiled run from with in their source trees without a ‘make install’ so making existing programs live completely within their package directory is no big deal. As I understand it, this is exactly the way applications are done on OSX. Most ROX packages use a script to start them for the sake of first run setup or compile. Most programs that are targeting “FoobarOS” will be dependent on the default support libraries any way. I can see providing programmers with a “porting wizard” to “FoobarOS” that would automate any details of creating a Package including any initialization scripts and bundeled libraries.
>Please explain why you think I’m joking or how your method would differ and how it would integrate into UNIX.
I think we have misunderstood each other. You are talking on integrating your script/hack into the *known* Unix OSes.
Me and a few others are talking about a new Unix-based OS, where these kinds of hacks/scripts won’t be needed, because they would be taken care by the system by default, in the first place.
I think we just started talking on different things here and we start misunderstanding each other. Sorry about that.
> I can see providing programmers with a “porting wizard” to “FoobarOS” that would automate any details of creating a Package including any initialization scripts and bundeled libraries.
Creating a new package for the FoobarOS, would be done via a wizard. It wouldn’t be a command line utility. It ain’t so neither in Windows, Mac or BeOS. And it doesn’t have to be. A wizard/form kind of thing, like in OSX would be great. Stop thinking again with the Linux mindshare of “in order to create a package I go to the command line and I have to do this and this and make sure that this is already there”.
As for porting the app itself, configure/make would STILL work in addition to GUI IDEs/tools. Remember, we are talking about a POSIX system still. It is important that any new OS, does remain POSIX.
ARGH! AppFolders are NOT the way to do this!
OK, let’s take this one step at a time.
1) Yes, Eugenia is right, using applications:/// to edit menus is a bit sucky, being able to edit the menus directly like in Windows would be better. On the other hand, editing stuff using the file manager is exactly what MacOS does, and I don’t hear any bitching about that? How about if we removed the menu entirely and forced you to keep around a nautilus window, would that be better? I don’t think so, but that’s what MacOS does.
2) So anyway. The .desktop spec is fine. No, there’s NO reason to make something XML just for the sake of it, if you actually read the specs you’ll see that it’s very extendable, and much easier to read/edit by hand than an XML based format would be. It gains simplicity and sacrifices…. what? You don’t need to style or transform .desktop files
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?
4) 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. 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.
@NathanO:
“I’m sure all who read this could come up with similar solutions given even 20 seconds to formulate the entire system.”
Yes yes, I’m a pimp, come help us out will you? http://autopackage.org/
@Eugenia:
“The Linux experience needs not only evolution at this point, needs revolution as well. I will bow to the one who’s got the guts to do what Apple did with BSD.”
MacOS X is basically just NeXTStep with a facelift. Interesting a decade ago, but it’s hardly revolutionary. Most of the big fuss in this particular thread seems to be over AppFolders which won’t ever work on Linux and that has nothing to do with it being unix, or having lots of ‘history’, it’s a social thing.
Anyway, I think you have an odd definition of “hack”. The freedesktop.org standards aren’t hacks, they are well thought out solutions to problems which often aren’t obvious until you sit down and talk about them. When you write your RFCs, are you taking into account system admins on large networks? The need for partially sighted people to have high-contrast icons? Yes? No? I’ve said it before and I’ll say it again, making things appear simple is fine, but losing important features because it is simple isn’t fine.