Bug 301909 - "No titlebar and frame = Force Yes" does not work
Summary: "No titlebar and frame = Force Yes" does not work
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.7.4
Platform: Debian testing Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-14 16:08 UTC by Enda
Modified: 2013-01-17 16:02 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
thomas.luebking: ReviewRequest+


Attachments
backtrace (5.92 KB, text/plain)
2012-07-05 15:30 UTC, Enda
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Enda 2012-06-14 16:08:00 UTC
KDE -> System Settings -> Window Behaviour -> Window Rules
New -> 'Application settings for okular'
Appearance & Fixes -> No titlebar and frame = Force Yes

This works fine when the 'Text position' in 'Toolbar Settings' is
'Text Only' or 'Text Alongside Icons', but does not work when 'Icons
Only' or 'Text Under Icons'.

Reproducible: Always
Comment 1 Albert Astals Cid 2012-06-16 16:21:57 UTC
Kwin guys, is this something kwin does?
Comment 2 Thomas Lübking 2012-06-16 16:28:39 UTC
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)
Comment 3 Enda 2012-06-22 15:16:59 UTC
(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.
Comment 4 Thomas Lübking 2012-06-22 16:51:49 UTC
(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)
Comment 5 Enda 2012-06-27 17:05:17 UTC
The problem still occurs for:
Okular Version 0.13.3
Using KDE Development Platform 4.8.3
Comment 6 Thomas Lübking 2012-06-27 17:55:27 UTC
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?
Comment 7 Enda 2012-06-29 20:12:49 UTC
(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.
Comment 8 Thomas Lübking 2012-06-29 20:39:50 UTC
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
Comment 9 Enda 2012-07-04 15:38:45 UTC
(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
Comment 10 Thomas Lübking 2012-07-04 19:17:56 UTC
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?
Comment 11 Enda 2012-07-04 19:32:12 UTC
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
Comment 12 Thomas Lübking 2012-07-04 20:22:53 UTC
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.
Comment 13 Enda 2012-07-04 20:35:46 UTC
(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.)
Comment 14 Thomas Lübking 2012-07-04 20:54:39 UTC
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?
Comment 15 Enda 2012-07-05 15:29:58 UTC
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.
Comment 16 Enda 2012-07-05 15:30:37 UTC
Created attachment 72334 [details]
backtrace
Comment 17 Thomas Lübking 2012-07-05 17:33:41 UTC
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.
Comment 18 Enda 2012-07-05 17:36:32 UTC
(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.
Comment 19 Hugo Pereira Da Costa 2012-07-05 17:49:55 UTC
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.
Comment 20 Thomas Lübking 2012-07-08 20:36:29 UTC
https://git.reviewboard.kde.org/r/105485/
I don't know whether this is the cause, though
Comment 21 Thomas Lübking 2012-07-09 22:49:24 UTC
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
Comment 22 Thomas Lübking 2012-07-09 23:10:07 UTC
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
Comment 23 Martin Flöser 2013-01-17 16:02:51 UTC
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.