kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

jean-pierre charras wrote:
> Dick Hollenbeck a écrit :
>>
>>
>> Regarding the two classes per dialog, one of which would be derived
>> from the other, we might think about adopting a pair of prefixes to
>> show that these two classes are related and share a common purpose by
>> way of a common basename, for example, with "basename" being variable
>> per such pair:
>>
>>
>> fbr_basename.cpp holding a class with name FBR_BASENAME
>> autogenerated by wxFormBuilder
>>
>>
>> dlg_basename.cpp holding the class derived from FBR_BASENAME with
>> name DLG_BASENAME which has the hand coded event handlers.
>>
>>
>> fbr_xyz.cpp and dlg_xyx.cpp would always be considered part of a set
>> implementing the dialog window. dlg_xyx.cpp in a rare case might
>> not be needed if there were not custom event handlers.
>>
>>
>> Could we agree on such a scheme, if JP were to accept the
>> wxFormBuilder?
>>
>>
>> Dick
>>
>>
>>
> 
> I had a look to wxFormBuilder 3.0 and it seems a very good tool.
> Switching from DialogBlocks to wxFormBuilder is Ok for me.
> 
I have no problem using wxFormBuilder if that is the consensus but it
suffers from the same basic problems as wxDialogBlocks. Every time you
regenerate the dialog UI source, you have to post process it with
uncrustify to get the source format to meet the (proposed) project
guidelines. Uncrustify doesn't get it completely right so you have to
manually format what uncrustify misses. This process has to be repeated
every time you change the dialog UI source for both the source and
header files. In the end, I don't know that you save that much time and
effort. There are current some Kicad dialogs where the code generated
by wxDialogBlocks has not been reformatted properly. They are very
difficult to read when your editor is configured for 80 character line
lengths.

> Wayne, I know an autogenerated dialog code is not the best.
> It is more difficult to understand (and maintain by hand) than dialogs 
> created by hand (and by a skilled guy)
> and it is far from an optimal code.
> 
> But some guys can be skilled programmers and do not know very well the 
> use of wxSizers (and a lot others items useful in nice dialogs)) in 
> wxWidgets.
> So using a tool like wxFormBuilder (when correctly used) can be a very 
> acceptable way of work.
> Using a tool like wxFormBuilder could be also a way to understand the 
> use of these useful items.
> 
RAD tools are great for learning how sizers work. You can quickly make
changes to your code and see the effect on the final output. I don't
use them for any production code that I write because their limitations
far outweigh any benefits that I get from them. I had to make the leap
to sizer based window layouts when I moved from MSVC to wxWidgets. It
took me a while, but I am much better off for putting in the effort to
learn (and I'm still learning) how to use them effectively. Now sizer
based window layout feels much more natural to me than fixed layouts.
Developers new to sizer based layouts can get up to speed fairly quickly
by using wxPython. That is path I took since I already was experienced
with Python.

Wayne