← Back to team overview

kicad-developers team mailing list archive

Re: DialogBlocks discussion once again.

 

jean-pierre charras wrote:
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)
There is a video about wxFormBuilder on their site. That is a quick way to see approximately what it does and how it works.

It generates a class, and in that class are a few virtual functions which remain unimplemented. You then derive from that abstract class, and implement the functions in the derived class. So the wxFormBuilder editor does not have to parse the hand written functions. It only knows that they exist, not how they are implemented.

This is version 3.0, and I'm thinking I also may have tried an earlier version and went away disappointed. JP, let us know what you think about the tool after you know more about version 3.x.

Dick









References