candybar - new WebKit-based status bar for tiling window managers

Lokaltog · 2014-03-07 08:05:05

Thanks for your comments!

ooo wrote:

out of curiosity, what's the memory footprint/overall speed like with wkline?
for me it feels like having a huge library like webkit as dependency wouldn't really fit the whole minimal desktop philosophy

I can totally understand your viewpoint. I've used dwm for years and been a "minimalist addict" before switching to qtile and now bspwm. Concerns about resource usage and large dependencies like GTK and WebKit are legitimate criticisms for a project like this.

According to valgrind wkline itself uses a couple of MB of memory, it doesn't use any CPU when idle, but some when updating a widget. The overall speed is very fast, changes in e.g. selected desktop, volume, currently playing songs, etc. are instantaneous. That being said, the focus of the projects isn't really zero resource usage, so if a minimal memory footprint is important to you, or if you don't care about how the statusline looks, you shouldn't use this project.

The project is primarily aimed at users and tinkerers who prefer tiling WMs but still enjoy eyecandy and customizability at the cost of a bit more resource usage. After trying to hack around the limitations of WMs and other apps for some time (see Powerline) I realized I'd rather sacrifice some resources and create a project like this in order to have a ton of flexibility so I can create exactly what I want, instead of trying to fight against the limitations of other alternatives.

Webkit is unfortunately not as lightweight as I'd prefer, but I think it's a pretty good compromise between resource usage, flexibility and ease of use. I'm continously working on reducing the resource usage further, one way of doing this is by providing access to widget data by extending JS like mentioned above, other ways may include using CSS to do the rendering on the GPU instead of the CPU, using static images instead of CSS gradients, etc. It's also possible to create more plain looking themes that don't update as often, which significantly reduces the resource usage.

ooo · 2014-03-07 16:08:24

didn't mean to critisize in any way. Merely wondering how lightweight webkit could be as rendering engine.
I was thinking that memory usage of anything <50MB would be pretty good, so couple of MB is quite impressive

have fun with the project.

Lokaltog · 2014-03-07 16:45:27

I thought a couple of MB seemed a bit low too, and I might be measuring the memory usage incorrectly (this is my first C project and I have a grand total of two weeks of experience writing and debugging C code), but according to the internet using valgrind is the best way of getting an accurate reading of the memory footprint. I suspect it might be quite a bit more in total though, as I'm not sure if valgrind measures the total memory usage of all the shared libraries (i.e. webkit), so anyone please correct me if I'm wrong!

chickenPie4tea · 2014-04-15 17:00:40

Glad I found this - after hours spent trying to get the desktop names to show in lemonboys bar using BSPWM I gave up and installed this - after launching it with
wkline &
the bspwm desktop numbers showed up fine - simple and easy! and looks way better.

Lokaltog · 2014-04-18 18:54:50

Glad you like it! I've moved to bspwm myself, so development on wkline will primarily target bspwm (which supports EWMH very well from a statusbar development perspective), as well as other EWMH compliant WMs. Some work has also been done on implementing an i3 compatible desktop list which uses i3's JSON socket interface instead of EWMH to get the desktop list.

shmibs · 2014-04-19 05:33:54

launching wkline causes an overall memory jump of 37 or so MB for me (just watching usage in htop), so i guess it's a fair trade-off for people who are used to web-based theming. also, yay for compatibility with things! clicking the desktop list appears to have no effect under herbstluftwm, though. does it not do anything yet?

Lokaltog · 2014-04-19 09:01:52

Yep, the total (resident) memory consumption appears to be about 40MB on my setup with all the widgets enabled (I looked at the wrong numbers earlier). I don't think it's possible to make it more lightweight if you want to be able to use HTML and CSS for theming.

I've done some work on implementing changing desktops when clicking the desktop names, changing the volume when clicking the volume widget, and re-checking weather/mail status when clicking those widgets. I haven't pushed all the code to the repo yet as it needs a bit more work.

I haven't gotten changing desktops to work yet, as I haven't found a way to properly set the correct EWMH properties, when checking the root window properties with xev it appears that XCB is unable to set the desktop number property. It's on top of the todo list and hopefully I'll be able to implement it soon!

tobias_ · 2014-04-24 19:54:36

On my setup with xmonad I see a strange behaviour:

_NET_WM_STRUT(CARDINAL) = 0, 24, 0, 24

Apparently the reserved space is wrongly set to 24px on bottom and right, but I see that its correctly set in the source. Does anyone have a clue?

Also: can you allow other devices than just battery_* for the battery plugin? I have two batteries in my laptop, and the sum is displayed in "DisplayDevice"

% upower -d                                                                                                                                                        [21:50:30]
Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path:          AC
  power supply:         yes
  updated:              Do 24 Apr 2014 18:51:11 CEST (11144 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    warning-level:       none
    online:              no
    icon-name:          'ac-adapter-symbolic'

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          BAT0
  vendor:               SANYO
  model:                45N1109
  serial:               33185
  power supply:         yes
  updated:              Do 24 Apr 2014 21:55:49 CEST (66 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    energy:              16,37 Wh
    energy-empty:        0 Wh
    energy-full:         22,12 Wh
    energy-full-design:  23,2 Wh
    energy-rate:         0 W
    voltage:             11,752 V
    percentage:          74%
    capacity:            95,3448%
    technology:          lithium-ion
    icon-name:          'battery-full-symbolic'

Device: /org/freedesktop/UPower/devices/battery_BAT1
  native-path:          BAT1
  vendor:               SANYO
  model:                45N1775
  serial:               7109
  power supply:         yes
  updated:              Do 24 Apr 2014 21:55:49 CEST (66 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    energy:              14,54 Wh
    energy-empty:        0 Wh
    energy-full:         21,94 Wh
    energy-full-design:  23,2 Wh
    energy-rate:         7,199 W
    voltage:             11,649 V
    time to empty:       2,0 hours
    percentage:          66%
    capacity:            94,569%
    technology:          lithium-ion
    icon-name:          'battery-full-symbolic'
  History (charge):
    1398369349	66,000	discharging
  History (rate):
    1398369349	7,199	discharging

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply:         yes
  updated:              Do 01 Jan 1970 01:00:00 CET (1398369415 seconds ago)
  has history:          no
  has statistics:       no
  battery
    present:             yes
    state:               discharging
    warning-level:       none
    energy:              30,91 Wh
    energy-full:         44,06 Wh
    energy-rate:         7,199 W
    time to empty:       4,3 hours
    percentage:          70,1543%
    icon-name:          'battery-full-symbolic'

Last edited by tobias_ (2014-04-24 19:57:16)

Lokaltog · 2014-04-24 20:03:31

I'm not sure what's wrong with the _NET_WM_STRUT property or why it might be set incorrectly, I'll have to investigate it. It would be great if you could post these issues to github so they're in the issue tracker. Regarding the battery path, I didn't realize that batteries could be stored at totally different paths, but it's an easy fix to allow having a full path to the battery instead of relying on the current path template string.

Jwpe · 2014-04-27 17:47:38

This seems like a really cool concept. Do you think it would be possible to extend this to make an entire WM driven by Webkit?

HalosGhost · 2014-04-27 18:22:01

Jwpe wrote:

This seems like a really cool concept. Do you think it would be possible to extend this to make an entire WM driven by Webkit?

Probably; GNOME is driven entirely by JS and CSS, afterall. I don't see why adding HTML would be so difficult. The real question would be whether or not that would be worth the performance penalty—running a statusbar through webkit is one thing, a whole WM is entirely different.

All the best,

-HG

Lokaltog · 2014-04-27 19:27:44

Jwpe wrote:

This seems like a really cool concept. Do you think it would be possible to extend this to make an entire WM driven by Webkit?

Maybe. It's probably possible given enough time and code, but it sounds hugely impractical - at least if you're implementing it on X instead of as an alternative to X (not implying that creating an alternative to X is possible in WebKit). If it's supposed to run on X you'd have to find a way to pass information like window contents, EWMH properties and client requests, etc. to a WebKit instance. Some of this, like retrieving window contents is as I understand it pretty difficult to do with the X protocol (this is why you need a compositor to be able to create stuff like transparent windows). You'd also have to handle all kinds of stuff like window dimensions and placement, etc. and pass those back to X. A WM also typically doesn't require stuff that's easy to implement with CSS/JS (like complex GUIs or good theming support), so there aren't any practical reasons I can see to write a WM in WebKit either. Not to mention that it will also almost certainly perform worse than a WM written in C.

tl;dr probably possible, but incredibly impractical.

Head_on_a_Stick · 2014-04-27 21:41:36

What an amazing status bar --- really lovely work

Lokaltog · 2014-04-28 06:33:13

tobias_ wrote:

Apparently the reserved space is wrongly set to 24px on bottom and right, but I see that its correctly set in the source. Does anyone have a clue?

tobias_ wrote:

Also: can you allow other devices than just battery_* for the battery plugin? I have two batteries in my laptop, and the sum is displayed in "DisplayDevice"

I just pushed fixes for both of these issues, they should be resolved in the latest commit.

There was a type-related issue that caused _NET_WM_STRUT to be set with incorrect values which is now resolved and tested to work in a WM that supports the property (qtile).

I've also updated the battery widget to accept a full DBus device path, please note that the config option has been renamed from "name" -> "dbus_path".

Jwpe · 2014-04-29 04:27:08

Lokaltog, HalosGhost, thanks for your responses. Just to clarify, I know very little about the implementation of existing window managers - more of a curious user/amateur, so please forgive me any technical inaccuracies.

I'm very interested in the idea of a HTML/CSS(/JS?) based window manager as a concept, as I think it would allow a degree of customization that isn't really available in any current window manager. What I was imagining was users using some kind of HTML templating engine to define their own screen layouts, and treating application windows as elements within those layouts. It seems to me like the flexibility of such a setup would be really cool. One of the main reasons for the HTML/CSS combo is that it would open the desktop environment up to a wide user base who already have the requisite skills to design cool interfaces.

However, it sounds from your replies that implementing something like that on top of X via WebKit would be impractical from a resource perspective. I wonder if this is a case of looking for a lighter HTML rendering engine, or if the concept itself is flawed.

Lokaltog · 2014-04-29 06:55:25

It would be fun to be able to use stuff like CSS flexboxes and having JS-based widgets, but I think it's simpler to just reimplement what layout functionality you can get from CSS in another WM, than to use WebKit itself as a WM. It's not only the resource cost, but the requirement of a compositor and having a "X translation layer" to translate window data to/from the WebKit web view. After working a bit with X and JavaScriptCore I can tell you that you *don't* want to attempt implementing an X translation layer in JSCore! I think it could be a fun experiment if you want to learn more about X and WebKit/JavaScriptCore, but I'm not sure if it will have a real-world use case even if you're able to build it, due to the complexity and resource cost of running it inside WebKit (or any other modern rendering engine).

fiddler · 2014-05-01 07:19:34

great project! but why changing the name to candybar?

Lokaltog · 2014-05-01 08:03:14

Works with "eye-candy status bar", and I think it sounds better than "wkline"!

ondoho · 2014-05-01 08:24:21

great, you changed the name!
i was thinking about that - nobody can say "wkline". better change it now than being stuck with it later.

Lokaltog · 2014-05-01 08:59:32

ondoho wrote:

great, you changed the name!
i was thinking about that - nobody can say "wkline". better change it now than being stuck with it later.

Yep, it has been bothering me since I started the project, so it feels good having a proper name for it. wkline was just a placeholder name, but as they say, "there are only two hard problems in Computer Science: cache invalidation and naming things."

BluMongoose · 2014-05-08 20:09:43

Hey Lokaltog, thanks for all the work on the project and the quick response to my comment in the AUR. I am having 2 issues currently. When i have my headset set as the default sound card I get a core dump with the following :

[14:57:32] INFO candybar beta-git-415.5e232b0 (May  8 2014 12:57:28)
No bp log location saved, using default.
[000:000] Cpu: 6.42.7, x4, 3700Mhz, 7885MB
[000:000] Computer model: Not available
[000:000] Browser XEmbed support present: 1
[000:000] Browser toolkit is Gtk2.
[000:007] Using Gtk2 toolkit
[000:016] No bp log location saved, using default.
[000:017] Cpu: 6.42.7, x4, 3700Mhz, 7885MB
[000:017] Computer model: Not available
[000:017] Browser XEmbed support present: 1
[000:017] Browser toolkit is Gtk2.
[000:017] Using Gtk2 toolkit
No bp log location saved, using default.
[000:000] Cpu: 6.42.7, x4, 3700Mhz, 7885MB
[000:000] Computer model: Not available
[000:000] No bp log location saved, using default.
[000:001] Cpu: 6.42.7, x4, 3700Mhz, 7885MB
[000:001] Computer model: Not available
[000:024] No bp log location saved, using default.
[000:024] Cpu: 6.42.7, x4, 3700Mhz, 7885MB
[000:024] Computer model: Not available
[000:024] Browser XEmbed support present: 1
[000:025] Browser toolkit is Gtk2.
[000:025] Using Gtk2 toolkit
[000:003] No bp log location saved, using default.
[000:004] Cpu: 6.42.7, x4, 3700Mhz, 7885MB
[000:004] Computer model: Not available
[14:57:32] INFO using config file '/home/blue/.config/candybar/config.json'
[14:57:32] INFO loading theme 'file:////usr/share/candybar/theme-default/index.html'
java version "1.7.0_55"
OpenJDK Runtime Environment (IcedTea 2.4.7) (ArchLinux build 7.u55_2.4.7-1-x86_64)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
candybar: simple.c:282: snd_mixer_selem_get_playback_volume_range: Assertion `elem' failed.
[1]    4027 abort (core dumped)  candybar

I also have a noob question on how to enable the desktops_i3 widget. I installed i3ipc-glib and changed the config file entry from "desktops" to "desktops_i3" which fails because /usr/lib/candybar/libwidget_desktops_i3 does not exist. Was that not the correct entry in the config file, or do I need to specify a path for that widget?

Lokaltog · 2014-05-08 20:15:58

The sound card bug is on the todo list for the 0.1 release, check this issue out (similar problem/error message): https://github.com/Lokaltog/candybar/issues/71

You have to recompile candybar after installing i3ipc-glib for it to work. If you install i3ipc-glib from the AUR waf should detect it and make sure that the desktops_i3 widget is compiled. Please let me know if this resolves your issue!

BluMongoose · 2014-05-08 20:22:08

Man you are fast! Yes, now it works like a charm. Thanks again for all your work, this bar is really awesome.

Lokaltog · 2014-05-08 20:28:58

It was a pretty simple fix (just had to check if a pointer was valid), I've committed a fix now. Check out the latest commit, and please let me know if the volume widget works correctly now!

BluMongoose · 2014-05-08 20:36:29

It does not core dump now, but I get the following:

[15:31:41] INFO candybar beta-git-416.0f2b4fd (May  8 2014 15:30:32)
No bp log location saved, using default.
[000:000] Cpu: 6.42.7, x4, 3700Mhz, 7885MB
[000:000] Computer model: Not available
[000:000] Browser XEmbed support present: 1
[000:000] Browser toolkit is Gtk2.
[000:006] Using Gtk2 toolkit
[000:016] No bp log location saved, using default.
[000:017] Cpu: 6.42.7, x4, 3700Mhz, 7885MB
[000:017] Computer model: Not available
[000:017] Browser XEmbed support present: 1
[000:017] Browser toolkit is Gtk2.
[000:017] Using Gtk2 toolkit
No bp log location saved, using default.
[000:000] Cpu: 6.42.7, x4, 3700Mhz, 7885MB
[000:000] Computer model: Not available
[000:000] No bp log location saved, using default.
[000:001] Cpu: 6.42.7, x4, 3700Mhz, 7885MB
[000:001] Computer model: Not available
[000:024] No bp log location saved, using default.
[000:025] Cpu: 6.42.7, x4, 3700Mhz, 7885MB
[000:025] Computer model: Not available
[000:025] Browser XEmbed support present: 1
[000:025] Browser toolkit is Gtk2.
[000:025] Using Gtk2 toolkit
[000:003] No bp log location saved, using default.
[000:004] Cpu: 6.42.7, x4, 3700Mhz, 7885MB
[000:004] Computer model: Not available
[15:31:41] INFO using config file '/home/blue/.config/candybar/config.json'
[15:31:41] INFO loading theme 'file:////usr/share/candybar/theme-default/index.html'
java version "1.7.0_55"
OpenJDK Runtime Environment (IcedTea 2.4.7) (ArchLinux build 7.u55_2.4.7-1-x86_64)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
[15:31:41] ERROR could not find selem 'Master' (volume.c)
[15:31:41] ERROR dbus error: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

[15:31:41] ERROR dbus: invalid battery (battery.c)

I am not sure if this is common among headsets, but instead of a master channel I have a Speaker channel. I assume that this may have something to do with it.

Arch Linux

#26 2014-03-07 08:05:05

Re: candybar - new WebKit-based status bar for tiling window managers

#27 2014-03-07 16:08:24

Re: candybar - new WebKit-based status bar for tiling window managers

#28 2014-03-07 16:45:27

Re: candybar - new WebKit-based status bar for tiling window managers

#29 2014-04-15 17:00:40

Re: candybar - new WebKit-based status bar for tiling window managers

#30 2014-04-18 18:54:50

Re: candybar - new WebKit-based status bar for tiling window managers

#31 2014-04-19 05:33:54

Re: candybar - new WebKit-based status bar for tiling window managers

#32 2014-04-19 09:01:52

Re: candybar - new WebKit-based status bar for tiling window managers

#33 2014-04-24 19:54:36

Re: candybar - new WebKit-based status bar for tiling window managers

#34 2014-04-24 20:03:31

Re: candybar - new WebKit-based status bar for tiling window managers

#35 2014-04-27 17:47:38

Re: candybar - new WebKit-based status bar for tiling window managers

#36 2014-04-27 18:22:01

Re: candybar - new WebKit-based status bar for tiling window managers

#37 2014-04-27 19:27:44

Re: candybar - new WebKit-based status bar for tiling window managers

#38 2014-04-27 21:41:36

Re: candybar - new WebKit-based status bar for tiling window managers

#39 2014-04-28 06:33:13

Re: candybar - new WebKit-based status bar for tiling window managers

#40 2014-04-29 04:27:08

Re: candybar - new WebKit-based status bar for tiling window managers

#41 2014-04-29 06:55:25

Re: candybar - new WebKit-based status bar for tiling window managers

#42 2014-05-01 07:19:34

Re: candybar - new WebKit-based status bar for tiling window managers

#43 2014-05-01 08:03:14

Re: candybar - new WebKit-based status bar for tiling window managers

#44 2014-05-01 08:24:21

Re: candybar - new WebKit-based status bar for tiling window managers

#45 2014-05-01 08:59:32

Re: candybar - new WebKit-based status bar for tiling window managers

#46 2014-05-08 20:09:43

Re: candybar - new WebKit-based status bar for tiling window managers

#47 2014-05-08 20:15:58

Re: candybar - new WebKit-based status bar for tiling window managers

#48 2014-05-08 20:22:08

Re: candybar - new WebKit-based status bar for tiling window managers

#49 2014-05-08 20:28:58

Re: candybar - new WebKit-based status bar for tiling window managers

#50 2014-05-08 20:36:29

Re: candybar - new WebKit-based status bar for tiling window managers

Board footer