Getting a control to expand on only one axis

[Ray Pasco]

I'm trying to get a ListBox to expand horizontally, but it keeps coming out with some undetermined fixed horizontal size. That size might be "the proper minimal size", but there seems to be some extra space on the right edge. See file "listbox_panel_layout.png".

The innermost sizer of 3 is vertical and has a StaticText on top of the Listbox. This sizer is inside the middle horizontal BoxSizer with a button to the right of the ListBox sizer. A 3rd outermost vertical BoxSizer holds everything. This is the desired general layout.

First, I had been playing with this for a while when the button suddenly stopped auto-expanding horizontally and became minimally sized, which is what I wanted all along, but couldn't figure out the proper incantation to specifically do this.  Is there some particular parameter that purposefully makes a control "minimally sized" ?

Next, I actually want the ListBox (not the button, of course !) to auto-expand horizontally to take up all the remaining horizontal space in the panel which excludes the minimally-sized button. The wx.EXPAND flag seems to do nothing at all. Does anyone have an idea ?

Thanks

[C M]

On Mon, Jul 26, 2010 at 12:31 AM, Ray Pasco <pas...@verizon.net> wrote:

I'm trying to get a ListBox to expand horizontally, but it keeps coming out with some undetermined fixed horizontal size. That size might be "the proper minimal size", but there seems to be some extra space on the right edge. See file "listbox_panel_layout.png".

The innermost sizer of 3 is vertical and has a StaticText on top of the Listbox. This sizer is inside the middle horizontal BoxSizer with a button to the right of the ListBox sizer. A 3rd outermost vertical BoxSizer holds everything. This is the desired general layout.

First, I had been playing with this for a while when the button suddenly stopped auto-expanding horizontally and became minimally sized, which is what I wanted all along, but couldn't figure out the proper incantation to specifically do this.  Is there some particular parameter that purposefully makes a control "minimally sized" ?

If you give it a proportion value of 0 and don't set it to wx.EXPAND, the sizer will leave the widget at its preferred size, which works well if you don't provide a size on creation or make it wx.Size(-1,-1). 

Next, I actually want the ListBox (not the button, of course !) to auto-expand horizontally to take up all the remaining horizontal space in the panel which excludes the minimally-sized button. The wx.EXPAND flag seems to do nothing at all. Does anyone have an idea ?

What you need to do is change two places.  First is lines 61-62:

allControls_horzSizer.Add( myList_vertSizer, proportion=0,
                                   flag=achs_borderflags, border=25 )

Here, change proportion=1, which means the myList_vertSizer is allowed to take up 100% of the horizontal space left over once the button's width and borders are taken into account.  Note, here you are actually allowing the *sizer* to take up that space, so that it can in turn apportion that space to the widget it sizes; you are giving it jurisdiction.  In this case, it sizes the listBox, which you already set to wx.EXPAND (in line 54).  Expand for a widget means "fill in the direction perpendicular to the orientation of the sizer it is in".  Since listBox is in a *vertical* sizer, expand here means expand *horizontally*--which is just what you want. Now that its sizer has the ability to itself take up the space it should work...but...

...the same concern about "limiting the jurisdiction" of a sizer by not allowing it to either have a proportion of 1 or to expand crops up again with the sizer sizing the one we just took care of!  It is constrained, too, shown on lines 69-71:

        acvs_borderFlags = wx.ALL
        panel_vertSizer.Add( allControls_horzSizer, proportion=0,
                             flag=acvs_borderFlags, border=25 )

So this is saying that when you add the allControls_horzSizer, it should not be allowed to expand within its sizer, panel_vertSizer.  Again, expand means to expand in the orientation perpendicular to the sizer.  Since its sizer is a *vertical* sizer, then to not allow it to expand means to not allow it to expand *horizontally*.  And yet it must be allowed, so that it can let myList_vertSizer can in turn let the listBox itself take up 100% of the width.  Therefore change the flags above to wx.ALL | wx.EXPAND.

Che

[Gadge...@live.co.uk]

 

From: Ray Pasco

Sent: Monday, July 26, 2010 5:31 AM

To: Wxpython Users

Subject: [wxPython-users] Getting a control to expand on only one axis

I'm trying to get a ListBox to expand horizontally, but it keeps coming out with some undetermined fixed horizontal size. That size might be "the proper minimal size", but there seems to be some extra space on the right edge. See file "listbox_panel_layout.png".

