kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> Wayne,
>
>
> Your capabilities bring great capacity to the project. We welcome your 
> ideas and contributions. 
>
> I like your new dialog window. I did notice that I cannot bail out of 
> the dialog using the ESC key. That is one of the things in 
> UIpolicies.txt. I don't know if wxWidgets is making this harder than 
> it needs to be? (Also sometimes the wxWidgets behavior on Linux is 
> different than on Windows. Sometimes we need to report bugs or 
> enhancement requests to the wxWidgets people and I have not seen any of 
> that yet from this list.)

Thanks for the heads up. I completely forgot check the default key 
bindings. The close button is mapped to wxID_CANCEL. I thought the 
default key binding for the this ID was the escape key. I'll check the 
wxWidgets documentation and come up with a solution. I hope I don't 
have to manually bind the escape key for every dialog box. I think many 
of the differences between linux and windows have to do with wxWidgets 
trying to honor the standard platform behavior.

> There is much to be gained by searching this list on the web for past 
> discussions about things, and possibly linking to those past discussions 
> with new postings, or adding to those threads.
>
> I think the coding guidelines document is an awesome idea! So much so 
> that I had spent a half day working on such a thing, dusting off an 
> internal document that we've used here for more than 15 years with great 
> success. I just got tired during the word processor conversion from 
> old word perfect to openoffice. I don't use openoffice enough to be 
> able to remember it well. I can send you that if you want as a 
> potential starting point.

Please send me a copy and I'll take a look at it. I actually started 
outlining it in plain text to avoid the usually grumbling about having 
to install and learn another program to view and/or edit the file. 
Hopefully no one will have any problems using their text editor.

> To say that I have zero interest in autotools/automake would be an 
> understatement. I have less than zero, (i.e. negative interest). 
> They would waste space on my disk. I am not persuaded by arguments of 
> maturity vs. CMake. 'Maturity' can be interpreted as good or bad. I 
> know of 'mature' dogs who are near death and can't learn new tricks. 
> These are matters of opinion, not fact. And you asked for opinion. So 
> it is quite probable that we will never agree.

Fair enough. I have seen plenty of deserved dislike for autotools. I 
used to feel the same way. I have personally tried CMake, SCons, and 
bjam and I always end up back at autotools. Maybe I'm just masochistic. 
After all, Emacs is my editor of choice. Hmm, perhaps its time for 
some self reflection?

> CMake is *by far* easier to learn than autotools/automake for a 
> developer. We already are maintaining TWO build environments. We 
> should have a third? Have we actually hit a wall with CMake that 
> cannot be addressed by writing a new script and putting it into the 
> CMakeModules directory? Or by enhancing an existing one? And has this 
> shortcoming been communicated to the CMake mailing list? Until that 
> shortcoming can be articulated specifically, we should be careful. I 
> love CMake and absolutely hate autotools/automake.

Here is the one major problem that I have had with CMake. It does too 
many platform specific checks as opposed to feature checks. For 
example, let say the folks at Boost have just implemented some new whiz 
bang class that will make Kicad totally rock. So you check out the 
source, build, and install Boost in your home directory. With autotools 
you just export CPPFLAGS=-I ~/custom_boost_path/include and LDFLAGS-L 
~/custom_boost_path/lib and your new development version of Boost is 
compiled and linked without changing any build configuration files. Now 
lets say that you find your shiny new Boost code is hopelessly broken so 
you go back the release version installed on your system. All you have 
to do is clear your exports of CPPFLAGS and LDFLAGS and away your go. 
If you look at FindBoost.cmake (and every FindFoo.cmake file I have 
looked at seems to do this), you will see that the FindLibrary paths are 
hard coded. CMake only looks for the presence of the file(s) in the 
path(s) in FindLibrary. Autotools checks to see if the appropriate 
header file can be found by the compiler preprocessor and that it 
compiles correctly. In other words, autotools respects the developers 
build settings and validates the headers and libraries you required 
build your project. Maybe it is a philosophical design difference 
between CMake and autotools that I am having trouble wrapping my head 
around. I actually rewrote FindwxWidgets.cmake to behave more like 
autotools but it was a major task and I still don't like the way it 
works with MS tools (not that its important to me, I'm content with 
linux and MinGW for development). I'll save that change for a rainy day 
when I want to here the Visual Studio guys yell at me.

Wayne

> And your excellent point about the "MS Visual what's their thing called 
> today" is an important consideration also, at least for some. That 
> could be the winning argument for those folks.
>
>
> Again welcome!
>
>
> Dick
>
>
> please forgive my top posting.
>
> > First I would like to introduce myself to the group for those of you
> > that I have not contacted directly. My name is Wayne Stambaugh. I
> > have been Electronics Engineer (please don't hold that against me) for
> > over twenty years. I have been using Kicad for almost two years and
> > free software for nearly ten years. Kicad is the ideal project for me
> > to contribute to given my skill set. Hopefully I can help the Kicad
> > project as much as it has helped me.
> >
> > I wanted to get some feedback from the Kicad developers about giving
> > the dialog layouts some much needed updates. I did my best to follow
> > "Gnome Human Interface Guidelines" as specified in UIPolicy.txt in the
> > Kicad root source directory. I am familiar with the Gnome HIG and
> > believe it is a sound document. Please take a look at the annotate
> > dialog in EESchema (SVN version 800) and let me know if you have any
> > serious objections or suggestions. I may make some additional changes
> > to address the spacing when the dialog is resized but other than that
> > I am reasonably satisfied with this layout. If no one has any serious
> > objections, I will continue to update the dialogs until they all have
> > this standard look and feel. If there are serious objections, please
> > let me know what HIG you prefer or send me mock ups of what you feel
> > is the ideal dialog layout. I do not want to commit a lot of time if
> > project is not interested in the changes.
> >
> > I also want to create a developer preferred practices guideline
> > similar to the Linux kernel CodingStyle document. It would be handy
> > for new developers to the project (and as a reference for all
> > developers) for the preferred coding practices used to contribute to
> > the project. I don't want the document to be "this is the way it has
> > to be". That will turn off developers. It should be a document that
> > says as a courtesy to the project, please follow these guidelines. It
> > can also be on light (fun) side like the kernel CodingStyle document.
> > As a courtesy, I will sent this to Jean-Pierre and some of the major
> > contributors for input before adding it to SVN when I have completed it.
> >
> > One last item. I personally am not the biggest fan of CMake. Not
> > that GNU autotools is perfect. It isn't. However, from my experience
> > autotools is designed better and is much more mature. I'm not sure
> > that it supports Microsoft development tools very well or at all but
> > it is the defacto standard for most (*nix) platforms. I actually had
> > a working GNU autotools solution months before CMake was committed to
> > SVN. The main reason I did not commit it was that I could not figure
> > out a sane way to convert the documentation files which are in ODT
> > format into the appropriate help files from the command line. I am
> > still kicking myself for not getting off my butt and submitting it to
> > the project. I am not trying to discourage those who did the
> > excellent CMake work. CMake makes more sense for Kicad if the project
> > needs (wants) to support Microsoft development tools and I will
> > continue to keep the CMake files current for any changes I make. I
> > have seen some other projects use CMake for building Visual Studio
> > projects files and autotools for platforms that have a posix shell. 
> > This solution would also work for Kicad. If there is enough there is
> > enough interest, I will finish up adding the help, library, and
> > internationalization directories and submit it to the project. 
> > Otherwise, I'll just keep using it for my own builds.
> >
> > Thanks in advance for the time, input, and all the hard work.
> >
> > Wayne
>
>
>
>
> Yahoo! Groups Links