Bug 187539

Upon further experimentation, I think the settings are actually saved; they're just not displayed in the dialog.

I can reproduce this bug on svn trunk r1184315.

now i think /this/ could really be a case matter. are the settings stored in "kcmshell4 kwinrules"?

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

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.

Oh, just recall - also check whether it's just bug #264981

Created attachment 64249 [details]
kwinrulesrc from a vanilla install of openSUSE 11.4 + KDE 4.6

Created attachment 64250 [details]
kwinrulesrc after Step 4 of Comment #7

@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.

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

Also, forgot to mention I seeing this behavior using a vanilla KDE 4.7.1 on Arch Linux.

what about comment #6?
have you checked the impact of multiple activities? -> bug #264981

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"?

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.

@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.

@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.

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 .*"

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;

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

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)

Yes, I'm using ext4.  I'll try modifying the code as you suggest and will report back with the results.

Nope, adding cfg.sync(); has no effect.  Where should I try adding the usleep(100000)?  Before or after the cfg.sync()?

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 :\

can you please check whether you actually encounter bug #288586 (ie. the window specif settigns are shown instead)?

Okey, forget it - the title strings are indeed the same ...

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

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

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

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

This issue report is quite old. Can you please confirm, that it still persists with Plasma 5.23?

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.