kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> 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.
> 
The original changes where committed on SVN version 800. I coded this
version by hand effectively removing it from wxDialogBlocks. I have
been working on making changes against the current version using
wxDialogBlocks and have things pretty much the same as my original
commit. I will try to commit the changes some time this weekend. I'll
probably send a message to the developers list to get some input and
share some of my frustrations with the current code.
> 
> 
>> 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.
> 
That's why the chainsaw is my favorite tool. You quickly find out when
you've made an error in judgment when using one.
> 
> 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. 
> 
I am glad I am not alone in my thinking. I was beginning to wonder if I
was way off base. I guess I will attempt to refocus my efforts on
cleaning up some of the low level plumbing before doing the more
glamorous work of UI design.

Wayne
> 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
>>
>> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
> 
>