Re: [Kicad-developers] 3D refactor

[Cirilo Bernardo]

Hi Simon,

For the scaling, some people do like to have independent scaling of XYZ.
One example I can think of are users who use a generic box to represent
most components and simply change the X,Y,Z scale to give a rough model
of each component.

Historically the orientation data was entered as Scale, Offset, Rotation;
I don't see a need to change that order so unless the chief devs believe
it would be an improvement to the UI, I wouldn't make such a change.

- Cirilo

On Wed, Mar 2, 2016 at 6:41 PM, Simon Wells  wrote:

> Hey Cirilo,
>
> The performance is much better for me now, and yeah touchpad scroll is
> zoom. Has anyone actually run into a situation where they need to
> scale differently in each axis? as it seems thats one setting that
> could be just made into a single scale amount.
>
> To avoid any confusion is it possible to put xyz on the RGB thing in
> the bottom left corner to avoid confusion as to offset and rotation
> axis?
>
> apart from that its looking good (and thanks for removing the sunken
> border) :)
>
>
>
> On Wed, Mar 2, 2016 at 3:51 PM, Cirilo Bernardo
>  wrote:
> > Thanks Wayne,
> >
> >  I had a look at the code and part of the problem seems to be that
> > the wxGLCanvas derived class wasn't calling event.Skip() on the
> > mouse buttons. I just added event.Skip() and the 3D frame now
> > gets the focus upon clicking. I decided against the ENTER_WINDOW
> > event since that could interfere with the GUI flow by stealing focus
> > when the user really doesn't want that to happen.
> >
> > - Cirilo
> >
> >
> > On Wed, Mar 2, 2016 at 11:15 AM, Wayne Stambaugh 
> > wrote:
> >>
> >> Take a look at the wxEVT_ENTER_WINDOW event.  You can set the canvas
> >> focus on this event.  This event should fire when the mouse enters the
> >> canvas so it should be handled there unless the parent frame window
> >> doesn't pass it down to the child canvas window.
> >>
> >> On 3/1/2016 5:24 PM, Cirilo Bernardo wrote:
> >> > Thanks Bernhard,
> >> >
> >> >  I found on MSWin after adding the SetFocus() as Mario suggested,
> >> > if I click somewhere else the wxGLCanvas loses focus again and
> >> > the rotate etc. no longer works until I use [tab] to set focus to the
> >> > window.
> >> >
> >> >  Are there any GUI experts out there who have some idea how we
> >> > can ensure that the wxGLCanvas frame has focus when the mouse
> >> > is above it?
> >> >
> >> > - Cirilo
> >> >
> >> >
> >> > On Wed, Mar 2, 2016 at 8:03 AM, Bernhard Stegmaier
> >> > > wrote:
> >> >
> >> > I’ll check zoom on OS X hopefully tomorrow.
> >> > I can tell that rotating the preview does work as expected.
> >> > And if I remember correctly, I did accidentally zoom once, but I
> >> > didn’t pay attention how I did it and if it was as it should be.
> >> >
> >> >> On 01 Mar 2016, at 21:52, Cirilo Bernardo
> >> >> >
> >> >> wrote:
> >> >>
> >> >> Thanks Mario,
> >> >>
> >> >>  I'll test that on MSWin soon; hopefully that works now.
> >> >>
> >> >> - Cirilo
> >> >>
> >> >> On Tue, Mar 1, 2016 at 9:03 PM, Mário Luzeiro  >> >> > wrote:
> >> >>
> >> >> > I'd also appreciate some help from anyone on the zoom
> >> >> function for the
> >> >> > 3D preview pane. The zoom works on Linux when using the
> mouse
> >> >> scroll
> >> >> > wheel but in MSWin I can only change the viewing angle, not
> >> >> the zoom. On
> >> >> > OSX I have no idea what the status is for zooming the
> model.
> >> >>
> >> >> Hi Cirilo,
> >> >>
> >> >> Looks like it was an old know wxWidgets issue, I fixed at:
> >> >>
> >> >>
> http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/revision/5897
> >> >>
> >> >> I found it here:
> >> >>
> >> >>
> https://github.com/KiCad/kicad-source-mirror/blob/a9427f899926155e48cab93187415710abc5438a/3d-viewer/3d_frame.cpp#L220
> >> >>
> >> >> In any case, in my windows laptop, the touchpad is not able
> to
> >> >> scrool.. but. I think it is some particularity of this
> >> >> windows/laptop...
> >> >> I tested with a mouse and it worked.
> >> >>
> >> >> Mario Luzeiro
> >> >>
> >> >>
> >> >> ___
> >> >> 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 

Re: [Kicad-developers] 3D refactor

[Simon Wells]

Hey Cirilo,

The performance is much better for me now, and yeah touchpad scroll is
zoom. Has anyone actually run into a situation where they need to
scale differently in each axis? as it seems thats one setting that
could be just made into a single scale amount.

To avoid any confusion is it possible to put xyz on the RGB thing in
the bottom left corner to avoid confusion as to offset and rotation
axis?

apart from that its looking good (and thanks for removing the sunken border) :)



On Wed, Mar 2, 2016 at 3:51 PM, Cirilo Bernardo
 wrote:
> Thanks Wayne,
>
>  I had a look at the code and part of the problem seems to be that
> the wxGLCanvas derived class wasn't calling event.Skip() on the
> mouse buttons. I just added event.Skip() and the 3D frame now
> gets the focus upon clicking. I decided against the ENTER_WINDOW
> event since that could interfere with the GUI flow by stealing focus
> when the user really doesn't want that to happen.
>
> - Cirilo
>
>
> On Wed, Mar 2, 2016 at 11:15 AM, Wayne Stambaugh 
> wrote:
>>
>> Take a look at the wxEVT_ENTER_WINDOW event.  You can set the canvas
>> focus on this event.  This event should fire when the mouse enters the
>> canvas so it should be handled there unless the parent frame window
>> doesn't pass it down to the child canvas window.
>>
>> On 3/1/2016 5:24 PM, Cirilo Bernardo wrote:
>> > Thanks Bernhard,
>> >
>> >  I found on MSWin after adding the SetFocus() as Mario suggested,
>> > if I click somewhere else the wxGLCanvas loses focus again and
>> > the rotate etc. no longer works until I use [tab] to set focus to the
>> > window.
>> >
>> >  Are there any GUI experts out there who have some idea how we
>> > can ensure that the wxGLCanvas frame has focus when the mouse
>> > is above it?
>> >
>> > - Cirilo
>> >
>> >
>> > On Wed, Mar 2, 2016 at 8:03 AM, Bernhard Stegmaier
>> > > wrote:
>> >
>> > I’ll check zoom on OS X hopefully tomorrow.
>> > I can tell that rotating the preview does work as expected.
>> > And if I remember correctly, I did accidentally zoom once, but I
>> > didn’t pay attention how I did it and if it was as it should be.
>> >
>> >> On 01 Mar 2016, at 21:52, Cirilo Bernardo
>> >> >
>> >> wrote:
>> >>
>> >> Thanks Mario,
>> >>
>> >>  I'll test that on MSWin soon; hopefully that works now.
>> >>
>> >> - Cirilo
>> >>
>> >> On Tue, Mar 1, 2016 at 9:03 PM, Mário Luzeiro > >> > wrote:
>> >>
>> >> > I'd also appreciate some help from anyone on the zoom
>> >> function for the
>> >> > 3D preview pane. The zoom works on Linux when using the mouse
>> >> scroll
>> >> > wheel but in MSWin I can only change the viewing angle, not
>> >> the zoom. On
>> >> > OSX I have no idea what the status is for zooming the model.
>> >>
>> >> Hi Cirilo,
>> >>
>> >> Looks like it was an old know wxWidgets issue, I fixed at:
>> >>
>> >> http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/revision/5897
>> >>
>> >> I found it here:
>> >>
>> >> https://github.com/KiCad/kicad-source-mirror/blob/a9427f899926155e48cab93187415710abc5438a/3d-viewer/3d_frame.cpp#L220
>> >>
>> >> In any case, in my windows laptop, the touchpad is not able to
>> >> scrool.. but. I think it is some particularity of this
>> >> windows/laptop...
>> >> I tested with a mouse and it worked.
>> >>
>> >> Mario Luzeiro
>> >>
>> >>
>> >> ___
>> >> 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] 3D refactor

[Cirilo Bernardo]

Thanks Wayne,

 I had a look at the code and part of the problem seems to be that
the wxGLCanvas derived class wasn't calling event.Skip() on the
mouse buttons. I just added event.Skip() and the 3D frame now
gets the focus upon clicking. I decided against the ENTER_WINDOW
event since that could interfere with the GUI flow by stealing focus
when the user really doesn't want that to happen.

- Cirilo


On Wed, Mar 2, 2016 at 11:15 AM, Wayne Stambaugh 
wrote:

> Take a look at the wxEVT_ENTER_WINDOW event.  You can set the canvas
> focus on this event.  This event should fire when the mouse enters the
> canvas so it should be handled there unless the parent frame window
> doesn't pass it down to the child canvas window.
>
> On 3/1/2016 5:24 PM, Cirilo Bernardo wrote:
> > Thanks Bernhard,
> >
> >  I found on MSWin after adding the SetFocus() as Mario suggested,
> > if I click somewhere else the wxGLCanvas loses focus again and
> > the rotate etc. no longer works until I use [tab] to set focus to the
> > window.
> >
> >  Are there any GUI experts out there who have some idea how we
> > can ensure that the wxGLCanvas frame has focus when the mouse
> > is above it?
> >
> > - Cirilo
> >
> >
> > On Wed, Mar 2, 2016 at 8:03 AM, Bernhard Stegmaier
> > > wrote:
> >
> > I’ll check zoom on OS X hopefully tomorrow.
> > I can tell that rotating the preview does work as expected.
> > And if I remember correctly, I did accidentally zoom once, but I
> > didn’t pay attention how I did it and if it was as it should be.
> >
> >> On 01 Mar 2016, at 21:52, Cirilo Bernardo
> >> >
> wrote:
> >>
> >> Thanks Mario,
> >>
> >>  I'll test that on MSWin soon; hopefully that works now.
> >>
> >> - Cirilo
> >>
> >> On Tue, Mar 1, 2016 at 9:03 PM, Mário Luzeiro  >> > wrote:
> >>
> >> > I'd also appreciate some help from anyone on the zoom
> function for the
> >> > 3D preview pane. The zoom works on Linux when using the mouse
> scroll
> >> > wheel but in MSWin I can only change the viewing angle, not
> the zoom. On
> >> > OSX I have no idea what the status is for zooming the model.
> >>
> >> Hi Cirilo,
> >>
> >> Looks like it was an old know wxWidgets issue, I fixed at:
> >>
> http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/revision/5897
> >>
> >> I found it here:
> >>
> https://github.com/KiCad/kicad-source-mirror/blob/a9427f899926155e48cab93187415710abc5438a/3d-viewer/3d_frame.cpp#L220
> >>
> >> In any case, in my windows laptop, the touchpad is not able to
> >> scrool.. but. I think it is some particularity of this
> >> windows/laptop...
> >> I tested with a mouse and it worked.
> >>
> >> Mario Luzeiro
> >>
> >>
> >> ___
> >> 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] Pcbnew delete hot key behavior.

[Sergey Borshch]

On 01.03.2016 15:23, Wayne Stambaugh wrote:

I was under the impression
that the user was trying to delete a trace and a nearby footprint was
deleted rather than the trace.  That shouldn't happen without a
disambiguation menu.
So you'll get annoying menu every time you want to delete wire under 
footprint in wire placement mode. I propose to add some intelligence:
let's current selected tool take precedence in selection. For example, 
in wire placement mode if user press del key while pointing mouse cursor 
to the wire under footprint, wire can be deleted without menu. If there 
is only footprint under cursor - it can be deleted without menu. If 
there more than one wire or more than one non-wire items (footprints or 
footprint and drawing line or line and filled zone) under cursor - menu 
appears. If there is more than one wire and another non-wire item(s) 
under cursor - menu appears, but only wires shown.


--
Regards,
   Sergey A. Borshchmailto: sb...@users.sourceforge.net
 SB ELDI ltd. Riga, Latvia

___
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] 3D refactor

[Simon Wells]

i could use touchpad scroll (which was zoom i think the performance
was so terrible that i am unsure whether it was pinch or scroll)  in
the preview window

But yeah the performance is worse for me than cairo

