boa-constructor-users

[Boa Constr] Getting started

[C. P. B. <po...@et...>]

Boa constructor looks interesting, and I would like to check it out.  I
couldn't get it working with python 2.0 and wxPython 2.2.2.  I tried to
get wxPython 2.2.1 working with python 2.0, but I didn't get that
working either.  I he latest version of Boa from the CVS.  Yet again, I
failed.

Could you help me get the latest from CVS?  This is what I type: 
cvs
-d:pserver:ano...@cv...:/cvsroot/boa-constructor login

When it asks for a password, I hit Enter, just like the instructions
say.  When I do that, I am immediately booted back to the command prompt.
--------------------------------------------------------------------------
C. Porter Bassett     po...@et...   http://www.cporterbassett.com
--------------------------------------------------------------------------
"Pretend like this is a really witty saying." - Anonymous
--------------------------------------------------------------------------

[Boa Constr] CVS updade

[Riaan B. <riaan@e.co.za>]

Hello everybody,

I've updated the CVS repository. Could those of you who are CVS enabled
please check it out and give it a go.

Needs wxPython 2.2.5.

Major changes:
* Improvements to the Inspector and Designer
* More component clipboard support
* New documentation
* Anchor integration
* Less old bugs :) More new bugs :(

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

Re: [Boa Constr] Sizers and Layout with Boa

[Riaan B. <riaan@e.co.za>]

Hi Enrique, you've prompted me to add a page about window layout to 
Boa's documentation, guess you'll have to proof read it now ;)

I've also attached 3 files showing the same window layout in three 
flavours, Constraints, Anchors and Sizers.

This is the new help page (excuse formatting, copy pasted)
Note that this help and examples really apply to my current version of
Boa and wxPython 2.2.5 but it should still be useful.

--

wxPython offers various flavours of window layout. The two main systems
are Constraints and Sizers. 
Constraints allow layout relationships to be setup between controls and
edges.
A constraint must define 4 valid individual layout constraints or chaos
will ensue.
Boa offers support but not complete integration of constraints
currently. They can be set up in the Collection Editor accessible from
the Constraints property of controls.
One problem is currently is that the relative offsets (margin and value)
are not kept in sync when controls are moved and sized. 

There are two more modules to help with this somewhat tedious to setup,
but powerful layout mechanism.
They can be found in wxPython.lib as layoutf and anchors.
With layoutf constraints can be specified in concise printf like format.
There is no built-in support for layoutf in Boa but they can be added by
hand. See the layoutf's source for documentation
The LayoutAnchors class in anchors derives from wxLayoutConstraint and
can be used in it's place. They offer a simple subset of normal
constraints where the sides of a control may be 'anchored' on it's
parent. Anchors are completely integrated into the Designer and
available by right clicking on a selection tag in the Designer or from
the Anchors property of controls.
See LayoutAnchors for detailed info. 

Sizers allow controls and other sizers to be packed horizontally and
vertically in window. They can grow, align to sides, proportionally
resize or be centered.
Boa has no built-in support for sizers currently. I have trouble
integrating them into Boa's current design time framework. They also
need special visual support in the Designer , and the 'packing' of
controls goes against the current placing and sizing methodology.
Support is planned at a later stage.
Remember that you can always add Sizers by hand (to __init__) if you
really need them. 

Please note that a window's AutoLayout property should be set to true
for the window to automatically apply layout for sizers and constraints.
If this is not set you'll have to call Layout() yourself in the OnSize
event of the window, but constraints will not be applied for that window
at design-time.

--

Enrique Castro wrote:
> 
> Hi,
>         I have used Boa for very simple GUIs fo far. Now I want to go further
> exploiting wxWindows features. I do not see how to introduce sizers (e.g
> wxBoxSizer) or Layout management into dialogs using Boa
>
>         I have read the new Guide, but there is nothing there about this topic
>
> Thanks a lot in advance
> Enrique Castro
> 
> ####################################################
> 
> Enrique Castro
> Dept. Bioquímica, Biología Molecular y Fisioloía
> Universidad de Las Palmas de Gran Canaria (ULPGC)
> Facultad de Ciencias de la Salud
> c/ Doctor Pasteur s/n
> 35016 Las Palmas, Spain
> 
> Tel: (34) 928 45 87 90
> Fax: (34) 928 45 14 41
> e-mail: ec...@ci...
> #####################################################
> 
> _______________________________________________
> Boa-constructor-users mailing list
> Boa...@li...
> http://lists.sourceforge.net/lists/listinfo/boa-constructor-users

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

[Boa Constr] Sizers and Layout with Boa

[Enrique C. <ec...@ci...>]

Hi,
	I have used Boa for very simple GUIs fo far. Now I want to go further 
exploiting wxWindows features. I do not see how to introduce sizers (e.g 
wxBoxSizer) or Layout management into dialogs using Boa
	I have read the new Guide, but there is nothing there about this topic

Thanks a lot in advance
Enrique Castro
 
####################################################

Enrique Castro
Dept. Bioqu=EDmica, Biolog=EDa Molecular y Fisiolo=EDa
Universidad de Las Palmas de Gran Canaria (ULPGC)
Facultad de Ciencias de la Salud
c/ Doctor Pasteur s/n
35016 Las Palmas, Spain

Tel: (34) 928 45 87 90
Fax: (34) 928 45 14 41
e-mail: ec...@ci...
#####################################################  

Re: [Boa Constr] [BOA] installation and library versions

[Robin D. <ro...@al...>]

> The answer was to use wxXXX 2.2.1 instead of 2.2.2.
> Well, right now only the 2.2.5 are accessible from sourceforge.
> Can someone tell me where I can download older versions ?
>

http://alldunn.com/wxPython/dist/

--
Robin Dunn
Software Craftsman
ro...@Al...       Java give you jitters?
http://wxPython.org      Relax with wxPython!

[Boa Constr] [BOA] installation and library versions

[Pascal P. <Pas...@ir...>]

Hello,

I teach at the University of Nantes and I often give projets to my
students in
python. This year I decided to use GTK/Glade.
One remark of my students is that there is no programming environment
(lets say
Delphi-like) for python/gtk/glade and that gtk/glade may not be very
portable
under windows.

Therefore I took a look at boa and it seems really interesting to me.
However, I have the following problem:

- boa does not works (I have the same error message someone already
posted on the
list some time ago).
The answer was to use wxXXX 2.2.1 instead of 2.2.2.
Well, right now only the 2.2.5 are accessible from sourceforge.
Can someone tell me where I can download older versions ?

(if possible, rpm version as I will ask my student to get it too, and
they are not
really "compiling", "makefiles" and "cvs" prone ...)

Pascal

Re: [Boa Constr] Interface comments

[Bernhard R. <ber...@in...>]

On Thu, Jan 18, 2001 at 04:57:28PM +0200, Riaan Booysen wrote:
> Hi Bernard, you keep on asking the tricky question don't you ;)

