ANNOUNCE: xfce4-power-manager 1.3.0 released
gber at opensuse.org
Thu Jun 5 11:42:52 CEST 2014
* Simon Steinbeiß <simon at xfce.org> [2014-06-04 15:05]:
> On Wed, 4 Jun 2014 09:30:35 +0200
> Guido Berhoerster <gber at opensuse.org> wrote:
> > I need some kind of battery status indicator for the openSUSE default
> > configuration of the panel that works for both laptops and desktop
> > computers. The big problem with a panel plugin in contrast to the
> > previous tray icon is that it cannot be hidden if the computer is on
> > AC power with no battery present or if there are no exposed devices
> > at all. Right now the new panel applet shows the rather scary
> > xfpm-primary-000 icon (critical battery levels) in that case. I
> > suppose this is an issue for other distros as well, ideas how to
> > address this and make it work for this usecase?
> I guess we have to check whether we can show the appropriate icon
> instead of the 000 icon. (Basically the plugged-in icon already
> exposed in the devices tab.) I think the plugin is useful to
> add/show in the default panel, as it provides quick access to
> e.g. the presentation mode and other connected devices that might
> be dis/charging.
Yeah, I'm aware that it is not viable to hide a plugin, so showing
a less "alarming" icon such as the plugged-in icon with a tooltip
"No battery detected" or similar would be good.
> > > The settings dialog has been completely restructured for better
> > > oversight. Additionally, xfce4-power-information, a stand-alone
> > > application has now been embedded inside the settings dialog.
> > While testing in kvm and on real hardware I've run into a number of
> > bugs and issues:
> > panel-plugin:
> > - the panel plugin icon is clipped with the Adwaita theme
> This one is known and we'll try to iron it out soon.
> > - should the preferences menu item in the panel plugin's popup menu
> > rather be in the context menu as with every other panel plugin?
> I think as the plugin is a togglebutton that shows a menu
> attached to it, the preferences-dialog button is where it should
> be. What you're referring to here (if I understand you correctly)
> is the plugin properties, which are usually accessible in the
> right-click menu. If we ever decide to go ahead and make that
> menu customizable, that properties-dialog would be linked to in
> the (right-click) context-menu.
> > settings dialog:
> > - the values below the inactivity-on-battery/inactivity-on-ac
> > hscales get clipped for large values
> Strange, this must be due to the Adwaita engine (and its
> incredible over-use of x/ythickness, sorry for that flamey
> remark). Looks fine here. Maybe we can improve that somehow in
> the packing or properties of the widget, but for now there is
> nothing non-standard about these scales.
This seems to happen when the width of the value exceeds the width
of the scale. E.g. the value label "One Hour 28 minutes" is about
twice as wide as the scale itself, how is that displayed with your
> > - why does the label on the "Display" tab say "Disable power saving"?
> > if it is supposed to mean "Display Power Saving" it can probably
> > be removed altogether
> Good catch, that must be a left-over of the restructuring that settings dialog a few times. :)
> > - brg-level-on-battery/brg-level-on-ac should be left-aligned with
> > the hscales above them
> Not sure why you would infer that the scales are left-aligned. I
> think with the two columns, it could be confusing if the two
> spinbuttons were left-aligned instead of centered (we had them
> like that at some point in the process).
Equal alignments and as few alignment lines as possible make it
much easier to scan through a table, see
> > - on-battery-lid combobox initially has no active entry
> Right, that should be fixed.
> > - the "Battery" and "Plugged In" labels are always (even when
> > devices are present) insensitve, making them hard to read and
> > confusing
> This is intentional, as they are solely headings. I played quite
> a while with this part – there aren't a lot of examples of this
> sort of preferences-table, however, it seemed to make the most
> sense to me to keep an eye on everything more easily (as compared
> to the amount of tabs before).
Hmm, at least with the Adwaita theme it is hard to read and implies
something is deactivated when it is not. Though I'm not sure how
such a table should look like and I'm not aware of any precedent...
> > - does the network-manager-sleep property really need to be exposed
> > in the UI?
> Yeah, fun. People complain about hidden options, but then again
> also if we expose options... I guess when we're approaching the
> next stable release – and maybe more options will have been added
> along the way to that – we can re-assess this and see what needs
> to be there and what maybe shouldn't.
I'm just wondering why you wouldn't want this to always be enabled
(when NM is available).
> > Bugs/issue on computers with no power-related devices:
> > panel-plugin:
> > - xfpm-primary-000 icon is shown (critical battery level)
> > - the popup menu always shows a separator although there are no
> > devices on top
> > settings dialog:
> > - the on-ac-lid combobox is not visible
> > - inactivity-on-battery/ac comboboxes are sensitive
> > - the brg-on-ac hscale and brg-on-ac-level spinbutton are
> > insensitive, all other widgets are sensitive
> That means xfpm can't control the display brightness, as far as I
> can tell.
Well in this case upower cannot tell whether it is on battery or AC
and there are no brightness controlling devices, yet I can set the
inactivity time and brightness level for battery but not AC which
> > - the devices tabs shows some empty and zero-width widget
> > If there are no devices exposed by upower it is probably sensible to
> > assume AC power and everything not relevant, such as all the "On
> > Battery" stuff, "When laptop lid is closed", or the "Devices" tab
> > should not be shown at all whereas the widgets related to "Plugged
> > in" should be sensitive and visible.
> The Devices-tab should always be shown, as it also lists all
> other connected devices that are charging. So if you connect your
> multimediaplayer or smartphone, it will show up there, even if
> you don't have a laptop. We can think about hiding all the
> battery-related stuff for desktop machines that don't have
It's not so much about laptop vs desktop but the presence of
devices which are exposed by upower, i.e. you might want to
couple the visibility/sensitivity of widgets based on upower
properties, mostly the presence of a bightness controlling device
and one or more batteries (of course with the new design this is
a bit more complicated than before where you could hide the
BTW, you can easily test the above case inside qemu/kvm which does
not expose any brightness control, battery or AC plug whatsoever.
> > I can later file bugs for these issues but I think it is more
> > appropriate to discuss some of the less clear-cut issues on list
> > first.
> Yup. Frankly, we did this release to gather this sort of
> feedback from people and to help us get a prioritized list of
> things to fix. On the other hand, we also released it so that
> distros that were already shipping snapshots could at least ship
> some sort of release now.
> Thanks for all the feedback, it's much appreciated!
xfpm maintenance is sorely needed, so thanks taking care of it.
More information about the Xfce4-dev