A generic E-mail metadata D-Bus API

A generic E-mail metadata API

You guys remember the Evolution Metadata API? No? I wrote about it a few days ago.

We now want Tracker to integrate with the KDE desktop too. I started implementing the D-Bus API in KMail. I have adapted the specification to become more generic and to split out specific pieces into a shared and a specific part. Like for example the ontology.

QT/C++

Yes, I’m doing some QT/C++ coding after three years of not having to touch a lot of C++. But I’ll manage. I mean, it can’t get worse than Python, PHP or Perl, right? I survived developing with those languages too and it’s not my first time that I had to touch C++ code. Also, I survive GObject without always having Vala available.

Well, QT/C++ is interesting. Firstly I refuse to call it normal C++, it’s not normal C++ at all. That’s not necessarily a bad thing about it, though. Secondly on top of the inhuman quagmire that C++ has become by itself, QT adds almost as much boilerplate and macros as GObject is doing on top of C

…

That’s not good.

In my opinion C++ is not a nice language at all. It’s a completely inconsistent quagmire in my opinion.

Freedesktop.Org

I’m not immediately proposing it as a Freedesktop.Org standard. My personal experience with F.D.O. is that unless you have a few implementations nothing much will happen with your proposal. At least not for several months. Maybe if I first finish the implementation for KMail while having the one for Evolution ready it’ll speeds things up?

Let’s first implement it for both E-mail clients.

Akonadi

This is a message for specifically Aaron Seigo, because I know he would otherwise be frantic about it.

I have been talking with the KMail developers and because KMail’s Akonadi integration will take too long to be finished we have agreed to start with this D-Bus API. We will most likely integrate Tracker with Akonadi as soon as it starts becoming consumable on people’s KDE desktops.

Birds will sing, the sun will shine. Don’t worry too much and especially don’t start punching the project teams who are actively but pragmatically trying to make things better.

We’ll get there but converting Evolution to use Akonadi is trying to take too large steps and is therefor not a useful proposal at this moment. While for Tracker, Akonadi needs to be ready *now*.

I propose that the Akonadi people develop a CamelProvider that talks with Akonadi, by the way. Then make an EPlugin that overrides the account management to always create such Akonadi accounts and develop working and well tested migration code for the data.

I think even if this is ever started as a project that it would be quite unlikely that this will be finished in time. So not very useful for Tracker right now.

