Version: unspecified (using KDE 4.4.2) OS: Linux Window Behavior allows to add specific window behavior rules for windows specified by window role and window class. After settings are saved (apply button in KDE Control Module), all text in window role and window class is converted to lower case, and is doesn't match anymore. Reproducible: Always Steps to Reproduce: 1. create new window behavior rule 2. Fill window class and window role using "detect" button. Use only windows with Uppercase role or class, for example, the "Edit Window-Specific settings" window with "Match also window title" checkbox 3. choose any obvious setting, for example "Geometry"->"Maximized"->"Force". 4. Close "Edit Window-Specific settings" 5. Press "Apply" in KDE Control Module 6. Close KDE Control Module 7. Reopen KDE Control Module, and check window-specific rule Actual Results: Expected window class and window role textbox should contain text with upper and lower case text, for example, for "Edit Window-Specific settings" window class should be "kcmshell4 Kcmshell4" (K is capital in Kcmshell4) Expected Results: Instead, window class and window role is lowercase, for example, for "Edit Window-Specific settings" window, window class is "kcmshell4 kcmshell4" (k is lowercase in kcmshell4).
matching of role & class is case insensitive (and works this way here) do you really observe a problem or just noticed the string alteration in the dialog? mismatches usually defer from varying window hints - eg. FF changes it's class with every version :-( try using a weaker regexp (to bypass eg. counting elements like "window_1" or such.
(In reply to comment #1) I've found string alteration only after I noticed that my rules do not apply to some windows, to be specific to Skype and Amarok windows (both have capital letters in role and class). I am aware that some application can change window class with new versions, but this is not the case. I've tried to use lowercase class and role, to use regexp. Both are not matching if letter in pattern is lowercase but letter in class/role is capital. So I am pretty sure that in kde 4.4.2 class/role matching is case sensitive.
the relevant code hasn't changed since then and i can successfully force eg. amarok's mainwindow maximized (also actually most KDE windows have capitalized roles/classes) the rule config is stored in ~/.kde/share/config/kwinrulesrc - if you don't mind for privace reasons (contains all rules you setup) you should attach it for inspection.
I am sorry for misinformation. I've experimented with rules, and found that class/role matching actually works fine, and is case insensitive: When i press "apply" in Window Behavior control panel, actions are applied correctly to all windows. The problem is that not all actions are "forced". This is my kwinrulesrc for skype chat: [5] Description=skype chat clientmachine=t00l clientmachinematch=0 desktop=3 desktoprule=2 maximizevert=true maximizevertrule=2 title= XXX - Skype™ Chat titlematch=0 types=1 windowrole=chats windowrolematch=3 wmclass=skype wmclasscomplete=false wmclassmatch=3 Purpose of this rule is to place skype chat on 3rd desktop, and to force chat window maximized vertically. Window is indeed forced to be on third desktop (i cannot move window to any desktop other than 3rd, which is good). But "force maximized vertically" is only applied when window is created (chat popup) or "apply" button pressed in "Window Behavior". Is that expected behavior of "force maximized vertically" option?
i guess skype initially resizes itself and the onedimensional maximizations don't contrain move/resize of the client. I changed the description in this regard. As a workaround you could force a special geometry (or size)
Git commit 44795854aa522c323e5fa1d9600bb63cb5aac02d by Thomas L��bking. Committed on 08/03/2011 at 21:33. Pushed by luebking into branch 'master'. Unlink maximization state from actual geometry Since clients with restricted geometry now cannot cover the entire screen by default it was necessary to unlink the state from the actual geometry to re-provide the "restore" feature. The patch also extends the protection of the maximized state to unilateral maximizations (emacs issue) BUG: 265568 BUG: 252314 CCBUG: 252255 review request https://git.reviewboard.kde.org/r/100606/ M +0 -1 kwin/client.cpp M +0 -1 kwin/client.h M +13 -44 kwin/geometry.cpp http://commits.kde.org/kde-workspace/44795854aa522c323e5fa1d9600bb63cb5aac02d
the commit is currently in git master - feel free to check whether it fixes your issue (it's just a guess because i don't know what skype's doing over there)
I have KDE 4.6.2 @ Ubuntu 10.10. With Opera the "Window class" isn't case insensitive. When i write "Opera"->"OK"->"Apply" the window moves to the correct desktop. After the next reboot it says "opera" and the window stays where it opens. Now with the Regex rule ".pera" it works.
The window should not be able to drop out of maximization at all, so is this still an issue? regarding comment #8 and the original report: Everything is handled lowercase rules.cpp:113 READ_MATCH_STRING(wmclass, .toLower().toLatin1()); toplevel.cpp:301 resource_class = QByteArray(classHint.res_class).toLower(); => either .toLower() is broken, your configuration is not what it seems to be (classclass match?) or this is a broken downstream (ubuntu?) patch.
just stumbled upon bug #231524 - i start to suspect that skype delays or changes the netwm hint setting, so it doesn't match because it simply doesn't match *at that time*.
pattern thickens, see bug #187539 gonna install skype
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!