Hi Christoph, thank you for reconsidering.
Although this thread hasn't been entirely pleasant for me, it has
definitely highlighted the need for a 'lighter' Boa.
I've now spent some time going thru the code, examining
dependencies and testing whether I could do what I promised 
For now suppose 'light' mode may be set with a commandline option
or preference setting.
The following components will be excluded:
Palette
Inspector
Frame Designer
I can see ways to make this work by adding lots of ifs and moving
certain imports out of module scope into function scope.
This is not the cleanest way to do this, but it's a good start.
It can be gradually refactored to something neater.
On a smaller scale it is very simple to remove views associated with
a model. They are defined as a tuple in the constructor of the
model's controller.
One question at the moment is the Inspector. It is not only
used by the Frame Designer, but also by some Explorers like Zope,
DAV and Preferences.
The Explorer classes cannot be left out because they provide the
transport layer for the Model objects. (items you open in the Editor)
If we decide we do need the Inspector, we also get the Companion
and PropertyEditor classes which make up a large part of the code
used by the Frame Designer.
I'd appreciate more feedback about what people would want in such
a light version of Boa.
Hi Riaan,
[Riaan Booysen wrote]:
>Boa is your wxIDLE.
>This is the *primary* role that Boa tries to fulfill,
>GUI building,Zope, etc are secondary for me.
>This is complete overlap!
>The IDE/Editor component that you talk about
> is ready for use in Boa,
>stable and offers equivalent functionality to IDLE.
>...
>I don't think this is a good idea,
>and am against yet another ide.
>Please help out with Boa.
>Why not work together on a wxPython IDE
>for Python instead of dividing resources
>and duplicating work? Boa aready does everything you want,
>you can help make it work the way you want it.
I cannot speak, of course, for Terrel, but personally I think you are
right.
What made me think of a "wxIDLE" as something apart from Boa
was simply my
impression of Boa as something fantastic but monolithic and huge
that would still have a long way to go. But what is there is really
great and that's why I had the idea of using Boa's editor for
"wxIDLE": it was clear for me that not using it would be something
like trying to reinvent the wheel.
I mean Boa is not exactly what I imagined as "wxIDLE",
it is (already now) much more. So my request for Boa is much in
line with Robin's advice for "wxIDLE".
[Robin Dunn wrote]:
>My one request for wxIDLE:
>Be sure to design it with a plug-in
>architecture. (Plug-in Editors: code editor,
>layout editor, menu editor, etc.
>Plug-in Tools: simple debugger, remote debugger,
>Bob's debugger, class browser, PythonCard, etc...)
If this is compatible with your future design ideas for Boa then
thinking of "wxIDLE" in fact means thinking basically of the Editor
and Shell components of Boa and it is of course infinitely more
meaningful to think of it as a part of a larger context (i.e. Boa) than
to take it out of this context into something "new" and smaller like
a "wxIDLE". This would indead mean wasting resources.
Seen from that angle I have to admit that my idea for "wxIDLE" was
not a very good one. But, on the other hand, if it helped bringing
broader attention, some new ideas and fresh life to the
development of Boa, it was still ok.
Christoph
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwindows.org
http://lists.wxwindows.org/mailman/listinfo/wxpython-users
This is my take on the 'Plug-in' nature of the components in Boa;
Boa itself is a framework in which many different 'boa plug-ins'
like explorers, controllers, models, views, companions, etc are
plugged in. This makes it very easy to extend Boa because most of the
work for integration in the IDE is done for you (indeed Boa could
never have grown as it has without such a framework), but the
drawback is of course that these classes are only useable in the
Boa framework.
Let's look at the Frame Designer as a plug-in component;
The DesignerView is just another (granted, big) EditorView class that
plugs into any BaseFrameModel, similarly for the DataView. Both these
views derive from InspectableObjectView which provides functionality to
view objects in the Inspector. Controls in the Frame Designer
have corresponding Companion classes that define their design-time
behaviour and are also referenced on the Palette. When the Designer is
closed the companions are serialised to the method their View
maintains (e.g. the Frame Designer maintains _init_ctrls,
Collection Editors maintain _init_coll_*, etc).
These methods are then finally written back to the Model through
the Module object that all Python Models (derived from ModuleModel)
have.
The point of this rather long winded description was to show how
the process of Frame Designing spans across quite a few of the
IDE framework components. To me, it does not make sense to separate
the Frame Designer from the boa framework.
If I had to create a stand-alone Designer plugin, I would add a pseudo
framework to this Designer plugin.
Enough for now (too much already
···
CCF.Herzog@gmx.net wrote:
--
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
http://boa-constructor.sourceforge.net
