OSNews

"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

> 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.

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?

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)

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"

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

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...

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.

"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.

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.

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.

"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.