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.
···
On Sat, 20 May 2006 11:07:32 -0700, johnf <jfabiani@yolo.com> wrote:
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
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
···
On Monday 22 May 2006 09:59, Tim Roberts wrote:
On Sat, 20 May 2006 11:07:32 -0700, johnf <jfabiani@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.
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 wrote:
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
What would be the first step? Although I think the goal would be to make GUI
programming easier what is the overall plan?
John
···
On Monday 22 May 2006 11:17, Don Dwiggins wrote:
Tim Roberts wrote:
> 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).
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.
···
On 5/22/06, johnf <jfabiani@yolo.com> wrote:
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?
--
# p.d.
johnf wrote:
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
Advanced Publishing Technology
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
···
On May 22, 2006, at 10:10 PM, Peter Decker wrote:
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.
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.