The innermost sizer of 3 is vertical and has a StaticText on top of the Listbox. This sizer is inside the middle horizontal BoxSizer with a button to the right of the ListBox sizer. A 3rd outermost vertical BoxSizer holds everything. This is the desired general layout.

First, I had been playing with this for a while when the button suddenly stopped auto-expanding horizontally and became minimally sized, which is what I wanted all along, but couldn't figure out the proper incantation to specifically do this.  Is there some particular parameter that purposefully makes a control "minimally sized" ?

 

When adding the control to the sizer set the proportion to 0.

Next, I actually want the ListBox (not the button, of course !) to auto-expand horizontally to take up all the remaining horizontal space in the panel which excludes the minimally-sized button. The wx.EXPAND flag seems to do nothing at all. Does anyone have an idea ?

 

You also need to set the proportion to 1 when adding the control to the sizer.

 

Hope the above sorts you out.

 

Gadget/Steve

Thanks

--
To unsubscribe, send email to wxPython-user...@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

[Ray Pasco]

Thanks for both your replies.  

I later stumbled across solution in a semi-desperate splattering of sizer parameter values.  I say "stumbled" because I have never found a reasonably complete and coherent list of sizer rules in any of the docs nor in any of the many examples with BoxSizers I have ever seen.

I don't want to rant, but...   The "UsingSizers" page on the wxPyWiki is truly HORRIBLE !  It is the most confusing "explanation" I have ever come across, anywhere, for any technical subject at all !   I am not exaggerating.  Can creating a reasonably understandable and complete sizer tutorial be that difficult ?

I now feel comfortable in getting BoxSizers to lay out anything in any manner I can think of, at the moment. Time will tell.  

More importantly, if anyone is willing, I would like write a new tutorial using the sizing rules I have learned. This must be a small group project. Checking it for validity must be done by several others. Making this tutorial "look pretty" will have to be done by some one else, too.

Ray Pasco

Here's an outline for BoxSizers I threw together.
-------------------------------------------------------------------------------
SIZERS

Sizers are control positioning algorithms. As such they can not be directly seen, but it's effects are readily apparent. The wx.BoxSizer is the most fundamental sizer and probably the most used. Understanding its rules will go a long way to understanding all the other more complex sizers.

The BoxSizer

The BoxSizer, unfortunately, is poorly named. A better one would be "StackSizer". It holds controls stacked in either the vertical or horizontal directions, from top-to-bottom or left to-right, respectively. When creating a BoxSizer, it must be declared with either the wx.VERTICAL or wx.HORIZONTAL parameter.  E.g.:

    listControls_vertSizer = wx.BoxSizer( wx.VERTICAL )

Controls of nearly any type are inserted into the sizer (top-to-bottom or right-to-left) using the .Add() method.  The general form is:

    {sizer name}.Add( {control name},
                      proportion={an integer}
                      flag={a logical "OR" of many possible positioning and padding flags},
                      [border={a positive integer}] )    # optional padding border size

The last three parameters are optional, but it is unlikely that "flag" positioning and/or spacing padding is not needed to achieve a reasonable and acceptable appearance.

The proportion argument

A control such as a multi-line wx.TextCtrl can either expandable=stretchable=grow-able along both its axes or have one or both of its dimension be a fixed size. To be expandable along an axis its axis dimension must be set to "-1'.  [ ??? Does "0" have a specific effect ? ]

The "proportion" parameter determines the size of the control in relation to the size of all the other controls in that sizer along the sizer's declared axis. A proportion value of '0' makes its .Add()_ed control be "properly minimally" sized as is typically desired with such a control as a wx.Button. A given proportion integer value greater than 0 will cause that control to be attempted to be stretched along the sizer's axis as much as the wx.Frame or wx.Window interior (client size) allows. The amount of expansion depends on the interaction of all the other controls and whether they are also trying to expand.

Each control with a proportion value >= 1 will divide up all the possible expansion room in exact proportion to their given proportion values less the room already claimed by the fixed, minimally sized controls. So, axis room is allotted according to:

wx.Window or wx.Frame Axis dimension (extent) =                  
    Sum( (the fixed-sized controls [proportion = 0])  +
         (the expanding controls  [proportion >= 1])    
       )

[ ??? Can proportion be negative ? ]

A real-life example is in order.  Let's make a wx.Frame with 4 controls: a wx.StaticText, a single-line wx.TextControl, another wx.StaticText and another single-line wx.TextControl. The wx.StaticText()_s have had their .BackGroundColour() set to something other than the frame's background color just so the extent of the staticTexts can easily be seen. The frame looks like this:

{ Insert image of file 1-SIZER.A.png ]

{ insert 2-TXTCTRLS_2-STATICTEXTS_1-SIZER.PY here }
[ maybe the code should come first, then the image ]

For now, just note the order in which controls are added to the sizer and what values are given for the "proportion" parameters.  This is pretty good for the first try. But, you probably will want to tweak it in just a few ways. First, there needs to be empty spaces to the left of the first StaticText and also to the right of the second TextCtrl. This is easily done using:

    allCtrls_horzSizer.AddSpacer( 15 )
    
... just before .Add()_ing the first StaticText and just after .Add()_ing the last TextCtrl.  The frame now looks like:

[ Insert image of file 1-SIZER.B.png ]

This was a small, be nice addition. Notice that when the frame's right-hand border is stretched the 2 spacer's "spaces" are maintained. Since the 2 StaticText_'s were added to their sizer with "proportion=0" their horizontal extent is fixed and is maintained despite any frame resizing. The TextCtrls were added to their sizer with "proportion=1", so their individual extents are equal to each other, but shrink or grow with changes in the frame's horizontal size/extent. So, now Spacers need to be added to the "Space Equation" as fixed-sized elements. Their not "controls" in the wx sense in that they have no properties or events of any kind except for their dimension along their sizer's axis.

wx.Window or wx.Frame Axis dimension (extent) =                  
    Sum( (the fixed-sized controls [proportion = 0] + AddSpacer()_s)  +
         (the expanding controls   [proportion >= 1])    
       )

Everything that takes up room in a Sizer has been accounted for, except for another separate Sizer.

The 2nd try at layout is definitely better, but a major flaw still exists:  When the frame is vetically resized all the controls in the sizer "float" up or down (vertically) in the middle of the frame.  If the frame is designed to be a fixed size this may not actually be a detriment depending on whether you happen to like everything to be automatically vertically centered.

If, instead, you want the controls pushed up near the top of the frame client a new wx.VERTICAL sizer can enclose the existing wx.HORIZONTAL sizer in order to adjust the inner sizer's vertical positioning.  Adding an inner sizer to an outer sizer is very much the same as just adding a control to a sizer. The modified code that adds a 2nd sizer:

[ insert TXTCTRLS_2-STATICTEXTS_2-SIZERS.PY here ]

Et, voila !  Not bad bad at all.  Now there's room at the bottom to add other useful controls such as buttons or anything/everything else you may want. So, let's add a couple of buttons:  "OK" and "Cancel".

{ insert additional code }

{ insert file image 2-SIZERS.B.WITH-BUTTONS.png }

This frame is getting to look like something useful. Once code to handle the button events has been added this wx.Frame (a wx.Window subclass ) is 95% on its way to becoming a custom popup window ! Actually modifying it to be a custom popup window deserves to be the subject of separate tutorial.

Now that the basics for creating and adding to BoxSizers has been covered, the slippery "flag" parameters need attention.

{ And so on ...

Should I continue ?

Is anyone willing to assist me ? }

-------------------------------------------------------------------------------

[Mike Driscoll]

> This was a small, be nice addition. Notice that when the frame's right-hand border is stretched the 2 spacer's "spaces" are maintained. Since the 2 StaticText_'s were added to their sizer with "proportion=0" their horizontal extent is fixed and is maintained despite any frame resizing. The TextCtrls were added to their sizer with "proportion=1", so their individual extents are equal to each other, but shrink or grow with changes in the frame's horizontal size/extent. So, now Spacers need to be added to the "Space Equation" as fixed-sized elements. Their not "controls" in the wx sense in that they have no properties or events of any kind except for their dimension along their sizer's axis.wx.Window or wx.Frame Axis dimension (extent) =                  

