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.
Subscribe to:
Post Comments (Atom)
15 comments:
And goodness flowed from all directions. Great update
Nice speed improvements!
I miss Tintin, they don't have it almost anywhere here in USA. I used to read it all the time when I was a kid in Argentina.
Aaron, I don't know if anyone else has asked but is this still relevant?
Hi Aaron,
Can you please answer to a (maybe) stupid question from a basic KDE user/fan?
I saw maybe two days ago a post on the planetkde, this one : http://jucato.org/blog/after-all-thats-been-said/#comment-6963
In fact, I do agree with that guy and I think that it's not a flameware but just reality.
Even if the link is not easy to guess, this made me think to one thing : the new (and I hope great) KDE took a long time to get ready, more or less two years I think. What will happen if next year or in a couple of years Qt 5 gets out with again a very different API but with great new features?
If you have an answer for me, I would be glad.
Sorry for the real "off topic" question and thanks in advance.
@temet:
Qt5 won't be a API-Break and won't be out before 2012, I think.
@temet : QT5 is not likely to happen in the near future. Here is the roadmap : http://aseigo.blogspot.com/2007/10/qt-roadmap.html
@stripe4 : I also remember that story :). Now it would be more efficient to to use qtscript and webkit (I'm not saying that khtml is bad, but it's simply that OSX use webkit too). So it might be better to wait qt4.4 and kde4.1 to start a project like this.
Thanks guys :D
I've missed this topic from Aaron :x
fucking awesome. :)
...speaking of tintin, I got a chinese tintin book here. it was at just the right level for my current reading ability; lots of words I didn't understand, but I could usually figure them out from context :) I've gotta go buy some more of those.
Scorp1us here... I read about you wanting to hook up events to elements in Svg, this is something we've wanted to do for a while, but I think as soon as you add that, you'd want essentialyl DOM support to, so you can re-arrange the items in the file.
Unfortuantely, SVG does not have layout information. (Right-align this fixed-sized text against this other element) so this would require the SVG to be imported into its own layout scheme. I was thinking that with DOM support, there could be a layout proxy that maps by ID and moves elements accordingly. This scheme would then allow you to get at the individual elements and accomplish want you want, and a whole lot more.
Ahhh Tintin...do you still have all your books from when you were little? How about the Asterisk and Obelix stories? THOSE were great!
Jaye
ps. That should be Asterix not Asterisk! And you can get them on ebay..I just checked! :)
Jaye
Can't wait to try kde 4 on a triple monitor setup and see how it fares. Tintin is generally racist (read tintin in the Congo for horrifying examples). Blacks and Asians (particularly the japanese) are portrayed in a terrible fashion. I believe the author even made a public apology for tintin in the Congo.
@stripe4: yes, but not before 4.1 due to QtWebKit availability.
@Temet: yes, kde4 has been a long time coming. after 4.0 we'll be back to the usual churn-out-a-release-every-6-9-months schedule and this will be a footnote in our history in 2 years time. this is exactly what happened with 2.0, as well, and you don't see people gnashing their teeth about that now, right?
and here's the rub: you can certainly incrementally improve what you have and release with a constant pace indefinitely. unfortunately, doing this leads to an increasingly irrelevant and dated system. at some point you need to take some bigger steps.
if we look at the corporate world (if only because we have a few centuries of really good data there) you'll see similar things such as with the Boeing 747 or Toyota's current hybrid strategy. there's lots of ways to do the Next Big Thing We Have To Do, but it almost always comes at huge risk (where the risk is complete failure for the organiazation!) and takes a lot of resources and time.
i recommend reading a book called "Built To Last" if you interested in such topics. they cover a lot more than this one aspect of building organizations (their data is corporate, but it applies generally) that are meant to go the long haul.
too many free software projects, due to the pressures of "internet time", the slashdot user mentalities and things like Mark Shuttleworth's "every six months! every six months!" marketing campaign lose sight of the mid term, let along the long term.
short term views will give you success in the short term, but almost always relegate you to second (or worse) place in the mid-to-long term.
what i'm saying is that, yes, it's a hard road but it's one we needed to take to ensure our future.
and as already noted, there are no plans for a Qt5 right now at Trolltech, and *if* a Qt5 were to happen, it wouldn't be before 2013.
@Scorp1us: i'm not trying to do a full event model, just basic "what element is at that point" and i'm faking the rest ;) i agree something more comprehensive would be awesome and should be possible with enough effort.
in fact, ksvg is exactly that. i have a screencast video here showing inline editing of objects in an svg, including text on a path, using ksvg in qtwebkit. pretty neat, huh?
@anonymous-the-latter: agreed. one thing i do make clear to p. when we're reading these books is that they are a reflection of an older time when things were different. i encourage him to notice the differences and we do talk about some of these issues.
Wow Aaron, I didn't actually expect something that quick. Awesome stuff. I really think a on screen keyboard as a plamsa app is a beautiful thing not only for the impaired but as I said before for tablet PCs. With these little touchscreen PCs coming out and being so powerful something like a integrated software keyboard is ideal. I can think of at least 3 current devices that you can install Linux and run at least KDE 3 that don't have keyboards plus the tablet market there's even more. Right now I'm using Viki for a keyboard on my TPC. For a standalone app it's not bad but SVG themes added to it would be awesome also. So the Viki maintainer may want to look into Plamsa further and maybe pick up the project. Thanks for all your hard work. If KDE 4 is half as successful as the hard work you all have put into it it will be revolutionary (already is for me).
Thanks a lot for your answer Aaron.
In fact, the book will wait, I still didn't find the time to finish "The Book of Qt4" ;)
Post a Comment