The battery plugin is somehow redundant cause there is now xfce4-power-manager with more features. It would be nice to have the plugin source inside. Advantages: - Package maintainers only need to maintain one single package (versus currently tow) for power purposes. - xfce4-power-manager places its icon into systray, so there's a dependency to the panel stuff anyways. - Users don't get confused what package to install, they keep to be free to choose if they would like a separate plugin or the systray icon. - Only one upstream development's main stream. Decisions about new features can be taken more centrally. Disadvantages: - ?
xfce4-battery-plugin doesn't need upower/udisks, and that's an advantage to some people. And I don't think there's a good reason to force them to change (I'm not one of them, I'm just saying :P). And honestly, the package maintenance cost for xfce4-battery-plugin isn't very high (e.g., that's a bit easier to debug than xfce4-power-manager when something goes wrong...).
Likely to not happen, as was already discussed at length in https://bugzilla.xfce.org/show_bug.cgi?id=4673. As lionel summarized, some people just want to have a battery level/notification without running Xfpm.. *** This bug has been marked as a duplicate of bug 4673 ***
Thanks for the quick reply. I guessed that there is already something here about the merge idea. (In reply to comment #1) > xfce4-battery-plugin doesn't need upower/udisks, and that's an advantage to > some people. And I don't think there's a good reason to force them to change > (I'm not one of them, I'm just saying :P). No, upower/udisks are optional dependency. If they aren't available, some features just don't work or are disabled. Further, it's up to the downstream package maintainers to encapsulate the battery plugin only in a separate package. I am talking mainly about merging the source to benefit from removing duplicated snippets. > > And honestly, the package maintenance cost for xfce4-battery-plugin isn't > very high (e.g., that's a bit easier to debug than xfce4-power-manager when > something goes wrong...). Again: The plugin should be kept as it is, only an idea to merge the source as such. (In reply to comment #2) > Likely to not happen, as was already discussed at length in > https://bugzilla.xfce.org/show_bug.cgi?id=4673. As lionel summarized, some > people just want to have a battery level/notification without running Xfpm.. > > *** This bug has been marked as a duplicate of bug 4673 *** Those users won't need to run Xfpm, and even not install the package with complete stuff if there's a package manager who knows what it does. Although, I must say that I am not aware of the work amount needed to merge sources. But I can keep an eye on it.
(In reply to comment #3) > > No, upower/udisks are optional dependency. If they aren't available, some > features just don't work or are disabled. > Yeah, well, xfce4-power-manager with upower is not really useful (it doesn't parse /sys like xfce4-battery-plugin does). > > Further, it's up to the downstream > package maintainers to encapsulate the battery plugin only in a separate > package. I am talking mainly about merging the source to benefit from > removing duplicated snippets. > Thanks, I know the distinction between source and binary packages. > > Again: The plugin should be kept as it is, only an idea to merge the source > as such. > But what's the point of that? They are different program, with little in common, except their purpose: xfpm mostly uses gobject stuff and the upower abstraction, so mostly it doesn't care about the platform. However, battery-plugin uses good old structs and lots of #ifdefs for all the platform it supports. So it doesn't look like you will remove many duplicate snippets... > > Those users won't need to run Xfpm, and even not install the package with > complete stuff if there's a package manager who knows what it does. > > Although, I must say that I am not aware of the work amount needed to merge > sources. But I can keep an eye on it. > Really, I don't think a folder called 'battery-plugin' inside xfpm would improve anything, because they wouldn't share code unless you rewrite one of them (e.g. have xfpm fall back to /sys parsing, let's not do that please).
> Yeah, well, xfce4-power-manager with upower is not really useful ^^^^ obviously, read: without
I agree keeping this program as a separate plugin (I stop using xfce4 power manager, since it owerwrites some fine-grain powersave settings suggested by powertop which I load from rc.local; now I do my own "custom power management").
(In reply to comment #6) > I agree keeping this program as a separate plugin This bug is not about packaging. My idea was to merge the sources in git. As suggested, packaging is another topic and can be done within the specific (downstream) distribution.
If this is supposed to remain a separate plugin without any dep to x-p-m, what is the use of merging it? I see only disadvantages: - Release management, because schedules would need to be aligned - Translations because of the combined schedules - bigger downloads - harder to build because of more dependencies - likely to break because a problem building one will break the other. As long as the plugin does not offer any integration with the x-p-m, this does not make sense.
I know at least about four options to see the battery state with xfce modules. - xfce4-power-manager: systray icon and tooltip - xfce4-panel-plugin: label and tooltip - xfce4-sensors-plugin: enable the ACPI sensors - xfce4-indicator-plugin: usage of a script to get battery values It can't get a little bit confusing when there are some (or all) of them in the panel. And it's obviously quite normal that each shows another time for the remaining power.
(In reply to comment #9) s/xfce4-panel-plugin/xfce4-battery-plugin
I see that the brightness plugin is already a part of the power manager. At the first look, there's no senseful reason for this, similiar as the battery plugin then.
*** This bug has been marked as a duplicate of bug 4499 ***