Author: admin

You can find some photos of the Evolution hackers (and contributors) at GUADEC this year here.

ps. Veerapuram Varadhan made these photos

Jow dudes … there’s no eog maintainer. I decided to implement the filesystem notification TODO. I created a bug for it with a proposed (first take) patch here.

Btw. I’m not promising to start maintaining it :p. Just wondering who to ask for commit approval?!

Hey Hubert, does that mean that with the Nokia 770 and this piece of software you mentioned, we have some building-components for a TomTom replacement?

Hey Federico, where do I apply to become one such superhero? :-)

No really. I agree with your statement. We do need more superheroes who for example decide to start building a programming environment (and btw. many other extremely important desktop components being used today).

But other than only the superheroes, we’ll also need the 3th party software solution providers. Most companies already have their software building partners. They aren’t going to change any of their infrastructure if their current software builder wont support it professionally. That would just be way to much of a risk for them.

And yeah for getting lots of specific things done, those superheroes are great individuals and I’m extremely grateful for their contributions to the softwares which I use every day. I’m even building my career using and learning from many of the components build by those superheroes. I thank you guys!

But in reality we still have two incompatible desktop development platforms. And it’s not helping acceptation of our technology in the large, small and middle sized businesses that don’t want to both employ a lot computer scientists and give them KDE and GNOME desktop development training.

Yet it’s (imho) precisely that what is very important to achieve Jeff Waughs 10×10 idea. Are the (in comparison with the Microsoft world) few GNOME and KDE developers going to support all the desktop software in this world? That would be insane! That’s not being realistic about the situation.

So yes, go superheroes! But we also need to start agreeing on specifics and seeing our very own problems. Our opensource and free software development models have flaws. And imho we need to address them today and now. Else I fear that our nice platforms will eventually become obsoleted.

Hey Christian, about Galago, (you already know about this but) I prepared the beginnings of the Python language binding and am planning to integrate Gossip with this (but the Gossip developers are of course welcome to be ahead of me). I hope all instant messengers will consider checking out this Galago as I’m foreseeing your framework to be used as one of the (many necessary) key elements to make my dream about Utopia come true. Don’t underestimate the importance of your framework. I do believe in it.

And let those people who believe we should talk to their whatever instant messenger client directly, think what they want. Do they really believe we (at Evolution, as I’m a contributor) want to talk to every single messenger available using a huge amount of EPlugins that are all to be configured by the end-user? Galago is the way to go! And we do want presence notification support in Evolution. Really, we do.

I hope the KDE messengers will also be interested. Perhaps even the Win32 ones as for example Evolution is coming to your Windows systems sooner or later. Let’s show the world that we do can play nice and all work together. Galago might be one of those nice framework components to achieve this goal.

I just wished an organisation (like fdo or whatever) would have persuaded the other free software developers to start supporting a framework like Galago. What if they would have, after consideration by for example an elected board, steered the developers of messengers to actually start integrating with this technology? Wouldn’t that just work better than this anarchic mess? I do understand that we, free software developers, don’t want to listen to leadership or steering committees. But lets face it people, we are becoming a group of insignificant childish anarchists if we don’t.

Oh yeah, lets all start looking in our own directions and be ignorant to each others technologies and infrastructure. Lets make this stupid situation worse and play the game with nothing but our egos. That isn’t going to get us closer to our goals! That won’t make it more easy for the salesmen to one day say: “Hey it doesn’t matter whether you, the customer, runs KDE or GNOME. We can develop using our way and our employees and that will just work seamlessly on both major platforms”. In stead of having to ask the customer: “Do you run GNOME or KDE”, and depending on the answer tell the customer: “Oh I’m sorry, we don’t have developers for that platform, we can’t help you”.

