*** Bug 207670 has been marked as a duplicate of this bug. ***

*** Bug 303185 has been marked as a duplicate of this bug. ***

*** Bug 329045 has been marked as a duplicate of this bug. ***

@Martin
I'm kinda willing to bump this to "bug" (at least in the title aspect)

Reason is that users keep running into it (also see stupid skype issues for that...)
When rules were introduced for KDE2, titles mostly kept static - but that's looong ago.

Technically that's not gonna be trivial :-(

What would be required would be some sort of "weak match", so that we won't have to search rules whenever a caption changes (what can happen pretty often, eg. when there's a counter in it, like amaroks playback or k3b burning process etc. etc.) but only of such window that in general (class, type) matches a rule with a non-ignored title match.

I've no worries about writing that, but i worry about the patch size which could turn it "KF/5 P-W/2 only" material?
It would at least require to add a "bool m_trackTitleChanges" to Client which is controlled by the rulebook...

Thoughts? Should I waste a Sunday on it? ;-)

> I'm kinda willing to bump this to "bug" (at least in the title aspect)
+1
> What would be required would be some sort of "weak match", so that we won't
> have to search rules whenever a caption changes (what can happen pretty
> often, eg. when there's a counter in it, like amaroks playback or k3b
> burning process etc. etc.) but only of such window that in general (class,
> type) matches a rule with a non-ignored title match.
> 
> I've no worries about writing that, but i worry about the patch size which
> could turn it "KF/5 P-W/2 only" material?
> It would at least require to add a "bool m_trackTitleChanges" to Client
> which is controlled by the rulebook...
> 
> Thoughts? Should I waste a Sunday on it? ;-)
Sounds like master material. Just thinking about it, it might be an idea to 
keep the title related window rules in an own "sub-rulebook", so that we only 
have to search those.

I don't really like the thought of re-evaluation the rules whenever the window 
title changes as there are windows which have an extremely nasty window title 
behavior (*cough*browsers*cough*).

Note: if you waste a Sunday on it, I might not be able to review before Friday 
due to Christmas induced no-computer time

Has development interest on this died?  User interest is still strong.  
I think Martin's idea of a sub-rulebook is a good one.
I'm not sure I understand the "weak match" concept, and perhaps this is what you're saying, but when it comes to browsers, I believe you only need to evaluate titles 1) on window creation and 2) if there is a change in the leading part (domain) of the URI.  Since amarok apparently is in it's own class, that would be an exception to re-evaluating titles.  Maybe create a new class for programs like amarok that are exceptions.

However obviously you know better than I do, what is required.  I just want to not have to keep reattaching tabs every time something crashes - which is frequently in KDE.  

I moved off everpad to notenix and now to libreoffice.  Everpad destroyed my notes, notenix has bugs with "stacks" or sub-notebooks and is a resource hog (java), and libreoffice crashes every 5 minutes; literally so I guess I'll be installing OpenOffice when I get a chance.  I've also traded sflphone in for jitsi because of delayed audio issues, which is likely not important to you, but I figure it can't hurt to mention it.

Thank you

> Sounds like master material.
-> not gonna happen in KDE SC4

On Wednesday 19 March 2014 16:37:43 you wrote:
> https://bugs.kde.org/show_bug.cgi?id=220227
> 
> --- Comment #7 from Thomas Lübking <thomas.luebking@gmail.com> ---
> 
> > Sounds like master material.
> 
> -> not gonna happen in KDE SC4

Also not going to happen for 5.0 where we are officially already in feature 
freeze.

*** Bug 348906 has been marked as a duplicate of this bug. ***

Git commit b2755bcaa70027e9f9d14e2ddf221e3fd9df139f by Thomas Lübking.
Committed on 29/10/2015 at 22:36.
Pushed by luebking into branch 'master'.

re-evaluate rules on title change

If a rule minus the title match matches,
the captionChanged signal is bound to re-evaluate
the rules for that client, ie. the tracking overhead
only exists for those clients where title matching
is relevant and costs rematching all rules when such
client changes its title (yes, the partial matching
rules could be stored for faster re-check, but that
would make the patch bigger and is probably not worth
it; just some string comparisms)

additional tracking of wm_class or wm_role
(what is iirc a netwm violation anyway) would require
to monitor the resp. property for changes (not done atm.)
FIXED-IN: 5.5
REVIEW: 125427

M  +6    -0    client.cpp
M  +1    -0    client.h
M  +8    -2    rules.cpp

http://commits.kde.org/kwin/b2755bcaa70027e9f9d14e2ddf221e3fd9df139f