Re: atk_component_set_[extents, position, size]() implementation



Oisin Boydell wrote:
> 
> The ATK API has functions atk_component_set_extents(),
> atk_component_set_position() and atk_component_set_size() which return TRUE if
> successful, FALSE otherwise. The functions are implemented in gailwidget.c.
> 
> The position or size of a child of a container cannot be set in coordinate units
> unless the container specifically supports that. This means that the above
> functions will first need to test if the widget is a top level widget, or a
> child of a container which supports resizing and/or repositioning in coordinate
> units. If the widget is not, then the function must return FALSE.
> 
> As far as I know, the only containers that support repositioning/resizing of
> their children are GtkFixed and GtkLayout. So if the widget to be
> resized/repositioned using the above functions is not a top-level widget (these
> are always resizable/repositionable with respect to coordinate units) or the
> child of a GtkFixed or GtkLayout, then the functions should return FALSE.
> If the widget is top-level then gtk_widget_set_uposition() and
> gtk_widget_set_usize() will be used. If the widget is a child of a GtkFixed or
> GtkLayout, then gtk_layout_move()/gtk_layout_set_size() or gtk_fixed_move() will
> be used.
> 
> Does this sound reasonable?
> 
> Any comments?
> 
> I will start implementing this soon.

I think it's reasonable to allow both flavors of coords for toplevel
windows, I think we should be able to convert to whatever coordinate
units the implementing widget prefers.

The use of the boolean to indicate whether the relocation operation is
supported seems like the right approach.

-Bill
-- 
--------------
Bill Haneman
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]