[Kicad-developers] eeschema inconsistency between symbols and sheet blocks move...

[Mark Roszko]

Is it intentional in EESchema that "sheet blocks" do not hide the pin
text on move but symbols do? Moving sheet blocks is incredibly laggy
right now due to the text redrawing with the cursor. I think I
remember way back that JP fixed the symbols to hide the text.


-- 
Mark

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

Re: [Kicad-developers] Autosave BS

[Clemens Koller]

Hello, Chris!

Thank you for considering crashes + loss of data/autosaves as *very* *serious* 
issue!

Crashes with data-loss and "no idea what I changed exactly since the last 
manual or autosave" happens to me in Mr P**S way too often and this is the 
*main* reason to migrate to KiCad being debug-friendly.


My suggestions:

1. Never ever delete something automatically - even not when the program closes 
successfully!

2. Keep the autosaved stuff with the design name + a timestamp in the filename.

3. Super feature: Remember the very last design step which was done (i.e. the 
Undo buffers) and save it to the file as well to be able to know where to 
continue and to be able to trigger a potential bug again by repeating the last 
step.

4. Store the autosave optionally in a hidden folder to avoid confusion with 
regular saved files. Confusion might lead to data-loss when operator is tired 
after routing a 484 ball FPGA.

5. Assist in cleaning up old autosaved data - use a dialog with a clear warning 
what will be deleted and ask for a confirmation.

Having a design error caused by a software crash can cost more than 4TB of 
Harddisk space.


Regards,

Clemens


On 2017-01-24 00:26, Chris Pavlina wrote:
> I'm talking to someone on IRC right now who lost two hours of routing
> because pcbnew crashed, then deleted his autosave file before he could
> make use of it. We need to put some new efforts into:
> 
> 1. Never delete autosave data. He may have accidentally saved the board
> before loading the autosave, I'm not sure - pcbnew deletes autosave when
> saving - but there should be some proper protection against this.
> 
> 2. Never overwrite potentially useful autosave data - if pcbnew is
> reloaded, a previous autosave shouldn't be deleted either. It should
> only be valid to delete autosave data if the board has not been modified
> since the autosave was made.
> 
> 3. Better recovery UI when loading after a crash.
> 
> It may be necessary to record in the autosave file which run of pcbnew
> it was created in (timestamp at startup?) to distinguish between old
> autosave data from a previous run (possible recovery source) and data
> from the current run (may be overwritten).
> 
> I haven't completely thought this through yet, just starting a thread
> for discussion. This is definitely a problem we need to do something
> about.
> 
> -- Chris
> 
> ___
> 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] Autosave BS

[Nox]

Some other program simply uses multiple autosaves. Although this is not 
the smartest solution it is relative effective and allow for some 
retracing the steps as well.



Am 24.01.2017 um 00:26 schrieb Chris Pavlina:

I'm talking to someone on IRC right now who lost two hours of routing
because pcbnew crashed, then deleted his autosave file before he could
make use of it. We need to put some new efforts into:

1. Never delete autosave data. He may have accidentally saved the board
before loading the autosave, I'm not sure - pcbnew deletes autosave when
saving - but there should be some proper protection against this.

2. Never overwrite potentially useful autosave data - if pcbnew is
reloaded, a previous autosave shouldn't be deleted either. It should
only be valid to delete autosave data if the board has not been modified
since the autosave was made.

3. Better recovery UI when loading after a crash.

It may be necessary to record in the autosave file which run of pcbnew
it was created in (timestamp at startup?) to distinguish between old
autosave data from a previous run (possible recovery source) and data
from the current run (may be overwritten).

I haven't completely thought this through yet, just starting a thread
for discussion. This is definitely a problem we need to do something
about.

-- Chris

___
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] Autosave BS

[Simon Wells]

It probably wouldn't be too bad, if each file was timestamped, and
then deleted if/when kicad exits cleanly, therefore unless one has a
very crashy kicad there should be very few autosaves and very few
needed. If you exit kicad cleanly and then want the autosave well
thats user fault.

On 24 January 2017 at 12:26, Chris Pavlina  wrote:
> I'm talking to someone on IRC right now who lost two hours of routing
> because pcbnew crashed, then deleted his autosave file before he could
> make use of it. We need to put some new efforts into:
>
> 1. Never delete autosave data. He may have accidentally saved the board
> before loading the autosave, I'm not sure - pcbnew deletes autosave when
> saving - but there should be some proper protection against this.
>
> 2. Never overwrite potentially useful autosave data - if pcbnew is
> reloaded, a previous autosave shouldn't be deleted either. It should
> only be valid to delete autosave data if the board has not been modified
> since the autosave was made.
>
> 3. Better recovery UI when loading after a crash.
>
> It may be necessary to record in the autosave file which run of pcbnew
> it was created in (timestamp at startup?) to distinguish between old
> autosave data from a previous run (possible recovery source) and data
> from the current run (may be overwritten).
>
> I haven't completely thought this through yet, just starting a thread
> for discussion. This is definitely a problem we need to do something
> about.
>
> -- Chris
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] Autosave BS

[Chris Pavlina]

I'm talking to someone on IRC right now who lost two hours of routing
because pcbnew crashed, then deleted his autosave file before he could
make use of it. We need to put some new efforts into:

1. Never delete autosave data. He may have accidentally saved the board
before loading the autosave, I'm not sure - pcbnew deletes autosave when
saving - but there should be some proper protection against this.

2. Never overwrite potentially useful autosave data - if pcbnew is
reloaded, a previous autosave shouldn't be deleted either. It should
only be valid to delete autosave data if the board has not been modified
since the autosave was made.

3. Better recovery UI when loading after a crash.

It may be necessary to record in the autosave file which run of pcbnew
it was created in (timestamp at startup?) to distinguish between old
autosave data from a previous run (possible recovery source) and data
from the current run (may be overwritten).

I haven't completely thought this through yet, just starting a thread
for discussion. This is definitely a problem we need to do something
about.

-- Chris

___
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] Current state of ActionPlugin

[Jean-Samuel Reynaud]

> Jean-Samuel, thanks, and please carefully test this rev, to be sure I did not 
> break anything.
> 
It look to work as I tested it before. I'm gonna use it more to see if
something was broken.
On same time, I prepare some examples.


___
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] mousewheelpan + ctrl = zooming

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

Hi Brano and Orson!

Code of the zooming was not modified in this patch. But I noticed, that
there is present MAC-specific block:

common/view/wx_view_controls.cpp (+147):
>
> #ifdef __WXMAC__
> // The following is to support Apple pointer devices (MagicMouse &
> // Macbook touchpad), which send events more frequently, but with
> smaller
> // wheel rotation.
> //
> // It should not break other platforms, but I prefer to be safe
> than
> // sorry. If you find a device that behaves in the same way on
> another
> // platform, feel free to remove #ifdef directives.
> if( timeDiff > 0 && timeDiff < 100 && std::abs( rotation ) < 20 )
> {
> aEvent.Skip();
> return;
> }
> #endif
>

Maybe is problem in it?

--
Regards, Konstantin.

2017-01-23 11:38 GMT+02:00 Brano Panak :

> Hi Orson,
>
> this occurs when touchpad panning enabled. When TP panning disabled wheel
> works ok (withou need to push ctrl).
>
> When TP panning enabled it zoom in work ok. When zooming out it look to me
> that sw zooms out and immediately zooms in again.
>
> I am using wireless apple mouse which has  both (vertical and horizontal)
> "wheels".
>
> When trying to zoom in/out with ctrl+ horizontal "wheel" all works ok.
>
> If i remember correctly this was working ok, befor latest "wheel" patch.
>
> regards
>
> Brano
>
> On 20/01/17 08:52, Maciej Sumiński wrote:
>
> Hi Brano,
>
> Are the problems occurring when touchpad panning is enabled? Is
> everything fine once you disable it?
>
> Would you give more details about zoom out being problematic? Does it
> zoom out too quickly, is it choppy?
>
> Regards,
> Orson
>
> On 01/19/2017 10:52 PM, Brano Panak wrote:
>
> Today i checked behavior on osx with version: (2017-01-18 revision
> 2eb840b)-master
> and behavior in pcbnew during zooming with wheel+ctrl(cmd on mac) on
> apple mouse  is very erratic.
>
> Zoom in works ok, zoom out is very problematic.
>
> Eeschema looks ok, pcbnew with zooming and scrolling on touchpad with 2
> fingers looks good.
>
> regards
>
> Brano
>
>
> On 17/01/17 18:17, Константин Барановский wrote:
>
> In attachment placed new patch, that contains both previous patches
> and in mousewheelpan mode, with pressed Shift key, does horizontal
> scrolling.
>
> So, in common, we will get:
>
> * mousewheelpan disabled:
> - mousewheel = zooming;
> - mousewheel + ctrl = horizontal scrolling;
> - mousewheel + shift = vertical scrolling;
>
> * mousewheelpan enabled:
> - touchpad two finger scrolling = pan;
> - mousewheel = vertical scrolling;
> -> mousewheel (touchpad two finger scrolling) + ctrl = zooming;
> -> mousewheel (touchpad two finger scrolling)  + shift = horizontal
> scrolling.
>
> This patch adds two last options and decreases the pan step in
> 3d-viewer to be more comfortable.
> It works in eeschema, pcbnew (legacy, openGL, cairo), 3d-viewer,
> gerbview.
>
> 2017-01-17 11:27 GMT+02:00 Maciej Sumiński 
>  
> >:
>
> Hi Konstantin,
>
> Your patches were not ignored, the problem was neither me nor Wayne
> could fully apply the patches in their original version. Thank you
> for
> correcting this.
>
> I still hold my previous remark about wheel scroll and shift+wheel
> scroll doing the same thing when touchpad panning is enabled.
> Instead,
> shift+wheel scroll could perform horizontal scrolling in touchpad
> panning mode.
>
> Regards,
> Orson
>
> On 01/16/2017 07:38 PM, Константин Барановский wrote:
> > Thank you, Wayne, for your response. I'm attached the checked
> patches.
> >
> > 2017-01-16 20:07 GMT+02:00 Wayne Stambaugh   >:
> >
> >> You are not being ignored.  I can't speak for all of the lead
> developers
> >> but I've been really busy so pretty much everyone has been getting
> >> ignored by me.  It's not intentional, it's just the reality of my
> >> current work load.
> >>
> >> Patch is giving me an unexpected eof with
> 3d_viewer-pan_step.patch.
> >>
> >> Did you address Bernhard's concern about the behavior of the GAL
> >> canvases as well as the legacy canvas?  I don't remember seeing
> anything
> >> but I may have missed it.
> >>
> >> On 1/16/2017 11:29 AM, Константин Барановский wrote:
> >>> Hello. I'm sorry for disturbing you, but I'm not understand
> why my
> >>> messages are ignored. Proposed feature not needed for no one,
> except me?
> >>> Or I'm made something wrong? Please, give any comment.
> >>>
> >>> 2017-01-06 12:03 GMT+02:00 Константин Барановский
> >>>   
> 

Re: [Kicad-developers] Dialog SetFocus patches for OSX

[Wayne Stambaugh]

Diogo,

Your patches have been pushed to the master branch.  Thank you for your
contribution to KiCad.

Cheers,

Wayne

On 1/22/2017 5:52 PM, Diogo Condeço wrote:
> Hi all,
> 
> I've attached 2 patches for some SetFocus optimisations on Macos. Tested
> also on Linux where there wasn't the issue, and it is still ok. This was
> a macos specific problem...
> 
> 0001 fixes the find dialog and pad_properties dialog on pcbnew
> 0002 fixes add_component dialog on eeschema
> 
> I've used the recommended wxFB3.5-RC1
> (https://github.com/marekr/wxFormBuilder.git
> ) to modify the dialogs.
> Which isn't also working on macos making it hard to use it...
> 
> 
> 
> -- 
> Diogo Condeço
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] Dialog SetFocus patches for OSX

[Diogo Condeço]

Once I've finished the edit value/reference dialog in eeschema, I will try
to get back to it.

Thanks.

On Mon, Jan 23, 2017 at 3:10 PM, Wayne Stambaugh 
wrote:

> The focus loss doesn't happen on windows so this must be an osx specific
> behavior.  I'll apply the patches since they address the initial focus
> issue on osx.
>
> On 1/23/2017 10:01 AM, Simon Wells wrote:
> > Just a comment on the pad properties dialog, it works fine on init but
> > the field loses focus when i mouse over the "preview" part of the
> > dialog... is there a way to prevent this? (it should really only lose
> > focus if someone clicks in the preview area) although i am unsure of
> > the intricacies of wx and osx as to whether you unfocused zooming and
> > panning and such work.
> >
> > On 23 January 2017 at 12:34, Wayne Stambaugh 
> wrote:
> >> Would one of our osx devs test these patches and let me know if I should
> >> commit them.  I don't see any coding policy violations so as long as
> >> they fix the problems on osx then I will commit them.
> >>
> >> Thanks,
> >>
> >> Wayne
> >>
> >> On 1/22/2017 5:52 PM, Diogo Condeço wrote:
> >>> Hi all,
> >>>
> >>> I've attached 2 patches for some SetFocus optimisations on Macos.
> Tested
> >>> also on Linux where there wasn't the issue, and it is still ok. This
> was
> >>> a macos specific problem...
> >>>
> >>> 0001 fixes the find dialog and pad_properties dialog on pcbnew
> >>> 0002 fixes add_component dialog on eeschema
> >>>
> >>> I've used the recommended wxFB3.5-RC1
> >>> (https://github.com/marekr/wxFormBuilder.git
> >>> ) to modify the dialogs.
> >>> Which isn't also working on macos making it hard to use it...
> >>>
> >>>
> >>>
> >>> --
> >>> Diogo Condeço
> >>>
> >>>
> >>> ___
> >>> 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
>



-- 
Diogo Condeço
___
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] Current state of ActionPlugin

[Nick Østergaard]

Ok, feel free to remind me later then.

2017-01-23 14:30 GMT+01:00 Wayne Stambaugh :
> On 1/23/2017 8:30 AM, jp charras wrote:
>> Le 23/01/2017 à 14:19, Nick Østergaard a écrit :
>>> Should it be enabled in the windows nightlies now or should we wait a bit?
>>>
>>
>> Before enabling it, please wait for a few tests from devs and J-S.
>> Perhaps also a bit of doc and 2 or 3 samples which do not delete anything 
>> (could be in demos) is
>> welcome.
>> This is in the J-S Reynaud's hands.
>
> I concur.  I think it would be wise to allow our python devs to test it
> for a while be for we make it available for general testing.
>
>>
>>
>>> 2017-01-23 14:13 GMT+01:00 jp charras :
 Le 18/01/2017 à 18:00, Jean-Samuel Reynaud a écrit :
> Just to know if this patch is now acceptable ? Did you plan to commit it ?
>
> Thanks,
> Le 17/01/2017 à 19:46, Jean-Samuel Reynaud a écrit :
>>> yes i was trying to subtly imply that :)
>> ok, find attached the patch with the about box updated ;)
>>
>> Regards,
>>

 I committed the patch ( with fixes, see comments) in rev:
 2b5769c0a8568e421c2152177a8f1c27d9bf9cb5

 Jean-Samuel, thanks, and please carefully test this rev, to be sure I did 
 not break anything.

 The action plugin feature must be currently seen as an experimental 
 feature, for developers, because
 it can easily break a board.
 It is enabled if the option -DKICAD_SCRIPTING_ACTION_MENU=ON is added to 
 the cmake command line.

 I am thinking this feature need to be tested, and enhancements added 
 (especially if a script deletes
 a board item), and this is the reason I see it as currently experimental.

 However, now it exists, it can be tested.


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

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

Re: [Kicad-developers] Dialog SetFocus patches for OSX

[Simon Wells]

it seems this is just as broke with or without the patch so this patch
can be pushed, will need to check into why its stealing focus on mouse
over though

On 24 January 2017 at 04:01, Simon Wells  wrote:
> Just a comment on the pad properties dialog, it works fine on init but
> the field loses focus when i mouse over the "preview" part of the
> dialog... is there a way to prevent this? (it should really only lose
> focus if someone clicks in the preview area) although i am unsure of
> the intricacies of wx and osx as to whether you unfocused zooming and
> panning and such work.
>
> On 23 January 2017 at 12:34, Wayne Stambaugh  wrote:
>> Would one of our osx devs test these patches and let me know if I should
>> commit them.  I don't see any coding policy violations so as long as
>> they fix the problems on osx then I will commit them.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 1/22/2017 5:52 PM, Diogo Condeço wrote:
>>> Hi all,
>>>
>>> I've attached 2 patches for some SetFocus optimisations on Macos. Tested
>>> also on Linux where there wasn't the issue, and it is still ok. This was
>>> a macos specific problem...
>>>
>>> 0001 fixes the find dialog and pad_properties dialog on pcbnew
>>> 0002 fixes add_component dialog on eeschema
>>>
>>> I've used the recommended wxFB3.5-RC1
>>> (https://github.com/marekr/wxFormBuilder.git
>>> ) to modify the dialogs.
>>> Which isn't also working on macos making it hard to use it...
>>>
>>>
>>>
>>> --
>>> Diogo Condeço
>>>
>>>
>>> ___
>>> 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] Dialog SetFocus patches for OSX

[Wayne Stambaugh]

The focus loss doesn't happen on windows so this must be an osx specific
behavior.  I'll apply the patches since they address the initial focus
issue on osx.

On 1/23/2017 10:01 AM, Simon Wells wrote:
> Just a comment on the pad properties dialog, it works fine on init but
> the field loses focus when i mouse over the "preview" part of the
> dialog... is there a way to prevent this? (it should really only lose
> focus if someone clicks in the preview area) although i am unsure of
> the intricacies of wx and osx as to whether you unfocused zooming and
> panning and such work.
> 
> On 23 January 2017 at 12:34, Wayne Stambaugh  wrote:
>> Would one of our osx devs test these patches and let me know if I should
>> commit them.  I don't see any coding policy violations so as long as
>> they fix the problems on osx then I will commit them.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 1/22/2017 5:52 PM, Diogo Condeço wrote:
>>> Hi all,
>>>
>>> I've attached 2 patches for some SetFocus optimisations on Macos. Tested
>>> also on Linux where there wasn't the issue, and it is still ok. This was
>>> a macos specific problem...
>>>
>>> 0001 fixes the find dialog and pad_properties dialog on pcbnew
>>> 0002 fixes add_component dialog on eeschema
>>>
>>> I've used the recommended wxFB3.5-RC1
>>> (https://github.com/marekr/wxFormBuilder.git
>>> ) to modify the dialogs.
>>> Which isn't also working on macos making it hard to use it...
>>>
>>>
>>>
>>> --
>>> Diogo Condeço
>>>
>>>
>>> ___
>>> 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] Signal handlers for SINGLE_TOP and KICAD

[Simon Wells]

this seems broken on pcbnew when python is enabled at least on osx. getting

Air:~ simon$ /Volumes/simon/kicad-app/bin/kicad.app/Contents/MacOS/kicad

^C^C^C^C^C^C^C^C^C^C^C^C^C^C^CError in sys.exitfunc:

Traceback (most recent call last):

  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py",
line 13, in _run_exitfuncs

def _run_exitfuncs():

KeyboardInterrupt

even after i close pcbnew and open eeschema it still doesn't work

On 12 January 2017 at 13:19, John Beard  wrote:
> And here is the patch with the class name in capitals and a class
> comment block. Sorry!
>
> On Wed, Jan 11, 2017 at 11:26 PM, John Beard  wrote:
>> Hi,
>>
>> None of the KiCad programs appear to implement any signal handlers.
>> This means that some of them (e.g. pcbnew) don't respond to things
>> like SIGINT generated by a Ctrl-C in the console its running from
>> (very annoying when running up and down repeatedly), and others (e.g.
>> eeschema) terminate immediately, rather than shutting down.
>>
>> The attached patch implements a graceful shutdown on SIGINT for all of
>> the SINGLE_TOP programs as well as KICAD.
>>
>> I have put it in a separate class (static members because the handlers
>> have to be that way), so that 1) the same handler can be used in both
>> places and 2) in future if the signal handlers grow, any complexity is
>> contained.
>>
>> I have tested this on Linux, and since it's using the standard C++
>>  stuff, I assume it works (or at least compiles) on all
>> platforms, but I can't prove it!
>>
>> Cheers,
>>
>> John
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] Dialog SetFocus patches for OSX

[Simon Wells]

Just a comment on the pad properties dialog, it works fine on init but
the field loses focus when i mouse over the "preview" part of the
dialog... is there a way to prevent this? (it should really only lose
focus if someone clicks in the preview area) although i am unsure of
the intricacies of wx and osx as to whether you unfocused zooming and
panning and such work.

On 23 January 2017 at 12:34, Wayne Stambaugh  wrote:
> Would one of our osx devs test these patches and let me know if I should
> commit them.  I don't see any coding policy violations so as long as
> they fix the problems on osx then I will commit them.
>
> Thanks,
>
> Wayne
>
> On 1/22/2017 5:52 PM, Diogo Condeço wrote:
>> Hi all,
>>
>> I've attached 2 patches for some SetFocus optimisations on Macos. Tested
>> also on Linux where there wasn't the issue, and it is still ok. This was
>> a macos specific problem...
>>
>> 0001 fixes the find dialog and pad_properties dialog on pcbnew
>> 0002 fixes add_component dialog on eeschema
>>
>> I've used the recommended wxFB3.5-RC1
>> (https://github.com/marekr/wxFormBuilder.git
>> ) to modify the dialogs.
>> Which isn't also working on macos making it hard to use it...
>>
>>
>>
>> --
>> Diogo Condeço
>>
>>
>> ___
>> 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] Current state of ActionPlugin

[Wayne Stambaugh]

On 1/23/2017 8:30 AM, jp charras wrote:
> Le 23/01/2017 à 14:19, Nick Østergaard a écrit :
>> Should it be enabled in the windows nightlies now or should we wait a bit?
>>
> 
> Before enabling it, please wait for a few tests from devs and J-S.
> Perhaps also a bit of doc and 2 or 3 samples which do not delete anything 
> (could be in demos) is
> welcome.
> This is in the J-S Reynaud's hands.

I concur.  I think it would be wise to allow our python devs to test it
for a while be for we make it available for general testing.

> 
> 
>> 2017-01-23 14:13 GMT+01:00 jp charras :
>>> Le 18/01/2017 à 18:00, Jean-Samuel Reynaud a écrit :
 Just to know if this patch is now acceptable ? Did you plan to commit it ?

 Thanks,
 Le 17/01/2017 à 19:46, Jean-Samuel Reynaud a écrit :
>> yes i was trying to subtly imply that :)
> ok, find attached the patch with the about box updated ;)
>
> Regards,
>
>>>
>>> I committed the patch ( with fixes, see comments) in rev:
>>> 2b5769c0a8568e421c2152177a8f1c27d9bf9cb5
>>>
>>> Jean-Samuel, thanks, and please carefully test this rev, to be sure I did 
>>> not break anything.
>>>
>>> The action plugin feature must be currently seen as an experimental 
>>> feature, for developers, because
>>> it can easily break a board.
>>> It is enabled if the option -DKICAD_SCRIPTING_ACTION_MENU=ON is added to 
>>> the cmake command line.
>>>
>>> I am thinking this feature need to be tested, and enhancements added 
>>> (especially if a script deletes
>>> a board item), and this is the reason I see it as currently experimental.
>>>
>>> However, now it exists, it can be tested.
>>>
>>>
>>> --
>>> 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] Current state of ActionPlugin

[jp charras]

Le 23/01/2017 à 14:19, Nick Østergaard a écrit :
> Should it be enabled in the windows nightlies now or should we wait a bit?
> 

Before enabling it, please wait for a few tests from devs and J-S.
Perhaps also a bit of doc and 2 or 3 samples which do not delete anything 
(could be in demos) is
welcome.
This is in the J-S Reynaud's hands.


> 2017-01-23 14:13 GMT+01:00 jp charras :
>> Le 18/01/2017 à 18:00, Jean-Samuel Reynaud a écrit :
>>> Just to know if this patch is now acceptable ? Did you plan to commit it ?
>>>
>>> Thanks,
>>> Le 17/01/2017 à 19:46, Jean-Samuel Reynaud a écrit :
> yes i was trying to subtly imply that :)
 ok, find attached the patch with the about box updated ;)

 Regards,

>>
>> I committed the patch ( with fixes, see comments) in rev:
>> 2b5769c0a8568e421c2152177a8f1c27d9bf9cb5
>>
>> Jean-Samuel, thanks, and please carefully test this rev, to be sure I did 
>> not break anything.
>>
>> The action plugin feature must be currently seen as an experimental feature, 
>> for developers, because
>> it can easily break a board.
>> It is enabled if the option -DKICAD_SCRIPTING_ACTION_MENU=ON is added to the 
>> cmake command line.
>>
>> I am thinking this feature need to be tested, and enhancements added 
>> (especially if a script deletes
>> a board item), and this is the reason I see it as currently experimental.
>>
>> However, now it exists, it can be tested.
>>
>>
>> --
>> 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
> 


-- 
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] Current state of ActionPlugin

[Nick Østergaard]

Should it be enabled in the windows nightlies now or should we wait a bit?

2017-01-23 14:13 GMT+01:00 jp charras :
> Le 18/01/2017 à 18:00, Jean-Samuel Reynaud a écrit :
>> Just to know if this patch is now acceptable ? Did you plan to commit it ?
>>
>> Thanks,
>> Le 17/01/2017 à 19:46, Jean-Samuel Reynaud a écrit :
 yes i was trying to subtly imply that :)
>>> ok, find attached the patch with the about box updated ;)
>>>
>>> Regards,
>>>
>
> I committed the patch ( with fixes, see comments) in rev:
> 2b5769c0a8568e421c2152177a8f1c27d9bf9cb5
>
> Jean-Samuel, thanks, and please carefully test this rev, to be sure I did not 
> break anything.
>
> The action plugin feature must be currently seen as an experimental feature, 
> for developers, because
> it can easily break a board.
> It is enabled if the option -DKICAD_SCRIPTING_ACTION_MENU=ON is added to the 
> cmake command line.
>
> I am thinking this feature need to be tested, and enhancements added 
> (especially if a script deletes
> a board item), and this is the reason I see it as currently experimental.
>
> However, now it exists, it can be tested.
>
>
> --
> 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] Current state of ActionPlugin