Well .. not on purpose.
I just tried to work with Boa and get a project done. :)
And while being in the position of a newcomer to boa I try to
get my feedback out so you have the opinion of someone who has a
fresh new angle on things.

> Bernhard Reiter wrote:

> > - How can I replace the main frame of an application and switch on
> >   autocreate for other frames? (This is probably something I just
> > missed in the docs..)
>=20
> In short, you must currently change the main frame by hand.

Okay.

> Autocreation has not been completely implemented. I've not yet decided
> on the best strategy to implement it.
>=20
> One way would be to create the frame in it's module scope.=20
> The singleton pattern.=20

=46rom your description I do not think this is a good idea.
(BTW: I never really understood the singleton pattern, I still
believe some C++ person invented it for shortcomings in the language
and other though it was cool...)


> It would be nice if all autocreated frames could be children of the
> main frame (who would then destroy them when it closes) but alas,
> because these objects are created at compile time (module scope)

Hmmm.

> Another way would have been to keep a global dict in the wxApp's=20
> module which keeps track of the autocreated frames.=20

> I do not want to use this pervertiom (perverted idiom) in EVERY app=20
> that Boa creates.
> What would you think if you read the above mentioned code?
>=20
> Any better ideas?

My local python expert (Bernhard Herzog) tells me that you might be
able to put in your own import hook with overwriting a function
sys.__import__ or something. Then you could make sure that you=20
have code always done when a module is imported.=20

Just thinking about it for a couple of minutes, I fail to see
why you are not creating the Frames in a function in the application
module.=20

You of course need to have a list of modules you import.
Then you can ask them via methods, if the application shall create a
frame instance.
	import frame
	try:
		if frame.autocreate():
			frameobj=3Dframe.new()
	expect x:
		pass



> > - I have been adding my own control and somehow Boa did not
> >   recognize what I have been done and editing this frame in the
> > designer lead to code being deleted by Boa. There should be guidline
> > on how to add own elements to boa so that the frame designer can
> > handle it.
>=20
> Was it a control not supported by Boa?

Yes. Filebrowsebutton, Dirbrowsebutton and such.

> Someone else also recently ran into this, the guideline is:
> Do not modify _init_* methods, Boa parses and regenerates these
> methods. Any code in these methods that do not comply exactly with
> the format that Boa expects will be lost.

Boa should put out a warning if I am motifying this code, it does
not understand or prohibit me to actually change it there.

> What you should have done was to create your control in the __init__
> method underneath _init_ctrls().
>=20
> As promised before, this will be added to the documentation.

	Bernhard

--=20
Professional Service around Free Software                (intevation.net) =
=20
The FreeGIS Project                                         (freegis.org)
Association for a Free Informational Infrastructure            (ffii.org)
FSF Europe                                            (www.fsfeurope.org)

Re: [Boa Constr] control layout in GUI Designer

[Geoff T. <gta...@na...>]

Riaan Booysen wrote:

> Ouch! No I didn't try it, but I used to have it at at 4 a while ago
> and assumed it would still work.
>
> You are running the CVS version of Boa?

Yes.

> This uncovered a hack that granulises the frame size when it is resized.
>
> in Views.Designer.OnControlResize change the following:
>
> # Granularise frame sizing so that controls inside main frame
> # fits exactly
> sze = dsgn.GetSize()
> granSze = granularise(sze.x), granularise(sze.y)+3
> dsgn.SetSize(granSze)
>
> to
>
> # Granularise frame sizing so that controls inside main frame
> # fits exactly
> sze = dsgn.GetClientSize()
> granSze = granularise(sze.x), granularise(sze.y)
> if sze.asTuple() != granSze:
>     dsgn.SetClientSize(granSze)
>

That fixed the problem -- thanks for the help!

--


- Geoff Talvola
  Parlance Corporation
  gta...@Na...

Re: [Boa Constr] Interface comments

[Riaan B. <riaan@e.co.za>]

Hi Bernard, you keep on asking the tricky question don't you ;)

Bernhard Reiter wrote:
> > I see there are a few new bugs reported, I wish
> > I could get SourceForge to forward these by email too!
> 
> I know that it can be done from other projects.
> You might want to check the options again.

I have, and I will when I can log in again (I've just installed a new
browser, so I will get to the soon)

> I have a couple of other things, I noticed when running Boa.
> 
> In CVS Version from the 16th of January:
> - How can I select a wxListBox in the Frame Designer.
> (I can do it using the Objs Tab.)

Some controls do not register clicks like all the others (statusbar on
MSW and Gen*Buttons) others report different objects in the event 
handler (wxListCtrl on GTK, but I think this has been fixed). I think
your wxListBox may also be reporting the wrong objects in the event.
I will investigate.

> 
> - How can I replace the main frame of an application and switch on
>   autocreate for other frames? (This is probably something I just
> missed in the docs..)

In short, you must currently change the main frame by hand.

Autocreation has not been completely implemented. I've not yet decided
on the best strategy to implement it.

One way would be to create the frame in it's module scope. The singleton
pattern. Also the way Delphi does it.
E.g. in wxFrame1.py add frame1 = create(None) to the bottom of the
module.
This way the autocreated frame can be accessed as wxFrame1.frame1.

The first problem is that it's not compatible with the current
strategy of creating the main frame. Another problem is the management
of the new name 'frame1'. Frames currently manage their class name, not
an instance name. Yet another problem is the destruction of these 
global (in module scope) frames. Who should destroy them?
If they are not destroyed the wxApp will not terminate. We can't 
destroy them in wxApp.OnExit because this won't get fired until
they are destroyed. Chicken and egg.
This also requires that the main frame's import not be done in module
scope as that will cause 2 wxApps to be created which is an error.

It would be nice if all autocreated frames could be children of the
main frame (who would then destroy them when it closes) but alas,
because these objects are created at compile time (module scope)
this would require an import and a reference of the main frame
in autocreated frames (which has to be updated on renames)
Too much management.

Another way would have been to keep a global dict in the wxApp's 
module which keeps track of the autocreated frames. This doesn't
work because the wxApp module is not added to sys.modules, therefore
when another module imports wxApp's module (the main module), it
will create a new global object and won't return the actual dict
that the wxApp module maintains. :/

This rather rare Python peculiarity can be worked around by
importing the autocreated dict from itself inside the main module.

e.g. in wxApp1.py:

autocreated = {}
from wxApp1 import autocreated

This assures that App1 will be in sys.modules and that anyone else
that imports wxApp1 will have access to the same autocreated dict.

I do not want to use this pervertiom (perverted idiom) in EVERY app 
that Boa creates.
What would you think if you read the above mentioned code?

Any better ideas?

> 
> - I have been adding my own control and somehow Boa did not
>   recognize what I have been done and editing this frame in the
> designer lead to code being deleted by Boa. There should be guidline
> on how to add own elements to boa so that the frame designer can
> handle it.

