[pygtk] size request in scrolled windows + viewport

[Pietro Battiston]

Il giorno mar, 18/08/2009 alle 18.34 +0200, Alessandro Dentella ha
scritto:
> On Tue, Aug 18, 2009 at 03:44:08PM +0200, Pietro Battiston wrote:
> > Il giorno lun, 03/08/2009 alle 20.57 -0700, John Finlay ha scritto:
> > > On 08/03/2009 01:27 PM, Alessandro Dentella wrote:
> > > > Hi
> > > >
> > > >    I have a table with many widgets inside, so that total dimenstions are
> > > >    bigger that the screen so that I put it in a ScrolledWindow + ViewPort.
> > > >
> > > >    So far so good. ow I have a Window with all widgets in a pane that scrolls
> > > >    fine... but starts very little indeed.
> > > >
> > > >    I'd like to know how to propagate the dimentions that the table would
> > > >    have requested to set dimentions of the Viewport.
> > > >
> > > >    I'm a little lost between size_request/get_child_requisition and similar
> > > >    methds.
> > > >
> > > >    
> > > If the table is larger than the screen then I would assume you want the 
> > > window to be smaller than the table. I usually set the default size of 
> > > the Window so it starts up bigger than the minimum size.
> > 
> > Right. Though several days passed, I'd like to signal that a deeper
> > answer is that pygtk (and Gtk in general) doesn't know/care about the
> > available size of the screen. More info can be found on the discussion
> > following this mail:
> > 
> > http://mail.gnome.org/archives/gtk-devel-list/2009-January/msg00057.html
> > 
> > Though horrible non-portable hacks are indeed possible, the clean
> > "solution" is to:
> > - set reasonable defaults
> 
> what is a "reasonable default"? It's just a height/width calculated on the
> screen the user is using. I don't think you can find any better value.
> 

Sure... this solution is "clean" gtkishly, I don't mean it is
satisfactory.

> 
> > - remember user-defined resizes across program runs
> 
> 
> That doesn't helpl when I want to guess the best "starting" window
> dimention.

Again, sure.

> 
> Really there was another mail - mistakenly sent to John Finlay that answerd
> me- that I report here:
> 
> 
>   Thanks John,
> 
>   I'd like to set it no greater than really needed. Now I query the table with
>   size_request(), but if I set dimentions -possibly reduced- on the Viewport
>   (or SrolledWidow) with set_size_request(x,y) that would inhibit the
>   possibility for a user to further reduce it, and set_default_size() only
>   work on window...
> 
> 
> My workaround is to:
> 
>   1. get the size_request of the table
>   2. derive a best macth, based on screen dimentions and size_request

This is where horrible non-portable hacks are needed for precision (if
you want to calculate the space of the screen free from panels etc.)

>   3. understand how many pixels are needed by non ViewPort staff around it
>   4. set_default_size() on the window so that the user can still interact
>      with it and refine it
> 
> Of course I could simplify all this process if I could 
> 
>   1. set size_request() on the Viewport/ScrolledWidow
>   2. set a parameter that says: you can resize


If you _ovveride_ size_request() (presumably by defining the
do_size_request() method), then the user _can_ resize.

If you instead use set_size_request(), the user can't (it is described
by documentation as "the smallest size a widget can accept while still
functioning well and drawing itself correctly", so the limitation makes
sense).

In your case, why isn't a gtk.Window.resize() enough?

> 
> At the end I don't understand why size_request of the table inserted in the
> ViewPort is not forwarded upward to it's container (the ViewPort).

I'm not sure what you'd want... the goal of the ScrolledWindow is
_exactly_ to break the chain of size_requests... but if you want, a more
pragmatic answerm may be "not to overflow from screen with big
requests".

Pietro