plasma now responds to changes in screen resolution. i added support for this yesterday but i wasn't getting the proper signals from QDesktopWidget in response to xrandr changes. apparently you really don't want more than one QDesktopWidget instantiated (even briefly!) if you need to listen to these events; instead always use QApplication::desktop() to get a pointer to the application global QDesktopWidget.
with that oddness fixed and behind me, a little testing fixed some issues in my code and now panels and desktops rearrange themselves quite neatly. yay!
it works pretty differently than kicker did: Corona listens for screen resize events. it then goes through all the Containments on the scene which are associated with a given screen and re-assigns them to the same screen causing an adjustment in their geometry.
meanwhile, plasma-the-application resizes the desktop widget and views. when the Containment adjust themselves, it results in a signal being emitted which is caught by the desktop and panel views which then adjust the area of the Corona they are viewing to match.
the result is a silky smooth change without any particularly visible jerks or pauses. at least here =) i'd appreciate testing by the xinerama crowd as well as those with various x.org setups to ensure that it's as smooth on your machines as it is on mine. baseline to compare against would be kicker and kdesktop in kde3. the goal: smoother.
zooming also works a bit better now due to some attention paid by jpwhiting; kevin ottens nearly has the hover-handles which provide generic access to movement, configuration, resize and rotate of applets working perfectly; Bertjan continues to improve the Package classes with his unit testing rampage ... and of course the various plasmoids continue to improve.
we've turned up a few more bugs in QGraphicsView over the last couple of days, mostly ones that impact performance. Andreas is on the case, so we should see resolution of those at least for 4.4 if not even sooner (depends on how tricky some of the fixes end up being and what his work load is like; not all bugs are equal after all =).
i've also got multiple panels working nearly perfectly; the last bit is to do geometry conflict resolution. right now new panels realize when they are in conflict with an existing panel, but i haven't written a way to resolve those conflicts. i needed the xrandr stuff working first to make sure that the geometry conflict resolver works properly during screen res changes.
this also gets me to the point where i can work on the PanelLayout which will resolve outstanding issues with the layout, movement and addition of items on panels.
i started the morning by seeing how long it would take to implement a basic on screen keyboard as a plasmoid. turns out the answer is "just over 9 minutes". thanks go out to digilander and mrosewarne for hooking me up with some svg's to use. the only downside is that to make it work requires a patch to QSvgRenderer so i can map clicks to elements in the svg. which means i can't check it in. well, yet. =) the plasmoid is -very- basic; for instance, it doesn't allow switching svg's for different layouts (though it could, with xkbcomp and xkbprint perhaps autogenerate those on the fly at runtime even!), it doesn't keep state for modifier keys (who needs capital letters anyways? ;), etc ... but it draws and you can click. yay!
once the QSvgRenderer thing is sorted out (i need to clean some things up in the patch and then send it on to the TT engineers) i'll check it into playground in hopes someone will pick it up and run with it. if not, it makes for a fun something-to-do-when-i'm-not-quite-awake-yet.
finally, the other day i mentioned something about speeding up KIconLoader::loadIcon(). after some hunting through it again with Hamish Rodda, due to kdevelop4 still hitting a nastily slow path, he spotted a code branch where the icon wasn't getting cached properly resulting in a very slow path being taken each and every time on the way to the now-faster caching path. after his commit the treeview painting time went from 2.5s to 0.1s. just shows how slow some of those paths in KIconLoader, KIconTheme, etc are and how important the caching is (thanks Rivo!!). in kde3 we cached in KIcon, but this new solution is even better as it is both not specific to icons and allows caching benefits between runs (even of different applications). yee-haw.
i also wrote a poem, got p. off to school and picked him up again, got a bit of a chat in with Zack in the morning (hacking on QSvgRenderer was a great excuse for that ;) who it turns out has a new (and rockin' if i may say so) hair do and also managed to eat lunch. not a bad day.
now it's time to make dinner and read some Tintin with p.