Re: [platform-swt-dev] Problem with Shell._setSize()

[Steve_Northover@xxxxxxx]

Yes, it tries to resize and returns.  This is correct.  Because the size of a control
is always queried then it's up to the underlying widget toolkit to make sure that
the size is consistent.  If it's not, then Windows/Motif/GTK/Photon have a bug
(or if you prefer, a feature that needs to be worked around).

Now, the size of a control in SWT includes the trimmings.  This is a deliberate
design decision.  Try writing a combo box when you can't rely on the position
of the drop down child (yes, I know about OverrideShell and what it's for) but
in general, it's a pretty crazy widget system where you can't position a widget
where you want it (and yes, I know also that you are at the mercy of the window
manager but we need to do the best we can).

So, this is not a problem for child controls but causes problems for top level
shells on systems that have window managers that do not provide API to
determine the size of the trimmings.  For example, Photon has a window
manager but there is API to get the size of the trimmings.  Unix has no API.

On Unix, where there is "window manager du jour", so the strategy that SWT
uses is to make an initial guess and then correct the guess when the real numbers
come in.  XtResizeWidget takes width and height in client units and the resulting
window is actually larger (it includes the trim).  So, using the guess, SWT asks
for a smaller shell, the window manager creates the larger shell and that shell
is the size the programmer asked for.  If the guess is wrong for the type
of trimming, the guess is updated so the next time it will be correct.  Really,
this is an awful hack and I'm sure there are cases where it fails but I can't
think of any other way to do it.

Now, this is probably more than you ever wanted to know about the problem.
I am open to better strategies and all ideas.  Will this approach work on GTK?
Do you have a better suggestion?

Steve

Havoc Pennington <hp@xxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 03/12/02 02:20 PM Please respond to platform-swt-dev

To:        platform-swt-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-swt-dev] Problem with Shell._setSize()

Steve_Northover@xxxxxxx writes: 
> All the discussion of "fantasy shell sizes" is bogus too.  SWT returns the
> real size of the shell.  State variables for location and size were not
> necessary on Motif so why would they be necessary on GTK?  Both are
> asynchronous.  Actually, there was some special processing in Shell
> on Motif with respect to the shell's initial size.  I will go look at the 
> code.
> 

The Motif code is not maintaining the invariant about getSize(), I
don't think:

public void setSize (int width, int height) {
                 checkWidget();
                 /*
                 * Feature in Motif.  Motif will not allow a window
                 * to have a zero width or zero height.  The fix is
                 * to ensure these values are never zero.
                 */
                 saveBounds ();
                 int newWidth = Math.max (width - trimWidth (), 1);
                 int newHeight = Math.max (height - trimHeight (), 1);
                 if (!reparented) {
                                  super.setSize(newWidth, newHeight);
                                  return;
                 }
                 boolean isFocus = caret != null && caret.isFocusCaret ();
                 if (isFocus) caret.killFocus ();
                 OS.XtResizeWidget (shellHandle, newWidth, newHeight, 0);
                 if (isFocus) caret.setFocus ();
}

It just tries to resize and returns.

So if SWT allows that semantic it's perfect, works fine in GTK too.
No need for maintaining a fantasy SWT size separately.

I don't know from reading the Motif getSize() though what size is
being gotten (client-side last-set size, last-received event size, or
server-side size). Someone who knows Motif could say.

Havoc
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev