Open
Bug 158226
Opened 22 years ago
Updated 2 years ago
kicker (kde toolbar) does not disappear in fullscreen
Categories
(Core :: XUL, defect)
Tracking
()
NEW
People
(Reporter: npietran, Unassigned)
Details
When entering fullscreen mode in KDE on linux, Kicker (the kde toolbar) does not
disappear.
Steps to reproduce:
When running KDE, press F11 when browser window is open.
Kicker will still be present.
(screenshot in bug #126685)
On Linux, F11 has been a non-op by default for a long time now.
Which build are you testing with?
Also: Have you configured kicker to allow other applications to be on top?
ahh.. i missed the checkin for bug 126685 at 17:43 today.
Comment 4•22 years ago
|
||
We don't attempt to compensate for always-on-top windows at all currently. Is
kicker configured as one?
Comment 5•22 years ago
|
||
yup, it IS always on top (as you can define for every window on KDE)
so wontfix?
not sure about KDE. But i notice that the fullscreen also conflicts with the
Gnome default panel (at top of desktop). All moz navigational features are thus
hidden behind it when in fullscreen. The default Gnome menu panel can NOT be
told to stay in background. (All other panels can though.)
Testing on RH7.3 and Gnome2, but I believe the top panel was default also in
Gnome 1.4
Reporter | ||
Comment 7•22 years ago
|
||
I know that both Konqueror and Konsole have full screen implementations that are
not covered by kicker. I'm not fluent enought in QT to decipher the code though
:( I don't know how those applications operate under other window managers
either.... Can anyone test?
Comment 8•22 years ago
|
||
R.K.Aa:
yes, the top panal was also there in GNOME 1.4, but many people had it disabled
(there was a bottom panel)
Comment 9•22 years ago
|
||
We may be able to tweak the z-index of the mozilla window. I'll look into it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 10•22 years ago
|
||
Not exactly related; my build of moz trunk with patches for fullscreen on Linux
loses focus in KDE3.
i.e. pressing F11; causes Moz window to become fullscreen (bar kicker area),
except that KDE focus jumps to another maximised window
Comment 11•22 years ago
|
||
Vaguely related and minor: in some KDE themes (namely MacOS X look and feel) you
get a menu on top of the desktop. This menu is always on top and I have never
found out how to configure it for autohide or sthg similar. It is not very
annoying as it takes extremely little space. The problem is that it covers half
of mozilla's toolbar while in full screen mode.
Moreover Konqueror and Konsole have the same problem. Menu bar stays on top. Not
acrobat reader 5 though (which does not hide neither kicker nor top menu for me,
but once autohide for kicker is on the menu disappears as well). This means that
this is doable for non KDE applications.
Another thing is that when you force mozilla to maximize while in fullscreen
mode (manually from kicker popup menu) then it neatly alignes under the menu so
there is no overlapping. I though that asking the window manager for the size
would be nice (instead of using the screen size), but then I realized it would
cause heaps of problems with other setups, where menus take lots of space on
sides or top. SO better not.
Just a drop of thouths to the topic.
Comment 12•22 years ago
|
||
Fullscreen windows should set a wm property to be above the panels. Other
fullscreen applications set:
_WIN_LAYER(CARDINAL) = 10
and if we look at /usr/include/gnome-1.0/libgnomeui/gnome-winhints.h we see this
enum that tells what the 10 stands for:
typedef enum
{
WIN_LAYER_DESKTOP = 0,
WIN_LAYER_BELOW = 2,
WIN_LAYER_NORMAL = 4,
WIN_LAYER_ONTOP = 6,
WIN_LAYER_DOCK = 8,
WIN_LAYER_ABOVE_DOCK = 10
} GnomeWinLayer;
However I think this is the "old" way to do it one should probably also do what
the http://www.freedesktop.org/standards/wm-spec/x225.html says. I guess there
is no harm doing both so it works with old and new window managers.
The freedesktop standard says that the set of atoms in _NET_WM_STATE should
contain the atom _NET_WM_STATE_FULLSCREEN. I don't know which wm's that support
this but I would guess at least metacity. The _WIN_LAYER I think is supported by
most.
Comment 13•21 years ago
|
||
suite still gets this wrong, Firebird appears to be getting it right
Updated•18 years ago
|
Assignee: bryner → jag
QA Contact: jrgmorrison → xptoolkit.widgets
Updated•16 years ago
|
Assignee: jag → nobody
Updated•2 years ago
|
Severity: minor → S4
You need to log in
before you can comment on or make changes to this bug.
Description
•