Was it a control not supported by Boa?
Someone else also recently ran into this, the guideline is:
Do not modify _init_* methods, Boa parses and regenerates these
methods. Any code in these methods that do not comply exactly with
the format that Boa expects will be lost.

What you should have done was to create your control in the __init__
method underneath _init_ctrls().

As promised before, this will be added to the documentation.

> 
> Best,
>         Bernhard
> 
> --
> Professional Service around Free Software                (intevation.net)
> The FreeGIS Project                                         (freegis.org)
> Association for a Free Informational Infrastructure            (ffii.org)
> FSF Europe                                            (www.fsfeurope.org)
> 
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

Re: [Boa Constr] control layout in GUI Designer

[Riaan B. <riaan@e.co.za>]

Geoff Talvola wrote:
> 
> Riaan Booysen wrote:
> 
> > Hi Geoff,
> >
> > Geoff Talvola wrote:
> > >
> > > How can I get Boa's GUI Designer to let me locate controls to multiples of 4 instead of multiples of 8?
> > >
> > > The reason I ask is because I'm trying to line up a bunch of wxStaticText controls with wxTextCtrl controls, and they line up properly if the wxStaticText's y position is 4 units below the wxTextCtrl's y position.  But the GUI Designer is snapping all controls to multiples of 8.
> > >
> >
> > This should be a runtime changeable setting, but in the meantime,
> > in the module Views.SelectionTags, line 25 change the value of
> > screenGran.
> 
> Have you tried it?  I just tried changing screenGran to 4, and it causes my frame window to automatically resize itself to be 780 units tall!  Every time I try to shrink it back down, it automatically resizes itself to 780 units tall.  Try it and see if you get the same behavior.  I'm running on Windows, by the way.

Ouch! No I didn't try it, but I used to have it at at 4 a while ago 
and assumed it would still work.

You are running the CVS version of Boa?

This uncovered a hack that granulises the frame size when it is resized.

in Views.Designer.OnControlResize change the following:

# Granularise frame sizing so that controls inside main frame
# fits exactly
sze = dsgn.GetSize()
granSze = granularise(sze.x), granularise(sze.y)+3
dsgn.SetSize(granSze)

to

# Granularise frame sizing so that controls inside main frame
# fits exactly
sze = dsgn.GetClientSize()
granSze = granularise(sze.x), granularise(sze.y)
if sze.asTuple() != granSze:
    dsgn.SetClientSize(granSze)

> 
> I get the same bug if screenGran is set to 5 or 6, but it does work properly if it's set to 7.
> 
> --
> 
> - Geoff Talvola
>   Parlance Corporation
>   gta...@Na...

Thanks for picking this up.

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

Re: [Boa Constr] Interface comments

[Bernhard R. <ber...@in...>]

Riaan,
again thanks for replying and thinking about my suggestions.


On Wed, Jan 17, 2001 at 11:00:09PM +0200, Riaan Booysen wrote:
> Bernhard Reiter wrote:

> I take exception to this; you are judging Delphi/Borland without
> knowing the products.=20

True.

> I think Delphi and it's libraries are VERY well designed.
> If you're not willing to even look at them, you're going to have to
> take my word for that ;)

Well I do not run a non-free operating system. :)
And Borland lost most of its credit to me, I just have a hard time
imagining that they can do truely great stuff...
But I respect your opinion, of course.

> > I get it know. IMO the normal way of actions should be limited.
> > This probably guides almost all users better. Why not change this
> > "loading" the pointer concept.=20
>=20
> This is nonnegotiable. Once you get used to it, it works very well.
> Patches are of course welcome :)

:)=3D
Naturally.
But first someone has to add the filebrowsebuttons and sizers.

> > It is also getting in the way when
> > you need to create like three buttons and so on.=20
>=20
> In Delphi if you want to create a control multiple times, hold down
> shift before clicking the item on the Palette. It will be depressed
> with a blue border.
>=20
> I plan on implementing this in Boa at some stage.

Sounds like a magic way to me... but Delphi users will know it, if I
understand you correctly.

> > (Did you btw clear up the bugs in the bug-tracker sometimes?)
>=20
> I've been out of touch with the website as the stats don't work and
> neither my IE or Netscape could log in to Source Forge since the
> last upgrade.=20

Oh.

> I see there are a few new bugs reported, I wish
> I could get SourceForge to forward these by email too!

I know that it can be done from other projects.
You might want to check the options again.

I have a couple of other things, I noticed when running Boa.

In CVS Version from the 16th of January:
- How can I select a wxListBox in the Frame Designer.
(I can do it using the Objs Tab.)

- How can I replace the main frame of an application and switch on
  autocreate for other frames? (This is probably something I just
missed in the docs..)

- I have been adding my own control and somehow Boa did not
  recognize what I have been done and editing this frame in the
designer lead to code being deleted by Boa. There should be guidline
on how to add own elements to boa so that the frame designer can
handle it.


Best,
	Bernhard


--=20
Professional Service around Free Software                (intevation.net) =
=20
The FreeGIS Project                                         (freegis.org)
Association for a Free Informational Infrastructure            (ffii.org)
FSF Europe                                            (www.fsfeurope.org)

Re: [Boa Constr] control layout in GUI Designer

[Geoff T. <gta...@na...>]

Riaan Booysen wrote:

> Hi Geoff,
>
> Geoff Talvola wrote:
> >
> > How can I get Boa's GUI Designer to let me locate controls to multiples of 4 instead of multiples of 8?
> >
> > The reason I ask is because I'm trying to line up a bunch of wxStaticText controls with wxTextCtrl controls, and they line up properly if the wxStaticText's y position is 4 units below the wxTextCtrl's y position.  But the GUI Designer is snapping all controls to multiples of 8.
> >
>
> This should be a runtime changeable setting, but in the meantime,
> in the module Views.SelectionTags, line 25 change the value of
> screenGran.

Have you tried it?  I just tried changing screenGran to 4, and it causes my frame window to automatically resize itself to be 780 units tall!  Every time I try to shrink it back down, it automatically resizes itself to 780 units tall.  Try it and see if you get the same behavior.  I'm running on Windows, by the way.

I get the same bug if screenGran is set to 5 or 6, but it does work properly if it's set to 7.

--


- Geoff Talvola
  Parlance Corporation
  gta...@Na...

Re: [Boa Constr] web page administrivia

[Riaan B. <riaan@e.co.za>]

Hi Mrak ;),

"Mark W. Alexander" wrote:
> 
> Riian,
> 
> The `Project` link on http://Boa-Constructor.sourceforge.net/ is
> incorrect. It points to http://sourceforge.net/projects/Boa-Constructor/,
> but should be http://sourceforge.net/projects/boa-constructor/ (lower
> case).

Thanks, I'll update it.

> 
> Mark Alexander
> mw...@ga...
> 
> _______________________________________________
> Boa-constructor-users mailing list
> Boa...@li...
> http://lists.sourceforge.net/lists/listinfo/boa-constructor-users

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

Re: [Boa Constr] control layout in GUI Designer

