SDL 1.3 and window size change without SDL_WINDOW_RESIZABLE flag (really, another X11 backend issue)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I’ve encountered this (rather design) issue when looking at X11 code in
SDL 1.3. Practically there is two different cases:

  1. User creates fullscreen window with resolution that is not supported
    by the graphics hardware (for example 1234x123 would be quite
    unstandard). So most logical action here would be to switch nearest
    supported larger mode and create fullscreen surface where user would get
    surface (or similar object) of the requested size but that surface would
    be placed in the middle of parent surface. Simple case.

  2. User creates windowed window. Unfortunately window manager is evil
    (for example like those embedded one-window-op-top-at-the-time window
    managers) and resizes the window to size which is different from what
    user requested in firts place. In this case same kind of actions would
    give user impression that she got surface of size she requested. Or is
    it better for SDL to be honest and give different sized surface? In old
    style SDL (at least X11 backend) it used to give surface with same size
    and user was happy. I think this is better as not enough people think
    about the possibility of getting bigger or smaller window as requested.
    But then again, as SDL 1.3 will have more or less proper multi-window
    system, the user playing with windowed surfaces (or windows etc) should
    be aware of the size changes.

Now back to my story. I was trying SDL 1.3 / X11 and checked the code
and it seemed to be quite uncompleted from the functional point of view
(was quite buggy when testing). I will look into this deeper how to
implement this but could anybody say what is the progress of current X11
implementation?

Now this gets back to multiple-window issue. In this fullscreen use-case
it could be beneficial for the simplicity if there is parent
(fullscreen) window and actual window as centered child window. But
again, if general public (and especially primary developers!) could
comment what would be nicest thing in those use-cases, that would be
helpful.

  • – Kuisma
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFFeW5aHIcMorDK+qsRAtNdAKCkAEVUyGYqN5SES6V7sKFoijF8wwCgikOu
975Co7nLym3tzYvGzFiAsig=
=RKfs
-----END PGP SIGNATURE-----