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