kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

Manveru wrote:
> Hello Dev's
>
> Because I personally do not like the fact that DialogBlocks is somehow
> commercial piece of software and is connected with KiCad. I know that
> opinions on the list are divided, but...
>
> I tried use another form creation tool called wxFormBuilder. It is
> IMHO much nicer than DialogBlocks, but has one annoying disadvantage:
> cannot add code for automatic dialogue window resize (I am looking how
> to properly handle this manually).
>
> Additionally is has different approach to the code generation.
> DialogBlocks do this in more Microsoft way - adds markers in code in
> between code is modified on re-generation. In wxFormBuilder generated
> classes (on file per project) are solid. Additional user functionality
> has to be inherited from base class coming from wxFormBuilder (I
> personally like this clean approach). This can be controversial.
>
> The new windows looks like this: http://manveru.pl/en/node/5 (very
> similar to old one)
>
> The problem with the KiCad code responsible for print dialogue is that
> there is real mess. The one class is implemented in two files, where
> the one of it (share/wxprint.cpp) implements other class. I cleaned it
> up a little when I was trying wxFormBuilder code, but still plenty
> things has to be cleaned up. I do not understand why classes are
> called WinEDA_something, when they could use namespaces (I know, large
> number of programmers do not like namespaces). I do not want to
> criticise anyone's work, but today there is lot of space for
> improvements.
>
> I can slowly clean it up (all dialogue windows moved to
> wxFormBuilder), add Doxygen comments, but I do not know how to handle
> this according to SVN structure (I need to create a lot of new files
> and remove a lot of poorly named files).
>
> I want to know others opinions. So please join the discussion.
>
> Michal

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.


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.

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.)


Jean-Pierre will hopefully offer an opinion here also.


Dick