You rock. :)

Hi

I’m looking at your fullscreen demo. I finally understand why you use
three windows. […]

  • So why your xit demo is “written from scratch”? You simply edited my

  • code (http://wizard.ae.krakow.pl/~jb/fullscreen.tar.gz).

  • Beware there may be some bugs. My knowledge about X programming is poor,

  • so you shouldn’t rely so hevily on my code.


There can be many approaches to the problem of moving image to/from
fullscreen. I’m remapping internal window between normal application
window and fullscreen override-redirected one, but probably moving
internal window directly onto root giving it large enough black border
may be possible. How about moving image instead internal window?

You should remember that current video mode and list of available video
modes is dynamic. You should reread it every time you’re using it.

Panic key such as SysRQ might be used to leave fullscreen despite focus.

Problems:

I don’t know how to guarantee the fullscreen window will be always on top.

I’m not sure how focus can be traced in nonmanaged environment. In demo
I just assumed that we have focus all the time. This problem also affects
old window managers like twm. “Follow mouse” focus model is always
uncertain.

Ideas:

Maximize window attribute can inform when user wants fullscreen mode to
be used. It can be used instead or beside program-side selection.
If there would be a way to leave maximized mode from app, we could treat
maximization as fullscreen indicator. When we lose focus we should remove
maximization attr from our window (how?).

Sometimes user clicks title bar just to move window. In such a case we should
stop ourselves from moving to fullscreen, and do it later when user just
click title bar. There is no method (?) to detect that user’s click however.
We should lose focus first.

Fullscreen mode should be user decision. Application should be able to
provide hint about it. “Managed fullscreen” should be named simply
fullscreen and DGA mode should be used when user will set I_AM_KAMIKAZE
environment variable. (It locks virtual console – this is dangerous. I had
problems with your demos)

Jan Bobrowski
jb at wizard.ae.krakow.pl

PS. (BTW) You used hack to detect autorepeated key in your keyboard driver.
There’s legal method to do so. XKBlib.h defines XkbGetDetectableAutoRepeat
for that purpose. (key-ups will be not generated)

I started with some code from viewport.c, and ended up reimplementing most
of what you did from scratch as I began to understand the X interactions.

  • Beware there may be some bugs. My knowledge about X programming is poor,
  • so you shouldn’t rely so hevily on my code.

I’ve been hitting the Xlib manuals and experimenting a great deal.
I did fix a few focus related bugs.

There can be many approaches to the problem of moving image to/from
fullscreen. I’m remapping internal window between normal application
window and fullscreen override-redirected one, but probably moving
internal window directly onto root giving it large enough black border
may be possible. How about moving image instead internal window?

Hmm, an interesting idea. That way you only need two windows instead of
three, and it removes some possible window manager interactions with the
child window.

You should remember that current video mode and list of available video
modes is dynamic. You should reread it every time you’re using it.

Thanks.

Panic key such as SysRQ might be used to leave fullscreen despite focus.

Not a bad idea…

Problems:

I don’t know how to guarantee the fullscreen window will be always on top.

You can’t. I ran into this problem with Enlightenment when using
"manually place windows", and trying to get into fullscreen mode
immediately. Enlightenment couldn’t grab the mouse, so it placed
the window as high as possible, and I couldn’t force it down, nor
could I raise the fullscreen window above it. That’s the reason
I eventually implemented the "wait until the window manager is idle"
code that you used.

I’m not sure how focus can be traced in nonmanaged environment. In demo
I just assumed that we have focus all the time. This problem also affects
old window managers like twm. “Follow mouse” focus model is always
uncertain.

I tested the focus follows mouse mode extensively. What happens if the
idle delay is too short, is the code leaves fullscreen mode, the mouse
hasn’t moved, and since it still may be above the managed window, it
reverts to fullscreen immediately (it takes about a second to switch
video modes). I lengthened the delay until there was a comfortable
gap between switching from fullscreen mode and switching back in which
I could move the mouse to another window.

Ideas:

Maximize window attribute can inform when user wants fullscreen mode to
be used. It can be used instead or beside program-side selection.
If there would be a way to leave maximized mode from app, we could treat
maximization as fullscreen indicator. When we lose focus we should remove
maximization attr from our window (how?).

Hmmm.

Sometimes user clicks title bar just to move window. In such a case we should
stop ourselves from moving to fullscreen, and do it later when user just
click title bar. There is no method (?) to detect that user’s click however.
We should lose focus first.

I’m handling LeaveNotify for this.

Fullscreen mode should be user decision. Application should be able to
provide hint about it. “Managed fullscreen” should be named simply
fullscreen and DGA mode should be used when user will set I_AM_KAMIKAZE
environment variable. (It locks virtual console – this is dangerous. I had
problems with your demos)

I agree. The Loki products have the -f fullscreen command line flag,
which will enable this. I’m also thinking about adding Alt-Enter to
the list of “official” key bindings.

Jan Bobrowski
jb at wizard.ae.krakow.pl

Thanks for the feedback!

PS. (BTW) You used hack to detect autorepeated key in your keyboard driver.
There’s legal method to do so. XKBlib.h defines XkbGetDetectableAutoRepeat
for that purpose. (key-ups will be not generated)

XKB is another extension which may or may not be supported, and seems
to affect the server as well (please correct me if I’m wrong!)
I’m inclined to keep the current code, unless it doesn’t work somewhere.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec