kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

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

> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
> 
>