On Wed, Mar 2, 2016 at 1:15 PM, Wayne Stambaugh  wrote:
> Take a look at the wxEVT_ENTER_WINDOW event.  You can set the canvas
> focus on this event.  This event should fire when the mouse enters the
> canvas so it should be handled there unless the parent frame window
> doesn't pass it down to the child canvas window.
>
> On 3/1/2016 5:24 PM, Cirilo Bernardo wrote:
>> Thanks Bernhard,
>>
>>  I found on MSWin after adding the SetFocus() as Mario suggested,
>> if I click somewhere else the wxGLCanvas loses focus again and
>> the rotate etc. no longer works until I use [tab] to set focus to the
>> window.
>>
>>  Are there any GUI experts out there who have some idea how we
>> can ensure that the wxGLCanvas frame has focus when the mouse
>> is above it?
>>
>> - Cirilo
>>
>>
>> On Wed, Mar 2, 2016 at 8:03 AM, Bernhard Stegmaier
>> > wrote:
>>
>> I’ll check zoom on OS X hopefully tomorrow.
>> I can tell that rotating the preview does work as expected.
>> And if I remember correctly, I did accidentally zoom once, but I
>> didn’t pay attention how I did it and if it was as it should be.
>>
>>> On 01 Mar 2016, at 21:52, Cirilo Bernardo
>>> > wrote:
>>>
>>> Thanks Mario,
>>>
>>>  I'll test that on MSWin soon; hopefully that works now.
>>>
>>> - Cirilo
>>>
>>> On Tue, Mar 1, 2016 at 9:03 PM, Mário Luzeiro >> > wrote:
>>>
>>> > I'd also appreciate some help from anyone on the zoom function 
>>> for the
>>> > 3D preview pane. The zoom works on Linux when using the mouse 
>>> scroll
>>> > wheel but in MSWin I can only change the viewing angle, not the 
>>> zoom. On
>>> > OSX I have no idea what the status is for zooming the model.
>>>
>>> Hi Cirilo,
>>>
>>> Looks like it was an old know wxWidgets issue, I fixed at:
>>> 
>>> http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/revision/5897
>>>
>>> I found it here:
>>> 
>>> https://github.com/KiCad/kicad-source-mirror/blob/a9427f899926155e48cab93187415710abc5438a/3d-viewer/3d_frame.cpp#L220
>>>
>>> In any case, in my windows laptop, the touchpad is not able to
>>> scrool.. but. I think it is some particularity of this
>>> windows/laptop...
>>> I tested with a mouse and it worked.
>>>
>>> Mario Luzeiro
>>>
>>>
>>> ___
>>> 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] PATCH: Unify mirror and copy block functions between schematic editor and library aditor

[Wayne Stambaugh]

No problem.  I hold of until you submit the patch with the rotate issue
resolved.

Thanks,

Wayne

On 3/1/2016 11:25 AM, Mikael Arguedas wrote:
> Hi,
> 
> Sorry about that, I'll update the patch to comply to the coding policy.
> I'm currently investigating the rotate block function. It seems to be
> working only is the selection rectangle lands on a pin location but
> doesn't work otherwise. I'm trying to figure out why this appears only
> for the rotate block function and not the others.
> 
> Thanks for reviewing it.
> 
> Cheers,
> Mikael
> 
> On Tue, Mar 1, 2016 at 6:56 AM, Wayne Stambaugh  > wrote:
> 
> Mikael,
> 
> I just tested your patches and they do unify the block mirror behavior
> but the rotate hot key (R) does not rotate a block in component library
> editor.  I would prefer that you fix that before I commit your patches.
>  Also, you have some copy policy violations (trailing white space, curly
> bracket placement, and missing spaces between text and braces) in your
> patch.  Since it's your first patch, I will cut you some slack but in
> the future please submit patches that to adhere to the coding policy[1].
> 
> Cheers,
> 
> Wayne
> 
> [1]:
> 
> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_coding-style-policy.html
> 
> On 2/24/2016 12:43 PM, Mikael Arguedas wrote:
> > Hi guys,
> >
> > Here are two patches:
> > unifyCopyBlock.patch: makes the CopyBlock function in library editor
> > match the behaviour of the one in schematic editor
> > addMirrorHotkeys.patch:
> > - adds the HkMirrorX and HkMirrorY hotkeys to library editor
> > - allor the HkRotate hotkey to rotate blocks and not only items
> >
> > Regards,
> > Mikael
> >
> >
> > ___
> > 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] 3D refactor

[Wayne Stambaugh]

Take a look at the wxEVT_ENTER_WINDOW event.  You can set the canvas
focus on this event.  This event should fire when the mouse enters the
canvas so it should be handled there unless the parent frame window
doesn't pass it down to the child canvas window.

On 3/1/2016 5:24 PM, Cirilo Bernardo wrote:
> Thanks Bernhard,
> 
>  I found on MSWin after adding the SetFocus() as Mario suggested,
> if I click somewhere else the wxGLCanvas loses focus again and
> the rotate etc. no longer works until I use [tab] to set focus to the
> window.
> 
>  Are there any GUI experts out there who have some idea how we
> can ensure that the wxGLCanvas frame has focus when the mouse
> is above it?
> 
> - Cirilo
> 
> 
> On Wed, Mar 2, 2016 at 8:03 AM, Bernhard Stegmaier
> > wrote:
> 
> I’ll check zoom on OS X hopefully tomorrow.
> I can tell that rotating the preview does work as expected.
> And if I remember correctly, I did accidentally zoom once, but I
> didn’t pay attention how I did it and if it was as it should be.
> 
>> On 01 Mar 2016, at 21:52, Cirilo Bernardo
>> > wrote:
>>
>> Thanks Mario,
>>
>>  I'll test that on MSWin soon; hopefully that works now.
>>
>> - Cirilo
>>
>> On Tue, Mar 1, 2016 at 9:03 PM, Mário Luzeiro > > wrote:
>>
>> > I'd also appreciate some help from anyone on the zoom function for 
>> the
>> > 3D preview pane. The zoom works on Linux when using the mouse 
>> scroll
>> > wheel but in MSWin I can only change the viewing angle, not the 
>> zoom. On
>> > OSX I have no idea what the status is for zooming the model.
>>
>> Hi Cirilo,
>>
>> Looks like it was an old know wxWidgets issue, I fixed at:
>> 
>> http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/revision/5897
>>
>> I found it here:
>> 
>> https://github.com/KiCad/kicad-source-mirror/blob/a9427f899926155e48cab93187415710abc5438a/3d-viewer/3d_frame.cpp#L220
>>
>> In any case, in my windows laptop, the touchpad is not able to
>> scrool.. but. I think it is some particularity of this
>> windows/laptop...
>> I tested with a mouse and it worked.
>>
>> Mario Luzeiro
>>
>>
>> ___
>> 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] 3D refactor

[Cirilo Bernardo]

Thanks Bernhard,

 I found on MSWin after adding the SetFocus() as Mario suggested,
if I click somewhere else the wxGLCanvas loses focus again and
the rotate etc. no longer works until I use [tab] to set focus to the
window.

 Are there any GUI experts out there who have some idea how we
can ensure that the wxGLCanvas frame has focus when the mouse
is above it?

- Cirilo


On Wed, Mar 2, 2016 at 8:03 AM, Bernhard Stegmaier 
wrote:

> I’ll check zoom on OS X hopefully tomorrow.
> I can tell that rotating the preview does work as expected.
> And if I remember correctly, I did accidentally zoom once, but I didn’t
> pay attention how I did it and if it was as it should be.
>
> On 01 Mar 2016, at 21:52, Cirilo Bernardo 
> wrote:
>
> Thanks Mario,
>
>  I'll test that on MSWin soon; hopefully that works now.
>
> - Cirilo
>
> On Tue, Mar 1, 2016 at 9:03 PM, Mário Luzeiro  wrote:
>
>> > I'd also appreciate some help from anyone on the zoom function for the
>> > 3D preview pane. The zoom works on Linux when using the mouse scroll
>> > wheel but in MSWin I can only change the viewing angle, not the zoom. On
>> > OSX I have no idea what the status is for zooming the model.
>>
>> Hi Cirilo,
>>
>> Looks like it was an old know wxWidgets issue, I fixed at:
>>
>> http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/revision/5897
>>
>> I found it here:
>>
>> https://github.com/KiCad/kicad-source-mirror/blob/a9427f899926155e48cab93187415710abc5438a/3d-viewer/3d_frame.cpp#L220
>>
>> In any case, in my windows laptop, the touchpad is not able to scrool..
>> but. I think it is some particularity of this windows/laptop...
>> I tested with a mouse and it worked.
>>
>> Mario Luzeiro
>
>
> ___
> 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] Legacy Canvas Mousewheel Behavior?

[Bernhard Stegmaier]

> On 01 Mar 2016, at 22:20, Wayne Stambaugh  wrote:
> 
> Even without touchpad panning enabled, on windows it works exactly how I
> would expect it to.  I can do both horizontal and vertical 2 finger
> scrolling with the touchpad.  
Good.

> When I enable touchpad panning, the mouse
> wheel becomes vertical scroll instead of zoom irregardless of the shift
> or control key state.  Vertical and horizontal touchpad scrolling still
Yes, that’s how it supposed to be.

Wheel normally has axis=vertical, so it scrolls vertical.
With a touchpad and 2-finger scroll you just want it to scroll without having
to press any modifier key. That’s why it doesn’t zoom but scroll without
modifier.

> work the same way but now there is no mouse wheel zoom.  This is the
Yes, that’s how it is currently implemented.

If you really want zoom again on wheel/touchpad, I could add to zoom with
ctrl modifier. Shouldn’t be a big deal.
I wouldn’t want to use shift, because you need shift-wheel to simulate 
horizontal scroll with a usual mouse in touchpad mode - if it wouldn’t be like 
that you would have to switch modes whenever you change devices.
Ah, wait… the shift-wheel probably only works on OS X because of the
previously discussed automatic change of axis (which obviously doesn’t
happen on Windows/Linux).

On OS X you don’t need modifier-touch/wheel for zooming, because you 
zoom with pinch-to-zoom gesture (which is unfortunately not yet supported 
by wxWidgets on Windows/Linux).

> case for all of the legacy canvases except the 3D viewer which behaves
> as I previously described.  I don't see any setting to enable/disable
That’s good, then touchpad-panning is working as it is supposed to be.

> the touchpad panning in the 3D viewer.
3D viewer doesn’t have a preference dialog, so I added this as first item
in the Preferences menu…


Regards,
Bernhard


___
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] Legacy Canvas Mousewheel Behavior?

[Wayne Stambaugh]

Even without touchpad panning enabled, on windows it works exactly how I
would expect it to.  I can do both horizontal and vertical 2 finger
scrolling with the touchpad.  When I enable touchpad panning, the mouse
wheel becomes vertical scroll instead of zoom irregardless of the shift
or control key state.  Vertical and horizontal touchpad scrolling still
work the same way but now there is no mouse wheel zoom.  This is the
case for all of the legacy canvases except the 3D viewer which behaves
as I previously described.  I don't see any setting to enable/disable
the touchpad panning in the 3D viewer.

On 3/1/2016 3:42 PM, Bernhard Stegmaier wrote:
> Thanks, I’ll check 3D viewer.
> 
> Do you mean touchpad scrolling with non-touchpad panning mode?
> Are you sure you are getting mouse wheel events when horizontal scrolling?
> I don’t see any checks in 3D viewer wrt axis (in non-touchpad mode), so it 
> should 
> treat horizontal/vertical events just the same… if there are any.
> 
>> On 01 Mar 2016, at 21:20, Wayne Stambaugh  wrote:
>>
>> This patch doesn't seem to break anything on windows.  However, I
>> noticed that the touchpad scroll behavior is wrong in the 3D viewer.
>> The touchpad horizontal scroll does nothing and the touchpad vertical
>> scroll zooms.  We should probably fix this as well.  I commit this patch
>> as is r6606.  Thanks.
>>
>> On 3/1/2016 2:13 PM, Bernhard Stegmaier wrote:
>>> It was the one you responded with
>>> <<<
>>> I believe the axis is for mice with multiple wheels where the 0 axis is
>>> the scroll wheel typically used for vertical scrolling. ...
>>
>>>
>>> I did forget to mark it as [PATCH] in the title.
>>> Sorry, my fault.
>>>
>>> For your convenience, again attached to this mail.
>>>
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
 On 01 Mar 2016, at 20:05, Wayne Stambaugh  wrote:

 What patch?  Did I miss an email in this thread at some point?

 On 3/1/2016 1:42 PM, Bernhard Stegmaier wrote:
> With my patch it should behave the same way on all platforms.
> It just does ignore axis then…
>
> GAL does things already differently and apparently it is fine on 
> Windows/Linux 
> and Mac with that code.
> So, just using my patch should be the easiest way to get things 
> consistent again
> on all platforms for now.
>
>> On 01.03.2016, at 19:35, Wayne Stambaugh  wrote:
>>
>> On 3/1/2016 1:25 PM, Bernhard Stegmaier wrote:
>>> I did that for a PC mouse with my Mac.
>>> As I said in the beginning… Whoever does this, I get axis 0 when 
>>> nothing 
>>> is pressed, and axis 1 when shift is pressed (using the same mouse, the 
>>> same mousewheel, no touchpad).
>>> That’s why it only did scroll horizontal with the original code 
>>> (obviously only 
>>> on OS X).
>>
>> It sounds like this is not what is happen on linux.  We may have to
>> normalize the axis/shift key behavior to account for platform 
>> differences.
>>
>>>
>>> Of course, the axis is for things like touchpads and that’s exactly 
>>> what gets 
>>> used in touchpad-panning mode.
>>> That’s exactly what is the really nice thing about the automatic axis 
>>> change:
>>> With touchpad-panning the same piece of code works with a touchpad and
>>> a normal mouse.
>>> Unmodifed wheel scrolls up/down, shift-wheel scrolls left/right.
>>> Kicad doesn’t have to know anything about which device is there, it just
>>> works… :)
>>>
>>>
 On 01.03.2016, at 19:15, Wayne Stambaugh  wrote:

 I believe the axis is for mice with multiple wheels where the 0 axis is
 the scroll wheel typically used for vertical scrolling.  I do not
 believe the shift or control keys have anything to do with the axis in
 the wxMouseEvent but I have looked at the wxWidget code to see if that
 is the case.  Perhaps there are some inconsistencies between platform 
 as
 to what these axis mean.  The easiest way to find this out is to trace
 the mouse events and see which axis is being sent in the wxMouseEvent
 inside the OnScroll function.

 On 3/1/2016 12:44 PM, Bernhard Stegmaier wrote:
> Yes, but documentation doesn’t state anything about changing axis 
> with 
> shift/ctrl (at least, I didn’t see it).
>
> If the non-touchpad scroll code shall ignore ignore any additional 
> axis, 
> then the current implementation is wrong (it doesn’t ignore axis).
>
> Attached a patch to ignore axis in non-touchpad scroll code (as it 
> was 
> before rev4505).
> Therewith, also shift/ctrl panning again works on OS X (though it 
> might not
> conform to Apple UI guidelines where shift-wheel does a 

Re: [Kicad-developers] 3D refactor

[Bernhard Stegmaier]

I’ll check zoom on OS X hopefully tomorrow.
I can tell that rotating the preview does work as expected.
And if I remember correctly, I did accidentally zoom once, but I didn’t pay 
attention how I did it and if it was as it should be.

> On 01 Mar 2016, at 21:52, Cirilo Bernardo  wrote:
> 
> Thanks Mario,
> 
>  I'll test that on MSWin soon; hopefully that works now.
> 
> - Cirilo
> 
> On Tue, Mar 1, 2016 at 9:03 PM, Mário Luzeiro  > wrote:
> > I'd also appreciate some help from anyone on the zoom function for the
> > 3D preview pane. The zoom works on Linux when using the mouse scroll
> > wheel but in MSWin I can only change the viewing angle, not the zoom. On
> > OSX I have no idea what the status is for zooming the model.
> 
> Hi Cirilo,
> 
> Looks like it was an old know wxWidgets issue, I fixed at:
> http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/revision/5897 
> 
> 
> I found it here:
> https://github.com/KiCad/kicad-source-mirror/blob/a9427f899926155e48cab93187415710abc5438a/3d-viewer/3d_frame.cpp#L220
>  
> 
> 
> In any case, in my windows laptop, the touchpad is not able to scrool.. but. 
> I think it is some particularity of this windows/laptop...
> I tested with a mouse and it worked.
> 
> Mario Luzeiro
> 
> ___
> 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] [RFC] Intra-sheet links and dangling ERC checks

[Nick Østergaard]

2016-02-29 19:48 GMT+01:00 Daniel Silverstone :
> On Mon, Feb 29, 2016 at 17:09:53 +, Kaspar Emanuel wrote:
>> I read through your blog post, I will build your fork and test it out if I
>> get a chance.
>
> Wonderful.
>
>> The extra ERC option seems useful indeed. I am a bit confused about the
>> intra-sheet link feature though, is this different from global labels?
>
> The intra-sheet link elements exist *purely* for ERC reasons, to communicate
> the explicit intent of the engineer to have a net linked elsewhere on the
> *same* sheet.

Thank you for the write up, I now better understan what exactly you
mean, although I would like so understand the use cases in combination
with the other label types. Like what happens for a global label
situation? Are the two sheets now considered the same sheet or?

> Global labels and heirarchical labels remain exactly as they were.  The idea 
> is
> only to ensure that the schematic capture engineer be a little more explicit
> about what currently could be a deliberately dangling wire (because they meant
> to link it elsewhere on the same sheet by way of labels) or a mistake which 
> the
> engineer or reviewer failed to catch.
>
> D.
>
>> P.S. Might I suggest a different favicon for your blog? The current one
>> isn't very welcoming.
>
> Aah yes, that's what my husband drew for me when I asked him to do a favicon
> which represented Git.  I'll change it over to something less rude :-)
>
> --
> Daniel Silverstone http://www.digital-scurf.org/
> PGP mail accepted and encouraged.Key Id: 3CCE BABE 206C 3B69
>
> ___
> 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] 3D refactor

[Cirilo Bernardo]

Thanks Mario,

 I'll test that on MSWin soon; hopefully that works now.

- Cirilo

On Tue, Mar 1, 2016 at 9:03 PM, Mário Luzeiro  wrote:

> > I'd also appreciate some help from anyone on the zoom function for the
> > 3D preview pane. The zoom works on Linux when using the mouse scroll
> > wheel but in MSWin I can only change the viewing angle, not the zoom. On
> > OSX I have no idea what the status is for zooming the model.
>
> Hi Cirilo,
>
> Looks like it was an old know wxWidgets issue, I fixed at:
>
> http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/revision/5897
>
> I found it here:
>
> https://github.com/KiCad/kicad-source-mirror/blob/a9427f899926155e48cab93187415710abc5438a/3d-viewer/3d_frame.cpp#L220
>
> In any case, in my windows laptop, the touchpad is not able to scrool..
> but. I think it is some particularity of this windows/laptop...
> I tested with a mouse and it worked.
>
> Mario Luzeiro
___
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] Legacy Canvas Mousewheel Behavior?

[Bernhard Stegmaier]

Thanks, I’ll check 3D viewer.

Do you mean touchpad scrolling with non-touchpad panning mode?
Are you sure you are getting mouse wheel events when horizontal scrolling?
I don’t see any checks in 3D viewer wrt axis (in non-touchpad mode), so it 
should 
treat horizontal/vertical events just the same… if there are any.

> On 01 Mar 2016, at 21:20, Wayne Stambaugh  wrote:
> 
> This patch doesn't seem to break anything on windows.  However, I
> noticed that the touchpad scroll behavior is wrong in the 3D viewer.
> The touchpad horizontal scroll does nothing and the touchpad vertical
> scroll zooms.  We should probably fix this as well.  I commit this patch
> as is r6606.  Thanks.
> 
> On 3/1/2016 2:13 PM, Bernhard Stegmaier wrote:
>> It was the one you responded with
>> <<<
>> I believe the axis is for mice with multiple wheels where the 0 axis is
>> the scroll wheel typically used for vertical scrolling. ...
> 
>> 
>> I did forget to mark it as [PATCH] in the title.
>> Sorry, my fault.
>> 
>> For your convenience, again attached to this mail.
>> 
>> 
>> 
>> 
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 01 Mar 2016, at 20:05, Wayne Stambaugh  wrote:
>>> 
>>> What patch?  Did I miss an email in this thread at some point?
>>> 
>>> On 3/1/2016 1:42 PM, Bernhard Stegmaier wrote:
 With my patch it should behave the same way on all platforms.
 It just does ignore axis then…
 
 GAL does things already differently and apparently it is fine on 
 Windows/Linux 
 and Mac with that code.
 So, just using my patch should be the easiest way to get things consistent 
 again
 on all platforms for now.
 
> On 01.03.2016, at 19:35, Wayne Stambaugh  wrote:
> 
> On 3/1/2016 1:25 PM, Bernhard Stegmaier wrote:
>> I did that for a PC mouse with my Mac.
>> As I said in the beginning… Whoever does this, I get axis 0 when nothing 
>> is pressed, and axis 1 when shift is pressed (using the same mouse, the 
>> same mousewheel, no touchpad).
>> That’s why it only did scroll horizontal with the original code 
>> (obviously only 
>> on OS X).
> 
> It sounds like this is not what is happen on linux.  We may have to
> normalize the axis/shift key behavior to account for platform differences.
> 
>> 
>> Of course, the axis is for things like touchpads and that’s exactly what 
>> gets 
>> used in touchpad-panning mode.
>> That’s exactly what is the really nice thing about the automatic axis 
>> change:
>> With touchpad-panning the same piece of code works with a touchpad and
>> a normal mouse.
>> Unmodifed wheel scrolls up/down, shift-wheel scrolls left/right.
>> Kicad doesn’t have to know anything about which device is there, it just
>> works… :)
>> 
>> 
>>> On 01.03.2016, at 19:15, Wayne Stambaugh  wrote:
>>> 
>>> I believe the axis is for mice with multiple wheels where the 0 axis is
>>> the scroll wheel typically used for vertical scrolling.  I do not
>>> believe the shift or control keys have anything to do with the axis in
>>> the wxMouseEvent but I have looked at the wxWidget code to see if that
>>> is the case.  Perhaps there are some inconsistencies between platform as
>>> to what these axis mean.  The easiest way to find this out is to trace
>>> the mouse events and see which axis is being sent in the wxMouseEvent
>>> inside the OnScroll function.
>>> 
>>> On 3/1/2016 12:44 PM, Bernhard Stegmaier wrote:
 Yes, but documentation doesn’t state anything about changing axis with 
 shift/ctrl (at least, I didn’t see it).
 
 If the non-touchpad scroll code shall ignore ignore any additional 
 axis, 
 then the current implementation is wrong (it doesn’t ignore axis).
 
 Attached a patch to ignore axis in non-touchpad scroll code (as it was 
 before rev4505).
 Therewith, also shift/ctrl panning again works on OS X (though it 
 might not
 conform to Apple UI guidelines where shift-wheel does a horizontal 
 scroll).
 
 
 Regards,
 Bernhard
 
 
 
 
 PS:
 Mac users using a PC mouse and a Apple mouse in parallel might notice
 that the
 scroll direction of PC mouse is just the other way round than for Mac
 mouse (and
 maybe touchpad).
 Yes. I don’t want to investigate if I can find out which device is
 connected, so it
 is as it is. Don’t use a PC mouse on a Mac… :) 
 
> On 29.02.2016, at 01:24, Wayne Stambaugh  > wrote:
> 
> Take a look at the documentation for wxMouseEvent.GetWheelAxis()[1].
> Some mice and/or trackpads can generate 

Re: [Kicad-developers] Legacy Canvas Mousewheel Behavior?

[Wayne Stambaugh]

This patch doesn't seem to break anything on windows.  However, I
noticed that the touchpad scroll behavior is wrong in the 3D viewer.
The touchpad horizontal scroll does nothing and the touchpad vertical
scroll zooms.  We should probably fix this as well.  I commit this patch
as is r6606.  Thanks.

On 3/1/2016 2:13 PM, Bernhard Stegmaier wrote:
> It was the one you responded with
> <<<
> I believe the axis is for mice with multiple wheels where the 0 axis is
> the scroll wheel typically used for vertical scrolling. ...

> 
> I did forget to mark it as [PATCH] in the title.
> Sorry, my fault.
> 
> For your convenience, again attached to this mail.
> 
> 
> 
> 
> 
> 
> Regards,
> Bernhard
> 
>> On 01 Mar 2016, at 20:05, Wayne Stambaugh  wrote:
>>
>> What patch?  Did I miss an email in this thread at some point?
>>
>> On 3/1/2016 1:42 PM, Bernhard Stegmaier wrote:
>>> With my patch it should behave the same way on all platforms.
>>> It just does ignore axis then…
>>>
>>> GAL does things already differently and apparently it is fine on 
>>> Windows/Linux 
>>> and Mac with that code.
>>> So, just using my patch should be the easiest way to get things consistent 
>>> again
>>> on all platforms for now.
>>>
 On 01.03.2016, at 19:35, Wayne Stambaugh  wrote:

 On 3/1/2016 1:25 PM, Bernhard Stegmaier wrote:
> I did that for a PC mouse with my Mac.
> As I said in the beginning… Whoever does this, I get axis 0 when nothing 
> is pressed, and axis 1 when shift is pressed (using the same mouse, the 
> same mousewheel, no touchpad).
> That’s why it only did scroll horizontal with the original code 
> (obviously only 
> on OS X).

 It sounds like this is not what is happen on linux.  We may have to
 normalize the axis/shift key behavior to account for platform differences.

>
> Of course, the axis is for things like touchpads and that’s exactly what 
> gets 
> used in touchpad-panning mode.
> That’s exactly what is the really nice thing about the automatic axis 
> change:
> With touchpad-panning the same piece of code works with a touchpad and
> a normal mouse.
> Unmodifed wheel scrolls up/down, shift-wheel scrolls left/right.
> Kicad doesn’t have to know anything about which device is there, it just
> works… :)
>
>
>> On 01.03.2016, at 19:15, Wayne Stambaugh  wrote:
>>
>> I believe the axis is for mice with multiple wheels where the 0 axis is
>> the scroll wheel typically used for vertical scrolling.  I do not
>> believe the shift or control keys have anything to do with the axis in
>> the wxMouseEvent but I have looked at the wxWidget code to see if that
>> is the case.  Perhaps there are some inconsistencies between platform as
>> to what these axis mean.  The easiest way to find this out is to trace
>> the mouse events and see which axis is being sent in the wxMouseEvent
>> inside the OnScroll function.
>>
>> On 3/1/2016 12:44 PM, Bernhard Stegmaier wrote:
>>> Yes, but documentation doesn’t state anything about changing axis with 
>>> shift/ctrl (at least, I didn’t see it).
>>>
>>> If the non-touchpad scroll code shall ignore ignore any additional 
>>> axis, 
>>> then the current implementation is wrong (it doesn’t ignore axis).
>>>
>>> Attached a patch to ignore axis in non-touchpad scroll code (as it was 
>>> before rev4505).
>>> Therewith, also shift/ctrl panning again works on OS X (though it might 
>>> not
>>> conform to Apple UI guidelines where shift-wheel does a horizontal 
>>> scroll).
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>>
>>>
>>>
>>> PS:
>>> Mac users using a PC mouse and a Apple mouse in parallel might notice
>>> that the
>>> scroll direction of PC mouse is just the other way round than for Mac
>>> mouse (and
>>> maybe touchpad).
>>> Yes. I don’t want to investigate if I can find out which device is
>>> connected, so it
>>> is as it is. Don’t use a PC mouse on a Mac… :) 
>>>
 On 29.02.2016, at 01:24, Wayne Stambaugh > wrote:

 Take a look at the documentation for wxMouseEvent.GetWheelAxis()[1].
 Some mice and/or trackpads can generate additional axis for horizontal
 scroll support.  That's why the scroll code ignores any additional 
 axis.
 Prior to 2.94, GetWheelAxis() returned an int where 0 was the vertical
 scroll.  Now GetWheelAxis() returns wxMOUSE_WHEEL_VERTICAL and
 wxMOUSE_WHEEL_HORIZONTAL which are enums.  I didn't look but I'm
 assuming they map to 0 and 1 but it would be more correct to use the
 enums rather than 0.

 [1]:
 

Re: [Kicad-developers] Legacy Canvas Mousewheel Behavior?

[Bernhard Stegmaier]

It was the one you responded with
<<<
I believe the axis is for mice with multiple wheels where the 0 axis is
the scroll wheel typically used for vertical scrolling. ...
>>>

I did forget to mark it as [PATCH] in the title.
Sorry, my fault.

For your convenience, again attached to this mail.


wheel-pan.patch
Description: Binary data



Regards,
Bernhard

> On 01 Mar 2016, at 20:05, Wayne Stambaugh  wrote:
> 
> What patch?  Did I miss an email in this thread at some point?
> 
> On 3/1/2016 1:42 PM, Bernhard Stegmaier wrote:
>> With my patch it should behave the same way on all platforms.
>> It just does ignore axis then…
>> 
>> GAL does things already differently and apparently it is fine on 
>> Windows/Linux 
>> and Mac with that code.
>> So, just using my patch should be the easiest way to get things consistent 
>> again
>> on all platforms for now.
>> 
>>> On 01.03.2016, at 19:35, Wayne Stambaugh  wrote:
>>> 
>>> On 3/1/2016 1:25 PM, Bernhard Stegmaier wrote:
 I did that for a PC mouse with my Mac.
 As I said in the beginning… Whoever does this, I get axis 0 when nothing 
 is pressed, and axis 1 when shift is pressed (using the same mouse, the 
 same mousewheel, no touchpad).
 That’s why it only did scroll horizontal with the original code (obviously 
 only 
 on OS X).
>>> 
>>> It sounds like this is not what is happen on linux.  We may have to
>>> normalize the axis/shift key behavior to account for platform differences.
>>> 
 
 Of course, the axis is for things like touchpads and that’s exactly what 
 gets 
 used in touchpad-panning mode.
 That’s exactly what is the really nice thing about the automatic axis 
 change:
 With touchpad-panning the same piece of code works with a touchpad and
 a normal mouse.
 Unmodifed wheel scrolls up/down, shift-wheel scrolls left/right.
 Kicad doesn’t have to know anything about which device is there, it just
 works… :)
 
 
> On 01.03.2016, at 19:15, Wayne Stambaugh  wrote:
> 
> I believe the axis is for mice with multiple wheels where the 0 axis is
> the scroll wheel typically used for vertical scrolling.  I do not
> believe the shift or control keys have anything to do with the axis in
> the wxMouseEvent but I have looked at the wxWidget code to see if that
> is the case.  Perhaps there are some inconsistencies between platform as
> to what these axis mean.  The easiest way to find this out is to trace
> the mouse events and see which axis is being sent in the wxMouseEvent
> inside the OnScroll function.
> 
> On 3/1/2016 12:44 PM, Bernhard Stegmaier wrote:
>> Yes, but documentation doesn’t state anything about changing axis with 
>> shift/ctrl (at least, I didn’t see it).
>> 
>> If the non-touchpad scroll code shall ignore ignore any additional axis, 
>> then the current implementation is wrong (it doesn’t ignore axis).
>> 
>> Attached a patch to ignore axis in non-touchpad scroll code (as it was 
>> before rev4505).
>> Therewith, also shift/ctrl panning again works on OS X (though it might 
>> not
>> conform to Apple UI guidelines where shift-wheel does a horizontal 
>> scroll).
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> 
>> 
>> 
>> PS:
>> Mac users using a PC mouse and a Apple mouse in parallel might notice
>> that the
>> scroll direction of PC mouse is just the other way round than for Mac
>> mouse (and
>> maybe touchpad).
>> Yes. I don’t want to investigate if I can find out which device is
>> connected, so it
>> is as it is. Don’t use a PC mouse on a Mac… :) 
>> 
>>> On 29.02.2016, at 01:24, Wayne Stambaugh >> > wrote:
>>> 
>>> Take a look at the documentation for wxMouseEvent.GetWheelAxis()[1].
>>> Some mice and/or trackpads can generate additional axis for horizontal
>>> scroll support.  That's why the scroll code ignores any additional axis.
>>> Prior to 2.94, GetWheelAxis() returned an int where 0 was the vertical
>>> scroll.  Now GetWheelAxis() returns wxMOUSE_WHEEL_VERTICAL and
>>> wxMOUSE_WHEEL_HORIZONTAL which are enums.  I didn't look but I'm
>>> assuming they map to 0 and 1 but it would be more correct to use the
>>> enums rather than 0.
>>> 
>>> [1]:
>>> http://docs.wxwidgets.org/3.0/classwx_mouse_event.html#a6e455a3fa3708031d8571e42489d453e
>>> 
>>> On 2/28/2016 6:22 PM, Bernhard Stegmaier wrote:
 Hi Garth,
 
 thanks for the link, do you remember what this patch does actually fix?
 I just checked and the bug is closed… and is integrated both in current
 3.0.x branch and master (I am using master).
 If I understand the ticket correctly, this fix is only about the
 not-working 

Re: [Kicad-developers] About dialog

[Wayne Stambaugh]

On 3/1/2016 12:04 PM, Simon Wells wrote:
> Ah, thats the issue you had with it The help menu option has been
> removed in v2 which i attached a few hours ago. Probably should have
> made it all a single patch from the start but i didn't for some
> reason.
> 
> I will work on adding the ABI information, build time info for wx and
> the curl info and submit a v3 patch with those included. Should we
> have build curl information as well or do you think it unnecessary?

I seem to remember that the libcurl build time information does not get
installed by default by the libcurl build system.  It may be that the
run time information is the best you will be able to do but that's
better than nothing.  If the build time info is ready available, then go
ahead and include it.

> 
> 
> On Wed, Mar 2, 2016 at 5:39 AM, Wayne Stambaugh  wrote:
>> On 3/1/2016 10:49 AM, Simon Wells wrote:
>>> Hey Wayne
>>>
>>> For what reasons are you not thrilled with putting it in the
>>> about_dialog? even on linux/windows i can't say i can remember an
>>> application which has copy version info in the menu structure.
>>>
>>> The main reason i reimplemented it in the about dialog class was due
>>> to wanting/expecting it to be removed from the help menu. The only
>>> missing information currently i believe is the ABI information which
>>> can be added easily enough, one of the problems i see with the current
>>> implementation is its all based on build time information and ignores
>>> run time (for wx mine does the opposite) i can also easily add the
>>> curl stuff which i don't believe is in the current implementation.
>>
>> If you're going to remove the existing copy version info from the
>> exiting help menus than I'm OK with adding it to the about dialog.
>>
>> Either call EDA_BASE_FRAME::CopyVersionInfoToClipboard() from the about
>> dialog (I believe all of our top level windows are derived from
>> EDA_BASE_FRAME), make it static, or move the code to the about dialog
>> source.  Keeping two copies of this around will only create maintenance
>> headaches.
>>
>> If you are going to use the wxWidgets run time information, please
>> create a new line so we can see the wxWidgets build vs run time info.
>> It could prove useful.
>>
>> Please add the libcurl info.  I thought it was already in there.
>>
>>>
>>> thanks
>>>
>>> Simon
>>>
>>>
>>> On Wed, Mar 2, 2016 at 4:18 AM, Wayne Stambaugh  
>>> wrote:
 Simon,

 I'm not thrilled with adding the copy version info button to the about
 box.  The information you are copying to the clipboard is incomplete and
 I don't want users the think this is the version information that we
 want included in bug reports.  I don't understand why you wouldn't have
 just called EDA_BASE_FRAME::CopyVersionInfoToClipboard().  At least it
 would be the same information.  The rest of the changes are fine.

 Cheers,

 Wayne

 On 2/29/2016 1:45 PM, Simon Wells wrote:
> Attached is a patch that modifies a few things in the About dialog, a
> screenshot with old and new is also attached
>
> It removes the horizontal rule which is redundant due to the auinotebook
> Adds Copy Version Info to the about box which i think is a better
> place for it than in the help menu esspecially on OSX where about
> isn't even in the help menu (I haven't removed the menu items yet  am
> interested to hear other peoples thoughts on whether it is used often
> enough to keep it in the main menu bar as well) due to this the code
> is currently in 2 places.
> I have also changed the about dialog (and version info from the about
> box) change to use the currently running version of wxwidgets rather
> than the version that kicad was built with unfortunately this is not
> possible with boost
>
> 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] Legacy Canvas Mousewheel Behavior?

[Wayne Stambaugh]

What patch?  Did I miss an email in this thread at some point?

On 3/1/2016 1:42 PM, Bernhard Stegmaier wrote:
> With my patch it should behave the same way on all platforms.
> It just does ignore axis then…
> 
> GAL does things already differently and apparently it is fine on 
> Windows/Linux 
> and Mac with that code.
> So, just using my patch should be the easiest way to get things consistent 
> again
> on all platforms for now.
> 
>> On 01.03.2016, at 19:35, Wayne Stambaugh  wrote:
>>
>> On 3/1/2016 1:25 PM, Bernhard Stegmaier wrote:
>>> I did that for a PC mouse with my Mac.
>>> As I said in the beginning… Whoever does this, I get axis 0 when nothing 
>>> is pressed, and axis 1 when shift is pressed (using the same mouse, the 
>>> same mousewheel, no touchpad).
>>> That’s why it only did scroll horizontal with the original code (obviously 
>>> only 
>>> on OS X).
>>
>> It sounds like this is not what is happen on linux.  We may have to
>> normalize the axis/shift key behavior to account for platform differences.
>>
>>>
>>> Of course, the axis is for things like touchpads and that’s exactly what 
>>> gets 
>>> used in touchpad-panning mode.
>>> That’s exactly what is the really nice thing about the automatic axis 
>>> change:
>>> With touchpad-panning the same piece of code works with a touchpad and
>>> a normal mouse.
>>> Unmodifed wheel scrolls up/down, shift-wheel scrolls left/right.
>>> Kicad doesn’t have to know anything about which device is there, it just
>>> works… :)
>>>
>>>
 On 01.03.2016, at 19:15, Wayne Stambaugh  wrote:

 I believe the axis is for mice with multiple wheels where the 0 axis is
 the scroll wheel typically used for vertical scrolling.  I do not
 believe the shift or control keys have anything to do with the axis in
 the wxMouseEvent but I have looked at the wxWidget code to see if that
 is the case.  Perhaps there are some inconsistencies between platform as
 to what these axis mean.  The easiest way to find this out is to trace
 the mouse events and see which axis is being sent in the wxMouseEvent
 inside the OnScroll function.

 On 3/1/2016 12:44 PM, Bernhard Stegmaier wrote:
> Yes, but documentation doesn’t state anything about changing axis with 
> shift/ctrl (at least, I didn’t see it).
>
> If the non-touchpad scroll code shall ignore ignore any additional axis, 
> then the current implementation is wrong (it doesn’t ignore axis).
>
> Attached a patch to ignore axis in non-touchpad scroll code (as it was 
> before rev4505).
> Therewith, also shift/ctrl panning again works on OS X (though it might 
> not
> conform to Apple UI guidelines where shift-wheel does a horizontal 
> scroll).
>
>
> Regards,
> Bernhard
>
>
>
>
> PS:
> Mac users using a PC mouse and a Apple mouse in parallel might notice
> that the
> scroll direction of PC mouse is just the other way round than for Mac
> mouse (and
> maybe touchpad).
> Yes. I don’t want to investigate if I can find out which device is
> connected, so it
> is as it is. Don’t use a PC mouse on a Mac… :) 
>
>> On 29.02.2016, at 01:24, Wayne Stambaugh > > wrote:
>>
>> Take a look at the documentation for wxMouseEvent.GetWheelAxis()[1].
>> Some mice and/or trackpads can generate additional axis for horizontal
>> scroll support.  That's why the scroll code ignores any additional axis.
>> Prior to 2.94, GetWheelAxis() returned an int where 0 was the vertical
>> scroll.  Now GetWheelAxis() returns wxMOUSE_WHEEL_VERTICAL and
>> wxMOUSE_WHEEL_HORIZONTAL which are enums.  I didn't look but I'm
>> assuming they map to 0 and 1 but it would be more correct to use the
>> enums rather than 0.
>>
>> [1]:
>> http://docs.wxwidgets.org/3.0/classwx_mouse_event.html#a6e455a3fa3708031d8571e42489d453e
>>
>> On 2/28/2016 6:22 PM, Bernhard Stegmaier wrote:
>>> Hi Garth,
>>>
>>> thanks for the link, do you remember what this patch does actually fix?
>>> I just checked and the bug is closed… and is integrated both in current
>>> 3.0.x branch and master (I am using master).
>>> If I understand the ticket correctly, this fix is only about the
>>> not-working event.skip() or some duplicate handling.
>>>
>>> So, even with this fix the current scrolling is broken due to (obviously
>>> OS X only) change in axis when shift is pressed.
>>> But, as you said, this might be on purpose, because it just leads to
>>> consistent behaviour of how it is handled in native OS X applications
>>> without having to change code or knowing which device is used.
>>>
>>> On OS X the only thing you would want to use is some Apple device with
>>> touchpad-panning anyway… :)
>>>
>>> I still 

Re: [Kicad-developers] OS X: "Save Block" doesn't work from context menu

[Bernhard Stegmaier]

OK, thanks.
I’ll go ahead and replace the used wxID_* event IDs with own ones.
Maybe also the other buttons will start to be useful on OS X.
I have never seen them being anything else than grey… :)


Regards,
Bernhard

> On 01 Mar 2016, at 19:57, jp charras  wrote:
> 
> Le 01/03/2016 19:48, Bernhard Stegmaier a écrit :
>> Hi,
>> 
>> I just had a quick look at that bug report:
>>   https://bugs.launchpad.net/kicad/+bug/1551063 
>> 
>> 
>> See my comments in there… is there any special reason why wxID_COPY is used?
>> Any objections about changing the IDs to own ones?
>> 
>> There is also some discussion here that might be related:
>>  http://trac.wxwidgets.org/ticket/13431 
>> 
>> 
>> 
>> Regards,
>> Bernhard
>> 
> 
> No special reason.
> It is used just because this is an existing ID event.
> 
> 
> -- 
> Jean-Pierre CHARRAS
> 
> ___
> 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] OS X: "Save Block" doesn't work from context menu

[jp charras]

Le 01/03/2016 19:48, Bernhard Stegmaier a écrit :
> Hi,
> 
> I just had a quick look at that bug report:
>https://bugs.launchpad.net/kicad/+bug/1551063 
> 
> 
> See my comments in there… is there any special reason why wxID_COPY is used?
> Any objections about changing the IDs to own ones?
> 
> There is also some discussion here that might be related:
>   http://trac.wxwidgets.org/ticket/13431 
> 
> 
> 
> Regards,
> Bernhard
> 

No special reason.
It is used just because this is an existing ID event.


-- 
Jean-Pierre CHARRAS

___
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] OS X: "Save Block" doesn't work from context menu

[Bernhard Stegmaier]

Hi,

I just had a quick look at that bug report:
   https://bugs.launchpad.net/kicad/+bug/1551063 


See my comments in there… is there any special reason why wxID_COPY is used?
Any objections about changing the IDs to own ones?

There is also some discussion here that might be related:
  http://trac.wxwidgets.org/ticket/13431 



Regards,
Bernhard___
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] Legacy Canvas Mousewheel Behavior?

[Bernhard Stegmaier]

With my patch it should behave the same way on all platforms.
It just does ignore axis then…

GAL does things already differently and apparently it is fine on Windows/Linux 
and Mac with that code.
So, just using my patch should be the easiest way to get things consistent again
on all platforms for now.

> On 01.03.2016, at 19:35, Wayne Stambaugh  wrote:
> 
> On 3/1/2016 1:25 PM, Bernhard Stegmaier wrote:
>> I did that for a PC mouse with my Mac.
>> As I said in the beginning… Whoever does this, I get axis 0 when nothing 
>> is pressed, and axis 1 when shift is pressed (using the same mouse, the 
>> same mousewheel, no touchpad).
>> That’s why it only did scroll horizontal with the original code (obviously 
>> only 
>> on OS X).
> 
> It sounds like this is not what is happen on linux.  We may have to
> normalize the axis/shift key behavior to account for platform differences.
> 
>> 
>> Of course, the axis is for things like touchpads and that’s exactly what 
>> gets 
>> used in touchpad-panning mode.
>> That’s exactly what is the really nice thing about the automatic axis change:
>> With touchpad-panning the same piece of code works with a touchpad and
>> a normal mouse.
>> Unmodifed wheel scrolls up/down, shift-wheel scrolls left/right.
>> Kicad doesn’t have to know anything about which device is there, it just
>> works… :)
>> 
>> 
>>> On 01.03.2016, at 19:15, Wayne Stambaugh  wrote:
>>> 
>>> I believe the axis is for mice with multiple wheels where the 0 axis is
>>> the scroll wheel typically used for vertical scrolling.  I do not
>>> believe the shift or control keys have anything to do with the axis in
>>> the wxMouseEvent but I have looked at the wxWidget code to see if that
>>> is the case.  Perhaps there are some inconsistencies between platform as
>>> to what these axis mean.  The easiest way to find this out is to trace
>>> the mouse events and see which axis is being sent in the wxMouseEvent
>>> inside the OnScroll function.
>>> 
>>> On 3/1/2016 12:44 PM, Bernhard Stegmaier wrote:
 Yes, but documentation doesn’t state anything about changing axis with 
 shift/ctrl (at least, I didn’t see it).
 
 If the non-touchpad scroll code shall ignore ignore any additional axis, 
 then the current implementation is wrong (it doesn’t ignore axis).
 
 Attached a patch to ignore axis in non-touchpad scroll code (as it was 
 before rev4505).
 Therewith, also shift/ctrl panning again works on OS X (though it might not
 conform to Apple UI guidelines where shift-wheel does a horizontal scroll).
 
 
 Regards,
 Bernhard
 
 
 
 
 PS:
 Mac users using a PC mouse and a Apple mouse in parallel might notice
 that the
 scroll direction of PC mouse is just the other way round than for Mac
 mouse (and
 maybe touchpad).
 Yes. I don’t want to investigate if I can find out which device is
 connected, so it
 is as it is. Don’t use a PC mouse on a Mac… :) 
 
> On 29.02.2016, at 01:24, Wayne Stambaugh  > wrote:
> 
> Take a look at the documentation for wxMouseEvent.GetWheelAxis()[1].
> Some mice and/or trackpads can generate additional axis for horizontal
> scroll support.  That's why the scroll code ignores any additional axis.
> Prior to 2.94, GetWheelAxis() returned an int where 0 was the vertical
> scroll.  Now GetWheelAxis() returns wxMOUSE_WHEEL_VERTICAL and
> wxMOUSE_WHEEL_HORIZONTAL which are enums.  I didn't look but I'm
> assuming they map to 0 and 1 but it would be more correct to use the
> enums rather than 0.
> 
> [1]:
> http://docs.wxwidgets.org/3.0/classwx_mouse_event.html#a6e455a3fa3708031d8571e42489d453e
> 
> On 2/28/2016 6:22 PM, Bernhard Stegmaier wrote:
>> Hi Garth,
>> 
>> thanks for the link, do you remember what this patch does actually fix?
>> I just checked and the bug is closed… and is integrated both in current
>> 3.0.x branch and master (I am using master).
>> If I understand the ticket correctly, this fix is only about the
>> not-working event.skip() or some duplicate handling.
>> 
>> So, even with this fix the current scrolling is broken due to (obviously
>> OS X only) change in axis when shift is pressed.
>> But, as you said, this might be on purpose, because it just leads to
>> consistent behaviour of how it is handled in native OS X applications
>> without having to change code or knowing which device is used.
>> 
>> On OS X the only thing you would want to use is some Apple device with
>> touchpad-panning anyway… :)
>> 
>> I still would consider this a wxWidgets bug, because I would expect that
>> a platform-independent application framework doesn’t show different
>> platform specific behavior like this… but that’s another story.
>> 
>> 

Re: [Kicad-developers] Python functionality on Windows

[Nick Østergaard]

Ahh, yeah, sure. I forgot that, I have now installed those now.

2016-03-01 19:04 GMT+01:00 Константин Барановский
:
> Hi, Nick!
> I installed nightly builds from here:
> http://downloads.kicad-pcb.org/windows/nightly/
> kicad-product-r6599.8522b0d-i686.exe from 28-Feb-2016 17:26
> kicad-product-r6601.bd80063-i686.exe from 29-Feb-2016 17:25
> In both is present python2.exe but missing pip (and setuptools).
> It looks like not installed toolchain package mingw-w64-{ARCH}-python2-pip.
> Before pull request, I'm checked the working of the changes and got
> installer that worked fine.
> Can you check your build system?
>
> Regards, Konstantin.

___
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] Legacy Canvas Mousewheel Behavior?

[Wayne Stambaugh]

On 3/1/2016 1:25 PM, Bernhard Stegmaier wrote:
> I did that for a PC mouse with my Mac.
> As I said in the beginning… Whoever does this, I get axis 0 when nothing 
> is pressed, and axis 1 when shift is pressed (using the same mouse, the 
> same mousewheel, no touchpad).
> That’s why it only did scroll horizontal with the original code (obviously 
> only 
> on OS X).

It sounds like this is not what is happen on linux.  We may have to
normalize the axis/shift key behavior to account for platform differences.

> 
> Of course, the axis is for things like touchpads and that’s exactly what gets 
> used in touchpad-panning mode.
> That’s exactly what is the really nice thing about the automatic axis change:
> With touchpad-panning the same piece of code works with a touchpad and
> a normal mouse.
> Unmodifed wheel scrolls up/down, shift-wheel scrolls left/right.
> Kicad doesn’t have to know anything about which device is there, it just
> works… :)
> 
> 
>> On 01.03.2016, at 19:15, Wayne Stambaugh  wrote:
>>
>> I believe the axis is for mice with multiple wheels where the 0 axis is
>> the scroll wheel typically used for vertical scrolling.  I do not
>> believe the shift or control keys have anything to do with the axis in
>> the wxMouseEvent but I have looked at the wxWidget code to see if that
>> is the case.  Perhaps there are some inconsistencies between platform as
>> to what these axis mean.  The easiest way to find this out is to trace
>> the mouse events and see which axis is being sent in the wxMouseEvent
>> inside the OnScroll function.
>>
>> On 3/1/2016 12:44 PM, Bernhard Stegmaier wrote:
>>> Yes, but documentation doesn’t state anything about changing axis with 
>>> shift/ctrl (at least, I didn’t see it).
>>>
>>> If the non-touchpad scroll code shall ignore ignore any additional axis, 
>>> then the current implementation is wrong (it doesn’t ignore axis).
>>>
>>> Attached a patch to ignore axis in non-touchpad scroll code (as it was 
>>> before rev4505).
>>> Therewith, also shift/ctrl panning again works on OS X (though it might not
>>> conform to Apple UI guidelines where shift-wheel does a horizontal scroll).
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>>
>>>
>>>
>>> PS:
>>> Mac users using a PC mouse and a Apple mouse in parallel might notice
>>> that the
>>> scroll direction of PC mouse is just the other way round than for Mac
>>> mouse (and
>>> maybe touchpad).
>>> Yes. I don’t want to investigate if I can find out which device is
>>> connected, so it
>>> is as it is. Don’t use a PC mouse on a Mac… :) 
>>>
 On 29.02.2016, at 01:24, Wayne Stambaugh > wrote:

 Take a look at the documentation for wxMouseEvent.GetWheelAxis()[1].
 Some mice and/or trackpads can generate additional axis for horizontal
 scroll support.  That's why the scroll code ignores any additional axis.
 Prior to 2.94, GetWheelAxis() returned an int where 0 was the vertical
 scroll.  Now GetWheelAxis() returns wxMOUSE_WHEEL_VERTICAL and
 wxMOUSE_WHEEL_HORIZONTAL which are enums.  I didn't look but I'm
 assuming they map to 0 and 1 but it would be more correct to use the
 enums rather than 0.

 [1]:
 http://docs.wxwidgets.org/3.0/classwx_mouse_event.html#a6e455a3fa3708031d8571e42489d453e

 On 2/28/2016 6:22 PM, Bernhard Stegmaier wrote:
> Hi Garth,
>
> thanks for the link, do you remember what this patch does actually fix?
> I just checked and the bug is closed… and is integrated both in current
> 3.0.x branch and master (I am using master).
> If I understand the ticket correctly, this fix is only about the
> not-working event.skip() or some duplicate handling.
>
> So, even with this fix the current scrolling is broken due to (obviously
> OS X only) change in axis when shift is pressed.
> But, as you said, this might be on purpose, because it just leads to
> consistent behaviour of how it is handled in native OS X applications
> without having to change code or knowing which device is used.
>
> On OS X the only thing you would want to use is some Apple device with
> touchpad-panning anyway… :)
>
> I still would consider this a wxWidgets bug, because I would expect that
> a platform-independent application framework doesn’t show different
> platform specific behavior like this… but that’s another story.
>
> Anyway… this still leaves the question open on how to fix it - assuming
> that a consistent KiCad behavior on all platforms is the goal.
> Change axis back on OS X or remove the piece of code that checks axis
> (if somebody can remember why it is done this way)?
> It came in with
> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4505
> … but there is no hint why this was changed.
>
>
> Regards,
> Bernhard
>
>> On 28 Feb 2016, at 23:18, 

Re: [Kicad-developers] Legacy Canvas Mousewheel Behavior?

[Bernhard Stegmaier]

I did that for a PC mouse with my Mac.
As I said in the beginning… Whoever does this, I get axis 0 when nothing 
is pressed, and axis 1 when shift is pressed (using the same mouse, the 
same mousewheel, no touchpad).
That’s why it only did scroll horizontal with the original code (obviously only 
on OS X).

Of course, the axis is for things like touchpads and that’s exactly what gets 
used in touchpad-panning mode.
That’s exactly what is the really nice thing about the automatic axis change:
With touchpad-panning the same piece of code works with a touchpad and
a normal mouse.
Unmodifed wheel scrolls up/down, shift-wheel scrolls left/right.
Kicad doesn’t have to know anything about which device is there, it just
works… :)


> On 01.03.2016, at 19:15, Wayne Stambaugh  wrote:
> 
> I believe the axis is for mice with multiple wheels where the 0 axis is
> the scroll wheel typically used for vertical scrolling.  I do not
> believe the shift or control keys have anything to do with the axis in
> the wxMouseEvent but I have looked at the wxWidget code to see if that
> is the case.  Perhaps there are some inconsistencies between platform as
> to what these axis mean.  The easiest way to find this out is to trace
> the mouse events and see which axis is being sent in the wxMouseEvent
> inside the OnScroll function.
> 
> On 3/1/2016 12:44 PM, Bernhard Stegmaier wrote:
>> Yes, but documentation doesn’t state anything about changing axis with 
>> shift/ctrl (at least, I didn’t see it).
>> 
>> If the non-touchpad scroll code shall ignore ignore any additional axis, 
>> then the current implementation is wrong (it doesn’t ignore axis).
>> 
>> Attached a patch to ignore axis in non-touchpad scroll code (as it was 
>> before rev4505).
>> Therewith, also shift/ctrl panning again works on OS X (though it might not
>> conform to Apple UI guidelines where shift-wheel does a horizontal scroll).
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> 
>> 
>> 
>> PS:
>> Mac users using a PC mouse and a Apple mouse in parallel might notice
>> that the
>> scroll direction of PC mouse is just the other way round than for Mac
>> mouse (and
>> maybe touchpad).
>> Yes. I don’t want to investigate if I can find out which device is
>> connected, so it
>> is as it is. Don’t use a PC mouse on a Mac… :) 
>> 
>>> On 29.02.2016, at 01:24, Wayne Stambaugh >> > wrote:
>>> 
>>> Take a look at the documentation for wxMouseEvent.GetWheelAxis()[1].
>>> Some mice and/or trackpads can generate additional axis for horizontal
>>> scroll support.  That's why the scroll code ignores any additional axis.
>>> Prior to 2.94, GetWheelAxis() returned an int where 0 was the vertical
>>> scroll.  Now GetWheelAxis() returns wxMOUSE_WHEEL_VERTICAL and
>>> wxMOUSE_WHEEL_HORIZONTAL which are enums.  I didn't look but I'm
>>> assuming they map to 0 and 1 but it would be more correct to use the
>>> enums rather than 0.
>>> 
>>> [1]:
>>> http://docs.wxwidgets.org/3.0/classwx_mouse_event.html#a6e455a3fa3708031d8571e42489d453e
>>> 
>>> On 2/28/2016 6:22 PM, Bernhard Stegmaier wrote:
 Hi Garth,
 
 thanks for the link, do you remember what this patch does actually fix?
 I just checked and the bug is closed… and is integrated both in current
 3.0.x branch and master (I am using master).
 If I understand the ticket correctly, this fix is only about the
 not-working event.skip() or some duplicate handling.
 
 So, even with this fix the current scrolling is broken due to (obviously
 OS X only) change in axis when shift is pressed.
 But, as you said, this might be on purpose, because it just leads to
 consistent behaviour of how it is handled in native OS X applications
 without having to change code or knowing which device is used.
 
 On OS X the only thing you would want to use is some Apple device with
 touchpad-panning anyway… :)
 
 I still would consider this a wxWidgets bug, because I would expect that
 a platform-independent application framework doesn’t show different
 platform specific behavior like this… but that’s another story.
 
 Anyway… this still leaves the question open on how to fix it - assuming
 that a consistent KiCad behavior on all platforms is the goal.
 Change axis back on OS X or remove the piece of code that checks axis
 (if somebody can remember why it is done this way)?
 It came in with
 http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4505
 … but there is no hint why this was changed.
 
 
 Regards,
 Bernhard
 
> On 28 Feb 2016, at 23:18, Garth Corral  
> > wrote:
> 
> Hi, Bernhard
> 
> Yes, you have it right on both counts.   That was, and still is, my
> assessment.  The existing behavior is not correct, at least as far as
> OS 

Re: [Kicad-developers] Legacy Canvas Mousewheel Behavior?

[Bernhard Stegmaier]

> On 01.03.2016, at 19:08, Garth Corral  wrote:
> 
> Even on Linux I think this behavior is wrong.  I can’t think of any 
> applications where shift-modified scrollwheel causes vertical scrolling.  If 
> an unmodified scrollwheel does that, and shift-modified commonly does 
> horizontal scrolling it just seems wrong that shifting it should cause 
> vertical scrolling in the case where the default action is to zoom.  It’s 
> just confusing.  At the very least the modifier should be changed to some 
> other key in that case.

I agree with you, but I don’t want to discuss which one is best here. 

But if it really should do a horizontal scroll on shift-wheel then IMHO it is a 
wxWidgets bug that it doesn’t change axis on Windows/Linux.
If it would have done that, Linux and Windows guys wouldn’t have been able to 
shift/ctrl-scroll since rev4505.
I guess that would have been brought up very early… :)


Regards,
Bernhard


___
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] Legacy Canvas Mousewheel Behavior?

[Wayne Stambaugh]

I believe the axis is for mice with multiple wheels where the 0 axis is
the scroll wheel typically used for vertical scrolling.  I do not
believe the shift or control keys have anything to do with the axis in
the wxMouseEvent but I have looked at the wxWidget code to see if that
is the case.  Perhaps there are some inconsistencies between platform as
to what these axis mean.  The easiest way to find this out is to trace
the mouse events and see which axis is being sent in the wxMouseEvent
inside the OnScroll function.

On 3/1/2016 12:44 PM, Bernhard Stegmaier wrote:
> Yes, but documentation doesn’t state anything about changing axis with 
> shift/ctrl (at least, I didn’t see it).
> 
> If the non-touchpad scroll code shall ignore ignore any additional axis, 
> then the current implementation is wrong (it doesn’t ignore axis).
> 
> Attached a patch to ignore axis in non-touchpad scroll code (as it was 
> before rev4505).
> Therewith, also shift/ctrl panning again works on OS X (though it might not
> conform to Apple UI guidelines where shift-wheel does a horizontal scroll).
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> 
> PS:
> Mac users using a PC mouse and a Apple mouse in parallel might notice
> that the
> scroll direction of PC mouse is just the other way round than for Mac
> mouse (and
> maybe touchpad).
> Yes. I don’t want to investigate if I can find out which device is
> connected, so it
> is as it is. Don’t use a PC mouse on a Mac… :) 
> 
>> On 29.02.2016, at 01:24, Wayne Stambaugh > > wrote:
>>
>> Take a look at the documentation for wxMouseEvent.GetWheelAxis()[1].
>> Some mice and/or trackpads can generate additional axis for horizontal
>> scroll support.  That's why the scroll code ignores any additional axis.
>> Prior to 2.94, GetWheelAxis() returned an int where 0 was the vertical
>> scroll.  Now GetWheelAxis() returns wxMOUSE_WHEEL_VERTICAL and
>> wxMOUSE_WHEEL_HORIZONTAL which are enums.  I didn't look but I'm
>> assuming they map to 0 and 1 but it would be more correct to use the
>> enums rather than 0.
>>
>> [1]:
>> http://docs.wxwidgets.org/3.0/classwx_mouse_event.html#a6e455a3fa3708031d8571e42489d453e
>>
>> On 2/28/2016 6:22 PM, Bernhard Stegmaier wrote:
>>> Hi Garth,
>>>
>>> thanks for the link, do you remember what this patch does actually fix?
>>> I just checked and the bug is closed… and is integrated both in current
>>> 3.0.x branch and master (I am using master).
>>> If I understand the ticket correctly, this fix is only about the
>>> not-working event.skip() or some duplicate handling.
>>>
>>> So, even with this fix the current scrolling is broken due to (obviously
>>> OS X only) change in axis when shift is pressed.
>>> But, as you said, this might be on purpose, because it just leads to
>>> consistent behaviour of how it is handled in native OS X applications
>>> without having to change code or knowing which device is used.
>>>
>>> On OS X the only thing you would want to use is some Apple device with
>>> touchpad-panning anyway… :)
>>>
>>> I still would consider this a wxWidgets bug, because I would expect that
>>> a platform-independent application framework doesn’t show different
>>> platform specific behavior like this… but that’s another story.
>>>
>>> Anyway… this still leaves the question open on how to fix it - assuming
>>> that a consistent KiCad behavior on all platforms is the goal.
>>> Change axis back on OS X or remove the piece of code that checks axis
>>> (if somebody can remember why it is done this way)?
>>> It came in with
>>>  
>>> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4505
>>> … but there is no hint why this was changed.
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
 On 28 Feb 2016, at 23:18, Garth Corral 
 > wrote:

 Hi, Bernhard

 Yes, you have it right on both counts.   That was, and still is, my
 assessment.  The existing behavior is not correct, at least as far as
 OS X (and probably Linux) is concerned.  I don’t know about windows.  
 That is the patch that fixes the issue to which I referred in that post.

 I think it might be this issue:

 http://trac.wxwidgets.org/ticket/15684


> On Feb 28, 2016, at 11:25 AM, Bernhard Stegmaier
>   >
> wrote:
>
> FYI, meanwhile I found an old mail from Garth on this topic (March
> last year):
> <<<
> Shift-modified scrollwheel events in wxWidgets (at least on OS X)
> have their axis modified (by wxWidgets) to be horizontal.  This
> matches the behavior of native OS X applications as well.  So making
> shift-scrollwheel do vertical scrolling is wrong (and exposed a
> wxWidgets bug for which I committed a patch).

>
> Maybe it is this patch
>  

Re: [Kicad-developers] Legacy Canvas Mousewheel Behavior?

[Garth Corral]

> On Mar 1, 2016, at 9:44 AM, Bernhard Stegmaier  
> wrote:
> 
> Yes, but documentation doesn’t state anything about changing axis with 
> shift/ctrl (at least, I didn’t see it).
> 
> If the non-touchpad scroll code shall ignore ignore any additional axis, 
> then the current implementation is wrong (it doesn’t ignore axis).
> 
> Attached a patch to ignore axis in non-touchpad scroll code (as it was 
> before rev4505).
> Therewith, also shift/ctrl panning again works on OS X (though it might not
> conform to Apple UI guidelines where shift-wheel does a horizontal scroll).
> 
Even on Linux I think this behavior is wrong.  I can’t think of any 
applications where shift-modified scrollwheel causes vertical scrolling.  If an 
unmodified scrollwheel does that, and shift-modified commonly does horizontal 
scrolling it just seems wrong that shifting it should cause vertical scrolling 
in the case where the default action is to zoom.  It’s just confusing.  At the 
very least the modifier should be changed to some other key in that case.

Garth


> 
> Regards,
> Bernhard
> 
> 
> 
> PS:
> Mac users using a PC mouse and a Apple mouse in parallel might notice that the
> scroll direction of PC mouse is just the other way round than for Mac mouse 
> (and
> maybe touchpad).
> Yes. I don’t want to investigate if I can find out which device is connected, 
> so it
> is as it is. Don’t use a PC mouse on a Mac… :) 
> 
>> On 29.02.2016, at 01:24, Wayne Stambaugh > > wrote:
>> 
>> Take a look at the documentation for wxMouseEvent.GetWheelAxis()[1].
>> Some mice and/or trackpads can generate additional axis for horizontal
>> scroll support.  That's why the scroll code ignores any additional axis.
>> Prior to 2.94, GetWheelAxis() returned an int where 0 was the vertical
>> scroll.  Now GetWheelAxis() returns wxMOUSE_WHEEL_VERTICAL and
>> wxMOUSE_WHEEL_HORIZONTAL which are enums.  I didn't look but I'm
>> assuming they map to 0 and 1 but it would be more correct to use the
>> enums rather than 0.
>> 
>> [1]:
>> http://docs.wxwidgets.org/3.0/classwx_mouse_event.html#a6e455a3fa3708031d8571e42489d453e
>>  
>> 
>> 
>> On 2/28/2016 6:22 PM, Bernhard Stegmaier wrote:
>>> Hi Garth,
>>> 
>>> thanks for the link, do you remember what this patch does actually fix?
>>> I just checked and the bug is closed… and is integrated both in current
>>> 3.0.x branch and master (I am using master).
>>> If I understand the ticket correctly, this fix is only about the
>>> not-working event.skip() or some duplicate handling.
>>> 
>>> So, even with this fix the current scrolling is broken due to (obviously
>>> OS X only) change in axis when shift is pressed.
>>> But, as you said, this might be on purpose, because it just leads to
>>> consistent behaviour of how it is handled in native OS X applications
>>> without having to change code or knowing which device is used.
>>> 
>>> On OS X the only thing you would want to use is some Apple device with
>>> touchpad-panning anyway… :)
>>> 
>>> I still would consider this a wxWidgets bug, because I would expect that
>>> a platform-independent application framework doesn’t show different
>>> platform specific behavior like this… but that’s another story.
>>> 
>>> Anyway… this still leaves the question open on how to fix it - assuming
>>> that a consistent KiCad behavior on all platforms is the goal.
>>> Change axis back on OS X or remove the piece of code that checks axis
>>> (if somebody can remember why it is done this way)?
>>> It came in with
>>>  
>>> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4505
>>>  
>>> 
>>> … but there is no hint why this was changed.
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
 On 28 Feb 2016, at 23:18, Garth Corral 
 >> wrote:
 
 Hi, Bernhard
 
 Yes, you have it right on both counts.   That was, and still is, my
 assessment.  The existing behavior is not correct, at least as far as
 OS X (and probably Linux) is concerned.  I don’t know about windows.  
 That is the patch that fixes the issue to which I referred in that post.
 
 I think it might be this issue:
 
 http://trac.wxwidgets.org/ticket/15684 
 
 
 
> On Feb 28, 2016, at 11:25 AM, Bernhard Stegmaier
>  
> >> wrote:
> 
> FYI, meanwhile I found an old mail from Garth on this topic (March
> last year):
> <<<
> Shift-modified scrollwheel events in wxWidgets (at least on OS X)
> have their axis 

Re: [Kicad-developers] Python functionality on Windows

[Константин Барановский]

Hi, Nick!
I installed nightly builds from here:
http://downloads.kicad-pcb.org/windows/nightly/
kicad-product-r6599.8522b0d-i686.exe from 28-Feb-2016 17:26
kicad-product-r6601.bd80063-i686.exe from 29-Feb-2016 17:25
In both is present python2.exe but missing pip (and setuptools).
It looks like not installed toolchain package mingw-w64-{ARCH}-python2-pip.
Before pull request, I'm checked the working of the changes and got
installer that worked fine.
Can you check your build system?

