I have found an explanation... in the official documentation.

"The minimum height for the minimum width is normally used to set the
minimum size constraint on the toplevel (unless
gtk_window_set_geometry_hints() is explicitly used instead)."

But the real answer to my problem is not in that sentence, but in its
non-obvious (to me) consequence: Gtk.Widget.do_get_preferred_width()
should _not_ return the minimal width the widget will ever be able to
cope with, but rather its width in some reasonable form factor, though
as compressed as possible.

(still, I don't see the rational for this design choice, since the
layout algorithm will not be able to know the _real_ minimum width of my
widget)

Pietro

Il giorno lun, 17/06/2013 alle 20.20 +0200, Pietro Battiston ha scritto:
> Hello,
> 
> I'm designing a widget. Its "do_get_request_mode(self)" returns
> Gtk.SizeRequestMode.HEIGHT_FOR_WIDTH.
> 
> 
> Now, in a testcase, the widget does the following:
> 1) do_get_preferred_width() is called: it returns 53 (minimum), 212
> (natural)
> 2) do_get_preferred_height_for_width() is called with width 53: it
> returns 170, 170
> 3) do_get_preferred_height_for_width() is called with width 212: it
> returns 51, 51
> 
> So far, so good: the widget has received all the calls I expected, and
> returned what I wanted it to. But now, what I would expect (at least in
> a test case in which no other widgets are reclaiming anything) would be
> that the widget is offered (212, 51). Instead, not only it is offered
> (212, 170), but the 170 is considered as minimum - I'm unable to resize
> the widget to something smaller. Now, I did declare 170 as a minimum...
> but only in the case in which the width is 53!
> 
> To reproduce, you can do:
> git clone git://pietrobattiston.it/quack
> cd quack
> git checkout wrapbox_error
> cd plugins/tags
> python test_wrapbox.py
> 
> to understand what I would like, just replace the "if nat:" at line 93
> with "if True:", and rerun.
> 
> Thank you in advance for any enlightenment, or pointer to a good
> discussion of such issues.
> 
> Pietro
> 
> _______________________________________________
> pygtk mailing list   [email protected]
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


_______________________________________________
pygtk mailing list   [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Reply via email to