In fact is this “ego thing” making the entire opensource and free software desktop community (me included) look insignificant. No really I’m serious about that! For people who don’t know how most GNOME and KDE developers think, please note that most developers don’t want this at all. When asked (and I do ask the others frequently) most think working together professionally is very important. And those who don’t can probably be easily convinced with some beer at meetings like GUADEC.

So what are we waiting for? The holy grail of the free desktop? Time? Lets go get some beer!

With this blog-entry I’m probably about to make one of my major mistakes in my career. I’m probably going to make a lot people pissed about this. And that’s okay. A blog is about sharing your opinion no? This is my opinion. Enjoy it.

Last night, I dreamt about Utopia. I dreamt that some day I would copy-paste a part of a video to my E-mail. And while I was typing it, my E-mail client was playing what I’ve just copy-pasted. I dreamt that the video wasn’t transferred from the clipboard-owner to my xserver and back to the clipboard-requester. You see, my xserver runs remote! Whereas both the clipboard-owner and requester run on the same machine. In my dream, the copy-paste was a local transfer of clipboard-data between two processes sharing the same memory, kernel and CPU. In fact I even dreamt that the process originally owning the video-data was the one playing it on the canvas of my E-mail client during the time I was typing the E-mail. And that only after I decided to actually send the E-mail, the data got transferred.

I dreamt that after that copy-paste operation, I copied the video-fragment from my E-mail editor to my instant messaging application. I wanted to show my friend what I was about to E-mail to the recipients of the E-mail. I copy-pasted it with some marked up text and it just got pasted perfectly into the messenger window. And my friend really received it just like how I wanted him to receive it. And his messenger client started playing the video while it was getting transferred. And our chat wasn’t blocked.

I dreamt that during the video-transfer I was chatting in combination with instant video conferencing. I dreamt about integration of GStreamer with X11’s clipboard. I dreamt about applications really working together to achieve very typical and common desktop usage. I dreamt that there wasn’t any difference between an application that has it’s name starting with a K and an application that has it’s name starting with a G. For the end-users it just didn’t matter at all! My instant messenger was a K-one. And my E-mail client was .. whatever .. Evolution.

I dreamt that all configuration information was shared using a common system. And as the end-user of my system, I never ever cared about this configuration. At my company our administrators took care of all the configuration stuff from their seat. And both applications that have their names starting with a K and the ones with a G just worked. You know like .. they just worked! And it just didn’t matter, for the administrator, how the configuration management of those applications is done.

Using some tool they decided about company-wide configuration options. When they decided to change one, not a single user had to restart any of the applications. The configuration-change was fully event-based for the applications.

And everything just worked together with my personal data assistant, with my cellphone, with my Nokia 770 or whatever version of the device I was dreaming about.

But then I woke up. I realized there isn’t any organisation trying to persuade free software developers to use some standardisation nor to decide on important shared desktop components. Oh you have freedesktop.org. But when asked they just say: “Hey, how!! We don’t do standardisation! We just give free software developers a forum to start flaming^H^H^H^H^H^H discussions about standardizations!”.

And I realized there’s a massive amount of political bullshit about technologies in the free software world. I realized that stuff like, integrating the X11 clipboard with a technology-library like GStreamer is probably a typical “over my dead body” thing for a huge amount of free software developers in our community. I realized that the current components for storing configuration data just aren’t shared between the KDE and GNOME platform. And that getting there is politically-wise so damned hard. You just couldn’t believe it. I’m serious! Can you imagine that this little component causes “over my dead body”-type reactions on mailinglists? It does. Again, I’m serious.

Yet during GUADEC some Novell people tried to tell us: “Jow dudes! Stop doing infrastructure-work. Start finishing real applications, we have good infrastructure already!”.

I’m just … not sure about that. Our infrastructure lacks a lot integration possibilities. Like infrastructure for integration between KDE and GNOME applications. Our basic infrastructure often isn’t consistent between the KDE and GNOME developer platforms. There’s progress! I agree with that statement. Like the fact that GStreamer might become a shared multimedia library for both. Or like the fact that D-BUS appears to be liked by both worlds. That’s good. I’m thrilled about it (I’m being honest)! But I’d share your opinion if you say that we need more like this. I don’t think we already have a kick-ass developer platform. We don’t.

