Bug 348906 - Title matching does not longer work
Summary: Title matching does not longer work
Status: RESOLVED DUPLICATE of bug 220227
Alias: None
Product: kwin
Classification: Plasma
Component: rules (show other bugs)
Version: 5.3.1
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-08 23:36 UTC by Soukyuu
Modified: 2015-06-10 13:21 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
This is the rule that has worked before (247 bytes, text/plain)
2015-06-08 23:36 UTC, Soukyuu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Soukyuu 2015-06-08 23:36:18 UTC
I had a rule that looks for a substring match of the window title ("DeaDBeeF"), because the program does not set the window type and I want to distinguish between normal windows and others.

This worked flawlessly as substring match until recently. Now, deadbeef's window is only correctly affected if I turn the title matching off. Otherwise, the window is ignored as if the match fails.

Reproducible: Always

Steps to Reproduce:
1. match a window by any of the available methods
2. start the program


Actual Results:  
window is not affected by the rule

Expected Results:  
window should have been affected by the rule

I think this has worked on 5.3.0 before, but I can't test it atm. The rule was created by sampling the main application window, so there shouldn't be a typo.
Comment 1 Soukyuu 2015-06-08 23:36:44 UTC
Created attachment 93086 [details]
This is the rule that has worked before
Comment 2 Thomas Lübking 2015-06-09 08:11:35 UTC
It's likely the client (setting the title late) - which program is it?

Does title matching work for "xterm -title Gnarf"
Comment 3 Soukyuu 2015-06-09 20:53:30 UTC
It appears to work for "xterm -title Gnarf" when matching against any substring of "Gnarf", but not for the (runtime-set) "username@hostname:~" title.

The program I noticed this behavior is deadbeef, an audio player.
Comment 4 Thomas Lübking 2015-06-10 06:42:13 UTC
(In reply to Soukyuu from comment #3)
> but not for the (runtime-set) "username@hostname:~" title.

The title isn't tracked (never was) - see bug #220227

> The program I noticed this behavior is deadbeef, an audio player.
I assume it's the same problem (relevant title is set after mapping), but to be sure: gtk2 or gtk3 interface? (and did that perhaps change?)

*** This bug has been marked as a duplicate of bug 220227 ***
Comment 5 Soukyuu 2015-06-10 11:09:21 UTC
Well I'll be damned. Today, the rule works. I haven't changed anything about it. Maybe deadbeef sometimes sets it a bit later (when there is more system load) and kwin ends up missing it because of that?

I'm using the GTK2 backend, never tried GTK3 before.
Comment 6 Thomas Lübking 2015-06-10 13:01:06 UTC
(In reply to Soukyuu from comment #5)
> Maybe deadbeef sometimes sets it a bit later (when there is more system
> load) and kwin ends up missing it because of that?

"Unlikely" - the title is either set before or after the maprequest, the systemload doesn't matter.
Did you start the process or mapped (brought to screen) the window from the systray icon?
Comment 7 Soukyuu 2015-06-10 13:16:29 UTC
Not using the systray, so yes, I started the process normally.
I just tried starting deadbeef while system is under heavy load, and no difference. It works and I have no idea why it suddenly stopped working before - I changed nothing about the system or the kwin rule =/
Comment 8 Thomas Lübking 2015-06-10 13:21:25 UTC
Heisenbug. Happens ;-)