kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

Here, have another vote of confidence. Very few GUI builders aren't 
crap, and most are fairly inflexible. wx is not a difficult toolkit to 
work with in general and any developer who can write decent code should 
be able to interact with it directly. Perhaps it is not a bad thing for 
"can write wx code" to be the "you must be this tall to enter" for the 
kicad codebase? ;) wxformbuilder is buggy - seriously, does anybody here 
*enjoy* working with that thing?? - and doesn't support some of the 
nicer widgets.

As for future plans to port to Qt - as much more as I like Qt than wx, 
that'd be rather a waste of dev time IMO.


On Mon, Aug 17, 2015 at 01:26:02PM -0400, Wayne Stambaugh 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.
> 
> > 
> > On 8/13/2015 2:41 PM, Wayne Stambaugh wrote:
> >>
> >> On 8/13/2015 2:05 PM, jp charras wrote:
> >>> Le 13/08/2015 18:36, Eldar Khayrullin a écrit :
> >>>> Hi all.
> >>>> Maybe in future need to port kicad in other modern gui as qt(
> >>>> https://en.wikipedia.org/wiki/Qt_(software) )
> >>> A bit overkilled for this issue (if this is an issue).
> >>> I am not especially thrilled by QT.
> >>> This is a very good tool, but it has its own issues.
> >>> Good luck to volunteers who will port 400 000 lines of code relative
> >>> to GUI.
> >>> (80% of code of any application; Kicad has more than 500 000 lines of
> >>> code)
> >> We'll leave that decision to the next project manager.  This project
> >> manager is not interested porting KiCad to QT.  This has been discussed
> >> before.
> >>
> >>>> 13.08.2015 13:00, Blair Bonnett пишет:
> >>>>> Hi all,
> >>>>>
> >>>>> It appears wxFormBuilder is, if not dead, not far from it. The
> >>>>> evidence:
> >>>>>
> >>>>> * No stable release in 4 years, and the last beta release was 13
> >>>>> months ago.
> >>> Although I agree with the fact wxFormBuilder is not actively maintained,
> >>> the last release was made the 17 June.
> >>>
> >>> I share your concern about wxFormBuilder.
> >>>
> >>> But replacing it is not easy.
> >>>
> >>> To answer one of your questions, before using wxFormBuilder, I used
> >>> DialogBox (free version).
> >> I'm reluctant to use proprietary tools for all of the usual reasons.  I
> >> would rather code dialogs by hand than use a proprietary tool.
> >>
> >>> It worked fine and was easy to use.
> >>> It is written and maintained by the creator of wxWidgets.
> >>>
> >>> But the user code is embedded in automatically generated DialogBox.
> >>> I did not used recent versions, so it is perhaps now different.
> >>>
> >>> One on the *best features* of wxFormBuilder is the fact it creates
> >>> "black box" files and all the user code is in other files.
> >>> You even do not need to read them.
> >>>
> >>> Any other candidate should have this feature.
> >>>
> >>> We need volunteers to test other candidates (in fact a very few
> >>> candidates)
> >> 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 got shot down the last time I suggested this and I understand the
> >> reasoning.
> >>
> >>>
> >>>>> * A grand total of 13 commits in the last 12 months (current trunk is
> >>>>> r2205, r2192 was made on 1 August 2014). A number of these are
> >>>>> buildsystem / release / changelog (!) updates.
> >>>>> * No developer responses on the mailing list, including to a message
> >>>>> three months ago [1] asking if the project was still active.
> >>>>> * No support for newer widgets. For example, the wxSpinCtrlDouble
> >>>>> widget added in wxWidgets 2.9.0 is not supported. I patched it to add
> >>>>> this widget back in April and posted the patch to both the mailing
> >>>>> list and an existing ticket from three years ago [2]. No response to
> >>>>> that either.
> >>>>>
> >>>>> We may have to start thinking about whether we continue with it from
> >>>>> here, or consider a move towards a different tool.
> >>>>>
> >>>>> I realise any change like this isn't going to happen prior to the
> >>>>> stable release, and nor am I suggesting it should. But with the recent
> >>>>> post to this list about UI improvements, I think this is a highly
> >>>>> related topic which should be discussed as well.
> >>>>>
> >>>>> There are a number of alternatives listed on the wxWidgets wiki [3].
> >>>>> Does anybody have any experience with any of them? (Spoiler alert, I
> >>>>> don't). Are there any thoughts on how to proceed from here?
> >>>>>
> >>>>> Regards
> >>>>> Blair
> >>>>>
> >>>>>
> >>>>> [1] https://sourceforge.net/p/wxformbuilder/mailman/message/34100789/
> >>>>> [2] https://sourceforge.net/p/wxformbuilder/feature-requests/45/
> >>>>> [3]
> >>>>> https://wiki.wxwidgets.org/Tools#Rapid_Application_Development_.2F_GUI_Builders
> >>>>>
> >>>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp