Replies: 4 comments 1 reply
-
|
The current release cycle makes major changes to the config language (and actually introduces a half-decent interpreted language in place of old action-list style function). The docs are out of date for this (largely because I am still making changes to the language). That said, the general idea of making a widget involves 3 steps:
The module() keyword loads modules. These are written specifically for sfwbar in C, where more complex logic is needed - i.e. implementation of dbus protocols or audio server connections. Happy to help with work on a power panel. I guess the source of data would be powerctl utility or is information available from a more basic sources? |
Beta Was this translation helpful? Give feedback.
-
|
@LBCrion Hello, thanks for the quick reply! I see, so it is a "custom" interpreted language for sfwbar? And actively changing means it would be hard to explain anything in detail, thanks for the clarification, I suppose I should get done what I can right now done and await for these changes to come out The module() keyword made me very confused so asking (and receiving an answer) saved me a lot of time, I'm no coding expert but I do know C so I'll see what I can do for creating such module For a Power Panel, first I apologize I made a mistake with the name, it's actually "powerprofilesctl" and I believe is the best target to have, it makes easy to manage power profiles with even just bash scripting and possibly many users interface with it to even use custom profiles, so working with that instead of a more primitive data source could cover a broader user base For acquiring such data, for example just sending "powerprofilesctl get" returns the currently active profile, comparing this to a list generated from "powerprofilesctl list" which returns all existing profiles would allow to display the information and gray out a selection button for the profile already active, finally "powerprofilesctl set (profile)" changes the active profile (activated via a button right side of the profiles?) and that covers all desired functionality. I'm currently not well versed on how it works with D-Bus, so I cannot give insight on those aspects |
Beta Was this translation helpful? Give feedback.
-
|
I had a look at powerprofilectl. Power profile daemon, which this utility is part of, actually has a simple(ish) DBus interface to broadcast and control the power state of the system. Sfwbar language currently has a native function DBusCall which can probably be used to control the power state using ppd DBUS interface. What we don't have are means to monitor and query the state of a DBus interface. |
Beta Was this translation helpful? Give feedback.
-
|
I think I got dbus module to a minimum level of functionality needed to communicate with power-profiles-daemon. As expected most of the work is related to converting between dbus structures and sfwbar variables. It turned out surprisingly clean, considering that dbus has 17 types and sfwbar has 3. The only conversion we can't handle gracefully is converting from sfwbar values to "v" dbus type, since "v" can contain anything, so we don't know what type it should hold. The translation is suprisingly graceful, although it results in very deep nested arrays on sfwbar side. (I.e. Profiles property for power profiles daemon is "(aa{sv})" translates into a nested array 4 levels deep. 1 for a tuple, 1 for each of 2 arrays and one for dict entry.) As far as the interface goes, the dbus module has 3 functions. Basic code for widget looks something like this: |
Beta Was this translation helpful? Give feedback.
-
|
I cleaned up the module to allow encoding of variant types, which was the last bit needed to control the power profiles daemon. Unfortunately this means the dbus strings used for encoding aren't completely standard when variants are involved. A 'v' when encoding should be followed by a type that variant will hold. I.e. '(syv(ss))'. This will encode a tuple where the last element is a variant holding two-string tuple. I also pushed |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello I would like to begin making clear I'm an absolute noobie, I have used SFWbar for a while now, and I'm interested in making a widget for battery management, I have tinkered with them a little already as none of the existing battery widgets worked out of the box for me, and now I want to make one that works more broadly, and do more too, hopefully I can end up pull requesting what I finish.
But I'm stuck at trying to understand how to code one, I understand the basic functionality that is explained in the documentation, but I really don't know what I am working with, is it C code? Plain bash? I read that it can import and work with Python but that also is not explained how to, I tried looking at existing widgets for an example and I couldn't figure out one way, I would also like to ask what functions are available but I suppose I can figure that out knowing the prior
On another note I've seen widgets be able to load module("x") of which each name suggests it's a system binary application, but trying to do that with anything doesn't work so I'm assuming is a pre-existing library from the project meant to interface with it? Just to confirm I would have to program one for example to send commands to power-profiles-daemon? (powerctl)
I think it would be good to explain what I want to do as well, so I'm using wbar-battery.widget as the base since it almost worked out of the box, it just needed a more variable battery detection approach and changed it to become a button-type widget, it's ICON (value) I haven't gotten around to make it dynamic yet, but the idea is to make it so like the volume and network-module widgets which use icons from the icon theme.
Right now I'm working on it's tool tip and made it display current battery charge and the state of the battery, I would like to add an estimated time left to 0% which I think I can do with mathematical logic alone and displaying the equation result, but I'm typing this right after finishing the state tool tip so yet to be done, more complicated than that I also want to add to the tool tip the current Power Profile from power-profiles-daemon (if available) which should be a lot more work but it's basically a pre-requisite for the last thing I want to add;
For my last addition I would like to do a Power Profiles Panel (much like network-module.widget or volume.widget popups) that displays power profiles with a button alongside that enables activating one, all of this interfacing with powerctl (if available) and so I would have a feature-complete battery widget for myself and contribute back hopefully
Sorry if I'm too much of a bother, but I really like sfwbar and I would like to make this happen, albeit I feel like I need guidance before I can deliver on it, cheers for the work and to who's reading please have a good day!
Beta Was this translation helpful? Give feedback.
All reactions