For a person who has a huge amount of free-time to learn about all the quirks of our platforms, we have more or less two platforms that are almost good enough. They can’t yet work together. But that’s okay — no it’s not!! –. I don’t think a lot software houses will really already like our developer platform. Or will like the fact that they’ll have to choose between letting the name of the application start with a K or a G. You see, that letter isn’t the real problem…

The real problem is the fact that it will have a great impact on their development model. On the type of persons to employ. On the libraries being used. On the many incompatibilities with whatever distribution ships with the other major desktop platform as default. Are we really so naive to believe that such software-building companies will let their customers change the major default setting of a distribution that has expensive support? — Just to give one example why not to do this —

How is a salesman going to sell (custom) Linux desktop software? Does he actually have to ask the customer: “Do you run KDE or GNOME”. And depending on that answer tell the customer: “Oh I’m sorry, we don’t have developers for that platform, we can’t help you”. Has this free software community ever professionally thought about the impact of that stupid little question? Have we ever professionally thought about that this might be the thing that is holding back wide adoption of the free desktop platform? Have we ever considered really talking with each-other about this? Not just giving one K-developer some beer at GUADEC and persuading him to adapt his kick-ass K-infrastructure. I mean, really talking. Really getting somewhere. Really making those important decisions. Nevertheless I agree that inviting them is a very, very very very good idea and nobel thing to do. I’m not saying it wont change stuff. I’m saying that I fear that it’s not enough.

For those people who are planning to respond: “Hey moron, in stead of whining you should start developing and fixing what you hate so much”: I am one of the persons who is at this moment spending a huge amount of his free time on the architecture and implementation of DConf. Thank you, come again.

Evolution hacking

I’ve been trying to improve the ENameSelectorEntry widget of Evolution. It’s that widget that you can find next to the To: and Cc: button in your E-mail composer (and many other places). The thing with it is (or was) that when you removed a comma-character, it got a little confused about what you’re trying to delete. So coming up in some next release of Evolution: an improved name-selector widget!

I also managed to adjust the Makefile.am’s of evolution-data-server so that it will load in gnome-build (and Anjuta 2.0). Screenshots here, here and here.

Cheerleading Evolution (was: Hacking Evolution)

IMHO does the current Evolution team need more contributors. I’m serious! :p. There’s a huge amount of great ideas. Like the desire to introduce gtkmozembed as HTML editor component and stuff like that. The current “employed-by-Novell” Evolution team has to support and maintain so much that there’s little place for innovation and new idea’s. More contributors means more innovations. Evolutions needs that. Other examples: The concept of integrating presence notification of instant messengers and video conferencing with Evolution using Galago. There’s also a bounty on that one. Check out the go-evolution wiki if you’re interested. Note that this wiki-with-information will grow as time comes.

The Evolution code just looks huge. In reality it’s rather easy to join the development. Also checkout the information about EPlugins.

mmap-love in Gtk+

People who’ve seen this talk at GUADEC know why. There’s a bug about optimizing Gdk/Gtk+ by replacing fread stuff with mmap.

Debian Release party in Leuven (Belgium)

Little note for the Belgian (and Dutch) readers of my blog:

From: yalu < ...>
To: members at l2u dot iguana dot be
Subject: [L2U] [be.comp.os.linux] Debian Release party
> Hoi,
>
> Vermits Debian eindelijk tot een release gekomen is, vonden "we" (dat
> wil zeggen, p2 en mezelf) het een goed idee om daar een feestje voor op
> te zetten. Iedereen die zin heeft, is uitgenodigd (inclusief mensen die
> zelf geen Debian gebruiken, maar *niet* als het is om andere
> distributies of besturingssystemen aan te prijzen ;-)
>
> Wanneer: Vrijdag 10/6, 21u00
> Waar: Leuven, in caf� Domus
>
> Als je niet weet hoe of waar je de Domus kunt vinden:
>
> * Ga naar het station in Leuven
> * Verlaat het station langs de voorkant en loop de bondgenotenlaan af
>   tot op het fochplein.
> * Ga links de tiensestraat in; een paar 100 meter verder zie je caf�
>   Domus op je rechterkant.
>
> Voel je vrij om dit bericht door te sturen naar andere ge�nteresseerden...

Done, here. Same as for the python library: I don’t know whether everthing is 100% in place. And again I used existing samples to get it working.

Note that both (python’s codegen and gapi) are guilty of requiring the developer to mutilate the configure.ac file.

I created python bindings for that asyncworker library. You can check it out here. Note that it does need some more love from an elite python hacker :-). I’m not a python hacker myself, so I had to learn from other libraries to get this binding correctly build.

It’s possible that I’ll do other such bindings like a C# one (since it’s fully GObject-style, this shouldn’t be hard to do). Meanwhile I kindly invite people to go ahead and get their bindings working in the subdirectory bindings. If you do, please leave it disabled from the build in the configure.ac (so like how the python-binding is configured a.t.m.). Most language-bindings (like a python-GObject binding) can be generated. So most of the times you don’t need to worry to much about API stability.

I completed some documentation about AsyncWorker, I renamed the OAsyncWorkerItem to OAsyncWorkerTask, added support for the sched_setscheduler stuff and did some more fixes.

You can find the documentation online here. You can, of course, also build the documentation yourself (–enable-gtk-doc).

I’m planning to do some sort of first release soon.

AsyncWorker is a library for doing asynchrone work queues in a GLib-style.

It makes it easy to queue worker functions and to launch a callback when work is finished, removed or cancelled (so that you can cleanup resources). It allows you to handle events like when a task got finished, cancelled or removed. Checkout an example here (note that it doesn’t to anything useful except showing how this stuff works).

It’s useful for applications like E-mail clients (who want to create a queue for for example retrieving E-mails and header-lists from a E-mail store like IMAP or POP3). Or for applications that do some sort of spooling or queue actions.

In case you are using a GMainLoop (like a Gtk+ userinterface mainloop), there’s support for cancellation of tasks. You can insert cancellation points in the body of your tasks. When such a task got cancelled by another context (for example by a userinterface event), the task will be aborted at the next cancellation point.

You don’t need to start or stop the queue. It will handle all that for you. By adding a task to the queue, it’ll make sure the task gets processed in a near future. You can also assign a priority to each task. Tasks with a high priority will get processed before tasks with a lower priority. Note, however, that running tasks can only be preempted at cancellation points. Also note that adding a new task, with a high priority, won’t preempt the current task. Even if the current task has a lower priority.

It was my first GUADEC and yep, those other GNOME developers convinced me they are indeed a great crowd and bunch of insanely cool and friendly people! A real community of friends and guys wanting to create this amazing desktop platform. I’ve never been to such a relax and fun conference. Asking questions to the speaker was like talking in a group, rather than firing a question, getting an answer, etcetera. In the smaller rooms, most questions became little discussions and sharing idea’s. That’s IMHO how a conference like GUADEC should be. And it’s how GUADEC was for me.

As number 44, I even won one of the five Nokia 770’s :). I can’t wait to get it (they are going to send it). I’m sorry for the other guys who also wanted one. I promise I’ll use it good and will contribute stuff for the device. The company where I’m employed is planning to buy a few so that we can investigate and develop specific softwares for our customers.

I’ve met some of the Evolution developers like Harish Krishnaswamy and Parag Goel. I didn’t know the Novell Evolution developers appreciated my little contributions so much. It was nice meeting you guys :-). I also met some of the RedHat Eclipse developers. So who did I meet, lets try to memorise. Andrew Overholt, David Malcolm, Ben Konrath … Hey David: that was a great restaurant you showed us!