[Riaan B. <riaan@e.co.za>]

Hi Geoff,

Geoff Talvola wrote:
> 
> How can I get Boa's GUI Designer to let me locate controls to multiples of 4 instead of multiples of 8?
> 
> The reason I ask is because I'm trying to line up a bunch of wxStaticText controls with wxTextCtrl controls, and they line up properly if the wxStaticText's y position is 4 units below the wxTextCtrl's y position.  But the GUI Designer is snapping all controls to multiples of 8.
> 
> Thanks in advance!
> 
> --

This should be a runtime changeable setting, but in the meantime, 
in the module Views.SelectionTags, line 25 change the value of 
screenGran. 


> 
> - Geoff Talvola
>   Parlance Corporation
>   gta...@Na...
> 

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

Re: [Boa Constr] Interface comments

[Riaan B. <riaan@e.co.za>]

Hi Bernard,

Bernhard Reiter wrote:

> Talking about Borland, I have a couple of years ago stopped to deal
> with their products, because they never were excelent. Just because
> VB and Delphi are very popular does not mean that they are well
> designed. It is no argument, it is just that most people have not
> bothered to do better.

I take exception to this; you are judging Delphi/Borland without
knowing the products. I'm sure there might have been less successfull
products in the past but you've never even seen the VCL. 
I think Delphi and it's libraries are VERY well designed.
If you're not willing to even look at them, you're going to have to
take my word for that ;)

> My problem is not that it is big, but it feels big. :)
> Of course bigger programs are harder to make right on all edges.
> Smaller programs can be tested more thoroughly, but you'll know.
> I was just suprised that you started adding thinks for tasks were
> other tasks could not relyably be done. Trying to do all in once
> is likely to be very hard and likely to fail.
> Despide this you have done a nice job and I am not complaining.

Indeed, it is working well enough for me, and I see no reason to
change a strategy that I enjoy and works. Every aspect of Boa is
developed in Boa. 

> 
> > I definitely agree with your later statements though, that users who
> > do not need specific functionality should be able to turn it off.
> 
> This would definetly help.
> Main reason that Boa feels so big is that you are not guided enough
> through all the different actions you can take. This does not mean
> you have to limit the power user of course.
> 
> Having the possibility of opening more than one frame designer and
> more than one collections editor seems to be overkill from my point
> of view.

Then don't open more than one, I'm not taking the option away from
people who do want that (including myself).
I will look into how easily it will be to optionally only use one
always open Collection Editor per frame, . I

> > Also I've adopted quite a few conventions from Delphi. They may not
> > all seem intuitive to someone who has not used Delphi, but would
> > to someone who has (I hope!).
> 
> I cannot tell. But maybe delphi users will.
> But python is certainly different from Delphi and you can adopt
> different conventions when you want it.

I have adopted my own conventions where I wanted, but the remember, 
Designers do not really model Python, their focus is more on 
wxPython/wxWindows, which is similar to the Delphi VCL.
(One of the reasons I went to wxPython instead of Tkinter)

> As the designer you probably do not have any problem learning your
> own conventions.

Of course.

> > > It should be possible to use a different editor.
> 
> > To what degree of integration? With which editors?
> > I'm editor agnostic.
> 
> Nedit, (g)vim and (x)emacs come to mind.
> It should be nice to have a documented way on how to use a different
> editor. It is mostly a reminder so you think about it in your design
> decisions.

I will keep it in mind.
The 'check if file have been updated' strategy is the simplest way which
should work for all of them. 

> I get it know. IMO the normal way of actions should be limited.
> This probably guides almost all users better. Why not change this
> "loading" the pointer concept. 

This is nonnegotiable. Once you get used to it, it works very well.
Patches are of course welcome :)

> It is also getting in the way when
> you need to create like three buttons and so on. 

In Delphi if you want to create a control multiple times, hold down
shift before clicking the item on the Palette. It will be depressed
with a blue border.

I plan on implementing this in Boa at some stage.

> This would allow
> you to just disable and enable the palette selection. I would regard
> this as a use usability advantage.
> 

Just as you are used to something else, this is what I'm used to and
want. The 'loaded' cursor strategy has it's own advantages.

> > If you are refering to commiting changes in a view (e.g. the Source
> > control) to the model this is always Refresh.
> > Commiting changes from the model to the disk is always Save ;)
> > Commiting changes to all GUI building windows is Post.
> >
> > Do you want refreshing your source to also be done with a Post button?
> >
> > Each is different, even though technically the GUI builders are views
> > which commit changes to the model, they run in a session which freezes
> > the other views until the session is either commited or cancelled.
> 
> See this is very complicated. Why not make it simpler and all
> concepts the same. Not thinking very deeply about I guess that it
> can be done.

It's not very complicated and while they are different their actions
will stay different. If the designers no longer work in a session
or applying changes also saves to disk, then I will agree on one 
action. 

> It is about what to do next and the role of the inspector.
> In NeXTStep an inspector was just there to inspect any selected
> object, no matter what it was. So the object metaphor held.

I believe the object metaphor holds very well for Boa, any 'object'
that is selected in any Designer will display it's properties in
the Inspector. (This even goes for Zope objects and Explorer objects)

> 
> Boa does not seem to make it this way, because of the cancel and
> post buttons. AS I learned from your mail, these buttons do actually
> close all designers. The inspector can inspect various objects, why
> are they in the same window? (As you can see, it did confuse me. :))

The Post and Cancel buttons were put on the Inspector because that is 
the window that is used most in conjunction with GUI Design.
In other words, for convenience. Also for convenience, changes are 
posted when you close the Designer frame.

> 
> I assumed that the changes made in the inspector will be posted,
> when I press the post button and thrown away, when I do not press
> the post button. For inspecting collection object properties, this
> does not hold.

Apart from the bug that has been fixed (post while selecting a 
collection item) collections are consistent with other designers.

> > You won't know about CVS unless
> > you choose to go into a CVS folder, and when you do, the view is so
> > much more useful than seeing Entries, Repository and Root files.
> 
> Well I was fearing as with some integrated system, that there will
> be some intelligence acting and I do not know what will happen.

No, CVS actions are explicit and require confirmation before running.

> 
> > Thanks for your comments and article!
> 
> You are welcome, thanks for sharing Boa.
> I guess that Boa will get much more popular in the future.
> (Did you btw clear up the bugs in the bug-tracker sometimes?)

I've been out of touch with the website as the stats don't work and
neither my IE or Netscape could log in to Source Forge since the
last upgrade. I see there are a few new bugs reported, I wish
I could get SourceForge to forward these by email too!

> 
> Best,
>         Bernhard
> 
> --
> Professional Service around Free Software                (intevation.net)
> The FreeGIS Project                                         (freegis.org)
> Association for a Free Informational Infrastructure            (ffii.org)
> FSF Europe                                            (www.fsfeurope.org)
> 
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

Re: [Boa Constr] Interface comments

[Riaan B. <riaan@e.co.za>]

