On Tue, Jul 13, 2004 at 11:21:58PM -0300, Christian Robottom Reis wrote:
> On Tue, Jul 13, 2004 at 09:05:51PM -0500, Alex Roitman wrote:
> 
> > Another interesting thing is that the packing defaults would be TRUE for
> > both properties, so this is really going against the defaults without
> > the way to revert this behavior.
> > 
> > Does this seem like enough grounds for filing a bug? Should I ask for changing
> > the packing to the defaults, or should I ask for means to affect the packing?
> 
> I don't know the answer to the second question, though to the first I'd
> suggest a `yes'. There are at least a few points to consider:
> 
>     - Might the FALSEs be put there for a reason -- are you going
>       to break existing druid pages?

Most likely some of the existing druids will look uglier if FALSE were changed
to the default TRUE. This is because buttons and labels don't look nice when
vertically stretched.

>       I'm having a hard time telling why FALSE would be the default
>       expansion for a VBox inside a druid page. Is this really the main
>       page widget?

There's a block of (pre_item_question,item,post_item_blurb) that can be
appended to the page. No other methods allow you to add anything onto
the druid page. The first and third are strings, and I would understand
having them not EXPANDed vertically. The central item is pretty much the
only widget on the page, except for aforementioned labels and the druid
buttons on the bottom.

>     - Is it possible to request a way to change packing without breaking
>       API compatibility? The easiest way is probably adding new API for
>       setting packing externally.

That's what I would like to have: 
1. A couple of optional packing arguments for append_item()
2. A method to change the packing properties, something like
   page.set_child_packing() along the lines of the method for the Box-es.
3. Another function to complement append_item, something like
   append_item_default_packing()

Any of the above choices would fill the gap for me and keep the backward
API compatibility.

>     - I think that hardcoding this is probably a bad idea. 

I hear you :-)

Thanks,
Alex

P.S. I started a similar thread on gnome-devel-list to get their advice. 
Since the problem is not specific to gnome-python I will probably stop 
posting to this thread. Please see gnome-devel archives if you're interested.
If/when I file the bug, I'll post the number here, just in case.

Alex

-- 
Alexander Roitman   http://ebner.neuroscience.umn.edu/people/alex.html
Dept. of Neuroscience, Lions Research Building
2001 6th Street SE, Minneapolis, MN  55455
Tel (612) 625-7566   FAX (612) 626-9201

Attachment: signature.asc
Description: Digital signature

_______________________________________________
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Reply via email to