Re: [Kicad-developers] Dialog field validation on KillFocus

2018-11-29 Thread Jeff Young 
> 
> You may want to tread carefully allowing users to accept invalid
> settings.  They may cause crashes or other unexpected behavior bugs.

Will do.  In most places where it really matters we weren’t trusting the 
on-exit-validation anyway, and already have code in TransferDataFromWindow.

Cheers,
Keff.___
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] Dialog field validation on KillFocus

2018-11-29 Thread Jeff Young 
The red boarder, red text (and a hover error message) would be my preferred 
solution as far as the user is concerned.  But this is straying into toolkit 
land.  That would be one thing if we had our own wxWidgets branches on MSW and 
GTK, or even if we used the latest so I could push some stuff to the official 
wxWidgets.  But since neither of those are true I’m not sure about this 
direction.

Cheers,
Jeff.

> On 29 Nov 2018, at 15:58, Mark Roszko  wrote:
> 
> > This would be more tolerable than a dialog but a red frame may not work 
> > well with all WM themes.
> 
> Make it display an exclaimination mark symbol adjacent to the field as well?
> 
> I'm not sure how well it works but wxWidgets has  
> wxSystemSettings::GetColour() 
> 
>  which could be a way to determine the optimal color. i.e. check on a simple 
> threshold either using one of two colors for contrast.
> 
> 
> 
> On Thu, Nov 29, 2018 at 9:32 AM Wayne Stambaugh  > wrote:
> On 11/29/2018 8:47 AM, Maciej Sumiński wrote:
> > On 11/29/18 2:36 PM, Jeff Young wrote:
> >> While most UI guidelines suggest validating on field exit, it’s not 
> >> without cost.  In particular, on GTK we can’t tell the difference between 
> >> a KillFocus from clicking the OK button (when validation should be run) 
> >> and a KillFocus from clicking Cancel (when it should not).  
> >>
> >> Needless to say, KillFocus-validation also plays very poorly when GTK’s 
> >> focus-follows-mouse is turned on.
> >>
> >> So I plan to do two things:
> >>
> >> 1) Remove automatic validation on KillFocus from UNIT_BINDER.  Clients 
> >> which need validation will be modified to call Validate() themselves from 
> >> their TransferDataFromWindow() methods.
> 
> This way is known to work well across platforms.  Anything else and your
> at the mercy of platform specific event ordering and other UI toolkit
> quirks.
> 
> >>
> >> 2) Remove UNIT_BINDER validation which isn’t needed.  We have a lot of 
> >> validation which just checks for “reasonable” values.  However, our 
> >> definition of “reasonable” doesn’t always match our users’ definitions.  
> >> “Needed” validation (which will remain) is that which prevents 
> >> un-supported situations, or that which makes recovery hard (for instance, 
> >> PCB text with a zero width is hard to select).
> >>
> >> Any comments before I go ahead?
> > 
> > Hi Jeff,
> > 
> > John Beard had a good idea of replacing an error pop-up dialog with an
> > error indicator (red frame around text or red background for text input
> > widget). It will notify the user about potential problems without being
> > too disruptive, and such check might be done by KillFocus event handler.
> 
> This would be more tolerable than a dialog but a red frame may not work
> well with all WM themes.
> 
> > 
> > I would still keep a pop-up dialog showing up if the user wants to
> > accept invalid settings (call Validate() in TransferDataFromWindow()).
> > If we want to provide ammo to shoot their feet, then 'Ignore' button
> > sounds like an appropriate caliber.
> 
> You may want to tread carefully allowing users to accept invalid
> settings.  They may cause crashes or other unexpected behavior bugs.
> 
> > 
> > Cheers,
> > Orson
> > 
> > 
> > ___
> > 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 
> 
> 
> 
> -- 
> Mark
> ___
> 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] Dialog field validation on KillFocus

2018-11-29 Thread Mark Roszko 
> This would be more tolerable than a dialog but a red frame may not work
well with all WM themes.

Make it display an exclaimination mark symbol adjacent to the field as
well?

I'm not sure how well it works but wxWidgets has
wxSystemSettings::GetColour()

which
could be a way to determine the optimal color. i.e. check on a simple
threshold either using one of two colors for contrast.



On Thu, Nov 29, 2018 at 9:32 AM Wayne Stambaugh 
wrote:

> On 11/29/2018 8:47 AM, Maciej Sumiński wrote:
> > On 11/29/18 2:36 PM, Jeff Young wrote:
> >> While most UI guidelines suggest validating on field exit, it’s not
> without cost.  In particular, on GTK we can’t tell the difference between a
> KillFocus from clicking the OK button (when validation should be run) and a
> KillFocus from clicking Cancel (when it should not).
> >>
> >> Needless to say, KillFocus-validation also plays very poorly when GTK’s
> focus-follows-mouse is turned on.
> >>
> >> So I plan to do two things:
> >>
> >> 1) Remove automatic validation on KillFocus from UNIT_BINDER.  Clients
> which need validation will be modified to call Validate() themselves from
> their TransferDataFromWindow() methods.
>
> This way is known to work well across platforms.  Anything else and your
> at the mercy of platform specific event ordering and other UI toolkit
> quirks.
>
> >>
> >> 2) Remove UNIT_BINDER validation which isn’t needed.  We have a lot of
> validation which just checks for “reasonable” values.  However, our
> definition of “reasonable” doesn’t always match our users’ definitions.
> “Needed” validation (which will remain) is that which prevents un-supported
> situations, or that which makes recovery hard (for instance, PCB text with
> a zero width is hard to select).
> >>
> >> Any comments before I go ahead?
> >
> > Hi Jeff,
> >
> > John Beard had a good idea of replacing an error pop-up dialog with an
> > error indicator (red frame around text or red background for text input
> > widget). It will notify the user about potential problems without being
> > too disruptive, and such check might be done by KillFocus event handler.
>
> This would be more tolerable than a dialog but a red frame may not work
> well with all WM themes.
>
> >
> > I would still keep a pop-up dialog showing up if the user wants to
> > accept invalid settings (call Validate() in TransferDataFromWindow()).
> > If we want to provide ammo to shoot their feet, then 'Ignore' button
> > sounds like an appropriate caliber.
>
> You may want to tread carefully allowing users to accept invalid
> settings.  They may cause crashes or other unexpected behavior bugs.
>
> >
> > Cheers,
> > Orson
> >
> >
> > ___
> > 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
>


-- 
Mark
___
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] Dialog field validation on KillFocus

2018-11-29 Thread Wayne Stambaugh 
On 11/29/2018 8:47 AM, Maciej Sumiński wrote:
> On 11/29/18 2:36 PM, Jeff Young wrote:
>> While most UI guidelines suggest validating on field exit, it’s not without 
>> cost.  In particular, on GTK we can’t tell the difference between a 
>> KillFocus from clicking the OK button (when validation should be run) and a 
>> KillFocus from clicking Cancel (when it should not).  
>>
>> Needless to say, KillFocus-validation also plays very poorly when GTK’s 
>> focus-follows-mouse is turned on.
>>
>> So I plan to do two things:
>>
>> 1) Remove automatic validation on KillFocus from UNIT_BINDER.  Clients which 
>> need validation will be modified to call Validate() themselves from their 
>> TransferDataFromWindow() methods.

This way is known to work well across platforms.  Anything else and your
at the mercy of platform specific event ordering and other UI toolkit
quirks.

>>
>> 2) Remove UNIT_BINDER validation which isn’t needed.  We have a lot of 
>> validation which just checks for “reasonable” values.  However, our 
>> definition of “reasonable” doesn’t always match our users’ definitions.  
>> “Needed” validation (which will remain) is that which prevents un-supported 
>> situations, or that which makes recovery hard (for instance, PCB text with a 
>> zero width is hard to select).
>>
>> Any comments before I go ahead?
> 
> Hi Jeff,
> 
> John Beard had a good idea of replacing an error pop-up dialog with an
> error indicator (red frame around text or red background for text input
> widget). It will notify the user about potential problems without being
> too disruptive, and such check might be done by KillFocus event handler.

This would be more tolerable than a dialog but a red frame may not work
well with all WM themes.

> 
> I would still keep a pop-up dialog showing up if the user wants to
> accept invalid settings (call Validate() in TransferDataFromWindow()).
> If we want to provide ammo to shoot their feet, then 'Ignore' button
> sounds like an appropriate caliber.

You may want to tread carefully allowing users to accept invalid
settings.  They may cause crashes or other unexpected behavior bugs.

> 
> Cheers,
> Orson
> 
> 
> ___
> 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] Dialog field validation on KillFocus

2018-11-29 Thread Maciej Sumiński 
On 11/29/18 2:36 PM, Jeff Young wrote:
> While most UI guidelines suggest validating on field exit, it’s not without 
> cost.  In particular, on GTK we can’t tell the difference between a KillFocus 
> from clicking the OK button (when validation should be run) and a KillFocus 
> from clicking Cancel (when it should not).  
> 
> Needless to say, KillFocus-validation also plays very poorly when GTK’s 
> focus-follows-mouse is turned on.
> 
> So I plan to do two things:
> 
> 1) Remove automatic validation on KillFocus from UNIT_BINDER.  Clients which 
> need validation will be modified to call Validate() themselves from their 
> TransferDataFromWindow() methods.
> 
> 2) Remove UNIT_BINDER validation which isn’t needed.  We have a lot of 
> validation which just checks for “reasonable” values.  However, our 
> definition of “reasonable” doesn’t always match our users’ definitions.  
> “Needed” validation (which will remain) is that which prevents un-supported 
> situations, or that which makes recovery hard (for instance, PCB text with a 
> zero width is hard to select).
> 
> Any comments before I go ahead?

Hi Jeff,

John Beard had a good idea of replacing an error pop-up dialog with an
error indicator (red frame around text or red background for text input
widget). It will notify the user about potential problems without being
too disruptive, and such check might be done by KillFocus event handler.

I would still keep a pop-up dialog showing up if the user wants to
accept invalid settings (call Validate() in TransferDataFromWindow()).
If we want to provide ammo to shoot their feet, then 'Ignore' button
sounds like an appropriate caliber.

Cheers,
Orson



signature.asc
Description: OpenPGP digital signature
___
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] Dialog field validation on KillFocus

2018-11-29 Thread Jeff Young 
While most UI guidelines suggest validating on field exit, it’s not without 
cost.  In particular, on GTK we can’t tell the difference between a KillFocus 
from clicking the OK button (when validation should be run) and a KillFocus 
from clicking Cancel (when it should not).  

Needless to say, KillFocus-validation also plays very poorly when GTK’s 
focus-follows-mouse is turned on.

So I plan to do two things:

1) Remove automatic validation on KillFocus from UNIT_BINDER.  Clients which 
need validation will be modified to call Validate() themselves from their 
TransferDataFromWindow() methods.

2) Remove UNIT_BINDER validation which isn’t needed.  We have a lot of 
validation which just checks for “reasonable” values.  However, our definition 
of “reasonable” doesn’t always match our users’ definitions.  “Needed” 
validation (which will remain) is that which prevents un-supported situations, 
or that which makes recovery hard (for instance, PCB text with a zero width is 
hard to select).

Any comments before I go ahead?___
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] [PATCH] Docset generation

2018-11-29 Thread John Beard 
No attachment went though, so here's a better video:
https://sendvid.com/lrzgrdmf

Cheers,

John
On Wed, Nov 28, 2018 at 4:36 PM John Beard  wrote:
>
> Hi Wayne,
>
> It is not a replacement for the existing doxygen docs, which are
> unaffected by this patch.
>
> This patch merely allows you to generate the docset if you wish, it's
> not an ALL target. My intention here is to provide a way for CI
> systems to generate these docs and provide an continuously updating
> docset, in the same way that the doxygen is kept up-to-date.
>
> Zeal (available on Win, Linux and Mac, and the commercial Dash for Mac
> and I think other equivalents) allow the documentation to be available
> offline and much more quickly searchable, as well as providing editor
> integration (I know at least vim, emacs and sublime all have
> integrations).
>
> Attached is a very short video showing the current docsets, as hosted
> on github. To use them right now, add this XML feed to Zeal: [1].
> (Note: the -dirty suffix is due to the presence of this change on top
> of master while the docset is generated!)
>
> As for the python script, availability in pip mean it can be installed
> easily with virtualenv, so you don't have to (and, with a package
> manager, should not) install at a system level. It is packaged in the
> AUR on Arch for python2. Again, you don't need it if you do not intend
> to generate any docsets yourself. If you do not have it, the CMake
> target is not created, just like the current doxygen target.
>
> PSA: Regardless of KiCad, I would recommend Zeal to anyone solely for
> the C, C++, CMake and wxWidgets references.
>
> Cheers,
>
> John
>
> [1]: 
> https://raw.githubusercontent.com/johnbeard/kicad-docset/master/feeds/master/KiCad.xml
> On Wed, Nov 28, 2018 at 4:07 PM Wayne Stambaugh  wrote:
> >
> > Hey John,
> >
> > What exactly does this buy use over the regular doxygen docs?  I'm not
> > familiar with Zeal.  I don't have the tools installed on my machine to
> > verify this and I'm not a big fan of using pip on a system that uses a
> > package manager.  Is doxytag2zealdb packages for any distros?  I would
> > like a better picture of what this brings to the table and the
> > availability of any dependencies before I commit it.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 11/27/2018 12:28 PM, John Beard wrote:
> > > Hi,
> > >
> > > This is a patch to generate docsets using our existing doxygen set-up.
> > > Docset documentation makes it very easy to quickly browse the docs
> > > using Zeal and similar [1], which means you can get IDE integration
> > > and other nice things.
> > >
> > > The patch adds a "make docset" target. To actually build the docset,
> > > you will need doxytag2zealdb, a Python program available with pip.
> > >
> > > There is a strange extraneous endif() in the existing version Cmake as
> > > well, which I
> > > cannot explain why it currently works at all in its current form!
> > >
> > > The docset can be used to construct a docset feed using the CI
> > > infrastructure. Basically you need to host the TGZ somewhere and then
> > > provide an XML which changes the version and the link as needed. Zeal
> > > then picks up new version availability when checked.
> > >
> > > I have a hastily constructed feed available here [2]. This means you
> > > can start using a nightly-ish docset today, but updates are not done
> > > by a CI system. It should be as simple as adding this URL in Zeal [3].
> > >
> > > Cheers,
> > >
> > > John
> > >
> > > [1]: zealdocs.org
> > > [2]: https://github.com/johnbeard/kicad-docset
> > > [3]: 
> > > https://raw.githubusercontent.com/johnbeard/kicad-docset/master/feeds/master/KiCad.xml
> > >
> > >
> > > ___
> > > 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