Re: gtkwindow changes

[Tim Janik <timj gtk org>]

On 17 Aug 2001, Owen Taylor wrote:

> > > Hmm, was it even intended that you could set a toplevel window to
> > > RESIZE_IMMEDIATE? The potential for causing yourself serious problem
> > 
> > well, we started out with gtk having RESIZE_IMMEDIATE being the only possible
> > resizing policy and at some point added the ability to handle resizes from
> > an idle handler. we never had a reason to disable RESIZE_IMMEDIATE for
> > toplevels, and in fact 1.2 still works fine with that kind of setup.
> 
> Actually, I believe 1.0 had only resize queing on the toplevel, and no
> ability to disable it. I'd have to go to the code to check that
> however.

yep, that's about right.

> We added RESIZE_QUEUE for GTK+-1.2 because it was needed for GtkViewport.

> I think we added RESIZE_IMMEDIATE just because it was easy enough and
> we sort of thought it might be useful for something.

nope, we basically handled RESIZE_IMMEDIATE because it was what we had so far
for non-toplevel containers. we did on the way re-introduce RESIZE_IMMEDIATE
for toplevels ("re-introduce" because that's what we had in early 1997 before
we did anything of resizing/redrawing asyncronously).

> > > with this is quite high.
> > 
> > why so? the bug hit in gtk_window_move_resize() was introduced recently,
> > what serious problems are you thinking about?
> 
> If you don't have queued resizes, your performance is miserable.
> We queue_resize() all over the place...

that depends on what kind of changes you actually do to your widgets.
if your only change is updating one label, then immediate doesn't
behave any different than queue, except that it shouldn't wait for
a configure event upon main window resizes.

> > > Is there a good reason for doing so?
> > 
> > is there a good reason not to?
> > considering that usually all containers but GtkWindow have RESIZE_PARENT
> > set on them
> 
> Not GtkViewport.

"usually". GtkViewport is really the only widget that doesn't have
RESIZE_PARENT by default, and i doubt many people call or even know about
set_resize_mode.

> > questioning RESIZE_IMMEDIATE for GtkWindow is more about
> > questioning set_resize_mode() in general, so far i've not come across
> > good reasons to disable RESIZE_IMMEDIATE, if you have any, describe them.
> > note that gtk_window_move_resize() usually handles RESIZE_IMMEDIATE quite
> > fine. in the case where we defer widget tree resizes upon issueing
> > gdk_window_resize() until we receive the configure event, we just meant
> > to take advatage of the resize queueing facility. in general, code
> > shouldn't rely on resizes occouring asyncronously.
>  
> There should never be any reason to have to justify why you should
> _not_ add extra complications. If there is no reason to do something,

i'm not _adding_ something, RESIZE_IMEMDIATE is there since RESIZE_QUEUE,
so if at all, i can just take your statement as "There should never be any
reason to have to justify why you should _have_ extra complications.", and
if i took that seriously it'd be my license to remove any and all deprecated
API we currently carry around with us.

> than it shouldn't be in there, since you have:
> 
>  - Made your interfaces more complex
> 
>  - Made your code more complex, and added new possible bugs.
>    Code paths that nobody ever uses are the perfect breeding ground
>    for bugs, as you've demonstrated by using RESIZE_IMMEDIATE
>    in GLE.

i feel you're somewhat misrepresenting matters. i'm not going to introduce
RESIZE_IMEMDIATE or have recently added it, i just brought it back to work.
if your point is to change existing API and get rid of RESIZE_IMEMDIATE
because it adds extra complexity, then state that.
i doubt it's used much in third-party code so it's probably not going
to really hurt users, but as long as we keep it, i'll keep code triggering
it in GLE so i notice when it breaks, i don't see anything wrong with that.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