Submitted by “The primary goal of Project Ridley is to cut down on the number of problem libraries that are part of the GNOME platform. We propose to do this by moving functionality into GTK+, wherever it makes sense. These libraries are generally small, undermaintained, and buggy.”
These libraries are generally small, undermaintained, and buggy.
Yeah, let’s put them in the main toolkit!
“Yeah, let’s put them in the main toolkit!”
You obviously miss the point. They ar buggy because they are umaintained but they are used already within several applications
By consolidating the platform into the toolkit, it becomes better maintained and serves the needs of the users who are now linking to several different libs
one of the main reasons i don’t like gnome/gtk is the amount of bloat. most of it beyond a normal user’s control. you certainly get the impression that the KDE dependencies are bit more tamed and controlled. having said that, I still feel that the X dependencies are a mess too.
I have been waiting a long time for that. I normally use KDE. But i sometimes compile gnome apps. But with all these dependencies you are going through hell if you try to compile a new programm. I think this will be a great step forward for gnome/GTK
I’m not convinced there is a lot of difference between the two sets overall. GNOME sticks to the rules about splitting dependency into single function packages, and accepts the overhead that creates, while kde opts for the kdelibs monolith.
I’m excited about this project though, as it will lessen the distinction between a gtk app and a gnome one, and so allow all gtk apps access to the power of gnome (libgnomeprint now, maybe even libgnome-vfs later?), without being tied to it. This is something that’s a lot harder for kde, as it would likely require branching qt for them to regularly add to the toolkit layer.
> while kde opts for the kdelibs monolith
There is no kdelibs monolith. The kdelibs package contains several single libraries. And Qt 4 is also split up into several single libraries.
KDE, as I can see, always provided an uniform environment for developers. Where all the core libs are under the control of the KDE main devel team.
Also, on KDE we can see the reuse of LOTS of components. This way you can have a more apps running, with a smaller memory footprint and a faster response. This kind of thing would be impossible if each developer utilized a diffenrent subset of libraries, each one with overlapping functionalities.
A good example is Kontact and Evolution… Evolution is almost monolithic, while Kontact is highly modular.
I made the switch recently, from Gnome (Ubuntu) to KDE (Kubuntu). And I’m really pleased to see that almost all of my old complains against KDE are gone. The K menu is cleaner, and most applications come whith simpler menus.
I really hope that the Gnome guys keep the good work, and tidy up their environment. As I hope that KDE folks continue their path to more simplicity.
Within the open source community I can’t understand why people always try to compare GNOME and KDE. Actually each DE should have their own path, own philosophy and own vision. They should not be duplicates of each other. Further they can have their own supporters and fans as well. But in some point they can even support each other as the open source community.
On the other hand, why don’t you try to compare GNOME/KDE with MS Windows or OS X. Are we appreciate that they are too matured and we have long way to reach them?
Within the open source community I can’t understand why people always try to compare GNOME and KDE.
And then start to complain because the one seems to follow the other, or the other way around.
Comparing KDE and GNOME is very natural, they are both Free Software/Open Source Desktop Environments, and obviously very similar in many ways. For example, I am a GNOME guy but find the idea behind Plasma for KDE 4, well, Fucking Brilliant! Lets face it, you will have a closer relationship with your brother then with your (distant) cousin, that’s what Windows and MacOSX are to both GNOME and KDE.
They do have different philosophies…
GNOME: simplicity
KDE: eye candy
And they do work together (freedesktop.org)
Both are aiming for better ease of use however, I fail to see how this is a bad thing?
That monolith may represent bad ideology, but like the Linux kernel, it “just works”. It’s easy to install KDE on a system due to the pleasantly small number of distinct packages that are needed. I’ve rarely had the patience to install GNOME due to the massive list of package dependencies..
Assuming its possible to clean up all those little packages and incorporate them into a simple set of monolithic libs, this could be just what GNOME needs.
Because of GNOME libraries though I was able to get a free (OSS) XSLT library for this website I was designing. http://xmlsoft.org/
It also AFAIK made possible the creation of XFCE the ease of porting GNOME applications to windows… despite KDE having the more portable toolkit!!!
I love KDE but that had to be said. KDE is great as long as you are using KDE, but outside of KDE (running kdeinit before running a program in fluxbox is trying)
I think it’s better to have everything in one place, with the same level of maintenance.
This could in turn, bring more people on the platform,and
maybe simplify the package installation for new versions of GNOME to come.
they have to rid of all bloated libraries
like
bonobo UNMAINTAINED
bonoboui UNMAINTAINED
Orbit UNMAINTAINED
gnome-vfs ugly
eel
gal
libgnome
libgnomeui
that’s it
Target Libraries
* libgnome
* libgnomeui
* libgnomeprint22
* libgnomeprintui22
* libglade
* libgnomecanvas
* libegg
* libeel
http://live.gnome.org/ProjectRidley
There are alot more than need to he shoved into it – the gtkHTML should be shoved into GTK as to allow all GTK programmers, not just GNOME ones, to have access to it.
If it means we have a über library, which is a 20mb (compressed/Bzipped), then so be, it, better to have an über library than the nightmare that unfolds when it comes to compiling GNOME from scratch.
“the gtkHTML should be shoved into GTK as to allow all GTK programmers, not just GNOME ones, to have access to it.”
nooooooo, lord, have mercy !!
i don’t want a HTML rendering engine such as this one. guess why most gnome projects needing one are using Gecko instead of gtkhtml ?!
How dare you actually read the proper article/page before commenting! ;o)
But seriously, why are people so lazy and/or incapable of looking for themselves? Isn’t it sad that a move to reduce bloat has been called “more bloat” by some readers?
Human psychology still baffles me …
rehdon
> gal
Gal can be considered dead. New Evolution 2.3.x don’t depend on it anymore and it’s by far the only application I know that uses it.
I think that libgnomeprint/ui should stay on their own because it makes sense to distinguish between printing stuff and normal toolkit.
The other libraries:
* libgnome
* libgnomeui
Ok, move the necessary things and kill off these libs. Also finally get rid of the gnome-config code inside it.
* libglade
* libgnomecanvas
Dunno about libglade myself but yes libgnomecanvas is a valid point. I think there should be a good default canvas inside GTK+ it definately is a good idea.
* libegg
* libeel
Dunno about libeel but libegg does make sense.
Something to talk about is libbonoboui. Move all the good bits away from it and kill that thing off.
“I think that libgnomeprint/ui should stay on their own because it makes sense to distinguish between printing stuff and normal toolkit.”
about printing, don’t forget that now that gtk+ uses cairo, it can generate both graphics on your monitor and … PostScript (for .ps/.pdf ‘screenshots’ and certainly to have better printing)
in better, i mean “looking quite exactly like what is on your screen”
GNOME sticks to the rules about splitting dependency into single function packages, and accepts the overhead that creates, while kde opts for the kdelibs monolith.
From a technical point of view this is not exactly correct, as it’s more a logistics and packaging issue. You don’t have to use all the libraries in kdelibs even if they are conveniently put into one package. And most of the different packages needed for Gnome are not runtime dependencies, making it any less monolithic. The only difference are you need get several packages compared to one, but that’s only logistic. Have you seen the graphical representation of the dependencytree to build Gnome, it’s ridiculous.
From a technical point of view this is not exactly correct, as it’s more a logistics and packaging issue. You don’t have to use all the libraries in kdelibs even if they are conveniently put into one package. And most of the different packages needed for Gnome are not runtime dependencies, making it any less monolithic. The only difference are you need get several packages compared to one, but that’s only logistic. Have you seen the graphical representation of the dependencytree to build Gnome, it’s ridiculous.
Yes, it’s entirely a logistic and packaging issue.
What most people here don’t (want to) understand, is that this project is not meant to diminish the number of libraries for the sake of it, the goal is to remove *problem* libraries. *Problem libraries* are the unmaintained, unmaintainable or useless ones.
This will in no way lessen any supposed bloat. Gtk+ is one of the longest library to compile in Gnome already, and this will only make it worse. You will have more functions in the library.
This is natural evolution of the toolkit.
Ookaze
Thanks to De Icaza and Ximian guys,now GNOME
don’t have a decent Component Object Model because
they have decided to work on mono and get bonobo
to die.
It’s time to rid off all the companies who fly around the project in an unresponsible manner like ximian did.
Hey, how about the rest of us that use GTK+ apps, but don’t want the bloat of Gnome on our systems? I feel like we’re getting squeezed out here.
Hey GTK developers, don’t do this! Keep the Gnome libs seperate from the GTK libs.
Criteria
As Owen said in a recent GTK+ meeting, when looking over the list of APIs that we are discussing here, there are basically three categories:
1. Cross-platform API – things that make sense on Windows / OS X
2. X / freedesktop.org-specific API
3. GNOME-specific API
APIs in category A. are clearly suitable for moving to GTK+, APIs in category B. may or may not be suitable, and things in category C. are better off in a GNOME-specific library. An examples for B. would be a session management API that closely follows XSMP, an example for C would be gnome-vfs. Also note that in some cases an API may in principle be cross-platform, even if the current implementation makes heavy use of platform-specific libraries.
http://live.gnome.org/ProjectRidley
It certainly seems like a rational move, but it’s also easy to see where the “it’s more bloat!” people are coming from. GTK+ 1.x was a lot faster and a lot faster than anything we’ve seen with GTK+ 2.x, and these changes will not help matters on that front. A lot of users just want a more modern GTK+ 1.x (with developer support, obviously).
On the other hand, most GTK+ 2.x applications really require a lot of non-GTK+ libraries as it is (libxml, bonobo, ORBit, etc.), so I personally don’t see this as being any worse than the current situation.
2. X / freedesktop.org-specific API
I would break this out into a separate library too, I’m thinking about sharing it with XFCE since they have their own libs or are creating libs in this area.
very good point….i think
I assume we would be getting a richer GTK that gnome would be making use of, NOT just gnome crammed into gtk which would be crazy. I think maybe if they cut and slice and squeeze just right we will get a SUPERGTK that other apps and windowmanagers will be able to benefit from and not just gnome….
but definately soemthing to keep in mind…
Is it backwards compatible???
As of now there seem to be no plans to break the ABI, so it should be backwards compatible even if called Gtk 3.0.
Should we allocate QString or not ? Well, Qt uses a powerful implicit shared mechanism for strings that allow you not to care at all about such things. Your QString will be managed correctly and you won’t have any segfault or memory leaks. Hey, that’s good technology.
Stable API ? Qt and KDE releases are binary compatible. This means that an application compiled with KDE 3.0 will work without any change with KDE 3.4 . So you can safely update your system. And if the binary releases are compatible, you understand that the API is rock-solid. You can safely develop your application without the need to update it at every new release.
Gui designer ? Gnome has Glade, Qt has QtDesigner. They work exactly the same way, i.e. generate a XML file that is then parsed to generate code. Generators are available for C++ and Python. Note that QtDesigner can import Glade files.
Component framework ? Gnome is developing Bonobo but it is still a pain to use it. KDE has a stable component technology, KPart for native in-process embedding and XPart for out-of-process embedding. KPart is very stable (it is used everywhere in konqueror) and easy to develop with
Good documentation ? You better leave Gtk then! Check the Qt documentation and the KDE documentation and enjoy it. Complete API reference, detailed architecture overview, tutorials, references to standards, everything you could have dreamed of! Who said free software usually lacks documentation ! With Gnome, you are limited to the “Use the source, Luke” solution, which is not very friendly.
AGAIN
Eazel spent $13 million in a file manager!
Well, there is not much more to say about it. Eazel had great plans, a lot of money but in my opinion a very poor Business Plan. They spent their $13 million venture capital in a beautiful file manager, with more than 60 people working on it. Now Eazel is no more but Gnome has a file manager, at the cost of the bankrupt of one company. Cool!
But if we have a look at KDE, we see Konqueror, a very good file manager that can certainly competes with the best browser and file managers available. Konqueror is developed by a team of approximatively 10 people, from which one only (David Faure) is a full time paid developer.
Miguel claims things while KDE produces code.
Miguel is a very good PR guy. He claimed many things. That Ximian(now Novell) would produce an improved version of Gnome. That there would be some bonobo components for Open Office. He had all the attention he could dream of, from the press, from the Free Software community. But when you see the results, you can be disappointed. Bonobo is very heavy, Gnome 3.0 is late, Ximian(now Novell) doesn’t produce an improved version of Gnome, they now sell propietary distro for interconnection with Windows and work on Mono. The OpenOffice/bonobo integration doesn’t look even started nor possible.
On the other side, look at KDE. No big promises, no big press attention, but a desktop that is there, has a stable component technology one year before Gnome, has very good technology that permits developers to now concentrate on applictions, has anti-aliasing, right to left internationalisation, has plenty of good applications. KDE just delivers features while Miguel talks about them. And KDE has never changed its direction, contrary to Ximian/Miguel.
“Stable API ? Qt and KDE releases are binary compatible. This means that an application compiled with KDE 3.0 will work without any change with KDE 3.4 . So you can safely update your system. And if the binary releases are compatible, you understand that the API is rock-solid. You can safely develop your application without the need to update it at every new release.”
It’s not that simple I’m afraid. We at autopackage have researched KDE applications’ portability. Qt 3.0.4 or something broke backwards compatibility. Kdelibs also has some problems. Finally, there’s the deal with different GCC versions. See http://lists.sunsite.dk/cgi-bin/ezmlm-cgi?21:mss:2846:200508:ildjhg… for details.
The Qt3.05 and later incompatibility with previous versions was caused by GCC. You point to the one exception to the rule and it was caused by GCC. Since Qt3.04 and before was normally used on distributions using GCC 2.95 and Qt 3.05 was used on distributions using GCC 3+ I don’t think it is that big a deal.
It isn’t caused by GCC. The ABI break I’m talking about is done by Trolltech themselves: http://lists.trolltech.com/qt-interest/2002-10/msg00950.html
The issue you are talking about is the GCC 2.95 C++ ABI vs 3.0 vs 3.1.1 vs 3.2 vs 3.4. That’s something entirely different.
If the user installs a package and it doesn’t work, then it certainly is a big deal. Right now, GNOME/GTK C applications have more chance of running properly on multiple distributions. Autopackage 1.2 attempts to work around the problem by making it easy for developers to ship packages with two sets of binaries: one with the GCC 3.2 ABI and one with the GCC 3.4 ABI.
Oh good… another DE flame war. 🙁
> Good documentation ? You better leave Gtk then!
GTK+ has rather good documentation. Visit http://www.gtk.org and check out the Documentation heading.
> Gnome 3.0 is late
Late? There has never even been a schedule for Gnome 3.0, so it can’t be late.
> Ximian(now Novell) doesn’t produce an improved
> version of Gnome, they now sell propietary distro
> for interconnection with Windows and work on Mono.
Proprietary? AFAIK, NLD is comprised of free software.
Proprietary? AFAIK, NLD is comprised of free software.
Well, granted it does have a couple bits of proprietary software, the large majority of it is Open Source. I think many people don’t have enough intelligence to differentiate between “costs money” and “proprietary”. Here is a nice, little example:
A hammer costs money, but it most certainly is not proprietary. You can do whatever you want with it, you can even melt it and remold it into something else if you really wanted to.
Adobe Acrobat Reader, on the other hand, is a free download, but you CANNOT do whatever you want to it. It is free of cost, but proprietary.
I didn’t compare two different softwares because it seems to confuse people that F/OSS can be charged for but is not proprietary.
well i think cleaning up gnome is a good thing, better late than never, for simplicitys sake…
but I also like that i can pick and choose pieces and parts of gnome, whereas with KDE I am stuck pretty much with the whole ball of wax…. So if they can clean it up but still allow me to only install the gnome panel, or just nautilus or whichever parts I want then I will be a happy camper. If they become a ball-of-wax then I guess I will just have to fork and make gnome-pieces
Project Ridley will only move functionalities that makes sense in the toolkit, not the whole kitchen sink.
Anyway, many distributions are already splitting the KDE packages in smaller ones so I wouldn’t be surprised if GNOME/GTK+ gets the same treatement if it ever becomes too ‘big’. It’s still a good compromise if the merged libs get better/faster/more stable because of the increased maintenance.
On the other hand, why don’t you try to compare GNOME/KDE with MS Windows or OS X. Are we appreciate that they are too matured and we have long way to reach them?
At least Gnome allready have much better usability than windows XP, so its not much point in comparing, at least not if the goal of the comparison is to see how Gnome can be improved. It still have some way to go to beat MacOS-X in this respect. T
he main difference when you compare MacOS-X and projects like Gnome and KDE is that these free projects seam to have far too many developers that want to create a good user interface to UNIX.
To most users this is irrellevant. They just want a system that works and get their job done. Far too often Unix concepts are mapped to concepts of everyday life, instead of map consepts of everyday life onto Unix. Ordinary users couldn’t care less if it is UNIX or not as long as it works.
One example:
Look at the folder structure that is visible to ordinary users in the MacOS-X gui. It just shows the parts that ordinary office users needs. Compare that to Gnome or KDE that shows /etc, /proc, /root, /lib, /dev,
/bin, /boot,… none of which is of any use unless you are a developer or sysadmin.
However, if you suggest that these should be hidden by default even on a KDE or Gnome usability mailing list you get lots and lots of replies from developers that wants to keep them. It is like they don’t think it is unix if you can’t see these folders from the GUI, or is it that they feel threatened in their guruhood if ordinary users actually would find their product easy to use.
So, who will be the first in this forum to say that /etc really need to be visible by default?
“However, if you suggest that these should be hidden by default even on a KDE or Gnome usability mailing list you get lots and lots of replies from developers that wants to keep them.”
How about lots of replies from users who want to keep them?
How about lots of replies from users who want to keep them?
The poeple that read Gnome or KDE usability lists is not exactly a good example of ordinary users or potential users, so it doesn’t really matter how many
answers I get from that crowd. Why they want it would be more interesting. Usually it is some kind of sysadmin task they want to do.
If you select some some typical office workers lets say accountants that would make up a potential Gnome user at random in the population I can assure you that very few of them will know what’s in /etc in the first place. So getting letters from them saying they need to accessing /etc, /dev,… is not very likely.
If they are knowledgable enough to actuall have any use of what they see in /etc or any of the other seldom visited folders, they probably are knowledgable enough to turn on “Show hidden files” in Nautilus
Right now, I am counting the accesses to /etc, /dev, /proc,.. using Gnome. After a month the count is still at zero, and I do work with software development, and manages the system for a couple of other users. I wonder what e.g. a secretary do that would require him to look at it more often.
Note, I’m not saying that users don’t need the information in these folders, I’m saying we need to create other ways to deliver that information. Just showing the folder is not good enough. E.g. Applications in Gnome are not normally started by browsing to the /bin, /usr/bin, /usr/local/bin folder and double click on them. They are started from the Gnome menu. The things in /etc should probably be in some sort of settings menu.
Besides, there is always a restistance to try something new and somtimes users oppose new things even though they might be good for them, especially if they havn’t tried them out.
In this case this is very easy to try out. To hide a folder or file just list it in a file named .hidden in /. The folders can be made visible again by selecting “Show hidden files” in the Nautilus View menu.
Unfortunately the .hidden listing doesn’t work for file dialogs where hiding of seldomly used folders probably would have much more effect than in Nautilus. The effect would naturally be faster navigation to things that is used more frequently.
Now, lets for a minute assume that users really need to get into /etc, /bin, /lib… How would they know what they contain /etc, /bin/, /lib are unix concepts. If you ask a relative that does not work with Unix for an appropriat name for a folder containing files for controlling the system behavior, I am quite confident that he would never suggest the name /etc. He would chose something like “Settings” if your relative lived in Sweden he would say “Inställningar” so even if you somehow could motivate these folders to be visible they still have the problem of being unix concepts unknown to most potential users.
Gnome starts in home, and doesn’t let you go up directories normally from there in the file open dialog or in nautilus. Gnome has a sidebar that shows 2 locations normally (at least here, I am using the home as desktop option, so the default may vary) Home, and Filesystem. Filesystem does indeed give you access to the unix filesystem. But a normal user likely has no need to ever go into it, and its kept seperate from the normal locations you’re likely to go.
So basically its exactly like OS X, you won’t normally go outside of home, but its not exactly hidden either.
So basically its exactly like OS X, you won’t normally go outside of home, but its not exactly hidden either.
This is not exactly true. Let me give you an example.
In most of the jobs I have had in my life, I have worked together with other people to reach some common goal. That means that I often have needed to share information with my collegues.
In your scenario with users, where users never leave their home folder how is such shared information handled?
If the coworkers trust each other their home folders could be group readable/writable. Another alternative would be to create a project folder somewhere else in the file syatem and let the group members have access to it. In both cases I would need to browse outside my home folder.
The “the user lives inside his home folder truth” is yet another example of Unix think that doesn’t correspond well to the real world of users.
In your scenario with users, where users never leave their home folder how is such shared information handled?
Easy – have it show up in Gtk’s bookmarks list, just like the ‘Home’, ‘Desktop’, and ‘Filesystem’ links do. For that matter, I think things like gnome-vfs and USB filesystems show up there too…
No different really to having a shared document folder in Windows.
“In your scenario with users, where users never leave their home folder how is such shared information handled?”
Easy – have it show up in Gtk’s bookmarks list, just like the ‘Home’, ‘Desktop’, and ‘Filesystem’ links do. For that matter, I think things like gnome-vfs and USB filesystems show up there too…
No different really to having a shared document folder in Windows.
That’s true. Even so, windows hides files that is not necessary for the every day use of most users and many of the settings you se in /etc of UNIX is hidden in the windows registry. Yet windows users and MacOS-X users seam to manage remarkedly well without seeing all folders and all registry informaiton in case they should accidentaly browse to the / folder or C:.
So would Gnome or KDE users.
In fact, it is never a good idea to present the user with information he doesn’t need. Selecting a file in a file dialog containig say 20 folders taks much more time than selecting it in a dialog containing six or so folders. If the user have to scroll to select the needed folder the time increases significantly. Not only does it take longer time. If we present information/folders whos function is unclear to the user, it reduces the users sense of control over the system.
Even if the sysadmin really really needs to go to /etc or /dev once or twice a year that doesn’t make up for the time lost by his users, at least if there are more users than sysadmins, as generally is the case in most companies.
You also have to take into account that some user may not know how to make shortcuts, and file requires more system resources than just mounting a file. Why make it more complicated than it need to be.
Again, most users don’t care much for UNIX other than as a solid platform for their work. To be successful in delivering usable systems developers need to think in terms of users needs and see the system through the eyes of its intended users, not through a 30+ years old OS paradigm where many things look like they do today, because it wasn’t technically possible to do it better at the time.
Apple have realized this, there no reason why Gnome, KDE and other free desktop developer teams could not do the same.
In general I agree with what you are saying. As a sys admin who administers 300 user-desktops(LTSP) who have very little computer exerience in general and virtually none in linux one of my foremost tasks is hiding the underlying complexity of the system from the users.
I think much of what you are pointing out are ‘legacy’ issues from earlier generations of linux software. Below I will point out a couple of the historical aspects of this legacy….
Older versions of the adobe acrobat routinely took the mozilla cache name for the PDF file one opened in it and when one tried to save the PDF(eg. after downloading) it was either saved in the mozilla cache directory or in /tmp. This was a nightmare- because a) no human can decipher mozilla cache names and b) anything saved in the /tmp folder is fair game to be erased at any moment in time. Users were forced to navigate through the entire file system to find their own home directories-given that they noticed that the default was not their home directories.
It was not unitl very recent that their was any kind of reliable menu system for desktop applications. And although it is not perfect it is far, far better than it was. Previously one had to have access to /usr/bin and /usr/local/bin because the vast majority of desktop applicatons would simply not show up in the menu structures. There was no such things as .desktop files (which both KDE and GNOME use-as well as all other f.d.o compliant window managers). There also were no icons for the vast majority of programs. Paradoxically it was also impossible to launch an exectuable program from the file manager-so at one you needed access to these directories from the file manager but you need to drop to the command line to actually execute said program.
In the latest incarnations of GNOME the file manager now has no problem executing binaries-which is IMHO is quite problematic eg. samba share are routinely mounted with the executable bit which causes nautilus to want to execute word documents instead of opening them via their mime type associated application. So now where we actually have a pretty good menu system we are no longer as dependent upon the file manager to find out which programs are available. And I wish that GNOME would give us sys admins the ability to turn of arbitrary binary execution inside nautilus….
Most applications which are not strictly desktop applications store their configuration files in /etc. The danager of accessing such files from the user desktop is mitigated to some extent that users have no right priveledges and cannot delete or create files in system directories. It is only very recently that GNOME has provided any kind of access to fairly simple admin tasks which users must be able to do in the absence of a sys admin( I always loved it when I would recieve warning messages in windows that I needed to get such information from my sys admin- I looked around in my apartment and no one else was there
)
Yet the vast majority of programs in linux still offer no user friendly way of configuring them requiring one to manually edit their config files and parse their obscure syntax. Of course some distributions have designed administration software to ease this process but this was distro specific and this in turn multiplied the the complexity involved administering such programs due to the fact that the knowledge base which developed was always fractured according to the distro in use precluding the development of universally usable documentation and FAQ’s.
This ‘legacy’ issue is still very much present today and is not likely to change anytime soon but linux has reached the point where if properly administered by a sys admin the user has no need to configure these non-desktop applications and actually no longer has any real need to use the command line. And this remains a conentious issue-the real power of linux is on the command line and this will likely always be the case-KDE has made great strides in trying to bring this command-line power to the desktop but this has resulted in an explosion of preferences which is a noobs worst enemy(eg. the click on something-something changes, they are not sure what it was that changed, or what effect it had, and cannot remeber what it was that they changed or how to find that unknown preference again to change it back)
So my answer to your insistence on hiding access to the underlying file system boils down to a series of questions:
a) have our menu systems matured to the point that we no longer need to execute files directly from the file system ?
b) are we providing GUI administration and configuration of system services sufficently that we no longer routinely need access to the command line and routinely need to edit configuration files ?
c) are our applications intelligent enough to respect the invisibile boundaries of our home directories ?
IMO we are rapidly progressing on each of these questions-once we are able to unequivocally answer yes to each of these questions there should be extremely little resistance to hiding access to the file system and its associated complexity from users….
So my answer to your insistence on hiding access to the underlying file system boils down to a series of questions:
a) have our menu systems matured to the point that we no longer need to execute files directly from the file system ?
What’s missing is a menu editor, but that is going to be addressed by GNOME 2.12. BTW, If you want GUI menuediting tool for current GNOME versions you could install Simple Menu Editor for GNOME (SMEG).
Even without full menuediting capabilities in standard GNOME you can always create application starters that you can put in the panel or on the desktop.
I admit that the mechanism for creating application starters is a bit braindead at the moment. When browsing for a command to execute the filedialog should have shortcuts to the places in your filesystem that is in your path (hidden or not).
The line where you enter the command name should also be able to do command line completion with completion targets selected from the set of all executable files in your path.
b) are we providing GUI administration and configuration of system services sufficently that we no longer routinely need access to the command line and routinely need to edit configuration files ?
What I’m suggesting is not to make /etc et al inaccessible to the users and the sysadmin, what I’m suggesting is to make them hidden just like if they were UNIX dot files. This means that a sysadmin that frequently need to configure legacy programs that have no good GUI config tool, could easily create a shortcut to /etc or whatever hidden place he often needs to visit, just like he could with any normal UNIX hidden dot directory.
c) are our applications intelligent enough to respect the invisibile boundaries of our home directories ?
In most cases, ordinary users have not permissions to do much outside of their home directory. This have been the case since UNIX saw the light of day. Programs that doesn’t respect this should considered broken and fixed.
IMO we are rapidly progressing on each of these questions-once we are able to unequivocally answer yes to each of these questions there should be extremely little resistance to hiding access to the file system and its associated complexity from users….
I would say that time is now. I have hidden /bin, /boot, /dev, /etc, /lib, /lost+found, /opt, /proc, /root, /sbin, /selinux, /srv, /tftpboot /usr and it have been very few occations if any where I have had to turn on “Show hidden files” to se them. Over the last month I have tried to count when that happens. So far that count is still at zero.
Unfortunately the current .hidden mechanism in Gnome doesn’t hide the hidden folders in file dialogs. This is unfortunate as this is where this hide feature would have been most useful as it would have prevented the need for scrolling in many cases. This is something I hope they address in gtk+ 3.0, even if they should decide not to hide /etc et al by default.
Other improvements that could be make the file hiding mechanism in Gnome is to make it user sensitive. That way folders could be hidden on a need to know basis. E.g. a sysadmin or a developer may opt to see /etc if they want without having it disturb other userss that have no need for it.
BTW, there is one more directory that really needs to be hidden by default, and that is the Desktop folder.
Not that one more folder in the users home directories is that annoying. The problem is instead that of consitency.
In the GNOME spatial way of looking at things files and folders should only be visible in one place. By having the contents of that folder show up both on the actual visible desktop and in the Desktop folder users may be led to believe that they have two copies of the the files residing in the desktop.
If the user removes what he think is a duplicate he looses the file. To make things worse, the Desktop is not referred to as “Desktop” in the Places meny of internationalized versions of Gnome. This gives the non english speaking user even less clue that he should not delete “Desktop” in his home directory.
MHO the only visible files in the home directory should be files and folders created by the user himself.
BTW: The next version of KDE elegantly addresses the myth that all user activity takes place in the home folder and that the user never needs see the work of their collegues. It introduces a homes:/ location where users that shares their home folder is listed by their real name. This is a really good example of how UNIX-think have been avoided.
See http://photos23.flickr.com/28584559_43e3879244_o.png
I wish Gnome could follow.
Isn’t this basically what I’ve been saying? An ordinary user will likely never have to go into the file system location. The way the abstraction of the underlying system is handled everything is available through autogenerated entries provided in the places menu and the items contained therein. The user IS going outside of their home, but its seamless for them, and they likely never realize it. I don’t see what hiding everything does except make it harder to get under the hood when you want to. You talk about KDE’s new shares system, didn’t I already mention that Gnome already does this?
By the way, Gnome hides hidden files in the file open/save dialogs by default. Unhiding them is a menu option. I’m not sure what dialog you’re talking about.
Personally I feel that gnome should by default use the home as desktop option. But many people don’t keep their home directory clean enough for this to be feasable.
You might not have a bad idea about hiding files that aren’t specifically created by the user, but this would have to be a fdo project, as it isn’t just gnome that makes a Desktop folder, or that makes a unhidden folder for itself in home. (GNUstep for one), and these would all have to be auto-added to the .hidden file for it to work.
“So, who will be the first in this forum to say that /etc really need to be visible by default?”
When I start up gnome there is an icon on the desktop called ‘home’. When I click on that I get my home directory.
To see the unix filesystem, I have to click the computer icon and then click on ‘filesystem’.
This seems a nice compromise to me, as it leads to user to their home directory, but still allows you to browse from / if you want to.
If I open gedit and hit save, it prompts me to save either in my home directory or the desktop. Again, I could browse the / filesystem from there, but it’s an extra step.
My point (if I actually have one
is that I never see any of the unix filesystem in Gnome unless I go out of my way see it.
Ooops. I hit refresh and this is almost exactly the same comment as ‘Best’ made. Still, no harm in corroberating.
Whenever I install some new GTK component because of undefined symbols, it is an adventure. At some point (very late at night), nothing works anymore. What starts as unability to compile because of 1 undefined symbol becomes a set of mutually incompatible libraries that has to be fixed by deleting and renaming stuff, etc.
The problem with GTK is not just bloat, but ignorance and total disregard for backwards compatibility. It seems that they target some new shiny distribution (Fedora) and forget about all the 100s of distributions out there that still need to have GTK programs compiled and working. We can’t expect the software packagers to provide compiled versions for every minor incompatible version of GTK. I hate GTK.
If this results in more manageable development for programmers, this will be very very good. If this allows for better speeds, albeit with more memory usage, I think this will be a very good thing. The better maintenance already means a better product though.
So long as this is done correctly, and we end up with something like Qt+kdelibs (ie, two libs that provide gnome and non-gnome functionality – which is what I read as the goal) then this wont be bad for anyone imo.
Everyone complains about how bad GNOME is to maintain, Slack even dropped gnome all together because its simply not manageable. This is certainly bad press for GNOME, so to avoid any more repeats can’t hurt.
I’m happy this is finally being done now, should have been done during the GTK2.x development all that time ago, but I suppose late is better than never.
Remote drives that have been mounted show up on the desktop, and in the Places menu. Shared folders can also show up in a similar fashion directly on the desktop. And sharing something is now typically as easy as simply selecting the ‘share’ option in the menu.
Essentially while they are leaving the home directory, the underlying system is hidden from them.
Unification ease maintenance and reference – no doubt. Will be more interesting if that make GTK and Gnome applications feel faster, as fast as GTK/Gnome 1.x.
I feel that Gnome is the future of GNU/Linux on the desktop due to the GNU GPL’d nature of Qt. If the desktops wish to compete on an equal footing then I should be able to develop a native destkop application and not have it under a set liscense, not even Microsoft does this.
I am a long time KDE user, I am still using KDE 3.3.0, and plan to upgrade to 3.4.2 or 3.5, when it is released. I like KDE’s vibrant colors, and because there dosn’t seem to be a theme that duplicates this on Gnome; I will not use it.
Cleanliness is next to Godliness I always say.