22 thoughts on “A generic E-mail metadata D-Bus API”

  4. > QT adds almost as much boilerplate and macros as GObject is doing on top of C

    Qt (note: lower-case ‘t’) does define a lot of macros but the important difference is that you hardly have to use any to ‘Get Stuff Working’ as a programmer.

    For example, a look at:

    http://gnomejournal.org/article/34/writing-a-widget-using-cairo-and-gtk28

    This requires 6 macros to be defined for run-time type identification, a custom function to create new instances of the class and quite a few GtkWidget* -> specific widget type casts. In Qt a single argument-less ‘Q_OBJECT’ macro at the top of the class gives you run-time type identification,casting and searching within object hierarchies. Casts are generally not required as often but when they are there is a single template method which does the job.

    If you were looking at Gtk# or Gtk with Vala then you’d be right that ‘boilerplate’ wasn’t such an issue but I think it is hard to argue that it doesn’t make Qt/C++ easier to get to grips with than GObject/C.

  5. >> QT adds almost as much boilerplate and macros as GObject is doing on top of C

    I don’t notice it. The extent of my macro use in Qt is Q_OBJECT, and signals, slots. That’s it. Three keywords of macros isn’t really that bad I think.

    >> It’s a completely inconsistent quagmire in my opinion.

    Examples? Qt/C++ code is very consistent. I really don’t see what you’re driving at. Just because you don’t know it well yet doesn’t mean it’s a quagmire.

  6. I’ll open one random .h file of kmail: kmkernel.h. Here we go:

    Q_DECLARE_METATYPE, Q_OBJECT, Q_SCRIPTABLE , Q_CLASSINFO, Q_SIGNALS, Q_SLOTS

    And worse, un-namespaced ones: SIGNAL, SLOT, etc. There are probably a lot more too. But spare me.

    On consistency: & vs *, heap vs. stack (if I wanted to care, I would use C or else make an ‘easy’ default for me in the language plz), callee owns vs. caller owns (how do I reliably know in most KDE/QT code that exists today?), complete overuse of operator overloading (as usual, that’s a decease each C++ programmer seems to be infected with! Making it very hard to ‘guess’ what will happen, making people stop using operators), overuse of templates (I guess it’s cool to show that you use them, but having to use somebody else’s is usually insanely hard).

    I mean, yours is also a little bit the the typical C++ reaction: it’s not because you are not elite enough to understand C++, that C++ isn’t awesome. You of course put it in a more friendly way, but that’s what it comes down to :)

    My point of view, after having worked with quite a lot of programming languages: The more time I need to invest in “knowing it well” the worse the language is. By definition. Other languages succeed just fine it allow me to “immediately” grasping every aspect of it.

    Frankly, whoever requires elitism of programmers probably shouldn’t be designing a programming environment or language. Requiring elitism is already wrong. Completely and utterly wrong.

    The best way to design either a framework or a programming language is, in my opinion, by asking people to implement samples with it BEFORE you set it in stone. Which is how the guys who did Delphi have done C# and .NET’s class libraries (read Brad Adam’s books). If most people fail at the task or can’t finish it within a few minutes it means YOU failed at getting it right.

    Try this with C++, or with QT. You’d be amazed at the failure rate. It’s not simple at all, in QT.

    What’s the problem with just keeping it simple instead? D, C#, Vala and normal C are all ~ equally powerful than C++ is. I can use damn pointers with all those languages, and with the exception of D and Vala all of them, and C++ too, have been used to write kernels, drivers, and whatever software that touches hardware. With Ms’s Singularity project that includes C#, yes. So “because C++ is more powerful” is just utter bullshit. It’s not more powerful at all. It’s powerful but misdesigned.

    Now if its programmers wouldn’t want to abuse each and every damn C++ feature of their compiler, perhaps some libraries and frameworks would have ended up pretty nice.

    But no, they all decided to become language-feature whores and inhumanly clutter their code and, far far worse, their public header files, with their abusive usage of each and every imaginable damn C++ feature. Even at places where it’s absolutely not necessary at all and where it absolutely does make it all a lot harder for the developer to just use it.

    The contest isn’t to produce code that was hard to write. The contest is producing code that does what it must do, in an elegant way, that doesn’t do more than that it must do, that is easy to consume and use (in case of a framework or library) and that isn’t hard to integrate with. And if possible code that is secure and bugfree. And please, let the language help me with that as much as possible indeed.

    The majority of C++ frameworks and libraries fail at most of those points.

    The language itself can be used right. Not disagreeing with that. Just that almost nobody seems to use it right.

    I usually prefer languages that make it hard for people to do it wrong and easy to do it right. Instead of making it easy for people to do it wrong and hard to do it right.

    And I’m certainly not defending GObject/C here, by the way. That sucks too :)

  7. @Robert Knight: sure, not saying GObject is better.

    Today I see GObject as a type system. Although Vala generates C code using that type system, I don’t see valac as a C code generator. For me it’s a language by itself and a compiler.

    I do care about what C API it spits out, and Vala’s is very sane for me given that it’s easy to integrate with libraries written using Vala. That’s not always the case with Qt/C++ ones although there are probably tools that help a lot with this task. But “having to use tools” vs. “‘automatically by design of the programming language” as which is the case with Vala?

    Anyway, not saying Vala is some sort of Utopia (D is, hehe). Just pointing out that the boilerplate in C doesn’t necessarily mean that GObject as a type system isn’t useful.

    But yeah, GObject/C is insane. But isn’t the idea of using C++ not having to add a typesystem on top of the language? Because that’s what Qt seems to be doing to C++. At least from my point of view.

  8. @Russ: ah, yes. I usually like boost. So that system for so-called slots is probably going to be nicer than Qt’s :-). But I don’t know. I never used it for that.

  10. > Q_DECLARE_METATYPE, Q_OBJECT, Q_SCRIPTABLE , Q_CLASSINFO, Q_SIGNALS, Q_SLOTS

    Only Q_OBJECT is true boilerplate, everything else is there for a good reason. Or do you consider Java’s “public” or “static” or “synchronized” boilerplate as well?

  11. Also, about memory management – it’s much easier than it looks, you just need to know certain conventions:

    1. QObject can form a tree, so when parent gets deleted, the children get deleted as well
    2. Most Qt APIs require you to manage QObjects yourself, except where it makes sense like tree item models and of course everything QWidget based (addWidget, etc.)

  12. 3. Use QPointer when you’re holding pointers outside of tree, it’ll be set to null automatically when the object is deleted
    4. Another nice technique is to connect destroyed signal from one object to another object’s deleteLater slot, so you can form powerful resource graphs, which cannot be described by trees, you can even form cyclic graphs without fear unlike in reference counting strategies
    5. It’s usually best to always delete (foreign) QObjects with deleteLater to prevent signal-slot delivery related crashes

    (btw., I’m a Qt programmer primarily, I don’t know much about KDE)

  13. Ah, the usual “idiots write bad C++ code so C++ sucks” argument. I’ve seen a great deal of horrific C code (e.g., the entire glib/gobject/gtk “quagmire” — implementing a macro-heavy type system in C is every last bit as dumb as using C++ features in inappropriate contexts), so clearly C sucks more than C++. By your own logic.

    And don’t even start with the “elitist” crap about C++ proponents. NOBODY has said you’re too dumb to understand C++. We’ve only said that you’re wrong. The same way that you’re saying _we’re_ wrong for defending C++… wait, that must mean that you’re an elitist jerk!!

  14. Many of those macros are bits of metadata passed to moc so that it can output proper code. Most of the time, you should not need to use them. The equivalent functionality in most other languages would involve similar decorators. (Or in the case of GTK/GObject, doing everything by hand.)

    Unless you’re doing something embedding scripting, you usually only see:

    Q_OBJECT – adds a few virtual functions and is a notifier for moc. This is the only one that could be qualified as boilerplate.
    Q_SIGNALS/signals – (the former is better namespaced and works even with the option that avoids namespace poisoning) it is a notifier for moc. The macro itself merely expands out to protected.
    Q_SLOTS/slots – again a notifier for moc. This avoids generating hooks for every function. The macro itself expands to…. nothing!
    emit – syntax used for calling signals. Guess what purpose this serves? Absolutely nothing! moc never sees it, and the macro expands to nothing. It’s solely for better syntax. emit foo(5); is simply foo(5); God forbid the Qt developers tried to make the programmer’s life easier. I suggest the GTK people, instead of complaining, try the same.
    SIGNAL – converts to string and prefixes with 1
    SLOT – converts to string and prefixes with 2

  16. @Sean and David: I don’t know how often I need to repeat myself before you guys realize it, but I have written it a few times now that I’m not defending GObject/C at all. Perhaps wait with your raging anger for after you have read whatever you are commenting on. Sometimes that helps you keeping your reputation in shape.

    If you insist on me giving a language that I would ‘defend’ against Qt/C++ (my true opinion is that in the end all languages suck) then let me point you to the languages D and Vala. And feel free to compare Qt’s moc with those two too. Note that I already wrote that I don’t see Vala as a C code generator. That it uses C for passing to a C compiler like GCC is irrelevant for me. Especially given that it’s a complete language on its own.

    @mou: Thanks! those are very helpful hints. I might actually use some of them. Like now I know why I’ve seen that QPointer thing a few times. Interesting.

  18. @pvanhoof

    there is a thread-safe version about, there must be a reason it isn’t included in Boost.

    …and that leads me to: ” “because C++ is more powerful” is just utter bullshit”. boost:: ? Templates! Typesafe-namespaced-no-macro-metaprogramming. Of course the power of a language is very subjective, but even a dyed in the wool C-programmer has to love somehting as beautiful as Eigen2:

    http://eigen.tuxfamily.org/index.php?title=Main_Page

    http://eigen.tuxfamily.org/index.php?title=API_Showcase

    …lets all just get along. Most Qt programmers love Qt. Most vala users love vala. Only gtk/gobject programmers consistently express distaste for their tools, *but* they get along and they write programs as good as anyone else.

  19. >> @Aurélien Gâteau: aha, what about proposing a patch to boost that makes Boosts’s signals thread-safe?

    That’s silly. Qt’s already works. Why would a Qt dev bother with working on boost signals/slots?

    >> then let me point you to the languages D and Vala.

    Good luck getting decent tool support for either of those. Sure I see the advantages of “C++ with 20/20 hindsight” which basically describes both D and Vala, but in the end we live in the real world. For a hobby project it’s fine to choose whatever, but for the real world, you want a nice IDE, you want tool support, you want examples written in the language you’re using, you want good documentation, and you want maturity. Neither Vala or D fits the bill on any of those counts. They are technically “cleaner”, but I don’t see any real world benefit.

Comments are closed.