kicad-developers team mailing list archive

[Manveru <manveru@...>]

2008/9/2 Dick Hollenbeck <dick@...>:
>
[...]
>
> If wxFormBuilder were to be used, then the discussion could be limited
> to two class names per dialog window. But let me stray briefly to
> state some general preferences first.
> I prefer *all* upper case class names, not just first letter of each
> word. The reason is that this distinguishes class names from function
> names, for which I prefer the upper case first letter only. Any prefix
> should be indicative of function or purpose. I think using Ki_ is not
> providing value here, since it does not indicate function or purpose.
> But I am not opposed to prefixes in general.
>
> Regarding the two classes per dialog, one of which would be derived from
> the other, we might think about adopting a pair of prefixes to show that
> these two classes are related and share a common purpose by way of a
> common basename, for example, with "basename" being variable per such pair:
>
> fbr_basename.cpp holding a class with name FBR_BASENAME autogenerated
> by wxFormBuilder
>
> dlg_basename.cpp holding the class derived from FBR_BASENAME with name
> DLG_BASENAME which has the hand coded event handlers.
>
> fbr_xyz.cpp and dlg_xyx.cpp would always be considered part of a set
> implementing the dialog window. dlg_xyx.cpp in a rare case might not
> be needed if there were not custom event handlers.
>
> Could we agree on such a scheme, if JP were to accept the wxFormBuilder?
>

IMO very strange coding standard - I've never seen such in any open
source code and commercial code. But decision about this is not mine.

I would prefer DialogClassBase or DialogClassGenerated for code from
wxBuilder and DialogClass for derived code.

I probably need DialogBase class for handling font set up - this has
to be set before controls are created. wxFormBuilder creates them in
class constructor (one another disadvantage of wxFormBuilder).

Could we create coding standard wiki page?

Michal