{September 3, 2009}   adventures in plasmaland, part 5: dataengines, classes, layouts

time for more javascript! yay.

First, a quick little thing: my last javascript post was slides from my LFNW presentation, which had an extra little thing about dataengines. I never did blog about that code, though.
It’s pretty simple. I wanted the time engine to give me an update once a day, so that I can reset the flag. For demonstration purposes, though, once a day isn’t so great, so I set it to reset every ten seconds instead.

plasmoid.dataUpdate = function(source,data)
progressValue = 0;
engine = dataEngine("time");
engine.connectSource("Local", plasmoid, 10*1000);

I define my dataUpdate function, which gets the source and data – but doesn’t actually use them. It just resets the flag back to red (maybe later I should set it to double-check the date, in case there’s a forced update). then I grab the time engine, and connect the local time to my plasmoid with an update of ten seconds.

now for something a bit harder: I want more than one task.

So, first attempt. I put the task creation into a function, and calling this function made things work just the same as before. So far so good. Next, I changed all references to the label, icon and progress counter into arrays. New tasks are appended to the end of each array, and the dataUpdate clears them all. the config UI only controls the name of the first task for now; a second one is hardcoded in there.

Then I realised that the slot for changing the flag could only work for one icon. huh. :/ maybe it would be possible to add the function to each icon? but it’d still not know its index in progressValues. what I really want here is for the label, icon and counter to be wrapped up in their own little class. and if that class was a widget with its own layout, then I could easily stack them vertically instead of having everything all in one row.

I haven’t a clue how to do classes in js though. inheriting graphicswidget, creating slots…
well, I read up on javascript prototypes, and found out about the extends keyword… but I bet we don’t have QGraphicsWidget in the js bindings. :P ok, for now I’ll skip the inheritance.

I spent a long time trying to understand how to do classes in javascript. It’s weird. It hurt my brain (probably didn’t help that I was half asleep the whole time). I did get it working eventually, though. and then discovered that connecting signals and slots in javascript didn’t work quite as I thought it did. if you want to connect to a function that’s in your class, you have to use either foo.mySignal.connect(this, this.mySlot) or foo.mySignal.connect(this, “mySlot”) – with these it refers to the function in the class (not a global function) with “this” properly set.

Here’s the code using classes – I ended up reorganizing the code a bit in the process. There’s the Task class constructor, which sets up all the variables (label, icon and progress counter) and layouting and connections. Then there’s the reset function, which is called on timeout, and the moreProgress function, called when the icon is clicked. After that I have some setup code that creates two Tasks, and the old dataengine and config stuff. Only the name of the first Task is configurable, still (and I’m being bad and setting it directly instead of putting a function in the class for that).

So now what? Well, the layouting is ugly. Let’s see if we can improve it a bit. Wow, I managed to crash plasmoidviewer. It doesn’t like me doing new LinearLayout(plasmoid) more than once – riight, because the plasmoid itself can only have one controlling layout. I want new LinearLayout(layout) to have layouts inside layouts. Fixed that, and now I have nested layouts. :)

Notice that the flags aren’t aligned with each other. that’s what happens when you put hboxes in a vbox instead of using a gridlayout. I could hide it by putting the icon on the left, but really I should do it properly…
uhm. looks like we don’t have gridlayout bindings ATM. we do seem to have qgraphicsitem bindings… but I don’t want *those* any more, because with a gridlayout there’d be no point.

Oh well – I think that’s enough for now. I’m going to go work on something else… or see when lunch is… :)

Emil Sedgh says:

Javascript bindings will be usefull only when we have bindings for whole stack. Unless all you want to do is to wrap a webpage using webkit :)

So, is there any progress on Qt bindings for whole Qt and whole kdelibs?

Comments are closed.

et cetera
%d bloggers like this: