← Back to team overview

kicad-developers team mailing list archive

Re: wxformbuilder version

 

If it counts for anything, I personally would like to see this done now
on dialogs like José describes: ones where the wxfb-generated code isn't
sufficient and so they get monkeypatched in the subclass constructor.
That's really, really ugly, and I'm not sure I see much of a
disadvantage to getting rid of it now - as long as anyone doing this is
aware that their efforts might be lost or heavily modified in the
future.

On Fri, Sep 02, 2016 at 08:48:33PM -0500, José Ignacio wrote:
> I'm talking about some simple particular cases where the dialogs are
> both simple (just a few boxes), and the code already muddles with it
> anyway. One such case is the pcbnew/dialog_graphic_item_properties
> which I submitted a patch for recently. When that dialog is called,
> the code changes the visibility and labels of some of the boxes
> depending on the type of graphic item that summoned the dialog. In
> that case a GUI-only change in wxFB could potentially break the dialog
> because the derived class touches the layout. I think in that case it
> might be best to just go all the way and make the dialog declarative.
> The impact would be minimal as the translation strings would remain
> the same, and the layout would be practically the same too, the code
> would just be cleaner in intent and easier to modify.
> 
> For more complicated dialogs I agree they should remain in wxFB for
> the time being, until someone figures out a clean way to implement
> them declaratively.
> 
> On Fri, Sep 2, 2016 at 8:22 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> > For 5 stable release, I would rather stick with wxFormbuilder than open
> > up a Pandora's box of other issues.  For the stable 6 release, we need
> > to have a discussion about if and how we want to implement
> > programmatically created dialogs.  I want our dialogs to be more
> > consistent in terms of spacing and layout and use the proper wxWidgets
> > method for transfer data to and from controls.  That will be an involved
> > discussion.
> >
> > On 9/2/2016 8:23 PM, José Ignacio wrote:
> >> Would patches to make some of the simpler dialogs programmatic be accepted?
> >>
> >> On Fri, Sep 2, 2016 at 7:17 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> >>> We've been dancing around this issue for a while without any real
> >>> resolution.  I'm fine with using Mark's version of wxFB but a lot folks
> >>> are going to want to use whatever is packaged for their distro rather
> >>> than build wxFB from source which presents a serious issue.  I'm not
> >>> sure there is a good answer for this problem.  If no one else has any
> >>> objections, I'm willing to make Mark's wxFB fork the official version
> >>> for KiCad dialog submission for the time being.  In the long run, if
> >>> wxFB is not actively being developed, I would rather come up with an
> >>> alternative.
> >>>
> >>> FWIW, I think most of you know how I feel about dialog creation tools
> >>> vs. creating them programmatically.  Kicad's dialogs used to be created
> >>> this way but I got out voted at the time the decision was made to switch
> >>> to wxFB.  I'm feeling better about my choice all the time. ;)
> >>>
> >>> On 9/2/2016 7:11 PM, Chris Pavlina wrote:
> >>>> I would vote in favor of using Mark's fork officially for everyone, if
> >>>> it builds okay on all the platforms. wxfb is kinda nasty, if we're going
> >>>> to use it it's nice to have our own fork that solves at least a few of
> >>>> these issues.
> >>>>
> >>>> On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote:
> >>>>> I just use MRoszko's fork; it's cleaner than the original and much
> >>>>> easier to configure and build since the bizarre wxFB build system
> >>>>> had been eradicated and replaced by CMake.
> >>>>>
> >>>>> git clone https://github.com/marekr/wxFormBuilder.git wxfb
> >>>>> cd wxfb && git checkout wxFB3.5-1
> >>>>>
> >>>>> A half year or so ago I tried the later wxFB in development but it
> >>>>> broke so many things that I just reverted the files and went back to
> >>>>> wxFB3,5-1.
> >>>>>
> >>>>> - Cirilo
> >>>>>
> >>>>>
> >>>>> On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina <pavlina.chris@xxxxxxxxx>
> >>>>> wrote:
> >>>>>
> >>>>>> Along these lines: this isn't the first time wxfb version issues have
> >>>>>> come up. Perhaps we should pick an "official" wxfb version for the
> >>>>>> project to use, and then actually provide builds of it for developer use
> >>>>>> (as it can be a bit annoying to track down a specific version)? Then we
> >>>>>> can upgrade together as new versions come out.
> >>>>>>
> >>>>>>
> >>>>>> On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
> >>>>>>> dialog_pad_properties_base.fbp h cpp was last modified in commit
> >>>>>>>
> >>>>>>> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> >>>>>>> https://git.launchpad.net/kicad/commit/?id=
> >>>>>> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> >>>>>>>
> >>>>>>> the problem is this version of wxformbuilder is newer than the one
> >>>>>>> available on sourceforge and it is very difficult to build on other
> >>>>>>> platforms ( i tried a while ago and gave up as it had issues)
> >>>>>>>
> >>>>>>> the version that was used to save these files has broken it on older
> >>>>>>> versions of wxformbuilder
> >>>>>>>
> >>>>>>> Is there a version of wxformbuilder that we should be using to avoid
> >>>>>>> it breaking on other versions?
> >>>>>>>
> >>>>>>> the last available from sf.net is 3.5rc1 iirc
> >>>>>>>
> >>>>>>> thanks
> >>>>>>>
> >>>>>>> Simon
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> 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
> >
> 
> _______________________________________________
> 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


Follow ups

References