lokaltog / candybar Goto Github PK

I've added loading of basic config data into a struct in b20a7a0. I'm having a bit of trouble finding a way to make the widget config data (the widgets object in config.json) available to widgets.

The problem is that the object has a dynamic size and no predefined keys, so what I initially thought was that we could pass a pointer to the json_t object returned from json_object_get() along to widgets and let the widgets decode the necessary JSON data instead of handling it in the global config loader. This doesn't work, even when removing this line, it seems that the pointer to the json_t gets reset after returning from load_config_file().

I have no idea how we can store a pointer like json_t *widget_config in the config struct and parse JSON data on demand inside widgets. Does anyone have any tips on how to resolve this issue?

I recently noticed that the desktops widget was consistently failing on i3wm. After digging through the source for a bit I can't seem to find out why, though I did find a helper program called i3-msg which talks to the i3 instance using some sort of socketed ipc interface. Do you think it's a bad idea to implement a fallback using i3's ipc interface as opposed to working on fixing the bug in i3 itself?

Hello,

I was taking a look at this project, and I noticed that the default config you provide has its theme non-local. I took a look at the default theme repo, and I understand that you perhaps don't want npm and grunt as compile-time dependencies. However, having a default config that is local is IMHO better, because:

• It is snappier because you don't depend on your network
• We don't always have Internet connectivity

Therefore, I suggest having a directory in this repo with a pregenerated version of the default theme, and copying the theme somewhere local on installation. I'd put it somewhere under /etc so that all users have access to it.

Thanks in advance for your consideration

Shortly after launching candybar with the sole change being desktops replaced with desktops_i3, another candybar instance is spawned (according to htop 1.03 at least) and both of them shoot up to 100 percent CPU usage and remain there until candybar is killed. Candybar remains fully functional during this period, and no error messages are printed (same with a debug build).

This is all using a git build up to cabe5d4.

• Local IP
• WLAN status (offline/online/signal strength/access point name)
• Upload/download speed

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I have various scripts which I currently use to build my status bar which write to simple files. Would it be possible to have a module to display the contents of a file?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

does the name of the file has to be config.def.json? i can't change it's name in autotools an wkline only knows about config.json. also i'm trying to load the configfiles from systemconfig path /etc/xdg/wkline.
Bottom line is autotools should know about config.def.json and we should not end the program if we can't find the user configuration.

I'm already fed up from using autotools and trying to understand the docs for it, it feels way too overkill and complex for a small project like this one. When searching for other options I came across SCons, which seems like a pretty good alternative. I'm a bit biased since it's written in Python, but I'm willing to try anything if it means I won't have to look at m4 and makefiles again.

I'd like to hear some opinions if you guys have tried SCons before, if you have any other ideas, or if you have any really good arguments in favor of keeping autotools as our build system of choice.

Edit: link to crash course showcasing a simple build script.

It appears that one is supposed to handle SIGINT/SIGTERM signals and quit child threads by e.g. setting a global bool running = false and checking for this variable in the child threads. The child threads should also use select with a timeout or otherwise be able to check this variable with regular intervals, then exit the while loop, cleanup and join the thread with g_thread_exit().

the problem is in commit 4a4c338 i think that the config is not being passed to widgets threads

The segments aren't very complex and don't require a lot of data processing, and porting the segments to C could be a fun exercise. Including everything in the same binary would also mean we won't have to depend on dbus or named pipes (this could be an optional feature instead).

Some useful libraries that can be used to fetch and handle data:

• jansson (json library)
• libcurl
• libmpdclient
• libdbus (for libnotify support)

It appears that the mpris widget is trying to rely on a version of playerctl that doesn't exist:

ctx.check_cfg(package='playerctl-1.0', uselib_store='PLAYERCTL', args=['--cflags', '--libs'], mandatory=False)

As far as I know, the latest version is 0.2.1. I have 0.2.0 installed from the .deb. I tried changing the package in the line above to playerctl and playerctl-0.2.0, but the waf script still doesn't recognise it.

Am I just getting the configuration wrong?

When running candybar-git as well, as the debug variant specified in your docs, I get this error while launching candybar: candybar: simple.c:282: snd_mixer_selem_get_playback_volume_ranger: Assertion elem' failed.`, which is promptly followed by candybar aborting.

Something of note: I use an external DAC and I've noticed that when It's not plugged in I don't get the error, but I do get this instead: ERROR could not attach card 'default' to mixer (-2) (volume.c), although unlike the other error candybar doesn't abort.

For the record I use ALSA, in case that's important.

It appears that the widget_data_callback macro crashes whenever it's run from a callback function set with g_signal_connect_closure. This makes it a bit more difficult to optimize receiving data through the "workspace" signal provided in the i3ipc-glib library for the temporary i3wm desktops widget replacement. I think I'm a bit in over my head.

Here's a link to the specific code I'm having problems with at around line 42. The callback is set through the convenience function i3ipc_connection_on which subscribes to signals through i3. The code for this function can be found here at around line 916.

Screenshot from recent commit.

Screenshot after changing dim.w = 1920.

It turns out that screen->width_in_pixels outputs 5760, which is the total combined width of my three monitors. Despite this the window only appears on one monitor.

At minimum allow for the same config to appear across all monitors.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Instead of requiring another application to send info about visible windows, number of desktops, etc. we could request this info from the root window: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html

With #45 merged we should support most tiling WMs. Here's a list of the current (confirmed) supported WMs:

• qtile (@Lokaltog) - working after qtile/qtile@02fd471 (qtile/qtile#385)
• bspwm (@Lokaltog) - requires bspc config (top|bottom)_padding 26, does not support any space reservation properties and does not support the dock hint
• dwm (@bbenne10 @Lokaltog) - does not support EWMH, requires the dwm bar to have the same height and position as wkline to reserve the proper space
• monsterwm (@bbenne10)
• i3wm (@Lokaltog) - uses the dock hint and adds wkline as an additional statusline

Please post a comment if you're running a WM not on this list so I can add it to the list and eventually add this list to the README.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I tried out candybar on i3, and while the first impression was positive, I was missing the system tray that is present in i3bar. I'm guessing this could be implemented as a separate widget, allowing it to be visible for those who want it and hidden otherwise.

Having a system tray in candybar would greatly increase its usefulness, as tray icons/applets usually offer quick access to information, features and settings that may be too complex or too specific for a widget to handle itself.

A good example is the NetworkManager applet, which provides both information about the current connection, and options for selecting different network connections as well as other network-related configuration settings.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

After adding macros and utility functions, I was wondering what's best practice for organizing the util directory. Some of the code rely on standard macros like MIN, MAX, and quite a lot of #defines are being added all over the place (most of it my fault, I apologize for that).

Is it good practice to have e.g. a macros.h and defines.h in the util directory that can be included in wkline.h or something like that?

Also, when adding utility functions, should each function have a separate .c/.h file if the functionality falls under the "general function" category (like the copy_prop function I added earlier today)?

The statusline isn't refreshed on every event it should - the window title often isn't updated, and urgent desktops aren't highlighted before a refresh is triggered by e.g. switching desktops. The XCB event listener should subscribe to more WM events to fix this issue.

I'm not great at naming projects, and "wkline" is a placeholder name I used when creating the repo. I'm not a fan of the name but don't really know what else I'd name the project, do any of you guys have any suggestions?

Candybar loads its own set of browser plugins, which on a system with Pipelight for Silverlight and Flash results in an excessively unnecessary load on the system. It would be nice if Candybar either didn't load plugins or had a config option to prevent the loading of plugins.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Both applications offer XMLRPC support, and sabnzbd offers JSON-RPC which won't have to introduce another dependency. It would be cool to have a status widget, possibly with speed statistics and graph, and notification support (some form of alert on finished downloads) for these applications.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

i think mpd also has this interface so it would be good to implement it, it's also used by spotify gnome-music clementine?(not sure) and Amarok docs in http://specifications.freedesktop.org/mpris-spec/latest/

wkline sometimes crashes with a "corrupted double-linked list" error in the battery widget.

GDB output

By blocking with select() we could avoid having to kill the child threads and do extra cleanup. By blocking with a timeout we could easily signal all the threads on page reload or SIGINT. The threads would break out of the main loop immediately or after finishing any work, then do the cleanup and we'd avoid the mess with cleanup handlers after killing the threads.

Possibly related articles: 1 2

Edit: possibly use epoll instead of select for this feature.

Attempting to send notifications via notify-send or any other notifications results in:

** Message: console message: file:///home/lucas/.config/wkline/wkline-theme-default/webroot/index.html @1: Could not update widget: TypeError: undefined is not an object (evaluating 'this.widgets[a].update')

Side note: I did locally install the theme, but the same error will appear even with the default web-based theme.

Edit: I used the AUR build. wkline-git 170.6b6715b-1

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Hi there,

I'm trying out wkline for the first time today - very cool concept. However, I'm running into an issue where the toolbar crashes a short time after being run, failing with a SIGSEGV error. Here is the relevant output:

fish: Job 1, “wkline” terminated by signal SIGSEGV (Address boundary error)
jonathan@UbuntuMaven ~> fixme:advapi:UnregisterTraceGuids 0: stub

The failure happens pretty consistently.

Not sure if it's relevant, but the failure is always accompanied by the fixme:advapi:UnregisterTraceGuids 0: stub message. To my understanding, this is a Wine output. Pipelight seems to be attaching itself to the wkline process, as shown by the startup logs:

jonathan@UbuntuMaven ~> [17:52:18] INFO wkline beta-git-342.b9eee92 (Apr 27 2014 15:09:23)
[PIPELIGHT:LIN:unknown] attached to process.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Screen brightness would be a useful widget to have especially for laptop users. I found some GNOME code as for how they use dbus to control brightness. My C is terrible (practically nonexistent), but I'll take a stab at it later. For reference if anyone wants to take a crack at it: https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=a4c3299c97ced9c9bcdc69800464103ba47a0a56

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

There's really no reason why LIBDIR should be hardcoded at compile time. I'm implementing command-line argument parsing (to be able to define a custom config file), I'm thinking that we could include --libdir as a command-line argument, and fall back to the compile-time libdir if this argument isn't provided.

We could also support loading of widgets from arbitrary locations, e.g. by supporting absolute file paths in the widgets array in the config file.

What's everyone's thoughts on making each widget a loadable library and added to the global collection upon application initialization? This way, if someone else wants to write a widget, it won't require a complete recompile of the application?

I was planning on implementing something like this by using GModule to handle this.

wkline currently relies upon ewmh hints to set it's role as a dock. This seems to be not quite enough, as many tiling window managers don't respect those hints. monsterwm, for instance, currently doesn't work with wkline. DWM wouldn't either (if you ripped it's built in bar out). I've not looked over the code for snapwm or dminiwm recently, but I suspect that it wouldn't work there either.

This could be fixed by setting "override redirect" on the window, but I'm not sure how that would affect anything else. I've tried doing this locally, but I'm getting a segmetation fault that I've not yet had time to track down. I don't have the code on me now (or I'd just link to a gist-d diff), but it was in wkline.c's main() that I acquired a gdk window from the gtk window and called gdk_set_override_redirect(gdkw, TRUE);. Doing this led to a segmentation fault on the gdk_set_override_redirect line reliably (before and after any other changes to the window, so it wasn't some conflict cause by using both gtk_* window handling and the gdk_set_override_redirect).

