Interface Builder Tool

100 views
Skip to first unread message

Cody Precord

unread,
Jan 14, 2011, 2:53:54 PM1/14/11
to wxpyth...@googlegroups.com
Hello,

I would like to introduce an early look at a little something that I
have been working on in my spare minutes over the last several weeks.
I am currently calling it Eguid (Editra Gui Designer). It started off
as more or less of an exercise in programming to test out some ideas
for a plugin for Editra but decided it would be better off as its own
application. Please see the link below for a demo via a short
screencast of the basic proof of concept showing the current user
interface in action. (VLC can play the video if you have trouble
viewing it)

Screencast: http://editra.org/uploads/test/eguid_prototype.avi

The general design idea for the output of the tool is that it will
generate code to abstract and hide the usage of sizers, panels, and
event bindings. It will do this by generating a subpackage of modules
that contain base class definitions that encapsulate the layout and
either provide a controller class or a virtual override mechanism for
the event handling. Basically it will enforce an MVC/MVP design
pattern but will wrap it in a framework that makes it really easy and
transparent to the client user code. The code will be generated from
an Xml representation of what is created in the designer which will
leave the door open for creating various code generators for different
languages and other design approaches.

Currently the application is mostly a basic shell of what it needs to
be (meaning, no you cant use it to create your UI's yet), however most
of the backbone of the core framework for each of the main components
and data model are in place and there is only about two pieces left
before a basic end to end test of creating a layout, saving it, and
loading it back in to the designer again can be performed.

To succeed and become useful in the near future this project needs
community buy in and since this seems to be a tool that everyone would
like to have I am hoping that in this post I can generate some
interest and recruit some help

So the plan is that in the coming weeks, I would like to setup a
structured project with clear and well defined work items with (loose)
requirements and design plans, that can be implemented by other
project members. There is a fair amount of rather interesting code to
write for such a tool so it should be enjoyable to work on ;). Anyway,
this is all dependent upon whether or not there is sufficient interest
in this so let me know as there will be tasks available for people at
any level of commitment.

----

Now for a slight segue into a request for wxPhoenix. The control
library and designer windows work almost entirely off of introspection
which allows for the application to dynamically adapt to any version
of wxPython and any new controls that may have been added, removed, or
changed. However I ran into a bit of a snag that required me to
augment my original design with some specialized code because the
Python wrapper code that is generated for wxPython currently defines
most methods using the short notation instead of the full method
signatures.

i.e)

currently defines

def __init__(self, *args, **kwargs):

instead of

def __init__(self, parent, id=ID_ANY, ...):

If the methods (or at least the constructors) had their full explicit
signature present in the Python modules it would be possible for me to
write a much better generic heuristic algorithm that doesn't rely on
as much (or any) specialized code to handle many of the widgets that
have extra non-standard constructor arguments present, it still may be
possible to do this by examining the properties defined in a class
prior to instantiation but I think it would be much safer to inspect
the argspec of the method signature to ensure that the property can be
set via the constructor or not.

Robin, Would there be any issues in making such a change?


----
Regards,

Cody

werner

unread,
Jan 15, 2011, 3:00:18 AM1/15/11
to wxpyth...@googlegroups.com
Cody,

This looks very very interesting. I would love a GUI designer which
easily can deal with new controls (all the agw ones etc etc).

I think it is very good that you keep it outside of Editra, a bigger
incentive for other IDE/Editors to adopt/use it too.

My coding is not good enough for stuff like this, but I think I could
help out in testing.

Werner

P.S.
Could it support things like "CreateButtonSizer" on a dialog?

Robin Dunn

unread,
Jan 15, 2011, 3:34:51 PM1/15/11
to wxpyth...@googlegroups.com
On 1/14/11 11:53 AM, Cody Precord wrote:
> Hello,
>
> I would like to introduce an early look at a little something that I
> have been working on in my spare minutes over the last several weeks.
> I am currently calling it Eguid (Editra Gui Designer). It started off
> as more or less of an exercise in programming to test out some ideas
> for a plugin for Editra but decided it would be better off as its own
> application. Please see the link below for a demo via a short
> screencast of the basic proof of concept showing the current user
> interface in action. (VLC can play the video if you have trouble
> viewing it)
>
> Screencast: http://editra.org/uploads/test/eguid_prototype.avi

That looks like a great start Cody. I like the lines that are drawn
while dragging items around. A nice feature to add there would be to
snap-to alignment points (edges or midpoints) of the other widgets that
the lines intersect.

If things continue as they are going now then we'll actually be taking
another step in the opposite direction in that there won't be any Python
code for the wrappers or implementations for many of the methods in a
class. Instead the application code will be calling direct to the C++
wrapper code. Unfortunately this means that normal introspection of the
class and method objects is going to yield a lot less information than
if the wrappers were actual Python classes/methods as now. However
there is no need to panic as there are two things I am thinking about
that will help you out, and I plan on doing at least one of them.

First, WingIDE has a feature (and I'm under the impression that some
other tools are using it too) where they will look for *.pi files
alongside the binary extension modules which can contain equivalent
Python stubs for the functions, classes and methods located in the .so
or .pyd file. In other words, the .pi file contains the code for
declaring the function, classes, methods, etc. with their parameter
names, default values, docstrings etc., but no real code in the
functions and methods. When these files are present then WingIDE uses
them for the source of its source code analysis instead of relying
solely on what it can glean from the extension module. There is a bit
more info here: http://www.wingware.com/doc/edit/helping-wing-analyze-code

Secondly, there is a common practice with documentation and analysis
tools to look at a function/method's docstring and see if it appears to
start with (after any leading white space and before an empty line) a
function prototype for the method, and if so, to use that portion of the
string for getting the information about the parameter names and default
values. So for example, the docstring for wx.Window.SetForegroundColour
would look something like this:

"""\
SetForegroundColour(colour) -> bool

Set the foreground colour of the window.
"""

Both of these approaches will have problems in the cases where a
function is overloaded. Essentially a single function/method in Python
needs to map to more than one C++ implementation, each with different
argument signatures. For the *.pi file, since it needs to essentially
be valid Python code, I'll probably need to fall back to the (*args,
**kw) type of declaration. For the docstrings (including those that are
written to the .pi file) I'll just list the prototype for each version
of the overloaded function. So for example, wx.Window.SetSize's
docstring will look something like this:

"""\
SetSize(x, y, width, height, sizeFlags=wxSIZE_AUTO)
SetSize(size)
SetSize(width, height)

Specify the size of the window in pixels. Blah blah blah...
"""

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

Mike Driscoll

unread,
Jan 15, 2011, 9:07:19 PM1/15/11
to wxpyth...@googlegroups.com
Hi Cody,



I wrote a quick article about this on my blog to try to drum up some support for it as I think this is a good idea. I took the liberty of uploading the video to youtube to make it easier for people to watch. Hopefully you won't mind. Here's the link to the article: http://www.blog.pythonlibrary.org/2011/01/15/wxpython-eguid-editra-gui-designer-wysiwyg-editor/

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

Blog:   http://blog.pythonlibrary.org

christof

unread,
Jan 16, 2011, 3:27:22 PM1/16/11
to wxPython-dev
Hi Cody,

this looks very promising. Here is a stimulation and also a big wish
of me.

Historically, the idea of an "interface builder" goes back to the
NextSTEP system, see http://en.wikipedia.org/wiki/Interface_Builder.
Interestingly, this interface builder was different of the modern gui
builders (except the apple tools), and I believe it was much more
powerful. Unfortionately, the original idea seems to be not very
widely known. Therefore, I would like to point you to this idea.

The difference is the following. With most gui builders you are
working on the level of classes, i.e. the result you are saving to
disc is a class definition (e.g. a frame). Instead with interface
builder, you work on the level of objects. You create objects, define
how they look/behave and then you can connect their events to methods
and also to functions. What you save to disc is not just a dead gui
(nothing happens when you click a button), but instead it is a pickled
fully functional application.

Working with interface builder is not only fun and efficient and also
very flexible: you connect the objects in a different way and you have
a different application.

Due to introspection capabilities and flexibility python should be
ideal for this conecept.

Here is a youtube video showing something similar with ruby:
http://www.youtube.com/watch?v=838MHbylnbk

I would love to have a tool like that and I believe that it is close
to what you have done.

Greetings
Christof

Tony C

unread,
Jan 16, 2011, 1:25:15 PM1/16/11
to wxPython-dev


On Jan 14, 11:53 am, Cody Precord <codyprec...@gmail.com> wrote:
> Hello,
>
> I would like to introduce an early look at a little something that I
> have been working on in my spare minutes over the last several weeks.
> I am currently calling it Eguid (Editra Gui Designer). It started off
> as more or less of an exercise in programming to test out some ideas

Great idea Cody.

Since there are already several gui designers for wxPython, have you
defined
how this project will be different from the others? Do you plan to
continue where the others left off?
One of the issues I see with the other gui designers is that they
don't implement the full set of widgets that wxPython
supports.
PythonCard is one example.

Cody Precord

unread,
Jan 16, 2011, 6:52:18 PM1/16/11
to wxpyth...@googlegroups.com
Hi,

On Sat, Jan 15, 2011 at 2:00 AM, werner <wbr...@free.fr> wrote:
>>
> This looks very very interesting.  I would love a GUI designer which easily
> can deal with new controls (all the agw ones etc etc).
>
> I think it is very good that you keep it outside of Editra, a bigger
> incentive for other IDE/Editors to adopt/use it too.
>
> My coding is not good enough for stuff like this, but I think I could help
> out in testing.
>
> Werner
>
> P.S.
> Could it support things like "CreateButtonSizer" on a dialog?

Yes it would use it internally for standard dialogs but the point of
the tool would be that you wouldn't even have to know what a
ButtonSizer is. You will just just create a layout by putting the
controls where you want and then optionally apply behaviors for the
layout such as alignment and grow factors.

Then the tool will simply generate a class that your application code
would either subclass or provide a controller impl to do the business
logic associated with the application.


Cody

Cody Precord

unread,
Jan 16, 2011, 6:58:01 PM1/16/11
to wxpyth...@googlegroups.com
Hi,

On Sat, Jan 15, 2011 at 2:34 PM, Robin Dunn <ro...@alldunn.com> wrote:
> On 1/14/11 11:53 AM, Cody Precord wrote:
>>
>> Hello,
>>
>> I would like to introduce an early look at a little something that I
>> have been working on in my spare minutes over the last several weeks.
>> I am currently calling it Eguid (Editra Gui Designer). It started off
>> as more or less of an exercise in programming to test out some ideas
>> for a plugin for Editra but decided it would be better off as its own
>> application. Please see the link below for a demo via a short
>> screencast of the basic proof of concept showing the current user
>> interface in action. (VLC can play the video if you have trouble
>> viewing it)
>>
>> Screencast: http://editra.org/uploads/test/eguid_prototype.avi
>
> That looks like a great start Cody.  I like the lines that are drawn while
> dragging items around.  A nice feature to add there would be to snap-to
> alignment points (edges or midpoints) of the other widgets that the lines
> intersect.
>

Yes this is planned there will also be markers and hints for margins
and spacing between objects.

I see, will have to look into these .pi files and I had seen the
docstrings before but not sure if I want to try going down that route
as it would be a bit messy in many cases and doesn't feel like it can
be implemented in a very reliable manner.

Thanks,

Cody

Cody Precord

unread,
Jan 16, 2011, 7:00:36 PM1/16/11
to wxpyth...@googlegroups.com
Hi,

On Sat, Jan 15, 2011 at 8:07 PM, Mike Driscoll <mi...@pythonlibrary.org> wrote:
> Hi Cody,


>
> I wrote a quick article about this on my blog to try to drum up some support
> for it as I think this is a good idea. I took the liberty of uploading the
> video to youtube to make it easier for people to watch. Hopefully you won't
> mind. Here's the link to the article:
> http://www.blog.pythonlibrary.org/2011/01/15/wxpython-eguid-editra-gui-designer-wysiwyg-editor/
>

Yea its fine, I just didn't want to register an account at youtube so
had uploaded to my server.

Thanks,

Cody

Cody Precord

unread,
Jan 16, 2011, 7:15:25 PM1/16/11
to wxpyth...@googlegroups.com
Hi,

On Sun, Jan 16, 2011 at 2:27 PM, christof <christo...@googlemail.com> wrote:
> Hi Cody,
>
> this looks very promising. Here is a stimulation and also a big wish
> of me.
>
> Historically, the idea of an "interface builder" goes back to the
> NextSTEP system, see http://en.wikipedia.org/wiki/Interface_Builder.
> Interestingly, this interface builder was different of the modern gui
> builders (except the apple tools), and I believe it was much more
> powerful. Unfortionately, the original idea seems to be not very
> widely known. Therefore, I would like to point you to this idea.
>

I am well aware of this, I have used a number of different tools in
the past and the closest one I have ever been to liking is Apples
Interface builder.

> The difference is the following. With most gui builders you are
> working on the level of classes, i.e. the result you are saving to
> disc is a class definition (e.g. a frame). Instead with interface
> builder, you work on the level of objects. You create objects, define
> how they look/behave and then you can connect their events to methods
> and also to functions. What you save to disc is not just a dead gui
> (nothing happens when you click a button), but instead it is a pickled
> fully functional application.
>
> Working with interface builder is not only fun and efficient and also
> very flexible: you connect the objects in a different way and you have
> a different application.
>

