Various updates and stuff

Hello everyone, long time no post.

As I’m used to do lately, I failed in keeping up all the stuff I’m doing in my blog, so I thought about writing a quick recap of what’s going on in my land.

Telepathy-KDE – New stuff

I am now working at Collabora: as I’m still a student, I got hired part time and have been assigned to telepathy-kde: so if you noticed some extra activity on my side being thrown into that part of KDE, you now know the reason :) I have to say I’m pretty excited about that and I found myself liking the project and Telepathy itself a lot: expect some more news on this specific topic soon.

For the moment, I started getting involved into the various projects (including Telepathy-Qt4), and already achieved something: you can now handle your contacts through telepathy-contactlist (so adding/removing contacts, handling groups, etc…) and have them synchronized with the corresponding nepomuk resources. I am also writing a small API which would allow KDE applications to access Telepathy functions easily from Nepomuk resources.

Telepathy really brings a lot to the table, and it can be a great addition to KDE. Just keep an eye on us, you might hear some exciting things ;)

On a side note, a big thank you to George Goldberg for helping me in getting up to speed with the project.

KAuth

KAuth is definitely in "maintainance mode": I fixed some small bugs in the last days, improved backend handling with dynamic plugins, and it definitely appears rock solid – there are no open bugs against it that I remember right now, and it’s becoming more widespread by the minute. KDE 4.5 will probably feature KDM’s KCM using KAuth, which was probably one of the most awaited modules to be ported to this new framework.

I’d also love to see some more applications following the drill and abandoning the "launch UI as root" meme: for example, I’d love to see the excellent KDE’s partitionmanager (btw, it’s hands down the best software out there for managing your disks, give it a shot) using KAuth and no longer running its GUI as root.

On a related note, it is planned to have KNewStuff3 using KAuth for system-wide installation. Yeah, this means you will be able to install new wallpapers/plasma themes/amarok scripts/whatever you might think for all of your users.

Polkit-kde-1

Things had to slow down on that front, for obvious reasons. Although, in SVN there’s an almost working KCModule which is able to manage polkit actions and system administrators. Hopefully somebody will help me giving it the bit of love it needs for a release :)

Power management

In 4.5, PowerDevil has been improved a lot – this thanks to many people who came up with patches. Especially, Holger Macht pushed some bug fixes and some usability fixes (which removed some controls like power management schemes) based on the latest kernel and power management stack improvements which relieved various options from the GUI.

Also, there are some more patches by Felix Geyer which are in process of being implemented, which will fix some of the most annoying bugs (double suspension, brightness control) found in PowerDevil these days. So expect a better power management experience in next 4.4 releases and especially in the upcoming 4.5.

For the future (4.6 or 4.7), PowerDevil might undergo a partial or total rewrite, due to a variety of factors. First of all, I’d like to implement at least a good part of the features I described in this previous post; secondly, PowerDevil’s code is starting to show its age and my inexperience at the time of its writing; thirdly, there will be some changes in the Solid stack.

Solid::Control is about to disappear. Yep, you heard correctly: that small set of libraries in kdebase/workspace will be "eaten" by the components which make use of it.

Why? Because S::C is meant to be used by the corresponding component only (PowerDevil, NetworkManagement, BlueDevil…), and has never guaranteed API stability. Merging the code would allow us to reduce complexity and sparse code.

I already hear cries from developers who used Solid::Control::PowerManagement in their applications – but don’t worry. A basic API (e.g. just what you need) will be exposed (probably through DBus) by "future PowerDevil" instead, and I’ll try to commit to a stable API once this will happen.

Also, the logic for suspension/hibernation will be probably moved to the session manager, which is where it belongs. More than that, there will be some further improvements to profile handling, inhibition handling, and more stuff.

And we’re not forgetting upower (former DeviceKit) support: you might be able to use it very soon, as a backend appears to be ready somewhere. Just watch out my blog for an announcement.

That’s all, folks

Hope you enjoyed the reading. Give out your feedback, and if you’re interested in giving out a helping hand on any of these topics, feel free to get in touch with me, I’d be more than happy :)

About these ads

~ by Dario on 15 April, 2010.

