Bug 187539 - Special Application Settings not remembered
Summary: Special Application Settings not remembered
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: rules (show other bugs)
Version: unspecified
Platform: openSUSE Unspecified
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 162773 197240 213672 293624 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-03-18 19:01 UTC by Tristan Miller
Modified: 2021-11-08 09:51 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
kwinrulesrc from a vanilla install of openSUSE 11.4 + KDE 4.6 (180 bytes, application/octet-stream)
2011-10-05 16:20 UTC, Tristan Miller
Details
kwinrulesrc after Step 4 of Comment #7 (702 bytes, application/octet-stream)
2011-10-05 16:20 UTC, Tristan Miller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tristan Miller 2009-03-18 19:01:08 UTC
Version:            (using KDE 4.2.1)
Installed from:    SuSE RPMs

Reproducibility: Always with some applications; never with others.  It seems to happen reliably with Skype and Ktorrent, but not with SeaMonkey.

Steps to reproduce:
1. Right-click on the title bar of a window
2. Advanced->Special Application Settings…
3. Check a checkbox for a geometry setting (e.g., Minimised) and select something other than "Do Not Affect" in its associated drop-down box (e.g., "Apply Initially".  Check the associated right-hand check-box.
4. OK
5. Right-click on the title bar of a window
6. Advanced->Special Application Settings…

Observed behaviour:
7. The changes we just made are gone.

Expected behaviour:
7. The changes we made should have been persistent.
Comment 1 Tristan Miller 2009-03-18 19:07:23 UTC
Upon further experimentation, I think the settings are actually saved; they're just not displayed in the dialog.
Comment 2 Michael Leupold 2010-10-10 18:47:53 UTC
I can reproduce this bug on svn trunk r1184315.
Comment 3 Thomas Lübking 2010-10-10 21:35:56 UTC
now i think /this/ could really be a case matter. are the settings stored in "kcmshell4 kwinrules"?
Comment 4 tekstr1der 2011-10-05 14:51:01 UTC
Has there been any progress on this?

I am still seeing the same bug - special application settings not saved in KDE 4.7.1

I would really like to hide the title bar in Firefox and have the setting retained
Comment 5 Thomas Lübking 2011-10-05 15:39:57 UTC
What progress? The bug doesn't exist here and never has... *shrug*

I'd say that it's either a downstream or local (ie. permission/path) issue - i've just tried and in particular remembering the titlebar state of FF does work here (notice that you can btw. also attach a shortcut to this, not the best workaround, but better than the alt+f3 menu ;-)

SO, i'm sorry. I do believe that the issue is real for you but since it's not reproducable at all and never has been the slightest, we can only provide support - but investigation oin why it fails has to happen on your system and requires as much information sharing from you as any possible.

Therefore and for the beginning, the unanswered question (and som more) remain:
- after you've added such special application rule, is there an entry for it in "kcmshell4 kwinrules" (all rules list)
- check permissions on ~/.kde/share/config/kwinrulesrc and/or pot. ~/.kde4/share/config/kwinrulesrc
- attach those files before adding the rule, after adding and after re-openinng the dialog
- does it only fails across sessions, but eg. restarting FF w/o restarting kwin first works.
Comment 6 Thomas Lübking 2011-10-05 15:43:19 UTC
Oh, just recall - also check whether it's just bug #264981
Comment 7 Tristan Miller 2011-10-05 16:20:19 UTC
Created attachment 64249 [details]
kwinrulesrc from a vanilla install of openSUSE 11.4 + KDE 4.6
Comment 8 Tristan Miller 2011-10-05 16:20:59 UTC
Created attachment 64250 [details]
kwinrulesrc after Step 4 of Comment #7
Comment 9 Tristan Miller 2011-10-05 16:21:16 UTC
@Thomas, please accept my apologies for having overlooked your question in Comment #3.  When I first read it, I thought you were merely musing; I didn't understand that it was a troubleshooting step you wanted me to try.

The problem is still reproducible for me; I'm now using KDE 4.6.0 on openSUSE 11.4.

I've carried out the tests you suggest in Comment #5.

The attached file kwinrulesrc is from before making any custom application settings.  It's from a fresh install of KDE 4.6 on openSUSE 11.4.  Starting from here, I went through the same steps as in my original report:

0. Open KTorrent
1. Right-click on the title bar
2. Advanced->Special Application Settings…
3. Check the checkbox for the "Minimized" geometry setting, select "Apply Initially" from the drop-down box, and check the associated right-hand checkbox.
4. OK
5. Right-click on the title bar of a window
6. Advanced->Special Application Settings…

The attached file kwinrulesrc_4 is the kwinrulesrc file as it appears immediately after Step 4.  As you can see, the settings appear to have been properly saved here.

However, in the dialog that appears after Step 6, none of those custom settings are present.  The dialog looks exactly as it did after Step 2.

The contents of kwinrulesrc does not change again after Step 4.

When I run kcmshell4 kwinrules, there is an entry "Application settings for ktorrent".  If I select it and press the "Modify" button, then a dialog appears, and the Geometry tab shows the custom settings correctly.
Comment 10 tekstr1der 2011-10-05 16:49:34 UTC
I can replicate and confirm the exact steps and results posted by Tristan in Comment #9.

kwinrulesrc is indeed populated with what appear to be correct parameters, but upon re-launching of the settings gui none of the settings are retained, nor are they applied to the applications in question.

As a workaround, to accomplish my specific needs of removing an application titlebar, I've been able to successfully apply the setting via:

System Settings > Workspace Appearance > Configure Decoration > Window-Specific Overrides > +Add

Matching window property: "Window Title"
Regular expression to match: "Mozilla Firefox"
[x] Hide window title bar
Comment 11 tekstr1der 2011-10-05 18:14:09 UTC
Also, forgot to mention I seeing this behavior using a vanilla KDE 4.7.1 on Arch Linux.
Comment 12 Thomas Lübking 2011-10-05 18:15:10 UTC
what about comment #6?
have you checked the impact of multiple activities? -> bug #264981
Comment 13 tekstr1der 2011-10-05 18:18:27 UTC
I read through bug #264981 and deleted all but the current Desktop activity. I don't use activities for anything.

Am I understanding this correctly, or is another step necessary to rule out "multiple activities"?
Comment 14 Tristan Miller 2011-10-05 18:28:16 UTC
I have no idea what an activity is.  The desktop's context menu has an "Activites…" command that brings up some panel-like widget which is empty except for a search box, a "New Activity" icon, a "Create Activity" button, and an "Add Widgets" button.  I guess this means I don't have multiple activities, whatever they might be.

Also, I forgot to mention (also in response to Comment #5) that my kwinrulesrc has adequate read and write permissions.
Comment 15 Thomas Lübking 2011-10-05 19:03:19 UTC
@tekstr1der
you'll probably have to restart kwin afterwards and retry applying that rule (don't know about activities myself)

@Tristan
Since activities never seemed an issue on your side, try altering the rule to
wmclassmatch=2
(substring match)

and also please post "xprop | grep CLASS" (the cursor becomes a cross, click the ktorrent window)

I've currently no other idea what could fail (i've installed ktorrent and tested the minimized remember rule - works ...)
Can you compile from sources and inject some debug output?