I (and the conference) convinced my colleague, Bjorn Monnens, who was with me at GUADEC, to become a member of this GNOME community. He’s a professional Java developer at our company. Every evening in the hotel he started trying out C, asking me questions about autotools and makefiles. Debuggers. Etcetera. He was also very interested in the latest Eclipse stuff. So we’ll have a new developer soon!

A few minutes ago I quickly made this sample (quicklink to the code) for AsyncWorker. Getting the sample to work forced me to fix some issues in the library. It shows you a GtkTreeView with tree buttons: Add, Remove and Cancel. Pressing Add will create a new AsyncWorkerItem that has some simulation-delays (usleep). Remove will remove the item. Cancel will wait for a cancellation point in the item (and will then abort the item).

Hey Sven,

A few days ago I tested the clipboard-manager of Anders. Regretfully, however, it’s using gtk. It would be better if a desktop-neutral solution was build. The freedesktop concept really doesn’t need ten different solutions for one little problem. No I don’t hate gtk. But lets be reasonable and accept the fact that not everybody likes depending on gtk. We can always conqueror the world later.

And the clipboard-manager only fixes one issue and only for applications that can and will be modified. Many applications will not be modified and will therefore still cause the clipboard to disappear when they owned it and decided to shut down. So the backwards compatibility issue isn’t fully resolved. Yet I agree it’s a nice solution: In my document I wrote that (imho) it’s not always a good idea to overcommit yourself to backwards compatibility. In the end it needs to solve the problems. A long-term solution would be to create a series of standard target-formats (xslt?) and to let those persist automatically (by a clipboard manager). The current solution requires that the desktop application developer understands a specific detail of the clipboard system: The fact that a clipboard manager needs notification of which targets to persist. Whereas that should be obvious for certain formats! Desktop application developers shouldn’t have to worry about such specifics (and in reality I think they’ll often disregard it).

Perhaps a solution for xclients that don’t have “persistent targets” (is it the “SAVE_TARGETS” atom? The document you talked about isn’t available on fdo) could be to nevertheless save (one of) the UTF-8 plaintext targets.

And it’s not the only problem of the X11 clipboard. There’s many other problems like the performance on remote xserver X11 deployments, support for console applications, recovery after session restart, etcetera.

Some years ago (when I was still young and naive) I implemented a tool that had the purpose of fixing the many issues of the X11 clipboard. While some people packaged and even used it, I didn’t succeed in really fixing any of the issues.

The real fix is harder and more difficult. It involves working together, X11 politics, creating standards and agreeing upon a set of solution and or proposals.

Therefore I created a document that enlightens my views on the subject. It contains some proposals that might or might not be doable. The purpose isn’t to get these specific proposals into the throats of the developers of our free desktop environments. The purpose of the document is to keep people talking about these problems. Who knows someday people will start fixing them.

An overview of the subjects:

• Sharing the clipboard with console applications like vim;
• Clipboard owner dies means that the clipboard is gone;
• Performance issues when xserver is remote while clipboard owner and requester run on the same host;
• Standardisation of clipboard-formats;
• Standardisation of a transformable clipboard-format;
• Recovery of the clipboard upon session-start;
• Addressing backwards compatibility;
• Extending the clipboard: Virtualization and network clipboard sharing;
• Confusing multiple clipboards.

ps. If you find errors in the document, feel free to inform me about them.

Hey Dom Lachowicz, I like the new layout. Perhaps, however, you’re right about the wasted space. This could be solved with a layout like this.

Note that I don’t have a stylesheet like it. I just quickly GIMP’ed this one

ps. Sorry for raping your post Luis. I needed a victim with a long blog-entry.

Today I added some aid for supporting cancellation of items to asyncworker. It goes like this (check the link):