I am still thinking of how I want to generate the output from the tool
but I am thinking that it will enforce an MVC design pattern. So that
the interface is separate from the business logic, that way the UI can
be interchanged with any number of different controllers to change the
behavior.

> Due to introspection capabilities and flexibility python should be
> ideal for this conecept.
>
> Here is a youtube video showing something similar with ruby:
> http://www.youtube.com/watch?v=838MHbylnbk
>
> I would love to have a tool like that and I believe that it is close
> to what you have done.
>

Yes that is Xcode and Apple's Interface Builder. The end goal is
something along those lines but will be more simplistic in nature.


Cody

David Lyon

unread,
Jan 16, 2011, 7:19:47 PM1/16/11
to wxpyth...@googlegroups.com
Boa constructor is excellent. It is sort of a delphi ripoff...

Unfortunately, development seems to have stopped.

For me personally, I am a "bullder" dependant developer. I just
cannot hand code.

I suggest that you think about forking boa constructor, and add
in whatever it is that you can think will improve it.



Cody

Cody Precord

unread,
Jan 16, 2011, 7:23:23 PM1/16/11
to wxpyth...@googlegroups.com
Hi,

On Sun, Jan 16, 2011 at 12:25 PM, Tony C <capp...@gmail.com> wrote:
>
> Great idea Cody.
>
> Since there are already several gui designers for wxPython, have you
> defined
> how this project will be different from the others? Do you plan to
> continue where the others left off?
> One of the issues I see with the other gui designers is that they
> don't implement the full set of widgets that wxPython
> supports.
> PythonCard is one example.
>

It should be readily apparent how it is different from the existing
ones from the video ;)

Most of the existing ones are in my opinion hard to use and don't make
it possible to create very nice interfaces with. I never spent much
time using any of them because it was much easier to just write out
the code for the UI on my own.

With this you will be able to create the UI and see it as you created
it by simply dragging the controls around to where you want them. It
will also abstract most of the internal implementation details that
all the other tools require you to have knowledge of while using them.

Anyway, at the current point the tool is mostly an idea in motion.
Hopefully if I can find enough time over the next weeks, it will be
usable enough to get a feel for its final direction.


Cody

David Lyon

unread,
Jan 16, 2011, 9:47:27 PM1/16/11
to wxpyth...@googlegroups.com
Sounds like an oximoron..

You are making a tool for coding screens but you prefer to do
it by hand in any case..

So why do you need a tool?

Mike Driscoll

unread,
Jan 16, 2011, 10:03:36 PM1/16/11
to wxpyth...@googlegroups.com


On Sun, Jan 16, 2011 at 8:47 PM, David Lyon <david.lyon...@gmail.com> wrote:
Sounds like an oximoron..

You are making a tool for coding screens but you prefer to do
it by hand in any case..

So why do you need a tool?


 

He doesn't need the tool. He's just being cool by making one for people that do.

werner

unread,
Jan 17, 2011, 3:28:24 AM1/17/11
to wxpyth...@googlegroups.com
On 17/01/2011 01:19, David Lyon wrote:
> Boa constructor is excellent. It is sort of a delphi ripoff...
>
> Unfortunately, development seems to have stopped.
>
> For me personally, I am a "bullder" dependant developer. I just
> cannot hand code.
>
> I suggest that you think about forking boa constructor, and add
> in whatever it is that you can think will improve it.
Another option would be that at some point Cody's designer is an
alternative designer within Boa.

Werner

Christopher Barker

unread,
Jan 18, 2011, 6:55:04 PM1/18/11
to wxpyth...@googlegroups.com
On 1/14/11 11:53 AM, Cody Precord wrote:
> Hello,
>
> I would like to introduce an early look at a little something that I
> have been working on in my spare minutes over the last several weeks.
> I am currently calling it Eguid

> Screencast: http://editra.org/uploads/test/eguid_prototype.avi

Very cool! nice work!

> hide the usage of sizers,

Hide, or not use at all? -- it sure looks like absolute positioning.
Please don't do that! I'm convinced that auto-layout of some sort is
critical for maintainable system, even if you are using a GUI GUI-Builder.

There has GOT to be a good way to put an interface on Sizers...

Anyway, cools stuff!

On 1/16/11 3:52 PM, Cody Precord wrote:
> You will just just create a layout by putting the
> controls where you want and then optionally apply behaviors for the
> layout such as alignment and grow factors.

Hmm -- I still think that the alignment shouldn't be "optional". In
fact, while perhaps most people are visual, and thus think: "I want a
button here", I think that actual layout ALWAYS has structure:

"This button goes in the lower left corner."

"I want a row of buttons along the bottom"

"I want a column of buttons"

"I want the label to the left of the text box"

i.e. what the basic Sizers encapsulate: rows, columns, grids.

Much of that can be accomplished with snap-to layout grids, alignment
tools, etc. However, I think that the structural information should be
what the user expresses, and what gets stored, and should only be turned
into layout as close to run-time as possible. (run-time because the
final layout depends on language, and system fonts, and ...)

In GUI layout tools I've seen, for instance, you can do things like
select a bunch of buttons, and then click 'alignment', and make them all
the same size, and lined up vertically. OK, but that alignment
information isn't stored, it has simply changed the absolute positioning
of the buttons. This becomes a maintainable pain, because every time you
add a button, change the size of one, etc, that "all lined up and the
same size" information has to be re-generated.

This is like using a word processor and making some text bold and 16pt
font -- rather than defining it as a heading -- it looks the same, but
becomes a nightmare when you want make changes, build a table of
contents, etc -- keep the meta data!

It does sound like you're thinking about how to easily incorporate
custom widgets -- that is key, that's one of things that's made many GUI
builders useless for me.

>> Secondly, there is a common practice with documentation and analysis tools
>> to look at a function/method's docstring and see if it appears to start with
>> (after any leading white space and before an empty line) a function
>> prototype for the method, and if so, to use that portion of the string for
>> getting the information about the parameter names and default values.

Are there Sphinx conventions for this? If so -- I'd go with that. Sphinx
is becoming the python doc standard (and it's a good one)

> On Sun, Jan 16, 2011 at 8:47 PM, David Lyon

> Sounds like an oximoron..
>
> You are making a tool for coding screens but you prefer to do
> it by hand in any case..
>
> So why do you need a tool?

First -- it's not a need, but I think the real point was that the other
tools he's looked at make it harder than hand-coding -- he's trying to
make one that he will want to use!

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

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

Chris....@noaa.gov

Cody Precord

unread,
Jan 19, 2011, 11:10:05 AM1/19/11
to wxpyth...@googlegroups.com
Hi,

On Tue, Jan 18, 2011 at 5:55 PM, Christopher Barker
<Chris....@noaa.gov> wrote:
> On 1/14/11 11:53 AM, Cody Precord wrote:
>>
>> Hello,
>>
>> I would like to introduce an early look at a little something that I
>> have been working on in my spare minutes over the last several weeks.
>> I am currently calling it Eguid
>
>> Screencast: http://editra.org/uploads/test/eguid_prototype.avi
>
> Very cool! nice work!
>
>> hide the usage of sizers,
>
> Hide, or not use at all? -- it sure looks like absolute positioning. Please
> don't do that! I'm convinced that auto-layout of some sort is critical for
> maintainable system, even if you are using a GUI GUI-Builder.

Yes, the generated application code will always use sizers, the point
is that from the designer you wont have to know anything about them,
how they work, or that they are even there. The view shown in the
video is just the Designer which will allow you to quickly and easily
place the controls where you generally want them to be.

The plan is that when the actual interface is generated from the
designer view that the absolute positioning in the designer will be
used as the inputs into generating the sizer managed layout. Writing
an algorithm to do this while not trivial should not be very difficult
either since it is a simple 2D plain of rectangles (though I haven't
had time to have a real go at writing it yet ;) ).

There is another idea that I am also playing around with, with
allowing the designer to be used in a sloppy mode which where you will
just kind of generally put things where you would like them to be, not
worrying about alignment or positioning very much. Then when it
generates it will fix everything based on decision rules using
platform standards for things such as margins/spacing and will do the
proper alignments based on the fuzzy alignments done in the designer.

>
> On 1/16/11 3:52 PM, Cody Precord wrote:
>>
>>  You will just just create a layout by putting the
>> controls where you want and then optionally apply behaviors for the
>> layout such as alignment and grow factors.
>
> Hmm -- I still think that the alignment shouldn't be "optional". In fact,
> while perhaps most people are visual, and thus think: "I want a button
> here", I think that actual layout ALWAYS has structure:

By optional I was referring to the ability to augment the defaults in
the Inspector dialog, similar to the way it is done in the XCode
Interface Builder to apply stretching and other properties to
individual controls.

>>> Secondly, there is a common practice with documentation and analysis
>>> tools
>>> to look at a function/method's docstring and see if it appears to start
>>> with
>>> (after any leading white space and before an empty line) a function
>>> prototype for the method, and if so, to use that portion of the string
>>> for
>>> getting the information about the parameter names and default values.
>
> Are there Sphinx conventions for this? If so -- I'd go with that. Sphinx is
> becoming the python doc standard (and it's a good one)

<side-rant>Well its a Python doc standard for now, however this seems
to change every year or two so will see...</side-rant>

>
>> On Sun, Jan 16, 2011 at 8:47 PM, David Lyon
>>    Sounds like an oximoron..
>>
>>    You are making a tool for coding screens but you prefer to do
>>    it by hand in any case..
>>
>>    So why do you need a tool?
>
> First -- it's not a need, but I think the real point was that the other
> tools he's looked at make it harder than hand-coding -- he's trying to make
> one that he will want to use!

Bingo! Chris gets a cookie ;)

Cody

Christopher Barker

unread,
Jan 19, 2011, 1:43:42 PM1/19/11
to wxpyth...@googlegroups.com
On 1/19/11 8:10 AM, Cody Precord wrote:

> Yes, the generated application code will always use sizers, the point
> is that from the designer you wont have to know anything about them,
> how they work, or that they are even there.

hmmm -- I do like the idea of that, but ...

> The view shown in the
> video is just the Designer which will allow you to quickly and easily
> place the controls where you generally want them to be.
>
> The plan is that when the actual interface is generated from the
> designer view that the absolute positioning in the designer will be
> used as the inputs into generating the sizer managed layout. Writing
> an algorithm to do this while not trivial should not be very difficult
> either since it is a simple 2D plain of rectangles (though I haven't
> had time to have a real go at writing it yet ;) ).

Well, yes, though I'm not sure sizers actually support a totally
arbitrary positions, and nor should they -- it could be a mess.

If you do want to support essentially arbitrary positioning, you may
need to write a new sizer.

> There is another idea that I am also playing around with, with
> allowing the designer to be used in a sloppy mode which where you will
> just kind of generally put things where you would like them to be, not
> worrying about alignment or positioning very much. Then when it
> generates it will fix everything based on decision rules using
> platform standards for things such as margins/spacing and will do the
> proper alignments based on the fuzzy alignments done in the designer.

This I really like! -- maybe it could be my "nice GUI interface to
sizers". i.e. a user creates a bunch of buttons and drags them more or
less in a column -- this gets translated by your tool into an actual
VERTICAL box sizer. Though I suspect that this will be pretty hard to do!

Another thought: I read an article a while back (sorry -- I have no idea
where), about how it is important that the UI of an application
represents the internal data model of the application. Otherwise, the
user's expectations are likely to get confused. It may be that you want
to design the UI first, and the internal data model second, if you have
an idea of what the user's model should be.

I have a personal opinion about that, though. Sometimes people try to
make an application "intuitive", by matching the UI (and internal data
model) to users' existing expectations. After all, "intuitive" means
"behaves the way a user expects it to". However, there is a problem with
that:

Computer's strengths are different that people's strengths. A really
good computer program will take advantage of the strengths of a
computer. This MAY require that the underlying data model is different
than what a human would come up with on their own.

Take document generation systems:

One thing a computer should be able to do is create indexes and tables
of contents, cross references, etc. perfectly. However, in order to do
that, the internal data model needs to reflect the structure of the
document -- what is a section, what is a figure, what is an equation,
and so on. I'm a LaTeX fan -- when you write a LateX document, you
define what every element of a document is: a section heading, an
equation, etc. As a result, LaTeX can build the contents, cross
reference equations, generate a bibliography, etc, for you perfectly.

Use a standard word processor, however, and none of that works very well
-- why? because the document model is not complete, and even worse, the
UI encourages the user to think of visual, rather than structural
design. I understand that someone that really knows how to use MS Word
can do all that pretty well with the proper use of styles, etc, but I've
literally NEVER seen anyone do it right. NEVER. That is because the UI
not only allows you, but encourages you, to write documents thinking
visually, rather than structurally:

"I want this text bold and in a 24 pt font"

rather than:

"This is a section title"

Word processors are particularly ugly because they support two data
models at once: "paragraph styles", etc and also free-form styling.

OK -- on to your problem. My argument before was that the internal data
model should reflect the structure of the GUI: "this is a column of
buttons", etc, etc. If that's the case, then I think the UI should
reflect that to the user, otherwise they will get confused.

It may be that you can write code that examines the hand-done layout and
finds the rows, columns, grids, etc. that are there. However, I think
it's likely that that will end up confusing the user instead -- if your
code gets it right, it will be really cool, but if it gets it wrong,
then it'll be a source of major frustration -- "why the heck did that
button move?". Kind of like almost every nifty auto-tool that MS Word
has. 20% of time it does the wrong thing, and that adds far more
frustration than the 80% of the time that it gets it right saves me.

In any case, you'd better be darn sure that it's easy to override the
decisions that your code makes about the structure of the layout --that
requires that the user UNDERSTAND the structure of the layout -- it
needs to be clear.

Here's one simple example -- ascii art:

---------
| but 1 |
---------

---------
| but 2 |
---------

----------
| but 3 |
---------

--------- --------- --------- ---------
| but 4 | | but 5 | | but 6 | | but 7 |
--------- --------- --------- ---------


OK -- so it would be pretty easy to see that that is a column of buttons
along the left, and a row along the bottom. However, where does button 4
go? Is it at the bottom of the column or the left or the row? Here it
makes no difference, but when the user changes something, it may matter
-- so it should be clear to the user what structure is being used, and
clear how to change that structure.

I fully understand that many users really do want to "just put the
widget where I want it", and if you can come up with a UI and logic that
will both allow that and get the internal structure right for
auto-layout and easy re-factoring -- WOW! you will have developed a
great tool.


However, my suggestion:

I know that most folks seem to struggle with the sizer-based GUI
builders (wxDesigner is the only one that I've used). But I think that
the reason they are so hard is not inherent to the idea but that the
Sizer API kind of sucks, and that the tools tend to map pretty directly
to the API. I think the Tool SHOULD map pretty directly to the sizer
model, but not necessarily to the API.

For example, in wxDesigner, when you go to edit a SizerItem's
properties, it actually has a field for "option" -- what the heck does
that mean? Well, for some historic reason, "option" is actually the
weighting parameter for how much an item should stretch -- we know that,
'cause we've written the code my hand, but how intuitive is that? But
simply re-naming that to "stretch factor" or something helps a lot.
Also, the FLAGS are a catch-all for a bunch of unrelated properties.

So I think you could write a UI that presented the user with a
visualization of the sizer model, but was easy to understand and use.
And might even map better to users' existing way of thinking about
design: "I want a row of buttons" -- "I want a these to line up", etc,
etc. But I can't say I know how to do that!

I think another stumbling block is that while people may think of layout
in terms of structure -- rows of things, they also think of
functionality before layout:

first: I need an OK and Cancel button, and text field, and a color selector.

second: now where should they go?

I think that's why people like UI designers that let you click a button
icon, then give it a label, then drag it somewhere, then drag it around
later to a different place -- it follows a natural train of though.

In contrast, with traditional Sizer-based layout, you need to FIRST
create the layout structure -- a row of buttons, THEN create the buttons
themselves.

Interestingly, when you write code, you do it the first way (I do
anyway) -- first I create the widgets, then the sizers, then put the
widgets in the sizers. Maybe your UI can reflect that process.

Wow! I got long winded -- I hope this helps.

> Bingo! Chris gets a cookie ;)

I'll take a virtual one 'till I run into you somewhere in person...

-Chris

PS: one more thought -- for this, and for code writing, maybe dump all
sizers except GridBagSizer -- every other one is a simplification of
that one.

Kevin Ollivier

unread,
Jan 19, 2011, 3:16:07 PM1/19/11
to wxpyth...@googlegroups.com
Hi Chris,

On Jan 19, 2011, at 10:43 AM, Christopher Barker wrote:

[snip]

> However, my suggestion:
>
> I know that most folks seem to struggle with the sizer-based GUI builders (wxDesigner is the only one that I've used). But I think that the reason they are so hard is not inherent to the idea but that the Sizer API kind of sucks, and that the tools tend to map pretty directly to the API. I think the Tool SHOULD map pretty directly to the sizer model, but not necessarily to the API.
>
> For example, in wxDesigner, when you go to edit a SizerItem's properties, it actually has a field for "option" -- what the heck does that mean? Well, for some historic reason, "option" is actually the weighting parameter for how much an item should stretch -- we know that, 'cause we've written the code my hand, but how intuitive is that? But simply re-naming that to "stretch factor" or something helps a lot. Also, the FLAGS are a catch-all for a bunch of unrelated properties.
>
> So I think you could write a UI that presented the user with a visualization of the sizer model, but was easy to understand and use. And might even map better to users' existing way of thinking about design: "I want a row of buttons" -- "I want a these to line up", etc, etc. But I can't say I know how to do that!

Personally, I like how IB handles it. You explicitly position controls (with alignment guides to line things up), but then identify how they should align and stretch. You don't really set borders, you just 'get' the HIG border. This approach is definitely more simplified than sizers but they work quite well in my experience so far, and they're intuitive. A few clicks and voila, your iPhone interface is able to auto-rotate between landscape and portrait (or can expand if the window is enlarged for desktop apps) perfectly. And building a GUI is so much faster.

As such, I think the conceptual approach best suited for this sort of GUI Builder is to consider every control a 'box' with properties of stretching and alignment, although I wonder if that approach is perhaps more like layout constraints than sizers.

I think the thing to remember about sizers is that they make hard layouts possible, but I'm not sure that they're very good at making common layouts easy. Sometimes requiring that a few corner cases need a bit of hacking is an okay trade-off when it makes a vast majority of cases more intuitive. You say "the problem with that" a lot in this email, but the reality is, all approaches have trade-offs. It's not about finding the solution that has no problems, it's about finding the solution that offers you the most benefits with the fewest problems, and sometimes the most robust solution isn't always best. I've seen a lot of APIs and such get hopelessly complex (and make easy cases less easy) in order to ensure they handle minor corner cases when a clear and documented workaround for the corner cases instead could have kept the API a lot simpler and suited people just fine. As they say, the perfect is the enemy of the good. ;-) After all, GUI Builders exist to speed up the development process (and IMHO also help with separation of concerns), and I think being able to build 90% of layouts in it quickly is much better than being able to build 100% in it slowly or painstakingly. ;-)

All I know is that I wish Cody luck on this. A tool like this would really help expand wxPython's reach, and from his video it looks better than any of the other GUI Builders I've played with!

Best,

Kevin

> I think another stumbling block is that while people may think of layout in terms of structure -- rows of things, they also think of functionality before layout:
>
> first: I need an OK and Cancel button, and text field, and a color selector.
>
> second: now where should they go?
>
> I think that's why people like UI designers that let you click a button icon, then give it a label, then drag it somewhere, then drag it around later to a different place -- it follows a natural train of though.
>
> In contrast, with traditional Sizer-based layout, you need to FIRST create the layout structure -- a row of buttons, THEN create the buttons themselves.
>
> Interestingly, when you write code, you do it the first way (I do anyway) -- first I create the widgets, then the sizers, then put the widgets in the sizers. Maybe your UI can reflect that process.
>
> Wow! I got long winded -- I hope this helps.
>
>> Bingo! Chris gets a cookie ;)
>
> I'll take a virtual one 'till I run into you somewhere in person...
>
> -Chris
>
> PS: one more thought -- for this, and for code writing, maybe dump all sizers except GridBagSizer -- every other one is a simplification of that one.
>
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chris....@noaa.gov
>

Nat Echols

unread,
Jan 19, 2011, 3:23:44 PM1/19/11
to wxpyth...@googlegroups.com
On Wed, Jan 19, 2011 at 12:16 PM, Kevin Ollivier <kevin...@theolliviers.com> wrote:
Personally, I like how IB handles it. You explicitly position controls (with alignment guides to line things up), but then identify how they should align and stretch. You don't really set borders, you just 'get' the HIG border. This approach is definitely more simplified than sizers but they work quite well in my experience so far, and they're intuitive. A few clicks and voila, your iPhone interface is able to auto-rotate between landscape and portrait (or can expand if the window is enlarged for desktop apps) perfectly. And building a GUI is so much faster.

Interface Builder is awesome, and every time I get stuck in sizer hell I wish all of my users had the wisdom (and, well, disposable income) to buy Macs.  However, the reason it's able to make explicit positioning work is that it's aimed at exactly *one* control set, instead of cross-platform portability.  Even with sizers, an arrangement that makes sense on Mac may look wretched on Linux, and I haven't even started working with Windows yet.

-Nat

Robin Dunn

unread,
Jan 19, 2011, 3:24:27 PM1/19/11
to wxpyth...@googlegroups.com
On 1/19/11 10:43 AM, Christopher Barker wrote:

> Well, yes, though I'm not sure sizers actually support a totally
> arbitrary positions, and nor should they -- it could be a mess.
>
> If you do want to support essentially arbitrary positioning, you may
> need to write a new sizer.

If you look at it from the perspective of sizers defining the size and
positioning *relationships* between the items on a form and also the
form itself, then taking the next step and allow to also define those
same relationships with a DnD GUI builder tool is not too great of a
leap. Then it is just a matter of mapping DnD defined relationships at
design time into Sizer relationships at run time.

If a particular design layout can not be mapped to a basic box and/or
flexgrid sizer layout then it can always fall back to a wx.GridBagSizer
and use row/col spanning to make things be sized, positioned and aligned
close to how they are in the design layout. In the worst case you may
end up using a lot of little cells because the design time relationships
don't line up or whatever, but even if it ends up with, for example,
enough grid cells such that they are about 1/8 inch on screen then it
ends up being like an old-style design tool that uses absolute
positioning and snap-to-grid.

> PS: one more thought -- for this, and for code writing, maybe dump
> all sizers except GridBagSizer -- every other one is a
> simplification of that one.
>

That's the approach taken with a form designer used in my day-job, a GBS
is always used for layout of components on the form. It's a somewhat a
higher-level of design functionality than what is being discussed here
(as the "components" are almost never single widgets and will have their
own panels, sizers etc. as needed) but in this case the GBS works well
for dealing with the top-level of the layout. During design time the
grid is visible and the user can DnD a component into an empty cell, and
then increment/decrement the number of rows/columns spanned as needed,
and so forth.

Robin Dunn

unread,
Jan 19, 2011, 3:50:21 PM1/19/11
to wxpyth...@googlegroups.com
On 1/19/11 12:16 PM, Kevin Ollivier wrote:

> As such, I think the conceptual approach best suited for this sort of
> GUI Builder is to consider every control a 'box' with properties of
> stretching and alignment, although I wonder if that approach is
> perhaps more like layout constraints than sizers.

Starting with the "everything is a box" concept, the designer could
allow the user to "group" a collection of boxes together into a new box.
If they select a group of boxes that are oriented vertically or
horizontally then that group could be implemented as a box sizer at
runtime. If the grouped boxes don't fit in a single column or row then
one of the grid sizers would be used. The design tool could then treat
the groups as just another box for when specifying other relationships

So to follow Chis's (and incidentally, the way I usually do it too)
implementation sequence of:

0. (draw the layout on paper if needed)
1. create the widgets
2. create the sizers
3. add widgets to sizers
x. (binding events is part of the typical sequence too)

The design tool could follow this same pattern by encouraging the user
to first select the widgets (boxes) they want to have on the form with
DnD and use the mouse to position them more or less how they want them
to be in the end result. (This is steps 0 and 1 above.)

When they have things basically the way they want the layout to be, then
the tool could allow the user to define the layout relationships by
group-selecting the widgets (or other groups) that should have a layout
relationship of some kind (another box). (Steps 2 and 3.) Another cool
feature would be for the design tool to suggest some likely box
groupings based on the manual layout that was done by the user.

All boxes, whether widgets or a group of widgets could have some common
properties that can be edited, and the tool can deal with them as widget
properties, sizer add flags, or whatever is needed when creating the
code for the sizer layout.

Ok, there's my $0.02 ideas for the moment.

Kevin Ollivier

unread,
Jan 19, 2011, 4:29:51 PM1/19/11
to wxpyth...@googlegroups.com
Hi Nat,

Right, but as you say, that's a problem even with sizers, so how are sizers helping you in this case? I'd be surprised to learn that much of the sizer logic is even platform aware because, aside from standard dialog button placement, I'm pretty sure the sizer implementation is almost completely platform agnostic from poking around sizer.cpp. Sizers would be no more, or no less, useful for writing a platform-specific app then they would a cross-platform one, and I think the same point applies to the IB approach for the most part.

As for the case you mention, I ran across this with my iOS app when I wanted to scale the UI to iPad. A number of the choices I made, which worked well on iPhone, were far from ideal on iPad. I ended up creating separate iPhone and iPad UIs. UI prototyping is so quick, and the UIs differed enough, that this was simpler than writing some code to share the UI and automatically change everything that needed changed. (They actually have a 'conversion' tool to get you started too.) 

One benefit I noticed that I hadn't considered when I first did it, as well, is that this approach encourages me to consider each platform's UI separately, and thus, to consider what design is best suited to that particular platform. This helps me avoid the urge to compromise on "middle of the road" UI approaches that focus on reducing UI maintenance (which is what I want), rather than optimizing the UI experience for the platform it's being run on (which is what my users want). The more you can focus on the latter, the better your chances of increasing user adoption.

Regards,

Kevin

-Nat

Kevin Ollivier

unread,
Jan 19, 2011, 4:46:47 PM1/19/11
to wxpyth...@googlegroups.com
Hi Robin,

On Jan 19, 2011, at 12:50 PM, Robin Dunn wrote:

> On 1/19/11 12:16 PM, Kevin Ollivier wrote:
>
>> As such, I think the conceptual approach best suited for this sort of
>> GUI Builder is to consider every control a 'box' with properties of
>> stretching and alignment, although I wonder if that approach is
>> perhaps more like layout constraints than sizers.
>
> Starting with the "everything is a box" concept, the designer could allow the user to "group" a collection of boxes together into a new box. If they select a group of boxes that are oriented vertically or horizontally then that group could be implemented as a box sizer at runtime. If the grouped boxes don't fit in a single column or row then one of the grid sizers would be used. The design tool could then treat the groups as just another box for when specifying other relationships
>
> So to follow Chis's (and incidentally, the way I usually do it too) implementation sequence of:
>
> 0. (draw the layout on paper if needed)
> 1. create the widgets
> 2. create the sizers
> 3. add widgets to sizers
> x. (binding events is part of the typical sequence too)
>
> The design tool could follow this same pattern by encouraging the user to first select the widgets (boxes) they want to have on the form with DnD and use the mouse to position them more or less how they want them to be in the end result. (This is steps 0 and 1 above.)

I think the issue here is that this approach is inherently not suited for rapid GUI prototyping. If I were to do this (as I do now when I'm using wxPython), I wouldn't use a GUI Builder, I'd code it up. It's more efficient that way, and the goal of a GUI Builder is supposed to be to save me time. If it's not serving that purpose, I have no reason to use it. Requiring these steps in one form or another with the GUI Builder also makes this unlike other GUI Builders, so people will be confused when trying to learn this GUI Builder after using others, so it's probably better to suggest they just code it up instead.

My point about using IB is that it gives me layouts like the ones I get with wxPython, but it doesn't require all those steps. I think everyone here assumes that is simply because it's not cross-platform, but I'm not yet convinced of that. Sizers make controls stretch to fill available space, or align to a specific area of the dialog relative to other controls. IB lets you do this too. The only thing that I can see off-hand that IB doesn't address is that on different platforms, the control's border should differ to match the platform's HIGs. That being said, sizers (out of the box) don't help you with this either.

You probably could come up with some case where IB's layout tools don't cut the mustard, but the purpose of a GUI Builder is to speed up the app building process. Even if the GUI Builder doesn't handle every case, so long as it handles enough cases that I can use it for building a majority of my GUI, it saves me more time than doing it using the above process, and for new users, this gets them to "Hello World" in less time and with less chances for coding errors. In my book, that means that despite its flaws, I and others are still ahead of the game in terms of speed and maintenance by using the GUI Builder.

Thanks,

Kevin

> When they have things basically the way they want the layout to be, then the tool could allow the user to define the layout relationships by group-selecting the widgets (or other groups) that should have a layout relationship of some kind (another box). (Steps 2 and 3.) Another cool feature would be for the design tool to suggest some likely box groupings based on the manual layout that was done by the user.
>
> All boxes, whether widgets or a group of widgets could have some common properties that can be edited, and the tool can deal with them as widget properties, sizer add flags, or whatever is needed when creating the code for the sizer layout.
>
> Ok, there's my $0.02 ideas for the moment.
>
> --
> Robin Dunn
> Software Craftsman
> http://wxPython.org
>

Christopher Barker

unread,
Jan 19, 2011, 5:10:43 PM1/19/11
to wxpyth...@googlegroups.com
On 1/19/11 12:16 PM, Kevin Ollivier wrote:
> Personally, I like how IB handles it.

I suppose I need to try that out eventually...

>Sometimes requiring that a few corner cases need a
> bit of hacking is an okay trade-off when it makes a vast majority of
> cases more intuitive.

Sure -- a solution that makes the easy things easy, and the hard things
possible is better than one that makes everything hard!

I still don't think Sizers are inherently difficult, I think the API
sucks. Also some of the implementation -- for instance, on wxMac,
buttons seem to have a size that is exactly the size of the button, but
they actually draw a little bit outside that size. So you HAVE to have a
larger border around Mac buttons than on other platforms. That should be
taken care of by either smart sizers or by wxButton itself, it should
simple use a larger "size".

> You say "the problem with that" a lot in this email

you got me!

So, despite the enormous amount I wrote, and all the "problems with
that", here are the key points:

1) Auto layout is MUCH better than explicit positioning.

2) The UI should reflect the layout model being used internally.

3) Custom controls should be just as easy to add as standard ones.

It sounds like IB does the first two -- I don't know about the third.

As for Cody -- I suppose he's stuck with the decision on whether to rely
on Sizers, or create yet-another-layout-system. (or use layout
constraints, I suppose)

On 1/19/11 12:24 PM, Robin Dunn wrote:
> wx.GridBagSizer
> and use row/col spanning to make things be sized, positioned and aligned
> close to how they are in the design layout. In the worst case you may
> end up using a lot of little cells because the design time relationships
> don't line up or whatever, but even if it ends up with, for example,
> enough grid cells such that they are about 1/8 inch on screen then it
> ends up being like an old-style design tool that uses absolute
> positioning and snap-to-grid.

That's a pretty good idea, actually. With the right UI -- that could be
a nice solution.

> That's the approach taken with a form designer used in my day-job,

Is this proprietary code? It sounds useful.

On 1/19/11 1:29 PM, Kevin Ollivier wrote:

> "middle of the road" UI approaches that focus on reducing UI maintenance
> (which is what I want), rather than optimizing the UI experience for the
> platform it's being run on (which is what my users want).

Well, we want the UI to be as similar as possible across platforms, as a
lot of our users use multiple platforms, using the same source helps
this. (not that there shouldn't platform specific tweaking)

On 1/19/11 1:46 PM, Kevin Ollivier wrote:
>> The design tool could follow this same pattern by encouraging the
>> user to first select the widgets (boxes) they want to have on the
>> form with DnD and use the mouse to position them more or less how
>> they want them to be in the end result. (This is steps 0 and 1
>> above.)

> I think the issue here is that this approach is inherently not suited for rapid GUI prototyping.

with a good UI -- I think it is. All those steps need to be done, but
the UI can make it easy, and do the easy ones for you.

> My point about using IB

I'll have to try it, but don't you have to do all that with IB one way
or another?

> Personally, I like how IB handles it. You explicitly position
> controls (with alignment guides to line things up),

OK -- that's the same.

> but then identify how they should align and stretch.

That's about the same as putting them in a box together.

> You don't really set borders, you > just 'get' the HIG border.

Well, we all think the way sizers handle borders is pretty poor...But
the tool could help by setting the defaults to match the HIG.

> Requiring these steps in one form or another with the GUI Builder
> also makes this unlike other GUI Builders, so people will be confused
> when trying to learn this GUI Builder after using others

This is a key problem with any interface design: intuitive means
"working like the user expects". If the user is used to another GUI
builder they will expect this one to work similarly. however, ifteh
underlying model of "most" GUI builders is broken, you have a problem --
users will simply HAVE to learn something else.

One idea I have to help with the fact that people do want to define a
GUI element before they define a layout is to allow a widget to be
dfeined and be "free-floating" -- let them stick it anywhere, but your
not done until it's layout is somehow defined. This is exactly like code
-- you can create a widget with wx.DefaultPosition and it still exists,
it'll get drawn wrong without some layout, but it can exist.

I'll need to check out IB -- but other absolute positioning systems I"ve
used (include powerpoint, by the way). let you do things like select a
bunch of widgets, and set them to be all lined up down the middle, or
all the same size, or all lined up on the left. The problem is that they
then set the positions, and that "line up" info is lost.

If, instead, you selected the widgets, defined their alignment, and that
definition was stored (and probably converted to sizer code). You'd be
in good shape.

Good conversation, anyway!

-Chris

Mike Rans

unread,
Jan 19, 2011, 4:32:31 PM1/19/11
to wxPython-dev, ra...@email.com
This looks fantastic. Could the code be structured to allow both a
standalone application and an Editra plugin?

Robin Dunn

unread,
Jan 19, 2011, 6:32:58 PM1/19/11
to wxpyth...@googlegroups.com
On 1/19/11 2:10 PM, Christopher Barker wrote:
> On 1/19/11 12:24 PM, Robin Dunn wrote:
>> wx.GridBagSizer
>> and use row/col spanning to make things be sized, positioned and aligned
>> close to how they are in the design layout. In the worst case you may
>> end up using a lot of little cells because the design time relationships
>> don't line up or whatever, but even if it ends up with, for example,
>> enough grid cells such that they are about 1/8 inch on screen then it
>> ends up being like an old-style design tool that uses absolute
>> positioning and snap-to-grid.
>
> That's a pretty good idea, actually. With the right UI -- that could be
> a nice solution.
>
>> That's the approach taken with a form designer used in my day-job,
>
> Is this proprietary code? It sounds useful.

It is proprietary, but it's rather hacky and kludgy so I'm not sure I
would want to share it even if it was possible to do so. (The code has
had multiple people poking at it now and then for a long time, bolting
on features or fixes as needed without a lot of forethought...)

Kevin Ollivier

unread,
Jan 19, 2011, 6:55:30 PM1/19/11
to wxpyth...@googlegroups.com
Hi Chris,

On Wed, Jan 19, 2011 at 2:10 PM, Christopher Barker <Chris....@noaa.gov> wrote:
On 1/19/11 12:16 PM, Kevin Ollivier wrote:
Personally, I like how IB handles it.

I suppose I need to try that out eventually...

Sometimes requiring that a few corner cases need a
bit of hacking is an okay trade-off when it makes a vast majority of
cases more intuitive.

Sure -- a solution that makes the easy things easy, and the hard things possible is better than one that makes everything hard!

I still don't think Sizers are inherently difficult, I think the API sucks. Also some of the implementation -- for instance, on wxMac, buttons seem to have a size that is exactly the size of the button, but they actually draw a little bit outside that size. So you HAVE to have a larger border around Mac buttons than on other platforms. That should be taken care of by either smart sizers or by wxButton itself, it should simple use a larger "size".

 You say "the problem with that" a lot in this email

you got me!

I think you took that wrong. ;-) I was trying to point out that sometimes "problem" is relative, or, at least, that some problems just aren't that big of a deal when you leave abstract arguments and think about practical costs like time and effort.
 
So, despite the enormous amount I wrote, and all the "problems with that", here are the key points:

1) Auto layout is MUCH better than explicit positioning.

2) The UI should reflect the layout model being used internally.

3) Custom controls should be just as easy to add as standard ones.

It sounds like IB does the first two -- I don't know about the third.

It does, in a manner of speaking. :) I don't really think there is an "internal" vs. "external" model. As an example, explicit positioning is allowed, and I use it all the time. It's just that when something changes that would affect layout (e.g. the window is resized), it uses the layout rules you set to calculate the control's new size and position. So at design time, this means the GUI Builder isn't mucking with what you tell it to do. The changes happen at runtime.
 
As for Cody -- I suppose he's stuck with the decision on whether to rely on Sizers, or create yet-another-layout-system. (or use layout constraints, I suppose)

On 1/19/11 12:24 PM, Robin Dunn wrote:
wx.GridBagSizer
and use row/col spanning to make things be sized, positioned and aligned
close to how they are in the design layout. In the worst case you may
end up using a lot of little cells because the design time relationships
don't line up or whatever, but even if it ends up with, for example,
enough grid cells such that they are about 1/8 inch on screen then it
ends up being like an old-style design tool that uses absolute
positioning and snap-to-grid.

That's a pretty good idea, actually. With the right UI -- that could be a nice solution.

That's the approach taken with a form designer used in my day-job,

Is this proprietary code? It sounds useful.


On 1/19/11 1:29 PM, Kevin Ollivier wrote:

"middle of the road" UI approaches that focus on reducing UI maintenance
(which is what I want), rather than optimizing the UI experience for the
platform it's being run on (which is what my users want).

Well, we want the UI to be as similar as possible across platforms, as a lot of our users use multiple platforms, using the same source helps this. (not that there shouldn't platform specific tweaking)

I know, but it all depends on the case. In some cases, that approach is just fine; in others, it means using some fairly non-native approaches that can really hurt your app's chances of succeeding on a particular platform. e.g. in a number of ways, wxAUI really looks and feels foreign on Mac. (wxTreeCtrl is another one...) I was talking about handling this sort of case.

On 1/19/11 1:46 PM, Kevin Ollivier wrote:
The design tool could follow this same pattern by encouraging the
user to first select the widgets (boxes) they want to have on the
form with DnD and use the mouse to position them more or less how
they want them to be in the end result. (This is steps 0 and 1
above.)

I think the issue here is that this approach is inherently not suited for rapid GUI prototyping.

with a good UI -- I think it is. All those steps need to be done, but the UI can make it easy, and do the easy ones for you.

I think the discussion is getting a bit abstract, but my idea of a good UI is one that can change quickly and easily. You don't have to think about the boxes you want to put things into in order to achieve the appropriate layout algorithm. You shouldn't have to "reorganize your layout boxes" if you want to change the layout in any meaningful way. I could be misunderstanding something though.
 

 > My point about using IB

I'll have to try it, but don't you have to do all that with IB one way or another?

Robin's steps #1-3 are really just two steps:

1) add widgets to window
2) set their layout properties

They don't have 'sizers', and #0 pretty much become unnecessary because you thus don't need to consider layout before designing your window.
 

> Personally, I like how IB handles it. You explicitly position
> controls (with alignment guides to line things up),

OK -- that's the same.


> but then identify how they should align and stretch.

That's about the same as putting them in a box together.

Conceptually, yes. From a user experience perspective, though, it's very different.
 
> You don't really set borders, you > just 'get' the HIG border.

Well, we all think the way sizers handle borders is pretty poor...But the tool could help by setting the defaults to match the HIG.


> Requiring these steps in one form or another with the GUI Builder
> also makes this unlike other GUI Builders, so people will be confused > when trying to learn this GUI Builder after using others

This is a key problem with any interface design: intuitive means "working like the user expects". If the user is used to another GUI builder they will expect this one to work similarly. however, ifteh underlying model of "most" GUI builders is broken, you have a problem -- users will simply HAVE to learn something else.  
One idea I have to help with the fact that people do want to define a GUI element before they define a layout is to allow a widget to be dfeined and be "free-floating" -- let them stick it anywhere, but your not done until it's layout is somehow defined. This is exactly like code -- you can create a widget with wx.DefaultPosition and it still exists, it'll get drawn wrong without some layout, but it can exist.

I'll need to check out IB -- but other absolute positioning systems I"ve used (include powerpoint, by the way). let you do things like select a bunch of widgets, and set them to be all lined up down the middle, or all the same size, or all lined up on the left. The problem is that they then set the positions, and that "line up" info is lost.
 
If, instead, you selected the widgets, defined their alignment, and that definition was stored (and probably converted to sizer code). You'd be in good shape.

Here's a quick tutorial on how IB's "autosizing" and anchors work (sorry for the ad!):


An interesting difference that this shows quite clearly is that it doesn't "move" elements on initial layout, it only defines how they move when the window size changes. So it has both the sizer concept of dynamically changing layout, and also the WYSIWYG concept common among GUI Builders. And the designer is not thinking in terms of defining layout algorithms to adjust groups of controls, just simply in terms of "in what direction and with what stretching do I want this element to move when the size changes?" Sizers tend to be designed around groups of controls, but that makes them a poor choice for GUI Builders because you need to know what type of layout you want for your group before you start designing it. In IB, it's a non-issue.

Thanks,

Kevin
 
Good conversation, anyway!

-Chris








--
Christopher Barker, Ph.D.
Oceanographer

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

Chris....@noaa.gov

Christopher Barker

unread,
Jan 20, 2011, 1:44:40 PM1/20/11
to wxpyth...@googlegroups.com
I suppose we are OT here, but...

On 1/19/11 3:55 PM, Kevin Ollivier wrote:
> I was trying to point out that
> sometimes "problem" is relative, or, at least, that some problems just
> aren't that big of a deal when you leave abstract arguments and think
> about practical costs like time and effort.

believe me, I am -- maybe I'm stretching to a different realm, but I
know for sure that WYSIWG word processors waste peoples time immensely
-- at least when writing substantial structured documents.

I spent almost NO time on formatting my dissertation to match the
University standard, or get the bibliography right, or cross reference
figure and tables or... -- I simply used LaTeX and a document style some
else had written. The computer did what computers do well, and took care
of all that for me. I saw folks use MSWord for that kind of thing, and
it's painful -- and I see that every day at work, too.

Does that lesson apply to a GUI-builder? I think so.

Does IB follow the lesson? maybe so. I'm not arguing that the IB
approach isn't fabulous -- it may well be.

> It does, in a manner of speaking. :) I don't really think there is an
> "internal" vs. "external" model.

By definition, there is -- if it doesn't appear that there is one, then
they are probably well matched.

> As an example, explicit positioning is
> allowed, and I use it all the time. It's just that when something
> changes that would affect layout (e.g. the window is resized), it uses
> the layout rules you set to calculate the control's new size and
> position.

That only sounds like semi-explicit positioning to me -- maybe the
anchor point is explicit, but the size not? But it sounds like the
anchor point could move too, as other widgets grow, so maybe only the
original (best?) position is explicit?

> So at design time, this means the GUI Builder isn't mucking
> with what you tell it to do. The changes happen at runtime.

But at design time, you'll want to know what's going to happen at run
time -- I assume there is a way to test that.

> As for Cody -- I suppose he's stuck with the decision on whether to
> rely on Sizers, or create yet-another-layout-system. (or use layout
> constraints, I suppose)

> e.g. in a number of ways, wxAUI really looks and feels foreign
> on Mac. (wxTreeCtrl is another one...) I was talking about handling this
> sort of case.

Ideally, those would be made more native at the wx level, rather than
the app level, but we don't live in a ideal world!

> I think the discussion is getting a bit abstract, but my idea of a good
> UI is one that can change quickly and easily. You don't have to think
> about the boxes you want to put things into in order to achieve the
> appropriate layout algorithm. You shouldn't have to "reorganize your
> layout boxes" if you want to change the layout in any meaningful way. I
> could be misunderstanding something though.

What I'm thinking is that a good UI might be able to make all that box
stuff intuitive an easy -- but I don't know how!

> #0 pretty much become unnecessary because
> you thus don't need to consider layout before designing your window.

That's a key point -- and one I was trying to make -- Robin added the
#0, my point was that users don't want to do that -- they first know
what widgets they want, THEN the want to think about how to lay them
out, and they probably want to do that visually with the tool, not on
paper. Personally, I don't mind paper, we we tend to have designers work
on layout ahead of time in who knows what drawing tools. However, it
would be nice if they could just draw it out with the real tool.


> > but then identify how they should align and stretch.
> That's about the same as putting them in a box together.
>
> Conceptually, yes. From a user experience perspective, though, it's very
> different.

We don't know that, cause we haven't seen Cody's fabulous tool yet!


> Here's a quick tutorial on how IB's "autosizing" and anchors work (sorry
> for the ad!):
>
> http://www.mefeedia.com/watch/28278358
>
> An interesting difference that this shows quite clearly is that it
> doesn't "move" elements on initial layout, it only defines how they move
> when the window size changes.

What I notice right away is that the first version of the dialog doesn't
respond to a changing Window size at all. What that says to me is that
the tool makes it easy, and perhaps encourages you, to not do it
"right". I think that's a bad thing.

It reminds me of working with one of our designers, and she had a
PageMaker layout where she actually used spaces to indent some text to
fit in an image! What a mess -- I think the tool shouldn't make that
possible or even easy.

So while it might make the learning curve a bit steeper, and
non-growing, totally absolute positioned dialog shouldn't be the default
behavior. Also, if size and all is static it makes a mess for
multiple-platform, changing font sizes, and i18n. Some sort of
auto-sizing should be default behavior.

> So it has both the sizer concept of
> dynamically changing layout, and also the WYSIWYG concept common among
> GUI Builders.

I do like the UI for setting the anchors, etc. Something like that could
be done for Sizer properties and Flags, too. i.e. a visual
representation of the property: wx.GROW, wx.ALIGN_HORIZONTAL, etc.)


> And the designer is not thinking in terms of defining
> layout algorithms to adjust groups of controls, just simply in terms of
> "in what direction and with what stretching do I want this element to
> move when the size changes?"

I don't know that that's better -- the two buttons at the bottom of that
dialog are clearly a group -- you want BOTH of them to stay with the
bottom, why are you setting that property independently? And you want
them both the same height, etc. With two, it's not a big difference but
with more it makes sense to group them.

Which makes me think of vector drawing apps where you can group
different objects, then apply properties, move them, etc. as a group.
Maybe that could inspire a UI idea.

> Sizers tend to be designed around groups of
> controls, but that makes them a poor choice for GUI Builders because you
> need to know what type of layout you want for your group before you
> start designing it.

I'm thinking that you could do the grouping after throwing the widgets
on there.

> In IB, it's a non-issue.

but you do still have to think in groups -- you need to set the
properties of a number of things the same way -- I'd like to have a way
to tell the tool that they are a group, and have it remember that.

I wonder if Cody is paying an attention to this anymore ;-)

Kevin Ollivier

unread,
Jan 20, 2011, 3:10:51 PM1/20/11
to wxpyth...@googlegroups.com
Hi Chris,

On Jan 20, 2011, at 10:44 AM, Christopher Barker wrote:

> I suppose we are OT here, but...
>
> On 1/19/11 3:55 PM, Kevin Ollivier wrote:
>> I was trying to point out that
>> sometimes "problem" is relative, or, at least, that some problems just
>> aren't that big of a deal when you leave abstract arguments and think
>> about practical costs like time and effort.
>
> believe me, I am -- maybe I'm stretching to a different realm, but I know for sure that WYSIWG word processors waste peoples time immensely -- at least when writing substantial structured documents.

Well, it's more that people are using a WYSIWYG print document approach for creating what should be structured documents. This is, to some extent, not really Word's fault.

> I spent almost NO time on formatting my dissertation to match the University standard, or get the bibliography right, or cross reference figure and tables or... -- I simply used LaTeX and a document style some else had written. The computer did what computers do well, and took care of all that for me. I saw folks use MSWord for that kind of thing, and it's painful -- and I see that every day at work, too.
>
> Does that lesson apply to a GUI-builder? I think so.

But what is the lesson? It depends on perspective. The lesson to you is that we should get people to use semantic tools vs. more absolute ones.

The lesson to me revolves around the fact that everyone wants to use Word, but very few people want to use LaTeX (or DocBook XML, etc.), and also that the semantic markup tools in Word are far less known and popular than the absolute markup tools, despite both being readily accessible in the toolbar, and despite the semantic tools sometimes being huge time-savers. :) That says something about human nature, and how people think, and how people adopt tools that fit their way of thinking rather than adjust their way of thinking to fit the use case or tool. Tools are built for humans, so if humans don't like how the tool is built, generally, they just move on to something that suits them better, unless such a thing is not accessible. It's probably more effective to get a little creative and try to find an out of the box solution that fits how people think and like to work than it is to try and force a design process on people that they feel is non-intuitive.

I think the designers of Word probably realize that the more heavy-handed they get with enforcing good design, the more anxious people will be to simply find another tool. I suspect the metric of success from the Word designer's perspective is that someone who does know how to use the tool can create the document they want with it without error.

> Does IB follow the lesson? maybe so. I'm not arguing that the IB approach isn't fabulous -- it may well be.
>
>> It does, in a manner of speaking. :) I don't really think there is an
>> "internal" vs. "external" model.
>
> By definition, there is -- if it doesn't appear that there is one, then they are probably well matched.
>
>> As an example, explicit positioning is
>> allowed, and I use it all the time. It's just that when something
>> changes that would affect layout (e.g. the window is resized), it uses
>> the layout rules you set to calculate the control's new size and
>> position.
>
> That only sounds like semi-explicit positioning to me -- maybe the anchor point is explicit, but the size not? But it sounds like the anchor point could move too, as other widgets grow, so maybe only the original (best?) position is explicit?

That's my understanding.

>> So at design time, this means the GUI Builder isn't mucking
>> with what you tell it to do. The changes happen at runtime.
>
> But at design time, you'll want to know what's going to happen at run time -- I assume there is a way to test that.

Run it, like he did in the video? :)

>> As for Cody -- I suppose he's stuck with the decision on whether to
>> rely on Sizers, or create yet-another-layout-system. (or use layout
>> constraints, I suppose)
>> e.g. in a number of ways, wxAUI really looks and feels foreign
>> on Mac. (wxTreeCtrl is another one...) I was talking about handling this
>> sort of case.
>
> Ideally, those would be made more native at the wx level, rather than the app level, but we don't live in a ideal world!
>
>> I think the discussion is getting a bit abstract, but my idea of a good
>> UI is one that can change quickly and easily. You don't have to think
>> about the boxes you want to put things into in order to achieve the
>> appropriate layout algorithm. You shouldn't have to "reorganize your
>> layout boxes" if you want to change the layout in any meaningful way. I
>> could be misunderstanding something though.
>
> What I'm thinking is that a good UI might be able to make all that box stuff intuitive an easy -- but I don't know how!

Intuitive and easy are relative. The bottom line is that if the user has to work with boxes at all, they can no longer efficiently rapid prototype GUIs, because they have to explicitly think about layout groups before adding controls. In short, the process of layout before controls is what hinders efficient rapid prototyping.

>> #0 pretty much become unnecessary because
>> you thus don't need to consider layout before designing your window.
>
> That's a key point -- and one I was trying to make -- Robin added the #0, my point was that users don't want to do that -- they first know what widgets they want, THEN the want to think about how to lay them out, and they probably want to do that visually with the tool, not on paper. Personally, I don't mind paper, we we tend to have designers work on layout ahead of time in who knows what drawing tools. However, it would be nice if they could just draw it out with the real tool.
>
>
>> > but then identify how they should align and stretch.
>> That's about the same as putting them in a box together.
>>
>> Conceptually, yes. From a user experience perspective, though, it's very
>> different.
>
> We don't know that, cause we haven't seen Cody's fabulous tool yet!

Again, if users have to think about layout groups, it doesn't matter how Cody or anyone implements it, the point is the same. Layout must be considered before adding controls, which is the step which removes many of the benefits of the rapid GUI prototyping approach.

>> Here's a quick tutorial on how IB's "autosizing" and anchors work (sorry
>> for the ad!):
>>
>> http://www.mefeedia.com/watch/28278358
>>
>> An interesting difference that this shows quite clearly is that it
>> doesn't "move" elements on initial layout, it only defines how they move
>> when the window size changes.
>
> What I notice right away is that the first version of the dialog doesn't respond to a changing Window size at all. What that says to me is that the tool makes it easy, and perhaps encourages you, to not do it "right". I think that's a bad thing.

People who want to do things the 'bad' way will find a way no matter what you do. The tool should make things easy for serious professionals to use, not be focused on babysitting people who don't want to even bother considering their UI design. You can make a horrible UI using Apple's tools too, but many popular Mac apps have very solid and praised UIs. This is because they sweat the details, not because it's overseeing their UI design like a hawk. Design a bad UI, and you risk failure. If you're okay taking that risk and not even trying to learn how to design a good UI, who are we to try and force you not to do that?

> It reminds me of working with one of our designers, and she had a PageMaker layout where she actually used spaces to indent some text to fit in an image! What a mess -- I think the tool shouldn't make that possible or even easy.

The problem is that the tool must then be capable of differentiating between "bad" and "good" design principles. Inserting a space, or even two in a row, isn't necessarily bad behavior. Knowing when it is, and when it's not, with any certainty would be quite complex. How far do you go with the tool to make it enforce good practices? What you're suggesting is along the lines of a gun that makes sure you only shoot bad people. ;) Good vs. bad practices are highly contextual. You know them when you see them (well, usually, though sometimes even for us humans it's tricky), but writing a tool that enforces them without generating false positive "bad" cases is highly complex.

I think if you want good PageMaker layouts, it's much more cost effective to make sure people who use it are trained. You wouldn't hire a truck driver without a trucking license, but we ask people to do things all the time using technology they have no experience with, and then we blame the tool when we get sub-standard results from it?

> So while it might make the learning curve a bit steeper, and non-growing, totally absolute positioned dialog shouldn't be the default behavior. Also, if size and all is static it makes a mess for multiple-platform, changing font sizes, and i18n. Some sort of auto-sizing should be default behavior.

Here's the thing though, for me I care about speed. If I know what I'm doing, then in IB I can watch a two minute tutorial and after that be able to build most of the layouts that I can with wxPython quickly and easily. In wxPython, to do the same thing, I have to master sizers and consider layouts on paper or mentally before I start building, or at best hope to have some tool that can automate that process reliably for me... If I know what I'm doing, then all the "protective features" of the tool are wasted on me, and I'm just jumping through extra hoops to get the same result I could get with some other tool much quicker.

>> So it has both the sizer concept of
>> dynamically changing layout, and also the WYSIWYG concept common among
>> GUI Builders.
>
> I do like the UI for setting the anchors, etc. Something like that could be done for Sizer properties and Flags, too. i.e. a visual representation of the property: wx.GROW, wx.ALIGN_HORIZONTAL, etc.)

Yes, of course, but in IB you don't need to specify any sizer on the parent. The question is how to abstract that away without risking the tool making bad decisions and improper layouts for you, while still being as intuitive as IB is.

>> And the designer is not thinking in terms of defining
>> layout algorithms to adjust groups of controls, just simply in terms of
>> "in what direction and with what stretching do I want this element to
>> move when the size changes?"
>
> I don't know that that's better -- the two buttons at the bottom of that dialog are clearly a group -- you want BOTH of them to stay with the bottom, why are you setting that property independently? And you want them both the same height, etc. With two, it's not a big difference but with more it makes sense to group them.
>
> Which makes me think of vector drawing apps where you can group different objects, then apply properties, move them, etc. as a group. Maybe that could inspire a UI idea.

In IB, select multiple items, then move them, or you can open the properties dialog. It shows only the properties that apply to all selected items. If you make a change, it applies the change to all items. This is how most Mac apps handle properties dialogs with multiple selection, BTW.

>> Sizers tend to be designed around groups of
>> controls, but that makes them a poor choice for GUI Builders because you
>> need to know what type of layout you want for your group before you
>> start designing it.
>
> I'm thinking that you could do the grouping after throwing the widgets on there.
>
>> In IB, it's a non-issue.
>
> but you do still have to think in groups -- you need to set the properties of a number of things the same way -- I'd like to have a way to tell the tool that they are a group, and have it remember that.

Why? Humans think in groups, but a tool should think in groups only if you always, without exception, want to make every change to that group in tandem. However, in GUI design that's rarely ever the case. (e.g. you wouldn't want to make a group of text fields, and then when you set one as a password field they all become password fields) The IB way is that you select a group of controls when you want to treat them like a group, or select individual controls when you want to change individual properties. Simple, and intuitive.

> I wonder if Cody is paying an attention to this anymore ;-)

I suspect he is, but he just needs to think about the relative merits and make a decision, as it's his project. Unless he has questions for us, he probably will just skim the perspectives for ideas. It's also possible he's already gone through much the same thought process in his head that we're going through now, meaning this is just a re-hash to him. ;-)

It's also worth considering the rule, which I hope someone will someday codify with a name if they haven't already, that the longer posts and discussion threads get, the less likely various people are to have time to even follow them. ;-)

Thanks,

Kevin

> -Chris
>
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chris....@noaa.gov
>

werner

unread,
Jan 20, 2011, 5:34:36 PM1/20/11
to wxpyth...@googlegroups.com
On 20/01/2011 21:10, Kevin Ollivier wrote:
...

> Intuitive and easy are relative. The bottom line is that if the user
> has to work with boxes at all, they can no longer efficiently rapid
> prototype GUIs, because they have to explicitly think about layout
> groups before adding controls. In short, the process of layout before
> controls is what hinders efficient rapid prototyping.
What about being able to define (give hints to the tool) on what the
boxes should be after having placed all the controls.

Be able to a "sketch with a pencil and a rubber" on paper but do it with
the tool. Place the widgets/controls, move them around and around and
around and when it more or looks the way one wants it at this point be
able to give some hints/settings to the Cody's tool on how things should
be grouped and what should stretch or not stretch etc.

Werner

David Lyon

unread,
Jan 20, 2011, 5:38:15 PM1/20/11
to wxpyth...@googlegroups.com
i like that idea...

Tony Cappellini

unread,
Jan 20, 2011, 7:24:04 PM1/20/11
to wxpyth...@googlegroups.com, codyp...@gmail.com
> Cody Precord <codyp...@gmail.com> Jan 16 06:23PM -0600 ^
>
> Hi,

>
>> don't implement the full set of widgets that wxPython
>> supports.
>> PythonCard is one example.
>
> It should be readily apparent how it is different from the existing
> ones from the video ;)
>
I think the drag & drop approach is definitely the way to go.
I have used this with Visual Basic & C++ Builder and missed it when I
started with wxPython.

The point I was making is- that Pythoncard only implemented a minimal
set of widgets.
XrCed goes further and adds sizers and a few more widgets.

Do you plan on implementing only a minimal set of widgets for any
given release of wxPython?

Kevin Ollivier

unread,
Jan 20, 2011, 8:43:45 PM1/20/11
to wxpyth...@googlegroups.com
Hi Werner,

The problem is that GUIs tend to evolve over time, and actually, a GUI Builder should expect and even encourage this. Your idea works fine up until the hints are formalized and turned into an actual layout, and then at that point, making changes becomes more difficult. Plus, it creates a "prototype" and "actual" layout mode for the GUI Builder, adding more complexity to the implementation. If, on the other hand, the layout is always auto-determined dynamically, it had better not get things wrong, or the user will be very frustrated.

Consider that all this discussion is fundamentally due to the fact that sizers separate layout from the control hierarchy, whereas that separation is very unnatural and problematic for GUI Builders. I'd be interested in seeing an approach that seamlessly reconciles these two approaches, but if it was me who had to put a lot of time and energy into it, at this point I'd simply avoid trying to reconcile two fundamentally different approaches and just design a layout system that suits the GUI Builder rather than try to jerry-rig an approach never designed for a GUI Builder. I think people who are really into sizers are not too concerned about the lack of a GUI Builder in the first place, which is no surprise because when you deal with sizers coding them up is much faster and more efficient.

In my experience, trying to merge two pieces of technology that weren't designed to work together doesn't turn out very well, particularly when you don't have the ability to alter one of those technologies to adapt it to the new use case.

Thanks,

Kevin

> Werner

werner

unread,
Jan 21, 2011, 5:04:52 AM1/21/11
to wxpyth...@googlegroups.com
On 21/01/2011 02:43, Kevin Ollivier wrote:
> Hi Werner,
>
> On Jan 20, 2011, at 2:34 PM, werner wrote:
>
>> On 20/01/2011 21:10, Kevin Ollivier wrote:
>> ...
>>> Intuitive and easy are relative. The bottom line is that if the user has to work with boxes at all, they can no longer efficiently rapid prototype GUIs, because they have to explicitly think about layout groups before adding controls. In short, the process of layout before controls is what hinders efficient rapid prototyping.
>> What about being able to define (give hints to the tool) on what the boxes should be after having placed all the controls.
>>
>> Be able to a "sketch with a pencil and a rubber" on paper but do it with the tool. Place the widgets/controls, move them around and around and around and when it more or looks the way one wants it at this point be able to give some hints/settings to the Cody's tool on how things should be grouped and what should stretch or not stretch etc.
> The problem is that GUIs tend to evolve over time, and actually, a GUI Builder should expect and even encourage this. Your idea works fine up until the hints are formalized and turned into an actual layout, and then at that point, making changes becomes more difficult. Plus, it creates a "prototype" and "actual" layout mode for the GUI Builder, adding more complexity to the implementation. If, on the other hand, the layout is always auto-determined dynamically, it had better not get things wrong, or the user will be very frustrated.
Agreed that if one has to have a prototype and actual layout it wouldn't
be good.

I was hoping that when one reads in an actual layout that one is
basically back to the sketch with the original hints already applied and
one can move things around again to ones liking and might have to apply
new hints and then one generates again.


> Consider that all this discussion is fundamentally due to the fact that sizers separate layout from the control hierarchy, whereas that separation is very unnatural and problematic for GUI Builders. I'd be interested in seeing an approach that seamlessly reconciles these two approaches, but if it was me who had to put a lot of time and energy into it, at this point I'd simply avoid trying to reconcile two fundamentally different approaches and just design a layout system that suits the GUI Builder rather than try to jerry-rig an approach never designed for a GUI Builder. I think people who are really into sizers are not too concerned about the lack of a GUI Builder in the first place, which is no surprise because when you deal with sizers coding them up is much faster and more efficient.

All my stuff uses sizers, because of the I18n needs and the different
resolution people use I can't imaging not using them.

I am not very good at paper sketches and therefore hand coding is still
a bit cumbersome as I just too often don't get it right and while
shifting code around is very easy it is not ideal. I currently use
Boa's designer and assign sizers first which I agree is not ideal, one
could assign them later but it is more work and not ideal either. What
I seen in Cody's demo is much better assuming that at the end I still
get a sizer enabled UI (or something with the same functionality).

Werner

Cody Precord

unread,
Jan 21, 2011, 11:28:39 AM1/21/11
to wxpyth...@googlegroups.com
Hi,

On Thu, Jan 20, 2011 at 2:10 PM, Kevin Ollivier <kev...@theolliviers.com> wrote:
>
>> I wonder if Cody is paying an attention to this anymore ;-)
>
> I suspect he is, but he just needs to think about the relative merits and make a decision, as it's his project. Unless he has questions for us, he probably will just skim the perspectives for ideas. It's also possible he's already gone through much the same thought process in his head that we're going through now, meaning this is just a re-hash to him. ;-)
>
> It's also worth considering the rule, which I hope someone will someday codify with a name if they haven't already, that the longer posts and discussion threads get, the less likely various people are to have time to even follow them. ;-)
>

Yes, I am, however my time is very limited these days (the 3.8 million
lines of non-comment MFC/Win32 source code tied around my waist in my
work project is slowly dragging me into the abyss ;) ).

And just frankly speaking, while this conversation is interesting and
brings up lots of good points for thought, it has gone off in too many
directions for me to completely follow in my limited time and has
moved onto a somewhat more philosophical and idealistic road than is
needed right now. We can talk philosophy from now until eternity but
its not going to get us anywhere practical. I think time would be
better spent getting actual measurable work done at this point in
time.

Just to layout some more concrete information the basic design is as follows:
1) Drag n' Drop things where you want them
2) Modify the properties of the objects as needed
3) Designer will generate an XML data representation of everything in
the designer
4) Code generator(s) will generate code from the XML data