[jp charras]

Le 18/01/2017 à 18:00, Jean-Samuel Reynaud a écrit :
> Just to know if this patch is now acceptable ? Did you plan to commit it ?
> 
> Thanks,
> Le 17/01/2017 à 19:46, Jean-Samuel Reynaud a écrit :
>>> yes i was trying to subtly imply that :)
>> ok, find attached the patch with the about box updated ;)
>>
>> Regards,
>>

I committed the patch ( with fixes, see comments) in rev:
2b5769c0a8568e421c2152177a8f1c27d9bf9cb5

Jean-Samuel, thanks, and please carefully test this rev, to be sure I did not 
break anything.

The action plugin feature must be currently seen as an experimental feature, 
for developers, because
it can easily break a board.
It is enabled if the option -DKICAD_SCRIPTING_ACTION_MENU=ON is added to the 
cmake command line.

I am thinking this feature need to be tested, and enhancements added 
(especially if a script deletes
a board item), and this is the reason I see it as currently experimental.

However, now it exists, it can be tested.


-- 
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] issues in GAL mode with event manager.

[jp charras]

Le 23/01/2017 à 12:02, Maciej Sumiński a écrit :
> Hi Jean-Pierre,
> 
> Both problems should be already fixed.
> 
> Regards,
> Orson
> 

Hi Orson,
They are fixed.

I am guessing it was not so easy to fix.
So thanks for this well done work.


-- 
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] issues in GAL mode with event manager.

[Maciej Sumiński]

Hi Jean-Pierre,

Both problems should be already fixed.

Regards,
Orson

On 01/20/2017 09:57 AM, jp charras wrote:
> Le 20/01/2017 à 09:46, Maciej Sumiński a écrit :
>> Hi Jean-Pierre,
>>
>> Thank you for the report. I already see the first issue, the fix is in
>> progress. I will check the second problem later as well.
>>
>> Regards,
>> Orson
> 
> Thanks.
> FYI, in my last commit, I modified CONTEXT_TRACK_WIDTH_MENU::EventHandler to 
> accept unexpected event
> IDs, so the strange track width change does not happen now.
> 
>>
>> On 01/18/2017 08:06 PM, jp charras wrote:
>>> Hi Orson and Tomasz,
>>>
>>> Sorry to give you a bit of work, but I found issues which are outside my 
>>> knowledge.
>>>
>>> Recently, a grid sub-menu was added to the router tool context menu.
>>> And I found issues when using it.
>>> But issues are due to the events are managed in GAL mode, not due to this 
>>> sub-menu.
>>>
>>> First (both on W7 and Linux):
>>> The submenu exists in other context menus, and does not show a problem.
>>> Especially, the current grid selection appears checked in context menu grid 
>>> list, but not in the
>>> ROUTER_TOOL_MENU context menu.
>>> First time I saw that, I was thinking it is just a cosmetic issue.
>>> But after more investigations, I am pretty sure this is a much more serious 
>>> issue.
>>>
>>> Second, but only on Windows:
>>> During investigations, I found a much more annoying behavior in GAL 
>>> dispatch events.
>>> This happens only on W7 (32bits for me), not on Linux. (I don't know on OSX)
>>>
>>> I saw EventHandler( const wxMenuEvent& aEvent ) living in many menus are 
>>> called at least once,
>>> regardless the menuid of the corresponding menu.
>>>
>>> I did not tested (obviously) all menus, but I tested:
>>> CONTEXT_TRACK_WIDTH_MENU::EventHandler
>>> ZOOM_MENU::EventHandler
>>> GRID_MENU::EventHandler
>>> (just add in these methods a call to a wxMessageBox: the result is very 
>>> interesting)
>>>
>>> In context menus where both zoom and grid menu exist, and when you select a 
>>> new grid or zoom, zoom
>>> and grid EventHandler are called, regardless the menu clicked, then the 
>>> right menu is called a
>>> second time.
>>> (Therefore the right handler is called twice. Usually, this is not a 
>>> problem, but...)
>>>
>>> Especially, the CONTEXT_TRACK_WIDTH_MENU::EventHandler is called when a new 
>>> grid is selected from
>>> the router tool context menu.
>>> And because the menuid is not expected in this handler, the width of tracks 
>>> created after this
>>> selection is very strange.
>>>
>>> (I have a fix for this menu in one of my working copy, but the best is to 
>>> fix the source of issues)
>>>
>>>
>>> Besides:
>>> in many case, assert is used, instead of wxASSERT in sources.
>>> At least on Windows, it makes the debug not usable (dbg is just closed, and 
>>> you have no trace and no
>>> message).
>>> And when you have to debug an issue which happens only on Windows, this is 
>>> a bit annoying.
>>>
>>> Thanks.
>>>
>>
>>
>>
>>
>> ___
>> 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
>>
> 
> 




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] [PATCH] Move PostCommandMenuEvent to EDA_BASE_FRAME

[Maciej Sumiński]

Hi John,

I have just merged your patch, thank you for your contribution.

Regards,
Orson

On 01/23/2017 02:11 AM, John Beard wrote:
> Hi,
> 
> This is a small patch to move PostCommandMenuEvent up to
> EDA_BASE_FRAME, from PCB_BASE_EDIT_FRAME.
> 
> This function has nothing intristic to PCB edit frames, it would apply
> to any frame. I'd like to use it for code that works in both Pcbnew
> and Cvpcb, which have EDA_BASE_FRAME as the first suitable common
> ancestor (KIWAY_PLAYER is first, but that's not really suitable for
> menu event code).
> 
> I'm submitting this ahead of the code that uses it, because it's
> logically separate and stands alone, and it touches common headers: if
> the make_unique patch goes in alongside, this will avoid a
> double-recompile for anyone pulling both at once!
> 
> Cheers,
> 
> John
> 
> 
> 
> ___
> 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
> 




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] [PATCH] C++14-style std::make_unique for C++11

[Maciej Sumiński]

Hi John,

I have just merged your patch, thank you for your contribution.

Regards,
Orson

On 01/21/2017 05:38 PM, John Beard wrote:
> Hi,
> 
> This is a patch to add std::make_unique to common.h when the C++
> standard is C++11 (which it normally is for KiCad).
> 
> This simplifies code creating std::unique_ptr's and also means you can
> generally say "never use new". It also closes a potential for
> exception-unsafety concerning temporary "new"ed objects.
> 
> It's cribbed shamelessly from its proposal for C++14
> (https://isocpp.org/files/papers/N3656.txt), and that's more or less
> exactly how my GCC (6.3.1) implements it too. I've added the GCC
> comments in for good measure.
> 
> The idea here is that when KiCad one day moves on to C++14, this file
> can be removed entirely and forgetten!
> 
> Cheers,
> 
> John
> 
> 
> 
> ___
> 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
> 




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] Group selection idea

[Kristoffer Ödmark]

> - Duplicating a group should create a new group (I'm not sure it works
> this way for the moment).

Currently duplication just copies the group, but yes, I can change so that it
appends -{num} from 1 and upwards when copying. Here I also guess that ideally
they would be a subgroup of a nested group after that. {groupname}-copies for 
example

> You can for instance
> define a group as a set of unique timestamps of the items which belong
> to it. This would also simplify the file format by not polluting the
> board entities with group information, e.g.

I am not sure I like this, the format pollution you mention is actually 
something
I want, It makes the file format easy to scan with a text editor, which is 
something
I have had to do a few times when using Kicad. But ofcourse I could probably 
change
that if it is deemed neccesary. How does timestamps work? Are they unique 
always or 
are they an indication at what time something is added/edited?

> - Add Group/Ungroup commands to the Edit menu.

Not sure I follow, do you mean the preferences menu? The one you get with the 
shortcut E?

> - if you click on a group member, the selection tool IMHO should select
> the group the member belongs to. An alternate mode (e.g. Shift+click)
> could be used to pick single elements from a group. This is the typical
> behaviour of all programs I know that support grouping (from
> Corel/Inkscape to Altium).

Hmm, yes, that seems more natural.

> - Add a shortcut to group/ungroup (e.g. Ctrl+G/Ctrl+U).
> - Add a 'merge groups' option which squashes several groups into a -
> single one.

Will look into it, although I see these as additions to a feature not yet



On 01/19/2017 02:30 PM, Tomasz Wlostowski wrote:
> On 19.01.2017 12:18, Kristoffer Ödmark wrote:
>> Hey!
>>
>> Did you have a look at the group selection patch and have any comments? :)
> 
> Hi,
> 
> Yes, but I didn't have much time. My quick observations:
> - if you click on a group member, the selection tool IMHO should select
> the group the member belongs to. An alternate mode (e.g. Shift+click)
> could be used to pick single elements from a group. This is the typical
> behaviour of all programs I know that support grouping (from
> Corel/Inkscape to Altium).
> - Add a shortcut to group/ungroup (e.g. Ctrl+G/Ctrl+U).
> - Add Group/Ungroup commands to the Edit menu.
> - Add a 'merge groups' option which squashes several groups into a -
> single one.
> - Duplicating a group should create a new group (I'm not sure it works
> this way for the moment).
> - Add a possibility to have recursive grouping. This probably means a
> bit of changes in the file format and code model. You can for instance
> define a group as a set of unique timestamps of the items which belong
> to it. This would also simplify the file format by not polluting the
> board entities with group information, e.g.
> 
> (track (timestamp A) ... )
> (track (timestamp B) ... )
> (track (timestamp C) ... )
> (track (timestamp D) ... )
> 
> // all grouping info stored in a separate section of the file which
> translates to a separate object within the BOARD.
> (groups
>   ( group (name small1) (timestamp X) ids ( A B ) )
>   ( group (name small2) (timestamp Y) ids ( C D ) )
>   ( group (name twogroupstogether) (timestamp Z) ids ( X Y ) )
> )
> 
> If you had time, you could also extend the 'append board' feature to:
> - Let the user append a board as a new group.
> - Optionally, rename the nets so that they are in a 'private' namespace
> in each appended board.
> This would be a *big* help for panelization which currently is quite
> cumbersome in Kicad.
> 
> Many thanks for your efforts,
> Tom
> 
> 
> 
>> - Kristoffer
>>
>>
>> On 2017-01-12 12:55, Tomasz Wlostowski wrote:
>>> I like it. Give me a few days to review it and I hope it will get
>>> merged. You'll also have to make the groups persistent (save to file).
>>> Recursive grouping (group of groups) would be also an advantage.
>>>
>>>
>>> Cheers,
>>> Tom
>>>
>>> Sent from my Samsung Galaxy smartphone.
>>>
>>>
>>>  Original message 
>>> From: Kristoffer Ödmark 
>>> Date: 12/01/2017 12:41 (GMT+01:00)
>>> To: kicad-developers@lists.launchpad.net
>>> Subject: Re: [Kicad-developers] Group selection idea
>>>
>>> Hey again, What would be the chances of seing this getting into the
>>> master branches on launchpad, what would I have to add/change to get it
>>> there?
>>>
>>> - Kristoffer
>>>
>>> On 2017-01-11 21:59, Kristoffer Ödmark wrote:
 Attaching Patch!

 ( Thanks Chris! )

 On 2017-01-11 20:51, Kristoffer Ödmark wrote:
