Re: [Kicad-developers] wxformbuilder version

[Cirilo Bernardo]

Sorry - ignore the last post - I managed to miss the part of the patch
that did specify the branch.

- Cirilo

On Thu, Sep 8, 2016 at 8:08 AM, Cirilo Bernardo 
wrote:

> I think the note needs to add some instructions to check out the
> wxFB3.5-RC1 branch.
> The default 'master' is probably not something we want at this point in
> time.
>
> - Cirilo
>
> On Wed, Sep 7, 2016 at 10:09 PM, Maciej Sumiński 
> wrote:
>
>> Wayne,
>>
>> I attach a patch updating the UI policy. I would rather you commit the
>> patch, to be sure you agree with the changes.
>>
>> Regards,
>> Orson
>>
>> On 09/03/2016 02:17 AM, Wayne Stambaugh 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.ch...@gmail.com>
>> >>> 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@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[Cirilo Bernardo]

I think the note needs to add some instructions to check out the
wxFB3.5-RC1 branch.
The default 'master' is probably not something we want at this point in
time.

- Cirilo

On Wed, Sep 7, 2016 at 10:09 PM, Maciej Sumiński 
wrote:

> Wayne,
>
> I attach a patch updating the UI policy. I would rather you commit the
> patch, to be sure you agree with the changes.
>
> Regards,
> Orson
>
> On 09/03/2016 02:17 AM, Wayne Stambaugh 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  >
> >>> 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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[Simon Wells]

yeah there has been talk in the irc channel

On Thu, Sep 8, 2016 at 3:51 AM, Wayne Stambaugh  wrote:
> Simon, thanks for update.  I knew it wasn't going to be that easy.  I'm
> guessing mroszko will be OK with this.
>
> On 9/7/2016 11:50 AM, Simon Wells wrote:
>> Just fyi mroszko's code doesn't currently build on osx, due to missing
>> stuff in cmakelists.txt i will try and find some time to make a patch
>> and send it to mroszko so there is something on osx
>>
>>
>>
>> On Thu, Sep 8, 2016 at 3:05 AM, Wayne Stambaugh  wrote:
>>> I'll commit it if there are no other serious objections.  Speak now or
>>> forever hold your peace.  This may be short lived if the wxFB folks
>>> start working on wxFB again.  If they do, I hope they come up with a
>>> better release version policy.
>>>
>>> On 9/7/2016 8:09 AM, Maciej Sumiński wrote:
 Wayne,

 I attach a patch updating the UI policy. I would rather you commit the
 patch, to be sure you agree with the changes.

 Regards,
 Orson

 On 09/03/2016 02:17 AM, Wayne Stambaugh 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 
>>> 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@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[Wayne Stambaugh]

Simon, thanks for update.  I knew it wasn't going to be that easy.  I'm
guessing mroszko will be OK with this.

On 9/7/2016 11:50 AM, Simon Wells wrote:
> Just fyi mroszko's code doesn't currently build on osx, due to missing
> stuff in cmakelists.txt i will try and find some time to make a patch
> and send it to mroszko so there is something on osx
> 
> 
> 
> On Thu, Sep 8, 2016 at 3:05 AM, Wayne Stambaugh  wrote:
>> I'll commit it if there are no other serious objections.  Speak now or
>> forever hold your peace.  This may be short lived if the wxFB folks
>> start working on wxFB again.  If they do, I hope they come up with a
>> better release version policy.
>>
>> On 9/7/2016 8:09 AM, Maciej Sumiński wrote:
>>> Wayne,
>>>
>>> I attach a patch updating the UI policy. I would rather you commit the
>>> patch, to be sure you agree with the changes.
>>>
>>> Regards,
>>> Orson
>>>
>>> On 09/03/2016 02:17 AM, Wayne Stambaugh 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 
>> 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@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[Simon Wells]

Just fyi mroszko's code doesn't currently build on osx, due to missing
stuff in cmakelists.txt i will try and find some time to make a patch
and send it to mroszko so there is something on osx



On Thu, Sep 8, 2016 at 3:05 AM, Wayne Stambaugh  wrote:
> I'll commit it if there are no other serious objections.  Speak now or
> forever hold your peace.  This may be short lived if the wxFB folks
> start working on wxFB again.  If they do, I hope they come up with a
> better release version policy.
>
> On 9/7/2016 8:09 AM, Maciej Sumiński wrote:
>> Wayne,
>>
>> I attach a patch updating the UI policy. I would rather you commit the
>> patch, to be sure you agree with the changes.
>>
>> Regards,
>> Orson
>>
>> On 09/03/2016 02:17 AM, Wayne Stambaugh 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 
> 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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[Wayne Stambaugh]

I'll commit it if there are no other serious objections.  Speak now or
forever hold your peace.  This may be short lived if the wxFB folks
start working on wxFB again.  If they do, I hope they come up with a
better release version policy.

On 9/7/2016 8:09 AM, Maciej Sumiński wrote:
> Wayne,
> 
> I attach a patch updating the UI policy. I would rather you commit the
> patch, to be sure you agree with the changes.
> 
> Regards,
> Orson
> 
> On 09/03/2016 02:17 AM, Wayne Stambaugh 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 
 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[Wayne Stambaugh]

I've reconsidered for simple dialogs for the time being long as there
are no other major objections.  One thing I will be a lot more picky
(even more than usual :) ) is that I will no longer tolerate overriding
OnOK and OnCancel for transferring data to and from controls which is a
poor design.  If you don't understand what this means see:
http://docs.wxwidgets.org/3.0/overview_validator.html.  I also would
prefer that we create standard wxSizerFlag (
http://docs.wxwidgets.org/3.0/classwx_sizer_flags.html) objects so all
dialogs use the same basic sizer spacing when laying out dialogs.  The
beauty of using wxSizerFlags is that the spacing will be the same for
every dialog and changing the standard sizers automatically updates
every dialog that uses them.  The spacing we have now is fairly
inconsistent.

Cheers,

Wayne

On 9/2/2016 9:48 PM, 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  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  
>>> 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 
>> 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:
 

Re: [Kicad-developers] wxformbuilder version

[Cirilo Bernardo]

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

Re: [Kicad-developers] wxformbuilder version

[Chris Pavlina]

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

Re: [Kicad-developers] wxformbuilder version

[José Ignacio]

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

Re: [Kicad-developers] wxformbuilder version

[Wayne Stambaugh]

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  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 
 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@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : 

Re: [Kicad-developers] wxformbuilder version

[Blair Bonnett]

There's been some activity on the wxFB mailing list over the last couple of
days; somebody proposed switching to GitHub and integrating the CMake
patches that originated here. One of the developers responded and it looks
like they're interested in going in that direction. The SourceForge mailing
list interface is a bit of a pain to navigate but see [1] for the
developers response. The GitHub repository is at [2]; I'm not sure how
'official' this is yet but I dare say we'll find out shortly.

[1]: https://sourceforge.net/p/wxformbuilder/mailman/message/35326676/
[2]: https://github.com/wxFormBuilder/wxFormBuilder
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[Cirilo Bernardo]

On Sat, Sep 3, 2016 at 10:17 AM, Wayne Stambaugh 
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.
>
>
Normally I'd go along with the "users can use whatever version of X is
in their distribution" but wxFB is an extreme case where every stable
version pushed out breaks all previous versions, so going for what's
prepackaged for a distribution in reality will tie the rest of us to
whatever oldest version is available on a contributor's platform and this
is definitely a bad thing. At least using Mark's fork we can make sure
it all builds and runs on all supported platforms and developers will
simply have to build wxFB and maybe even live with 2 versions of wxFB
on their system if they use it for other things as well. On Debian for
example, wxFB is not packaged and building it was an extreme
nuisance until Mark cleaned up the build system and eliminated
numerous counterproductive dependencies which were peculiar to
wxFB's official build system.

- Cirilo



> 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 
> >> 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@lists.launchpad.net
>  Unsubscribe : https://launchpad.net/~kicad-developers
>  More help   : https://help.launchpad.net/ListHelp
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 

Re: [Kicad-developers] wxformbuilder version

[José Ignacio]

Would patches to make some of the simpler dialogs programmatic be accepted?

On Fri, Sep 2, 2016 at 7:17 PM, Wayne Stambaugh  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 
>>> 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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[Wayne Stambaugh]

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 
>> 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@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[Chris Pavlina]

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 
> 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@lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[Cirilo Bernardo]

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 
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@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[Simon Wells]

as far as i can see 3.5.2 hasn't even been tagged in the wxformbuilder svn repo

On Sat, Sep 3, 2016 at 9:35 AM, José Ignacio  wrote:
> I have version 3.5.2
>
> On Fri, Sep 2, 2016 at 4:28 PM, Chris Pavlina  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@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[José Ignacio]

I have version 3.5.2

On Fri, Sep 2, 2016 at 4:28 PM, Chris Pavlina  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@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxformbuilder version

[Chris Pavlina]

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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] wxformbuilder version

[Simon Wells]

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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] wxFormBuilder version

[Moses McKnight]

Hi,

I'm using Linux Mint 16, 64bit

I looked through past posts on the list here, and figured out that wxFormBuilder 
version 3.3.4 is the one to use for kicad dialogs.


So I installed that from a package on the wxFormBuilder site on sourceforge.
But, when I open dialog_fp_lib_table_base.fbp I get the following messages:

01:21:15 PM: The property named skip_lua_events of class Project is not 
supported by this version of wxFormBuilder. If your project file was just 
converted from an older version, then the conversion was not complete. 
Otherwise, this project is from a newer version of wxFormBuilder.  The 
property's value is: 1 If you save this project, YOU WILL LOSE DATA
01:21:15 PM: The property named ui_table of class Project is not supported 
by this version of wxFormBuilder. If your project file was just converted from 
an older version, then the conversion was not complete. Otherwise, this project 
is from a newer version of wxFormBuilder.  The property's value is: UI If you 
save this project, YOU WILL LOSE DATA


Do I actually need a newer version of wxFormBuilder?  Can I just ignore those 
messages?  I tried using 3.5.0 and 3.4.2 and they both wanted to re-write the 
file on the disk just to open it!


Thanks,
Moses

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxFormBuilder version

[Wayne Stambaugh]

On 9/5/2014 2:40 PM, Moses McKnight wrote:
 Hi,
 
 I'm using Linux Mint 16, 64bit
 
 I looked through past posts on the list here, and figured out that
 wxFormBuilder version 3.3.4 is the one to use for kicad dialogs.
 
 So I installed that from a package on the wxFormBuilder site on
 sourceforge.
 But, when I open dialog_fp_lib_table_base.fbp I get the following messages:
 
 01:21:15 PM: The property named skip_lua_events of class Project is
 not supported by this version of wxFormBuilder. If your project file was
 just converted from an older version, then the conversion was not
 complete. Otherwise, this project is from a newer version of
 wxFormBuilder.  The property's value is: 1 If you save this project, YOU
 WILL LOSE DATA
 01:21:15 PM: The property named ui_table of class Project is not
 supported by this version of wxFormBuilder. If your project file was
 just converted from an older version, then the conversion was not
 complete. Otherwise, this project is from a newer version of
 wxFormBuilder.  The property's value is: UI If you save this project,
 YOU WILL LOSE DATA
 
 Do I actually need a newer version of wxFormBuilder?  Can I just ignore
 those messages?  I tried using 3.5.0 and 3.4.2 and they both wanted to
 re-write the file on the disk just to open it!
 
 Thanks,
 Moses
 

Sorry Moses.  I meant to respond to you original question and it just
fell though the cracks.  I'm currently using 3.4.2.  I've used it on
several of the dialogs but there are still many that have not been
updated.  My guess is that there are several versions of wxFormBuilder
dialogs around so I wouldn't worry about it too much.  I noticed that
3.5.0 is now available so I think your OK using that.  The rest of us
will just have to upgrade when we want to modify any of the dialogs
you've edited with 3.5.0.  If any one else has any major objections,
speak now or forever hold you peace.

Wayne


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp