How easy it is to make people believe a lie, and how hard it is to undo that work again

Hey Federico,

I’m most likely missing something extremely important here but simply doing,

gchar *
g_utf8_offset_to_pointer (const gchar *str,
                          glong        offset)
{
  const gchar *s = str;
  while (offset--)
    if (*s < 191) s++;
    else s = g_utf8_next_char (s);

  return (gchar *)s;
}

Makes it a little bit faster (on my system). Oh and that way can the utf8_skip_data bitmap also be 191 bytes smaller, of course (adjust the macro to subtract 191 from (*s)). The idea here is that arithmetic operations are less expensive (on my CPU/architecture/system) than looking up memory. Just compile test.c using gcc -S test.c with and without -DOPT and check the differences in the resulting test.s file.

Hey Lucas, and the gegls from outer space, free the fish! :-P

That said, I launch a virtual petition titled: Don’t kill wanda!

By the way, check out the Nokia ordering page for ordering your Nokia 770.

A few weeks ago I discussed with Peter Saint-Andre the problem that there were no best practises specified for so called “offline messaging” with the XMPP standard. While Instant Messaging is one application that implements the XMPP protocol (as further described in XMPP-IM) and while for “Instant Messaging” the delivery of a message to a person who isn’t available at the time message is being sent isn’t (always) critical, other applications that implement the XMPP standard might or might not have reasons to mark this aspect of the standard as an important one.

Since as far as I know all Jabber service implementations support this “offline messaging”-feature, there was a need for specifying the best practises.

So Peter specified it in JEP-0160: Best Practices for handling offline messages.

I’d like to thank Peter Saint-Andre for making this Jabber Enhancement Proposal.

We are planning to use XMPP for applications like distributed package management. We’d like to signal clients when they should update themselves. And we’d like to make sure clients will get that message when they rejoin the network in case of being offline or unavailable (mobile devices and in case a desktop on a corporate network was shut down). It’s also interesting for the concept of distributed personal preference management or distributed desktop configuration. Why reinvent the wheel if you have both good and existing/tested service implementations and a suitable standard for this? XMPP fits the requirement.

This, this and that it’s very unfinished. That’s all I’m saying today.

Interesting …

It looks like Robert Staudinger imported GtkMozEdit in the GNOME cvs repository.

Perhaps it’s a bit premature to already mention it. And I’m not making any promises. Nevertheless is my Sauron eye fixed on trying to replace the GtkHTML editor Bonobo component with GtkMozEmbed.

Some information about the attempt to do this with our poor Evolution can be found here. To be more specific you can make a GtkMozEmbed component editable using this API. That API, however, of course doesn’t mean that this is/will be a flat road without issues and problems.

For example one issue is that the current state of the EMsgComposer code is a little bit tight to the Bonobo way of working. Another issue is that there’s a lot “commands” to support (like, “insert html”, “set bold”, “undo”, “redo”). Most are also supported by the nsICommandManager. Some are not.

So I started with making sure that other parts of the Evolution code don’t try to tamper with private fields and members of the EMsgComposer. Why? Well, if we’re sure no other Evolution developer used something other than the API as agreed in e-msg-composer.h, then a programmer can more securely alter the internals of the implementation (e-msg-composer.c).

You can find the result of that first step (data hiding) here. As usual, if you want to help. Contact me, or you know .. help (give me tips, guidance, whatever). Note that I don’t even know whether or not the Evolution maintainers like this idea. So this blog entry doesn’t mean that in a few weeks you’ll have a slick Gecko HTML editor component for typing your E-mails in Evolution.

I created some patches that will make the GPLed part of Maemo target the D-BUS version that can a.t.m. be found in fd.o’s CVS. Come join the fun if you like.

A colleague of me at X-Tend has just send me a link to a website with what must be the only true definition of GNOME.

Yesterday I told about The desktop configuration specification. Regretfullt my server went down this morning after 541 days uptime. It’s possible that cause of that downtime some people who where interested in the document failed to view it. It should be back online now.

During the last days/weeks I’ve been working on the desktop configuration specification. Yesterday I decided to convert the document to XHTML. This makes it even more easy for potential contributors to join the effort of creating this specification.

With the document I got to the point where I’m about to say: “this my proposal”, “what do you want me to adjust and/or do different”? So I’m seeking comments and/or suggestions.

The freedesktop.org organisation told me that they’d like to see a rough implementation first (replace fd.o with Daniel if you want it to be 100% correct). They will, however, assist me with facilities like repository hosting, a mailing list for a committee that decides about shareable keys and a wiki page once that first implementation is finished. The specification might also become a recommendation by the freedesktop organisation. The requirement, however, is that there needs to be a first a rough implementation first. The main reason for holding back is that specifications tend to change a lot during the development of a first implementation. I don’t disagree with this.

Therefore I invite interested people to read the proposal. Perhaps even help me make corrections (I’m sure there’s plenty of errors in the document at this moment). Perhaps even help me implementing a rough first implementation and/or adjust an existing infrastructure (like KConfig or GConf). Or build a new infrastructure. Or help with any imaginable use for this specification. One could, for example, adapt GConf or KConfig. Or even make a code generator like KConfigXT that uses the schemas defined by this specification. There’s a lot of work if you too want to make this standard happen (just ask me for it! :p).

One direction that will be taken is extending this specification (and implementing an implementation) with an add-on to make remote desktop configuration data management reality. At my company we will be looking into this. We are already doing an analysis about this subject. I will/might publicise a document with this analysis soon. I can already tell that it will most likely implement JEP 0072 (SOAP over XMPP) for remote notification of pushed changes and SOAP over https for transferring data. But all this is highly unfinished and uncertain at this moment. We welcome participants and/or teams that are interested. As a Linux consultancy company, our plans are to release this project using the GPL license (note that it doesn’t exist at this moment, we are doing analysis).

Cairo – Egypt

I’ve been to Cairo (in Egypt, not the software library) last week. All I have to share with my blog readers about my vacation is that
the (taxi) drivers in Cairo are insane and that I learned a lot about the ancient Egyptians and their culture. Our tourist guide was very good. If you plan to travel to Cairo and need a tourist guide, ask your travel agency (they probably use the services of Travco) for Mr. Hosam M. Kamel. I really enjoyed his passion for the culture of his country.

Desktop configuration specification

(Before I went on vacation) I’ve been doing some discussions with some of the key developers of
existing configuration infrastructure on the opensource platform about the creation of a specification and/or standard for desktop configuration.

I tried to create the standard. I used LaTex for the document format and
added a build environment that will create both a dvi and pdf from it.

You can find more information here (unfinished). You can find the proposal itself (it’s source) here and a tarball of it here. Because I know most of you guys are fucking lazy, this is a precompiled PDF.

I don’t yet have permission (from Daniel) to let freedesktop.org be the
CVS repository hosting location. He’d like to see a rough/scratch but
working implementation first. Mainly because standards tend to change
radically as an implementation is written. I don’t disagree with that.

If people are interested in building a rough implementation and/or
helping me with crafting this standard/specification: please do contact
me. I really can use your help (I’m serious). Read the “ps” if you are
interested.

Note that this rough implementation is not necessarily the same as the
project that has been dubbed “DConf”. It might be. Or “UniConf” could
implement it. Or .. whatever (which project implements it first, isn’t
important. But a first implementation is important for the standard to
prove itself).

ps. Some very interesting and extremely important documentation about
desktop configuration that affects this specification can be found here

• OOR document format
• Plans for GConf
• Plans for GConf as a spec

This one might also interest you.

Hey dobey,

You recently blogged:

It’s time to get ourselves off the couch, and onto the shelves. It’s time we get the third party application developers on our side. It’s time we get the hardware support we need. And, it’s time to take back the desktop, along with the web. None of that 10×10 marketing junk. No arguing about how to get it done. Let’s just do it.

I’ve been working on a specification for configuration infrastructure. Last weeks I’ve been discussing this with some of the key-players in the field of configuration management on the free desktop (including the authors of gconf, kconfig, the config system of openoffice.org and mozilla). I’m convinced that in order to get third party application developers on our side, we need to have a solid and consistent way of dealing with this type of application development obstacles. I will not yet publicise this work because I want it to be perfect first.

I have also been talking about the many problematic design flaws of the X11 clipboard (and I proposed a solution). And recently I mentioned the existence of openusability.org to the GNOME usability team. Both in blogs and on the mailing list. And I blogged about the importance of an infrastructure and/or standard for presence notification. I’ve also prepared the Python bindings for this infrastructure and I’m planning to (if nobody else is going to do it) adjust Gossip in such a way that it registers with Galago.

I also wrote this blog, just to make sure everybody is aware of my targets. I’m planning to put a lot of my free time in the targets you can extract from that document. Knowing I’m probably not going to succeed in any of them. Mainly because of the huge amounts of stop-energy we have in our communities.

These are only the recent actions that I’ve been taking. A few years ago I decided to help the Anjuta team because I was convinced that the GNOME environment lacked a good IDE. And that this was holding back third party developers (Face it. vim and emacs are not always what they want to use. Look at Visual Studio. This is often what they want. Yes really). I’m planning to rejoin them because their work on Anjuta2 is starting to look great. I specifically like the gnome-build stuff (they didn’t create this, the project Scaffold of Jeroen Zwartepoorte caused it to get written. But Anjuta2 is the first project to use it and they are, as far as I know, doing bugfixes for the component).

So what I’m basically trying to say: If you need somebody who is waiting to get in action to work on this type of jobs: I’m here. And I’m willing to put my (free)time on this. Regretfully there’s no leadership or committee steering this. Freedesktop.org already responded that they are not planning to be that leadership. So it’s very very hard. Also note that many of our social differences have made it very hard to talk to team members of the other teams in a constructive way (for me, that’s for example the KDE developers). It’s a very unpleasant obstacle. It’s yet another reason why I don’t yet want to publicise my work on the (protocol) specification for configuration infrastructure (so it’s not “dconf”, it’s a spec that a project like “dconf” would have to implement — Yes, I’m also trying to implement it. So this is not vaporware –). It needs to be perfect in every possible way first. There’s a lot stop-energy. Also in our very own team. It’s very very hard to “just do it”. And in my humble opinion are few people doing it nor are planning to do it.

A few weeks ago at LinuxTag, I met Tina Trillitzsch and Jan Muehlig at their openusability-booth. I asked the guys what openusability is about, their answer was that openusability is an umbrella for coordinated efforts for making open source software more usable.

So I talked with them about how they should be cooperating with the people doing usability for GNOME. I also decided to post a question about cooperation at the GNOME usability mailing list

My opinion is that we should steer our desktop developments in such a way that one day it will really no longer matter, for the user, which libraries have been used by the application developer. Because lets all face it: There’s not a lot non-technical users who really care about our reasoning for choosing to develop for KDE, XFCE or GNOME. Yet we are making it harder, for them, by introducing more and more big differences. At this moment are our programming decisions having a huge impact on the usability experience. It’s my opinion that this is a bad thing.

If openusability is going to help the KDE people with usability (it’s not their only target), I think it’s extremely important that at least some basics are shared or shareable with the GNOME usability infrastructure. Because the study of usability should have the most influence on the user experience of a desktop system. Not the programming decisions. Our users (often) don’t care about our stupid programming decisions.

If we don’t commit ourselves to creating usability standards, we’ll probably end up having totally incompatible ways of expecting user interaction with our applications. We’ll end up with a platform like Windows, where every software supplier decided to create his own usability standard.

This will make educating “The free software desktop” to people extremely expensive and very hard for the users. Because they’d basically have to learn about two usability standards. Two ways of doing the same thing. It would create a lot confusion. If we want to achieve that crazy 10×10 idea of jdub, it’s inevitable to cooperate on usability with other popular desktop application development environments and popular desktop applications that aren’t strongly committed to using the GNOME usability standards (like firefox, openoffice.org, etcetera).

So I urge everybody in the usability space of both GNOME, KDE and openusability to meet, greet and talk to each other.

I’ve uploaded a simplified drawing of the concept.It also contains the drawing of an experiment Magnus Bergman is trying. You’ll need Dia to view and/or edit this drawing.

A temporary SVN repo has been set up. If you want write-access, you should join our temporary mailing list and ask for it.

We have plans to rename the project dconf. We’ve been thinking about the following names:

• confuse
• confusion
• Irene
• Harmonia
• Eunomia

Names that have been taken and/or can’t be used:

• dconf (taken by Dag Wieers)
• pconf (taken)
• yaconf (yet another conf, taken)
• uniconf (taken — and this project isn’t about unifying things –)

I compared the world of computing with the world of music. You can find the nonsense here.

Hey John, I fully agree with your point of view about how fd.o projects should be.

I more or less used xdg-list to get a huge amount of opinions. I tried filtering some of them into a wiki page. I decided to go public with that wiki-page and let interested people add their needs. It turned out to be more or less a small success. The wiki-page did, indeed, grow. And most additions where not being added by idiots (unlike the flame wars on xdg-list). The idiots decided not to waste their time with it. Once done with that, I decided to shut up about it. And I started to search for people who are interested, I started a mailing list and etcetera. So just like you suggest.

I’d like to make sure, however, people understand that this wiki page isn’t “dconf”. It’s not. Not at all. It’s just the opinion of a lot people about desktop configuration management. So Colin, you’re blog-title is wrong! That image isn’t about “DConf”. It’s unjustified to use that drawing to taint peoples opinions about “dconf”. Please don’t.

DConf is a research project. It’s about “seeing what happens if you do this or that”. The exercise of telling people about a shared configuration management infrastructure is part of that research. Viewing our communities fail to agree on this stuff is a lesson that we are learning today. For me, it’s also part of the research: The results are miserable. I decided to stop that experiment.

I learned GNOME nor KDE are ready to cooperate on this level today. And it’s not only the cooperation between the two teams. I’m sure, John, you are learning how difficult it is with “D-BUS”. In my humble opinion shouldn’t cooperation be that difficult. So my plan is to keep this project a research one. I don’t think it’s a good idea to be very “public” about “dconf”. Yet you guys forced me to defend this ghost. I hope this illustrates why I wrote my previous reaction, and why I said “I don’t (yet) like doing that (blogging about dconf)”.

I hope the nonsense reactions (that I removed) from my blog and nonsense blogs and comments about “dconf” that suddenly pop-up on various places also illustrate why I think it’s better not to be very public about “dconf”. Some are really hilarious!

Hey John and Ross, now you guys forced me to blog about “dconf” :p. And trust me: I don’t (yet) like doing that. Simply because “dconf” is at this moment “only an idea”. It’s a “concept”. It’s not yet code. You can’t yet touch it. Please understand this!

And please understand that we are not about flamewars on xdg-list. We are actually thinking about and investigating the concept. We are doing meetings. Etcetera. But we aren’t promising anything! It’s unfair of you to start saying “dconf is crack” when we haven’t even started it. Sure you meant “that E-Mail is crack”, but a lot people might interprete your blog as: “dconf is crack”. That’s unfair and will kill the project. In my humble opinion shouldn’t the free software community behave like that.

I’d like to make sure people understand that the proposal of Jamie isn’t really about DConf. It’s about a project that he’ll be doing himself

So far the only (more or less official) conceptual proposal, coming from me, about DConf, is this one. And this drawing will give you a visual overview of the different (proposed) components and their responsibilities.

I’m glad you guys read the mailing list. But please don’t take things out of the context. Please make sure people will read the conversations, not just one E-mail of anybody who’s subscribed to the mailing list.

Also note that storing the configuration data in a CVS server isn’t addressed in any of the current proposals. So DConf, it’s current proposal, isn’t about that at all. Again, please keep things in context. Only one person requested this on xdg-list a very long time ago. None of the people who are interested in dconf have ever acknowledged that this is an important feature request.

I also like to repeat that DConf is (in my humble opinion) a research project. It’s not something that will be usable soon. Please do not start thinking that we’ll have a solution for the next major GNOME or KDE release. It’s not that simple!

Oh and by the way: Yes, you’re right, we do need a realistic-minded project leader.

I decided to take a look at this bug about eog. It’s a feature request to have printing support for eog. It used to be available but got removed for some reason. So I reimplemented it using libgnomeprint and libgnomeprintui. It’s my first time I used gnome-print so please review before approving. There’s still a little issue with the paper-margins for example.

By the way, why isn’t the gnome-print API available on developer.gnome.org? Is it a secret API? Or did people just forgot to add it? At Foundation level we are talking about “Certification for GNOME apps”, but at documentation level we aren’t telling people how to do simple things like printing a document. IMHO there should also be more samples. Simple ones like: “How to print a GdkPixbuf using gnome-print and get scaling it on the paper right”. I actually had to start searching koders.com to get basic answers about how to use gnome-print. That shouldn’t be, there should be samples and real documentation.

By the way Tim, if it’s not a problem for you it’s more easy for me to commit patches like this myself (after approval of course). That way my tree doesn’t get a huge CVS conflict. However, if you prefer to commit it yourself, it’s not a real problem for me.