QML to KDM! Presto!!
24 December 2009I’m really surprised you’re still reading, since the title really explains it all.. but for you, my beloved reader, I’ll spend some words more.
The KDE login Manager
The login manager is the “insert password” dialog that gets in the way when you want to use your computer. Of course you may not be the only user of the machine, so it’s somewhat needed when you share the seat. Some facts:- the honorable Stephan ‘coolo’ Kulow landed it in cvs Sept 2nd 1997 (yes, that’s 12 years ago)
- great people like Waldo Bastian and David Faure worked on it
- it’s now maintained by the über-expert Oswald ‘ossi’ Buddenhagent
- I did the graphical themes support, implementing the GDM themes spec back in the KDE3 days
- “The first thing you’ll notice about the new KDE 4 is it’s old login manager” – as David Vignoni says in his controversial blog entry,
The funny thing is: 1 year from now Win7 and MacOS will stare at KDM with envy!! Read on to know the future history.
Kdm Top to Bottom
Let’s say that KDM rocks ‘backend-wise’: multiple-seats, integration with running sessions, XDMCP and all the other stuff that makes kdm the top of the class. But what do you find in $SVN/KDE/kdebase/workspace/kdm ?
- backend/* -> the display management core
- kfrontend/*.{cpp,h} -> 90’s GUI, there is even an aliased analog clock..
- kfrontend/themer/* -> graphical themes stuff (just 2243 source lines of code)
The themer, which is used by default, implemented the gdm theming specs but it was never package-compatible (afaik) with gdm (we lost a good inter-op chance there). It was implemented in the KDE3 days, so we had to code our ‘backing storage’ to implement transparency between layers and in the end the themes are hand-written xml files that embed some default components (line-edits for user/pass insertion, listview for user list, etc).
It looks so old-style, doesn’t it?
Qml to the rescue!
What if we throw away (or keep for “retro-compatibility”) the classic and themer frontends and just add a frontend using QML? This is the name of the language of the Qt Declarative module, that has just seen the light and will be merged into Qt for the 4.7 release.
Imagine this:
- theme creators will have 100X or more expressive power: make snow! login via a tetris puzzle! bounce my webcam picture!
- there will be animated themes (for login, user change, logout, etc..) or simple ones for more ‘classic’ kind of people
- kdm only needs to add a couple of bindings to the qml runtime, like functions for logging in and shutting down / suspend the system
- there is no need for compiled binaries, packages will be interpreted by the qml runtime – finally a painless get-hot-new-stuff (compared to plasma widgets, at least).
Conclusion
I’m not able to mock-up what comes to my mind, but just look at some qml videos on youtube to grab the concept.
What do you think about that? Could this be a low-effort high-inpact development for KDE 4?
Thanks to Davide Bettio who made me blog this.
Wasn’t there some talk of having libplasma linked into kdm? That way, you’d be able to use existing Plasmoids, as with Chani’s work on the Widgets on Screensaver, and I believe there’s some work to integrate QML with Plasma.
Yes is a great thing, we need to improve kdm, we need a beautiful login manager and one more functional, this could be the key to achieve it.
I’m curious, would QML be dangerous from a security perspective? Would themers writing QML have to be security experts in order to avoid accidently having holes in the login?
You made it sound like it might be too flexible.
I would love to see KDM add QML when 4.7 gets here. And more of all see more parts of KDE4 get added to QML.
instead of inserting her password, that could be nice if we could click on different area on the image… to simulate a password
I wanted to re-write KDM using Plasma, but I don’t have the time for it now. I’m glad to see somebody is working on making it easier to theme. Now, if we can just get GTK+ and GDM 3.0 to support QML…
Mmm, I want Plasma and others to use QML :] .
Oh, and Amarok! When it gets Phonon with equalizer [my requirement for audio player].
I’ve thinking on this since i’ve watched the first QML videos, looking forward for someone to code it.
So who is going to write the code? 🙂
Livio: In my function as a music and HiFi snob I have to say: If you need an equalizer your stereo sucks.
@anon, Alex: plasma’s good, but frankly it’s always changing, you don’t find any good scripted applet around, you can make it crash too easily. On the other side, qml+kdm api can be one, stable, and well defined starting from day 0 and lasting for years – something theme authors can really rely on – and we need to build *trust* after disorienting people with the early kde4 releases.
@ComputerDruid: nice question. the security model must be enforced by the exposed api, to avoid having a mad root script compromising your system. security can also be taken into account on the deployment phase.
@colinm: great idea. it can be a new way of authenticating people!
@Alex: gtk+ to support QML? 😉 for using kdm themes?? 😉
@Rp, @Quasar, @Andreas: It won’t take too much to implement this: we need to keep ideas and inspiration flowing… the code will come 😉
I totally love it!
IMHO KDM is still one of the apps that needs some love and modern feel that fits KDE 4. And being able to change its looks with QML were plain awesome – e.g. creating some 2 steps login like with CentOS/Gnome should be a no brainer, not to speak of all the shiny bling bling possibilities ;D
Please do it if you find some time 🙂
[…] This post was mentioned on Twitter by Martin Spa and Kwan, Ian Cylkowski. Ian Cylkowski said: #KDM really needs a revamp – introducing #QML for awesome login! http://2tu.us/1ayg […]
first, QML already works inside of Plasma. has from the first day QML was released (code is in playground still, for probably obvious reasons 🙂 and that support is worked on by the people who are working on QML.
@Enrico:
“plasma’s good, but frankly it’s always changing”
the API hasn’t “changed” in a BIC or SIC way since 4.2 (which is precisely what we roadmapped). if you’re referring to things in plasma-desktop changing about, then you’re confusing the Plasma library and it’s framework with one app that uses it. those changes have nothing to do with the Plasma framework, which is what should be used to create a KDM front end (more on why that is later). if you’re referring to the fact that we keep adding new things you can do with the Plasma framework, then i don’t know what the complaint is. maybe we should stop improving it so you can be happy with it? (yes, that’s sarcasm)
“you don’t find any good scripted applet around”
what’s your definition of “good”? have you looked on kde-look? have you seen the examples in kdeexamples? what’s missing for you?
“you can make it crash too easily.”
so, the crashes that exist in a rather limited number of places. many of them are in Qt, actually. so good luck with your “QML will solve it all!” theory. (and yes, we report all issues upstream that we come across as we all want them worked out.) the majority of the remaining issues are in very specific, but non-Plasma-framework, components; e.g. the task bar, which i assume one wouldn’t be using in kdm 😉
if you kept the Plasma driven KDM interface elements to JavaScript, HTML and/or QML you should be just fine.
so .. that said. why would you WANT to use Plasma in kdm?
because then you get access to widgets for free like an on-screen keyboard, audio levels, network management, etc. etc. that would make really nice additions.
because then you’d get access to numerous sources of data (like weather, as seen in your blog entry picture) for free.
because then you’d get, for free, theme compatibility with the other apps that use Plasma such as Plasma Desktop and Netbook, KRunner, KWin, etc.
basically, you get a whole bunch of features for free that improve the functionality and integration for free that you’d have to reinvent from scratch with a QML-only approach.
perhaps just as importantly, instead of creating Yet Another KDM Front End That Nobody Would Care About Enough To Hack On A Week After It’s Committed To Trunk we would get a front end that the Plasma team, one of the very active and exuberant communities around KDE, would actually care about and therefore likely help maintain and even improve.
writing a Plasma shell app is very simple. it wouldn’t be any more work than creating a QML driven shell for KDM, and it would give a lot more bang for the buck. have you actually looked into this?
@Aaron: I like plasma on my desktop. Nonetheless I think that using plasma is a *bad* idea for a login manager.
Reason 4.
Designers are more willing to speak QML language, not “plasma framework || scripted applets || plasma shell” language.
Reason 3.
Designers want control over their pixels, they don’t like a broken plasma theme compromising the rendering or unlocked layouts or removable widgets.
Reason 2.
I just tried installing the first 4 applets on plasma’s “Get New Widgets”. Only 1 worked, the other complained about some python and I think Javascript bindings for applets are not yet final -> I don’t see an easy way to make “plasma kdm themes” shareable. On the other hand pure QML+contents packages are portable, then shareable, like current themes.
Reason 1.
A login manager is a login manager: it must work, be fast and be pretty.
The User won’t change widgets or layouts, in the best case he will choose the most appealing and less intrusive “kdm theme”.
The Designer will create his artwork (and user interaction), package it and hope for it to be used by the most people across the globe.
QML makes User and Designer happy!
If you can prove wrong all the 4 reasons I’ve no objections to a plasma approach 😉 Anyway I can’t volunteer to do the QML kfrontend (I’m working on QtCreator, X11, fotowall and I’m full), so feel free to prove me wrong with a plasma one.
What needs to be done too, is integration of fingerprint-reader-login into kdm. The direction is, that we will (or already have?) have over 50% notebook-installations, most of them with fingerprint reader. Would be also much easier to use.
Enrico, I think you’ve lost me somewhere along the way. You start off with “The themer (…) implemented the gdm theming specs but it was never package-compatible (afaik) with gdm (we lost a good inter-op chance there).” and you end in “QML (…) is the name of the language of the Qt Declarative module, that has just seen the light and will be merged into Qt for the 4.7 release.”
Doesn’t using some Qt component constitute losing a good inter-op chance once more?
Regards,
Rufus D
@Rufus: you’re perfectly right. We weren’t compatible to gdm themes because of a couple of minor glitches (Oswald can tell you more about this). Moving to QML won’t improve compatibility with gdm, but at least we’ll have a new login manager that’s better than apple’s or microsoft’s one.
@Peter: also having webcam-enabled logins will be cool – do anybody wants to research face recognition?? 😉
[…] make much sense to me | David Vignoni Visual Designer Blog Archive So one of the devs responded: QML to KDM! Presto!! | Enrico Ros Some awesome videos of QML animations, one even on the Nokia N900, sweetness! Direct Link to […]
@Enrico Ros
“do anybody wants to research face recognition?? ”
I suggest to ask from digiKam developers. They had talk about such on last codingsprint if I remember correctly.
Many would like to get a face recognition for digiKam as autotagging. It is not impossible task to do but bretty difficult at least when it is needed to be remembering who is who and autotag them as well like iPhoto.
I’m not much bothered by whether it is Plasma or pure QML (though Aaron’s arguments strike me as the more convincing).
But yes, please, somebody jazz up KDM *a lot*. It’s slow and ugly, and as David pointed out long ago none of the options make very much sense.
someone did face recognition in KDM for pardus as a GSoC project:
http://code.google.com/p/pam-face-authentication/
WOW… interesting!
Grazie mille per il commento, CIAO!!! 😀