← Back to team overview

kicad-developers team mailing list archive

Re: Dialog layout updates.

 

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.)

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.

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.

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.

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








Follow ups

References