data engines and transitions

i got some more work over the weekend in on plasma, though it was pretty low key due to everything else going on. i wrote a small engine that grabs rss feeds from cia.vc and publishes them.

this enabled me to test some new data engine features that are needed, such as placing an upper limit on the number of data sources available with an engine. the least used ones get dropped off automatically when a limit is set.

then i wrote an applet that starts to display the current strengths and weaknesses of the new layout stuff, which is still in its infancy. but in 127 lines of c++ code, including the header, it displays the information published by the cia.vc engine in a series of text boxes in a vertical layout. now that we have something that demonstrates the layout code easily, i expect that to start firming up even quicker. well, not that it was going slow lately, but.. yeah.. easier when there are real use cases about.

which was my entire intention with writing this engine/applet pairing. though it is neat to see kde's commits on the desktop =)

my plan had been to work on a transition effects class which i'm tentatively calling Phase. i did the design this afternoon based on thoughts that have been collecting for quite some time on it. in essence, the idea is to allow this class to manage all manners of animated transitions: objects appearing and disappearing, sliding, joining, getting attention, etc.

the base class handles managing the timelines (which controls the animation firings) as well as informing the Corona (which is the plasma graphicsview implementation) when the animation is complete. the base class then calls the actual animation producing methods which get all the state information they need delivered to them.

it will support pluggable implementations so we can ship a basic (e.g. none ;) transition implementation but people can create pretty much any sort of transition they can think of and code up.

there will be one method per transition type, and the method will be called with a QGrahpicsItem object and where in the animation it currently is. that means that creating new animation sets means simply working on the animations themselves, none of the boring framework bits like the timelines and what not. that's my job ;) given the ability to draw on top of, around as well as modify the passed-in QGraphicsItem itself this should be a pretty flexible system that opens up all sorts of doorways for useless eye candy ;)

this, along with a few similar things that we're doing, should also allow plasma to also scale from a high end system with a local desktop to a low capability system running a desktop over the network simply by setting the complexity of the effects and imagery.

my goals this week are to get the start of script support, ghns2 and packaging (working with ruphy towards that end) and grouping... lots to do, indeed, but the progress is encouraging me to go even faster =)