openSUSE 11.1: Power Management

Another bit for the upcoming openSUSE 11.1 KDE4 desktop is power management: KPowersave has not been ported to KDE4. Powerdevil, which will be part of KDE 4.2, comes to our rescue. Together with a backport of the battery plasmoid popup from KDE 4.2 SVN as in yesterday's released openSUSE 11.1 Beta 5 we get a good power management solution. The backport only uses QWidgets so that we are not forced to backport all the latest Plasma 4.2 widgets etc.:

Btw, a big thanks to the openSUSE Localization teams who make it possible that we can add or backport all these small bits. :-)


This spate of backporting and uglifying (just so you can be lazy when backporting) is an insult to our release cycles and a misrepresentation of the work of the Plasma team.

I'm tired of spending time with bug reports for half-completed features downstreams are backporting, I'm tired of seeing our work butchered (I mean, just LOOK at that screenshot) by your hamfisted attempts at appeasing your users and I'm tired of you bragging about it as if this is all something good.

It's a travesty in motion. At this point you'd be better off shipping a full and proper snapshot of plasma from svn than this crap. At least be honest and tell people that these aren't backports as much as they are a fork of upstream development.

Suse is, at least potentially, a great partner for Plasma, and vice versa. Right now, however, you are burning up your goodwill at a terrific pace and becoming an increasingly large liability to our public image.

And people wonder why the Mozilla Foundation is such a hardass when it comes to their trademarks.

By Aaron J. Seigo at Fri, 11/14/2008 - 21:40

It's no laziness but a conscious decision to take only selected and limited parts of code (testing, maintenance). The emphasis of this effort is on working basic functionality, not beauty as I have sometimes the impression from Plasma developers, which I think is good for users. You're IMHO not the right person to complain about including half-completed features (what about activities/ZUI in 4.0 or 4.1?). And you do mispresent the current pre-Beta state of Plasma trunk as shippable.

By at Sat, 11/15/2008 - 00:45

I do not understand this harsh reaction, unless there are really tons of bug-reports that are caused by bugs introduced by the backports, i.e. bugs that are not in the branch/trunk plasma.

From the reviews I read, openSUSE was one of the distros with the most polished and useable KDE 4.0 desktops, in part because it offered functionality which was backported from 4.1. So users and reviewers seemed to appreciate that and did not complain about the looks introduced by it.

In openSUSE 11.1, KDE 4.1 is the standard KDE desktop, although KDE3 is available too. This is a statement that KDE 4.1 is ready for the users. The latter is a bold move since as one could see on several mailinglists or forums, there is still harsh criticism of KDE 4, in this case 4.1 lacking features KDE3 offers. Pointing to KDE 4.2 does not help openSUSE or any other distro's users, so there is a choice to make, either provide KDE 4.1 without any backports lacking certain features or trying to backport whatever a distro considers crucial for its users.

One of the most frequent complains about KDE4 is that devs put beauty before functionality, which I think is not true, but anyway. Having not so pretty but working powersave-plasmoid is certainly better than having none and having some GUI to powerdevil other than the kcm is, from a laptop-user's point of view, a gain too. So one pays the price of beauty to get some functionality benefit, there is nothing wrong with that IMHO. If it was missing, people could complain that there is no such GUI, i.e. lack of functionality KDE3's kpowersave provided. Which one is worse, complains about "not so beautiful" or "another proof that KDE4 still lacks functionality I used in KDE3"?

So in terms of functiontionality openSUSE users will have a better experience which falls back on KDE. There might be some that complain about the ugliness of that plasmoid, fair enough, yet those are easy to put off compared to those enjoying KDE4 because of the backports and improved functionality.

All this assumes that the functionality of the backport is given. There might be some bugs that get into the kde bugzilla because of backports, but those are marked "SuSE RPMs" and I did not hear anyone complaining yet about the tons of upstream bugs that get reported at Novell's bugzilla. I bet there are more KDE upstream bugs at Novell than backport-bugs at bko, but I might be wrong about it.

Of course it would be better to backport everything, including beauty, but the reality is that resources are limited, so you have to make a choice, as you did for 4.0 and 4.1.

To sum up, this backport increases functionality and is not so good looking. So plasma might get blamed for a not so good looking plasmoid. Yet at the same time it will be liked because of the functionality. So blaming openSUSE or other distros because of this is unfair IMHO. Demanding that they tell users that this is a backport would include telling them that you would rather have them use KDE 4.1 without that functionality than without the beauty from trunk.

I use plasma from trunk self-compiled and there are bugs a lot more annoying and things more ugly than this plasmoid. which is fine, because it is trunk, but certainly not shipable. I have a built of branch as well and it lacks a lot of functionality compared to openSUSE packages. I go for the functionality and blame that on openSUSE, others might not even know that they provide functionality that is not in KDE 4.1 and might blame those improvements on KDE, ignoring the backport work.

There was the idea of a KDE distro, I'm not sure whether it got reality, but I would be interested what people would use for daily work, a KDE 4.1 distro on steroids, with a few beauty glitches, or a default oxygen look that lacks things like panel-hiding, powersaving-GUI etc.?

By backporting openSUSE is creating goodwill for KDE 4.1 and working against those claiming that released KDE4 lacks a lot of functionality. Are you sure you are right about your public image and what affects it in what way?

By rabauke at Sat, 11/15/2008 - 15:18

+1 to all this, which is essentially also what I said last time this discussion came up.

