Category: english

Today I added support for XSLT Templates to codegen.

The generator will during the generation phase create an internal XML document before it’ll apply your XSLT Template on it. In that template you can iterate the operations, parameters, attributes and interfaces of each generated interface and class. It will also pass some arguments to the XsltTransform instance. Arguments like the name of the inherited class, the package name, the class name or the interface name to generate.

How the internal XML document is formatted and which parameters to expect is documented in the sample templates. All this is, of course, experimental. I’m going to tweak and bugfix it this evening. Don’t just sit there reading this blog entry with a donkey-face. Help me :-)! It’s C# but it’s LGPL (yes, that is possible).

Lets make a new supported-list: Dia class diagrams in, XMI models (class diagram) (Rational Rose) in, C# out, VB.NET out, any format and/or language using XSLT out

I also added a Nant build file and tested the project with Mono, an opensource .NET framework that works on platforms like Linux. Everything builds and works with Mono. This effectively makes the framework platform independent. I also added MonoDevelop combine and project files. This eases debugging and developing on Linux. The Visual Studio .NET solution files are also stored in the repository. I suggest using AnkhSVN if you’d like source control with Subversion to be intergrated in VS.NET. It works great. So it doesn’t matter much on what platform you’d like to develop if you want to contribute.

Yesterday I wrote about a code generator that generates skeleton code from your UML Class diagrams. Today the support for XMI files (Rational Rose supports this) is done. It’s still, of course, experimental.

This brings the “supports”-list to: Dia in, XMI in, C# out and VB.NET out. And since all this is implemented as a LGPL library, it’s easy to integrate your existing softwares (like integrated development environments) with it. You can, indeed, generate class per class and interface per interface. And the generation doesn’t have to go to a file. The output is a TextWriter and defaults to the Console.Out instance. There’s also implementations (for C# and VB.NET) that will write to files and directories. The input is also abstracted to StreamReader. So you could implement one that reads it’s data from any source (including remote locations, databases or any other input source).

Next on my to do list for this project is implementing a IGenerator that uses XSLT Templates. If you’re interested in helping me with this, search me on the typical opensource IRC networks as “pvanhoof” and talk. Do type my nickname in a channel, it’ll make my IRC client flash. I might be busy coding :-p.

The nice guys at Novell approved putting the project at Novell Force. You can find the webpage for it here. I’ll add information and releases to that page later. You can put bugs here.

ps. If you need commit access on this repository, ask.

I’m working on something that I’ll call “A Code Generator framework” written in C# (but not only meant for .NET).

As every good code generator it doesn’t try to generate your great implementations. It will try to convert your UML class diagram into skeleton code (which is IMHO a boring and automatable task). A good thing about this UML to skeleton code generator is that it forces the developer to design first, code later (reverse engineering to a UML class diagram is cool for refactoring, but this code generator isn’t meant for refactory tasks).

I’ve added support for Dia as input and C# and VB.NET as output. Continue reading if that triggers your interest. If not, I’m also planning to support Rational Rose (sooner or later) as input and XSLT als output (which would make it even more easy to add other languages).

In fact it’s already somewhat finished (so for me it ain’t vaporware any more). I released this as LGPL. You can find the sources in a Subversion repository here. You can contact me if you’d like to make changes and/or if you’d like commit access.

It heavily uses the Strategy Design Pattern. The framework abstracts the source and target. The Strategy Design Pattern’s delegate is a concrete IGenerator implementation. A concrete ISourceParser implementation is an object that can parse a specific source into a list of interfaces, classes and packages. The interfaces and classes itself have, of course, properties and methods. At this moment I’m not yet supporting aggregation nor composition. This is on my to do list.

You can find a UML class diagram here.

I’ve added support for Dia, C# and VB.NET. Dia input support is implemented in DiaSupport.Parser.CSharpSupport.CSharpCodeGenerator implements support for the C# language and VBNETSupport.VBNETCodeGenerator implements support for the VB.NET language.

I also created implementations for both C# and VB.NET that will write files in directories (one directory per package). It will not yet generate Visual Studio .NET solution and project nor nANT build files. This is on my to do list. I’d first like to create a generator that will transform XSLT files.

I’ve added a sample console tool that demonstrates how to use the framework. You can also use the framework as a library. For example if you’d like to integrate with an Integrated Development Environment.

This is a quick ‘n dirty Dia UML class diagram to C# code generator. It doesn’t yet support aggregation nor composition. It does support inheritance (dia:connections), classes (dia:object), interfaces (dia:object) and properties (attributes). It also doesn’t yet supports methods (I’d have to generate the methods that are to be implemented because your class implements interfaces that define them. Same for Properties that are defined in the interfaces (they aren’t yet generated in classes that implement the interface). All this is perfectly possible but I’m lazy right now (and I have to go to my girlfriend in a few minutes).

Of course it also doesn’t generate implementations. And it doesn’t work with xslt (it simply uses Console.WriteLine).

Since the opensource community reads this on planet.gnome.org, I expect a fully supported and fully functional DIA to C# code generator in a few minutes! I added a line that this thing is LGPL (I don’t really care). So .. start! :-P

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 –)