Developing my first plasmoid Part 1

I have three main hobbies: photography, my webcomic and programming.  After spending a year working on my 365 Project, I’ve been taking a lot less photos as that part of my brain takes a break.  After working with Dan to get the story for INM worked out through May of this year and working on strips that will appear this March, I wanted to take a bit of a break from that.  The one bit of code I wrote for myself that I use on a daily basis is my flickr views code.

I’m involved in a series of groups on flickr where you place photos based on the amount of views they have.  Some people refuse to participate because they see it as a form of bragging.  I like using it because it’s the simplest way I know of tracking how my photos are doing.  When I see a photo is ready to move to the 200 views group, I know that photo has at least 200 views.  And it’s been very interesting to see my photos progress through the groups.  For example, some photos I shot this October during Halloween in NYC already have 500 views, like this one:

Katy Perry's Too Tasty to Resist
Not too surprised, except a bit about why it doesn't have even more views

Other photos have been in my stream for nearly a year and are just getting to 100 views.  In a lot of ways, it’s those photos that make me really enjoy the process.  In much the same way as the Photojojo time capsules that I post here twice a month, it’s a way to revisit photos I’d forgotten even taking and enjoying them again.  (Or wondering what I was thinking)  So, I wrote a commandline script I wrote that lets me know when it’s time for a photo to advance to the next group.  I first mentioned it back in 2008 (almost exactly 3 years ago) when I first came up with it.  The next logical extension was to create a script to add photos into the groups as they reach 25 views (the smallest group).  And I did that in March of 2008.  Finally, I created a web app to share it with others.  I know at one point a lot of people on flickr were using it and it even was making up a huge portion of my non-blog server traffic.  I think it may be seeing less use nowadays with people moving onto some more AJAXy, fancy sites, but it still accounted for 218 hits so far this month.

Things have been good and I haven’t made too many changes to it in the past three years.  I had to do a bit of a change to the XML parser after the API I was using changed, but that’s all.  And, ever since some time last year or so, I can just click on the URL in either Gnome Terminal or KDE’s Konsole to load up the images into my web browser so I can move it into the new group and out of the old one.  I probably could figure out some way to automate that too, but I couldn’t think of a nice elegant way.

Ever since I got back into KDE in Nov of last year, I’d been thinking of perhaps making a plasma widget to do this.  This would allow me to more easily automate the moving of photos into groups (via a button) and also allow for some graphics.  Plus it was an idea for a plasmoid that wasn’t yet another system monitor or weather app.  I’m not sure how many people out there are in the subset of KDE users in the subset of Linux users in the subset of Views groups users of flickr.  But even if it’s just useful for me, it’d make me happy.  However, I knew that GUI programming was hard, so I put it off into the future.

Recently the wife wanted to go to JoAnne’s so I went to Borders and the latest issue of Linux Format Magazine (which I used to be subscribed to) had a QT programming example.  I bought the issue solely for that.  It had this neat tutorial on QT Quick which is this semi-new prototyping language based on Javascript.  In just a few lines of code (less than 100 for sure), Graham Chapman showed how to create a program that would take a geo feed from flickr and map the photos onto Google.  It’s pretty amazing!  Check out the screenshot of the one I made:

My RSS Geo Program based on Linux Format Magazine Code
My RSS Geo Program based on Linux Format Magazine Code

That’s pretty cool.  But I already had my flickr program written in Python and I understood how python worked so much better than this new language I’d never heard of before now.  So I decided that I would design my Plasmoid in Python.  God, what a nightmare!

First of all, according to the documentation (which does tend to be out of date when it comes to FLOSS), you can’t use QT designer to make your GUI for a plasmoid.  So I had to try and figure out how to make my GUI from scratch with very sketchy and very few examples available for Python.  Usually, like [most?] programmers, I look for code that does this or that function that I want so I can use that to learn how it works.  Just trying to figure out how to clear the screen and stuff like that was such a pain.

I was very lucky to have notsmart, aseigo, and einer77 slowly work over things with me while I tried to figure this out.  In the end I decided that the best thing would be to have tabs instead of trying to clear the screen.  It took me 8 or so hours to come up with this:

flickr views main screen
flickr views main screen
flickr views results screen
flickr views results screen

I was DARN PROUD of having come that far.  Shoot!  I didn’t know jack about QT GUI coding and barely anything about GUI programming in general.  I had done it – I had ….. I had something that was less functional than the CLI.  At least with the commandline I could click on the URL and get to the webpage.  I couldn’t even do that much with my plasmoid.

And there are the stupid headaches involved in QT programming.  For example, when you click a button, you can’t pass any arguments to the method/function you call.  It’s maddening.  When I thought of the work I had yet to do in order to get the plasmoid to where I wanted it to be and how easy QML had been, I realized this was not the way to go.

Aaron Seigo had suggested as much as he helped me work my way through the Python code (of course this was in hour 6 so I wasn’t ready to throw away the previous six hours of work just yet).  Of course, I also had to separate the data out into a dataengine.  Right now, the data is looked up when the user clicks the button.  For users like me that have over 1600 photos in a group, the performance is unacceptable.  And, I hadn’t even handled what to do when the API is unavailable.

I’m not an elegant programmer in the best of times (I enjoy it, but I’m def no prodigy like the kids I went to college with) and I was learning GUI programming as I went along so this code probably looks like crap compared to how it should, but I want to attach a link to my code here so that if someone is trying to make a plasmoid GUI in Python, they at least have something to work from.

Click here to see it.

Just comment out the flickr-specific stuff.  I can’t upload that because I haven’t sanitized it yet.  For comparison purposes, here’s the main code from the RSS reader (missing the delegate code)

Click here to see it.

So, Aaron suggested that Python and QML can be combined with KDE 4.6 libraries.  Unless I understood something incorrectly about what LXF said was needed to do their QT Quick coding tutorial, I have the QT 4.7 libraries or something like that on my computer.  Anyway, last night as I was going to sleep and this morning as I woke up, I saw in my head some of the ways in which doing the interface in QML would make my life so much easier.  It seemed to do for interfaces what Python does for arrays – make them easier to work with by having lists, tuples, etc as primitives rather than concepts sandwiched onto arrays.

So my current plan of attack is to generate some fake data to get a GUI working (and I think I’m going to go with a completely different layout for the GUI).  And I’ll make a couple dummy groups on flickr to test the ability to add and remove from groups.  One thing I need to deal with before unleashing to the public is the fact that only 5 photos may be added to each group per day.  I need to make sure I handle the errors correctly.  I also need to work on this dataEngine that will provide the data for the Plasmoid.  I envision having the data already pulled so that there isn’t a delay for the user of the Plamoid except on first loading.  But, since plasmoids tend to live on the desktop, hopefully by the time the user gets around to polling the plasmoid for data, it’ll be there.


As of now I’m not sure if I’m going to post updates on my interim progress, but I’ll be sure to post when I’ve got the final Plasmoid working.

Published by Eric Mesa

To find out a little more about me, see About Me

5 replies on “Developing my first plasmoid Part 1”

Comments are closed.