← Back to team overview

kicad-developers team mailing list archive

Re: wxFormBuilder and the future

 

Hello all,

Sorry for keep this discussion I know it is not an appropriated time (stable release! :P)

I have no (pro) experience in GUIs or deep knowledge how KiCad is using wxWidgets, but any way, my 2 cents:

I believe usually projects like KiCad, are using a framework (like wx, Qt..GTK..etc) for two main proposes: GUI and general OS stuff (deal with files, internet, keyboard, mouse,..)

For the second propose you always have to rely on a good library: the OS target specif library or a multi OS generic library (wx, Qt, ...)

So far from what I saw in kicad, maybe in the future (after identify the basic requirements with an OS) we can have a kiLayer that will work as a wrap to basic functions. (wxOpen -> kiOpen )
I saw also that kicad uses in some parts lots of "definitions" (types..structs.etc) from the wxWidgets that could be made instead by a local kicad library (ok, I know that it is supposed to reuse ..but) so it would be less dependent on external libs.

Related with the GUI and GUI design.
It seems to me that there is a trend by some recent software that is to use a minimal GUI system.. and develop a simple / minimal UI... that at some point it is the best for the users as it provides a tuned and quick, easy to learn interface.
Usually this approach uses the graphic hardware (opengl / directX) libraries. One good example is the SKIA (https://en.wikipedia.org/wiki/Skia_Graphics_Engine)

Then this softwares usually implement their own minimal GUI (with the forms created hard coded? as some of you pointed.) so they usually looks different and not following the traditional "forms editors"
Some examples in my mind are (Sublime text editor, Blender, Wings3d, popular web browsers, www.zofzpcb.com a 3d gerber viewer , etc ..)

.. and .. if you want.. KiCad is it self a good example: the GAL !

Mario
________________________________________
From: Kicad-developers [kicad-developers-bounces+mrluzeiro=ua.pt@xxxxxxxxxxxxxxxxxxx] on behalf of Chris Pavlina [pavlina.chris@xxxxxxxxx]
Sent: 17 August 2015 23:02
To: kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] wxFormBuilder and the future

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

_______________________________________________
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

References