[Kicad-developers] Color issues before V5

2017-10-02 Thread Jon Evans 
Hi all,

I'm currently working on refactoring SELECTION_TOOL to share code between
GerbView and Pcbnew, but I also want to know about any issues with the new
color options so that I can try to spend some time improving things before
V5.

I know about these ones:
https://bugs.launchpad.net/kicad/+bug/1670669
https://bugs.launchpad.net/kicad/+bug/1584505

Best,
Jon
___
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] Update PCB from Schematic hotkey in pcbnew and bug in schematic filename

2017-10-02 Thread Dan Green 


On Friday, September 29, 2017 at 11:32 PM, jp charras wrote:

> Le 29/09/2017 à 03:51, Dan Green a écrit :
> > Odd, on macOS the menu displays properly as the option symbol+F8. Yes I can 
> > look into tomorrow, I
> > have kicad building on a linux machine at work.
> >  
> > Looks like AddModifierToKey() in hotkeys_basic.cpp is adding an extra “Alt” 
> > to any accelerator key
> > that’s not between ‘A’ - ‘Z’.  
> > Anyone know why this is? I’ll try to figure it out tomorrow…
> >  
> > Dan
>  
> AddHotkeyName automatically adds “Alt” or "Ctrl" to a key if IS_ACCELERATOR 
> option is used.
>  
> IS_ACCELERATOR option modify the key code and is useful *only* if the "same" 
> key (like hotkeys ZOOM
> F1 and F2 and a few others) is used *both* as hotkey and accelerator, and if 
> the action is nearly
> the same but differs by using the mouse position.
> (For instance in zoom: the zoom center is the mouse position if the hotkey is 
> pressed, and the
> screen center if the menu or accelerator key is pressed).
>  
> This is due to the fact I never found a easy way (common to the 3 platforms) 
> to know if a menuitem
> was activated by a click on it or by its accelerator key to use or not the 
> mouse position.
>  
> If it is not the case (if the key is not also used as hotkey or if the mouse 
> position is not used),
> do not use IS_ACCELERATOR option that adds a SHIFT or ALT to the base key.
> Just set the key code: in this case ALT+F8 (or perhaps CTRL+F8)
>  
Thanks jp, I see what IS_ACCELERATOR is for now.  
The easy solution would be to patch AddHotkeyName() and/or AddModifierToKey() 
to disallow adding an Alt if an Alt  
already exists in the hotkey (in which case, try adding Ctrl, etc).

But thinking about this more, it seems that there are really two distinct 
actions we want to do. For example:
Begin Wire (W = hotkey) vs. switch to Wire Tool (Shift+W = accelerator/menu)

Perhaps each action needs its own entry in the *_Hotkey_List, and its own 
command event ID (e.g. there would be  
ID_BEGIN_WIRE in addition to ID_WIRE_BUTT)

From the user’s perspective, this would match the menu bar displaying Shift+W, 
vs. the WIDGET_HOTKEY_LIST  
displaying just W. An added benefit would be that it won’t be confusing to a 
user who tries to change a new hotkey  
in the preferences, and sees it showing up as having an extra Shift or Alt 
added to it in the menu bar.

Is this worthwhile to change, or is there some other layer of complexity I’m 
missing that requires us to tie the two  
actions together? I can volunteer to tackle this unless you or someone else 
would prefer.

Also on my short to-do list is to bring the hotkeys up to compliance with Mac 
OS keyboards, allowing for use of (raw) Ctrl  
for hotkeys, and calling Alt by it’s Mac name “Opt”.

thanks,
Dan
>  
> >  
> >  
> > > On Sep 28, 2017, at 9:47 AM, Wayne Stambaugh  > > >
> > > wrote:
> > >  
> > > Dan,
> > >  
> > > I found an issue but I don't think it's your issue but rather a bug in
> > > the AddHotKeyName() function. The menu accelerator for the "Update PCB
> > > from Schematic" menu entry ends up being "Alt + Alt + F8" instead of
> > > "Alt + F8" (see attached image). Do you have time to look at this and
> > > see if you can fix it? The broken code is in common/hotkeys.cpp. This
> > > will have to be fixed to include your patch.
> > >  
> > > Wayne
> > >  
> > > On 9/26/2017 6:35 PM, Dan Green wrote:
> > > > Ah yes, of course, all that makes sense. Thanks for explaining it.
> > > > Alt+F8 is available, so attached is a patch using that as the default 
> > > > (and with IS_ACCELERATOR).  
> > > > thanks,
> > > > Dan
> > > >  
> > > >  
> > > > On Tuesday, September 26, 2017 at 6:57 AM, Wayne Stambaugh wrote:
> > > >  
> > > > > Hey Dan,
> > > > >  
> > > > > I have a few comments on your patches.
> > > > >  
> > > > > The "Update PCB from Schematic" patch uses a duplicate hotkey. F8 is
> > > > > already assigned to the HK_SWITCH_LAYER_TO_INNER4 command ID. Check 
> > > > > the
> > > > > pcbnew/hotkeys.cpp file for the list of assigned hotkey. Also, you are
> > > > > using F8 as a menu accelerator not a hotkey which requires you to add
> > > > > the IS_ACCEL HOTKEY_ACTION_TYPE to the AddHotkeyName() call. You are
> > > > > going to have to choose a different hotkey and resubmit your patch.
> > > > >  
> > > > > Technically the file name fix patch works but you should use the
> > > > > wxFileName( path, name, ext) ctor to create the full file name. I've
> > > > > been trying to weed out this particular issue in KiCad but I must have
> > > > > missed this one. Also, there is no need to wrap "%s.%s" in with the
> > > > > internationalization macro _(). There is no text to translate in the
> > > > > string. I will fix this one now that I know where the issue exists.
> > > > >  
> > > > > Thanks,
> > > > >  
> > > > > Wayne
>  
>  
> --  
> Jean-Pierre CHARRAS
>  
>

Re: [Kicad-developers] [PATCH] Gerbview: Zoom to selection tool duplication

2017-10-02 Thread Константин Барановский 
OK.
Please, use patch from first message, that only removes extra tool from
left toolbar.

2017-10-02 17:32 GMT+03:00 Wayne Stambaugh :

> Nor would I.
>
> On 10/2/2017 3:30 AM, Maciej Sumiński wrote:
> > Hi Konstantin,
> >
> > I would rather not remove the cursor tool from the legacy canvas. Once
> > you select zoom to selection, the only way to revert back to the cursor
> > tool is to press Esc. The rest of the patch seems reasonable to me,
> > though I want to wait for some other comments.
> >
> > Regards,
> > Orson
> >
> > On 10/01/2017 08:32 PM, Константин Барановский wrote:
> >> I noticed that after deleting zoom-to-selection tool from left toolbar,
> >> cursor (no tool) and separator becomes redundant in legacy view mode.
> >> Updated patch in attachment.
> >> It removes zoom-to-selection tool from left toolbar and hides cursor
> with
> >> followed separator in legacy mode. When GAL canvas is active the cursor,
> >> mesurement tool and separator is shows at the top of the toolbar.
> >>
> >> 2017-09-30 22:16 GMT+03:00 Константин Барановский <
> >> baranovskiykonstan...@gmail.com>:
> >>
> >>> Gerbview has "Zoom to selection" tool present on both toolbars (left
> and
> >>> top).
> >>> Attached patch removes it from left toolbar, so "Zoom to selection"
> stay
> >>> present beside other zooming tools.
> >
> >
> >
> > ___
> > 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] Gerbview: Zoom to selection tool duplication

2017-10-02 Thread Wayne Stambaugh 
Nor would I.

On 10/2/2017 3:30 AM, Maciej Sumiński wrote:
> Hi Konstantin,
> 
> I would rather not remove the cursor tool from the legacy canvas. Once
> you select zoom to selection, the only way to revert back to the cursor
> tool is to press Esc. The rest of the patch seems reasonable to me,
> though I want to wait for some other comments.
> 
> Regards,
> Orson
> 
> On 10/01/2017 08:32 PM, Константин Барановский wrote:
>> I noticed that after deleting zoom-to-selection tool from left toolbar,
>> cursor (no tool) and separator becomes redundant in legacy view mode.
>> Updated patch in attachment.
>> It removes zoom-to-selection tool from left toolbar and hides cursor with
>> followed separator in legacy mode. When GAL canvas is active the cursor,
>> mesurement tool and separator is shows at the top of the toolbar.
>>
>> 2017-09-30 22:16 GMT+03:00 Константин Барановский <
>> baranovskiykonstan...@gmail.com>:
>>
>>> Gerbview has "Zoom to selection" tool present on both toolbars (left and
>>> top).
>>> Attached patch removes it from left toolbar, so "Zoom to selection" stay
>>> present beside other zooming tools.
> 
> 
> 
> ___
> 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] Update Fields in eeschema

2017-10-02 Thread Maciej Sumiński 
On 08/26/2017 08:01 PM, jp charras wrote:
> Le 25/08/2017 à 15:37, Maciej Sumiński a écrit :
>> The attached patches add to eeschema possibility of updating fields for
>> components already placed on schematics sheet using library values.
>>
>> It is useful for users maintaining additional fields in libraries to
>> store information that may change over time (e.g. Obsolete, URL fields).
>>
>> Regards,
>> Orson
> 
> Looks good to me, but perhaps a few enhancements could be welcome:
> - a minimal filtering of updated fields: especially value and footprint can 
> be reset to a not wanted
> text (Spice fields can also create issues if updated without filtering)
> The first attempt I made to test this patch reseted these precious (value and 
> fp) fields in a
> generic component.
> - perhaps (just an idea) add an option to update these fields for all similar 
> (same library symbol
> link) symbols.
> Fields like Obsolete, URL fields can be obsolete for many similar symbols is 
> schematic.
> 
> Thanks.

I have added a dialog where one can select the fields to be updated. The
dialog also allows the user to remove fields that do not occur in the
original libraries. I have pushed everything to the master branch.

Filtering by library symbol link might be added in the future, I would
not mind it.

Regards,
Orson



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

Re: [Kicad-developers] GitHub Plugin (my nemesis)

2017-10-02 Thread Andrey Kuznetsov 
Sorry, I was only talking about wrapping the 3D files which can be 100KB to
10MB large.
The other files are small enough.

On Mon, Oct 2, 2017 at 2:38 AM Simon Küppers  wrote:

> I am no expert, but this question is out of the scope of this thread.. For
> downloading, gut applies compression anyway.
>
> I respect the people having slow Internet lines.. However as shown a few
> posts backwards, the whole footprints and symbol library is like 100
> megabytes without the 3d models. If think the benefit of a single repo
> outways the ability to download only a selection of libraries... By a LOT.
>
>
>
> Am 2. Oktober 2017 10:22:10 MESZ schrieb Andrey Kuznetsov <
> kandre...@gmail.com>:
>>
>> Is it possible to keep the 3d models ZIPed or RARed on disk and KiCAD
>> unpacks them on the fly as needed/used during the session/etc?
>>
>> I am seeing 10x reduction in size when I pack the files whether they are
>> 7.5MB or 120KB, both were reduced to 750KB and 10KB respectively.
>> That's a lot of space wasted if we're thinking of the poor designers with
>> limited disk space.
>>
>> On Mon, Oct 2, 2017 at 1:03 AM, Carsten Schoenert <
>> c.schoen...@t-online.de> wrote:
>>
>>> Am 02.10.2017 um 06:14 schrieb David Godfrey:
>>> > Bernhard hit the nail on the head here.
>>> > For normal Users, ALL of the git functionality should be hidden behind
>>> > basic KiCad GUI features.
>>>
>>> A "normal" user doesn't need any git functions. He expects to have a
>>> working solution if he is using KiCad or $whatever software. The tricky
>>> part is on the software developers side, they need to take care about
>>> full functional additional components for the normal users.
>>>
>>> > However, for Users and Librarians that want to manage, add, edit at
>>> > least a basic knowledge of whatever tooling is used behind the scenes
>>> is
>>> > a HARD REQUIREMENT.
>>>
>>> Agreed.
>>> But such things are additional extras on the current situation. I guess
>>> the intent of this whole thread was to improve the current situation on
>>> the library handling inside KiCad. I think this should be focused on
>>> first as this increases the usability on the user side significantly.
>>>
>>> > These days git is probably one of the best documented, and most well
>>> > supported in the greater community.
>>> > That alone makes it a very good choice of backend.
>>> >
>>> > Handling of submodules can be slightly tricky, but a few simple helper
>>> > scripts (for LedgerSMB project we use a Makefile with a few targets
>>> such
>>> > as "submodules" which updates all submodules to the current repo head's
>>> > commit references to them)
>>> Mhh, I never have seen that any body is really happy about git
>>> submodules as they are always problematic. The reasons for this are
>>> already written here in this thread.
>>>
>>> I always look at the Linux kernel development model which is quite
>>> larger and bigger than the KiCad project.
>>> All parts in the development there don't use git submoduls for good
>>> reasons. All people involved always use the full tree. Sorry, I don't
>>> see a real need and gain for using git submoduls. And even if you have
>>> some scripting on top you need to teach the people how to use this. That
>>> is *always* overhead I'd avoid.
>>>
>>> As written here also, a complete git repository about all of the
>>> schematics with a stable and development branch and tagged releases
>>> would be fine and enough. The l10n and documentation part is already
>>> using this model.
>>>
>>> --
>>> Regards
>>> Carsten Schoenert
>>>
>>> ___
>>> 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
>>>
>>
>>
>>
>> --
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the
>> future [JFK]
>>
>> kandre...@gmail.com
>> Live Long and Prosper,
>> Andrey
>>
> ___
> 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
>
-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] GitHub Plugin (my nemesis)

2017-10-02 Thread Andrey Kuznetsov 
Is it possible to keep the 3d models ZIPed or RARed on disk and KiCAD
unpacks them on the fly as needed/used during the session/etc?

I am seeing 10x reduction in size when I pack the files whether they are
7.5MB or 120KB, both were reduced to 750KB and 10KB respectively.
That's a lot of space wasted if we're thinking of the poor designers with
limited disk space.

On Mon, Oct 2, 2017 at 1:03 AM, Carsten Schoenert 
wrote:

> Am 02.10.2017 um 06:14 schrieb David Godfrey:
> > Bernhard hit the nail on the head here.
> > For normal Users, ALL of the git functionality should be hidden behind
> > basic KiCad GUI features.
>
> A "normal" user doesn't need any git functions. He expects to have a
> working solution if he is using KiCad or $whatever software. The tricky
> part is on the software developers side, they need to take care about
> full functional additional components for the normal users.
>
> > However, for Users and Librarians that want to manage, add, edit at
> > least a basic knowledge of whatever tooling is used behind the scenes is
> > a HARD REQUIREMENT.
>
> Agreed.
> But such things are additional extras on the current situation. I guess
> the intent of this whole thread was to improve the current situation on
> the library handling inside KiCad. I think this should be focused on
> first as this increases the usability on the user side significantly.
>
> > These days git is probably one of the best documented, and most well
> > supported in the greater community.
> > That alone makes it a very good choice of backend.
> >
> > Handling of submodules can be slightly tricky, but a few simple helper
> > scripts (for LedgerSMB project we use a Makefile with a few targets such
> > as "submodules" which updates all submodules to the current repo head's
> > commit references to them)
> Mhh, I never have seen that any body is really happy about git
> submodules as they are always problematic. The reasons for this are
> already written here in this thread.
>
> I always look at the Linux kernel development model which is quite
> larger and bigger than the KiCad project.
> All parts in the development there don't use git submoduls for good
> reasons. All people involved always use the full tree. Sorry, I don't
> see a real need and gain for using git submoduls. And even if you have
> some scripting on top you need to teach the people how to use this. That
> is *always* overhead I'd avoid.
>
> As written here also, a complete git repository about all of the
> schematics with a stable and development branch and tagged releases
> would be fine and enough. The l10n and documentation part is already
> using this model.
>
> --
> Regards
> Carsten Schoenert
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Copy/Paste in pcbnew

2017-10-02 Thread Kristoffer Ödmark 

Great new, been looking ofrward to this!

Thanks!

On 10/02/2017 02:12 AM, Tomasz Wlostowski wrote:

Hi all,

I've just pushed Kristoffer's Copy feature for pcbnew and the
footprint editor. The feature is available only in GAL canvases and
activated by standard Edit menu entries and keyboard shortcuts.

I hope all the bugs have been fixed by now, but in case something
doesn't work, please file your complaints on the bug tracker ;-)

Kudos to Kristoffer for his hard work!

Tom



--
 -Kristoffer

___
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] GitHub Plugin (my nemesis)

2017-10-02 Thread Carsten Schoenert 
Am 02.10.2017 um 06:14 schrieb David Godfrey:
> Bernhard hit the nail on the head here.
> For normal Users, ALL of the git functionality should be hidden behind
> basic KiCad GUI features.

A "normal" user doesn't need any git functions. He expects to have a
working solution if he is using KiCad or $whatever software. The tricky
part is on the software developers side, they need to take care about
full functional additional components for the normal users.

> However, for Users and Librarians that want to manage, add, edit at
> least a basic knowledge of whatever tooling is used behind the scenes is
> a HARD REQUIREMENT.

Agreed.
But such things are additional extras on the current situation. I guess
the intent of this whole thread was to improve the current situation on
the library handling inside KiCad. I think this should be focused on
first as this increases the usability on the user side significantly.

> These days git is probably one of the best documented, and most well
> supported in the greater community.
> That alone makes it a very good choice of backend.
> 
> Handling of submodules can be slightly tricky, but a few simple helper
> scripts (for LedgerSMB project we use a Makefile with a few targets such
> as "submodules" which updates all submodules to the current repo head's
> commit references to them)
Mhh, I never have seen that any body is really happy about git
submodules as they are always problematic. The reasons for this are
already written here in this thread.

I always look at the Linux kernel development model which is quite
larger and bigger than the KiCad project.
All parts in the development there don't use git submoduls for good
reasons. All people involved always use the full tree. Sorry, I don't
see a real need and gain for using git submoduls. And even if you have
some scripting on top you need to teach the people how to use this. That
is *always* overhead I'd avoid.

As written here also, a complete git repository about all of the
schematics with a stable and development branch and tagged releases
would be fine and enough. The l10n and documentation part is already
using this model.

-- 
Regards
Carsten Schoenert

___
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] GitHub Plugin (my nemesis)

2017-10-02 Thread Thomas Kindler 
On 02.10.2017 07:00, David Godfrey wrote:
> [..]

> Don't Forget that not all of the world's internet connections are FAST.
> While it might seem a good idea from the librarians perspective to have
> everything in a single repo, IT ISN'T a good idea at all if you happen to be 
> on
> a slow internet connection.
> 
> When I say slow, I'm talking common ADSL speeds here in Australia for example.
> They are often 8mbit/s or less.
> 

8 MBit/s is not too shabby. You could download 3.6 gigabytes in one hour.

> [..]

> If the entire lib ended up being ~ 3G (a figure mentioned in other posts) that
> would Take an Unacceptably long time to download.

If you are refering to my post from 2017-09-23:

* The worst-case download size would be 650 MB for everything (history, 3D
models, etc).

* 3.8 Gigabyte is the on-disk size after decompression

As said, 90% of that size comes from generated 3D models. It might make sense to
keep them in a separate repo for people with slow computers or internet 
connections.


Here are the .git directory (i.e. download with full history) sizes:

  kicad-library (with 3D models) :  650 MB

  kicad-library (without 3D models)  : < 22 MB  (estimated)
  kicad-footprints (with all 88 submodules)  :   51 MB
  kicad-packages3D-source:   16 MB


> For this reason I would STRONGLY advise libraries remain broken up into
> manageable sized repositories

The current situation is madness. The footprints are broken into tiny,
unmanageable chunks for no apparent reason at all.

The only chunk to separate out that makes sense is the 3D models.