In this case, the battery plasmoid in its KDE 4.1 state is really completely unshippable, it's a useless decoration with no functionality. There are only really 3 possibilities:
1. Continue shipping KDE 3 KPowersave - that's what we did in Fedora 9. Shipping a mix of KDE 3 and 4 stuff is generally seen as a suboptimal solution, and KPowersave had to be patched to work at all in KDE 4 (it was trying to talk to KDE 3's mounting/unmounting (mediamanager) service through DCOP).
2. Ship a temporary KDE 4 solution, e.g. guidance-power-manager from extragear (thanks to the Kubuntu guys for that one) - that's what we're doing for Fedora 10. The advantage is that it is a known stable solution, the drawback is that it is only a temporary solution which is not integrated into Plasma (in fact, we have to disable the battery plasmoid by default in Fedora 10 because it was duplicating the battery status display of guidance-power-manager, while missing all its other functionality) and which is very different from the upstream solution we will most likely eventually default to (in Fedora 11).
3. This backport. We would probably have used this in Fedora 10 if it had been available a bit earlier (when the backport has become available, Fedora 10 was already in its final development freeze, so changing the default power manager at that point would have been a risky move). It means shipping what will eventually be the upstream default, even if it had to be modified to work with the 4.1 version of Plasma. We may consider shipping this as a non-default option in a Fedora 10 update. (I'm in favor of it, but this has to be decided in the team.)

As for another example, we are carrying the panel autohide backport in Fedora 10 and in the latest Fedora 9 updates, all the feedback we got (from actual users) was positive. There had been a lot of complaints about this feature missing. Users see features which were in 3.5 and are not in Plasma as bugs, they don't care that the code is completely different, all they see is that the feature used to be there and isn't now.

By Kevin Kofler at Sat, 11/15/2008 - 20:09

This screenshot is not ugly, it actually integrates into the system, unlike the NIH widgets which will sadly be in 4.2.

I see Plasma widgets as a big step backwards, and the fact that they can only be themed with SVG (i.e. by replacing images with others, with all the drawing logic being hardcoded) is extremely inflexible (it just can't compare to QStyle's flexibility) and makes it impossible to truly match the look of standard widgets.

(But no, we aren't shipping this in Fedora 10, because the backport came too late for it, so we're defaulting to guidance-power-manager from extragear for now.)

By Kevin Kofler at Sat, 11/15/2008 - 18:55

Oh, and as far as I know the borderlessness of the rectangle is not related to the use of QWidgets, it's a deliberate theme choice (Aya theme). OpenSUSE is using the Aya theme because it actually honors the user's color scheme unlike the Plasma Oxygen theme's "any color that he wants so long as it is black" (bonus points if you can figure out where the quote comes from ;-)). I'm personally using it for the same reason (though it is not the default in Fedora, we currently default to the Oxygen theme as upstream does).

By Kevin Kofler at Sun, 11/16/2008 - 02:27

"I see Plasma widgets as a big step backwards, and the fact that they can only be themed with SVG (i.e. by replacing images with others, with all the drawing logic being hardcoded) is extremely inflexible (it just can't compare to QStyle's flexibility) and makes it impossible to truly match the look of standard widgets."

That is so completely and utterly wrong it borderlines ridicules.
The initial usage of SVG in Qt was to test Qt rendering engine because everything Qt can do can be expressed in SVG (besides perspective transforms which were added later). SVG includes the "drawing logic" and in that sense it is exactly as flexible as QStyle with the added benefit of making it way easier for artists to theme it.

By zack rusin at Mon, 11/17/2008 - 00:40

No, SVG theming can't do everything a C++ style can do.

For example, Plasma scrollbars are drawn by using subComponentRect to figure out the components of a scrollbar and then drawing SVGs for the components. But what if I want to draw a scrollbar differently than the standard components? For example, with the extra buttons at the bottom which Plastik used? Or with glow from one component which blends into the other one? Or with an even more original rendering technique neither you nor me can think of right now? C++ styles can do all this. With SVG theming, we can only replace the images, not the logic.

As another example, Plasma frames have fixed components: the borders in the 4 directions and the corners. What if I want to render a Plasmoid like a toolbox window, with a small title bar (like the ones in toolboxes, distinguishible from a window), with the name of the plasmoid printed in that title bar? I can't do that with an SVG theme. (To fully work the way I want, it would need something like the KWin decorations, where not only the drawing is done in C++ code by the decoration, but the decoration can also handle mouse events, like dragging the title bar.)

C++ code can also query the QStyleOption or even the QWidget (or whatever object is being themed) for all sorts of state information and draw something completely different based on it. (Drawing the name of the plasmoid as in the previous paragraph would be one example of that.) Again, an SVG can't do that.

I have worked on both a QStyle and a KWin decoration (Quarticurve and Quarticurve-KWin, which are Qt/KDE 4 ports of the Bluecurve themes), so I'm not new to theming. I have looked into Plasma theming, but immediately despaired in front of the lack of flexibility.

Theming through images is not a new idea, it has been done a lot of times, and invariably theme authors run into unsurmountable limitations (where they would need to change the code to get the look they want, not just the image), and my experience is also that in cases where both code themes and image themes are possible, the high-quality themes are invariably the code ones (just look at native KWin decorations vs. deKorator themes for one example). I know people love image theming because it's easy to replace the images and they don't have to write any code, but to get a truly original look, or to match the look of something different (e.g. to make Plasma look more like regular applications, but for another example how would you suggest writing QGtkStyle if QWidgets were only themable through SVG?), more flexibility is needed.

Another issue is that there are 2 completely different theming systems for widgets (QWidgets vs. Plasma widgets), so to get a consistent look (think Bluecurve), I have to reinvent an SVG theme which looks like Bluecurve. It's a complete waste of time, it would make much more sense to just let the QuarticurveStyle (Qt 4 Bluecurve port) draw the widgets to get what I want.

By Kevin Kofler at Mon, 11/17/2008 - 02:42

I'm thinking about installing openSUSE on my netbook (Eee PC), currently the battery is running about 4 hours- maybe with the new power management it's even longer? anyone tried it yet with the eee pc?

thanks in advance
cyrax :)

By cyrax1 at Mon, 11/24/2008 - 00:50