kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #01060
Dialog layout updates.
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
"Wayne Stambaugh" <stambaughw@...>
-
Date:
Tue, 26 Feb 2008 15:42:52 -0000
-
User-agent:
eGroups-EW/0.82
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
Follow ups