> Hello!
>
> I hacked together a group selection concept looking like this:
> https://youtu.be/eJp-aJ8i0H4
>
> It can assign BOARD_ITEM to a specific group for easier selection and
> group manipulation. I am open to suggestions on changes, this is surely
> not an optimal implementation.
>
> Useful when you may want to 

Re: [Kicad-developers] [PATCH] mousewheelpan + ctrl = zooming

[Brano Panak]

Hi Orson,

this occurs when touchpad panning enabled. When TP panning disabled 
wheel works ok (withou need to push ctrl).


When TP panning enabled it zoom in work ok. When zooming out it look to 
me that sw zooms out and immediately zooms in again.


I am using wireless apple mouse which has  both (vertical and 
horizontal) "wheels".


When trying to zoom in/out with ctrl+ horizontal "wheel" all works ok.

If i remember correctly this was working ok, befor latest "wheel" patch.

regards

Brano


On 20/01/17 08:52, Maciej Sumiński wrote:

Hi Brano,

Are the problems occurring when touchpad panning is enabled? Is
everything fine once you disable it?

Would you give more details about zoom out being problematic? Does it
zoom out too quickly, is it choppy?

Regards,
Orson

On 01/19/2017 10:52 PM, Brano Panak wrote:

Today i checked behavior on osx with version: (2017-01-18 revision
2eb840b)-master
and behavior in pcbnew during zooming with wheel+ctrl(cmd on mac) on
apple mouse  is very erratic.

Zoom in works ok, zoom out is very problematic.

Eeschema looks ok, pcbnew with zooming and scrolling on touchpad with 2
fingers looks good.

regards

Brano


On 17/01/17 18:17, Константин Барановский wrote:

In attachment placed new patch, that contains both previous patches
and in mousewheelpan mode, with pressed Shift key, does horizontal
scrolling.

So, in common, we will get:

* mousewheelpan disabled:
- mousewheel = zooming;
- mousewheel + ctrl = horizontal scrolling;
- mousewheel + shift = vertical scrolling;

* mousewheelpan enabled:
- touchpad two finger scrolling = pan;
- mousewheel = vertical scrolling;
-> mousewheel (touchpad two finger scrolling) + ctrl = zooming;
-> mousewheel (touchpad two finger scrolling)  + shift = horizontal
scrolling.

This patch adds two last options and decreases the pan step in
3d-viewer to be more comfortable.
It works in eeschema, pcbnew (legacy, openGL, cairo), 3d-viewer,
gerbview.

2017-01-17 11:27 GMT+02:00 Maciej Sumiński >:

 Hi Konstantin,

 Your patches were not ignored, the problem was neither me nor Wayne
 could fully apply the patches in their original version. Thank you
for
 correcting this.

 I still hold my previous remark about wheel scroll and shift+wheel
 scroll doing the same thing when touchpad panning is enabled.
Instead,
 shift+wheel scroll could perform horizontal scrolling in touchpad
 panning mode.

 Regards,
 Orson

 On 01/16/2017 07:38 PM, Константин Барановский wrote:
 > Thank you, Wayne, for your response. I'm attached the checked
 patches.
 >
 > 2017-01-16 20:07 GMT+02:00 Wayne Stambaugh >:
 >
 >> You are not being ignored.  I can't speak for all of the lead
 developers
 >> but I've been really busy so pretty much everyone has been getting
 >> ignored by me.  It's not intentional, it's just the reality of my
 >> current work load.
 >>
 >> Patch is giving me an unexpected eof with
3d_viewer-pan_step.patch.
 >>
 >> Did you address Bernhard's concern about the behavior of the GAL
 >> canvases as well as the legacy canvas?  I don't remember seeing
 anything
 >> but I may have missed it.
 >>
 >> On 1/16/2017 11:29 AM, Константин Барановский wrote:
 >>> Hello. I'm sorry for disturbing you, but I'm not understand
why my
 >>> messages are ignored. Proposed feature not needed for no one,
 except me?
 >>> Or I'm made something wrong? Please, give any comment.
 >>>
 >>> 2017-01-06 12:03 GMT+02:00 Константин Барановский
 >>> 
 
  :
 >>>
 >>> 2016-11-23 0:22 GMT+02:00 Maciej Sumiński
 
 >>> >>:
 >>>
 >>> I could not apply the second patch, it gives me
 "unexpected end
 >>> of file
 >>> in patch" error. Would you verify the file?
 >>>
 >>>
 >>>  I downloaded both patches and checked them, they looks
 good for me.
 >>> I do not got any problems or errors.
 >>>
 >>>
 >>
 >
 >
 >
 > ___
 > 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
 
 >