Does anyone have any thoughts on this? I'd be happy to finish up the (probably very small) changes, if they'd be welcome.

Some sort of lock should be implemented, if you send SIGUSR1 before all the threads have been joined and restarted you'll end up with some threads being killed after restarting, and in some cases a segfault when it tries join threads that have already been joined.

The datetime widget should be moved to the theme JS file and incremented with a setInterval.

The mpd now playing widget needs to be parsed in the theme JS file, and the player position and progress bar needs to be updated with a setInterval to work properly (currently the mpd widget only sends updates when the player state has changed to playing/paused/stopped).

Could be a bit cleaner solution. Not sure about having dbus as a dependency, maybe it could be an optional feature that's enabled in config.h or something like that.

DBUS API guide

Wkline crashes after mpd is killed if mpd was running when wkline was started.

http://rvr.typepad.com/wind/2011/10/webkit-extending-javascript-3.html

Ref #14

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Here's the issue:

• Have candybar open and suspend via systemctl suspend
• Resume, and have candybar say I have 0% battery

Candybar states I have 0% battery (with the accompanying red glowing background) for a decent amount of time afterwards, up to 15-20 seconds (I didn't time it, that's just approximately what I remember).

I'm running UPower, so perhaps UPower, or the underlying power information UPower is abstracting, isn't restored immediately, so UPower could be returning 0 as the battery's percentage if candybar is asking immediately on resume. One more thing of note is that I've never noticed this on short suspends, but if I don't use my computer for a few hours than this issue tends to pop up. For example, if I run systemctl suspend right now, and immediately proceed to resume, candybar works fine. Does candybar's battery interface operate on an event driven basis or a polling one?