I have implemented the basics of 1-3 already. The architecture will
allow for a lot of flexibility in step 4 to generate the code in
different ways, or for different languages, and I imagine even
different toolkits to some extent. So in step 4 we can do anything and
everything if it was so chosen, the tool will generate a enough data
that the code generation strategy can do whatever it wants to do.
After we get here and have the first two basic strategies
(static/sizers) in place it will be prime time to talk philosophy and
alternate implementations. (IMHO) There is not much sense in spending
a whole lot time on that now until there is a working end to end proof
of concept in place that shows this whole thing is achievable.

The main purpose of starting this thread was to see if I could find
any volunteers to help with writing code as the number of man hours
required to properly implement this tool on my own coupled amongst my
other commitments appears to be somewhat logistically impossible
(though the work is very interesting and stimulating so it wont stop
me from trying ;) ). I was hoping that if I could off load at least
some of the basic infrastructure tasks such as logging, UpdateUI
handling, features like additional alignment guides in the designer
view, control strategies, unittesting, error handling, implementation
of the workaround for dnd on OSX, Menu/Toolbar editor, ... Things
would move along much more smoothly and the possibility of having a
good working model in the near future is much more realistic.


Cody

Cody Precord

unread,
Jan 21, 2011, 11:42:39 AM1/21/11
to wxpyth...@googlegroups.com
Hi,

On Wed, Jan 19, 2011 at 3:32 PM, Mike Rans <ra...@email.com> wrote:
> This looks fantastic. Could the code be structured to allow both a
> standalone application and an Editra plugin?
>

It could though I am not sure I will pursue it or not. Some things are
just better done in separate tools. However, I have tried to design it
as a collection of libraries as much as possible thus far so it should
be pretty straight forward to use as either an application or a
library.

This is a long ways off though so haven't spent much though on it thus far.


Cody

Mike Driscoll

unread,
Jan 21, 2011, 11:51:14 AM1/21/11
to wxpyth...@googlegroups.com
Hi Cody,
I have a feeling that your code is too advanced for me, but I'm willing to try. I can't help with OSX though because I just don't have a Mac available to me. I can hack away on Windows and (probably) Ubuntu though.

Kevin Ollivier

unread,
Jan 21, 2011, 11:58:47 AM1/21/11
to wxpyth...@googlegroups.com
Hi Werner,

I think you will definitely get something with the same functionality, the question is whether sizers are the way to do it with a GUI Builder. For a while, I too thought that wx meant sizers and that was simply how it had to be, but after spending more time with non-wx tools that give me comparable layouts with far less learning curve and far less advance planning, I'm not so sure. In fact, I'm almost sure it's not.

Regards,

Mike Driscoll

unread,
Jan 21, 2011, 12:00:56 PM1/21/11
to wxpyth...@googlegroups.com
I'm pretty sure there's something wrong with me because I don't usually have to spend a lot of time planning out my GUIs. I have a found a handy tool for visualization though. It's called Balsamiq Mockups: http://balsamiq.com/

Kevin Ollivier

unread,
Jan 21, 2011, 12:19:32 PM1/21/11
to wxpyth...@googlegroups.com
Hi Mike,

You probably don't use a GUI Builder then. :) When it's code, you can change anything via quick copy and paste, which is, I suspect, pretty much why everyone who likes sizers is also coding up their GUI instead of using a builder.

Regards,

Kevin

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

Blog:   http://blog.pythonlibrary.org

Kevin Ollivier

unread,
Jan 21, 2011, 12:42:58 PM1/21/11
to wxpyth...@googlegroups.com
Hi Cody,

On Jan 21, 2011, at 8:28 AM, Cody Precord wrote:

> Hi,
>
> On Thu, Jan 20, 2011 at 2:10 PM, Kevin Ollivier <kev...@theolliviers.com> wrote:
>>
>>> I wonder if Cody is paying an attention to this anymore ;-)
>>
>> I suspect he is, but he just needs to think about the relative merits and make a decision, as it's his project. Unless he has questions for us, he probably will just skim the perspectives for ideas. It's also possible he's already gone through much the same thought process in his head that we're going through now, meaning this is just a re-hash to him. ;-)
>>
>> It's also worth considering the rule, which I hope someone will someday codify with a name if they haven't already, that the longer posts and discussion threads get, the less likely various people are to have time to even follow them. ;-)
>>
>
> Yes, I am, however my time is very limited these days (the 3.8 million
> lines of non-comment MFC/Win32 source code tied around my waist in my
> work project is slowly dragging me into the abyss ;) ).
>
> And just frankly speaking, while this conversation is interesting and
> brings up lots of good points for thought, it has gone off in too many
> directions for me to completely follow in my limited time and has
> moved onto a somewhat more philosophical and idealistic road than is
> needed right now. We can talk philosophy from now until eternity but
> its not going to get us anywhere practical. I think time would be
> better spent getting actual measurable work done at this point in
> time.

Yes, the problem is often that on mailing lists, people discuss things that they aren't seriously thinking of implementing, and so the discussion turns from "what is feasible here (or what would I do)" to "what would the ideal tool look like?"

> Just to layout some more concrete information the basic design is as follows:
> 1) Drag n' Drop things where you want them
> 2) Modify the properties of the objects as needed
> 3) Designer will generate an XML data representation of everything in
> the designer
> 4) Code generator(s) will generate code from the XML data
>
> I have implemented the basics of 1-3 already. The architecture will
> allow for a lot of flexibility in step 4 to generate the code in
> different ways, or for different languages, and I imagine even
> different toolkits to some extent. So in step 4 we can do anything and
> everything if it was so chosen, the tool will generate a enough data
> that the code generation strategy can do whatever it wants to do.
> After we get here and have the first two basic strategies
> (static/sizers) in place it will be prime time to talk philosophy and
> alternate implementations. (IMHO) There is not much sense in spending
> a whole lot time on that now until there is a working end to end proof
> of concept in place that shows this whole thing is achievable.

The only real point I've been trying to make is that I think ultimately going the sizers route will make the implementation far more complex, and the UI more unwieldy, then taking an approach more like IB's. In short, I think trying to make sizers work well with a GUI Builder may very well just lead the project down a bit of a rabbit hole. I've been thinking about this problem for a while, and SizedControls was actually an attempt to nudge GUI Builders to use sizers, but after researching and working with other tools for a while I feel more and more that sizers are just not suited for GUI Builders, and I think if alternate solutions aren't considered before starting, the project stands to lose a lot of time by trying to figure out ways to get a square peg fitting into a round hole. wx has its share of GUI Builders, and none of them got a real following, and I think dealing with the sizers issue was a big part of that.

I think IB's approach of "every control is an island" where you would consider each control individually starting probably with the non-stretching controls (to determine what space is available for controls to grow in), then handling the stretching ones last, would probably take less time to prototype and implement than some "static to sizers auto-conversion" layout tool, and would jive better with GUI Builders.

My $0.02 anyways.

> The main purpose of starting this thread was to see if I could find
> any volunteers to help with writing code as the number of man hours
> required to properly implement this tool on my own coupled amongst my
> other commitments appears to be somewhat logistically impossible
> (though the work is very interesting and stimulating so it wont stop
> me from trying ;) ). I was hoping that if I could off load at least
> some of the basic infrastructure tasks such as logging, UpdateUI
> handling, features like additional alignment guides in the designer
> view, control strategies, unittesting, error handling, implementation
> of the workaround for dnd on OSX, Menu/Toolbar editor, ... Things
> would move along much more smoothly and the possibility of having a
> good working model in the near future is much more realistic.

I do wish you luck, but I too can't spend much time working on this. If I could, I'd have done more to help Robin get Project Phoenix off the ground, or added more capabilities to wxWebKit, or one of any number of other things. :( It was a big disappointment for me to see the lack of interest in wxWebKit, in terms of people willing and interested in helping, and sometimes I fear that many potential improvements in wx(Python) just don't have the resources to make real at this point, at least, without them moving forward very, very slowly. I think realistically that you have to go into this GUI Builder project assuming it will be yours, and yours alone. That has been the reality of projects like wxWebKit that I have started. (I know wxWebKit is obviously pretty complex, but even smaller projects like SizedControls have been pretty much single-person projects. And let's not forget that wxWebKit solves a pretty major problem - one that I know there's a lot of demand to have solved, and one which may very well be causing people to pick tools other than wx, like Qt.)

Thanks,

Kevin

> Cody

Mike Driscoll

unread,
Jan 21, 2011, 1:34:35 PM1/21/11
to wxpyth...@googlegroups.com


On Fri, Jan 21, 2011 at 11:19 AM, Kevin Ollivier <kev...@theolliviers.com> wrote:
Hi Mike,




I think you will definitely get something with the same functionality, the question is whether sizers are the way to do it with a GUI Builder. For a while, I too thought that wx meant sizers and that was simply how it had to be, but after spending more time with non-wx tools that give me comparable layouts with far less learning curve and far less advance planning, I'm not so sure. In fact, I'm almost sure it's not.

Regards,

Kevin


I'm pretty sure there's something wrong with me because I don't usually have to spend a lot of time planning out my GUIs. I have a found a handy tool for visualization though. It's called Balsamiq Mockups: http://balsamiq.com/

You probably don't use a GUI Builder then. :) When it's code, you can change anything via quick copy and paste, which is, I suspect, pretty much why everyone who likes sizers is also coding up their GUI instead of using a builder.

Regards,

Kevin



True enough. The GUI builders I tried didn't work with the widgets I was using and I had gotten used to hand-coding.

Christopher Barker

unread,
Jan 21, 2011, 6:33:54 PM1/21/11
to wxpyth...@googlegroups.com
On 1/21/11 10:34 AM, Mike Driscoll wrote:
>> I think you will definitely get something with the same
>> functionality, the question is whether sizers are the way to
>> do it with a GUI Builder. For a while, I too thought that wx
>> meant sizers and that was simply how it had to be, but after
>> spending more time with non-wx tools that give me comparable
>> layouts with far less learning curve and far less advance
>> planning, I'm not so sure. In fact, I'm almost sure it's not.

could be -- it's certainly possible that:

1) Sizers are simply more pain than they are worth!

2) As Kevin says, sizers are not well suited to a visual gui-builder.
- I'm not convinced of that -- I'm sure it could be done better than
it has in any of the ones I've seen (but wxDesigner is the only one I've
used at all)

But: ultimately what we want is a tool that maximizes productivity. What
I think is that there is often a trade-of between what I call
"learn-to-useability" and "productivity-once-you've-learned-it". To sell
a product, you need to emphasize the former, but if it conflicts with
the later, you're a bit stuck. Personally, for a tool I"m going to use
often, I'd rather emphasize productivity, if it it take a bit to wrap my
head around it.

Ideally, one can have a smooth transition between features that are easy
to learn, and more complex features that can help you be more productive
later -- like scripting, auto-sizing of controls, who knows what? But if
your fundemental model is not suitable for truly productive use, then
you're stuck.

Maybe IB's anchor-style system is great -- it looks to me like it would
not work so well if you don't know the exact size of controls when you
are designing -- which is the case with i18n and cross-platfrom
development. But maybe it's got features I don't see.

To me what's missing from the model is that while you can do
multi-select and change properties on a group of controls, that grouping
information is lost -- why to store the fact that you lines up these 5
widgets along their right edges? If you did that, you could change the
size of one of them, and they would stay lined up.

> You probably don't use a GUI Builder then. :) When it's code, you
> can change anything via quick copy and paste, which is, I suspect,
> pretty much why everyone who likes sizers is also coding up their
> GUI instead of using a builder.

Not sure of everyone -- none of the sizer-based GUI builders has become
standard, but they still exist (wxDesigner had an update last July, I
don't know about the others).

For my part, I don't use a graphical GUI builder because:

a) the ones I tried didn't support custom widgets well

b) I often like to have my GUI constructed in code from data.

Even given that, a number of people use wDesigner (and I suppose others)
to prototype sizer-based code that they are going to write (or tweek) by
hand.

So graphical tools, with all their faults, can make working with Sizers
easier (if not easy).

Christopher Barker

unread,
Jan 21, 2011, 6:43:56 PM1/21/11
to wxpyth...@googlegroups.com
On 1/21/11 8:28 AM, Cody Precord wrote:
> Yes, I am, however my time is very limited these days (the 3.8 million
> lines of non-comment MFC/Win32 source code tied around my waist in my
> work project is slowly dragging me into the abyss ;) ).

Wow! you need a new job. ;-)

(note: if you happen to live in or want to move to Seattle, let me know)

> moved onto a somewhat more philosophical and idealistic road than is
> needed right now. We can talk philosophy from now until eternity but
> its not going to get us anywhere practical. I think time would be
> better spent getting actual measurable work done at this point in
> time.

I can see that, but...

> Just to layout some more concrete information the basic design is as follows:
> 1) Drag n' Drop things where you want them
> 2) Modify the properties of the objects as needed
> 3) Designer will generate an XML data representation of everything in
> the designer
> 4) Code generator(s) will generate code from the XML data

> After we get here and have the first two basic strategies
> (static/sizers) in place

Here is the hard part -- sizers and static are very different, and (I
think) incompatible. i.e. can you have a few widgets on a Panel
absolutely positioned, and the rest in Sizers?

As I said before, I think it is very important that your GUI reflect the
'data model' of your internal implementation. If you don't select a data
model before writing the GUI, that's going to be tough.