What will happen is that first the item will be created and then (at some point) launched. Upon some_event will a request to cancel the item be set. If such a request is set and a cancellation point happens, the item will be cancelled. You can pass a boolean to the cancellation point that will tell the asyncworker-library whether to still launch the callback (for cleaning up). Once cancelled or really finished, the “item_finished” signal will be emitted (and the handler will therefor happen).

ps. I also created the build-environment for the gtk-doc stuff. You can preview the API-docs here

AsyncWorker is a GObject-style library (liboasyncworker.so) that will ease implementing a task queue. By
which I mean a system like a printer spool, but for functions (or methods) rather than printer-tasks. So for
each queue instance, there’s always maximum one task being processed. Tasks can’t be preempted (it’s not a kernel scheduler),
but tasks that haven’t run or aren’t running can be removed. Of course can the kernel preempt tasks (the entire proces). I mean
that within your application, you can’t preempt a task: to make another task happen before the current task ended. While using
the same queue instance.

Creating a task happens by creating a OAsyncWorkerItem instance, which is of course a simple GObject. The object
holds, for example, a reference to a launcher function (the task itself), a callback (to cleanup your stuff after
the launcher finished), a launcher-arguments pointer (user data for the launcher) and a priority.

Once you add the item to the OAsyncWorker instance, the worker will make sure that at some point in the future, the
item will be processed. The higher the priority of an item, the faster it will be selected to be processed.

My plans for this one are to replace a specific GList with a GAsyncQueue. And to let all the signals (it has signals like
item_finished, item_added and item_removed) emit in the GMainLoop.

There’s some basic support (on platforms that support this) to set CPU affinity on a queue-instance. This way you,
as the programmer, can specify on which processors the queue may process it’s tasks. I haven’t yet added support
for the other sched.h functions. You can, of course, use multiple queues simultanously.

There’s no support for cancellation of the current-item (but you can remove items that haven’t ran). The reason is
rather simple: GThread isn’t supporting thread cancellation (for good reasoning). Yet, you can of course implement your own
cancellation-points and a cancel trigger. I might add functionality to ease this (not sure yet).

You’ll still need to use gdk_threads_enter() and gdk_threads_leave() in the launcher and callback functions of your
tasks. For example in case you’re planning to perform gtk stuff. You wont need to do that in the signal-handlers.

Mikael Hallendal invented both the name AsyncWorker and the namespace
to which I renamed this library. That namespace is “O”. It means “Onion”. It’s indeed to make sure that now we have
“Egg”, “Bacon” and “Onion”. Yet you can’t blame me for it!

pvanhoof - EggAsyncWorker ? :)
Hallski - eek
luis - I think Egg is a curse :)
Hallski - OnionAsyncWorker
pvanhoof - lol
Hallski - so we have an entire omelette
Hallski - with Egg, Bacon and now Onion

You can find asyncworker as a module in CVS here. You can find a simple sample that illustrates all this a little bit here.

Please note that the API isn’t stable (this is bleeding edge and very new). I did, however, already added some API documentation (so you can already generate API-documentation).

Hey John and others who’ll tryout this new release of Anjuta. I created this little script that will help you (compile and) keep that checkout of Anjuta updated. If you’re using one of the popular GNOME-from-CVS buildscripts, this ain’t useful of course.

About Marc Maurers Evince stuff: And if you want to let Evince also load some ppts without making it crash on most of them, try this patch which I quickly created while debugging this stuff :-).

There’s still much work. The stuff in present/libpresent/, for example, needs love!

A few weeks ago I blogged about a multi-alarm aware alarm notification dialog in Evolution. Now Evolution’s HEAD has reopened, these patches have been accepted by Rodrigo Moya and are now availabe in Evolution’s CVS.

It looks like this:

I hope people will like this improved alarm notification userinterface. You can suggest HIG specifics about it on the evolution-hackers mailinglist.