25 Oct 2002 pfremy   » (Journeyer)

A few preliminary remarks:

  1. It is a lot more interesting to troll on advogato than anywhere else :-) You get interesting replies.
  2. Being able to post comments to diary entries would be better to discuss the subject.
  3. I am going on holyday so I won't (to my regret) be able to continue this very interesting discussion.

Uraeus:

As for the file access we have something called gnome-vfs in GNOME that does the same thing as kioslaves in KDE.

I am aware that. But why if you have good gnome-vfs support are there _seven scripts_ on the nautilus script page to just handle an archive file ? Why do you need a script to play files in Xine or Xmms ? Or to call a shredder ? Is Gnome-vfs lacking all these features ? I was also referring to the NFS/Samba question. Why isn't Nautilus able to browse samba and NFS shares ? In KDE all these things are provided by the kio_slave library.

The separate theme handling was a mistake, but has now been 99% fixed

I think this mistake is a hint of the way Nautilus was developed: independantely of Gnome. Eazel did not take the time to contribute to Gnome the way it should have been done. They just developed and did not care.

Why isn't it possible to provide a Nautilus view of a folder ? Why isn't it possible for Nautilus to embed a CVS frontend ? Both those things are possible in KDE, and not because someone took care of implementing them specifically. They are available because because a CVS frontend application (Cervisia) and a file manager application (Konqueror) had them. Both applications have used KDE's very simple component system and that's it, all other app have it. Every app shares all its features with the others, without extra-work. That fits the integrated consistent desktop goal.

From what I read, Nautilus is a very monolithic application. Where are the bonobo components ? Isn't that the kind of thing bonobo is supposed to handle ? For every cool feature request, the answer seem to be "sorry but the architecture doesn't allow that currentely".

I think (and correct me if I am wrong) that the reason Nautilus is so monolithic is that:

  1. Gnome's component support was not mature when Nautilus was developed
  2. Nautilus developers did not care. They simply did not fit into the integrated desktop vision. They developed an independant application that would use Gnome but not integrate it.

Please understand that I am not critisicing the current Nautilus. The issues are obviously being adressed. I am criticising the way Eazel created Nautilus.

As for its own icon management [...] if anything you could argue that the functionality was misplaced inside Nautilus or eel instead of being placed in a more core GNOME library.

Indeed. So one application has some feature that the other have not and may be lacking ? This is exactly the opposite of the goal of a desktop such as Gnome or KDE. The projects are not about having good applications, we already have that. The projects are about having consistent integrated applications that communicate with eachother. A side-effect of this goal is the avoidance of code-duplication.

On the other hand this is how we develop new stuff in GNOME. We include them it outer libs or applications and as they mature and prove usefull we migrate them further down in the toolchain.

So this means that some application have feature the other are lacking ? I do not see this as a right way to proceed. If a feature is useful, it should be in a core library so that a maximum number of application use it and provide a consistent interface. You want to avoid code duplication and UI inconstency.

Well a vast majority of the bugs in Nautilus bugzilla are leftovers from the Eazel days.

Ok, forget the bug issue. The interview said nothing about this however.

As for slow, well yes it is slower than windows explorer, but it is faster than Konqueror.....

All I have to say is :-) . But what I was underlining is that Eazel seem to have developed the thing withoug optimising it at all.

You did not oppose my statement about the code being complicated and buggy. I take this as an agreement.

As for most of the future features are things that KDE already have. Yes, some of these features you already have, yet some like the video preview stuff is ugly hacks.

I don't know if they are hack, but there are cool and they are an technological advance for KDE above Gnome. :-)

And there are other things in Nautilus and GNOME where you implemented them after us, SVG support comes to mind as an example.

My point was not to count which feature KDE or Gnome has, but to highlight the fact that KDE applications use core KDE technologies to provide many services in the way that makes them both easy to code and available to all applications. From my experience, Gnome application have tend to do their stuff in each application and not providing enough code/feature sharing.

And before you jump, I understand this is being adressed in Gnome 2.

As for lacking a 'large shared vision', I think you are mistaken. But truly we have had more discussions about these issues in GNOME than you have had in KDE, but I think this is mostly because KDE have almost no power over these issues, you have put yourself in a position where most important design decisions are handed down to you by TrollTech.

This last sentence show how much you ignore the way KDE is being developed. You are simply completely wrong but I do not blame you for that. This is a common misbelief. KDE has full control over its development. It will be hard to convince you but maybe those few facts will bring some hints:

  • There are very few KDE developers that work for Trolltech (or put it differentely, very few Trolltech employee that develop KDE). All the KDE developers that have been employed by Trolltech have almost stopped working on KDE. However, they do work hard to make Qt good. Having a good Qt is good for KDE.

  • All interesting KDE technologies (dcop, KPart, kio_slave, XML-Gui, mimetype handling, KDE's service Trader, arts, ...) are developed completely independately of Trolltech and Qt. Those technologies depend on Qt the way Gnome application depend on glib and no more. Saying that this makes Trolltech control KDE is exactly like saying the glib developers control Gnome.

  • Something that may surprise you is that Trolltech is actually taking ideas from KDE for Qt and not the opposite. Their QSocket code, their QProcess code, their handling of dynamic libraries, their Qt translator, all this has been first seen in KDE and then added into Qt with KDE's experience. As a matter of fact, KDE doesn't use the Qt version of those.

  • Qt and KDE have completely different goals. The goal of Qt is to be a good cross-platform library for application development. KDE's goal is to bring a consistent easy to use desktop on Unix.

  • Qt is GPL. So if the Qt developed by Trolltech doesn't please KDE, KDE could fork it. But Trolltech has always helped KDE getting better, mainly by providing a very good Qt. There has never been any need for forking. But do not think it could not happen. KDE has 'forked' or recreated many tools because they did not suit KDE's need. Qt will be no exception to this.

  • Trolltech has zero influence on the KDE development or KDE releases. Remember they make money by selling non-GPL Qt versions on Windows and Unix platform. KDE is cool for them because it makes free publicity and it serves as a testbed but they have no interest at all in controlling KDE.
I hope this explains why Trolltech has never influenced KDE's design. The opposite is however true, Trolltech has already been working on stuff that only KDE would use. I challenge you or anybody to cite me one single thing that proves that Trolltech is controlling KDE, its architecture or its developers.

However, it is interesting in fact that the large shared vision is not discussed in KDE. It seem to be implictely shared and agreed upon by all the developers. We have far less flames than in Gnome for example. Almost everybody agrees on what is the right thing to do.

pfremy I think your reading of my interview is heavily coloured by your premade opinion. While there are issues in Nautilus as my interview did illustrate your are blowing these issues out of proportion.

Rereading my post, I confess the end of it is getting a bit too far :-). And please, my first name is Philippe.

Hadess

Every file access is done through kio_slaves: in Gnome, every file access is made via gnome-vfs methods (I wrote one for my Rio500, at the time, there are plenty more).

I was not suggesting that Gnome was lacking this feature, I was wondering why it doesn't seem to be available in Nautilus. Why all these extra script ? Why no access to smb and NFS shares ?

The UI of every KDE appliation is controlled through a XML file: Yep, we do that as well, libglade is taking care of it.

The XML-gui stuff provides more than gladeui (last time I checked). It provides default shortcuts for all appliations, it provides a common menu organisation, it provides menu merging for components.

duplicate features of Gnome into Nautilus: hmm, which ones ?

Theme management ? Okey, this is being adressed. As I already said, I am not criticising current Nautilus but the one developed by Eazel.

Opening of gzipped archives ? Component to display files the way Nautilus does ? Those features are either duplicated into Gnome libraries, or missing in Gnome libraries. I don't see the interest of having a cool feature in one application with other Gnome application unable to use it.

in which cases does Nautilus not use the existing framework ?

I was wrong with the mimetype (although I remember having read about Nautilus's mimetype database. And the article raises questions about complicated mimetype handling of Gnome and Nautilus) but what about Bonobo ? Where is the Nautilus Bonobo component ? Can nautilus display a preview of every file that has an application associated with it in Gnome (the way KDE does it in KDE, for example to embed KOffice viewers into Konqueror) ? Or do you need to code specifically every file preview directly in Nautilus ?

Did you look at the code ?

No, but I read what the developers said about it. I cite from the article:

you really need to be two people to maintain Nautilus [...] the new code is also vastly more readable and somewhat better performing than the old code [...] the [sidebar] code was horrible [...] The Icon view is quite integrated with the core Nautilus code at the moment, so it is very hard to do things like this [...] Right now the CVS view has to recreate the whole directory view, which is a pain. It leads to views that don't integrate well with the rest of nautilus (and more often, views that just aren't written) [...] I don't think using the nautilus codebase is such a good idea, as Nautilus has an architecture that is overly complicated for a fileselection dialog [...] The Nautilus views require to much of the Nautilus internal asynchronous machinery, which we don't export (for various reasons) [...] there isn't anyone with concrete plans for fixing the mime system. [...]

Nautilus 1.0 architecture seem to be very monolithic, and the code not efficient. Did _you_ look at the code ?

I use file-roller, which handles much more than just tarballs, and there's also support in gnome-vfs for reading from tarballs.

And you try to convince me that there is no code duplication, when you cite two tools to perform the same action ? Just joking :-), archive handling is no major feature :-) Okay, I was mislead on this topic by the Nautilus script page. I still wonder why you have seven scripts here to perform an action that is part of the gnome core libraries.

Philippe, do a little research before talking. You won't get far on this site (and in the Free Software World) spitting flames. All you're doing is making people in the know laugh at you. Poor sod.

This is a diary entry, not an article, hence less research. I am posting what I think and I am happy to engage discussion and to correct what is wrong. Looking at what Uraeus said on KDE development, I am certainly not the only one that have misinformation. And I am glad to learn, do you suggest I should stay in my ignorance ?

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!