Re: [xine-devel] xine-ui-cvs: sub menus of context menu do not show up in full screen mode

[Carsten H. (T. R. <ra...@ra...>]

On Sun, 31 Dec 2006 21:55:38 +0100 Hans-Dieter Kosch <hd...@t-...=
>
babbled:

> Hi Carsten,
>=20
> Carsten Haitzler (The Rasterman) wrote:
> > On Fri, 29 Dec 2006 02:34:37 +0100 Hans-Dieter Kosch <hdkosch@t-onlin=
e.de>
> > babbled:
> >=20
> >=20
> >>Hi,
> >>
> >>Reinhard Nissl wrote:
> >>
> >>>Hi,
> >>>
> >>>I've got this report from a vdr-xine user. He also reports that sub
> >>>menus work with xine-lib-1.1.3 and xine-ui-0.99.4, but I haven't che=
cked
> >>>that yet.
> >>>
> >>>The problem can be reproduced in window mode too, if the UI option
> >>>"always_layer_above" is set. To get the same effect as in full scree=
n
> >>>mode, one must open the context menu at a position so that the sub m=
enu
> >>>is completely within the area of the output window. Otherwise the su=
b
> >>>menu will be partially visible outside the output window.
> >>>
> >>>BTW: to see this effect after changing "always_layer_above" one may =
need
> >>>to restart xine-ui or switch to full screen mode and back again.
> >>>
> >>
> >>What window manager? Has he checked out current xine-ui CVS? Such a=20
> >>problem was introduced under Kwin by a patch with WINDOW_TYPE_MENU, I=
=20
> >>changed it back to WINDOW_TYPE_DOCK for Kwin (which is also not optim=
um:=20
> >>sloppy focus doesn't work). It has to do with focus attraction. I hav=
e=20
> >>some more fullscreen issues in my queue. But the more I go into detai=
ls,=20
> >>the less I find an end. Different WMs and even different versions of =
the=20
> >>same WM may behave differently. The main problems are the transient-f=
or=20
> >>and window-type properties of the GUI windows which are not always=20
> >>handled by the WM as expected. And it seems to me that the layer=20
> >>handling of xine-ui needs some rewriting. So, any input is appreciate=
d.
> >=20
> >=20
> > what on earth are you doing making menus wm managed windows? why aren=
't you
> > just using override-redirect like every good widget set :)
> >=20
> >=20
> xine-ui is historically grown stuff. Making such a change may have=20
> far-reaching consequences. Moreover, the other GUI windows are also=20
> affected by fullscreen problems. A WM may be proofed ICCCM compliant,=20
> but ICCCM does not rule everything up to the very last detail and=20
> different WMs set/use different window properties (and even WM bugs=20
> cannot be excluded). That's a reason why xine-toolkit does extensive=20
> checks for the WM type and tries to adapt itself. So, the best way I se=
e=20
> at the moment is to find out about WM behaviour and adjust xine-ui's=20
> code accordingly.

yes - BUT for menus - if you did override-redirect,

1. you would not interact with the wm, override-redirect windows bypass w=
m';s
and go straight to X thus you have no need to worry what the wm will do -
it will do nothing.
2. override-redirect windows give you (the app or toolkit) full control, =
but
you lose window manager "help". this is ok for menus as they are transien=
t and
pop up quickly on a mouse of key press, stay up until the selection of an=
 item
is aborted, or something is selected (and you will grab the keyboard and =
mouse
during menu popup to make sure you retain control until the users does on=
e of
the above).
3. they are "faster" at popping up as there is no redirection via the wm
4. this is how xt, motif, gtk, qt, (need i go on) do their menus. this is
because it is the most sane way and removes the wm from the picture.

that is why i asked - why make the menus wm managed? making them managed =
highly
complicates life as you say above. there is no need to... :)

-- ------------- Codito, ergo sum - "I code,
therefore I am" -------------- The Rasterman (Carsten Haitzler)
ra...@ra... =E8=A3=B8=E5=A5=BD=E5=A4=9A
Tokyo, Japan (=E6=9D=B1=E4=BA=AC =E6=97=A5=E6=9C=AC)