Re: window geometry/positioning

[Jan Kratochvil <short ucw cz>]

Hi

On Sat, Mar 10, 2001 at 12:36:02AM -0500, Havoc Pennington wrote:
...
> Owen and I discussed the issue of window positioning and geometry, and
> worked out a proposal. This addresses bug:
>   http://bugzilla.gnome.org/show_bug.cgi?id=17167
...
> We came up with the following use-cases for where people are trying to
> use these things on toplevels:
...
[ yet another addition: ]

 - "fullscreen size limit" - some applications have widgets generated
   dynamically (like harddisks found on the current machine). Such content may
   not fit on the screen so they want to limit it to the maximum size WITHOUT
   any WM frame decorations.

   I have spent yesterday afternoon by searching through gtk-list and everyone
   still solves how to do such simple fullscreen limitation, they usually
   finallu resolve it by limit GtkWindow to gdk_screen_{width,height}() as it
   is hard to get WM decorations size/placement. But when a regular
   application wants to limit itself to the screen size, it doesn't want to be
   without WM decorations - without decorations can be some fullscreen TV
   etc., NOT application!

   Yes, I am aware that such limitation functionality is more appropriate as
   general WM feature but as most of other such 'use-cases', application
   sometimes just want to emulate possibly missing WM feature (such
   application-based limitation should have its disable in the application
   preferences). Also there is a problem that it would be very bold from WM to
   limit ANY application exceeding screen size as there exist applictions with
   STATIC content (and thus not ready for size limit from WM) exceeding
   640x480.  Unfortunately there is no WM hint which can application use to
   say:
   "Hi WM, I have some dynamic content so I'm ready for any size limits from
   you. And you are so gentle to respect my GDK_HINT_MIN_SIZE, of course."

   I'm currently using XQueryTree/XGetGeometry to detect WM frame decorations
   (all ancesting XWindows from the
    ((GdkWindowPrivate *)gtk_widget_get_toplevel(ANYTHING)->window)->xwindow
   up to the root XWindow) which works fine but it is a crude hack (and used
   also in Mozilla, according to gtk-list).


> So we are proposing the following functions on the GTK level, with the
> exact GDK implementation to be decided:
...

 gtk_window_set_limitations
   (GtkWindow *, gboolean screen_limit, gboolean reposition_window)

  Both FALSE by default.
  
  (screen_limit)      => Attempts to limit window size to screen size.

  (reposition_window) => Try to always shift the window up/left to get its
			 contents always completely visible (including WM
			 decorations).

  Needed actions should be probably done only when:

gtk_window_configure_event():
-----------------------------
   * 3) the size changed and resize_count > 0
   *    -> we asked for a new size and we got one

  Unfortunately it is hard to do repositioning inside the whole
  possibly-multi-pass resizing cycle, safe decorations estimation should be
  probably done after such whole cycle. (Decorations can finally resize
  themselves due to our resize.) I'm relying on gtk_idle but unfortunately
  there is a race that WM may not yet updated its decorations although the
  applications is perfectly in idle state already. I'm attaching some edited
  notes from my code but take them with reserve, please:

/* We need to keep decorations size updated for the current
 * difference beween "top-GtkWindow" size and the "top-XWindow" size.
 * Although it would seem appropriate to execute window reposition right now
 * IF the "idle" already occured but such behaviour would be WRONG. Sometimes
 * GTK+ will invoke:
 *  + 'idler' (when resize_count!=0)
 *  + 'configurer' (this code point)
 *    But here we may be are INSIDE the reallocation cycle and the GTK vs. X
 *    structures may not be matching!
 *    In such case the estimation 'xtop-own' would be incorrect!
 *  + 'idler' - additional one or generally another bunch of
 *    idlers/configurers
 * Generally waiting for another idler should never be bad thing.
 */


>  gtk_window_set_frame_size ()
>  gtk_window_get_frame_size ()
>  
>   Attempts as best we can to set and get the size of the window
>   _including the window manager frame_. These functions can't 
>   be implemented reliably, but we can do a good bit better
>   than naive application authors might do.

  get_frame_size () should also return the POSITION of our window in the
  parent WM frame, not just the total WIDTH/HEIGHT of the frame.
  (Not clear for me whether these fields were planned by you.)


> So find the bugs in this mail, I'm implementing this soon.

  Not bugs but IM>H<O missing feature.


Lace


P.S.: Please don't think that I'm so limited as described above.  ;-)