Reading planet.kde.org the last few days has been great. There have been several great blogs about akademy.br, a regional Brazilian KDE event that kicked off this year with its first installment. It looks like they did a great job with it and I can't wait to see next year's event. The number (and quality!) of regional KDE events just keeps growing: Akademy.es, Camp KDE, Akademy.br. This is an interesting evolution from KDE only participating as part of other conferences (something we still do, believe in and get a lot out of), through to Akademy growing up as our own themed conference to an increasing number of KDE specific events around the globe.
This reflects the growing efforts in KDE itself, I think, something that can also be seen on planet.kde.org. Frank updated us on the progress ownCloud is making to free the cloud for all, Roozbeh wrote up a bit on Chakra Mini which is yet another Plasma Netbook based offering and Marco showcased the work of Bjorn Ruberg on the Plasma On-Screen Keyboard complete with a video of it running on two different devices:
OGG video version
This is really all just tip-of-the-iceberg stuff, as you might imagine. There's work underway to provide a Plasma front end for KDM, for instance. The most interesting thing for me in all of that (besides standardizing look and feel and the generally neat things we'll be able to do with it visually) is that KDM will get things like that on-screen keyboard for free. This is the kind of stuff people had to hack into KDM in the past (and did, in some cases!), but which we'll now be able to say is just part of the standard kit. This is also an interesting example of how different hardware formfactors (in this case touch and mobile in Plasma workspaces) are helping drive improvements elsewhere as well (in this case accessibility in KDM).
Another interesting example of this is work being done to streamline the KDE Development Platform for non-desktop scenarios that finally made it's way out of the KDE Maemo (should that be Meego now?) team onto kde-core-devel with this email from Kevin Ottens a couple days ago. Everyone will benefit from people casting a critical eye on this key shared set of technologies.
There is so much more like that going on around KDE. We don't always do the best job communicating it out as many of us are busy and having too much fun working on these things, and sometimes the communication side of it gets less priority than our users and downstreams probably would wish for. :)
Still, the KDE steamrollers continue on paving the way forward for all of us who rely, or would like to rely, on Free software on all our computing systems. Efforts to coordinate that energy even more effectively are underway and ongoing and we have so many exciting challenges ahead of us (including really "simple" but actually difficult ones like, "How do we improve our documentation?") that I don't see it getting boring any time soon.
Subscribe to:
Post Comments (Atom)
9 comments:
Hey, just a friendly suggestion..
Wouldn't be nicer if you embedded the .ogg video and gave a link for the flash one instead? =)
Will Plasma-KDM be ready for KDE SC 4.5?
One thing I didn't see in the video and was curious about; an easy way to hide or "minimize" the virtual keyboard.
I was thinking about this in the context of KDM; if, for example, the password field is covered by the keyboard, and the user doesn't know to use Tab to switch fields, it could leave them confused.
On a related note, does the keyboard ever adjust its orientation and geometry according to the text entry area that's selected? Or does it always try to resize the content to accommodate the keyboard?
I'd imagine that something like KDM probably wouldn't react well (appearance-wise) if it were asked to squish itself into a tiny space, so how would that get handled? The amount of variation between KDM themes (and the currently rigid theming syntax) would make it pretty hard to write such adaptability into the code.
This would be easier if KDM were to use QML or Plasma for theming, but from what I gather, that's still a ways off.
@Zayed
No, sorry, that's impossible :)
I am working on it currently, but I am also hoping that I will be accepted for GSoC, wherein I can work on it fulltime.
Considering the soft-feature freeze for 4.5 is April 26th, and the hard feature freeze is May 11th. And it is April 14th.
I'm not *quite* that fast ;-)
@evergreenpsyche
I don't think you understand.
KDM themes will be not used in the Plasma frontend; instead, the Plasma themes will be. Therefore we have a lot more flexibility with it, given to us with no real extra amounts of work required..
"This would be easier if KDM were to use QML or Plasma for theming" [snip]
It would use Plasma for theming (as mentioned)...which is one of the big bullet points of running Plasma on KDM :)
The whole "make KDM use QML" is overhyped imo. Plasma is already spearheading things like QML, along with the loads of other features that it gives us. Building a frontend for *just* QML is going in the wrong direction. Instead of having unified themes, we would be creating separate ones. Instead of having easily creatable (and unified) widgets, we would not be having really any at all. Not to mention the wallpaper plugins that are instantly usable in Plasma-KDM.
So it isn't really a ways off, I have already gotten it to "work", and have witnessed the leet marble wallpaper plugin at work ;-)
(although that was the more easy part of this task/project).
You can see my blog entry if you want more persuation/facts ;-)
@Shaun Reich
Actually, what you described is exactly what I meant (using Plasma themes in the corresponding frontend for KDM).
As far as QML vs Plasma for KDM themes, well, that's a debate with two coherent sides to it. Both have their merits and drawbacks, and I imagine that eventually, both might be implemented as usable frontends.
What I was really talking about was the presence of the virtual keyboard and its effects on the content displayed on the screen. In the videos showcased by notmart, it seems like whenever the virtual keyboard is present, the content on-screen gets resized to make space for it.
My comment on that was that it would be difficult for KDM to handle that resizing with its current, supported theming capabilities (in a stable branch, at least). The next generation of KDM theming (as proposed by developers thus far) would be flexible enough to accommodate it, but the older (i.e. currently used) theming engine is not.
What I'm really getting at is, is it possible to dynamically adjust the position and geometry of the virtual keyboard with respect to the selected text-input-area so that resizing of the on-screen content is not necessary?
Basically, while the resizing is fine for plasma-derived objects and web-browsers, it seems like it would be an ordeal for more rigidly themed constructs such as the present-day KDM. A more dynamic virtual keyboard would accommodate the soon-to-be-legacy KDM themes without obsoleting them.
note: I used the bold tags in an attempt to highlight the most important points in my post, not to imply shouting or aggressiveness. I apologize if it comes across that way for anyone reading.
I'd also like to see the possibility of pairing bluetooth devices in KDM: given access to Solid, KDM could detect whether bluetooth is available and whether there are more conventional (e.g. USB) input devices before scanning for bluetooth keyboards/mice.
This is important for new iMac buyers, since they all now use wireless peripherals.
@evergreenpsyche
"it would be difficult for KDM to handle that resizing with its current, supported theming capabilities (in a stable branch, at least)."
Well, to be honest...it would not make any sense to resize the KDM screen content just to use a virtual keyboard. That only makes sense in this small device example, where the constraints of the screen are very important, and none can be wasted. For KDM this does not apply.
As for adding an onscreen keyboard in KDM without Plasma..well, that is precisely one of the major points of making it use plasma..to get the onscreen keyboard for free, as there would be great difficulties in trying to create a *separate* (mind you), keyboard just for the old theme engine. And it should go without saying that it could never be as good, or anything near it, from what I predict.
"is it possible to dynamically adjust the position and geometry of the virtual keyboard with respect to the selected text-input-area so that resizing of the on-screen content is not necessary?"
Hm..are you referring to how, for example, the Playstation 3 does it?
http://www.youtube.com/watch?v=xTIVmZfN3lQ
Look at 4:25-ish.
I suppose that is what you have in mind.
I don't like the idea of "light versions" of kdelibs for mobile devices at all. I want the full kdelibs ported to them so all the great existing KDE applications just work, without requiring any porting.
I'm really afraid of multiple "profiles" of kdelibs diluting the value of the KDE development platform, splitting it into multiple incompatible platforms.
Today I thought "if only I could make this window in Dolphin into a Folder View". Then I remembered I could just drag the folder onto my desktop.
Post a Comment