kicad-developers team mailing list archive
Mailing list archive
Re: Dialog layout updates.
Wayne Stambaugh <stambaughw@...>
Tue, 26 Feb 2008 14:37:17 -0500
Thunderbird 220.127.116.11 (Windows/20071031)
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.
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