Regards, Konstantin.
___
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] Legacy Canvas Mousewheel Behavior?

[Bernhard Stegmaier]

Yes, but documentation doesn’t state anything about changing axis with shift/ctrl (at least, I didn’t see it).If the non-touchpad scroll code shall ignore ignore any additional axis, then the current implementation is wrong (it doesn’t ignore axis).Attached a patch to ignore axis in non-touchpad scroll code (as it was before rev4505).Therewith, also shift/ctrl panning again works on OS X (though it might notconform to Apple UI guidelines where shift-wheel does a horizontal scroll).Regards,Bernhard

wheel-pan.patch
Description: Binary data
PS:Mac users using a PC mouse and a Apple mouse in parallel might notice that thescroll direction of PC mouse is just the other way round than for Mac mouse (andmaybe touchpad).Yes. I don’t want to investigate if I can find out which device is connected, so itis as it is. Don’t use a PC mouse on a Mac… :) On 29.02.2016, at 01:24, Wayne Stambaugh  wrote:Take a look at the documentation for wxMouseEvent.GetWheelAxis()[1].Some mice and/or trackpads can generate additional axis for horizontalscroll support.  That's why the scroll code ignores any additional axis.Prior to 2.94, GetWheelAxis() returned an int where 0 was the verticalscroll.  Now GetWheelAxis() returns wxMOUSE_WHEEL_VERTICAL andwxMOUSE_WHEEL_HORIZONTAL which are enums.  I didn't look but I'massuming they map to 0 and 1 but it would be more correct to use theenums rather than 0.[1]:http://docs.wxwidgets.org/3.0/classwx_mouse_event.html#a6e455a3fa3708031d8571e42489d453eOn 2/28/2016 6:22 PM, Bernhard Stegmaier wrote:Hi Garth,thanks for the link, do you remember what this patch does actually fix?I just checked and the bug is closed… and is integrated both in current3.0.x branch and master (I am using master).If I understand the ticket correctly, this fix is only about thenot-working event.skip() or some duplicate handling.So, even with this fix the current scrolling is broken due to (obviouslyOS X only) change in axis when shift is pressed.But, as you said, this might be on purpose, because it just leads toconsistent behaviour of how it is handled in native OS X applicationswithout having to change code or knowing which device is used.On OS X the only thing you would want to use is some Apple device withtouchpad-panning anyway… :)I still would consider this a wxWidgets bug, because I would expect thata platform-independent application framework doesn’t show differentplatform specific behavior like this… but that’s another story.Anyway… this still leaves the question open on how to fix it - assumingthat a consistent KiCad behavior on all platforms is the goal.Change axis back on OS X or remove the piece of code that checks axis(if somebody can remember why it is done this way)?It came in with http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4505… but there is no hint why this was changed.Regards,BernhardOn 28 Feb 2016, at 23:18, Garth Corral > wrote:Hi, BernhardYes, you have it right on both counts.   That was, and still is, myassessment.  The existing behavior is not correct, at least as far asOS X (and probably Linux) is concerned.  I don’t know about windows.  That is the patch that fixes the issue to which I referred in that post.I think it might be this issue:http://trac.wxwidgets.org/ticket/15684On Feb 28, 2016, at 11:25 AM, Bernhard Stegmaier> wrote:FYI, meanwhile I found an old mail from Garth on this topic (Marchlast year):<<> wrote:Hi,while testing the touchpad-panning for the recent 3d-viewer fixes Inoticed, that non-touchpad-panning using shift/ctrl-wheel and anormal PC mouse seems to be broken on OS X with legacy canvas.It only pans horizontal regardless whether you press shift or ctrl.This is already the case in the official 4.0.1, so it has nothing todo with my changes.Debugging this I noticed that obviously wxWidgets or OS X change thewheel axis from vertical (0) without shift (or, while pressing ctrl)to horizontal (1) when pressing shift.So, this piece of code (draw_panel.cpp, line 

Re: [Kicad-developers] [PATCH 3/8] Use PATH to search for shared libraries on Windows

[Simon Richter]

Hi,

On 01.03.2016 16:58, jp charras wrote:

> I do no see what issue patch 1 fixes.

That is one half of the things I did -- the Windows API offers
InterlockedIncrement and InterlockedDecrement only for unsigned types,
while gcc's intrinsic is overloaded, so I had to change that in a common
header anyway, and it doesn't make much sense to use a signed value
here, so I split that from the platform specific parts.

With C++11, it may make more sense to use std::atomic to be fully portable.

   Simon



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

Re: [Kicad-developers] About dialog

[Simon Wells]

Ah, thats the issue you had with it The help menu option has been
removed in v2 which i attached a few hours ago. Probably should have
made it all a single patch from the start but i didn't for some
reason.

I will work on adding the ABI information, build time info for wx and
the curl info and submit a v3 patch with those included. Should we
have build curl information as well or do you think it unnecessary?


On Wed, Mar 2, 2016 at 5:39 AM, Wayne Stambaugh  wrote:
> On 3/1/2016 10:49 AM, Simon Wells wrote:
>> Hey Wayne
>>
>> For what reasons are you not thrilled with putting it in the
>> about_dialog? even on linux/windows i can't say i can remember an
>> application which has copy version info in the menu structure.
>>
>> The main reason i reimplemented it in the about dialog class was due
>> to wanting/expecting it to be removed from the help menu. The only
>> missing information currently i believe is the ABI information which
>> can be added easily enough, one of the problems i see with the current
>> implementation is its all based on build time information and ignores
>> run time (for wx mine does the opposite) i can also easily add the
>> curl stuff which i don't believe is in the current implementation.
>
> If you're going to remove the existing copy version info from the
> exiting help menus than I'm OK with adding it to the about dialog.
>
> Either call EDA_BASE_FRAME::CopyVersionInfoToClipboard() from the about
> dialog (I believe all of our top level windows are derived from
> EDA_BASE_FRAME), make it static, or move the code to the about dialog
> source.  Keeping two copies of this around will only create maintenance
> headaches.
>
> If you are going to use the wxWidgets run time information, please
> create a new line so we can see the wxWidgets build vs run time info.
> It could prove useful.
>
> Please add the libcurl info.  I thought it was already in there.
>
>>
>> thanks
>>
>> Simon
>>
>>
>> On Wed, Mar 2, 2016 at 4:18 AM, Wayne Stambaugh  wrote:
>>> Simon,
>>>
>>> I'm not thrilled with adding the copy version info button to the about
>>> box.  The information you are copying to the clipboard is incomplete and
>>> I don't want users the think this is the version information that we
>>> want included in bug reports.  I don't understand why you wouldn't have
>>> just called EDA_BASE_FRAME::CopyVersionInfoToClipboard().  At least it
>>> would be the same information.  The rest of the changes are fine.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 2/29/2016 1:45 PM, Simon Wells wrote:
 Attached is a patch that modifies a few things in the About dialog, a
 screenshot with old and new is also attached

 It removes the horizontal rule which is redundant due to the auinotebook
 Adds Copy Version Info to the about box which i think is a better
 place for it than in the help menu esspecially on OSX where about
 isn't even in the help menu (I haven't removed the menu items yet  am
 interested to hear other peoples thoughts on whether it is used often
 enough to keep it in the main menu bar as well) due to this the code
 is currently in 2 places.
 I have also changed the about dialog (and version info from the about
 box) change to use the currently running version of wxwidgets rather
 than the version that kicad was built with unfortunately this is not
 possible with boost

 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] About dialog

[Wayne Stambaugh]

On 3/1/2016 10:49 AM, Simon Wells wrote:
> Hey Wayne
> 
> For what reasons are you not thrilled with putting it in the
> about_dialog? even on linux/windows i can't say i can remember an
> application which has copy version info in the menu structure.
> 
> The main reason i reimplemented it in the about dialog class was due
> to wanting/expecting it to be removed from the help menu. The only
> missing information currently i believe is the ABI information which
> can be added easily enough, one of the problems i see with the current
> implementation is its all based on build time information and ignores
> run time (for wx mine does the opposite) i can also easily add the
> curl stuff which i don't believe is in the current implementation.

If you're going to remove the existing copy version info from the
exiting help menus than I'm OK with adding it to the about dialog.

Either call EDA_BASE_FRAME::CopyVersionInfoToClipboard() from the about
dialog (I believe all of our top level windows are derived from
EDA_BASE_FRAME), make it static, or move the code to the about dialog
source.  Keeping two copies of this around will only create maintenance
headaches.

If you are going to use the wxWidgets run time information, please
create a new line so we can see the wxWidgets build vs run time info.
It could prove useful.

Please add the libcurl info.  I thought it was already in there.

> 
> thanks
> 
> Simon
> 
> 
> On Wed, Mar 2, 2016 at 4:18 AM, Wayne Stambaugh  wrote:
>> Simon,
>>
>> I'm not thrilled with adding the copy version info button to the about
>> box.  The information you are copying to the clipboard is incomplete and
>> I don't want users the think this is the version information that we
>> want included in bug reports.  I don't understand why you wouldn't have
>> just called EDA_BASE_FRAME::CopyVersionInfoToClipboard().  At least it
>> would be the same information.  The rest of the changes are fine.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 2/29/2016 1:45 PM, Simon Wells wrote:
>>> Attached is a patch that modifies a few things in the About dialog, a
>>> screenshot with old and new is also attached
>>>
>>> It removes the horizontal rule which is redundant due to the auinotebook
>>> Adds Copy Version Info to the about box which i think is a better
>>> place for it than in the help menu esspecially on OSX where about
>>> isn't even in the help menu (I haven't removed the menu items yet  am
>>> interested to hear other peoples thoughts on whether it is used often
>>> enough to keep it in the main menu bar as well) due to this the code
>>> is currently in 2 places.
>>> I have also changed the about dialog (and version info from the about
>>> box) change to use the currently running version of wxwidgets rather
>>> than the version that kicad was built with unfortunately this is not
>>> possible with boost
>>>
>>> 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] PATCH: Unify mirror and copy block functions between schematic editor and library aditor

[Mikael Arguedas]

Hi,

Sorry about that, I'll update the patch to comply to the coding policy.
I'm currently investigating the rotate block function. It seems to be
working only is the selection rectangle lands on a pin location but doesn't
work otherwise. I'm trying to figure out why this appears only for the
rotate block function and not the others.

Thanks for reviewing it.

Cheers,
Mikael

On Tue, Mar 1, 2016 at 6:56 AM, Wayne Stambaugh 
wrote:

> Mikael,
>
> I just tested your patches and they do unify the block mirror behavior
> but the rotate hot key (R) does not rotate a block in component library
> editor.  I would prefer that you fix that before I commit your patches.
>  Also, you have some copy policy violations (trailing white space, curly
> bracket placement, and missing spaces between text and braces) in your
> patch.  Since it's your first patch, I will cut you some slack but in
> the future please submit patches that to adhere to the coding policy[1].
>
> Cheers,
>
> Wayne
>
> [1]:
>
> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_coding-style-policy.html
>
> On 2/24/2016 12:43 PM, Mikael Arguedas wrote:
> > Hi guys,
> >
> > Here are two patches:
> > unifyCopyBlock.patch: makes the CopyBlock function in library editor
> > match the behaviour of the one in schematic editor
> > addMirrorHotkeys.patch:
> > - adds the HkMirrorX and HkMirrorY hotkeys to library editor
> > - allor the HkRotate hotkey to rotate blocks and not only items
> >
> > Regards,
> > Mikael
> >
> >
> > ___
> > 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] [PATCH 3/8] Use PATH to search for shared libraries on Windows

[jp charras]

Le 26/02/2016 22:18, Simon Richter a écrit :
> 
> This is appropriate for all Windows targets, not just MSYS.
> ---
>  include/kiway.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

I committed patches 2 and 3.
Thanks.

PS:
I do no see what issue patch 1 fixes.


-- 
Jean-Pierre CHARRAS

___
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] About dialog

[Simon Wells]

Hey Wayne

For what reasons are you not thrilled with putting it in the
about_dialog? even on linux/windows i can't say i can remember an
application which has copy version info in the menu structure.

The main reason i reimplemented it in the about dialog class was due
to wanting/expecting it to be removed from the help menu. The only
missing information currently i believe is the ABI information which
can be added easily enough, one of the problems i see with the current
implementation is its all based on build time information and ignores
run time (for wx mine does the opposite) i can also easily add the
curl stuff which i don't believe is in the current implementation.

thanks

Simon


On Wed, Mar 2, 2016 at 4:18 AM, Wayne Stambaugh  wrote:
> Simon,
>
> I'm not thrilled with adding the copy version info button to the about
> box.  The information you are copying to the clipboard is incomplete and
> I don't want users the think this is the version information that we
> want included in bug reports.  I don't understand why you wouldn't have
> just called EDA_BASE_FRAME::CopyVersionInfoToClipboard().  At least it
> would be the same information.  The rest of the changes are fine.
>
> Cheers,
>
> Wayne
>
> On 2/29/2016 1:45 PM, Simon Wells wrote:
>> Attached is a patch that modifies a few things in the About dialog, a
>> screenshot with old and new is also attached
>>
>> It removes the horizontal rule which is redundant due to the auinotebook
>> Adds Copy Version Info to the about box which i think is a better
>> place for it than in the help menu esspecially on OSX where about
>> isn't even in the help menu (I haven't removed the menu items yet  am
>> interested to hear other peoples thoughts on whether it is used often
>> enough to keep it in the main menu bar as well) due to this the code
>> is currently in 2 places.
>> I have also changed the about dialog (and version info from the about
>> box) change to use the currently running version of wxwidgets rather
>> than the version that kicad was built with unfortunately this is not
>> possible with boost
>>
>> 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] About dialog