> There is not much sense in spending
> a whole lot time on that now until there is a working end to end proof
> of concept in place that shows this whole thing is achievable.

What's achievable? A drag-and-drop absolute positioning system? maybe a
lot of code to write, but it's clearly achievable.

What I'm not sure is achievable (and Kevin is sure isn't..) is a simple
easy-to use graphical front end to sizers that lets users follow a
natural thought/design process.

> The main purpose of starting this thread was to see if I could find
> any volunteers to help with writing code

OK -- I'm not helping you build your bike shed, I really don't have any
say in what color is it.

If you do find the time and help, I do suspect you'll end up with
something good!

joshua

unread,
Jan 24, 2011, 10:49:46 PM1/24/11
to wxpyth...@googlegroups.com
hi, all:
I spawn a thread at my wx.App object, and found it that the app didn't
exit until the thread exit.
the thread is responsible for background communication with server, and
it should be terminated when all frames are closed. Since I don't want
the frames obj consider of the thread, I choose to let the app handle
the thread. The problem is how can I terminated the thread once all
frames are closed? I tried to use hook function OnExit of wx.App, since
it will be called before the App exit to clean resources. However, it
didn't work. It seems to be called until all windows are closed and all
threads are terminated. Any idea? Thank a lot!

Christopher Barker

unread,
Jan 25, 2011, 12:39:43 PM1/25/11
to wxpyth...@googlegroups.com

hmmm -- I've put a sys.exit() in after the call to App.MainLoop().
MainLoop() should exit when all the frames are closed, then sys.exit
kills whatever threads are left.

works for me.

where are you starting your extra threads? maybe you need to start them
before you call MainLoop() ?

Robin Dunn

unread,
Jan 25, 2011, 1:38:33 PM1/25/11
to wxpyth...@googlegroups.com
On 1/24/11 7:49 PM, joshua wrote:

What platform and wx version? Do you join() the thread anywhere? What
about setting the deamon property?

Christopher Barker

unread,
Jan 25, 2011, 2:15:25 PM1/25/11
to wxpyth...@googlegroups.com
On 1/25/11 10:38 AM, Robin Dunn wrote:
> On 1/24/11 7:49 PM, joshua wrote:

>> I spawn a thread at my wx.App object, and found it that the app didn't
>> exit until the thread exit.

>> It seems to be called until all windows are closed and all


>> threads are terminated. Any idea? Thank a lot!
>>
>
> What platform and wx version? Do you join() the thread anywhere? What
> about setting the deamon property?

I've done all that, and had threads not always exit (Robin, this was in
the Cameo Chemicals project)

My solution was to start the external thread (only one on my case)
outside the App object, and then call sys.exit at the end of everything.

Maybe it doesn't have to be outside the App object, but it may have to
be before MainLoop() gets called.

-CHB

joshua

unread,
Jan 25, 2011, 9:20:42 PM1/25/11
to wxpyth...@googlegroups.com, Christopher Barker
On Wednesday, January 26, 2011 01:39 AM, Christopher Barker wrote:
> On 1/24/11 7:49 PM, joshua wrote:
>> I spawn a thread at my wx.App object, and found it that the app didn't
>> exit until the thread exit.
>> the thread is responsible for background communication with server, and
>> it should be terminated when all frames are closed. Since I don't want
>> the frames obj consider of the thread, I choose to let the app handle
>> the thread. The problem is how can I terminated the thread once all
>> frames are closed? I tried to use hook function OnExit of wx.App, since
>> it will be called before the App exit to clean resources. However, it
>> didn't work. It seems to be called until all windows are closed and all
>> threads are terminated. Any idea? Thank a lot!
>
> hmmm -- I've put a sys.exit() in after the call to App.MainLoop().
> MainLoop() should exit when all the frames are closed, then sys.exit
> kills whatever threads are left.
>
> works for me.
>
> where are you starting your extra threads? maybe you need to start them
> before you call MainLoop() ?
>
> -Chris
>
>
>
>
My situation is complicated a little bit: a connection will be
established via socket as soon as the thread start. Since I don't want
to connect to the server unless any user behaviors happens, the user's
first action will trigger the thread starting. That means the thread
must be started after MainLoop. I tried put a sys.exit in after the call
to App.MainLoop(), and it didn't work either.


joshua

unread,
Jan 25, 2011, 9:43:42 PM1/25/11
to wxpyth...@googlegroups.com, Robin Dunn

my environment :
WinXp + WxPython2.8.11.0

This a infinite loop running within the thread and a flag to indicate to
exit the loop. The perfect timing to set the flag and join the thread
should be when all frames are closed, but I just didn't find the right
place to meet the moment at the wx.App. I used to think OnExit function
will be called at that moment, but it turn out to be wrong.

I tried to set the daemon property, and it didn't work whether it set to
True or False.

werner

unread,
Jan 26, 2011, 2:38:22 AM1/26/11
to wxpyth...@googlegroups.com
Joshua,

What about if you do this in your toplevel window close event:
for item in wx.GetTopLevelWindows():
if not isinstance(item, twcbF):
item.Close()
event.Skip() # closes twcbF

In my case 'twcbF' is my TopLevel window, but I might have other dialogs
and frames still open and then do whatever you need in your OnExit to
shut down your threads.

Werner

Robin Dunn

unread,
Jan 26, 2011, 3:01:09 PM1/26/11
to wxpyth...@googlegroups.com
On 1/25/11 7:28 PM, joshua wrote:
> On Wednesday, January 26, 2011 11:01 AM, Robin Dunn wrote:
>> Are you sure that there are no top-level windows that still exist?
>> Perhaps a dialog that wasn't destroyed? How about a wx.TaskBarIcon?
>>
> I double sure. I also tried to terminate the thread as soon as it start
> (therefore the corresponding communication functionality is disabled and
> UI is still working fine), close all windows(frames, dialog, task bar
> etc), and then the app exit normally. That confirm it is the thread
> problem.

Please make a small runnable sample that demonstrates the problem.
http://wiki.wxpython.org/MakingSampleApps

joshua

unread,
Jan 26, 2011, 8:57:11 PM1/26/11
to wxpyth...@googlegroups.com, Robin Dunn

Problem solved! The cause of the problem is that the socket was blocking
to wait for receiving message from server that made the thread not exit
at all. I set the socket to non-blocking mode and the wx.App exit as
expected. The point is the wx.App wouldn't exit until all windows are
destroyed and all threaded are terminated.
Thanks All you guys! You are all kind and nice!


David Goldsmith

unread,
Nov 6, 2011, 4:31:32 PM11/6/11
to wxpyth...@googlegroups.com
Sorry for the Windows-only (I think) reference: I see that all the pieces are available, but has anyone put them together to come up with a "list assembly control" wherein one selects items in one list and then either double-clicks, button-clicks, or DnD's them to a second list, which in turn is acted upon when one produces a predetermined event (e.g., clicking on an OK button)?  (In my particular use case I'd like "List A" to be a wx.DIRCTRL_SHOW_FILTERS, the entries in which, i.e., file paths, I can drag to "List B," the contents of which, i.e., the custom list of file paths, are then available to the calling routine upon clicking "Done," but clearly a general tool such as this should be of use in a broad variety of applications, i.e., a good candidate for addition to the list of controls available in the wxPython Standard Distribution, hint, hint.)

Robin Dunn

unread,
Nov 7, 2011, 6:02:42 PM11/7/11
to wxpyth...@googlegroups.com

It doesn't support DnD of items, but the recently added ItemsPicker
class does the rest of what you mentioned with a couple simple
wx.ListBoxes. It could probably be adapted for wx.DirCtrl without too
much hassle.

David Goldsmith

unread,
Nov 8, 2011, 3:25:12 AM11/8/11
to wxpyth...@googlegroups.com
Cool, I'll give it a look-see. (I was going to try to leverage the DragAndDrop demo, since that already includes file browsing support...) Thanks!

--- On Mon, 11/7/11, Robin Dunn <ro...@alldunn.com> wrote:

Cody

unread,
Oct 23, 2012, 4:23:43 PM10/23/12
to wxPyth...@googlegroups.com
Hi,

On Tue, Oct 23, 2012 at 2:35 PM, Michael McCormick
<mccormick...@gmail.com> wrote:
> Cody,
>
> Is this project still active? I would love to give you a hand with coding.
>

Had been hoping to keep working on it further but my day job has been
more and more pressing on my time the last couple of years...

I am on a buisness trip this week but will try to plan on publising
the code somewhere in the near future so it can be played with /
worked on if your interested. At the very least I think that there is
alot of fairly interesting code to look at in there.

It is however mostly still proof of concept, but has enough as can be
seen in the demo video I had posted to work on the interface and test
out design ideas. Next step was some design effort that I was going
over for possible code generation / interface serialization schemes to
try out but its been so long now that I don't remember exactly how far
I had gone into it. Was mostly weighing cons/benefits between things
like generating code from the tool or providing a framework that would
create the interface at runtime based on some sort of serialized (XML)
data from the tool.


Cody

David Holl

unread,
Oct 23, 2012, 11:02:41 PM10/23/12
to wxPyth...@googlegroups.com
On Tue, Oct 23, 2012 at 4:23 PM, Cody <codyp...@gmail.com> wrote:
Hi,
... Next step was some design effort that I was going
over for possible code generation / interface serialization schemes to
try out but its been so long now that I don't remember exactly how far
I had gone into it. Was mostly weighing cons/benefits between things
like generating code from the tool or providing a framework that would
create the interface at runtime based on some sort of serialized (XML)
data from the tool.

Cody

How about the existing tools to support loading serialized GUI described via XRC?

XRC is an application of XML...
Brief description:  http://wiki.wxpython.org/XRCTutorial

The new drag-n-drop UI-layout tool would be very very nice... and I wonder if using the existing XRC support routines would solve your GUI serialization & deserialization.  Then you could focus on making a pleasant-to-use tool.

At the moment, I use wxFormBuilder for UI layouts, and I wish very much that it supported the simple notion of drag-n-drop widget placement...  But at least it satisfies my desire for being able to serialize a GUI into a data format (in this case XML/XRC) and thus divorce my code from my UI layouts.

- David

Mike Driscoll

unread,
Oct 24, 2012, 9:10:44 AM10/24/12
to wxPyth...@googlegroups.com

--


XRC only covers the basic widgets right now. Someone would have to write a bunch of wrappers for the rest of the widgets for it to work. Not a bad idea though.

Cody

unread,
Oct 24, 2012, 9:45:38 AM10/24/12
to wxPyth...@googlegroups.com
Hi,
The serialization layer I had started was using its own XML format
that was very generic and based mostly on dynamic discovery. The tool
can basically import any module its pointed at then introspects all
the objects in the module and discovers everything that derives from
Window/Control/Dialog/ect... it then generates a control library xml
file for each of these imports its told to inspect. These libraries
are then loaded into the library view in the tool and the user can
then use any of the controls in their designs. Some of the controls
require special wrappers for the UI editor but this is also
generalized to certain types of controls which IIRC was currently just
composite controls which needed special handling.

The manipulation of these objects then relies fairly heavily upon the
dynamic discovery of any properties that the class has. The properites
are used to discover and present things such as editing the label,
background color, ect.. Where I had left the tool it was capable of
the dynamic discovery of all this data and allowed the manipulation of
several things in the UI for all the discovered items. Next big piece
was to create the reverse of persisting this data of the built UI back
out to XML. This is mostly simple except for there are some provisions
that need to be designed for the layout management.

So in theory as the way the tool is setup now it can automagically
work with any wx derived control automatically if it is able to import
the module and perform introspection. I was somewhat concerned about
how this was going to work in Phoenix though as it sounded that most
the python wrappers were going away and the introspection may not work
as well.


Cody

Metallicow

unread,
Jun 11, 2017, 7:47:53 AM6/11/17
to wxPython-dev
Hey Cody :)

Is this project still alive... It's 2017 now and phoenix is here.
Is there source code uploaded anywhere.? 
I would be interested in looking at it. 
Maybe upload to GitHub?

Cody

unread,
Jun 11, 2017, 8:20:44 AM6/11/17
to wxPyth...@googlegroups.com
Hi,

On Jun 11, 2017 6:47 AM, "Metallicow" 

Hey Cody :)

Is this project still alive... It's 2017 now and phoenix is here.
Is there source code uploaded anywhere.? 
I would be interested in looking at it. 
Maybe upload to GitHub?

It's been in github for several years.


Haven't touched anything related to it in several more though ;)

Cody

Metallicow

unread,
Jun 11, 2017, 9:05:40 AM6/11/17
to wxPython-dev
Thanks for the official link. I'll star/bookmark it. I guess googling `wxPython GUI Designer by Cody Precord` wasn't good enough. and Googling `eguid` only finds a github user with that name.
Searching for it on github for `eguid` pops up the 2nd hit.
I don't see a license/readme file in the repo... Is it wxPython licensed? Could you add one please in a commit so it is clear...?

ff

unread,
Jun 14, 2017, 10:48:52 AM6/14/17
to wxPyth...@googlegroups.com

I am working with Boa, your tool would be a nice option to add !

What is required for seamless working in Boa ?
Reply all
Reply to author
Forward
0 new messages