Hi Randy,

Randy wrote:
> 
> >
> > I want to clear up something which you seem to expect of Boa.
> > Boa is not just a Frame Designer, it aims to be an Python IDE
> > supporting as many Python technologies as possible that aid the
> > development process.
> 
> Against my will, I switched from Boa to Xemacs because Boa
> does not support editing of remote Python CGI server files via
> FTP, and Xemacs does. I would very much prefer using Boa but
> cannot directly do so for my CGI work.
> 
> One alternative is to do my CGI development locally with Boa
> and upload files to the server, but using Xemacs to remotely
> edit server files works better - the server changes are
> instantaneous and the development is far faster and easier.
> 
>      Randy

The current CVS version is halfway there, FTP connections can be 
browsed with the explorer and can be copy and pasted to the 
filesystem.
The idea is definitely to end up editing the Boa modules 
transparently over FTP, but we're not there yet.

As an amusing but effective quick hack you may try is the following;
if you are not using the Zope side of Boa. My Zope Explorer 
implementation uses FTP as the transport.

In Editor.py change the definitions of the Zope Views (for me line 69) 
from:

defZopeDocModelViews = (HTMLSourceView,)
adtZopeDocModelViews = (ZopeHTMLView,)

to:

defZopeDocModelViews = (PythonSourceView,)
adtZopeDocModelViews = ()

Also define under the 'zope' section of Explorer.*.cfg the parameters
of your FTP connection. 

This adds the thin layer of syntax highlighted Python on top of
essentially a FTP text document model. Basic operations like Save, Find,
Cut/Copy/Paste etc work, but features that access parsed python
datastructures fail, so expect a lot of noise on stderr ;)

HTH in the meanwhile...

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

Re: [Boa Constr] Interface comments

[Riaan B. <riaan@e.co.za>]

Bernhard Reiter wrote:

[snip]

>   ------------------------------------------------------------------------
>                      Name: weaknesses.txt
>    weaknesses.txt    Type: Plain Text (text/plain)
>                  Encoding: quoted-printable
> 
>    Part 1.2Type: application/pgp-signature

[snip]

>         h) 
> 
> It would be nice if Zope and CVS capabilties 
> could each completly be switched off.

I've just discovered Boa also has a time mashine!

To turn of Zope, SSH or FTP support in the explorer just remove the
entries from Explorer.*.cfg under the 'explorer' section.
I don't remember when I did this, so you might be able do do it.

I've just changed the Palette to only display the Zope page if the
zope dictionary is defined in the config file.

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

[Boa Constr] web page administrivia

[Mark W. A. <mw...@ga...>]

Riian,

The `Project` link on http://Boa-Constructor.sourceforge.net/ is
incorrect. It points to http://sourceforge.net/projects/Boa-Constructor/,
but should be http://sourceforge.net/projects/boa-constructor/ (lower
case).

Mark Alexander
mw...@ga...

[Boa Constr] control layout in GUI Designer

[Geoff T. <gta...@na...>]

How can I get Boa's GUI Designer to let me locate controls to multiples of 4 instead of multiples of 8?

The reason I ask is because I'm trying to line up a bunch of wxStaticText controls with wxTextCtrl controls, and they line up properly if the wxStaticText's y position is 4 units below the wxTextCtrl's y position.  But the GUI Designer is snapping all controls to multiples of 8.

Thanks in advance!

--


- Geoff Talvola
  Parlance Corporation
  gta...@Na...

Re: [Boa Constr] Interface comments

[Bernhard R. <ber...@in...>]

Hi Riaan,
thanks for the prompt reply.=20
I will try to answer and explain as much as I can.

Note that every program need one principal designer.
And you are the designer for boa.=20
It is not my intention to give you advice which necesarrily=20
is best and would lead to the best results, because you have to
decide and it is better get one consistant system instead of
a patchwork by multiple people.
I am trying to discuss some of the design principle and I do have
some experience with IDEs and developing interfaces.

Talking about Borland, I have a couple of years ago stopped to deal
with their products, because they never were excelent. Just because
VB and Delphi are very popular does not mean that they are well
designed. It is no argument, it is just that most people have not
bothered to do better.

To actually really improve Boa, I would need to have the time to do a full
examination on the interface, which I have not. So I hope that my
sometimes half baked comments might be at least inspiring.



On Tue, Jan 16, 2001 at 02:48:10AM +0200, Riaan Booysen wrote:
> Bernhard Reiter wrote:

> > My comments are attached. Generally: Boa feels too big.

> Sorry to have to tell you this but Boa will get bigger still.

My problem is not that it is big, but it feels big. :)
Of course bigger programs are harder to make right on all edges.
Smaller programs can be tested more thoroughly, but you'll know.
I was just suprised that you started adding thinks for tasks were
other tasks could not relyably be done. Trying to do all in once
is likely to be very hard and likely to fail.
Despide this you have done a nice job and I am not complaining.

> I definitely agree with your later statements though, that users who=20
> do not need specific functionality should be able to turn it off.

This would definetly help.
Main reason that Boa feels so big is that you are not guided enough
through all the different actions you can take. This does not mean
you have to limit the power user of course.

Having the possibility of opening more than one frame designer and
more than one collections editor seems to be overkill from my point
of view.

> I have quite a clear vision of what Boa is and where it's going.
> Some of the things that you see as weaknesses, I see as strengths.

Naturally.
But you have to expect that boa might never become a tool which is
good for many people. (Which is my goal in helping to improve it.)
And we are in free software, we can have many versions.
Maybe boa-constructor-imperator (the big version) and
boa-constructor orophias (the small island version). :)

> Boa is not just a Frame Designer, it aims to be an Python IDE
> supporting as many Python technologies as possible that aid the
> development process.

I know. Integrated tools are harder to maintain and improve.=20
Of course we all use a tool-box and it is very nice to have all the
tools fit together.

> Also I've adopted quite a few conventions from Delphi. They may not
> all seem intuitive to someone who has not used Delphi, but would
> to someone who has (I hope!).

I cannot tell. But maybe delphi users will.
But python is certainly different from Delphi and you can adopt
different conventions when you want it.
As the designer you probably do not have any problem learning your
own conventions.=20

> > It was much more stable this time than last time.
> Thanks, but also thanks to Kevin Gill and Shane Hathaway.
Thanks Kevin and Shane.

> > ps.: My wxPython article in German in
> > http://www.sw-development.de/deutsch/magazin/magazin.html
>=20
> I wish I could read it, but my German is worse than my Prolog :)
> Babelfish will probably not do it justice, but I'd like to try if you
> could mail me a copy.

The article is not online. :(
I still have to put it online and work things out with the
publisher. (They are new in the market, it was the first issue.)
Boa is only mentioned very brief.

> > and its mentioning of Boa was well received.
> I'd love to read some of the feedback.

Most of it was not in writing.
Tom Schwaller of famous the German "LinuxMagazin" told me that you
wanted to try Boa now. He always wanted to, but I was faster. ;-)

