Re: [wxPython-users] Why can't we get rid of sizers?
Arnold Chen
I think wxGlade (http://wxglade.sourceforge.net/) should be what you are
looking for. A GUI editor that generate wxPython code.
Arnold
johnf wrote:
> Hi,
>
> I wonder why we need to have sizers? Why can't someone develop a GUI editor
> that automaticly determines what is required to keep the relative proportions
> and positions of widgets on a frame.
>
> Sizers work but they are a pain to work with. Robin spent a whole chapter
> (11) just to explain sizers. So you create a nice looking frame with sizers
> and then someone says "Look's great but could you add these two other
> widgets". It's just a pain to work with. There has to be something better.
>
> Does anyone know of any sort of project trying to get rid of sizers?
>
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-user...@lists.wxwidgets.org
> For additional commands, e-mail: wxPython-...@lists.wxwidgets.org
>
>
>
>
--
Arnold Chen
[ mailto:arn...@design97.com ]
[ tel: +852 9250 0063]
Design 97
[ http://www.design97.com ]
[ tel: +852 2802 8900]
johnf
johnf
John
Michael Hipp
> I wonder why we need to have sizers? Why can't someone develop a GUI editor
> that automaticly determines what is required to keep the relative proportions
> and positions of widgets on a frame.
>
> Sizers work but they are a pain to work with. Robin spent a whole chapter
> (11) just to explain sizers. So you create a nice looking frame with sizers
> and then someone says "Look's great but could you add these two other
> widgets". It's just a pain to work with. There has to be something better.
>
> Does anyone know of any sort of project trying to get rid of sizers?
I agree wholeheartedly with your sentiments. Every encounter with sizers is pure torture for all but the simplest layouts.
But I wouldn't immediately jump to a GUI editor as being the solution as they bring problems of their own. I haven't tried wxGlade as I soured on GUI editors many years ago.
Personally I think a lot of the wxWidgets sizers fall deep into the category of "don't behave as expected" but I've no idea what to do about it.
Best regards,
Michael
Robin Dunn
> Hi,
>
> I wonder why we need to have sizers? Why can't someone develop a GUI editor
> that automaticly determines what is required to keep the relative proportions
> and positions of widgets on a frame.
But what would it do instead of sizers? Absolute positioning and sizing
breaks as soon as you change platforms or even change the default font
size on the same platform, because widget min sizes and such change. So
that leaves doing something dynamic at runtime to manage the layout.
Sure a gui editor could generate code that measures min or best sizes of
widgets, checks rules that contorl expandability of some widgets,
calculates the minimum needs of the container, and then call all of this
code from the container's EVT_SIZE handler. But why bother? Sizers
already do all of that and more, and the gory details are hidden from
the programmer instead of requiring you to deal with pages and pages of
generated code in a EVT_SIZE handler that would have to be duplicated in
any program that uses this approach.
>
> Sizers work but they are a pain to work with. Robin spent a whole chapter
> (11) just to explain sizers. So you create a nice looking frame with sizers
> and then someone says "Look's great but could you add these two other
> widgets". It's just a pain to work with. There has to be something better.
There's the predecessor of the sizers, layout constraints. They're
still in the library although they've been marked for many years in the
docs as deprecated. Personally I think they are much more complex than
sizers, but some people like them. There is also wx.lib.anchors which
is based on layout constraints.
>
> Does anyone know of any sort of project trying to get rid of sizers?
Nope. If you're really interested in doing this I would suggest that as
an exercise you should take a complex layout done with sizers and
convert it to raw code in a EVT_SIZE handler that handles fixed size
items, best or min sized items, and expandable items, along with
borders, alignments, and etc. Then try to think of ways that what you
did by hand could be generalized for nearly any layout requirements.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Marc Hedlund
On Sat, 20 May 2006, Robin Dunn wrote:
>> Does anyone know of any sort of project trying to get rid of sizers?
>
> Nope. If you're really interested in doing this I would suggest that as an
> exercise you should take a complex layout done with sizers and convert it to
> raw code in a EVT_SIZE handler that handles fixed size items, best or min
> sized items, and expandable items, along with borders, alignments, and etc.
> Then try to think of ways that what you did by hand could be generalized for
> nearly any layout requirements.
Or try it in Java. Then you'll love wxPython a lot more than you already
do.
-M
Dave Rose
vertical grid-sizer and right-click, then select Add or Insert (position)
and it'll place another spot for your new widget. Actually, I really enjoy
using wxGlade. It's not perfect, but darned good.
There is a style, however, to using it most effectively. You have to create
your GUI (Save reasonably-regularly incase of a crash) . There are a few
pre-created widget buttons on the tool pallette. One of which is a
custom-widget button.Use this for everything else you'd want, but isn't
defined as a widget-button. Suppose you want to drop in an LED-control.
You'd select Custom Widget button, and in the class name, you'd enter
gizmos.LEDNumberCtrl and for the name, you'd maybe use self.led. That's
give you self.led = gizmos.LEDNumberCtrl(self.panel_liveWindow, -1), wit the
size and location information being automatically entered via the sizer.
You'd have to manually update the generated code with the correct import
line. Also, the generated code can't (really, really shouldn't) be manually
altered. There are REM-med lines like # wxGlade Begin and # wxGlade End
lines meant to show you where to avoid coding, so you can write your code
either above or below those REM lines.
However, I've recently taken to creating all code to a wxGUI.py file, then
sub-classing each class like this:
import wx
import wxGUI
import locale
import wx.lib.printout as printout
FONTSIZE = 10
class SalesTaxReport_Dialog(wxGUI.SalesTaxReport_Dialog):
def __init__(self, *args, **kwds):
self.con = kwds['dbCon'] # I've added a few arguments to
the instantiation of the object, to help configure it.
self.cur = kwds['dbCur'] # Here I just place the
values into a variable, and then delete the index from the dictionary of
arguments.
kwds.__delitem__('dbCon')
kwds.__delitem__('dbCur')
locale.setlocale(locale.LC_ALL, '')
# begin wxGlade: AppFrame.__init__
wxGUI.SalesTaxReport_Dialog.__init__(self, *args, **kwds) #
Rem: Here I call the __init__ of the superclass
# end wxGlade
self.pdata = wx.PrintData()
self.pdata.SetPaperId(wx.PAPER_LETTER)
self.pdata.SetOrientation(wx.PORTRAIT)
self.margins = (wx.Point(15,15), wx.Point(15,15))
So, what I've done is extract all the generated code lines (which are quite
visually 'bloaty') out of sight, and now it's just imported, sub-classed,
and called. I think using wxGlade this way is easy and effective. But I'm
not the savviest nor smartest pythoneer so maybe I'm just doing it the hard
way and now knowing it .....
-Dave
Josiah Carlson
johnf <jfab...@yolo.com> wrote:
> I wonder why we need to have sizers? Why can't someone develop a GUI editor
> that automaticly determines what is required to keep the relative proportions
> and positions of widgets on a frame.
Sizers aren't necessary, but I find them far more convenient than
guessing and checking with a static layout, or even
> Sizers work but they are a pain to work with. Robin spent a whole chapter
> (11) just to explain sizers. So you create a nice looking frame with sizers
> and then someone says "Look's great but could you add these two other
> widgets". It's just a pain to work with. There has to be something better.
self.newc = ...
sizer.Add(self.newc)
Wow, that was a pain. I can't imagine how anyone manages to use sizers
to layout their controls.
In Python 2.5 there will be a method to manage 'contexts' via the 'with'
statement. Using with, you can define context managers to help defining
layout of your controls in a structural manner. Something like the
following perhaps...
with wx.Panel(self, -1) as self.panel:
with my.BoxLayout(self.panel, wx.HORIZONTAL, border=5):
self.b1 = my.Button(self.panel, -1, "click me!")
self.b2 = my.Button(self.panel, -1, "or click me!")
Where my.Layout could be defined as:
layout_stack = []
@context
def BoxLayout(control, which_layout, weight=0, flags=wx.ALL,
border=0, fit=0):
l = wx.BoxSizer(which_layout)
def layout(c):
l.Add(c, weight, flags, border)
try:
try:
yield
except:
pass
else:
if fit:
control.SetSizerAndFit(l)
else:
control.SetSizer(l)
control.SetAutoLayout(1)
finally:
_ = layout_stack.pop()
Where my.Button could be defined as:
def Button(parent, id=-1, text="", ...):
b = wx.Button(...)
layout_stack[-1](b)
return b
- Josiah
Kevin Ollivier
On May 20, 2006, at 12:01 PM, Robin Dunn wrote:
> johnf wrote:
>> Hi,
>> I wonder why we need to have sizers? Why can't someone develop a
>> GUI editor that automaticly determines what is required to keep
>> the relative proportions and positions of widgets on a frame.
>
> But what would it do instead of sizers? Absolute positioning and
> sizing breaks as soon as you change platforms or even change the
> default font size on the same platform, because widget min sizes
> and such change. So that leaves doing something dynamic at runtime
> to manage the layout. Sure a gui editor could generate code that
> measures min or best sizes of widgets, checks rules that contorl
> expandability of some widgets, calculates the minimum needs of the
> container, and then call all of this code from the container's
> EVT_SIZE handler. But why bother? Sizers already do all of that
> and more, and the gory details are hidden from the programmer
> instead of requiring you to deal with pages and pages of generated
> code in a EVT_SIZE handler that would have to be duplicated in any
> program that uses this approach.
Of course I wholeheartedly agree. But he raises an interesting point
in terms of why widgets don't automatically determine the correct
relative proportions and positions. Why shouldn't they? What about,
for common cases, removing the user's need to deal with sizers by
creating one internally? i.e. as he said, why can't widgets have
"default" sizers that just "do the right thing" to maintain the
proportion and position of widgets, in accordance with the platform's
HIGs? Of course, this would always be overrideable by changing the
sizer or the sizer flags, but I can think of a ton of cases in my own
code where I just want to use the platform's defaults/HIGs, and in
fact have to currently write conditional code in order to do that.
If all controls in the hierarchy have default sizers, and they simply
add controls to their sizer when the control is added as a child,
then sizers could become almost transparent to the user, and become
more a property of the control. Controls could simply have a function
such as SetSizer or SetSizerProps(wxSizerFlags&) for any case in
which the user wants to provide custom behavior, and using explicit
sizes turns off the sizer, of course. This approach would also be
backwards compatible because old code would always create and assign
the sizers itself, overriding the defaults. For container controls,
such as wxPanel, we could have a simple default such as a vertical
wxBoxSizer that again just needs to be overridden by the user.
I've had this in my mind for a while, but I was wondering if others
think this sort of system would make sense. Sizers are absolutely
essential for good cross-platform apps, but I think we could actually
internalize the sizer code for 80% of cases, which would not only
simplify things but save users a whole lot of largely tedious sizer
coding, and provide a much more favorable initial impression of
dealing with wxPython.
Regards,
Kevin
>
>> Sizers work but they are a pain to work with. Robin spent a whole
>> chapter (11) just to explain sizers. So you create a nice looking
>> frame with sizers and then someone says "Look's great but could
>> you add these two other widgets". It's just a pain to work
>> with. There has to be something better.
>
> There's the predecessor of the sizers, layout constraints. They're
> still in the library although they've been marked for many years in
> the docs as deprecated. Personally I think they are much more
> complex than sizers, but some people like them. There is also
> wx.lib.anchors which is based on layout constraints.
>
>> Does anyone know of any sort of project trying to get rid of sizers?
>
> Nope. If you're really interested in doing this I would suggest
> that as an exercise you should take a complex layout done with
> sizers and convert it to raw code in a EVT_SIZE handler that
> handles fixed size items, best or min sized items, and expandable
> items, along with borders, alignments, and etc. Then try to think
> of ways that what you did by hand could be generalized for nearly
> any layout requirements.
>
> --
> Robin Dunn
> Software Craftsman
> http://wxPython.org Java give you jitters? Relax with wxPython!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-user...@lists.wxwidgets.org
> For additional commands, e-mail: wxPython-users-
> he...@lists.wxwidgets.org
>
Michael Hipp
> self.newc = ...
> sizer.Add(self.newc)
>
> Wow, that was a pain. I can't imagine how anyone manages to use sizers
> to layout their controls.
Josiah, I hope you intended that playfully. As the level of sarcasm in that jab defies your normal professionalism and helpfulness on this list.
If all anyone ever did was align things in a straight line, then the above then the above would work and this thread wouldn't have come into existence.
But it gets a lot more complicated by just adding labels to those controls.
Then what if you want them in a hierarchy of grids and some to get bigger with resizing and some not. With static boxes around them. With various groupings of various sizes.
Sizers are a pain. They add unbearable clutter to otherwise simple code. And they often simply don't behave as expected.
And this is the worst criticism of all: *There is nothing about them to aid in debugging.* Something not sized right. Why? Which element is causing things to spill off the edge of the screen? Why is one group growing and another is not? Why is some group bigger than it obviously needs to be? No obvious way to find the answers to any of those questions.
End of rant.
(But not end of sizers being a pain. :) )
Michael
Josiah Carlson
"Michael Hipp" <mic...@hipp.com> wrote:
>
> > From: "Josiah Carlson" <jcar...@uci.edu>
>
> > self.newc = ...
> > sizer.Add(self.newc)
> >
> > Wow, that was a pain. I can't imagine how anyone manages to use sizers
> > to layout their controls.
>
> Josiah, I hope you intended that playfully. As the level of sarcasm in
> that jab defies your normal professionalism and helpfulness on this
> list.
Indeed, I forgot the emoticon. I also forgot to finish the sentence in
a previous paragraph.
> If all anyone ever did was align things in a straight line, then the
> above then the above would work and this thread wouldn't have come into
> existence.
What I was trying to say is that simple layouts are simple to do. But
complicated layouts are going to be complicated, I believe, regardless
of the tools one attempts to use to attack the situation. Right now,
you need to state how you want items to be laid out via sizers. But
once you've done that, you are done.
I understand that debugging layout can be a pain; I've spent uncountable
hours hacking away just to try to get layouts *just right*. Other users
have pointed out GUI designers that attempt to make such laying out
better, easier, whatever.
I have personally found that once I know what I want it to look like
(which is hard to figure that out without trying it, using paper cutouts,
etc.), actually laying it out isn't that bad (of course I also find that
BoxSizers are sufficient for 99.9% of the stuff I do).
> But it gets a lot more complicated by just adding labels to those
> controls.
>
> Then what if you want them in a hierarchy of grids and some to get
> bigger with resizing and some not. With static boxes around them. With
> various groupings of various sizes.
>
> Sizers are a pain. They add unbearable clutter to otherwise simple
> code. And they often simply don't behave as expected.
>
> And this is the worst criticism of all: *There is nothing about them
> to aid in debugging.* Something not sized right. Why? Which element is
> causing things to spill off the edge of the screen? Why is one group
> growing and another is not? Why is some group bigger than it obviously
> needs to be? No obvious way to find the answers to any of those
> questions.
From what I remember, there is supposed to be a keyboard hotkey to
highlight sizer regions in wxPython 2.7 . I also described a method
using the Python 2.5 with statements along with some sample context
managers for handling layout, etc. Neither are a panacea, but both
could help people with GUI layout.
- Josiah
johnf
done about it. I think your ideas have merit. But I doubt anything will be
done.
I was thinking of an editor that could inspect the frame run some sort of
routine to add sizers (based on vbox and hbox). Anyway, just a drag and
drop, adjust and then process. The generated code would include the sizers.
Then we could sub-class the generated code. If a change was required just do
it again.
John
Michael Hipp
> I understand that debugging layout can be a pain; I've spent uncountable
> hours hacking away just to try to get layouts *just right*. Other users
> have pointed out GUI designers that attempt to make such laying out
> better, easier, whatever.
>
> I have personally found that once I know what I want it to look like
> (which is hard to figure that out without trying it, using paper cutouts,
> etc.), actually laying it out isn't that bad (of course I also find that
> BoxSizers are sufficient for 99.9% of the stuff I do).
It is a rare blessed occasion when I am able to make do with a simple box sizer. You are the envy of my life :)
This whole subject is a bit of a sore spot right now. I just finished the layout of a panel with some 43 controls on it grouped by 8 static boxes. i have easily 2 full working days into getting it to layout correctly. Sizers inside of sizers inside of sizers. And I cringe at the thought of ever having to modify that code. (I think I'd sooner tackle some Z80 code I wrote 20 years ago than modify that panel.)
Yes, I know 43 controls on one panel is excessive. Boy, do I know it. But I'm trying to give the client what she wants and that's how she wants it. Mine is not to question why.
I haven't looked at any of the code underlying the wx sizers, but I'm convinced there is a wrong algorithm somewhere. If I could just command all my sizers to "Don't grow any bigger than you must, except to fill in extra space only as needed" then all would be well. The sizers seem to have a philosphy of grow, grow, and then just grow some more for good measure.
Anyway, ranting never got any code written...
Michael
Horst Herb
> Everyone agrees that sizers are pain in (you know where).
Well, I don't.
I have been programming GUIs for more than 20 years - including writing event
driven GUI systems from scratch in Pascal and C at a time when Windows 2.0
was only a vague announcement - and I find sizers are the greatest thing
since sliced bread. I cannot think of any way making flexible layout even
simpler.
People disliking sizers have probably not grokked the concept behind them - I
found that especially people used to statically positioned point-and-click UI
generators simply can't dislodge their minds from the statical paradigm.
I found that the syntax of Tk sizers is perhaps a bit easier to understand -
maybe thosehaving difficulties with Python should play a bit interactively
with Tk in order to "get it"
Horst
Christian Kristukat
never liked using gui builders which output python code. Xrc on the other hand
is very easy to use and does not interfere with your code. Having changed to a
xrc based gui the amount of time I had to spend on understanding why some parts
of my gui weren't resizing as expected reduced to 20% and of course the code got
much shorter.
Christian
Grant Edwards
[...]
> I haven't looked at any of the code underlying the wx sizers,
> but I'm convinced there is a wrong algorithm somewhere. If I
> could just command all my sizers to "Don't grow any bigger
> than you must, except to fill in extra space only as needed"
> then all would be well. The sizers seem to have a philosphy of
> grow, grow, and then just grow some more for good measure.
>
> Anyway, ranting never got any code written...
I know how you feel. I've been using sizers for several years
now, and I still spend a lot of time doing things by
trial-and-error. I've read the all of the documentaiton and
tutorials I can find, but I'm still regularly baffled. I'd
guess that about half of the times when I make a change
involving a sizer, it doesn't to what I think it's going to do.
--
Grant
johnf
> On 5/20/06, johnf <jfab...@yolo.com> wrote:
> > I wonder why we need to have sizers? Why can't someone develop a GUI
> > editor that automaticly determines what is required to keep the relative
> > proportions and positions of widgets on a frame.
>
> and this requires developers to make an effort, rather than make users
> work harder.
>
> Have looked at Dabo? They have embraced a sizer-centric approach in
> their development tools. I resisted it at first, since it seemed too
> confusing. But since I've been able to grok sizers, it seems like
> these guys really have insight into the way to develop apps that are
> cross-platform without having to hack things for each platform.
>
> I love wxPython and all it offers, but once I got hooked on Dabo's ui
> module, I can't go back. Yes, there is a learning curve, but isn't
> that true of any worthwhile tool? If you haven't seen Dabo, you should
> really take a look at it: http://dabodev.com.
Actually dabo is what started me thinking about what might be done to solve
the sizer issue. Ed and Paul have done a very good job. But they have only
gone halfway. They have made it easier but not easy. Ed and Paul came from
the VFP (visual foxpro) world and realize the ease that VFP programmers setup
frames (windows). Changes can be made in seconds vs hours (at least that's
what happens to me). But VFP forms lack re-sizing - controls have fixed
positions. I want to be able to create GUI's short periods of time and be
able add or subtract easily.
John
John Jackson
In Robin's book on wxPython there is a diagram (Figure 6.7) that
shows the relationship between box sizers, flags and factors and the
resize behavior. I've cut out a copy of it and put in on my desk. It
keeps me straight, and I've had far fewer problems sorting out sizer
issues after looking at that diagram.
</end plug>
But if we really want to "get rid of sizers," the best solution I
have ever worked with for GUI building has been Apple's Interface
Builder. If you aren't familiar with it but have access to a Mac with
the developer tools on it, you should look at it if you are
interested in what a polished interface builder can look like.
It uses something akin to layout constraints to do the sizing, and I
find them straight forward. You can immediately toggle into a running
application mode, and test your layout. All the controls are
available on inspectors for addition to your window / panel / menu.
There is automatic interface guidelines displayed so that you can
line up objects in a consistent fashion. It makes the design of
interfaces a pleasure. It's the one thing I miss about not working in
Cocoa.
I have thought about how great it would be to have an application as
slick as Interface Builder for wxPython.
______________
John Jackson
David Hughes
My current project contains over 75 layouts but I haven't written any sizer code for years - life's too short! ;-)
Regards
David Hughes
[1] It is also sold as a more comprehensive RAD tool but I only use it as a layout designer
Eli Golovinsky
> It is a rare blessed occasion when I am able to make do with a simple box sizer. You are the envy of my life :)
>
> This whole subject is a bit of a sore spot right now. I just finished the layout of a panel with some 43 controls on it grouped by 8 static boxes. i have easily 2 full working days into getting it to layout correctly. Sizers inside of sizers inside of sizers. And I cringe at the thought of ever having to modify that code. (I think I'd sooner tackle some Z80 code I wrote 20 years ago than modify that panel.)
>
Maybe I'm missing something, but I really don't understand the merit of
writing layouts using bare code. An imperative language is not a very
good way to describe UI design. I've been working with complex design
with lots of controls and I've been doing it with XRCed for quite a
while now. It takes a sort of middle road between coding the layouts
manually and using a UI designer, and because it doesn't mess with the
XRC format too much you can even tweak it manually. I still use bare
code for some very dynamic UI's (etc. when the number of controls is
determined at runtime), but I still usually design the basic layout in
XRC and leave an empty panel to fill with code-created controls later.
I've had some experience with VB, .NET and Java, and the wx combined
with XRCed is just simpler, faster and more maintainable.
Robin and me have also recently added some code to XRCed that
auto-generates the slightly ugly code that loads the XRC file and
creates the objects.
You really should try it.
Having said that, I really do think there are times when absolute
positioning is better. One occasion I felt it would help me a lot was
when I was building a skinned UI. I needed to position the control just
so and it wasn't very convenient using sizers and spacers. Being a
strong proponent of XRC, I would think that this is something that
should be added to the format (and to XRCed). I could hack something up
if there is some interest in this.
Karsten Hilbert
> This whole subject is a bit of a sore spot right now. I
> just finished the layout of a panel with some 43 controls on
> it grouped by 8 static boxes. i have easily 2 full working
> days into getting it to layout correctly. Sizers inside of
> sizers inside of sizers.
Maybe I am naive but I won't be scared from the outset
attempting same with the help of wxGlade.
I usually don't like generated code too much but in the case
of wxGlade I have given in due to it's obvious (tested) ease
of use over what I was doing manually before.
I learned that it helps to name sizers usefully, eg
self.__szr_top_left_inner_btns = wx.*Sizer*(...)
I only wish wxGlade let me specify import lines from
within its user interface.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Karsten Hilbert
On Sun, May 21, 2006 at 12:53:40PM +0200, Karsten Hilbert wrote:
> I learned that it helps to name sizers usefully, eg
>
> self.__szr_top_left_inner_btns = wx.*Sizer*(...)
Obviously a contrived and exaggerated example.
John Lockett
>
> Robin and me have also recently added some code to XRCed that
> auto-generates the slightly ugly code that loads the XRC file and
> creates the objects.
>
> You really should try it.
Where will I find this auto-generating code please? I'm using version
0.1.7-3
John
Peter Decker
> I wonder why we need to have sizers? Why can't someone develop a GUI editor
> that automaticly determines what is required to keep the relative proportions
> and positions of widgets on a frame.
Sizers are wonderful, IMO. The goal is to create rich applications,
and this requires developers to make an effort, rather than make users
work harder.
Have looked at Dabo? They have embraced a sizer-centric approach in
their development tools. I resisted it at first, since it seemed too
confusing. But since I've been able to grok sizers, it seems like
these guys really have insight into the way to develop apps that are
cross-platform without having to hack things for each platform.
I love wxPython and all it offers, but once I got hooked on Dabo's ui
module, I can't go back. Yes, there is a learning curve, but isn't
that true of any worthwhile tool? If you haven't seen Dabo, you should
really take a look at it: http://dabodev.com.
--
# p.d.
Michael Hipp
> Michael Hipp wrote:
>
> > This whole subject is a bit of a sore spot right now. I just finished the
> > layout of a panel with some 43 controls on it grouped by 8 static boxes. i
> > have easily 2 full working days into getting it to layout correctly.
> > ever having to modify that code. (I think I'd sooner tackle some Z80 code
> > I wrote 20 years ago than modify that panel.)
>
> Maybe I'm missing something, but I really don't understand the merit of
> writing layouts using bare code. An imperative language is not a very good
> way to describe UI design. I've been working with complex design with lots
> of controls and I've been doing it with XRCed for quite a while now. It
> takes a sort of middle road between coding the layouts manually and using a
> UI designer, and because it doesn't mess with the XRC format too much you
> can even tweak it manually. I still use bare code for some very dynamic UI's
> (etc. when the number of controls is determined at runtime), but I still
> usually design the basic layout in XRC and leave an empty panel to fill with
> code-created controls later.
>
> I've had some experience with VB, .NET and Java, and the wx combined with
> XRCed is just simpler, faster and more maintainable.
> the slightly ugly code that loads the XRC file and creates the objects.
>
> You really should try it.
Thanks. I will indeed look into XRC. I haven't in the past because I worried about overhead/inefficiency and issues like repeatability and flexibility. Plus I find XML about as easy to read as C++. But I can certainly get over it if the payoff is big enough.
Thanks,
Michael
Robin Dunn
> From what I remember, there is supposed to be a keyboard hotkey to
> highlight sizer regions in wxPython 2.7 .
It's what somebody here dubbed the "four finger salute,"
Ctrl-Alt-Shift-middleclick
Uwe C. Schroeder
> On Saturday 20 May 2006 16:55, Horst Herb wrote:
> > People disliking sizers have probably not grokked the concept behind them
> > - I found that especially people used to statically positioned
> > point-and-click UI generators simply can't dislodge their minds from the
> > statical paradigm.
>
> mostly to do with having to make changes after laying out a large number of
> controls. In fact I really try to stay away from grid sizers because it is
> easier to control layout with boxers. It could be that I'm not as smart as
> others but I find it a pain compared to point and shoot. Yes, I was hand
> coding for the most part. When I tried Glade and others I had a harder
> time (until ClassDesigner.py in dabo) making changes. I haven't tried
> wxDesigner nor have I worked with the Apple development packages. But they
> sound like what I think can be done - point and shoot along with re-sizing.
I use wxDesigner together with XRC. Makes changes very simple to deal with.
UC
--
Open Source Solutions 4U, LLC 1618 Kelly St
Phone: +1 707 568 3056 Santa Rosa, CA 95401
Cell: +1 650 302 2405 United States
Fax: +1 707 568 6416
Robert Gravina
For an application I'm working on at the moment, many forms are of
the data entry kind - they allow the user to add a new object of some
kind, and later edit this object. Usually there is some kind of
parent class, and it's attributes are a mixture of basic types and
other objects, lists of other objects etc.
I've found from my experience many apps have these kinds of forms.
Web-based apps (like say Zope/Plone Archetypes-based apps) often make
it very easy to auto-generate web-based UI's from descriptions of the
fields you want to edit, but I can't find anything like this for
wxPython.
Is there anything like this out there for wxPython?
Anyhow, I've so far developed code (based on the Model-View-Presenter
pattern described here: <http://wiki.wxpython.org/index.cgi/
ModelViewPresenter>) that makes it relatively easy to make simple
data entry forms like the screenshot attached, provided you don't
mind sticking to a simple two-column layout.
The basic concept is of a panel that contains a listbox, two +/-
buttons to add/remove entries and controls off to the right that
contains a control for editing each field of an object (string fields
get textboxes, integers get sliders etc.). The form takes a
dictionary of columns to display in a listbox, attribute names and
types and builds a form from it. In the example screenshot I've
attached I passed form (the View) a dictionary like this (from the
Presenter):
{"columns":("name",),
"attributes":("name", "description", "items"),
"types":(types.StringType, types.StringType,
types.ListType)}
Other work is done by the Presenter, Interactor and Model to update
the model as the data in the edit boxes changes and update the fields
in the list as you edit the text in the text boxes etc.
I'd be interested in sharing this so we could all benefit from it.
Creating a complete framework that can work with various kinds of
controls and data types on the Model object, support various layouts
etc. might take some work, so it might be worth open sourcing, and
I'd be happy to do that. At the moment the code is very rusty (and
not very long neither), and really nothing special, but if anyone
would like to see it I would be happy to post it to the list.
I'd just like to know if this is really novel enough to warrant
sharing. I'm admittedly a Python/wxPython beginner so what I'm
creating here is probably not all that special.
Robert
Robin Dunn
> Having said that, I really do think there are times when absolute
> positioning is better. One occasion I felt it would help me a lot was
> when I was building a skinned UI. I needed to position the control just
> so and it wasn't very convenient using sizers and spacers. Being a
> strong proponent of XRC, I would think that this is something that
> should be added to the format (and to XRCed).
XRC and XRCed already support absolute positioning and sizing. Although
it is definitly *not* XRCed's strong point to edit layouts this way, it
is possible.
<?xml version="1.0" encoding="utf-8"?>
<resource>
<object class="wxFrame" name="FRAME1">
<title>Look Ma, no sizers!</title>
<object class="wxPanel">
<object class="wxStaticText">
<label>Name:</label>
<pos>10,10</pos>
</object>
<object class="wxTextCtrl">
<pos>60, 8</pos>
<size>150,-1</size>
</object>
<object class="wxStaticText">
<label>email: </label>
<pos>10,40</pos>
</object>
<object class="wxTextCtrl">
<pos>60,38</pos>
<size>150,-1</size>
</object>
<object class="wxStaticLine">
<pos>0, 75</pos>
<size>300,-1</size>
</object>
<object class="wxButton" name="wxID_OK">
<label></label>
<pos>20, 90</pos>
</object>
<object class="wxButton" name="wxID_CANCEL">
<label></label>
<pos>120,90</pos>
</object>
<size>300,200</size>
</object>
<size>300,200</size>
</object>
</resource>
Robin Dunn
It's only in CVS at the moment. You can get just the code generating
tool from here:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/wx/tools/pywxrc.py
And the XRCed code that has been enhanced to use pywxrc.py is here:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/wx/tools/XRCed/
johnf
> I found that especially people used to statically positioned
> point-and-click UI generators simply can't dislodge their minds from the
> statical paradigm.
That's not accurate in my case. I think I understand sizers. My issue has
mostly to do with having to make changes after laying out a large number of
controls. In fact I really try to stay away from grid sizers because it is
easier to control layout with boxers. It could be that I'm not as smart as
others but I find it a pain compared to point and shoot. Yes, I was hand
coding for the most part. When I tried Glade and others I had a harder time
(until ClassDesigner.py in dabo) making changes. I haven't tried wxDesigner
nor have I worked with the Apple development packages. But they sound like
what I think can be done - point and shoot along with re-sizing.
John
Jürgen Kareta
I think the concept of sizers is really great and usefull. But I also
often need a lot of time to get my UI's working as expected.
For me the main point is my impossibility to introspect it. If I get
some unexpected behavior I often try to solve it by 'try and error' or
in case of fail try to ask the list.
If I can find a way to introspect the behavior in a better way than
adding many 'print sizer.GetSize()' methods, the problem should be
solved. While I found the chapter about the event handling in 'wxpython
in action' really helpfull, I miss something similiar for the sizer and
they behavior.
I don't know if it is necessary to add some new functionalty to the
sizer for doing better introspection. But in any case it would be really
helpful for me, if one of the experts can provide a 'how-to' which
explains how to go on in case of unexpected behavior.
regards,
Jürgen
Robert Gravina
On 2006/05/22, at 11:35, Peter Decker wrote:
> On 5/21/06, Robert Gravina <rob...@gravina.com> wrote:
>
>> I've found from my experience many apps have these kinds of forms.
>> Web-based apps (like say Zope/Plone Archetypes-based apps) often make
>> it very easy to auto-generate web-based UI's from descriptions of the
>> fields you want to edit, but I can't find anything like this for
>> wxPython.
>>
>> Is there anything like this out there for wxPython?
>
> Have you looked at Dabo? Their AppWizard makes query/update
> applications for databases in about a minute, and they have lots of
> pre-defined UI controls and dialogs that make coding in wxPython so
> much easier than plain raw wxPython.
>
I have had a quick look at it, but I get the impression it's designed
for working with relational databases. I'm writing an application
that uses the Twisted networking framework and a ZODB... I have no
idea how this would work with something like Dabo.
>> Anyhow, I've so far developed code (based on the Model-View-Presenter
>> pattern described here: <http://wiki.wxpython.org/index.cgi/
>> ModelViewPresenter>) that makes it relatively easy to make simple
>> data entry forms like the screenshot attached, provided you don't
>> mind sticking to a simple two-column layout.
> [snip]
>> I'd just like to know if this is really novel enough to warrant
>> sharing. I'm admittedly a Python/wxPython beginner so what I'm
>> creating here is probably not all that special.
>
> It isn't that it isn't special, it's just that you are probably
> spending time re-creating things that have already been done in Dabo.
> I thought that I had done some cool things in wxPython, and then I saw
> that these were trivial using the dabo.ui.
>
Can the dabo.ui be used outside of a Dabo application?
Anyway, I have attached a small sample application called Pet Manager
that lets you maintain a list of dogs (run it from the command line
as "python petmanager.py", or "pythonw petmanager.py" for Mac) . The
framework code, of about 550 lines, is in databoundframe.py while the
small sample app is about 150 lines.
My framework code is very un-Pythonic, so if anyone would like to
suggest how I might use dictionaries or some other Python type to
replace the big if-then-else statements I have for determining which
bit of code to run based on the control type (e.g. see
DataBoundPanelPresenter class, updateModelFromView and
updateViewFromModel methods), I'd greatly appreciate it!
Also, being based on the Model-View-Presenter pattern it's a bit hard
to understand without looking at that first (see wxPython wiki here:
<http://wiki.wxpython.org/index.cgi/ModelViewPresenter>). If anyone
has used MVP can can spot obvious problems with my code please let me
know (for example, it's very long! Sometimes I feel like ditching
this whole MVP thing altogether but then again this is a much better
solution than huge, unmaintainable, GUI forms).
If there is a way I could achieve something similar with Dabo I would
be happy to throw this out and switch. If people think this code has
merit I'll try and clean it up and post again as it evolves.
Robert
Peter Decker
> I've found from my experience many apps have these kinds of forms.
> Web-based apps (like say Zope/Plone Archetypes-based apps) often make
> it very easy to auto-generate web-based UI's from descriptions of the
> fields you want to edit, but I can't find anything like this for
> wxPython.
>
> Is there anything like this out there for wxPython?
Have you looked at Dabo? Their AppWizard makes query/update
applications for databases in about a minute, and they have lots of
pre-defined UI controls and dialogs that make coding in wxPython so
much easier than plain raw wxPython.
> Anyhow, I've so far developed code (based on the Model-View-Presenter
> pattern described here: <http://wiki.wxpython.org/index.cgi/
> ModelViewPresenter>) that makes it relatively easy to make simple
> data entry forms like the screenshot attached, provided you don't
> mind sticking to a simple two-column layout.
[snip]
> I'd just like to know if this is really novel enough to warrant
> sharing. I'm admittedly a Python/wxPython beginner so what I'm
> creating here is probably not all that special.
It isn't that it isn't special, it's just that you are probably
spending time re-creating things that have already been done in Dabo.
I thought that I had done some cool things in wxPython, and then I saw
that these were trivial using the dabo.ui.
--
# p.d.
Eli Golovinsky
>
>> Having said that, I really do think there are times when absolute
>> positioning is better. One occasion I felt it would help me a lot was
>> when I was building a skinned UI. I needed to position the control
>> just so and it wasn't very convenient using sizers and spacers. Being
>> a strong proponent of XRC, I would think that this is something that
>> should be added to the format (and to XRCed).
>
> XRC and XRCed already support absolute positioning and sizing.
> Although it is definitly *not* XRCed's strong point to edit layouts
> this way, it is possible.
What I meant was exactly that - XRCed should probably be able to work
better with absolute positioning, but I think that would require a
serious redo of XRCed.
Tim Roberts
>
>I wonder why we need to have sizers? Why can't someone develop a GUI editor
>that automaticly determines what is required to keep the relative proportions
>and positions of widgets on a frame.
>
>
Why? Because there is no one-size-fits-all definition of what "keeping
the relative proportions and positions" means. If the user shrinks the
dialog, do you also shrink the buttons? Minimum button sizes are
specified in the Windows User Interface standard, as well as many
corporate UI standards. What if there is a logo bitmap that can't be
shrunk or stretched? What if shrinking requires a font to go below 6
points? What if you have one panel displaying a picture, and you want
that panel to grow but not the rest?
I worked a long time creating a pleasing layout for my dialog, and got
the corporate usability committee to sign off on it. The dialog looks
stupid if it is shrunk 50%, and it looks silly if it just grows 200%. I
need finer control.
>Sizers work but they are a pain to work with. Robin spent a whole chapter
>(11) just to explain sizers. So you create a nice looking frame with sizers
>and then someone says "Look's great but could you add these two other
>widgets". It's just a pain to work with. There has to be something better.
>
>
Nope, there isn't. Not in my experience.
>Does anyone know of any sort of project trying to get rid of sizers?
>
Sure. Have you ever programmed a Win32 GUI in straight C++? You have
no sizers, and no automatic adjustments at all. It is an enormous pain
in the rear to try to do the Right Thing when a dialog resizes, or when
the dialog is run on a system with a different native font size.
Sizers are the worst possible UI solution, except for all of the others.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Don Dwiggins
>
> Sizers are the worst possible UI solution, except for all of the others.
>
This comment is spot on the mark, and a good hook for my own contribution.
Like Eli and others, I've largely, but not completely, tamed the sizer
monster by using XRCed. The major factors that make it a good 'sizer
tamer' (for me, at least:
- The declarative nature of XRC;
- Ability to work with XRC without needing to even look at the XML;
- A tight interactive build-try cycle;
- The WYSIWYG experience -- you don't progam your GUI, you construct it.
That said, I've had more experiences than I'd like of wrestling with
sizers, both within XRCed and my own code ("why doesn't the
fershlugginer frame resize when I set the control's size and call
frame.Fit?"). Part of this is the less-than-intuitive combination of
flags and settings to express what I want (maybe I should break down and
buy a copy of The Book, especially for the table that someone mentioned
on this thread). Another part is the occasionally unintuitive way they
operate (whether by design or "unintended features").
As a casual suggestion, how about creating a page on the Wiki for
collaborative authoring of a requirements and high-level design document
for "next generation sizers"? Someone recommended the Mac GUI Builder's
approach to layout -- maybe that could be one source of inspiration.
Actually, "next generation" may be too grandiose for what I have in
mind. I'm really thinking more of a series of incremental improvements,
driven by the ideas of the community (with each increment able to be
implemented in a modest amount of time).
--
Don Dwiggins
Advanced Publishing Technology
johnf
What would be the first step? Although I think the goal would be to make GUI
programming easier what is the overall plan?
John
johnf
I liked what you had to say you are very practical. Yes I have worked with
Windows and fixed positions - in fact daily. All I'm saying is we need a
better way. I'm being told that apple has some of these issues solved. If
that is true (I don't have access to an apple development system) then why
not wxPython? You suggest that there is no better solution. You maybe
right! Does that mean we can't invent one? It was just a few years ago that
GUI API's were dreams. Now we have QT and Wxwidgets. What if you had a
template that described how to resize. Maybe it could be based on what your
corporate standard required. Would that be easier than worrying what happens
in resizing events? The GUI API's can handle the fonts and languages (not
perfect but better than in the past) why not resizing? I don't have the
answers. But it seems silly to keep working with sizers when we are no
longer limited by CPU power or Graphic power.
John
Peter Decker
> I have had a quick look at it, but I get the impression it's designed
> for working with relational databases. I'm writing an application
> that uses the Twisted networking framework and a ZODB... I have no
> idea how this would work with something like Dabo.
That I couldn't say. I don't work with database apps, so I have no
idea what it would take to make it work with your setup.
> Can the dabo.ui be used outside of a Dabo application?
Sure! I use it all the time. Even if you don't use all of the three
tiers of the framework, the headaches avoided by not having to look at
all the ugly raw wxPython code and by being able to approach the UI
Pythonically makes using dabo.ui a no-brainer!
--
# p.d.
Christopher Barker
>> Everyone agrees that sizers are pain in (you know where).
> Well, I don't.
Me neither. I love them!
> People disliking sizers have probably not grokked the concept behind
> them -
I agree, they do take a while to wrap your brain around, but they are
wonderful, and I know spend little time fighting with them.
I do think the syntax could be better, and a better way to visualize
what you're doing also helps.
Also, just like code: start small and modularize your code! I've seen
people post to this list with 20 widgets all layout out and the whole
thing is a mess. If you group them and make sure each grouping works
before you put them together, it'll be much easier to do.
Also create custom classes to group your controls. Chances are you can
come up with a better structure if you have 20 controls all laid out in
one class.
Kevin O: I am curious about your ideas, but I don't see how it could
work, at all! I suppose using the HIG for standard spacing between
widgets could be done, but other than that I don't see how there is
anything at all standard about how widgets are arranged in any GUI: it
totally depends on how they are being used. You have to specify the
layout somehow!
> I found that the syntax of Tk sizers is perhaps a bit easier to
> understand -
I hated them! "pack" is easy, until you do something complex, and then
you're nesting frames all over the place: worse than sizers!
Michael Hipp wrote:
> I just finished the layout of a panel with some 43 controls on it
> grouped by 8 static boxes.
How it the world could you imagine making than easier? And this sounds
like exactly what I'm talking about above -- break it down into smaller
pieces!
> Yes, I know 43 controls on one panel is excessive. Boy, do I know it.
> But I'm trying to give the client what she wants and that's how she
> wants it. Mine is not to question why.
No, but yours is to write the code cleanly. Just because your client
wants to see all those controls at once doesn't mean you have to put
them all in one Panel. that could be ten Panels: it would look the same.
And I think yours might be to point out usability issues as well!
> The sizers seem to have a philosphy of grow, grow, and then just grow
> some more for good measure.
I've never had that problem. There is something tricky going on there,
that you must have missed. I do think you'd find it easier if you did
things in smaller pieces, though.
Eli Golovinsky wrote:
> Maybe I'm missing something, but I really don't understand the merit of
> writing layouts using bare code.
http://www.hacknot.info/hacknot/action/showEntry?eid=76
Primarily, the biggest Issue I have with GUI-builders is that all of the
ones I have seen discourage using custom controls. I strongly believe
that grouping controls into app-specific custom controls is a very god idea.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Josiah Carlson
"Michael Hipp" <mic...@hipp.com> wrote:
> From: "Eli Golovinsky" <go...@tuzig.com>
> > You really should try it.
>
> Thanks. I will indeed look into XRC. I haven't in the past because I
> worried about overhead/inefficiency and issues like repeatability and
> flexibility. Plus I find XML about as easy to read as C++. But I can
> certainly get over it if the payoff is big enough.
Based on the comments of others, I also took a look at the XRCed from
CVS. Wow. It took me 5 minutes to layout basically anything I wanted
to. Very nice. I don't know if I'm going to end up using it for other
GUI tasks, but it does work quite well.
- Josiah
Peter Decker
> I'm being told that apple has some of these issues solved. If
> that is true (I don't have access to an apple development system) then why
> not wxPython?
I've played with Apple's Interface Builder, and while they do have an
elegant approach to visually specifying layout constraints, it
certainly isn't any simpler than using sizers in wxPython, just
different. You still have to specify everything, so I think it is not
accurate to claim that they've solved anything; they've just come up
with a solution that has the same number of features and problems as
sizers - they're just different features and problems.
--
# p.d.
Kevin Ollivier
On May 22, 2006, at 12:05 PM, Christopher Barker wrote:
[snip]
> Kevin O: I am curious about your ideas, but I don't see how it could
> work, at all! I suppose using the HIG for standard spacing between
> widgets could be done, but other than that I don't see how there is
> anything at all standard about how widgets are arranged in any GUI: it
> totally depends on how they are being used. You have to specify the
> layout somehow!
I think I probably didn't explain myself well. I'm trying to tackle
two problems:
1) Creating HIG compliant apps with proper borders/padding is
currently a pain (you have to read the HIGs yourself and then code
your sizers accordingly), and
2) Using sizers in visual GUI builders is rather awkward, and it may
even be true to say the current implementation limits how close to
RAD a wxPython GUI builder can get.
I think the reason default sizers solves problem #1 is pretty
obvious, and doesn't need further explanation. :-) (And I think for
this feature alone it makes sense to have a default sizer for native
OS controls.) But how does it address problem #2?
Take a look at Interface Builder (IB). It allows for sizer-like
control (although perhaps it's a bit closer to layout
constraints...), but in IB the 'sizers' are not something you need to
create yourself - by default you can just drag and drop elements into
a window. You can't do that with wxPython GUI builders when using
sizers, because you need to give that window a sizer first before you
can add the control. In other words, for wxPython, creating a sizer
to hold controls is always step one in GUI building, not "adding
controls", which is step one in other editors.
Some people say that's because those other editors don't use sizers,
but they do have layout and alignment tools, so I don't think that's
entirely true. I think the reason is that, in other GUI builders,
e.g. Interface Builder, Qt Designer, etc. layout and sizing are
*properties* of the control, not something totally separate from the
control. So when you move the control around, in a way you're
adjusting its (and/or its parent's) 'sizer' dynamically. (e.g.
adjusting left and top padding) wxPython GUI builders could probably
be designed to do this, except for one problem - by default, a
control doesn't have a sizer, so obviously it can't be adjusted until
it's created.
Therefore, to me it's not a matter of whether or not the default
sizer will work in most cases - what I care about is that
manipulating sizers within GUI builders becomes easier to do so we
can get closer to RAD GUI building. By making controls always have a
sizer, we can internalize some sizer code, e.g. adding controls to
their parents' sizer, into wx itself meaning that users and GUI
builders automatically get this behavior 'for free'. Once that is
done, we can remove the need to have sizers as separate entities in
the layout hierarchy. Sizers are now simply part of the control, and
can be adjusted in the exact same manner as you'd adjust, for
example, the control's default text value. So when you're writing
your wx app in your GUI builder, and a vertical box sizer doesn't cut
it anymore, go into the parent's properties and change it to a grid
sizer and watch the new layout appear in front of you. Don't like
that? Adjust it's properties, or maybe try a flex grid sizer.
A nice side-benefit for users who code their GUIs by hand is that
much of the tedious coding is gone - now you just code changes to the
defaults, rather than write code to set the (often largely redundant)
flags for, and add, every control to a sizer. All you need to do now
is add the control as usual, and change any control sizer properties
you want to change.
Hopefully this clarifies things some. Maybe I'm off-base here but it
seems to me this is the underlying issue as to why wxPython GUI
builders typically have problems working like more RAD-style GUI
builders such as Interface Builder.
Thanks,
Kevin
Don Dwiggins
>> As a casual suggestion, how about creating a page on the Wiki for
>> collaborative authoring of a requirements and high-level design document
>> for "next generation sizers"? Someone recommended the Mac GUI Builder's
>> approach to layout -- maybe that could be one source of inspiration.
>> Actually, "next generation" may be too grandiose for what I have in
>> mind. I'm really thinking more of a series of incremental improvements,
>> driven by the ideas of the community (with each increment able to be
>> implemented in a modest amount of time).
>
> What would be the first step? Although I think the goal would be to make GUI
> programming easier what is the overall plan?
I think an overall plan will have to emerge. As a first step, consider
the little (and not-so-little) combinations of things that you have to
do over and over today. What would be a good way of encapsulating them
into single operations? (Macros, templates, ???) A particularly simple
example is the (label, control) pair that occurs over and over.
Don Dwiggins
> Take a look at Interface Builder (IB). It allows for sizer-like control
> (although perhaps it's a bit closer to layout constraints...), but in IB
> the 'sizers' are not something you need to create yourself - by default
> you can just drag and drop elements into a window. You can't do that
> with wxPython GUI builders when using sizers, because you need to give
> that window a sizer first before you can add the control.
Well, I've occasionally done it controls first with XRCed: add a bunch
of controls, then: add a sizer, cut'n'paste a few controls into it,
iterate as needed (XRCed has execellent support for cut'n'paste). I've
mostly done that when I'm in "visual brainstorming" mode; if I have a
clear idea of how it should look, I'll usually build it top-down. Dunno
how that might go in other builders.
Come to think of it, a nice extension to XRCed might be the ability to
select a group of controls/containers and say "wrap these in a sizer of
this kind".
> I think the reason is that, in other GUI builders, e.g.
> Interface Builder, Qt Designer, etc. layout and sizing are *properties*
> of the control, not something totally separate from the control.
Seems to me there's a potential problem with that approach: sizing is
generally not an operation on an individual control, but on a set of
them (possibly the whole frame). It could be awkward to try to specify
a multi-control layout when you're restricted to operations on one
control at a time. I might be missing something, though.
>
> what I care about is that manipulating sizers
> within GUI builders becomes easier to do so we can get closer to RAD GUI
> building.
I think we're probably all in sympathy with this. I think we're still
in learning mode as a community on the best way (or ways) to do it.
> when you're writing your wx app in your GUI builder, and a vertical box sizer
> doesn't cut it anymore, go into the parent's properties and change it to
> a grid sizer and watch the new layout appear in front of you. Don't like
> that? Adjust it's properties, or maybe try a flex grid sizer.
Hate to sound like a shill for XRCed, but it does that nicely with its
Replace operation (which works on controls as well as sizers). I've
used it to good effect.
Kevin Ollivier
Multi-control layouts would be controlled by the parent control in
the multi-control layout. e.g. you'd change the parent's layout from
BoxSizer to GridSizer, and this would adjust all the child controls
automatically.
>> what I care about is that manipulating sizers within GUI builders
>> becomes easier to do so we can get closer to RAD GUI building.
>
> I think we're probably all in sympathy with this. I think we're
> still in learning mode as a community on the best way (or ways) to
> do it.
>
>> when you're writing your wx app in your GUI builder, and a
>> vertical box sizer doesn't cut it anymore, go into the parent's
>> properties and change it to a grid sizer and watch the new layout
>> appear in front of you. Don't like that? Adjust it's properties,
>> or maybe try a flex grid sizer.
>
> Hate to sound like a shill for XRCed, but it does that nicely with
> its Replace operation (which works on controls as well as sizers).
> I've used it to good effect.
It's not so much an issue of whether or not it can be done; it's
rather an issue of how intuitive is it, and how quickly and easily
can people coming from other tools (e.g. Interface Builder, Qt
Designer, MS IDE) can get used to it. wxGlade does seem to do a nice
job of this, but the issue is, again, that sizers are external
elements, and you have to add them yourself for even basic layouts.
It's just not intuitive, to me, that you have to add a control, then
click "Add slot" on the sizer, then add another control, etc. Much
more intuitive, I think, to add a control, have wx internally add it
to the sizer, and have it pop up on the screen. I know XRCEd does it
that way, but it probably is a bit easier to implement things that
way since users don't see the interface until they preview. (That's
just a guess, though.)
Basically, my primary goal is removing the separation between sizers
and controls, so that some of these special features can be replaced
by more standardized ones found in other IDEs in order to reduce the
learning curve sizers pose.
Thanks,
Kevin
> --
> Don Dwiggins
> Advanced Publishing Technology
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-user...@lists.wxwidgets.org
> For additional commands, e-mail: wxPython-users-
> he...@lists.wxwidgets.org
>
Christopher Barker
> I think I probably didn't explain myself well.
Much better this time. I know you well enough that I expect your ideas
were good ones.
I think you've focused on a good point here: there are three independent
hierarchies used when building an UI:
The Python class hierarchy (subclass, superclass)
The wxWindow hierarchy (parent, child)
The Sizer Hierarchy
This does make things confusing -- can we at least get rid of one?
> 1) Creating HIG compliant apps with proper borders/padding is currently
> a pain (you have to read the HIGs yourself and then code your sizers
> accordingly), and
That could be better. I'm not sure we need to do anything really
different structurally, just add some more defaults, maybe even smart
ones: A Button gets an n pixel border, a TextCtrl gets an m pixel
border, etc.
> 2) Using sizers in visual GUI builders is rather awkward, and it may
> even be true to say the current implementation limits how close to RAD a
> wxPython GUI builder can get.
Personally, I'd like layout to be easier to code by hand, then I think
the GUI builders would be easier too.
> You can't do that
> with wxPython GUI builders when using sizers, because you need to give
> that window a sizer first before you can add the control. In other
> words, for wxPython, creating a sizer to hold controls is always step
> one in GUI building, not "adding controls", which is step one in other
> editors.
Couldn't the editor do it for you anyway? though, as I said, I want the
code to be easy to write too.
> By making controls always have a sizer, we can internalize
> some sizer code, e.g. adding controls to their parents' sizer, into wx
> itself meaning that users and GUI builders automatically get this
> behavior 'for free'.
Hmm. I still don;t see how it makes sense for a control to have a sizer,
unless it's a container control, like a wxPanel. (Doesn't MindWrapper do
something like this? and/or Dabo?) However, controls could have sizing
properties, that get used by the sizer. Essentially these would be all
the parameters and flags that get passed in to the Sizer.Add() method.
Another thought I had was to simplify the difference between horizontal
and vertical sizing, when do you have to know if you use the "option"
parameter or a wx.GROW? Why not:
StretchFactorVert = 3
StretchFactorHoriz = 0
Then that would work in either a horizontal or vertical box sizer (and
grid sizers)
Another thing I often thought: BoxSizers are just special cases of grid
sizers. In fact, I think you could really have only GridBagSizer and
everything else is a special case.
The only real trick here that I see at first is that some layouts (quite
a few, really) need nested sizers. If there is one sizer per Panel
object, how do you do nested sizers? Nested Panels? maybe. It seems like
extra Panels, but maybe that's not a big deal.
> A nice side-benefit for users who code their GUIs by hand is that much
> of the tedious coding is gone -
Now that I like!
Now we need someone to prototype this up....
Kevin Ollivier
On May 22, 2006, at 4:49 PM, Christopher Barker wrote:
> Kevin Ollivier wrote:
>> I think I probably didn't explain myself well.
>
> Much better this time. I know you well enough that I expect your
> ideas were good ones.
Thanks, though your expectations may be set too high. ;-) I'm glad I
was more clear this time; sometimes I get too much into how and
forget to identify the 'why' in the first place. ;-)
> I think you've focused on a good point here: there are three
> independent hierarchies used when building an UI:
>
> The Python class hierarchy (subclass, superclass)
> The wxWindow hierarchy (parent, child)
> The Sizer Hierarchy
>
> This does make things confusing -- can we at least get rid of one?
>
>> 1) Creating HIG compliant apps with proper borders/padding is
>> currently a pain (you have to read the HIGs yourself and then code
>> your sizers accordingly), and
>
> That could be better. I'm not sure we need to do anything really
> different structurally, just add some more defaults, maybe even
> smart ones: A Button gets an n pixel border, a TextCtrl gets an m
> pixel border, etc.
You're right, it's not anything radically different. We just need to
set the padding and borders according to HIG specs.
>> 2) Using sizers in visual GUI builders is rather awkward, and it
>> may even be true to say the current implementation limits how
>> close to RAD a wxPython GUI builder can get.
>
> Personally, I'd like layout to be easier to code by hand, then I
> think the GUI builders would be easier too.
>
>> You can't do that with wxPython GUI builders when using sizers,
>> because you need to give that window a sizer first before you can
>> add the control. In other words, for wxPython, creating a sizer to
>> hold controls is always step one in GUI building, not "adding
>> controls", which is step one in other editors.
>
> Couldn't the editor do it for you anyway? though, as I said, I want
> the code to be easy to write too.
Sure, but the less an editor has to do to implement a feature, the
more likely it will be implemented. :-)
> > By making controls always have a sizer, we can internalize
>> some sizer code, e.g. adding controls to their parents' sizer,
>> into wx itself meaning that users and GUI builders automatically
>> get this behavior 'for free'.
>
> Hmm. I still don;t see how it makes sense for a control to have a
> sizer, unless it's a container control, like a wxPanel. (Doesn't
> MindWrapper do something like this? and/or Dabo?) However, controls
> could have sizing properties, that get used by the sizer.
> Essentially these would be all the parameters and flags that get
> passed in to the Sizer.Add() method.\
I'm not stuck on this approach. The reason I thought of doing it this
way is because it simplifies the internal wx implementation - e.g. We
can always just check for a sizer and add it if one exists.
Otherwise, we'd have to do something like:
if (child->GetSizer())
parentSizer->Add(child->GetSizer());
else
parentSizer->Add(child, child->GetDefaultSizerFlags());
or something like that. (GetDefaultSizerFlags doesn't exist yet ;-)
Actually, that being said, I'm starting to like the idea of
GetDefaultSizerFlags() so maybe we should implement it anyways, in
which case why not just do the above? Robin, any thoughts on this?
> Another thought I had was to simplify the difference between
> horizontal and vertical sizing, when do you have to know if you use
> the "option" parameter or a wx.GROW? Why not:
>
> StretchFactorVert = 3
>
> StretchFactorHoriz = 0
>
> Then that would work in either a horizontal or vertical box sizer
> (and grid sizers)
Yeah, this one often gets me too. I also think it would be a good
idea to do this. How do you propose to add this to the API?
> Another thing I often thought: BoxSizers are just special cases of
> grid sizers. In fact, I think you could really have only
> GridBagSizer and everything else is a special case.
Personally, I think at the API level it's nice to have something that
is simple like BoxSizers. Implementation-wise, maybe they could share
code, but I think BoxSizers are very beginner-friendly.
> The only real trick here that I see at first is that some layouts
> (quite a few, really) need nested sizers. If there is one sizer per
> Panel object, how do you do nested sizers? Nested Panels? maybe. It
> seems like extra Panels, but maybe that's not a big deal.
If you code by hand, you can always just do myPanel.GetSizer().Add
(anotherSizer), but for GUI builders it would probably be easiest for
the user to create another Panel object, as you say. I don't think
this would happen to such an extent that it would introduce
significant overhead, and this seems to me the intuitive way to do
things from a GUI builder.
>> A nice side-benefit for users who code their GUIs by hand is that
>> much of the tedious coding is gone -
>
> Now that I like!
>
> Now we need someone to prototype this up....
If I can sell Robin on this idea, then I'll take it to wx-dev and try
to sell it there. The basic implementation will be pretty simple. A
default sizer for container controls, a
wxWindow::GetDefaultSizerFlags API, and code in wxWindow::Create to
add the child to the parent's sizer. What will take time is
implementing the GetDefaultSizerFlags for various native controls,
though the nice thing is that we don't have to do it for all controls
in one full shot; we can do it one at a time. And IMHO early in the
2.7 cycle would be a good point to introduce this, so we have a
little time to make this work.
Thanks,
Kevin
> -Chris
>
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> NOAA/OR&R/HAZMAT (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chris....@noaa.gov
>
Don Dwiggins
>> Seems to me there's a potential problem with that approach: sizing is
>> generally not an operation on an individual control, but on a set of
>> them (possibly the whole frame). It could be awkward to try to
>> specify a multi-control layout when you're restricted to operations on
>> one control at a time. I might be missing something, though.
>
> Multi-control layouts would be controlled by the parent control in the
> multi-control layout. e.g. you'd change the parent's layout from
> BoxSizer to GridSizer, and this would adjust all the child controls
> automatically.
So in effect, every container comes with a sizer (in its "layout"
attribute), and it can be identified and replaced with a different
sizer, automatically acquiring any children of the old one (which might
require some interaction, depending on the classes of the sizers).
A basic form of this shouldn't be too hard to implement as an extension
of Panel and/or a tweak to a GUI builder. In XRCed, you could have a
setting that would hide these "automatic sizers" in the tree, making it
a bit easier to read. I guess what I'm saying is, maybe someone who
feels strongly about this should cobble up a strawman prototype for the
group to play with. Maybe some common Panel subclasses that each come
with a standard set of sizers that it manages mostly invisibly to the
programmer. (Of course, you'd want good visibility to them when
needed.). (I'm thinking along the lines of Word's and OpenOffice's
concept of document templates, but recursive.)
> Basically, my primary goal is removing the separation between sizers and
> controls, so that some of these special features can be replaced by more
> standardized ones found in other IDEs in order to reduce the learning
> curve sizers pose.
There's a learning curve with any but the simplest controls. It took me
a few days to get comfortable with ListCtrl, for example, and I expect
to have a similar experience if/when I tackle tree controls. The only
special thing here about sizers is that they're ubiquitous. (The
special thing about the current wx.Sizers is that getting them to do
what you want is untuitive until you've had an epiphany.)
BTW, I still think that tackling aspects of this issue would be a good
project for the Summer of Code -- prototypes like mentioned above, demos
that make it visibly clear how the different kinds of sizers work,
alternatives/complements to sizers, etc.
Ed Leafe
> I think that if the issue is making the creation of sizer-based forms
> simple, what we need to do as a community is take the time to abstract
> out the design of forms we have created, and contribute them back into
> the project. Then everyone benefits. And if a dozen people each
> contribute one design, then every Dabo developer will have a dozen
> great designs to start from.
Thanks, Peter, that's exactly what I had in mind all along. I think
that it would be way cool if you could start with a pre-defined
layout, add the controls you want, and have a professional-looking
form that is completely platform independent. I'd even like to take
it one step further: to add the ability to create custom builders
that are automatically fired when a design element is added to the
form. Think of them as mini-wizards, or simply abstractions of the
properties that each design needs. So instead of adding a generic
label/control combo, you select that option, and you get a builder
dialog that lets you specify the label's Caption and the control's
type and data source. Click 'OK', and it's added to your form with
all the important properties set.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
Robin Dunn
>> Hmm. I still don;t see how it makes sense for a control to have a
>> sizer, unless it's a container control, like a wxPanel. (Doesn't
>> MindWrapper do something like this? and/or Dabo?) However, controls
>> could have sizing properties, that get used by the sizer. Essentially
>> these would be all the parameters and flags that get passed in to the
>> Sizer.Add() method.\
>
> I'm not stuck on this approach. The reason I thought of doing it this
> way is because it simplifies the internal wx implementation - e.g. We
> can always just check for a sizer and add it if one exists. Otherwise,
> we'd have to do something like:
>
> if (child->GetSizer())
> parentSizer->Add(child->GetSizer());
> else
> parentSizer->Add(child, child->GetDefaultSizerFlags());
>
> or something like that. (GetDefaultSizerFlags doesn't exist yet ;-)
> Actually, that being said, I'm starting to like the idea of
> GetDefaultSizerFlags() so maybe we should implement it anyways, in which
> case why not just do the above? Robin, any thoughts on this?
It's probably a good idea, although there should be an easy way to
override the flags without needing to derive a new control class.
One potential problem I do see however is in cases where you want the
tab order to be different than the order items are added to sizers.
Currently it's pretty easy to do, but if items are being added to sizer
automatically then you have to create them in sizer order and then deal
with the MoveBeforeInTabOrder.
>> The only real trick here that I see at first is that some layouts
>> (quite a few, really) need nested sizers. If there is one sizer per
>> Panel object, how do you do nested sizers? Nested Panels? maybe. It
>> seems like extra Panels, but maybe that's not a big deal.
>
> If you code by hand, you can always just do
> myPanel.GetSizer().Add(anotherSizer),
Don't forget that the items you want to Add to anotherSizer will already
have been added to myPanel's sizer.
> but for GUI builders it would
> probably be easiest for the user to create another Panel object, as you
> say. I don't think this would happen to such an extent that it would
> introduce significant overhead, and this seems to me the intuitive way
> to do things from a GUI builder.
Again potential tab order problems come into play here, since you can't
change the tab order nested nested controls and non-nested controls.
>
>>> A nice side-benefit for users who code their GUIs by hand is that
>>> much of the tedious coding is gone -
>>
>> Now that I like!
>>
>> Now we need someone to prototype this up....
>
> If I can sell Robin on this idea, then I'll take it to wx-dev and try to
> sell it there. The basic implementation will be pretty simple. A default
> sizer for container controls, a wxWindow::GetDefaultSizerFlags API, and
> code in wxWindow::Create to add the child to the parent's sizer. What
> will take time is implementing the GetDefaultSizerFlags for various
> native controls, though the nice thing is that we don't have to do it
> for all controls in one full shot; we can do it one at a time. And IMHO
> early in the 2.7 cycle would be a good point to introduce this, so we
> have a little time to make this work.
Another potential problem is dealing with moving items to another sizer
if you want to use one that is not the default for the container. Also,
wx.GridBagSizer uses a different wx.SizerItem type than the other sizers.
Kevin Ollivier
On May 22, 2006, at 9:08 PM, Robin Dunn wrote:
> Kevin Ollivier wrote:
>
>>> Hmm. I still don;t see how it makes sense for a control to have a
>>> sizer, unless it's a container control, like a wxPanel. (Doesn't
>>> MindWrapper do something like this? and/or Dabo?) However,
>>> controls could have sizing properties, that get used by the
>>> sizer. Essentially these would be all the parameters and flags
>>> that get passed in to the Sizer.Add() method.\
>> I'm not stuck on this approach. The reason I thought of doing it
>> this way is because it simplifies the internal wx implementation -
>> e.g. We can always just check for a sizer and add it if one
>> exists. Otherwise, we'd have to do something like:
>> if (child->GetSizer())
>> parentSizer->Add(child->GetSizer());
>> else
>> parentSizer->Add(child, child->GetDefaultSizerFlags());
>> or something like that. (GetDefaultSizerFlags doesn't exist
>> yet ;-) Actually, that being said, I'm starting to like the idea
>> of GetDefaultSizerFlags() so maybe we should implement it anyways,
>> in which case why not just do the above? Robin, any thoughts on this?
>
> It's probably a good idea, although there should be an easy way to
> override the flags without needing to derive a new control class.
Sorry, I forgot to mention that I had planned SetDefaultSizerFlags
(wxSizerFlags&) for this.
> One potential problem I do see however is in cases where you want
> the tab order to be different than the order items are added to
> sizers. Currently it's pretty easy to do, but if items are being
> added to sizer automatically then you have to create them in sizer
> order and then deal with the MoveBeforeInTabOrder.
Good point, though IMHO there are merits to both approaches. (i.e. if
you don't heavily modify tab order, you probably gain more by not
having to type all those sizer.Add lines and maintaining sizers
separately)
>>> The only real trick here that I see at first is that some layouts
>>> (quite a few, really) need nested sizers. If there is one sizer
>>> per Panel object, how do you do nested sizers? Nested Panels?
>>> maybe. It seems like extra Panels, but maybe that's not a big deal.
>> If you code by hand, you can always just do myPanel.GetSizer().Add
>> (anotherSizer),
>
> Don't forget that the items you want to Add to anotherSizer will
> already have been added to myPanel's sizer.
D'oh! Well, as a potential solution to this, we could have sizer Add
methods check to see if the control's already in a sizer, and detach
it from that sizer if so. Although I'm not sure if it's worth the work.
>> but for GUI builders it would probably be easiest for the user to
>> create another Panel object, as you say. I don't think this would
>> happen to such an extent that it would introduce significant
>> overhead, and this seems to me the intuitive way to do things from
>> a GUI builder.
>
> Again potential tab order problems come into play here, since you
> can't change the tab order nested nested controls and non-nested
> controls.
Yes, this sucks, but this is a wx limitation that affects more than
just this proposal, IMHO. Actually, I did find a suggestion about
handling custom tab order on the wxWiki:
http://www.wxwidgets.org/wiki/index.php/WxDialog
If this works cross-platform, and I don't see why it wouldn't
(although does SetFocus always set keyboard focus too?), we could
derive a CustomTabDialog that uses it and has a Get/SetTabOrder
( [ control1, control2, control7, control43, control3,
control15... ] ) function. This would be almost trivial to write at
the wxPython level.
Or, just add Get/SetTabOrder to wxDialog, and when SetTabDialog is
called, the CharHook is registered... That way we don't muck with
previous behavior.
>>>> A nice side-benefit for users who code their GUIs by hand is
>>>> that much of the tedious coding is gone -
>>>
>>> Now that I like!
>>>
>>> Now we need someone to prototype this up....
>> If I can sell Robin on this idea, then I'll take it to wx-dev and
>> try to sell it there. The basic implementation will be pretty
>> simple. A default sizer for container controls, a
>> wxWindow::GetDefaultSizerFlags API, and code in wxWindow::Create
>> to add the child to the parent's sizer. What will take time is
>> implementing the GetDefaultSizerFlags for various native controls,
>> though the nice thing is that we don't have to do it for all
>> controls in one full shot; we can do it one at a time. And IMHO
>> early in the 2.7 cycle would be a good point to introduce this, so
>> we have a little time to make this work.
>
> Another potential problem is dealing with moving items to another
> sizer if you want to use one that is not the default for the
> container.
My thoughts on this were that it would just involve a call to
container.SetSizer, which internally will, for each child control,
grab its flags from the old sizer and then add the control to the new
sizer. Do you see any problems with this?
> Also, wx.GridBagSizer uses a different wx.SizerItem type than the
> other sizers.
It's true that we lose GB data, but if we're moving either to or from
GBSizer, the GB-specific properties aren't of any use to us anyhow.
And as long as we use GetItem, we get a wxSizerItem back, so we could
use that to grab the other properties.
Thanks,
Kevin
>
> --
> Robin Dunn
> Software Craftsman
> http://wxPython.org Java give you jitters? Relax with wxPython!
>
>
johnf
> On 5/20/06, johnf <jfab...@yolo.com> wrote:
> > I wonder why we need to have sizers? Why can't someone develop a GUI
> > editor
> > that automaticly determines what is required to keep the relative
> > proportions
> > and positions of widgets on a frame.
> >
> > chapter (11) just to explain sizers. So you create a nice looking frame
>
> been using wx for a while for a multitude of projects, so I'm somewhat
> insulated from what the impressions might be for a new coder. But I do
> remember the progression I went through (I started with layout constraints)
> and how happy I was when I finally figured out a sizer 'idiom' that worked
> for me.
>
> I've programmed on a few other platforms (including Amiga using three
> different GUI toolkits, some quite similar to wx) and have to say that
> sizers, while not being the absolute finest of all possible solutions, make
> the most sense for a dynamic, flexible, professional-looking user interface
> without much in the way of pain - provided one uses good habits.
>
> with sizers
>
> > and then someone says "Look's great but could you add these two other
> > widgets". It's just a pain to work with. There has to be something
> > better.
>
>
> OK, so you've got a complex UI you're putting together. You're using a
> object-oriented language to do it with. Does it make even the slightest bit
> of sense to put everything at the top level (the frame) and try to manage
> it? No! Absolutely not! Here's an example of how I'd put together a program
> with a working area (text input/output) and a series of controls.
>
> FRAME
> - TOP PANEL
> - Left-hand (working) panel
> - Right-hand (control) panel
>
> Aside from the frame, each of these elements are consisted of a
> wx.Panelwith its own sizer, in its own class OUTSIDE the frame class.
> Each distinct
> component is (in source) presented in its own context.
>
> Want a working example? Have a look at wx.Joystick in the wxPython demo
> program. That example has a wx.GridBagSizer at the top level, and various
> components below it. I did a large part of the work on that one (the
> rewrite when we moved from wx* to wx.*) so it expresses my 'idiom' fairly
> well. It breaks down like this:
>
> * JoystickDemoPanel
> * InfoPanel (info pulled from the joystick driver)
> * JoyPanel (joystick positon display)
> * POVPanel (POV button position display)
> * AxisPanel (various axis position displays)
> * JoyButtons (state of all joystick buttons)
>
> Each is consisted of one or more custom and standard controls (such as the
> LED or crosshair displays) wrapped by a sizer. We even have a control
> (Label) that is reused over and over again, again it's in its own little
> class rather than mashed into the top level. I could have made it even
> further nested (I often do) and it would still be coherent and
> maintainable.
>
> You can even break it up into seperate files - I have, for the more complex
> ones (such as programs that have multiple notebook pages), which helps keep
> the code readable and (again) maintainable.
>
> So back to your example:
>
> with sizers
>
> > and then someone says "Look's great but could you add these two other
> > widgets". It's just a pain to work with. There has to be something
> > better.
>
> so years, using this 'idiom'. Using the Joystick demo as an example, the
> following would all be trivial:
>
> - add an additional control to reset the driver's data
> - Add another 16 button indicators
> - Add another POV mode
> - Rearrange the entire layout of the top panel
>
> So: I don't think sizers are the problem here. I think the learning curve
> is the problem, and time and experience using them. That and the approach
> you might take in organizing your code. Maybe I'm wrong, but almost every
> case I've seen like this has been because the code was a confusing mess due
> to everything being smooshed together.
>
>
> Does anyone know of any sort of project trying to get rid of sizers?
>
>
> can say is I'd buy one for a dollar. :-)
I can and do use sizers. They are a pain - period. There is no reason I can
think of that prevents wxPython from moving forward to a new level of GUI
programming. I have programmed in asm, c, c++, a little java, VFP, Object
Pascal, and Python. I moved to c because it was faster and easier to use
than asm. I moved to C++ to get oop. I moved to VFP because it was the
fastest way to get a data project to market and used OOP. I used the free
pascal compiler because it again provided a easier tool to work with on the
Linux platform. I have been using Python for a couple of years now. I'd
like to move on to a easier and faster way to setup a GUI and I think
wxPython could be that vehicle. So why would you be completely baffled at
these sentiments?
Even if I couldn't use sizers - I still believe wxPython can and should
improve the way sizers are used. And sizers are not perfect by a long shot!
Most people let textboxes just expand when resizing forms. If I have seen
one I've seen a hundred screens where the programmer allowed the textbox just
to expand to the right. I heard the argument many times why "change it -
it's not broken". Why move from c to basic - because programmers became more
productive for most applications. Why move to a interpretive language when c
is faster at execution. Why move from text based screens to GUI screens?
BTW my suggest does not mean I think wxWidgets should get rid of sizers. I'm
saying why can't wxPython do a better job of using them. Today we have
computers with dual-core CPU's. Graphic cards with more ram than some of my
computers from just a few years ago. I can think of nothing that can stop
wxPython from creating a better GUI system - accept desire.
John
Jeff Grimmett
I wonder why we need to have sizers? Why can't someone develop a GUI editor
that automaticly determines what is required to keep the relative proportions
and positions of widgets on a frame.
Sizers work but they are a pain to work with. Robin spent a whole chapter
(11) just to explain sizers. So you create a nice looking frame
I have to say I am completely baffled at these sentiments. Granted I've been using wx for a while for a multitude of projects, so I'm somewhat insulated from what the impressions might be for a new coder. But I do remember the progression I went through (I started with layout constraints) and how happy I was when I finally figured out a sizer 'idiom' that worked for me.
I've programmed on a few other platforms (including Amiga using three different GUI toolkits, some quite similar to wx) and have to say that sizers, while not being the absolute finest of all possible solutions, make the most sense for a dynamic, flexible, professional-looking user interface without much in the way of pain - provided one uses good habits.
with sizers
and then someone says "Look's great but could you add these two other
widgets". It's just a pain to work with. There has to be something better.
Back to this in a moment ...
OK, so you've got a complex UI you're putting together. You're using a object-oriented language to do it with. Does it make even the slightest bit of sense to put everything at the top level (the frame) and try to manage it? No! Absolutely not! Here's an example of how I'd put together a program with a working area (text input/output) and a series of controls.
FRAME
- TOP PANEL
- Left-hand (working) panel
- Right-hand (control) panel
Want a working example? Have a look at wx.Joystick in the wxPython demo program. That example has a wx.GridBagSizer at the top level, and various components below it. I did a large part of the work on that one (the rewrite when we moved from wx* to wx.*) so it expresses my 'idiom' fairly well. It breaks down like this:
* JoystickDemoPanel
* InfoPanel (info pulled from the joystick driver)
* JoyPanel (joystick positon display)
* POVPanel (POV button position display)
* AxisPanel (various axis position displays)
* JoyButtons (state of all joystick buttons)
Each is consisted of one or more custom and standard controls (such as the LED or crosshair displays) wrapped by a sizer. We even have a control (Label) that is reused over and over again, again it's in its own little class rather than mashed into the top level. I could have made it even further nested (I often do) and it would still be coherent and maintainable.
You can even break it up into seperate files - I have, for the more complex ones (such as programs that have multiple notebook pages), which helps keep the code readable and (again) maintainable.
So back to your example:
with sizers
and then someone says "Look's great but could you add these two other
widgets". It's just a pain to work with. There has to be something better.
Cake, relatively speaking, on just about any UI I've done in the past 5 or so years, using this 'idiom'. Using the Joystick demo as an example, the following would all be trivial:
- add an additional control to reset the driver's data
- Add another 16 button indicators
- Add another POV mode
- Rearrange the entire layout of the top panel
So: I don't think sizers are the problem here. I think the learning curve is the problem, and time and experience using them. That and the approach you might take in organizing your code. Maybe I'm wrong, but almost every case I've seen like this has been because the code was a confusing mess due to everything being smooshed together.
Does anyone know of any sort of project trying to get rid of sizers?
No, but if someone can beat sizers (say, with HTML table-like stuff) all I can say is I'd buy one for a dollar. :-)
"Ladies and gentlemen, there's nothing to worry about ... but please keep your heads down." - The Muppet Show
Best,
Jeff
Eli Golovinsky
> One thing that was mentioned on the Dabo list a while back was being
> able to create small template classes that could be added to a design
> just as easily as base controls. These classes could be the sort of
> 'label, control' pairs that you mention, or general 3-column layouts,
> or any other sort of thing that someone sees a need for. This is
> pattern recognition, and it takes developers who are creating forms to
> contribute reusable classes.
This is a great idea. Layouts do seem to repeat themselves and there is
no need to use a paper an a pencil each time you want to create a dialog
with a row of Apply, Ok, Cancel at the bottom and a few Label + TextCtrl
pairs on it.
I'm not sure though that this should be implemented in code. Maybe we
should start by collecting common layouts and best-practice ways to
build them using sizers. We can create a standard method of describing
such a layout and treat them as a sort of a design pattern to be
combined or altered as each developer sees fit. At a later point in
time, when the list has stabilized, those standard layouts can be added
either to the wxPython distribution, to the demo, to XRCed or to all three.
And we can start collecting ideas and common layout designs right from
the start. I think a screen shot and a hirarchical list of sizers and
controls could be a good basis for the format.
Jeff Grimmett
> think of that prevents wxPython from moving forward to a new level of GUI
> programming.
> Even if I couldn't use sizers - I still believe wxPython can and should
> improve the way sizers are used. And sizers are not perfect by a long shot!
> one I've seen a hundred screens where the programmer allowed the textbox just
> to expand to the right. I heard the argument many times why "change it -
> it's not broken".
Michael Hipp
> ----- Original Message -----
> From: "Ed Leafe" <e...@leafe.com>
> To: wxPytho...@lists.wxwidgets.org
> Subject: Re: [wxPython-users] Why can't we get rid of sizers?
> Date: Tue, 23 May 2006 16:18:41 -0400
>
>
> On May 23, 2006, at 10:25 AM, Michael Hipp wrote:
>
> >> I have to say I am completely baffled at these sentiments. Granted I've
> >> been
> >> using wx for a while for a multitude of projects, so I'm somewhat insulated
> >> from what the impressions might be for a new coder. But I do remember the
> >> progression I went through (I started with layout constraints) and how
> >> happy
> >> I was when I finally figured out a sizer 'idiom' that worked for me.
> >
> > because you're too uneducated/inexperienced/dumb/lazy."
>
> I think you're reading way too much into such comments. I took them to
> mean that sizers address a complex issue, and while complex themselves, are
> no more complex than they have to be. The learning curve is appropriate to
> the size of the task involved.
>
> Nothing about being dumb or lazy; it's simply that the majority of GUI
> design tools work completely differently than the approach required by
> sizers, so most people (including myself) get a first impression that
> sizers are confusing and difficult. IMO, they simply take time to retrain
> your brain to think in a sizer-centric manner when laying out a form. Once
> you get used to that, they really aren't any more of a pain than any other
> UI tool.
I appreciate the sentiments. I really do. But you're once again dismissing any complaints about sizers and blaming it on the need for "retraining" or "first impressions", "learning curve", or "getting used" to it.
For the record I didn't find sizers confusing and difficult. They *seem* rather straightforward, at least once I understood the proportions and flags thing. It's when actually trying to coerce them into giving sensible results that the torture sets in with the hours of tweaking proportions, flags, spanning of rows and columns, etc. I've been working with sizers fairly steadily for about a year and a half now. I'm way past first impressions.
Michael
Kevin Ollivier
On May 23, 2006, at 2:44 PM, Robin Dunn wrote:
> Christopher Barker wrote:
>
>> Robin Dunn wrote:
>>> It's probably a good idea, although there should be an easy way
>>> to override the flags without needing to derive a new control class.
>> Why not just have the flags be an attribute you can alter?
>
> In this scheme by the time you have a widget whose attributes you
> can alter it has already been added to the sizer and the sizer has
> it's own copy of the flags. So you would have to do it something
> like this:
>
> parent.GetSizer().FindItem(widget).GetFlags().SetSomeFlagValue(value)
>
>
>
>>> Again potential tab order problems come into play here, since you
>>> can't change the tab order nested nested controls and non-nested
>>> controls.
>> Is that changeable? the tab order approach is pretty limited in
>> other ways already. Being able to set tab order arbitratily
>> accross multiple Panels would be very cool!
>
> I don't think it's changeable. Tab order is currently handled on a
> per-container window basis with some help from the platform, and in
> most cases with support for tabbing into and out of a container at
> the beginning and end of the container's tab-order. Having a tab-
> order that transcends containers and sub-wontainers with an
> arbitrary order of widgets would probably require a lot of work,
> lose the platform support and would likely be quite fragile when
> changes are made.
Sorry, I'm not sure I understand what you mean here. I'm guessing you
mean that our current implementation for tab traversal is due to how
some of the OS/toolkits work, but so far in googling I haven't been
able to find a good explanation as to why the OS would care about
container controls WRT handling navigation events. I can tell why wx
cares, due to wxContainerControl::HandleOnNavigationKey, but I
haven't found any information on why we had to do things that way or
why traversing some tab order list (e.g. wxWindowList GetTabOrder())
would be significantly different than traversing GetChildren(). Any
light you could shed on what could make the above problems occur or
why things are setup this way would be greatly appreciated!
Thanks,
Kevin
>
>
> --
> Robin Dunn
> Software Craftsman
> http://wxPython.org Java give you jitters? Relax with wxPython!
>
>
Ed Leafe
> I believe a textbox control should not grow/expand to fill space.
> It should
> grow proportionly. If the developer believes the size should be
> 1/2 inch
> long when using 10 point font on a 1024x768 resolution - then as
> the screen
> gets bigger or the font changes so should the textbox. But today I
> doubt
> that can happen so I'd just like to see a better way of using sizers.
That's really not the job of sizers. In Dabo, you can use the
textbox's DynamicFontSize property to dynamically change the font
size. Just create your own algorithm for determining the proper size,
and set DynamicFontSize to that method. If you want all your
textboxes to behave that way, then just create a subclass with that
algorithm, and add instances of the subclass to your form.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
Christopher Barker
>> So you would have to do it something like this:
>>
>> parent.GetSizer().FindItem(widget).GetFlags().SetSomeFlagValue(value)
Only if you don't re-do how sizers work. For the sake of prototyping,
that's probably what we'd have to do, but my "pie in the sky" idea is
that the layout related properties of an individual Window in a sizer
would be stored with the Window, like "BestSize" currently is. Then when
a Sizer did it's layout thing, it would refer to the Windows it contains
to figure out those properties. So:
AWindow.LayoutProperties.Border = 5
Sizer.Layout()
Would just work.
(I'm imagining that we would have a LayoutProperties object that would
hold all that stuff, and that every Window (and SizerItem) would have
one by default.
IN fact, multiple Windows could share a reference to the same
LayoutProperties object, so you could change a bunch of stuff in one
place. That would be kind of cool.
Robin Dunn
> Hi Kevin,
>
> It used to be called wxSizerProducer is that a better name? It however
> does not reall cover it. wxTextGUI is also not really THE name as it
> sounds like the GUI is created by some kind of text windows only like
> TurboVision ;-)
>
> Any other suggestions? A search / replace is done easily.
>
> wxGuiParser might also be a better name. What do you think?
I think it should at least have "Sizer" in the name since that is what
it is creating. wxSizerFactory?