kicad-developers team mailing list archive

[Manveru <manveru@...>]

2008/9/2 jean-pierre charras <jean-pierre.charras@xxxxxxx>:
> Dick Hollenbeck a écrit :
>
>> Have you read the Kicad project's UIpolicies.txt document?

I just read it. Gnome rules are very good in general. If I have time I
will read more. Sizers are obvious for me.

>> To the non-developer user, the behavior of the dialogs is more important
>> than the tool used to create them. So our main concern needs to be
>> window behavior.

If we correct code implementing dialogs, then usability can be improved easier.

>> I would not oppose the switch to this wxFormBuilder tool. It does seem
>> like a nice design. My biggest problem with DialogBlocks is that it
>> limits us to 30 controls per dialog.

wxFormBuilder does not have such limitation. And it allows to move
controls to different places around window.

> This is the main (and I believe, the only one) problem.
> The fact DialogBlocks is a commercial tool is - in this special case -
> not a problem because :
> - kicad does *not*depend on this tool (sources could be edited by hand
> if DialogBlocks disappears)

I don't think this is the best method of improving dialog windows.

> - it is written by Julian Smart, the author of wxWidgets. I believe if
> a problem arises with Julian Smart, this will be with wxWidgets, not
> DialogBlocks.

Some advantage of DialogBlocks.

> I did not yet tested wxFormBuilder ( I will do ASAP).
> The question is only: Is it suitable and good (more than DialogBlocks ?)
> for the dialogs creations *and* maintenance.

I feel wxFormBuilder v.3.0 easier to use than DialogBlocks. But this
is my opinion.

> I tested others tols like it and they were not so easy to use ( or
> stalled for some free and open source tools).
> Stalled open source tools (there are a lot of) are a problem also when
> you are using them ...

wxFormBuilder looks like actively developed - I found it on page
comparing wxSmith (which is plugin to CodeBlocks IDE). According to
that table only wxDevC++ and wxForms support more widgets, but that
table seems to be not currently actual, as wxFormBuilder started
supporting conditional UI.
Link: http://wiki.codeblocks.org/index.php?title=Comparison_of_wxSmith_features

> And also: is it sure tools used to create an open source must be open
> source, if they are not critical:
> Are you sure your text editor is open source ?

PSPad is free, but not open source :-) Eclipse is open source.

> Are you sure your bios is free and open source ? (And i do no talk about
> the firmware of your mouse !)

In my dreams... I now have open sourced phone... Maybe BIOS in my PC someday :-)
But I can live with closed firmware to some stuff, but I would like to
see open source project tied up with other open projects not
commercial (less or more).

>> But any conversion effort would be protracted, and there would be
>> several months where we would be living with dialog windows coming from
>> two different tools. I again would be willing to live with this.
>> However it may end up being *years*. We have seen folks come before and
>> offer to enhance dialogs. They do a couple and then quit.
>>
> This is true ...
>
> but old dialogs do not require to be converted.
> Only new could be written with an other tool (o an older if/when redesigned)

Interface should be consistent from user's point of view as from
developer's point of view. If this will be divided between different
tools it makes more mess only.

>> My main concern would be that when converting each dialog, that we
>> enhance any dialog window which currently does not follow the
>> UIpolicies.txt document into conformance with it.

I can take polices into account during "conversion". But I probably
need an reviewer of these changes (optical).

>> I am especially fond of expandable dialog windows, as a simple search of
>> this list will show.
>>
>> (The class naming discussion does not necessarily need to be part of
>> this tool discussion. However, having said that, I also am not fond of
>> WinEDA_ as a prefix for so many class names. And simplifying class
>> names does not mandate namespace adoption. Namespaces are a collision
>> avoidance mechanism. There are not that many classes in Kicad. The
>> only reason I used a namespace in the specctra import/export was because
>> some of the class names had the potential to overlap some already in
>> Kicad.)
>>
> WinEDA_ as a prefix was not a very good idea.
> but I think a prefix (I used Ki_ (shorter and more meaningful) in some
> last created classes ) is useful to identify what is a kicad source,
> and what is an other source (like the kbool library).
> wxWidgets does that, and it is a good idea (assuming wxWidgets authors
> are not beginners).

Maybe "ki", like "kiPrintOutput"? I personally prefer class names as
CamelCase with capitalization of all words, but it this case this
would be a prefix. Prefixes are important in libraries, but do we
really need them in KiCad main code?

Michal