Bug 264981

works for me (tried xterm)- maybe activity related?

@danny
- you're aware that "remember" remembers the setting, ie. it has to be set sticky before closing?
- what applications did you try?

before 4.6 I had this set for pidgin, kontact, and firefox.  None of those work now, but they did work before.  What exactly does sticky mean, I don't see anything named that in the settings?  I just tried xterm with no luck either, even though it shows up in the system settings it doesn't appear when I right click on the title bar again.  Even if I set it in a window and then immediately go look at the setting it isn't set.

Perhaps something has changed here in the functionality, I have no activities I am aware of.

sorry, "sticky" means "on all desktops" - ie. the attribute has to be set when the window closes, otherwise it would not be re-attached.
if you want them to be sticky in all cases, you have to force the setting (or "apply initially"), however the fact that it does not appear on the window (but in the systemsettings) worries me.

please attach dumps* of xprop & xwininfo of the window you apply the rule to (before closing it, check whether the rule's still present) and then of the window you'd expect them to see on.

xprop > old_props.txt
xwininfo > old_info.txt
[close, restart]
xprop > new_props.txt
xwininfo > new_info.txt

also check permissions of the rule config file
stat `kde4-config --path config | cut -d ":" -f1`kwinrulesrc

and maybe watch for possibly conflicting files
ls `kde4-config --path config | cut -d ":" -f1`*kwin*rule*

Created attachment 56711 [details]
xprop right after applying remember on all desktops

Created attachment 56712 [details]
xwininfo right after applying remember on all desktops

Created attachment 56713 [details]
xprop after a close and start again

Created attachment 56714 [details]
xwininfo after a close and restart

stat `kde4-config --path config | cut -d ":" -f1`kwinrulesrc
  File: `/home/da/.kde/share/config/kwinrulesrc'
  Size: 3338            Blocks: 8          IO Block: 4096   regular file
Device: 824h/2084d      Inode: 10946       Links: 1
Access: (0600/-rw-------)  Uid: ( 7558/      da)   Gid: ( 7558/      da)
Access: 2011-01-31 13:18:35.151023282 -0800
Modify: 2011-01-31 13:18:35.151023282 -0800
Change: 2011-01-31 13:18:35.151023282 -0800

ls `kde4-config --path config | cut -d ":" -f1`*kwin*rule* | more
/home/da/.kde/share/config/kwin_rules_dialogrc
/home/da/.kde/share/config/kwinrules_update
/home/da/.kde/share/config/kwinrulesrc

more /home/da/.kde/share/config/kwin_rules_dialogrc
[Notification Messages]
displayhints=false

more /home/da/.kde/share/config/kwinrules_update
[$Version]
update_info=kwin_fsp_workarounds_1.upd:kde351

more /home/da/.kde/share/config/kwinrulesrc
[$Version]
update_info=kubuntu-fix-kwin-default-size.upd:kubuntu-fix-kwin-default-size

[1]
Description=Application settings for firefox
clientmachine=snowflake
clientmachinematch=0
desktop=1
desktoprule=4
types=4294967295
wmclass=navigator firefox
wmclasscomplete=true
wmclassmatch=1
...

Ok, the client is sticky (before the close) and doesn't change any attributes (like wm_class or so) across the restart, but this:
...
desktop=1
...
is wrong wrong:
desktop should be "-1" (all) not "1" - when did you take this?
before or after the restart and how does it look before you close the application?

(the 2^32-1 "types" is ok, means: apply to all window types)

I viewed this after the restart.  It appears this might be the problem though.  It looks like no matter what I set that desktop var to it gets reset to 1 when I restart the app.  Any ideas?

the client get's unsticked while it's closed (is it _always_ one, even if you close the application from eg. desktop 2?)

try to set the rule, then 
chmod -w `kde4-config --path config | cut -d ":" -f1`kwinrulesrc
restart firefox (and watch the sticky state)
chmod +w `kde4-config --path config | cut -d ":" -f1`kwinrulesrc

a) it sure happens with any client and not only (*sigh* and especially) firefox?
b) which decoration do you use? (just a wild shot)

Even though the file doesn't change without write permissions it always goest to Desktop 1.  It happens for every app I have tried.  Pidgin, Firefox, aterm, xterm, Wine, amarok, etc...

I am using QTCurve, but I tried with Oxygen as well.  I have the same results on a different box with a similar setup as well.

On a different note, it appears if I set the param to Force instead of Remember it works, and sticks after the restart.  So it appears Remember is the problem.

"Force" and "Apply Initially" work but "Remember" does not and puts the application in the top left of the screen in a small rectangle with KDE 4.6.3. Seems something is not correct with kdelibs ruleswidget.cpp.

@texstar
Are you actually talking about a "sticky" rule?
Setting sticky to remember causes windows to appear in a tiny rect at 0,0 at your side??

I open an application say Firefox as example. I right click on the title bar and select Advanced -> Special Window Settings. I click on the Geometry. I check position and check size and select Remember for both. I click on OK. I close out Firefox and open it again and Firefox opens in a tiny rectangle in the top left corner of the screen. Pictures linked.

Configuration Screen:
http://i52.tinypic.com/1467p0.jpg

Result:
http://i53.tinypic.com/28u0gif.jpg

If I select Apply Initially or Force in the options, the application opens in the correct place and geometry.

Hope this helps.

kwinrules after setting konsole to remember setting.

[1]
Description=Window settings for konsole
clientmachine=thenudiebar
clientmachinematch=0
position=191,56
positionrule=4
size=811,517
sizerule=4
title=texstar : bash
titlematch=0
types=1
windowrole=mainwindow#1
windowrolematch=1
wmclass=konsole
wmclasscomplete=false
wmclassmatch=1

kwinrules after closing konsole and opening again with konsole now in the top left corner of the screen in a tiny rectangle:

[1]
Description=Window settings for konsole
clientmachine=thenudiebar
clientmachinematch=0
position=0,0
positionrule=4
size=139,100
sizerule=4
title=texstar : bash
titlematch=0
types=1
windowrole=mainwindow#1
windowrolematch=1
wmclass=konsole
wmclasscomplete=false
wmclassmatch=1

The critical moment is after the window closed, but before it's reopened (the rule after starting the application reflects its current state and is thus correct)

Are you using (and maybe alongside a rule)
- window tabbing (tabstrip, aurorae - iirc oxygen has an opt-out checkbox)
- window tiling
- multiple activities

That is it! Multiple Activities. I had two listed (odd). I removed one and remember started working.

yupp, can confirm. adding a 2nd activity breaks it here as well.

fix is to prevent Client::updateActivities() call Client::updateWindowRules() during Client::manage()

@chani
why does "updateActivities();" have to "updateWindowRules();" at all?

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

Git commit b08fa7d0b5e53cec2950c3f0f3e2fc88a40c0ba8 by Thomas Lübking.
Committed on 14/11/2011 at 12:46.
Pushed by luebking into branch 'master'.

don't ::updateRules() in ::updateActivities()

breaks remember rules when called by ::setActivity() in ::manage()
TODO: add activity rules and make remember state applying more robust in 4.9

BUG: 264981

M  +1    -1    kwin/client.cpp

http://commits.kde.org/kde-workspace/b08fa7d0b5e53cec2950c3f0f3e2fc88a40c0ba8

Git commit 4ea7eadcd6c1666e5a3315a156588da1bca2d1a6 by Thomas Lübking.
Committed on 14/11/2011 at 12:46.
Pushed by luebking into branch 'KDE/4.7'.

don't ::updateRules() in ::updateActivities()

breaks remember rules when called by ::setActivity() in ::manage()
TODO: add activity rules and make remember state applying more robust in 4.9

BUG: 264981
FIXED-IN: 4.7.4
(cherry picked from commit b08fa7d0b5e53cec2950c3f0f3e2fc88a40c0ba8)

M  +1    -1    kwin/client.cpp

http://commits.kde.org/kde-workspace/4ea7eadcd6c1666e5a3315a156588da1bca2d1a6

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