kicad-developers team mailing list archive

["stambaughw" <stambaughw@...>]

--- In kicad-devel@xxxxxxxxxxxxxxx, Lorenzo Farina <flm_mail@...> wrote:
>
> Hello. I'm trying to add wxAUI and Art support to Kicad (eeschema &
pcbnew). This will be time-consuming, but I hope snapping toolbars
(and, next, internal frames) could make interface mutch more simple.
I'm actually working on complete menus, this means that (as every MS
application), every toolbar command should be found also on menus.
This is because a lot of functions cannot be understood by new users
simply watching icons, and changes could give a standard interface.
I'm very interested in development of Kicad, witch is actually THE
best GPL schematic and PCB drawing. However, threre are a few things
that needs to be changed before massive use. One of the most
importants is the wire-snap-to-pin facility. Is there anyone who is
working on that?
> Thanks.
> 
> 
>

Hi Lorenzo,

I have been following this thread and wanted to put my in two cents. 
First let me say I admire your ambition taking on such a large
project. The wxAUI has some very interesting features that would
probably be very beneficial to Kicad. However, before getting input
from the Kicad developers or users about making major changes to the
user interface (and you should get that input), you may want to take a
serious look at the code base. The Kicad code has been around a while
and there is very little separation between the user interface code
(view) and the document manipulation code (model - the schematic in
the case of EESchema). I am speaking from experience. I thought I
would lend a hand and give some of the Kicad dialogs some much needed
love by attempting to make them more consistent. I picked the
annotate dialog in EESchema to start. Easy right? Wrong! The
annotation code directly accesses the controls in the dialog and
vice-versa. There wasn't even the typical SetFoo/GetFoo functions to
access the controls in the dialog. So it turned out to be a much more
difficult task than I originally anticipated (isn't it always?).

I am not trying to discourage you (although I'm probably doing a good
job of it). You should know what you are getting yourself into. It
may be better for your wxAUI implementation and the project in general
to start at a lower level and consider trying to implement a
model/view/controller or model/view/presenter design pattern to
isolate the interaction between the UI and the model. This would have
the added benefit of being able to keep the current UI design without
disrupting your wxAUI code every time a change is made to the code
that effects the model. If you attempt to fit wxAUI into the current
design, I fear you will quickly become discouraged and give up. I'll
be interested in seeing your wxAUI implementation.

Good Luck,

Wayne