Left margin of the module + change the font style of the active window

[Dupond]

Hello!

Here's my humble feedback, after finally finding the time to test your module. It's great: I love it! Thanks for bringing it to my attention here :)

If you don't mind, I'd just like to ask you a couple of questions:

• having carefully read your README before installing the module, I'd have appreciated being able to know what the default configuration options were without having to open the config.toml file; perhaps it would be possible, in the configuration table, to add " (default)" in each line next to the default value?
• in my polybar configuration file, I have successively the ewmh and windowslist modules... but (silly me) I can't figure out which option defines a margin between the two (sorry for this question, which is a bit outside the strict scope of your module);
• finally, with the little script I've been using until now, I used to distinguish the name of the active window in my polybar not by changing its color (or the color of the name of other windows) but simply by putting it in bold; is this also possible with your module? If not, would you consider adding this option?

I've carried out a few performance tests on my machine: in normal use, the impact of the module seems almost non-existent (at least, it's not very different from what it was with my previous script); but when moving a window, my 4 CPUs easily climb to 25 or 30% utilization each (tested with htop), whereas with my previous script, in this same scenario, they remained below 10%.

[tuurep]

Hi,

Great to hear that you like it! I created this module because I wanted it so badly myself and polywins had a bug that was unacceptable to me (with wrong window names) so I went to great lengths to fix it all up.

I use it all day every day so that's awesome that others find it useful as well 😄

Answers:

having carefully read your README before installing the module, I'd have appreciated being able to know what the default configuration options were without having to open the config.toml file; perhaps it would be possible, in the configuration table, to add " (default)" in each line next to the default value?

Yeah absolutely. I didn't add them before, for a poor reason: In my typical browser window, it has such cramped horizontal space:

---

So I tried to not add any more columns, but what you're suggesting we could definitely do, plus one can always scroll or maximize the window so this is a personal problem to me 😄

in my polybar configuration file, I have successively the ewmh and windowslist modules... but (silly me) I can't figure out which option defines a margin between the two (sorry for this question, which is a bit outside the strict scope of your module);

Hmm I tried something out:

[module/windowlist]
type = custom/script
exec = ~/.config/polybar/scripts/windowlist/main 2> /dev/null
tail = true

format-margin = 10

Looks like format-margin is having an effect, if this is what you're after?

Source:

https://github.com/polybar/polybar/wiki/Formatting

(admittedly quite incomplete docs)

finally, with the little script I've been using until now, I used to distinguish the name of the active window in my polybar not by changing its color (or the color of the name of other windows) but simply by putting it in bold; is this also possible with your module? If not, would you consider adding this option?

Good news on that, I semi recently came up with that myself and opened an issue on it as a little TODO:

#24

I'll add this real soon since you want to use it :)

I've carried out a few performance tests on my machine: in normal use, the impact of the module seems almost non-existent (at least, it's not very different from what it was with my previous script); but when moving a window, my 4 CPUs easily climb to 25 or 30% utilization each (tested with htop), whereas with my previous script, in this same scenario, they remained below 10%.

Mostly sounds really great!

How do you feel about that 25%-30%, is it bad?

And what do you think of the sort_by option: "position"? I've considered making so that only if you have that option set, we listen to the events that are related to window geometry changes.

So if you're fine not using the "position" sort (which I personally prefer), I could try increasing the performance.

But I would have to check whether name = "title" requires listening to the same events, context:

#6

Thanks for the feedback, I'll open some new issues raised from here, also please check whether you find other issues interesting, and contributing in any way is welcome.

First thing I'll add your font thing and add defaults to the readme 😄

[Dupond]

Thank you for your answers!

So I tried to not add any more columns

Don't you just want to add "default" next to the value in the 3rd column? For example, for the sort_by line: "none (default): unordered etc."

Looks like format-margin is having an effect, if this is what you're after?

Yes, it works perfectly; thank you! I was able to restore the same layout I was using before.

After changing the configuration in config.toml the changes are only applied after manually killing and restarting polybar, right? By running killall -q polybar;polybar -q -r mainbar & polybar restarts, but the windowslist module is not displayed until an action triggers the window name refresh (e.g. an Alt-Tab). I don't know if it's possible to make windowslist relaunch automatically at the same time as polybar, without impacting performance...

I semi recently came up with that myself and opened an issue on it as a little TODO: #24 I'll add this real soon since you want to use it :)

Good news! Thank you!

I've considered making so that only if you have that option set, we listen to the events that are related to window geometry changes.

Makes sense, doesn't it? I've seen your last 2 issues; they look promising :)

One last question: how do I update the module properly? A simple git pull origin master will overwrite my changes to config.toml, right?

Thanks so much for all your work on this module!

[tuurep]

Don't you just want to add "default" next to the value in the 3rd column? For example, for the sort_by line: "none (default): unordered etc."

For the most part yes, but I need to reorganize the table quite a bit for the click-actions and colors: #26 (comment)

After changing the configuration in config.toml the changes are only applied after manually killing and restarting polybar, right? By running killall -q polybar;polybar -q -r mainbar & polybar restarts, but the windowslist module is not displayed until an action triggers the window name refresh (e.g. an Alt-Tab). I don't know if it's possible to make windowslist relaunch automatically at the same time as polybar, without impacting performance...

I've been noticing this too, but since it only comes up when editing and not regular use, didn't bother looking at it yet 😄 This could be as simple as doing a single output() outside of the main event loop. I'll try this, thanks!

Makes sense, doesn't it [#27]? I've seen your last 2 issues; they look promising :)

I'm pretty excited about this idea: #27 (comment)

Would make everything quite more solid, I think.

One last question: how do I update the module properly? A simple git pull origin master will overwrite my changes to config.toml, right?

Yes it would, I've been working around this simply by:

• mv config.toml ..
• git pull origin master
• mv ../config.toml .
• overwrite? y

Not sure what to do about it, if you have suggestions please share 😄

[tuurep]

I'm eager to start adding all these ideas, but today I really have to work on my thesis 😄 Tomorrow though, you bet.

[Dupond]

Not sure what to do about it, if you have suggestions please share

Perhaps you've heard of suckless tools? Generally (for the st terminal, for example) there are 2 configuration files: the default file (config.def.h) and the user file (the user copies the default file, renaming it config.h, and then applies the modifications he wishes). The update only replaces the default file, so you can compare the differences between the 2 files with a diff or vimdiff. But the program only takes the config.h file into account (if it was created by the user; otherwise, the default configuration file is applied).

I hope this is more or less clear...

There's no rush, but thanks for all the updates you plan to make... and good luck with your thesis :)

[tuurep]

I know suckless, even used slock before

But didn't know that config approach. I think we might be able to do that 😄 Thanks

[Dupond]

It's the same with nsxiv. Don't you use it? I thought I saw it in your dotfiles.

Edit: I must have made a mistake: I installed all this (st, nsxiv, etc.) a long time ago, but now that I think about it, I think make also generated the config.h file as a copy of config.def.h. Seems logical...

Edit 2: Confirmed: if I rename the nsxiv config.h file, it's recreated during make as a copy of config.def.h. So, contrary to what I said, the config.h file is always used. And the user doesn't have to create it himself.

[tuurep]

Great idea, we can also make config.toml in make.

I'll try to resolve #29 today, so we can continue pulling the other updates without hassle.

[tuurep]

Today's updates make it so much smoother to edit the config. Thanks :)

Will continue later.

[Dupond]

Today's (well... yesterday's) updates are great! Thanks to you :)

The update went smoothly, and the module is now displayed when I relaunch polybar. Perfect!

...

... I'm waiting for the rest :)

[Dupond]

I noticed that you recommend adding the module using: exec = ~/.config/polybar/scripts/windowlist/main 2> /dev/null. Do you consider this error redirection mandatory? Have you ever seen errors displayed with your module? I think I'll test without it for a while, just to see if it happens sometimes...

Also, the empty space in my polybar varies quite regularly; for example, I display the list of USB devices so that I can unmount them simply by clicking on them. As a result, the max_windows option isn't ideal: sometimes there's a lot of free space, sometimes quite little. Is it possible to limit the number of windows displayed in windowlist according to the space available, rather than a fixed number of windows?

[tuurep]

About stderr:

I think I've mostly taken that from polywins's example, which was this:

[module/polywins]
type = custom/script
exec = ~/.config/polybar/scripts/polywins.sh 2>/dev/null
format = <label>
label = %output%
label-padding = 1
tail = true

At some point I deemed these lines not necessary:

format = <label>
label = %output%
label-padding = 1

Still have kept the error redirection for some reason. I have a hunch it's for a good reason, especially because the error handling in XLib was very... strange:

windowlist/windowlist.c

Lines 217 to 238 in 54972b3

	int error_catcher(Display* d, XErrorEvent* e) {
	/*
	Ignore BadWindow error instead of halting program
	Because XLib is async, a window may already be destroyed when I try to do
	something with its ID.
	See these:
	https://stackoverflow.com/questions/44025639/how-can-i-check-in-xlib-if-window-exists
	https://stackoverflow.com/questions/51908828/xlib-and-badwindow
	*/
	if (e->error_code == BadWindow || e->error_code == BadDrawable) {
	// get_desktop_id() causes BadDrawable by extension of ignoring BadWindow:
	// gets an undefined window as argument
	fprintf(stderr, "Expected XError type %d\n", e->error_code);
	return EXIT_SUCCESS;
	}
	fprintf(stderr, "Unexpected XError type: %d\n", e->error_code);
	return EXIT_FAILURE;
	}

But yeah, let me know if it works out while removing the redirection.

Other question:

This sounds very complicated, I doubt I have the control to make this possible. Otherwise it's a good idea. If you've got any ideas how to measure space in Polybar, I'll take a look.

[tuurep]

Definitely keep the stderr redirection, when I was working on some stuff and adding debug prints, I noticed it spits out quite a bit of errors especially in the case of closing windows.

$ ./main
Expected XError type 3
Expected XError type 3
Expected XError type 3
Expected XError type 3
Expected XError type 3
Getting desktop property failed (_NET_WM_DESKTOP or _WIN_WORKSPACE)
Expected XError type 9
Expected XError type 3
Expected XError type 3
Expected XError type 3
Expected XError type 3
Expected XError type 3
Expected XError type 3
Getting desktop property failed (_NET_WM_DESKTOP or _WIN_WORKSPACE)
Expected XError type 9
Expected XError type 3
Expected XError type 3
Expected XError type 3
Expected XError type 3
Expected XError type 3
Expected XError type 3
Getting desktop property failed (_NET_WM_DESKTOP or _WIN_WORKSPACE)
Expected XError type 9
Expected XError type 3

^ this is put to stderr after a few times closing other terminal windows.

(comment out the output()s in main.c if you want to try.)

[Dupond]

Thanks for your explanations.

I updated to include your latest commits about an hour ago, and since then my CPU usage has soared: even without doing anything, they're all at over 50%. As soon as I remove the windowslist module from polybar, they drop back to 0 or 1%... I think one of your last commits causes this: are you seeing the same thing on your side?

[tuurep]

Sounds strange! So are you sure it's good in 54972b3?

If so, I only made real changes when adding the double-click actions: #36

I find it hard to see anything on my side because I have excessive CPU specs. When I hold down Alt + Tab, which for me updates the module on each repeat, I can see windowlist main climb up in htop, showing ~4% CPU%.

[tuurep]

Well here's something: when I switched to using default config, main segfaults. Let's see what's up with that.

Observations:

• Doesn't segfault with an empty config.toml

Found it, config-default.toml:

inactive_window_left_click        = "raise"
inactive_window_right_click       = "close"
inactive_window_middle_click      = "none"
active_window_left_double_click   = "none" <---------- inactive*
active_window_right_double_click  = "none" <---------- inactive*
active_window_middle_double_click = "none" <---------- inactive*
inactive_window_scroll_up         = "none"
inactive_window_scroll_down       = "none"

[tuurep]

Well, nice to spot the broken default config (fixed: c89c02f), but since your program wasn't segfaulting, I doubt it could be related to that?

[tuurep]

I don't know how to use htop much, but maybe this would indicate that windowlist has just about zero impact:

[Dupond]

Weird: after rebooting my PC, everything went back to normal... So I did add back 2>/dev/null to my polybar config, you never know :) However, there's one more problem: with name="title" the module displays "Left margin of the module + ch‥" instead of displaying the name of the first window opened (e.g. "firefox")... I don't have this issue if I use name="class".

One last thing I wanted to ask you: when I open LibreOffice Writer, the windowlist module displays "N/A" for 1/2 second, then "Soffice". When an action on the windows causes a refresh of the windowlist (for example, an Alt-Tab), the name changes again from "Soffice" to "libreoffice-writer". So... if the name is not yet available ("N/A"), is there any point in displaying it? On the other hand, windowlist only seems to be able to display the actual program name after a refresh... Is there anything I can do to improve this?

[tuurep]

I'm gonna take a proper look later, but off the top of my head:

"N/A" means there's literally a window opened that has a WM_CLASS of "" (empty), and I change it to "N/A". I believe this is something I took from polywins. In my experience, too, this has most commonly been seen when some kinda loading window opens until the application launches.

If you're sure you never care to see a window that has an empty WM_CLASS, you could try:

config.toml:

ignored_classes = [ "n/a" ]

"Soffice" thing sounds really strange. I'll have to try and see.

[tuurep]

Great to know the performance is good now

[Dupond]

Here's an image of the issue:

[tuurep]

Oh my.. Didn't have enough coffee I see:

            // Get events for individual windows' property changes,
            // to know when a window's title (WM_NAME) changes
            if (!strcmp(config.sort_by, "name")) {
                configure_windows_notify(d, prev_wlist, prev_wlist_len, wlist, wlist_len);
            }

sort_by = "name" instead of name = "title", really? 😄

Has another serious bug with the order of operations in the event loop, introduced in #31 Fixing this.

Update: gonna take a proper look in #37 when I have the time (hopefully today)

---

However, not 100% sure this is what your question referred to. The tab name is firefox's "title" (WM_NAME), but I've broken the auto-updating aspect of it.

Relevant:

#3
#6

[tuurep]

Identified and fixed the title updating problems:
#37
#38
If there's any more trouble, let me know.

Btw thanks.. You made me catch some serious mistakes 😄

[Dupond]

So far, so good...

"Soffice" thing sounds really strange. I'll have to try and see.

This problem only occurs with LibreOffice Writer (not with Base, Calc, Draw, etc.) As long as no action has occurred on the windows, the class remains "Soffice". It changes as soon as windowlist is refreshed, and becomes "libreoffice-writer". Of course, I can always add "Soffice" = "libreoffice-writer" in the nicknames, but it seems a bit odd: it looks like the window list is missing a refresh when its class changes; I don't know if other programs do this (have one class at launch, and another once the program is fully open). I've opened most of the other programs I use (Kdenlive, Thunar, etc.) and haven't encountered this problem, but I think it's because their class is defined from the start.

Edit: I forgot to mention that I think this problem didn't exist a few days ago. I'm not 100% sure, though.

[tuurep]

Hmm, yeah

There's definitely an assumption in the code that WM_CLASSes don't change on the fly

While I didn't exactly see the string "Soffice", could reproduce this:

(with name = "class")

1. open LibreOffice
2. class is libreoffice-startcenter
3. open LibreOffice Writer (or any others)
4. remains libreoffice-startcenter in windowlist, until next update

There's an easy fix, adding within 1 hour

[tuurep]

Alright, could you check whether that's fixed in #39?

[Dupond]

While I didn't exactly see the string "Soffice"

This is because I don't open “LibreOffice”, but launch lowriter directly.

Alright, could you check whether that's fixed in #39?

It seems so! Everything seems to be working perfectly now. Thanks for all the updates: you've been busy the last few days :)

Will adding enough nicknames to [window_nicknames] (a dozen or so) have any impact on performance?

[tuurep]

Well, I can say that the table is looped over for each window in the list:

windowlist/main.c

Lines 216 to 240 in da0587f

	char* get_window_nickname(char* class, char* title) {
	if (!config.window_nicknames) {
	return NULL;
	}
	for (int i = 0; i < toml_table_len(config.window_nicknames); i++) {
	int keylen;
	const char* key = toml_table_key(config.window_nicknames, i, &keylen);
	char* val;
	if (!strcmp(config.name, "title")) {
	if (!strcasecmp(key, title)) {
	val = toml_table_string(config.window_nicknames, key).u.s;
	return val;
	}
	} else {
	if (!strcasecmp(key, class)) {
	val = toml_table_string(config.window_nicknames, key).u.s;
	return val;
	}
	}
	}
	return NULL;
	}

I'd guess the number of nicknames has to be much higher (an impractical number) for that to be slow. But let me know if you suspect problems related to that 😄

If there was like 100.000 window_nicknames, I'd be looking at reimplementing it as a hash map.