Dick Hollenbeck a écrit :
Michal,
Have you read the Kicad project's UIpolicies.txt document?
To the non-developer user, the behavior of the dialogs is more important
than the tool used to create them. So our main concern needs to be
window behavior.
I would not oppose the switch to this wxFormBuilder tool. It does seem
like a nice design. My biggest problem with DialogBlocks is that it
limits us to 30 controls per dialog.
This is the main (and I believe, the only one) problem.
The fact DialogBlocks is a commercial tool is - in this special case -
not a problem because :
- kicad does *not*depend on this tool (sources could be edited by hand
if DialogBlocks disappears)
- it is written by Julian Smart, the author of wxWidgets. I believe if
a problem arises with Julian Smart, this will be with wxWidgets, not
DialogBlocks.
I did not yet tested wxFormBuilder ( I will do ASAP).
The question is only: Is it suitable and good (more than DialogBlocks ?)
for the dialogs creations *and* maintenance.
I tested others tols like it and they were not so easy to use ( or
stalled for some free and open source tools).
Stalled open source tools (there are a lot of) are a problem also when
you are using them ...
And also: is it sure tools used to create an open source must be open
source, if they are not critical:
Are you sure your text editor is open source ?
Are you sure your bios is free and open source ? (And i do no talk about
the firmware of your mouse !)
But any conversion effort would be protracted, and there would be
several months where we would be living with dialog windows coming from
two different tools. I again would be willing to live with this.
However it may end up being *years*. We have seen folks come before and
offer to enhance dialogs. They do a couple and then quit.
This is true ...
but old dialogs do not require to be converted.
Only new could be written with an other tool (o an older if/when redesigned)
My main concern would be that when converting each dialog, that we
enhance any dialog window which currently does not follow the
UIpolicies.txt document into conformance with it.
I am especially fond of expandable dialog windows, as a simple search of
this list will show.
(The class naming discussion does not necessarily need to be part of
this tool discussion. However, having said that, I also am not fond of
WinEDA_ as a prefix for so many class names. And simplifying class
names does not mandate namespace adoption. Namespaces are a collision
avoidance mechanism. There are not that many classes in Kicad. The
only reason I used a namespace in the specctra import/export was because
some of the class names had the potential to overlap some already in
Kicad.)
WinEDA_ as a prefix was not a very good idea.
but I think a prefix (I used Ki_ (shorter and more meaningful) in some
last created classes ) is useful to identify what is a kicad source,
and what is an other source (like the kbool library).
wxWidgets does that, and it is a good idea (assuming wxWidgets authors
are not beginners)