---

In doubt, shutdown "kquitapp plasma-desktop" to get rid of activities.
Comment 16 Tristan Miller 2011-10-05 19:25:34 UTC
@Thomas, the output of xprop|grep CLASS both before and after making the alteration to kwinrulesrc you suggested is as follows:
WM_CLASS(STRING) = "ktorrent", "Ktorrent"

Changing to wmclassmatch=2 has no effect on the bug.

I can compile from sources if you point me to some instructions.  (I know how to build software, but have never compiled anything from KDE before; I wouldn't know where to get the source code and how to configure the build for debugging output.)  Googling turns up <http://techbase.kde.org/Getting_Started/Build> which claims it is out of date.
Comment 17 Tristan Miller 2011-10-11 12:19:44 UTC
I compiled kwin from sources, injecting the line

qDebug() << "RULES SUCK" << wmclassmatch << match_class << match_name << wmclass;

at the beginning of Rules::matchWMClass.

I then ran kwin with the default kwinrulesrc from openSUSE 11.4 (see attachment).  Here is the output, with my annotations as to what's happening:

$ kwin --replace
RULES SUCK 3 "plasma" "plasma" "^xv .*" 
RULES SUCK 3 "konsole" "konsole" "^xv .*" 
RULES SUCK 3 "plasma" "plasma" "^xv .*" 
RULES SUCK 3 "ktorrent" "ktorrent" "^xv .*" 
// At this point I do Steps 1 to 4 of the original bug report, then
// quit and reload ktorrent:
RULES SUCK 3 "kwin_rules_dialog" "kwin_rules_dialog" "^xv .*" 
RULES SUCK 1 "konsole" "konsole" "ktorrent" 
RULES SUCK 3 "konsole" "konsole" "^xv .*" 
RULES SUCK 1 "plasma" "plasma" "ktorrent" 
RULES SUCK 3 "plasma" "plasma" "^xv .*" 
RULES SUCK 1 "ktorrent" "ktorrent" "ktorrent" 
RULES SUCK 3 "ktorrent" "ktorrent" "^xv .*" 
RULES SUCK 1 "ktorrent" "ktorrent" "ktorrent" 
RULES SUCK 3 "ktorrent" "ktorrent" "^xv .*"
Comment 18 Thomas Lübking 2011-10-11 19:03:05 UTC
looks fine, the rule is there and tested. properties are ok.

-> please debug wmclasscomplete or cwmclass - sorry for the workload.

qDebug() << "RULES DO NOT SUCK" << wmclassmatch << match_class << match_name << cwmclass << "," << wmclass << wmclasscomplete;
Comment 19 Tristan Miller 2011-10-18 21:08:46 UTC
OK, here are the results with my annotations:

$ kwin --replace
// First I load ktorrent
RULES DO NOT SUCK 3 "plasma" "plasma" "plasma plasma" , "^xv .*" true
RULES DO NOT SUCK 3 "konsole" "konsole" "konsole konsole" , "^xv .*" true
RULES DO NOT SUCK 3 "plasma" "plasma" "plasma plasma" , "^xv .*" true
RULES DO NOT SUCK 3 "plasma-desktop" "plasma-desktop" "plasma-desktop plasma-desktop" , "^xv .*" true
RULES DO NOT SUCK 3 "ktorrent" "ktorrent" "ktorrent ktorrent" , "^xv .*" true

// Now I do Steps 1–4 of the original bug report
RULES DO NOT SUCK 3 "kwin_rules_dialog" "kwin_rules_dialog" "kwin_rules_dialog kwin_rules_dialog" , "^xv .*" true 
RULES DO NOT SUCK 1 "konsole" "konsole" "konsole" , "ktorrent" false 
RULES DO NOT SUCK 3 "konsole" "konsole" "konsole konsole" , "^xv .*" true 
RULES DO NOT SUCK 1 "plasma" "plasma" "plasma" , "ktorrent" false 
RULES DO NOT SUCK 3 "plasma" "plasma" "plasma plasma" , "^xv .*" true 
RULES DO NOT SUCK 1 "ktorrent" "ktorrent" "ktorrent" , "ktorrent" false 
RULES DO NOT SUCK 3 "ktorrent" "ktorrent" "ktorrent ktorrent" , "^xv .*" true 

//Now I quit and restart ktorrent 
RULES DO NOT SUCK 1 "plasma-desktop" "plasma-desktop" "plasma-desktop" , "ktorrent" false 
RULES DO NOT SUCK 3 "plasma-desktop" "plasma-desktop" "plasma-desktop plasma-desktop" , "^xv .*" true 
RULES DO NOT SUCK 1 "ktorrent" "ktorrent" "ktorrent" , "ktorrent" false 
RULES DO NOT SUCK 3 "ktorrent" "ktorrent" "ktorrent ktorrent" , "^xv .*" true 

// Now I do Steps 5 and 6 of the original bug report
RULES DO NOT SUCK 1 "kwin_rules_dialog" "kwin_rules_dialog" "kwin_rules_dialog" , "ktorrent" false 
RULES DO NOT SUCK 3 "kwin_rules_dialog" "kwin_rules_dialog" "kwin_rules_dialog kwin_rules_dialog" , "^xv .*" true 

//Now I click OK and quit ktorrent 
RULES DO NOT SUCK 1 "konsole" "konsole" "konsole" , "ktorrent" false 
RULES DO NOT SUCK 3 "konsole" "konsole" "konsole konsole" , "^xv .*" true 
RULES DO NOT SUCK 1 "plasma" "plasma" "plasma" , "ktorrent" false 
RULES DO NOT SUCK 3 "plasma" "plasma" "plasma plasma" , "^xv .*" true 
RULES DO NOT SUCK 1 "ktorrent" "ktorrent" "ktorrent" , "ktorrent" false 
RULES DO NOT SUCK 3 "ktorrent" "ktorrent" "ktorrent ktorrent" , "^xv .*" true
Comment 20 Thomas Lübking 2011-11-13 18:26:37 UTC
Sorry for the delay.

Apparently triggering the dialog kill the rules and i've a (i think pretty good) idea why.
You're probably on an Ext4 or btrfs filesystem, are you?

I guess rules.cpp, Workspace::writeWindowRules() desperatly lacks a cfg.sync() for that purpose.

Can you compile kwin and test that (just add "cfg.sync();" right before the closing bracket of that function, is around line 962 in current git master)
In very doubt, add a nice little "usleep(100000);" (will add 100ms delay, you might raise that value, but it will block the window manager - including the compositor - and actually the sync _should_ be sufficient)
Comment 21 Tristan Miller 2011-11-13 19:09:21 UTC
Yes, I'm using ext4.  I'll try modifying the code as you suggest and will report back with the results.
Comment 22 Tristan Miller 2011-11-17 20:49:02 UTC
Nope, adding cfg.sync(); has no effect.  Where should I try adding the usleep(100000)?  Before or after the cfg.sync()?
Comment 23 Thomas Lübking 2011-11-17 21:25:34 UTC
blasted.
"after", but it's likely not gonna help (you could do 1000000 as well, that will block for a second)

*sigh* - nevertheless, it's worth a shot ... esp. since i'm otherwise out of ideas ... for the moment :\
Comment 24 Thomas Lübking 2011-12-09 19:20:47 UTC
can you please check whether you actually encounter bug #288586 (ie. the window specif settigns are shown instead)?
Comment 25 Thomas Lübking 2011-12-09 19:40:06 UTC
Okey, forget it - the title strings are indeed the same ...
Comment 26 Thomas Lübking 2012-02-08 18:07:58 UTC
*** Bug 293624 has been marked as a duplicate of this bug. ***
Comment 27 Thomas Lübking 2012-03-11 05:43:45 UTC
*** Bug 197240 has been marked as a duplicate of this bug. ***
Comment 28 Thomas Lübking 2012-03-11 05:53:54 UTC
*** Bug 162773 has been marked as a duplicate of this bug. ***
Comment 29 Thomas Lübking 2013-03-23 20:12:43 UTC
*** Bug 213672 has been marked as a duplicate of this bug. ***
Comment 30 kde.org 2021-11-07 11:03:39 UTC
This issue report is quite old. Can you please confirm, that it still persists with Plasma 5.23?
Comment 31 Tristan Miller 2021-11-08 09:51:42 UTC
No longer reproducible for me with Plasma 5.22.5.  I followed the steps in my Comment 9 (modulo some changes to the UI in the last ten years) and the settings now persist as expected.

I'm tentatively marking this issue as RESOLVED/WORKSFORME but of course if anyone else can still reproduce this, the bug should probably be reopened.