Bug 301909

Kwin guys, is this something kwin does?

Yesno, most important question:
-> which KDE version do you use?

Next question:
it's only broken on startup, but if you apply that rule to the running application the titlebar is withdrawn regardless of the icon style?

Also it's likely not limited to Okular but more or less all KDE applications with toolbars?

It works fine here but there were issues around the motif hint for the titlebar (which were and likely still are for some reason altered with changes to the toolbar, don't ask me) but i think we resolved that for some 4.8 version (and the bug is not reproducible here)

(In reply to comment #2)
> Yesno, most important question:
> -> which KDE version do you use?

4.7.4

> Next question:
> it's only broken on startup, but if you apply that rule to the running
> application the titlebar is withdrawn regardless of the icon style?

Applying 'Icons Only' or 'Text Under Icons' shows the titlebar.

(In reply to comment #3)
> (In reply to comment #2)
> > Yesno, most important question:
> > -> which KDE version do you use?
> 
> 4.7.4
Please try a somewhat recent version than, it's very likely fixed.

> > Next question:
> > it's only broken on startup, but if you apply that rule to the running
> > application the titlebar is withdrawn regardless of the icon style?
> 
> Applying 'Icons Only' or 'Text Under Icons' shows the titlebar.
That's not what i asked. The issue was that the toolbar eventually causes an alteration of that motif hint and kwin just respected that, therefore it's likely that -in this case- you could alter the state anytime for applications that are already there, ie. forcing the state for a running application works but it's "broken" next time you start the application/window.

The toolbar setting should not matter in this case (resp. only be relevant for the two mentioned modes since they seem to trigger the update of the motif hint)

The problem still occurs for:
Okular Version 0.13.3
Using KDE Development Platform 4.8.3

can you please answer:

> it's only broken on startup, but if you apply that rule to the running application the 
> titlebar is withdrawn regardless of the icon style?

(In reply to comment #6)
> it's only broken on startup, but if you apply that rule to the running application, is the 
> titlebar withdrawn regardless of the icon style?

Yes.

Ok, that's bug #291312 but should be /really/ fixed in 4.8 and i can't reproduce it anymore either.

Do you apply any other rules to it (geometry or stuff) - ideally attach ~/.kde/share/config/kwinrulesrc

(In reply to comment #8)
> Do you apply any other rules to it (geometry or stuff) - ideally attach
> ~/.kde/share/config/kwinrulesrc

No

~/.kde/share/config/kwinrulesrc

[1]
Description=Application settings for okular
clientmachine=debian
clientmachinematch=0
noborder=true
noborderrule=2
wmclass=okular
wmclasscomplete=false
wmclassmatch=1

[General]
count=1

Last question ("dumb one" since i'm out of ideas, no offense intended)

You're also running KWin from KDE 4.8 ie. updated kde-workspace as well and logged out/in (resp. at least restarted kwin) since the bug is neither covered/fixed by kdelibs nor okular but the contradiction of rule and application wish was rebalanced in kwin.

If the answer is yes, here's the first question on the next level:
can you patch and recompile kwin to inspect what's going on there?

I am running Debian Testing. I wouldn't know how to patch and recompile kwin.


P.S.

When I press Save Changes in bugs.kde.org, I am redirected to another webpage, for instance: https://bugs.kde.org/show_bug.cgi?id=292574

Can you please try changing UI style and window decoration?
(kcmshell4 style, kcmshell4 kwindecoration)

I can probably see another reason why a window could get a border despite the focus (but can't reproduce)
Also this makes it very important to ensure that this does not only happen to okular only.

Thanks.

(In reply to comment #12)
> Can you please try changing UI style and window decoration?
> (kcmshell4 style, kcmshell4 kwindecoration)

I don't exactly know what (kcmshell4 style, kcmshell4 kwindecoration) means, but I changed the icons to a few other themes before in 'Settings', and it had the same effect.

(Also, pressing CTRL+F also shows the titlebar when it was hidden.)

commands for konsole/krunner
kcmshell4 is the k-control-module-shell - it can directly load parts of systemsettings, so if you type
kcmshell4 style
into konsole a dialog shows up and lets you alter the UI style
kcmshell4 kwindecoration
does the same for the titlebar theme

the icon theme is irrelevant (just pixmaps)

ctrl+f is "find" on your side?

Okular Version 0.14.3
Using KDE Development Platform 4.8.3

(In reply to comment #14)
> commands for konsole/krunner
> kcmshell4 is the k-control-module-shell - it can directly load parts of
> systemsettings, so if you type
> kcmshell4 style
> into konsole a dialog shows up and lets you alter the UI style
> kcmshell4 kwindecoration
> does the same for the titlebar theme

thanks

> the icon theme is irrelevant (just pixmaps)
> 
> ctrl+f is "find" on your side?

Yes.

>

When changing window decoration, I discovered the following which could be relevant:

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

When I click 'Add' in the 'Window-Specific Overrides' dialog, it (always) crashes.

Created attachment 72334 [details]
backtrace

The crash happens in some unknown function in the oxygen deco config dialog - it's for sure not related to this issue. Do you have installed oxygen(-transparent) from some external repo?

@Hugo, please have a short look at the backtrace whether this is sth. known or to worry about.

(In reply to comment #17)
> The crash happens in some unknown function in the oxygen deco config dialog
> - it's for sure not related to this issue. Do you have installed
> oxygen(-transparent) from some external repo?

No.

concerning the backtrace, you need debug symbols can't make anything of 
"?? () from /usr/lib/kde4/kwin_oxygen_config.so"

If this is oxygen, this should not happen (and I can't reproduce)
I wonder if you would have some library vs plugin inconsistency (but that requires that you did configure and compile some kde / oxygen stuff around)

Also, I quite think this is totally unrelated to the original (windows rules) bug.

https://git.reviewboard.kde.org/r/105485/
I don't know whether this is the cause, though

Git commit 61b27a48005bde6afac08fedecf54147fde643a1 by Thomas Lübking.
Committed on 08/07/2012 at 22:29.
Pushed by luebking into branch 'KDE/4.9'.

honor rule when updating deco presence for reshape
REVIEW: 105485

M  +2    -2    kwin/client.cpp

http://commits.kde.org/kde-workspace/61b27a48005bde6afac08fedecf54147fde643a1

Git commit ef28257181451b28090908301459eb7a3a344a46 by Thomas Lübking.
Committed on 08/07/2012 at 22:29.
Pushed by luebking into branch 'master'.

honor rule when updating deco presence for reshape
REVIEW: 105485

M  +2    -2    kwin/client.cpp

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

As you are using Debian testing: it will take some time till 4.9 (or more likely 4.10/4.11) hits the repositories. So you are unable to test whether it fixed it.

I assume that the commit fixed the issue. If it is still reproducable once you have 4.9 or later on your system, please reopen the bug report and we look into it again.