kicad-developers team mailing list archive
Mailing list archive
Re: Re: AUI support
The focus depends on whether you are a user or a developer. They are
both important. The end user cares about GUI design and consistency not
that the underlying code is well written. A well designed UI will
attract users to and that should be one of the goals of the project. If
I thought no one was going to use it, I wouldn't invest my time in the
project. However, if you create the "perfect" UI but the underlying
code is a mess, I can assure you that most (if not all) of the
developers on this list will care. That was the point I was trying to
make. If changing something as trivial a dialog box layout was as much
effort as I have put into the annotate dialog, I can't imagine how
difficult changing the UI design would be. I was just trying to save
you (and the other developers) a lot of grief.
Hello. Thanks for advices.
I understand that the focus is not about GUI look but how the GUI and
the code is written.
I share genral opinion that SDI is simpler than MDI, and I don't want
to change it. However, wxAUI support could be the starting point for
internal frames, such as snapping panels, toolbars, command line and
look and feel customization. I also understand this is not an easy
task. The question is: at actual status, is it really needed? Or
others improvements are more important? I think (this is no more than
my very humble opinion) a better look and feel could help new users
to move to Kicad.
I have seen both good and poor implementations of SDI, MDI, CLI, etc. I
think most people have their own personal preference. I do agree that
Kicad needs some UI polishing to help attract new users.
For what is about menus, my opinion is still not changed. I'm talking
to one of the main developers, and this should be enought to make me
silent. However, let me explain something.
For programs witch looks standard, like kicad (standard behavoir,
usual menus, toolbars), the first user expects to find every common
command also on menus. I agree that a Draw menu with each drawing
command is not necessary, but I don't understand why
undo/redo/save/print and similar commands are both in menus and
toolbars, but there is not New into File menu, cut/copy/paste into
edit, and something similar. This looks incomplete (for me).
Last message I referred to Blender to make an opposite example. This
is not standard, in other words, when you open it, you
understand: "Hello. I'm not standard, and you need time to learn how
to draw. But this improves your drawing speed and possibilities.".
Actually there is not this galvanic separation between standard and
non standard application. The same problem will be only moved to
future. If extended menus are not needed, the code will be only for
You have just described why writing end user software is so difficult.
If it were easy, everyone would be doing it.
I hope to do something useful, and I know this could be a very long
operation. As soon as there is something working, I'll post a new
I'll give a try when it's ready. Just don't for get about the rest of
use poor developers while you are coding.
Yahoo! Groups Links