kicad-developers team mailing list archive

[jean-pierre charras <jean-pierre.charras@...>]

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).
> Jean-Pierre will hopefully offer an opinion here also.
Done.
> Dick

--

Jean-Pierre CHARRAS

Maître de conférences
Directeur d'études 2ieme année.
Génie Electrique et Informatique Industrielle 2
Institut Universitaire de Technologie 1 de Grenoble
BP 67, 38402 St Martin d'Heres Cedex

Recherche :
GIPSA-LIS - INPG
46, Avenue Félix Viallet
38031 Grenoble cedex