>     Sum( (the fixed-sized controls [proportion = 0] + AddSpacer()_s)  +
>          (the expanding controls   [proportion >= 1])    
>        )
> Everything that takes up room in a Sizer has been accounted for, except for another separate Sizer.
> The 2nd try at layout is definitely better, but a major flaw still exists:  When the frame is vetically resized all the controls in the sizer "float" up or down (vertically) in the middle of the frame.  If the frame is designed to be a fixed size this may not actually be a detriment depending on whether you happen to like everything to be automatically vertically centered.
> If, instead, you want the controls pushed up near the top of the frame client a new wx.VERTICAL sizer can enclose the existing wx.HORIZONTAL sizer in order to adjust the inner sizer's vertical positioning.  Adding an inner sizer to an outer sizer is very much the same as just adding a control to a sizer. The modified code that adds a 2nd sizer:
> [ insert TXTCTRLS_2-STATICTEXTS_2-SIZERS.PY here ]
> Et, voila !  Not bad bad at all.  Now there's room at the bottom to add other useful controls such as buttons or anything/everything else you may want. So, let's add a couple of buttons:  "OK" and "Cancel".
> { insert additional code }
> { insert file image 2-SIZERS.B.WITH-BUTTONS.png }
> This frame is getting to look like something useful. Once code to handle the button events has been added this wx.Frame (a wx.Window subclass ) is 95% on its way to becoming a custom popup window ! Actually modifying it to be a custom popup window deserves to be the subject of separate tutorial.
> Now that the basics for creating and adding to BoxSizers has been covered, the slippery "flag" parameters need attention.
> { And so on ...
> Should I continue ?
> Is anyone willing to assist me ? }

What kind of assistance do you need? You can post to the wiki or I can
do it for you once you've got the text the way you want it.

-------------------
Mike Driscoll

Blog: http://blog.pythonlibrary.org

[Ray Pasco]

I need:

1) Multiple people to act as "technical editors" to check the draft  for accuracy and content completeness. Another traditional editor to review readability and grammar, etc.

2) Make the final page "look pretty". I still don't have a handle on all the ins-and-outs of formatting a wiki page.

3) Testers to make sure each demo program runs properly on both Mac and *nix platforms.

Otherwise, I can:

1 - Write the draft text;
2 - Provide the demo code files. They will have been tested only on MS Windows.
3 - Provide all relevant screen shots of the actual frames & pop-ups as well as any graphic "sketches".

I estimate that my contributions will be about 85% of the overall man-hours needed.

We all need a good cross-platform file format (perhaps MS Word '97-2003 .DOC ?) to exchange the draft documents that must contain both text and images. Word has the ability to add "mark ups" and a revision history which is great for group exchange. Does "Open Office" have this, too, or is MS Office widespread enough ?

Thanks,
Ray Pasco

[Mike Driscoll]

Open Office has commenting as well. I like MS Word, but OO can open
Word files so I don't think it matters that much. I've done technical
editing before, so you can send the text and code to me and I'll be
one of the reviewers.

[WinCrazy]

Thanks.

I've always had unacceptable results converting MS Word back and forth
with Open Office. Yes, they read each other's files, but the
appearances comes out substantially different, especially dealing with
graphics. I may as well use Open Office.

How do I go about finding testers for other the other major
platforms ?

Ray Pasco

[Mike Driscoll]

I can test on Windows XP/7 and Ubuntu. You'll just have to ask on this thread for a Mac user to jump in. I know a lot of the others use Linux too, so I'm sure that a few of them wouldn't mind helping, especially since they won't need to install anything.

- Mike

--
To unsubscribe, send email to wxPython-user...@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

--
-----------------

[WinCrazy]

Great ! I'm converting to OO now. It's very similar to MS Word 2003.

I think it's best that a new thread be started asking for volunteers
after they first round of our own edit/review loop.

Ray

[Al]

Ray,

Excellent idea! I'll be happy to assist as I've just been through the
process of learning how box sizers really work.

Also, I don't see any mention of adding stretchers (AddStretchSpacer).
I think it's much better to use those than to depend on some other
control to be adjustable.

Al

[WinCrazy]

Thanks, Al. I'll be done my first draft in a couple of days.

---------------------

Mike: OO Writer loses all the inserted graphics when closed. This is
a really bad bug in V3.2.1 for MS Windows ! How could Oracle have
possibly let this bug slip through ?! However, when created in Word,
closed, and then imported into OO all the graphics and formatting is
preserved. Then saving the imported file to OO native format trashes
the images again.

I could save to a .PDF, but then no one would be able to mark their
copies up. This is a serious group sharing problem that definitely
needs to be solved soon. Do you know how every other cross-platform
development team in the world solves editing exchanged formatted
documents ?

Ray

pascor(at)verizon(dot)net

[Christopher Barker]

WinCrazy wrote:
> Do you know how every other cross-platform
> development team in the world solves editing exchanged formatted
> documents ?

Word Processors Suck.

Use some text-based format that can function properly in version control
systems: LaTeX, ReSt, html, plain old text.

But for this, why not just use the Wiki -- that's what it's for!

-Chris

> Ray
>
> pascor(at)verizon(dot)net
>
>
>
> On Jul 28, 3:16 pm, Al <alman...@rusnam.org> wrote:
>> On Jul 28, 8:15 am, WinCrazy <pas...@verizon.net> wrote:
>>
>>
>>
>>> Great ! I'm converting to OO now. It's very similar to MS Word 2003.
>>> I think it's best that a new thread be started asking for volunteers
>>> after they first round of our own edit/review loop.
>>> Ray
>>> On Jul 27, 4:31 pm, Mike Driscoll <m...@pythonlibrary.org> wrote:
>>>> I can test on Windows XP/7 and Ubuntu. You'll just have to ask on this
>>>> thread for a Mac user to jump in. I know a lot of the others use Linux too,
>>>> so I'm sure that a few of them wouldn't mind helping, especially since they
>>>> won't need to install anything.
>>>> - Mike
>> Ray,
>>
>> Excellent idea! I'll be happy to assist as I've just been through the
>> process of learning how box sizers really work.
>>
>> Also, I don't see any mention of adding stretchers (AddStretchSpacer).
>> I think it's much better to use those than to depend on some other
>> control to be adjustable.
>>
>> Al
>

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris....@noaa.gov

[Mike Driscoll]

On Jul 28, 11:35 pm, Christopher Barker <Chris.Bar...@noaa.gov> wrote:
> WinCrazy wrote:
> > Do you know how every other cross-platform
> > development team in the world solves editing exchanged formatted
> > documents ?
>
> Word Processors Suck.
>
> Use some text-based format that can function properly in version control
> systems: LaTeX, ReSt, html, plain old text.
>
> But for this, why not just use the Wiki -- that's what it's for!
>
> -Chris
>
>

I think the wiki would be fine too. Just create a new page, link to it
from the main page or the Cookbook page and send us the link. We can
fix the markup as we go along.

Alternatively, we might be able to use Google Docs or Zoho...

[Steven Sproat]

> --
> To unsubscribe, send email to wxPython-user...@googlegroups.com
> or visit http://groups.google.com/group/wxPython-users?hl=en

+1 here for using the wiki!

[Raoul]

Sounds good. I know how to create a new page, but how do I "link it to
the main page" ?

Also, how are graphic images inserted ? Do the files go into a wiki
repository of some kind ? If so, how are they linked/referred to in
the wiki page ?

Ray


On Jul 29, 10:36 am, Steven Sproat <spro...@gmail.com> wrote:

> On 29 July 2010 15:23, Mike Driscoll <kyoso...@gmail.com> wrote:
>
>
>
>
>
> > On Jul 28, 11:35 pm, Christopher Barker <Chris.Bar...@noaa.gov> wrote:
> >> WinCrazy wrote:
> >> > Do you know how every other cross-platform
> >> > development team in the world solves editing exchanged formatted
> >> > documents ?
>
> >> Word Processors Suck.
>
> >> Use some text-based format that can function properly in version control
> >> systems: LaTeX, ReSt, html, plain old text.
>
> >> But for this, why not just use the Wiki -- that's what it's for!
>
> >> -Chris
>
> > I think the wiki would be fine too. Just create a new page, link to it
> > from the main page or the Cookbook page and send us the link. We can
> > fix the markup as we go along.
>
> > Alternatively, we might be able to use Google Docs or Zoho...
>
> > -------------------
> > Mike Driscoll
>
> > Blog:  http://blog.pythonlibrary.org

>

[Mike Driscoll]

On Jul 29, 10:30 am, Raoul <raoulpa...@yahoo.com> wrote:
> Sounds good. I know how to create a new page, but how do I "link it to
> the main page" ?
>
> Also, how are graphic images inserted ? Do the files go into a wiki
> repository of some kind ? If so, how are they linked/referred to in
> the wiki page ?
>
> Ray
>

For me, I usually use camelcase. So something like:

NewBoxSizerTutorial

Then you click on that and see that that page doesn't exist yet. So
you create it and you link to it by using that string.

[Robin Dunn]

On 7/29/10 8:30 AM, Raoul wrote:
> Sounds good. I know how to create a new page, but how do I "link it to
> the main page" ?

Please read http://wiki.wxpython.org/HelpForUsers, especially the pages
about page formatting, linking, etc.

>
> Also, how are graphic images inserted ? Do the files go into a wiki
> repository of some kind ? If so, how are they linked/referred to in
> the wiki page ?
>

Upload the image as an attachment to the page, and then refer to it from
the page text with "{{attachment:filename.png}}"

--
Robin Dunn
Software Craftsman
http://wxPython.org

[Raoul]

Thanks, Robin. I think I'm a little too comfortable with "drag-and-
drop", "cut-and-paste" and WYSIWYG when it comes to creating
documentation. I guess I should brush up on the formatting commands in
"Wordstar for DOS".

Do you know when the GUI version of the wiki page creation is due to
come out ? ;-)

