← Back to team overview

kicad-developers team mailing list archive

Re: Dialog layout updates.


Dick Hollenbeck wrote:

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.


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!


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.


Yahoo! Groups Links