Even with the best scripts and tools, git submodules are a pain to work with and
a *BIG* turn-down for contributors.

> Also, keep in mind that a repository never gets smaller, it only grows as
> changes are made.
> 

Yes, but it will grow *very* slowly. Footprints and Library symbols are text
files that compress and diff great.

The generated 3D models might be another story.

> [..]

best regards,
-- 
Thomas Kindler

___
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] Gerbview: Zoom to selection tool duplication

2017-10-02 Thread Maciej Sumiński 
Hi Konstantin,

I would rather not remove the cursor tool from the legacy canvas. Once
you select zoom to selection, the only way to revert back to the cursor
tool is to press Esc. The rest of the patch seems reasonable to me,
though I want to wait for some other comments.

Regards,
Orson

On 10/01/2017 08:32 PM, Константин Барановский wrote:
> I noticed that after deleting zoom-to-selection tool from left toolbar,
> cursor (no tool) and separator becomes redundant in legacy view mode.
> Updated patch in attachment.
> It removes zoom-to-selection tool from left toolbar and hides cursor with
> followed separator in legacy mode. When GAL canvas is active the cursor,
> mesurement tool and separator is shows at the top of the toolbar.
> 
> 2017-09-30 22:16 GMT+03:00 Константин Барановский <
> baranovskiykonstan...@gmail.com>:
> 
>> Gerbview has "Zoom to selection" tool present on both toolbars (left and
>> top).
>> Attached patch removes it from left toolbar, so "Zoom to selection" stay
>> present beside other zooming tools.



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] DXF Import: new patch (fixes 2 problems)

2017-10-02 Thread Cirilo Bernardo 
Thanks Orson,

 I hope to see v5 soon too - it's been a few years now since the last
stable series. :)

- Cirilo


On Mon, Oct 2, 2017 at 7:22 AM, Maciej Sumiński  wrote:
> Hi Cirilo,
>
> Thank you for the patches. I have just pushed them to the master branch,
> but the stable branch might be still affected. I am not sure if it is a
> critical bug, and I really hope to see 5.0 rather than 4.0.8.
>
> Regards,
> Orson
>
> On 10/02/2017 02:20 AM, Cirilo Bernardo wrote:
>> The attached patch is pretty much the same as the previous
>> (dxf_polylines_20171001.patch) except for the addition of
>> a LOCALE_IO to switch to "C" locale before opening a DXF
>> file. Some people have reported problems importing DXF when
>> using language settings other than "English".
>>
>> The fixes in this patch should also be applied to the stable branch
>> (though I haven't checked out 'stable' to see if these patches can be
>> applied without changes).
>>
>> - Cirilo
>
>
> ___
> 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] DXF Import: new patch (fixes 2 problems)

2017-10-02 Thread Maciej Sumiński 
Hi Cirilo,

Thank you for the patches. I have just pushed them to the master branch,
but the stable branch might be still affected. I am not sure if it is a
critical bug, and I really hope to see 5.0 rather than 4.0.8.

Regards,
Orson

On 10/02/2017 02:20 AM, Cirilo Bernardo wrote:
> The attached patch is pretty much the same as the previous
> (dxf_polylines_20171001.patch) except for the addition of
> a LOCALE_IO to switch to "C" locale before opening a DXF
> file. Some people have reported problems importing DXF when
> using language settings other than "English".
> 
> The fixes in this patch should also be applied to the stable branch
> (though I haven't checked out 'stable' to see if these patches can be
> applied without changes).
> 
> - Cirilo



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] Pcbnew: small fix for pad properties dialog

2017-10-02 Thread Maciej Sumiński 
Hi Konstantin,

Thank you for the patch, I have just pushed it to the master branch.

Regards,
Orson

On 10/01/2017 03:36 PM, Константин Барановский wrote:
> In "Pad properties" dialog on "Local Clearance and Settings" tab last
> option has some difference from others.
> Attached patch makes label "Custom pad shape in zone:" aligned by vertical
> center and removes right and top borders from wxChoice item (to make size
> of it to be equivalent to other items in this column).



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