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

[Steve_Northover@xxxxxxx]

Are you telling me that gdk_window_get_frame_extents() is broken
and that I should attempt a flavour of our Motif hack on GTK?  What does
gdk_window_get_frame_extents() do?

<rant>
>It _is_ completely possible to write code that works fine and reliably
>under the X model - it's just that all cross-platform toolkits are
>apparently first written on win32, then API frozen, and then
>ported. ;-) So they end up with unportable APIs. It's trivial to
>emulate the X behavior on Windows so people are doing stuff
>backward. ;-)

Not true ... the VA/Smalltalk widget toolkit CommonWidgets uses Motif API
and was written first on X and then ported to Windows.  This is the toolkit on
which SWT is based.  Smalltalk users liked the functionality but found the
Motif API unpleasant.

>I consider the X model totally legitimate - there are many very valid
>reasons for it, for example "window is maximized so can't be resized"
>or "the user changed the titlebar font size because they have poor
>vision, and thus the frame size changed" or whatever.

Not exactly sure what you're getting at here.  Not knowing the size of the
trimmings means that you cannot position a shell ... but apps need to do
this to implement things like fancy hover help, code assist etc.

WRT:  Shell extents.  Even telling people that you couldn't trust the size
of the shell until it was realized didn't help for CommonWidgets because
the implementation on Windows returned the correct size all the time (the
choice was to do this or return a random number?) so people relied on the
Windows behavior anyways and then were surprised when their code
failed on X.  Pointing them at the spec, and saying the behavior was not
guaranteed on all platforms wasn't a great solution because nobody
reads the spec.

So, we take API seriously.  This time round, shell extent thing works like
Windows because that's what people expect, it's reasonable and it is
possible to implement on X with a small (but gross) hack.
</rant>

Steve

Havoc Pennington <hp@xxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 03/12/02 04:05 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: 
> 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?

Well, GDK has the built in gdk_window_get_frame_extents() to try to
get the size of the window frame. It's not reliable, for obvious
reasons. But you can take advantage of our prewritten broken hack
instead of having to do your own.

It _is_ completely possible to write code that works fine and reliably
under the X model - it's just that all cross-platform toolkits are
apparently first written on win32, then API frozen, and then
ported. ;-) So they end up with unportable APIs. It's trivial to
emulate the X behavior on Windows so people are doing stuff
backward. ;-)

I consider the X model totally legitimate - there are many very valid
reasons for it, for example "window is maximized so can't be resized"
or "the user changed the titlebar font size because they have poor
vision, and thus the frame size changed" or whatever.

I don't think this is really a GTK issue, rather an X issue; I predict
you'll find that the issues and possible solutions are pretty much
identical to the ones with Motif.

Havoc

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