kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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