We already agreed on a).

> >         b)
> >=20
> > It should be possible to use a different editor.

> To what degree of integration? With which editors?=20
> I'm editor agnostic.=20

Nedit, (g)vim and (x)emacs come to mind.
It should be nice to have a documented way on how to use a different
editor. It is mostly a reminder so you think about it in your design
decisions.

> To a certain degree you can already use a different editor, just
> save after posting changes. Will it be sufficient if Boa could detect
> when another application saved changes to a module and prompt to
> reload?=20

This would be a start!

> This way (if the other editor also detects when Boa saves)
> you should be able to easily switch between Boa and your favourite=20
> editor.

Yes! Maybe you should enable it that an external command can be
configured and run when Boa changes the code. So the editor can be
triggered.  This is the most basic integration, but it should be
useful.

> >         c)

> > There are too many GUI rules to learn.=20
> > First it looks like I can have most windows I will need on my screen and
> > I just use notebook-like tabs to switch between them.  The frame design=
er
> > window obviously deviates from this rule.
>=20
> This is the way Delphi does it. I definitely prefer this to the VB like
> frame in a window editing style.

This is okay, IMO.

> > But Collection editors break it somehow.=20

> Also like in Delphi, collection editors have their own windows.

That you can open more than one of course explains this.
I would vote against having more that one open at a time.

> > They are a submenu of the=20
> > inspector and the post and chancel buttons of the inspector are not
> > ghosted (visibly disabled).
>=20
> They should not be disabled, they should actually post and close all
> Designers. This has been fixed.=20

Okay.

> > On the other hand the properties of the objects in the collection
> > editor do again appear in the inspector, but now I cannot use the post
> > or chancel buttons. There is no button to use now. This was suprising
> > for me, I consider it unintuitive.
>=20
> As far as I understand you, this has been fixed.

Okay.

> > I suggest to place the collectors editor on screen from the beginning.

> All of them?=20

Well just one. But as I said I have not yet find the situations to
actually find it useful to have more than one open.

> On a busy frame there might be quite a few! Remember you
> are also not limited in the number of Designers which you have open.
> This is not practical.=20
> I think it's better to open them as needed.=20

I agree, when you have multiple windows open.
I though that the collection editor is to be used only once and then
commited and closed.

> > (You might want to use the up to now unused space over the editor window
> > and make the main window a bit slimmer.)
>=20
> Which unused space? I ran out of space a long time ago :)

Depends on your screen. I was talking about what show up as upper
main window on my screen. It is quite empty in the right side, here.

> > When editing collection properties I suggest to open another inspector.
>=20
> I don't agree. The inspector shows the currently selected item from
> which ever Designer (Frame, Data or Collection) that you selected last.
> I do agree that Designers should unselect their selection if something=20
> is selected in another Designer. It's on the todo.

Okay.

> >         d)
> >=20
> > I was also severly confused by the options of the elements in the main
> > window and the places were I can use these element.=20
>=20
> This is probably confusing at first because different pages behave
> differently, but is explained on the Palette page of the application=20
> help (slightly out of date).=20

It there is the possibility to make it more intuitive without
reading help I think it would be appreciated.

> > It seems a good idea
> > to me to disable the options when I am not allowed to use them.
>=20
> This is not technically correct, because the palette's control pages
> work on the concept of 'loading' your cursor (the action will only be=20
> completed once you click in a receptive window) you can actually
> select a button to be added before you even open the Designer.
> Only the the Dialogs palette page require that you have source view=20
> open before clicking on a button.
>=20
> > Like Disable application, when I am in the Frame Designer.
>=20
> Feel free to create as many Application modules when you have the
> Frame Designer open. There is nothing illegal about that.

I get it know. IMO the normal way of actions should be limited.
This probably guides almost all users better. Why not change this
"loading" the pointer concept. It is also getting in the way when
you need to create like three buttons and so on. This would allow
you to just disable and enable the palette selection. I would regard
this as a use usability advantage.

> > Disable Zope, when there is no Zope connection.
> > And so on.
>=20
> The Zope palette also work on the 'loading' principle. But I agree that=
=20
> it should not be there if the user has Zope support turned off.

Agreed.

> > It will reduce the choises and help to focus on the work.
> > The less options a user has, the higher the chance that he will select
> > the right one.
> >=20
> >         e)
> >=20
> > The current keyboard accelerators=20
> > should be shown in the menus entries, behind the label.
>=20
> wxPython does not yet support the standard right aligned accelerators
> and I was hoping for them to appear before adding this.

Okay. Nice.
(To my shame I must admit that I forgot to thoroughly check the TODO list.)

> I've just added the accelerator after the menu between <> brackets.

Nice.

> >         f)
> >=20
> > If you need a sort of commit button to make a change in a window
> > permanent, it should look the same for each window (including subwindow=
s.)
>=20
> If you are refering to commiting changes in a view (e.g. the Source=20
> control) to the model this is always Refresh.
> Commiting changes from the model to the disk is always Save ;)
> Commiting changes to all GUI building windows is Post.
>=20
> Do you want refreshing your source to also be done with a Post button?
>=20
> Each is different, even though technically the GUI builders are views
> which commit changes to the model, they run in a session which freezes
> the other views until the session is either commited or cancelled.

See this is very complicated. Why not make it simpler and all
concepts the same. Not thinking very deeply about I guess that it
can be done.

> >         g) (almost an addition to c) )
> >=20
> > The big part of a good inspector is, that you can inspect each
> > object with it.  When using Boa I had the impression that the
> > main control point is the inspector once I have pressed a button
> > in a frame to design it.  So I always have to get back to the
> > inspector to commit my changes to do something else.
> >=20
> > Sometimes the main control point for my subsequent action will
> > again change the windows to the main window (like editing
> > something in Data.)
>=20
> I don't really understand you here, could you please rephrase.

It is about what to do next and the role of the inspector.
In NeXTStep an inspector was just there to inspect any selected
object, no matter what it was. So the object metaphor held.

Boa does not seem to make it this way, because of the cancel and
post buttons. AS I learned from your mail, these buttons do actually
close all designers. The inspector can inspect various objects, why
are they in the same window? (As you can see, it did confuse me. :))

I assumed that the changes made in the inspector will be posted,
when I press the post button and thrown away, when I do not press
the post button. For inspecting collection object properties, this
does not hold.

> >         h)=20
> >=20
> > It would be nice if Zope and CVS capabilties=20
> > could each completly be switched off.
>=20
> OK, but is CVS really that intrusive?=20

Yes. It is just the overwhelming=20
capabilities that should be switched off by default.

> You won't know about CVS unless=20
> you choose to go into a CVS folder, and when you do, the view is so
> much more useful than seeing Entries, Repository and Root files.

Well I was fearing as with some integrated system, that there will
be some intelligence acting and I do not know what will happen.

> Thanks for your comments and article!

You are welcome, thanks for sharing Boa.
I guess that Boa will get much more popular in the future.
(Did you btw clear up the bugs in the bug-tracker sometimes?)

Best,
	Bernhard

--=20
Professional Service around Free Software                (intevation.net) =
=20
The FreeGIS Project                                         (freegis.org)
Association for a Free Informational Infrastructure            (ffii.org)
FSF Europe                                            (www.fsfeurope.org)

Re: [Boa Constr] Interface comments

[Randy <ra...@re...>]

>
> I want to clear up something which you seem to expect of Boa.
> Boa is not just a Frame Designer, it aims to be an Python IDE
> supporting as many Python technologies as possible that aid the
> development process.

Against my will, I switched from Boa to Xemacs because Boa
does not support editing of remote Python CGI server files via
FTP, and Xemacs does. I would very much prefer using Boa but
cannot directly do so for my CGI work.

One alternative is to do my CGI development locally with Boa 
and upload files to the server, but using Xemacs to remotely 
edit server files works better - the server changes are
instantaneous and the development is far faster and easier.

     Randy

Re: [Boa Constr] Interface comments

[Riaan B. <riaan@e.co.za>]

Hello Bernard, thank you very much for your comments and feedback.

Bernhard Reiter wrote:
> 
> Dear Riaan,
> 
> got a chance to test a fresh version of Boa yesterday.
> My comments are attached. Generally: Boa feels too big.

Sorry to have to tell you this but Boa will get bigger still.
I definitely agree with your later statements though, that users who 
do not need specific functionality should be able to turn it off.

I have quite a clear vision of what Boa is and where it's going.
Some of the things that you see as weaknesses, I see as strengths.

I want to clear up something which you seem to expect of Boa.
Boa is not just a Frame Designer, it aims to be an Python IDE
supporting as many Python technologies as possible that aid the
development process.

Also I've adopted quite a few conventions from Delphi. They may not
all seem intuitive to someone who has not used Delphi, but would
to someone who has (I hope!).

> 
> It was much more stable this time than last time.

Thanks, but also thanks to Kevin Gill and Shane Hathaway.

> 
> My contratulations on the tutorial, it is very nice and was badly
> needed. 

Kevin Gill did that, much better than I ever could.

> Some thing are so obscure that I never would have guessed
> them without reading the tutorial. ;->
> 
> I hope that my feedback help to improve Boa.

Definitely.

> Please forward specific replies to me, as I am not on the list.
> 
> Keep up the good work,
>         Bernhard

Will do.

> 
> ps.: My wxPython article in German in
> http://www.sw-development.de/deutsch/magazin/magazin.html

I wish I could read it, but my German is worse than my Prolog :)
Babelfish will probably not do it justice, but I'd like to try if you
could mail me a copy.

> and its mentioning of Boa was well received.

I'd love to read some of the feedback.

>   ------------------------------------------------------------------------
>                      Name: weaknesses.txt
>    weaknesses.txt    Type: Plain Text (text/plain)
>                  Encoding: quoted-printable
> 
> Sun Jan 14 17:33:50 CET 2001
> Mon Jan 15 17:08:10 CET 2001
> Boa Constructor GUI remarks, tested CVS Version from 8th of January (v0.0.4.5)
> with wxPython-2.2.2 on GNU/LinuxPPC
> (Running through the tutorial.)
> 
> 
>         a)
> 
> The lines in the editor should be formatted to fit into to 80 characters
> per line or a free configuratable value. This is important if I want to
> use a different editor.

This is on the todo list, it has a lowish priority because you (can but)
shouldn't be working on generated code. But agreed, it will be done.

> 
> 
>         b)
> 
> It should be possible to use a different editor.

To what degree of integration? With which editors? I'm editor 
agnostic. Before Boa I used to work mostly in the Delphi IDE, Boa has
most of the basic keyboard short cuts I used so I'm happy ;)
The keys are defined in PrefsKeys.py

To a certain degree you can already use a different editor, just
save after posting changes. Will it be sufficient if Boa could detect
when another application saved changes to a module and prompt to
reload? This way (if the other editor also detects when Boa saves)
you should be able to easily switch between Boa and your favourite 
editor.

> I know that this will create difficulties, but the integrated approach
> of Boa certainly is a weakness. 

I see the integration as a strength. Boa is an IDE after all ;)

> I don't know Delphi's IDE, but I know
> that it can be done more seperated. The NeXT Step Project- and
> interface builder for instance are a good example.

I don't know the NeXT Step IDE ;)
Please check out Delphi when you have a chance. It is an incredible
piece of software (and you now have a good background)

> It would be nice if there would be a subproject using boa to just
> construct the GUI part and couple it up with a program which can be
> developed independently from Boa. That does not seem to work out right
> now. WxDesigner goes more in this direction.
> 
>         c)
> 
> There are too many GUI rules to learn. 
> First it looks like I can have most windows I will need on my screen and
> I just use notebook-like tabs to switch between them.  The frame designer
> window obviously deviates from this rule.

This is the way Delphi does it. I definitely prefer this to the VB like
frame in a window editing style.

> But Collection editors break it somehow. 

Also like in Delphi, collection editors have their own windows.

> They are a submenu of the 
> inspector and the post and chancel buttons of the inspector are not
> ghosted (visibly disabled).

They should not be disabled, they should actually post and close all
Designers. This has been fixed. 

> On the other hand the properties of the objects in the collection
> editor do again appear in the inspector, but now I cannot use the post
> or chancel buttons. There is no button to use now. This was suprising
> for me, I consider it unintuitive.

As far as I understand you, this has been fixed.

> I suggest to place the collectors editor on screen from the beginning.

All of them? On a busy frame there might be quite a few! Remember you
are also not limited in the number of Designers which you have open.
This is not practical. I think it's better to open them as needed. 
Note, I've implemented 'default actions'. 
Components now define a default action which should be triggered when 
the component is double clicked. For controls which have a collection
this usually opens up the collection editor. For others like buttons,
this defines an OnButton event. This should make the opening of
collections less tedious.

I just thought about it some more, maybe collection editors for which
there is code defined could open up when the Designer is opened.
Added as a todo.

> (You might want to use the up to now unused space over the editor window
> and make the main window a bit slimmer.)

Which unused space? I ran out of space a long time ago :)
If you are refering to the white space that opens up in the editor,
it is the Data view designer in which you create invisible 
components as found on the Utilities palette page (only wxMenu and
wxImageList work). You refer to Data later on, so I'm not sure I
understand you correctly.

> When editing collection properties I suggest to open another inspector.

I don't agree. The inspector shows the currently selected item from
which ever Designer (Frame, Data or Collection) that you selected last.
I do agree that Designers should unselect their selection if something 
is selected in another Designer. It's on the todo.

> 
> 
>         d)
> 
> I was also severly confused by the options of the elements in the main
> window and the places were I can use these element. 

This is probably confusing at first because different pages behave
differently, but is explained on the Palette page of the application 
help (slightly out of date). 

> It seems a good idea
> to me to disable the options when I am not allowed to use them.

This is not technically correct, because the palette's control pages
work 
on the concept of 'loading' your cursor (the action will only be 
completed once you click in a receptive window) you can actually
select a button to be added before you even open the Designer.
Only the the Dialogs palette page require that you have source view 
open before clicking on a button.

> Like Disable application, when I am in the Frame Designer.

Feel free to create as many Application modules when you have the
Frame Designer open. There is nothing illegal about that.

> Disable Zope, when there is no Zope connection.
> And so on.

The Zope palette also work on the 'loading' principle. But I agree that 
it should not be there if the user has Zope support turned off.

> It will reduce the choises and help to focus on the work.
> The less options a user has, the higher the chance that he will select
> the right one.
> 
>         e)
> 
> The current keyboard accelerators 
> should be shown in the menus entries, behind the label.

wxPython does not yet support the standard right aligned accelerators
and I was hoping for them to appear before adding this.

I've just added the accelerator after the menu between <> brackets.

> 
>         f)
> 
> If you need a sort of commit button to make a change in a window
> permanent, it should look the same for each window (including subwindows.)

If you are refering to commiting changes in a view (e.g. the Source 
control) to the model this is always Refresh.
Commiting changes from the model to the disk is always Save ;)
Commiting changes to all GUI building windows is Post.

Do you want refreshing your source to also be done with a Post button?

Each is different, even though technically the GUI builders are views
which commit changes to the model, they run in a session which freezes
the other views until the session is either commited or cancelled.

> 
>         g) (almost an addition to c) )
> 
> The big part of a good inspector is, that you can inspect each object with it.
> When using Boa I had the impression that the main control point is the 
> inspector once I have pressed a button in a frame to design it.
> So I always have to get back to the inspector to commit my changes 
> to do something else.
> 
> Sometimes the main control point for my subsequent action will again change the windows to the main window (like editing something in Data.)

I don't really understand you here, could you please rephrase.

> 
>         h) 
> 
> It would be nice if Zope and CVS capabilties 
> could each completly be switched off.

OK, but is CVS really that intrusive? You won't know about CVS unless 
you choose to go into a CVS folder, and when you do, the view is so
much more useful than seeing Entries, Repository and Root files.

Thanks for your comments and article!

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

[Boa Constr] Interface comments

[Bernhard R. <ber...@in...>]

Dear Riaan,

got a chance to test a fresh version of Boa yesterday. 
My comments are attached. Generally: Boa feels too big.

It was much more stable this time than last time.

My contratulations on the tutorial, it is very nice and was badly
needed. Some thing are so obscure that I never would have guessed
them without reading the tutorial. ;->

I hope that my feedback help to improve Boa.
Please forward specific replies to me, as I am not on the list.

Keep up the good work,
	Bernhard

ps.: My wxPython article in German in 
http://www.sw-development.de/deutsch/magazin/magazin.html
and its mentioning of Boa was well received.


-- 
Professional Service around Free Software                (intevation.net)  
The FreeGIS Project                                         (freegis.org)
Association for a Free Informational Infrastructure            (ffii.org)
FSF Europe                                            (www.fsfeurope.org)

Re: [Boa Constr] Mixing in unsupported widgets and other questions

[Riaan B. <riaan@e.co.za>]

Hi Scott, rest assured, you are supposed to add your own code to the 
generated code. In brief, just don't touch the _init_* methods.

Harris Scott R CIV AFRL/SNJM wrote:
> 
> I'm looking for some documentation or guidance regarding the overall
> intended use of Boa Constructor.  I'm able to build simple demo apps, but I keep
> getting the feeling that I'm using the tool incorrectly.
> 
> For example, my goal is to build a GUI around an app I'm writing that uses the visualization toolkit (VTK).
> If I build the GUI and then add code to insert a wxVTKRenderWindow everything works fine. Going back to the
> designer and making changes causes my added code to be deleted.  

Where did you put the code that got lost?

> Where can or can't I put code I've written?

All methods starting with _init_* are generated and maintained by Boa.
Their bodies are regenerated when you open the designer and post
changes.

When events are defined, an On* method will be added to your class,
Boa does not touch the bodies of these methods.

Any other methods will be left as they are.

> Can I modify the code written by Boa Constructor, or will that break something?

Yes you may edit generated code (_init_* methods). As long as the 
structure is consistent with generated code it will be parsed when 
the Designer is opened. This is not advised though. (Humans aren't as
consistent as computers)

> 
> What are good strategies for mixing my code with Boa's code?

In your case just define your wxVTKRenderWindow in __init__ below the 
call to _init_ctrls.

You may add any number of classes/functions to a generated module.
You may add any attributes or methods to a generated class.

> 
> In addition, is there a simple way to rename the classes I'm creating.  If I start building an about box I'd like to
> call it wxMyAboutBox or something like that. Boa calls it wxDialog1.  Is there a simple way to change the name
> of objects?

In the Inspector, change the Name property of the Frame, Dialog or
control.
To change the name of the module, do a Save As...

> 
> I guess what I'm really looking for is a few pages of documentation that describe the design philosophy, high level operation of
>  the program, and how to use it to build large, real programs.

I will add this to the todo list.

> 
> As I come up to speed, I'd be happy to help out and write up some additional documentation.  It might also be useful to
> make the guide available as a separate download.  I found it by accident because it's not part of the 0.4 download.

Kevin Gill wrote the Guide/Tutorial since the 0.0.4 release, it will 
be part of 0.0.5.

> 
> Thanks for your help in advance,
> -Scott Harris
> 
> _______________________________________________
> Boa-constructor-users mailing list
> Boa...@li...
> http://lists.sourceforge.net/mailman/listinfo/boa-constructor-users

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

[Boa Constr] Mixing in unsupported widgets and other questions

[Harris S. R C. AFRL/S. <Sco...@wp...>]

I'm looking for some documentation or guidance regarding the overall
intended use of Boa Constructor.  I'm able to build simple demo apps, but I keep
getting the feeling that I'm using the tool incorrectly.

For example, my goal is to build a GUI around an app I'm writing that uses the visualization toolkit (VTK).
If I build the GUI and then add code to insert a wxVTKRenderWindow everything works fine. Going back to the
designer and making changes causes my added code to be deleted.  Where can or can't I put code I've written?
Can I modify the code written by Boa Constructor, or will that break something?

What are good strategies for mixing my code with Boa's code?

In addition, is there a simple way to rename the classes I'm creating.  If I start building an about box I'd like to
call it wxMyAboutBox or something like that. Boa calls it wxDialog1.  Is there a simple way to change the name 
of objects?

I guess what I'm really looking for is a few pages of documentation that describe the design philosophy, high level operation of
 the program, and how to use it to build large, real programs.

As I come up to speed, I'd be happy to help out and write up some additional documentation.  It might also be useful to
make the guide available as a separate download.  I found it by accident because it's not part of the 0.4 download.

Thanks for your help in advance,
-Scott Harris