[Wayne Stambaugh]

Simon,

I'm not thrilled with adding the copy version info button to the about
box.  The information you are copying to the clipboard is incomplete and
I don't want users the think this is the version information that we
want included in bug reports.  I don't understand why you wouldn't have
just called EDA_BASE_FRAME::CopyVersionInfoToClipboard().  At least it
would be the same information.  The rest of the changes are fine.

Cheers,

Wayne

On 2/29/2016 1:45 PM, Simon Wells wrote:
> Attached is a patch that modifies a few things in the About dialog, a
> screenshot with old and new is also attached
> 
> It removes the horizontal rule which is redundant due to the auinotebook
> Adds Copy Version Info to the about box which i think is a better
> place for it than in the help menu esspecially on OSX where about
> isn't even in the help menu (I haven't removed the menu items yet  am
> interested to hear other peoples thoughts on whether it is used often
> enough to keep it in the main menu bar as well) due to this the code
> is currently in 2 places.
> I have also changed the about dialog (and version info from the about
> box) change to use the currently running version of wxwidgets rather
> than the version that kicad was built with unfortunately this is not
> possible with boost
> 
> 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] PATCH: Unify mirror and copy block functions between schematic editor and library aditor

[Wayne Stambaugh]

Mikael,

I just tested your patches and they do unify the block mirror behavior
but the rotate hot key (R) does not rotate a block in component library
editor.  I would prefer that you fix that before I commit your patches.
 Also, you have some copy policy violations (trailing white space, curly
bracket placement, and missing spaces between text and braces) in your
patch.  Since it's your first patch, I will cut you some slack but in
the future please submit patches that to adhere to the coding policy[1].

Cheers,

Wayne

[1]:
http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_coding-style-policy.html

On 2/24/2016 12:43 PM, Mikael Arguedas wrote:
> Hi guys,
> 
> Here are two patches:
> unifyCopyBlock.patch: makes the CopyBlock function in library editor
> match the behaviour of the one in schematic editor
> addMirrorHotkeys.patch:
> - adds the HkMirrorX and HkMirrorY hotkeys to library editor
> - allor the HkRotate hotkey to rotate blocks and not only items
> 
> Regards,
> Mikael
> 
> 
> ___
> 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] About dialog

[Kaspar Emanuel]

Sorry simon, this wasn't specific to your patch, more of a general
question. Thanks for the clarification Nick.

On 1 March 2016 at 13:52, Nick Østergaard  wrote:
> It depends on how it is built. Currently the triplet version number is
> manually added by packagers. If you build from the tars you will get
> no-bzr or something like that. If you build from a bzr repo you will
> get a bzr revno, if you build from a git repo, you will get a bzr and
> git hash.
>
> 2016-03-01 13:43 GMT+01:00 Kaspar Emanuel :
>> Why doesn't the version in the about dialog actually give the versions that
>> are announced e.g. 4.0.2?
>>
>> On 1 March 2016 at 10:19, Simon Wells  wrote:
>>>
>>> Removed the menu option from help in this version of the patch.
>>>
>>> On Tue, Mar 1, 2016 at 7:45 AM, Simon Wells  wrote:
>>> > Attached is a patch that modifies a few things in the About dialog, a
>>> > screenshot with old and new is also attached
>>> >
>>> > It removes the horizontal rule which is redundant due to the auinotebook
>>> > Adds Copy Version Info to the about box which i think is a better
>>> > place for it than in the help menu esspecially on OSX where about
>>> > isn't even in the help menu (I haven't removed the menu items yet  am
>>> > interested to hear other peoples thoughts on whether it is used often
>>> > enough to keep it in the main menu bar as well) due to this the code
>>> > is currently in 2 places.
>>> > I have also changed the about dialog (and version info from the about
>>> > box) change to use the currently running version of wxwidgets rather
>>> > than the version that kicad was built with unfortunately this is not
>>> > possible with boost
>>> >
>>> > 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] About dialog

[Nick Østergaard]

It depends on how it is built. Currently the triplet version number is
manually added by packagers. If you build from the tars you will get
no-bzr or something like that. If you build from a bzr repo you will
get a bzr revno, if you build from a git repo, you will get a bzr and
git hash.

2016-03-01 13:43 GMT+01:00 Kaspar Emanuel :
> Why doesn't the version in the about dialog actually give the versions that
> are announced e.g. 4.0.2?
>
> On 1 March 2016 at 10:19, Simon Wells  wrote:
>>
>> Removed the menu option from help in this version of the patch.
>>
>> On Tue, Mar 1, 2016 at 7:45 AM, Simon Wells  wrote:
>> > Attached is a patch that modifies a few things in the About dialog, a
>> > screenshot with old and new is also attached
>> >
>> > It removes the horizontal rule which is redundant due to the auinotebook
>> > Adds Copy Version Info to the about box which i think is a better
>> > place for it than in the help menu esspecially on OSX where about
>> > isn't even in the help menu (I haven't removed the menu items yet  am
>> > interested to hear other peoples thoughts on whether it is used often
>> > enough to keep it in the main menu bar as well) due to this the code
>> > is currently in 2 places.
>> > I have also changed the about dialog (and version info from the about
>> > box) change to use the currently running version of wxwidgets rather
>> > than the version that kicad was built with unfortunately this is not
>> > possible with boost
>> >
>> > 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] About dialog

[Simon Wells]

can you post your version info please

On Wed, Mar 2, 2016 at 1:43 AM, Kaspar Emanuel  wrote:
> Why doesn't the version in the about dialog actually give the versions that
> are announced e.g. 4.0.2?
>
> On 1 March 2016 at 10:19, Simon Wells  wrote:
>>
>> Removed the menu option from help in this version of the patch.
>>
>> On Tue, Mar 1, 2016 at 7:45 AM, Simon Wells  wrote:
>> > Attached is a patch that modifies a few things in the About dialog, a
>> > screenshot with old and new is also attached
>> >
>> > It removes the horizontal rule which is redundant due to the auinotebook
>> > Adds Copy Version Info to the about box which i think is a better
>> > place for it than in the help menu esspecially on OSX where about
>> > isn't even in the help menu (I haven't removed the menu items yet  am
>> > interested to hear other peoples thoughts on whether it is used often
>> > enough to keep it in the main menu bar as well) due to this the code
>> > is currently in 2 places.
>> > I have also changed the about dialog (and version info from the about
>> > box) change to use the currently running version of wxwidgets rather
>> > than the version that kicad was built with unfortunately this is not
>> > possible with boost
>> >
>> > 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] About dialog

[Kaspar Emanuel]

Why doesn't the version in the about dialog actually give the versions that
are announced e.g. 4.0.2?

On 1 March 2016 at 10:19, Simon Wells  wrote:

> Removed the menu option from help in this version of the patch.
>
> On Tue, Mar 1, 2016 at 7:45 AM, Simon Wells  wrote:
> > Attached is a patch that modifies a few things in the About dialog, a
> > screenshot with old and new is also attached
> >
> > It removes the horizontal rule which is redundant due to the auinotebook
> > Adds Copy Version Info to the about box which i think is a better
> > place for it than in the help menu esspecially on OSX where about
> > isn't even in the help menu (I haven't removed the menu items yet  am
> > interested to hear other peoples thoughts on whether it is used often
> > enough to keep it in the main menu bar as well) due to this the code
> > is currently in 2 places.
> > I have also changed the about dialog (and version info from the about
> > box) change to use the currently running version of wxwidgets rather
> > than the version that kicad was built with unfortunately this is not
> > possible with boost
> >
> > 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] Pcbnew delete hot key behavior.

[Bernhard Stegmaier]

On 2016-02-29 21:29, Wayne Stambaugh wrote:

On 2/29/2016 3:25 PM, Tiger12506 wrote:

I'm always accidentally deleting components when trying to cleanup a
track that i didn't route correctly.

I don't know if one is a good idea over the other, but I can certainly
understand why someone would think that.


Perhaps, but Ctrl-Z is much faster than selecting the track tool,
deleting track(s), selecting the previous tool your were using to 
resume

your work just to prevent accidental deletes.


Of course, but that doesn't solve the original problem of deleting the
right thing.

So, this might end up in something like
Delete => Wrong => Ctrl-Z => Move mouse a little => Delete => Still 
Wrong

=> Ctrl-Z => Damn, move again => ...


Regards,
Bernhard

___
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] About dialog

[Simon Wells]

Removed the menu option from help in this version of the patch.

On Tue, Mar 1, 2016 at 7:45 AM, Simon Wells  wrote:
> Attached is a patch that modifies a few things in the About dialog, a
> screenshot with old and new is also attached
>
> It removes the horizontal rule which is redundant due to the auinotebook
> Adds Copy Version Info to the about box which i think is a better
> place for it than in the help menu esspecially on OSX where about
> isn't even in the help menu (I haven't removed the menu items yet  am
> interested to hear other peoples thoughts on whether it is used often
> enough to keep it in the main menu bar as well) due to this the code
> is currently in 2 places.
> I have also changed the about dialog (and version info from the about
> box) change to use the currently running version of wxwidgets rather
> than the version that kicad was built with unfortunately this is not
> possible with boost
>
> Simon


kicad-about_v2.patch
Description: Binary data
___
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] 3D refactor

[Mário Luzeiro]

> I'd also appreciate some help from anyone on the zoom function for the
> 3D preview pane. The zoom works on Linux when using the mouse scroll
> wheel but in MSWin I can only change the viewing angle, not the zoom. On
> OSX I have no idea what the status is for zooming the model.

Hi Cirilo,

Looks like it was an old know wxWidgets issue, I fixed at:
http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/revision/5897

I found it here:
https://github.com/KiCad/kicad-source-mirror/blob/a9427f899926155e48cab93187415710abc5438a/3d-viewer/3d_frame.cpp#L220

In any case, in my windows laptop, the touchpad is not able to scrool.. but. I 
think it is some particularity of this windows/laptop...
I tested with a mouse and it worked.

Mario Luzeiro
___
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] KiCad GUI Translation HOWTO error (docs.kicad-pcb.org)

[Nick Østergaard]

2016-03-01 8:59 GMT+01:00 Marco Ciampa :
> On Wed, Feb 24, 2016 at 02:06:47PM +0100, Nick Østergaard wrote:
>> Remember that that menu entry is different in the 4.0 series and the
>> latest product. legacy versus defualt.
>>
>> @Marco, I would like to know if the 4.0 branch on kicad-i18n is
>> aligned with he 4.0 series of kicad, I did not check it.  If it is
>> aligned with the 4.0 series, we can safely tag it for the new release,
>> but we can wait a bit if there are some translators that want a bit
>> more time to finish the translations int hat branch for 4.0.2.
>
> Sorry ... saw this mail only now. What do you mean?
>
> If you are asking me if I updated the .po files for all the languages (if
> I do it from time to time) the answer is no.
>
> The reason is this: I have written a little script left on the root of
> the i18n repo that could be used (without arguments) to update all the po
> files of all languages (I usually run it with the language argument to
> update only that specific language).
>
> BUT if I run it for all languages I'll create a conflict if someone is,
> at the same time, updating his language po file, so I do it only after
> being warned translators some days before I do it (I've done it just one
> time).

No, this is not what I am asking. The po file should only be updated
by the respective translator for the given language.

> IMHO when the (strings of the) program freeze for a few days for a
> release, that is a good moment to fire it, warning translators in advance
> of course, to let translators see if there are strings left to translate
> / update.
>
> If there is somewhere a "release procedure flowchart", this "standard
> translation freeze procedure" sequence could be added to it.

Yeah, I am working on defining a better aligned release proposal, such
that the translators have a chance to complete their translations
before the actual release.

But this time, I merged master into the 4.0 branch and tagged it
4.0.2, this looked to be the most update version when loading in kicad
4.0.2.

>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> ++
> | GNU/Linux User  #78271 |
> | FSFE fellow   #364 |
> ++
>
>
> ___
> 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] KiCad GUI Translation HOWTO error (docs.kicad-pcb.org)

[Marco Ciampa]

On Wed, Feb 24, 2016 at 02:06:47PM +0100, Nick Østergaard wrote:
> Remember that that menu entry is different in the 4.0 series and the
> latest product. legacy versus defualt.
> 
> @Marco, I would like to know if the 4.0 branch on kicad-i18n is
> aligned with he 4.0 series of kicad, I did not check it.  If it is
> aligned with the 4.0 series, we can safely tag it for the new release,
> but we can wait a bit if there are some translators that want a bit
> more time to finish the translations int hat branch for 4.0.2.

Sorry ... saw this mail only now. What do you mean?

If you are asking me if I updated the .po files for all the languages (if
I do it from time to time) the answer is no.

The reason is this: I have written a little script left on the root of
the i18n repo that could be used (without arguments) to update all the po
files of all languages (I usually run it with the language argument to
update only that specific language).

BUT if I run it for all languages I'll create a conflict if someone is,
at the same time, updating his language po file, so I do it only after
being warned translators some days before I do it (I've done it just one
time).

IMHO when the (strings of the) program freeze for a few days for a
release, that is a good moment to fire it, warning translators in advance
of course, to let translators see if there are strings left to translate
/ update.

If there is somewhere a "release procedure flowchart", this "standard
translation freeze procedure" sequence could be added to it.

--


Marco Ciampa

I know a joke about UDP, but you might not get it.

++
| GNU/Linux User  #78271 |
| FSFE fellow   #364 |
++


___
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