kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

I'm all in favor of dropping the .fbp and autogeneration in such
simple cases as well. Initially I had a few such dialogs while working
on the 3D plugin system but personally found that wxFB was
more of a nuisance than an aid in those cases so I threw out
the autogenerated files and coded the GUI by hand. Maybe I'm
just an old fart who grew up with hand-coding GUIs, but with
the exception of the Think C++ GUI generator on the Macs
25 years ago and the MSVS GUI generator for C++ (which
I barely tolerate), I've found all other GUI helpers quite annoying
because they seem to aim to hide the fairly simple GUI coding
procedures and keep programmers mystified rather than
educating people on how a GUI framework works.  I'd lump
wxFB with MSVS in the "just tolerable" class, but to be fair
I'd say wxFB is very far from the worst and perhaps even one
of the better ones.

- Cirilo


On Sat, Sep 3, 2016 at 11:55 AM, Chris Pavlina <pavlina.chris@xxxxxxxxx>
wrote:

> 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
>
> _______________________________________________
> 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
>