Ray

On Jul 29, 12:41 pm, Robin Dunn <ro...@alldunn.com> wrote:
> On 7/29/10 8:30 AM, Raoul wrote:
>
> > Sounds good. I know how to create a new page, but how do I "link it to
> > the main page" ?
>

> Please readhttp://wiki.wxpython.org/HelpForUsers, especially the pages

[Al]

PDF-XChange Viewer works to annotate PDF docs, and it's free and way
better than Adobe Reader.

http://www.tracker-software.com/product/pdf-xchange-viewer

[Raoul]

PDF-XChange Viewer is for Windows, only. My goal is to use a platform-
independent solution.

[Ray Pasco]

> > > > > On Jul 27, 4:31 pm, Mike Driscoll <m...@pythonlibrary.org> wrote:
> > > > > > I can test on Windows XP/7 and Ubuntu. You'll just have to ask on this
> > > > > > thread for a Mac user to jump in. I know a lot of the others use Linux too,
> > > > > > so I'm sure that a few of them wouldn't mind helping, especially since they
> > > > > > won't need to install anything.
> > > > > > - Mike

> > > > Also, I don't see any mention of adding stretchers (AddStretchSpacer).
> > > > I think it's much better to use those than to depend on some other
> > > > control to be adjustable.
> > > Al

> >http://www.tracker-software.com/product/pdf-xchange-viewer

Hi to all Reviewers and readers. Sorry for the long hiatus in
preparing the draft of the new BoxSizer Tutorial wiki page(s). The
first 4 pages are ready for testing and general review. The main page
is:

BoxSizerFromTheGroundUp
http://wiki.wxpython.org/BoxSizerFromTheGroundUp

I am starting a new thread specifically for the purpose of
communication during the review of the wiki pages. Please reply to
this post in that thread: It is titled:

BoxSizerFromTheGroundUp Wiki pages

The first post will be the contents of this post.

Development Status:

The first 4 pages are ready for testing and general review. The first
page is rather long, but I haven't figured out how to break it up and
still show complete demos. It's no wonder that so many people have
difficulty with getting even simple sizing to work as expected with
the BoxSizer being as complicated as it is.

The 5th page is half finished at this point. Writing is going quickly
to my own amazement. I anticipate only one more page unless I've
overlooked some important feature that I'm not aware.

All corrections and suggestions are welcome. Please be constructive
with your comments. Keep in mind that much of the "official" BoxSizer
documentation (not tutorials) seems to be haphazardly thrown together
as afterthoughts. So, I've had to make guesses about some specific
parameters.

---------

I have to say that there needs to be a wiki page on constructing wiki
pages ! The documentation that is there is OK, but there's no guide
concerning "how to get things done" when creating a page. Also, the
documentation clearly states that code blocks will use a monospaced
font. This is clearly wrong and disappointing. The way I tend to write
code is by aligning sequential lines of similar calls with their
parameters aligned by their columns. This style makes it very easy to
identify which parameters have changed and which remain the same. This
appearance is much more difficult using a kerned (variable width)
font. Is this a bug in the configuration of the wiki ? It appears to
be.

Ray Pasco

[Ray Pasco]

> > > > > On Jul 27, 4:31 pm, Mike Driscoll <m...@pythonlibrary.org> wrote:
> > > > > > I can test on Windows XP/7 and Ubuntu. You'll just have to ask on this
> > > > > > thread for a Mac user to jump in. I know a lot of the others use Linux too,
> > > > > > so I'm sure that a few of them wouldn't mind helping, especially since they
> > > > > > won't need to install anything.
> > > > > > - Mike

> > > > Also, I don't see any mention of adding stretchers (AddStretchSpacer).
> > > > I think it's much better to use those than to depend on some other
> > > > control to be adjustable.
> > > Al