I'm using the latest version available of candybar as of this issue's submission date.

I'm not sure if this is a bug or intended behaviour, but here it goes. Here's an example of my problem in case it's not clear:

- Only have one workspace, no gui applications open

• Open Firefox, window_title in candybar is updated to reflect FF title
• Switch to new blank workspace in i3, however window_title still shows FF title

Window_title should not output anything on a blank workspace in my opinion.

Tried running some of our source code through splint, and it spews out a ton of warnings. Some of these warnings should probably be looked into (buffer overflow issues, possible null pointers, etc). Here's a command that can be run from the project root:

splint [file.c] -I. -I `pkg-config --cflags gtk+-3.0 webkitgtk-3.0`

Output for src/wkline.c
Output for src/wkline/widgets.c

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I'm starting to think the current way of having a JSON-based config system will cause more and more issues over time. First of all, we don't really need a tree-structured config file, a flat file could work equally well. If we implement JavaScriptCore extensions we won't need to depend on a JSON library at all. Here's a proposal for an improved config format:

Use an existing config library like libconfuse.

Each widget shared object library will provide a predefined config struct with default values, if we use libconfuse it would be something like this.

The config loader will override any default values in the config structs for each widget with new values found in the config file.

Any ideas/suggestions?

If a window is created and killed very quickly (e.g. open terminal then immediately kill it), reading wm_name fails and the active window title loop is repeated and fails a lot of times, resulting in a long stderr log and high cpu usage:

Could not read WM_NAME from active window
Error while fetching EWMH properties (2, 0), not updating
Could not read WM_NAME from active window
Error while fetching EWMH properties (2, 0), not updating
[repeated a couple of hundred times]

To avoid having XCB as a dependency (to support Wayland) for the desktop list and window title widgets, we can use GDK to get desktop info. Here is a source file that demonstrates using gdk_property_get to get WM properties like the desktop list, current desktop, etc.

I've implemented an alternative way to create background effects, as CSS filters proved to be a bit wonky (the blur effect is a major hassle to implement properly, and the webview frequently crashed due to out of memory errors when testing it with various images and settings).

This feature requires graphicsmagick (switched from imagemagick due to poor performance) to work, which isn't ideal, but I don't know another better way of doing this efficiently. The bg image is generated on startup and don't use any extra resources when wkline is running.

What this widget does is crop an image of your choice, then apply a configurable amount of brightness/saturation/blur to the image, then sets it as the statusline background image.

Here's a screenshot of a test I just did with blur and lower brightness applied:

To enable this widget, make sure you have graphicsmagick installed and recompile wkline. You should now be able to enable the magick_background widget in your config.json:

        {
            "module": "magick_background",
            "config": {
                "image": "file:///path/to/your/bg-image.jpg",
                "blur_radius": 0,
                "brightness": 100,
                "saturation": 100
            }
        },

These are the options you're most likely to want to use currently, the rest are defined in the widget header file. The brightness and saturation settings are set as percentages in the range 0..100 (100 is default brightness/saturation).

You may need to tweak the values depending on your background image and preference. I found that a blur radius of 3 or 4, brightness of 70-80 and saturation of 0 looks pretty good with medium to dark images.

Anyways, it would be great if you guys could give me some feedback on this and let me know what you think, or if you have suggestions to other effects that can be added (any feature of graphicsmagick is possible).

wkline segfaults if weather data loading fails:

error: server responded with code 400
Error while fetching weather data
fish: Job 1, “wkline” terminated by signal SIGSEGV (Address boundary error)