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 _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
