[Guikachu] Re: status: hacking on visual resizing

[ERDI G. <ca...@ca...>]

On Wed, 30 Jan 2002, ERDI Gergo wrote:

> The next TODO item is to implement the resize grips for the other three
> corners, and then we're all done for the 1.2.0 betas.

Implementing the other resize grips was very straightforward -- but then
it turned out it was just too damn slow. So I did the most obvious
optimization: changes to widgets don't immediately cause a re-render,
instead, an idle handler is chained to the GTK+ main loop. This way, code
like

	widget->width += 10;
	widget->height += 6;
	widget->x -= 5;
	widget->y -= 3;

will cause only one redraw instead of four (as soon as the GTK+ event loop
is re-entered).

I still can't say I'm satisfied with rendering speed (try dragging around
a resize grip like crazy and you'll see the problem) but I'm willing to
consider this a GnomeCanvas problem and get over with life.
If anyone has some bright ideas on how to speed up rendering, please share
them. 'Just drop the Canvas and write your own' is not considered a bright
idea, unless you include a patch :).

If you want to test this, don't forget that only Buttons and Pushbuttons
are resizeable at the moment.


This last check-in also includes a change to the FormElement class that
makes it very hairy, since it uses methods like get_x/set_x instead of
Properties, like everything else. Should I use properties here instead,
and do some wild magic in Widgets::Form to forward these to the underlying
real Resources::Form? Should Widgets::Form be simply dropped and all code
moved to Resources::Form, this way Form could be a subclass of FormElement
and Resizeable, thus it could use the FormElement::x (and y) property. I'm
open to suggestions on this one.


-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= ca...@ca... =---'
CanYouFixTheSpaceBarOnMyKeyboard?