Older blog entries for aaronl (starting at number 58)

Mustapha, iain: Ummh, I never forked Gnapster. I don't know where you get the idea. I am implementing this as an official feature. Stop being uninformed.

I've been ranting a lot recently, so here's another one to go along with them.

iain said he wanted to turn Gnapster into a bonobo component.

So I'd like to rant about component systems. Note that when I refer to "Bonobo" I am talking about component systems in general. This particular rant is about software design philosophy, not gnome-bashing.

Component systems blur the boundries of what is one application and what is another. This would be nice if it could be put to good use. But the fact is that the only thing it is good for is bloat. Once an application supports Bonobo or a similar library, it can do anything. As proven by Nautilus, it can browse the web, manage files, play MP3's, view images, launch progams.... I'm not saying that that code could be writen to make them do these things, as is the situation with Emacs, I'm saying that they can do them. By design. So, the application has no clear purpose. Well, except Nautilus. Nautilus' purpose is to do everything. But what about all other applications? Is there no need for new programs?

Let's assume for now that it is a good thing to abolish applications and only write new components. These would all run inside a huge mega-application like Nautilus. Doesn't this defeat the purpose of having a multitasking operating system? What if Nautilus crashes? What if Nautilus' UI doesn't match what would be needed for a specific application? In a classic X window-system display, you can run Gnome applications, KDE applications, Motif applications, etc etc. These might look and/or act a bit differently. But if we were to abandon applications and move to a component-based model, you would need one mega-app for gnome components, one mega-app for KDE components, etc... And then traditional X applications would look out-of-place.

My biggest gripe about component architecture is that I just don't understand when it would ever be needed. What are the shortcomings of a gtk widget in a shared library that Bonobo addresses? Mozilla, XEmacs, and other applications have sucessfully been embedded using GtkWidgets. I can understand why embedding might be nice in some circumstances, but I don't see why everything should become a component rather than a chuck of code in a library that the application using it calls directly.

Bonobo sounds like ActiveX: something that could embed parts of an application in a way that would be inferior to just running the application directly.

Bonobo does not sound like Emacs: A powerful, exstensible application that is oriented to a specific set of jobs. Emacs is for text editing and processing. Emacs cannot browse the web. Sure, you can write code that will let you browse the web in Emacs (and such code has been writen), but this actually has to be implemented inside Emacs. With a component system, your text editor can become a web browser if a component for web browsing is installed on the system. Say, for a real web browser to use. Now, instead of the code being in the web browser, it's in a component that can be used by any application.

I am definetely not anti-functionality, but I can't for the life of me see any reason why I would want to browse the web inside my word processor. It would be a neat hack, but in a realistic sense it is stupid. If I wanted to browse the web, I would lanuch my web browser. I would keep functionality seperated cleanly. So, flexibility is good, but I weigh the pros against the cons of every individual situation. And when there are no pros, the answer is usually very simple to arive at: the flexibility of this particular thing has no purpose, and therefore sucks.

mjs: Are you trying to say that a gnome application takes up less memory or equal memory than an equivilent GTK program? I pointed out long ago that I was never trying to arive at accurate figures.

itp: Suit yourself. I'll use the programs that I want to use. As for your claims that "one extra dependecy" is resonable:

gnome-bin gnome-core gnome-libs-data libgdk-pixbuf2 libgnome32 libgnomesupport0 libgnomeui32 libgnorba27 libgnorbagtk0

...looks like a hell of a lot more than one dependency to me. If it was one library, I might not mind as much. This is not even including the libraries that the Gnome libraries depend on, such as audiofile, esd, etc.

itp: Wow, you really ARE an idiot. Considering the fact that only very few programs on my system use Gnome libraries, shared memory has nothing to do with this at all. It is extremely unlikely that I would run two Gnome apps at one time. Now, you claim that Gnome has advantages?? Consistany of interface? HAHAH! Let's make some completely unrelated applications have exactly the same interface for doing different things! No thanks. I do not care for the ugliness or so-called "features" of gnome-libs. Therefore, I have decided it has no purpose on my system other than trying to convince me to run that crappy desktop environment. And therefore, it must go. Considering the fact that only a few applications on my system use Gnome, this is not such a hard task. I am doing it for my personal convenience and for others who want a gnomeless system. Freedom of choice is a good thing, but the Gnome developers don't seem to think so.

You go develop applications for Gnome and have fun. Unfortunately, many people will not use them. And it will also make you look like an idiot for not seperating your engine code from your sissy desktop Windows 95 emulation. But then again, it is far too late for anyone who has read this to not think you're an idiot or ever have their mind changed, so that shouldn't matter much.

19 Sep 2000 (updated 19 Sep 2000 at 03:35 UTC) »

itp: excuse me? Wait, you work for that company that is trying to blow APT out of the water with a tool that runs only on their desktop environment? And only under X? BWUHAHAHAH. That explains it.

gilbertt: heh

bma: yeah, I would present my rebuttal to this here except we met on IRC today and straightened it out.

Uraeus: BTW, I AM an AbiWord developer. I believe that feedback is very important to the development process and I make a point of reporting even bugs that I might fix. I was disappointed with the current release, and I wanted to make my troubles known. If I hadn't done that, as you pointed out, it would be a lot harder to fix them.

Also, I forked the debian sawfish package today. Due to the maintainer's total lack of clue, I have made my own version that does not link with Gnome. To get it, put in your sources.list:

deb http://vitelus.com/debian unstable main deb-src http://vitelus.com/debian unstable main

Sorry, i386 only at this time.

I sent the patch to jasta, and fortunately it worked fine for him. He applied it to the devel tree and completely rewrote many of the things that I did poorly. Things are going at a great pace and I've been pleased with the level of cooperation from the maintainer and support from the community for this patch.

Major progress on Gnapster work. Two days ago I got one file ported. Yesterday I got all files ported and the application linking. The program even mostly worked. Today it REALLY works -- the biggest deficiency I can find is the lack of an about box (which is being worked on at the moment). It took about 5 minutes to port the patch forward to the current development version of Gnapster. Tomorrow I will send a patch to the maintainer.

I have sucessfully ported Gnapster to Gtk. I have a tree on my system that will link either with or without gnome. The GTK interface need a little polishing and fixing, but it basically works. The whole project was 10 hours of work, split across about 30 hours of Real Life. We expect the changes to go into the next release of Gnapster. However, there are some licensing concerns that will have to be cleared up before then :(

The diff is currently 55k. Tomorrow I will fix the final issues so that popups actually do the function you select, and diaogs also work.

This was a cool little project, and I will probably be doing some long-term work on Gnapster too.

Wonder if the RIAA will come after me.

49 older 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!