← Back to team overview

kicad-developers team mailing list archive

Re: wxFormBuilder and the future

 

On Tue, Aug 18, 2015 at 3:26 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

> On 8/17/2015 9:14 AM, David Novak wrote:
> >> To be honest, I've never been a big fan of dialog box layout tools.
> >> Their strength is there weakness.  They promote designing quick dialog
> >> box layouts that makes reuse difficult.  Take a look at the padding and
> >> overall layout in KiCad's dialogs.  They are all over the map.  I prefer
> >> hand coding dialogs.  It's painfully slow but encourages reuse (well
> >> designed base dialog classes) and standardization (using wxSizerFlags).
> >
> > I agree with Wayne. Dialog layout tools are nice to get up and running
> > quickly, but the more I use them, the more they get in the way. On
> > internal projects, my team ends up implementing workarounds for advanced
> > features.
> >
> > I've recently started trying to convince my team to code the dialogs by
> > hand. In my mind, with a little planning up front, hand coding the
> > dialog could be relatively quick.
> >
> > David
> >
>
> Thanks for the vote of confidence.  I thought I was the lone voice in
> the woods when it came to hand coding dialogs.  I doubt we will have an
> easy time convincing everyone else it's a good idea.  That being said,
> we may end up in a position where we have no option if there is not a
> viable open source option.  I would reject using a proprietary tool and
> I don't want to waste precious KiCad development resources maintaining
> wxFormBuilder.
>
> [snip]
>

I think hand-coded stuff is best, but GUI widgets and windows can be
very difficult to work with for people who don't code for it on a frequent
basis. To help with the development I think we would need some
home-grown documentation which includes:
(1) example of how to code the basic class representing the dialog,
which of course may be derived from a class like DIALOG_SHIM.
(2) guides on how to use sizers and place widgets within them
(3) guides on commonly used widgets and their attributes and events,
with examples of how they go into a window and how to set up to
service an event. Sure all that information can be read in the
wxWidgets documentation, but for occasional GUI coders that's
an awful lot of documentation to wade through and a lot of logical
links to make.

Sometimes I still miss Think C++ on the Mac; 30 years ago it set
things up just as wxFormbuilder does, except that it worked well
and kept up to date with Apple's widgets. I think the closest thing
to it these days is Microsoft's Visual Studio.

- Cirilo

References