12 Responses to “Various updates and stuff”

  1. Impressive work! Thank you!
    Regarding KAuth it would be nice to have this feature implemented for KDE 4.6:

    https://bugs.kde.org/show_bug.cgi?id=179289

    Regards,
    Diego

    • Hi Diego,

      thanks :) that feature is actually on my todo list since a while – I really hope somebody will step up and implement it, otherwise I’ll do it myself – but that might mean to wait until 4.6-4.7, given that I have way more stuff to do :\

      Anyway, it’s a must have and will be there at some point

      • It would be nice also be nice if when saving a file from *any* KDE app it would do similarly if it required permission from another user/root.

        Could this be implemented in the libs (without touching the application code)?

        Though it might not be possible to do it this way without touching the application code as there may be cases where an application tries to save a document without explicit request from the user where it would be confusing/inappropriate to ask the user “application X trying to save Y to folder Z but does not have permission to do so… “.

      • Yeah, it will – such a thing would be implemented at KIO level, so every KDE application using KIO (-> all of them) for handling files would get this kind of management for free. No need for touching anything in any application – and this includes dolphin. The only thing that might be implemented in Dolphin is a UI element telling you that you will need to authenticate to save/open a file, in a similar fashion to the KCM UI. But more than this small details, there’s no need to touch any application.

        About the other part – well, it’s not confusing, it’s the whole point of a secure framework :). If an user got such a message without an explicit request, he definitely knows that something is going strange, and he’d better abort the request ;)

      • Yes. what I mean might be confusing is if the application was for example “changing a setting” it would be more appropriate for the user to be presented with a “this application wishes to change setting X for the system, effecting all users” than “this application is trying to save to /etc/some_module/settingrc”.

  2. I’ve looked into using KAuth for KDE Partition Manager a couple of weeks ago, following your nice tutorial on techbase. KDE Partition Manager 1.0.x needs root mostly to make the kernel reload partition tables. Access to the devices can be handled via permissions in /dev.

    Unfortunately, something in the KAuth/PolicyKit (or Polkit? all this is a little messy) stack seems broken on Kubuntu 9.04 once you install KDE 4.4 (the time/date KCM doesn’t work either). Since my primary devel machine runs this distro, I decided to postpone KAuth work a little.

    In the meantime KDE Partition Manager gained some rather comprehensive SMART support that also requires root privs. I’m not yet sure how this will work out with KAuths helper-binary design in the future.

    The thing is really, once you leave the “write some file/call some binary as root and be done with it” design it can probably get tricky very quickly.

    Anyway, cool tech! Thanks a lot for your hard work on this.

    • Hi Volker, thanks for replying

      >I’ve looked into using KAuth for KDE Partition Manager a couple of weeks ago,
      >following your nice tutorial on techbase. KDE Partition Manager 1.0.x needs root
      >mostly to make the kernel reload partition tables. Access to the devices can be
      >handled via permissions in /dev.

      That’s awesome news :)

      >Unfortunately, something in the KAuth/PolicyKit (or Polkit? all this is a little messy)
      >stack seems broken on Kubuntu 9.04 once you install KDE 4.4 (the time/date KCM
      >doesn’t work either). Since my primary devel machine runs this distro, I decided
      >to postpone KAuth work a little.

      Hmm, this sucks (btw, for clarifying polkit/policykit mess, http://drfav.wordpress.com/2009/12/22/polkit-and-kde-lets-make-the-point-of-the-situation/ – a very interesting read if you want to use/understand KAuth more efficiently). Are you using prebuilt packages or a self compiled environment (maybe installed out of /usr)? If your case is the latter, it’s just a matter of moving some files to the locations polkit/policykit and dbus expect.

      >In the meantime KDE Partition Manager gained some rather comprehensive SMART
      >support that also requires root privs. I’m not yet sure how this will work out with
      >KAuths helper-binary design in the future.

      I saw – I also love the backend split part. In fact, what I though (supposing that the part lying in the backend is the only part requiring root privileges) was that simply by moving the whole backend handling to an helper should already do the job.

      For doubts about the helper and stuff – consider that you can do pretty much whatever you want in it, aka everything you can do in your main app. Also, if the communication between helper and main application provided by KAuth is not enough for you, you can still attach a new DBus interface and use it – but it’s not really needed in most cases, as you can stream back to the application a QVariantMap during the execution of each action.

      >The thing is really, once you leave the “write some file/call some binary as root
      >and be done with it” design it can probably get tricky very quickly.

      Definitely, but it’s not a strict requirement. You can still use QProcesses and stuff inside the helper

      >Anyway, cool tech! Thanks a lot for your hard work on this.

      Thanks a lot! And thanks for partitionmanager of course, it’s one of my favorite kde apps, but I think I already stated this point ;)

      Ah, if it was not obvious: feel free to mail me for any support for KAuth & friends.

  3. Hi! Since you are talking about PowerDevil, could you post something about the complete deprecation of HAL? Thanks a lot for all your work!

    • Hi there,

      there’s not much to say actually – the decision has already been taken and we took no part in it. However, we purposefully delayed devicekit support to avoid going through dependency/API hell and have our users rely on unstable software, and given all that’s happened (devicekit being deprecated, components being renamed), we’ve been definitely proved right.

      At the moment, though, upower is starting to show his superiority (at least API wise – I still did not try it) against HAL. As I wrote, the first bits will might land even in KDE 4.5. For sure PowerDevil will also take advantage of the new features.

      If you want a random estimate which is based only on my believings (so nothing official or reliable), I’d say that with 4.6 you’ll be able to use KDE without HAL retaining all the functionalities – and possibly having some new goods.

      However, due to our awesome architecture, you’ll still be able to have KDE working with HAL, as there will always be a HAL solid backend. So, you’ll also be able to delay the switch further if you need to.

      Hope this helps :)

  4. BTW, for 4.5, will you definitely remove the “Allow PowerDevil manage the screen energy savings” (or something like that) option and give that task definitely to PowerDevil? One confusing option less, one point to make your interface a little less cluttered.

    I’ll be waiting for 4.5 (and, when I can make my touchscreen work with evdev like Fedora is doing now, I’ll install Chakra too ;))

  5. I wonder if there any plans to implement udev backend for Solid? Hal has been deprecated for quite some time and some distributions considered to not ship it by default.

    Also it’s very nice to hear that double suspend bug has been fixed!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: