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