kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

Wayne Stambaugh wrote:
> 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
>
> I thought I would weigh in on this subject since this was one of my
> primary goals when I joined the project. First I would like to start
> out with a disclaimer. This message is not intended to hurt anyone's
> feelings, spread FUD, and/or discourage anyone from participating in the
> development of Kicad. I apologize in advance for any misunderstandings.
> These are just observations from my own experience.
>
> I think the biggest problem you will encounter is not changing the UI
> code of Kicad's dialogs. That is fairly trivial whether you are using
> wxDialogBlocks, wxFormBuilder, or writing the dialog source with you
> favorite editor. It is the interdependency between the UI code and the
> actual code that manipulates the underlying document the will take the
> most effort. This was what stalled my efforts. You will find that many
> of Kicad's dialogs suffer from this problem. If you don't clean this up
> first, you will find that no matter what tool you use to generate the
> dialog UI code the task will be much more difficult than you anticipated.
>
> Once you've fixed the interdependency problem, the next problem will be
> interpreting the GNOME user interface guidelines as mentioned in
> UIPolicy.txt as it applies to Kicad. If you happen to find a dialog in
> Kicad that remotely resembles anything described in the GNOME UI
> guidelines, I sure would like to know about it. I actually changed the
> annotation dialog in EESCHEMA to fit the GNOME UI guidelines as best I
> could. It has since been almost completely reverted to the original
> incarnation of the dialog.


Thanks for the feedback on this dialog. We could have used this info 
more effectively at the time the change was made. If you still think 
your version is closer to our goals, maybe we can take a look at it 
now. Maybe mention to us which SVN version it was and we can look at it.



> I guess this was done to make it look like
> the rest of the Kicad dialogs before the latest stable release. I have
> read the GNOME UI guidelines and I did not see any mention of using
> colored text in controls, non-standard fonts in dialogs and frames, not
> respecting the platform specific widgets theme, etc. Are all the
> developers of Kicad aware of UIPolicy.txt? If so, why aren't they
> following it? Did someone (as I suspect) just add UIPolicy.txt
> hoping that everyone would follow this standard? I also thought that
> one of the goals of wxWidgets was to create programs that would look
> reasonably native to the platform it was compiled for. Kicad does not
> look native on any platform that I am aware of. Is the project truly
> going to adopt the GNOME UI guidelines? Is the project willing to live
> with some UI inconsistencies (which seems a bit silly given the current
> situation) until all of the dialogs are updated? I know that I will
> wait until a consensus is reached on this one before I make anymore UI
> updates. ;)
>
> And last but by no means least, using RADS and IDES in my opinion is not
> very good idea. While they make it easy to prototype and quickly make
> layout changes to dialogs, they encourage developers to open a file and
> to begin haphazardly throwing things together without any thought about
> project structure, code reuse, code readability, software architecture,
> etc. I realize that this is not the tools fault. It is the lack of
> discipline of the developer. I have been guilty of this myself. If you
> take a look at many of the Kicad dialogs generated by wxDialogBlocks it
> is not uncommon to see the following pattern: m_Control1, m_Control2,
> .... m_Controln. In order to find out which control correlates to which
> selection or action you have to search the source for where the control
> was created or open it in wxDialogBlocks to figure out what it does. 

I agree with your statement about variable names. There is a way within 
DialogBlocks to rename these controls, so I would not concur that this 
is an inherent problem of that tool. Yet again the more meaningful 
variable names are obtainable within that tool when the time is taken to 
rename the variable within the tool.

If we see that a hammer is bending nails, rather than driving them in 
straight, there is a tendency to blame the hammer. 

Obviously folks use a tool like this because they are not full time 
wxWidgets programmers and they want visual feedback on what they are 
contemplating. When you put down the code and come back to it 6 months 
later, having the tool to remind you what a class is can be helpful. I 
think that while what you are saying about investment in code structure 
is largely true, we have to come to the point of recognizing that time 
and expertise are precious in an open source project, there is none to 
spare. So initial productivity is the trump card.

In the Java world I have traveled down both paths that you describe. 
In the C++ world I have also, infact I once wrote a package like 
wxWidgets from the ground up on OS/2 to duplicate an API called 
GlockenSpiel's CommonView. So I can relate very well to what you are 
saying and agree with most all of it. But in the final analysis it is 
the carpenter's skills, not the hammer's capability that will determine 
the effectiveness of the hammer.


And obviously I agree with your statement 100% about the bad spot we are 
in with respect to dialog window code referencing variable names too 
deeply embedded within the document structure, leading to an undesirable 
interdependency. 

But if we paid our programmer's more we'd probably get better work, 
eh? No answers to this issue from me. It's a friggin miracle to me 
that any open source exists at all without a corporate sponsor. And 
very little does, if we are honest.


Dick


> If
> you generated this source code by hand you would probably give the
> controls readable names like m_buttonEnableFoo and m_buttonDisableBar.
> While RADs give an initial time savings, they generally create
> maintainability issues for the life of the source. Another issue is
> that many of the dialogs in Kicad use different sizer and layout
> spacing. wxWidgets has supported creating standard sizer layouts
> settings since at least version 2.4 using wxSizerFlags which makes
> creating standard sizers fairly easy. The advantage of using
> wxSizerFlags is that you could create default sizer spacings for most
> common dialog layout styles. This way when the GNOME UI guidelines
> decide to change the dialog frame spacing from 12 pixels to 20 pixels,
> all you have to do is change one wxSizerFlag number, recompile, and all
> of your dialogs have the new spacing. If you use a RAD, you would have
> to manually edit every single dialog. These are the kinds of things
> that you tend think about when you use an editor (although not always)
> to write the dialog source. If your like me and don't like wasting
> keystrokes (read lazy), these are the kinds of things to consider before
> writing any code.
>
> Just my two cents,
>
> Wayne