Besides taking the P-man to school (and picking him up after), doing sink full of dishes, re-arranging P's room, putting together a new computer chair, preparing three meals today and getting rid of a huge number of full-screen repaints for Containments ... I essentially rewrote the Twitter Plasma::DataEngine.
It was one of the older engines, and as such had a lot of less than pretty work arounds inside it. What really motivated me to finally look into was that it used QHttp, which means all sorts of bad things like not knowing about web proxies. Thiago is about to commit a change to KDE's CMake support that will deny QHttp usage in KDE apps because it is just that broken.
So I slapped on my hip waders and started tearing the engine apart. First I created a pair of DataContainer classes (one for the status timelines and one for getting user images) that encapsulate the individual HTTP requests; now the TwitterEngine doesn't have to multiplex all those jobs and the code to massage the results into order is neatly tucked into each class.
Finally, I created a Plasma::Service so setting the password for an account or updating the status (aka "tweeting") is not hackish at all anymore. Even nicer, the password is no longer visible outside of the DataEngine itself.
Update: In my rush to write this entry, I completely forgot to include the conclusion: that the DataEngine pattern used along with KDE's libraries and Qt makes it easy enough to write something like this in just a portion of a day. The new engine is also only about 20-30 lines more code than the old one but a hell of a lot more readable and debuggable, which shows how nicely the DataEngine classes have matured over the last year or so.
Thankfully the Twitter plasmoid was the only user of this engine, so I was free to change things about nearly at will like this. The downside is that right now the Twitter plasmoid is rather broken in svn. Tomorrow I'll be hacking on plasmaengineexplorer so that one can interact with Services associated with a DataEngine source and fixing the applet.
I'll also be finally adding a DataEngine design description tomorrow while I'm at it. It's kind of impressive how many details have been covered in the DataEngine classes to make it stupid simple and efficient to use, but things are fairly well in order now it seems after another round of improvements were made for 4.2, mostly induced by increased usage of Plasma::Service and Plasma::DataContainer subclasses.
On Thursday I have a Nepomuk meeting on IRC after which I will hopefully have enough in place to talk about the work on publishing Contexts to the desktop evironment. I've already put the hooks into libplasma, but the Nepomuk side is still being defined. Until then, I get to work on other things ... like the Twitter stuff. Unfortunately, I only got out half the emails I was supposed to today, so I'll have to finish those off tomorrow as well.
Then next week it's off to finish of Service/JOLIE integration and clear out the panel hiding TODOs.
No rest for the wicked ...
It's also apparently "reconnect with Aaron" time of year: not only has the P-man returned (though that was expected), two old friends that I haven't talked to in a while (one for nearly a year, the other for nearly eleven years) showed up randomly in the last 48 hours for some really interesting conversation. I wonder who will appear next ... ...
Wednesday, September 03, 2008
Subscribe to:
Post Comments (Atom)

6 comments:
Where can we find that alternative for Qhttp?
@Alexei: I guess this will give you an answer: http://mail.kde.org/pipermail/plasma-devel/2008-August/000667.html
@Alex, the alternative is using KIO, e.g. with KIO::NetAccess or KIO::Job. See http://api.kde.org/4.0-api/kdelibs-apidocs/kio/html/index.html for details.
Amarok uses QHttp for its DAAP support I'm pretty sure. QHttp is much more low-level then KIO, or at least, a more logical choice when doing low-level http type things. And obviously proxy settings are pretty irrelevant for DAAP anyways.
Seems like a technological solution to an issue that should be solved socially...
hmm. i never quite liked that user images were the only bit of user data cached in the engine. i had plans to do somemthing about that, but i don't really remember them any more. i think it had something to do with making a source for each user, maybe. i dunno.
Ian: What is more low level on QHTTP? I don't see any reason for that. And why should it be a "more logical choice"? Can you elaborate on that? I don't think it's true.
Post a Comment