Re: [pygtk] expander packing issue
Alex Roitman wrote:
On Wed, 2006-03-01 at 20:09 -0800, John Finlay wrote:
Alex Roitman wrote:
Hello,
I have asked this question before:
http://www.daa.com.au/pipermail/pygtk/2005-December/011572.html
and was pointed by John Finlay to the proper solution:
http://www.daa.com.au/pipermail/pygtk/2005-December/011562.html
Unfortunately, following the given advice still did not do the trick.
Running the code below still leaves the window not shrunken in
either direction. It seems to be limited by the size that would
be a minimum size of the _expanded_ expander, not collapsed expander.
==
import gtk
d = gtk.Dialog('Dialog')
d.connect('delete-event',lambda obj,event: gtk.main_quit())
e = gtk.Expander('Expander')
e.add(gtk.Label('Label\nAnother line that is very very very long\n'
'and another line'))
def expander_toggled(expander,param):
if expander.get_expanded():
print "expanding -> do nothing"
else:
print "collapsing -> shrink both X and Y size"
d.resize(1,1)
e.connect('notify::expanded',expander_toggled)
d.vbox.add(e)
d.show_all()
gtk.main()
==
If after
print "expanding -> do nothing"
I add:
d.resize(400,200)
or if I resize the window manually to a larger size
while expander is in the expanded state, I can see that
the window does indeed shrink somewhat upon collapsing
the expander, so I know that resize() is working.
The problem is that it shrinks to the size constrained
by _expanded_ state of the expander, not its _collapsed_
state.
After collapsing, I can manually resize the window
to the smaller size, picking up "the slack" produced
by collapsing the expander.
Am I missing something obvious? How can I make the window
shrink after expander is collapsed so that there's
no "slack"?
I thought the message following mine actually indicated a better
solution than the one I suggested:
http://www.daa.com.au/pipermail/pygtk/2005-December/011564.html
i.e. use d.set_resizable(False)
This does shrink the dialog window, but then it becomes, er,
not resizable :-) For a complex window with a lot of widgets
and a text editable area, this is not very nice. We do want small
size, but the user will ultimately decide what's the convenient
size. Smallest is the nice default behavior on expander collapse.
What's your thinking on how this would work?
My wild guess as to what's happening would be that the size request
of the expander widget is not set to the new state while the handlers
are being run. It is properly set afterwards, so I can manually do
what I want. But this behavior seems to leave me no way to do
the obviously logical thing: free the space when expander is collapsed.
If you add the expander using d.vbox.pack_start(e, False) the expander
will shrink automatically. If a textview shares the vbox it will expand
when the expander shrinks. Is that what you're looking for?
John
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] [ANNOUNCE] Twenty-ninth release of PythonCAD now available
Hi. I'm pleased to announce the twenty-ninth development release of PythonCAD, a CAD package for open-source software users. As the name implies, PythonCAD is written entirely in Python. The goal of this project is to create a fully scriptable drafting program that will match and eventually exceed features found in commercial CAD software. PythonCAD is released under the GNU Public License (GPL). PythonCAD requires Python 2.2 or newer. The interface is GTK 2.0 based, and uses the PyGTK module for interfacing to GTK. The design of PythonCAD is built around the idea of separating the interface from the back end as much as possible. By doing this, it is hoped that both GNOME and KDE interfaces can be added to PythonCAD through usage of the appropriate Python module. Addition of other PythonCAD interfaces will depend on the availability of a Python module for that particular interface and developer interest and action. The twenty-ninth release of PythonCAD contains various improvements to the internal entity creation and manipulation code. The routines for transferring entities between layers has been reworked, as have the routines for deleting entities. This code rework flushed out a number of bugs and sub-optimal code issues which have been resolved. The code for creating and modifying Dimension entities was both simplified by removing redundant arguments to various methods and some missing undo/redo abilities were added as well. In addition to internal code improvements, the ability to toggle RadialDimension entities to display diameter values and the ability to invert an AngularDimension entity have been added to the interface. Lastly, a variety of miscellaneous bug fixes and code improvements are present in this release. A mailing list for the development and use of PythonCAD is available. Visit the following page for information about subscribing and viewing the mailing list archive: http://mail.python.org/mailman/listinfo/pythoncad Visit the PythonCAD web site for more information about what PythonCAD does and aims to be: http://www.pythoncad.org/ Come and join me in developing PythonCAD into a world class drafting program! Art Haas -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gtk.Entry / gtk.Completion behavior -- can I change it?
Hi, Am Donnerstag, den 02.03.2006, 20:29 -0600 schrieb Chris Gonnerman: > I have an application with a form, very vanilla, and some of the > gtk.Entry fields have attached gtk.Completions to make life easier for > my users (who happen to work for me). When working the form entirely > from the keyboard, selecting an item requires arrowing down to it (after > the gtk.Completion list appears), then pressing Return. My users are > accustomed to the Windows standard behavior, where pressing Tab after > highlighting the target item inserts it into the field, then passes > focus to the next field. > > I've banged my head against Google for a few hours now, and can't figure > out any reasonable way to change this behavior. Have I missed something? I tried with gtk+ 2.8.9 and there I confirm that it works strangely (assuming you mean gtk.EntryCompletion). Typing some prefix into the entry causes - the listbox to pop up - the first item to be selected <- this one drives me nuts, can't it stop getting in my way? Then press down arrow and press tab, indeed, it takes the wrong one... I'd file a bug with gtk... cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] a question ab filechooserbutton
Hi, I just use get_filename(), it works, but while as I click cdrom driver, the problem still there. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] a question ab filechooserbutton
Hi, I was puzzled ab filechooserbutton class, when I clicked the button and changed the folder, but the get_current_folder() still get no change most of times, how could I used it? There is not a document ab it, what’s ab its signals such as current_folder_changed or selection_changed or update_preview? Please give me any idea ab it, thanks. Wang wei 2006-3-3 ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
