Re: [Kicad-developers] 1: GAL Bug with Window Buttons

[Nick Østergaard]

What version of kicad did he test?

Den 13. sep. 2017 5.45 AM skrev "Strontium" :

> Hi all,
>
> Background: My father is a hardware engineer, he has been doing it since
> the early 70s learning in the RAAF, laying boards using tape, so he has a
> lot of experience.  He is retired, but still likes to design boards, and I
> have convinced him to give KiCAD a go.  He has been using old versions of
> Altium and still uses Protel 99SE, but would like to use KiCAD because he
> doesn't want to use windows in a VM any more if he can avoid it, he wants
> to use Linux native.
>
> He has a number of problems adapting to the software and I will lay those
> out over three messages, one is a clear bug in GAL, the others are not as
> clear, although I think his criticisms have merit and are useful to
> consider.  He is using the nightly build from PPA, so all the criticisms
> are directed to KiCAD at that state.
>
> 1. The window sliders/buttons on the GAL Canvas do not function.
>
> If you press left/right/up/down, nothing happens.
>
> If you click the mouse in the slider space, the slider bar moves, but
> nothing updates on the screen.
>
> The only thing the sliders do is if you grab them and drag them, the
> canvas updates.
>
> In Legacy, these buttons/sliders work as expected and one would imagine
> they should do exactly the same thing in GAL Canvas.  I think this is a bug.
>
> The other two issues I will put in their own posts.
>
> Steven
>
>
> ___
> 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] 3: Net Connectivity

[Strontium]

His third criticism is with net connectivity.

What he did was he has a component with 4 GND pads in a row.  He ran a 
track across them (in the middle) and finished it at the last pad.  The 
Track clearly crosses all pads, however the DRC shows them as 
"unconnected" when they are really connected electrically.


His complaint is that this is tedious and unintuitive to lay, and wrong 
from a physical model of the board perspective.  That any copper track 
crossing a pad at any point should be considered connected, because it 
is, it shouldn't need to touch the centre of the pad, which is an 
arbitrary anchor.


Its also not consistent with a track that crosses a pad that is not its 
net.  That track, if it touches the wrong pad at any point throws a DRC 
error, but if it connects to a pad with the correct net (but doesn't end 
on the pads centre) is considered not connected.


There is an edge case where a track only slightly touches a pad, and is 
electrically connected, but Not connected sufficiently for the design, 
but that is not the same thing as being "unconnected" and isn't handled 
by DRC now in any event.


He IS a new user and he naturally has numerous complaints, most of which 
result from frustration with learning a new tool, and I talk him through 
those.  But, I think these three points are valid criticisms that the 
developers should consider in the future.  I will make some entries in 
the bug tracking system to track these, but I wanted feedback first, are 
these "wont fix" or "feature requests", "bugs", etc.


Steven


___
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] 2: Via Tool

[Strontium]

His second criticism is with the via tool.

What he did is lay two tracks on his board, one on either side. (Both 
had the same net)


He then pressed the via tool, and dropped vias into the intersections.

The vias created design violations because they are assigned No Net.  
Doing DRC does not reconnect them.


This is hostile, especially for a new user.  His complaint was, whats 
the point of a via tool if i cant place a via on a track and it "Just 
Work".  Seems a reasonable criticism.


We argued about the end cases, but I agree with him that:

1. If you have tracks with the same net on multiple tracks, the via tool 
should be able to place a via on the tracks and pick up their net.  It 
shouldn't create a Design violation.


2. If you have one track with a net and the other(s) with "No Net" the 
via should get the net of the one track that has a net.


3. That a DRC should propagate the net through connectivity of the 
connected tracks and vias laid in this way, and it currently doesn't.  
It just throws a design violation.


4. With DRC checking enabled, it shouldn't be possible to drop a via if 
that via would cause a design violation.  Exactly like its not possible 
to lay two tracks with different nets over one another. (For example, 
two tracks on different layers, with different nets should not be able 
to put a via over them because thats a design violation)


I am not sure if the Via tool is considered complete, or still a work in 
progress, however I think these things should be considered as the way 
it currently works is unintuitive.


Steven


___
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] 1: GAL Bug with Window Buttons

[Strontium]

Hi all,

Background: My father is a hardware engineer, he has been doing it since 
the early 70s learning in the RAAF, laying boards using tape, so he has 
a lot of experience.  He is retired, but still likes to design boards, 
and I have convinced him to give KiCAD a go.  He has been using old 
versions of Altium and still uses Protel 99SE, but would like to use 
KiCAD because he doesn't want to use windows in a VM any more if he can 
avoid it, he wants to use Linux native.


He has a number of problems adapting to the software and I will lay 
those out over three messages, one is a clear bug in GAL, the others are 
not as clear, although I think his criticisms have merit and are useful 
to consider.  He is using the nightly build from PPA, so all the 
criticisms are directed to KiCAD at that state.


1. The window sliders/buttons on the GAL Canvas do not function.

If you press left/right/up/down, nothing happens.

If you click the mouse in the slider space, the slider bar moves, but 
nothing updates on the screen.


The only thing the sliders do is if you grab them and drag them, the 
canvas updates.


In Legacy, these buttons/sliders work as expected and one would imagine 
they should do exactly the same thing in GAL Canvas.  I think this is a bug.


The other two issues I will put in their own posts.

Steven


___
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] disable icons in menus by default on osx

[Michael Kavanagh]

Doesn't matter to me (although I personally always turn them off). I was
just pointing out that the code didn't appear to work as it was intended to
on macOS and provided an alternative.

Michael

On 12 September 2017 at 16:28, Wayne Stambaugh  wrote:

> Do we really need to change the default?  All this will do is change
> which group of users complains about the default setting.  The reason we
> changed this is that some users wanted the menu bitmaps even on
> platforms where it is recommended not to use them.  I just don't see any
> benefit to making this change.  Is it that difficult for users to check
> or uncheck the menu bitmap setting according to their preference?
>
> Wayne
>
> On 9/12/2017 8:56 AM, Fabrizio Tappero wrote:
> > Hi Diogo,
> > thanks for point it our. This has been fixed in a patch that is
> > currently in the pipeline.
> >
> > Cheers
> > Fabrizio
> >
> >
> > On Mon, Sep 11, 2017 at 7:51 PM, Diogo Condeço  > > wrote:
> >
> > While personally I won't use icons in the menus if that option is
> > available to me, I can see why someone would like to use them.
> >
> > I can see it being useful to identify actions visually, but with
> > that in mind, I can't understand why having icons and reusing them
> > on different functions would help anyone. I've attached a screenshot
> > where the same icon is used for 3 different actions
> >
> > BR,
> > Diogo
> >
> > On Thu, Sep 7, 2017 at 3:59 PM, Miguel Angel Ajo Pelayo
> > > wrote:
> >
> > I personally (as a user) find the icons visually more intuitive.
> > Specially for newcomers and better adoption of KiCad.
> >
> > I know it's out of some guidelines, but this is a very complex
> > software.
> >
> > My feeling is that it's better with a "on" by default setting,
> > as long as people already used to the software, or not liking
> > icons could disable them.
> >
> > On Thu, Sep 7, 2017 at 4:34 PM, Michael Kavanagh
> > >
> > wrote:
> >
> > Hi,
> >
> > Sorry to bring this up again, but for me icons are still
> > enabled by default on macOS (and Windows unsurprisingly). I
> > deleted /Library/Application Support/kicad,
> > ~/Library/Preferences/kicad and /Applications/Kicad,
> > reinstalled from most recent nightly (07-Sep-2017) and the
> > icons were there upon startup.
> >
> > I think the problem was the default value was true when the
> > key wasn't found (ie for new install),
> > see http://docs.wxwidgets.org/trunk/classwx_config_base.
> html#a93b700301e0b73f1b42f14497f2e6bc7
> >  a93b700301e0b73f1b42f14497f2e6bc7>
> >
> > I have attached a patch to turn icons off by default on all
> > platforms (doing away with "ugly" #if defined()/#endif). I
> > think this would be preferable as per both the macOS and
> > Windows guidelines. I am unfamiliar with Linux UI's but if
> > Linux users want the icons enabled by default the #if will
> > have to be added again.
> >
> > Cheers,
> > Michael
> >
> >
> > On 13 April 2017 at 18:51, Wayne Stambaugh
> > > wrote:
> >
> > Simon,
> >
> > I committed your patch since osx expects the icons to be
> > disabled by
> > default.
> >
> > Thanks,
> >
> > Wayne
> >
> > On 4/8/2017 6:42 AM, Simon Wells wrote:
> > > Please see attached patch to disable icons in the
> menus by default on osx
> > >
> > >
> > >
> > > ___
> > > 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] disable icons in menus by default on osx

[Wayne Stambaugh]

Do we really need to change the default?  All this will do is change
which group of users complains about the default setting.  The reason we
changed this is that some users wanted the menu bitmaps even on
platforms where it is recommended not to use them.  I just don't see any
benefit to making this change.  Is it that difficult for users to check
or uncheck the menu bitmap setting according to their preference?

Wayne

On 9/12/2017 8:56 AM, Fabrizio Tappero wrote:
> Hi Diogo,
> thanks for point it our. This has been fixed in a patch that is
> currently in the pipeline.
> 
> Cheers
> Fabrizio
> 
> 
> On Mon, Sep 11, 2017 at 7:51 PM, Diogo Condeço  > wrote:
> 
> While personally I won't use icons in the menus if that option is
> available to me, I can see why someone would like to use them. 
> 
> I can see it being useful to identify actions visually, but with
> that in mind, I can't understand why having icons and reusing them
> on different functions would help anyone. I've attached a screenshot
> where the same icon is used for 3 different actions
> 
> BR,
> Diogo
> 
> On Thu, Sep 7, 2017 at 3:59 PM, Miguel Angel Ajo Pelayo
> > wrote:
> 
> I personally (as a user) find the icons visually more intuitive.
> Specially for newcomers and better adoption of KiCad.
> 
> I know it's out of some guidelines, but this is a very complex
> software.
> 
> My feeling is that it's better with a "on" by default setting,
> as long as people already used to the software, or not liking
> icons could disable them.
> 
> On Thu, Sep 7, 2017 at 4:34 PM, Michael Kavanagh
> >
> wrote:
> 
> Hi,
> 
> Sorry to bring this up again, but for me icons are still
> enabled by default on macOS (and Windows unsurprisingly). I
> deleted /Library/Application Support/kicad,
> ~/Library/Preferences/kicad and /Applications/Kicad,
> reinstalled from most recent nightly (07-Sep-2017) and the
> icons were there upon startup.
> 
> I think the problem was the default value was true when the
> key wasn't found (ie for new install),
> see 
> http://docs.wxwidgets.org/trunk/classwx_config_base.html#a93b700301e0b73f1b42f14497f2e6bc7
> 
> 
> 
> I have attached a patch to turn icons off by default on all
> platforms (doing away with "ugly" #if defined()/#endif). I
> think this would be preferable as per both the macOS and
> Windows guidelines. I am unfamiliar with Linux UI's but if
> Linux users want the icons enabled by default the #if will
> have to be added again.
> 
> Cheers,
> Michael
> 
> 
> On 13 April 2017 at 18:51, Wayne Stambaugh
> > wrote:
> 
> Simon,
> 
> I committed your patch since osx expects the icons to be
> disabled by
> default.
> 
> Thanks,
> 
> Wayne
> 
> On 4/8/2017 6:42 AM, Simon Wells wrote:
> > Please see attached patch to disable icons in the menus by 
> default on osx
> >
> >
> >
> > ___
> > 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: 

[Kicad-developers] [PATCH] Improved zoom behavior on MacOS

[Jon Evans]

Hi,

This patch changes the way middle wheel events are handled on MacOS.
In my testing, this new behavior feels way better when using Apple
trackpads, and also seems to work fine with the normal wheel on my external
mouse.

Mac users, I'd appreciate some testing to see if the behavior is worse than
the existing one in any use cases.  Since MacOS provides wheel event
acceleration at the OS level, we shouldn't need our own acceleration
management code, but maybe there are some situations where the old code
works better?

Thanks,
Jon


0001-Improved-zoom-behavior-on-MacOS.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] [PATCH] minor icon improvements

[Wayne Stambaugh]

Fabrizio,

Did you submit a revised patch with the suggestions that I made?  I just
looked in the mailing list archives and all I see is the original patch.

Cheers,

Wayne

On 9/12/2017 8:57 AM, Fabrizio Tappero wrote:
> gentle reminder 
> 
> cheers
> Fabrizio
> 
> 
> On Tue, Aug 29, 2017 at 7:12 PM, Wayne Stambaugh  > wrote:
> 
> On 8/29/2017 12:44 PM, Simon Küppers wrote:
> > -    Run Pcbnew
> >
> > +   Edit PCB
> >
> > What about "Edit PCB Layout" orientiert "Edit PCB Design"? Sounds more
> > professional imho.
> 
> I'm fine with "Edit PCB Layout".
> 
> >
> >
> > Am 29. August 2017 10:04:19 MESZ schrieb Fabrizio Tappero
> > >:
> >
> >     Hi Wayne,
> >     it sound good. 
> >     I think "Run" should go and I think "Edit Schematic" in place of
> >     "Run Eeschema" is a great step up.
> >
> >     The considerations about the use of the words "Symbol" and "Table"
> >     sound good too.
> >
> >     I changed the patch accordingly and resubmitted here. Just as
> >     reference, this is what I came up with:
> >
> >     -    Run Eeschema
> >     +   Edit Schematic
> >
> >     -    Run Library Editor
> >     +   Edit Schematic Symbol
> >
> >     -    Run Pcbnew
> >     +   Edit PCB
> >
> >     -    Run Footprint Editor
> >     +   Edit PCB Footprint
> >
> >     -    Run Gerbview
> >     +   View GERBER
> >
> >     -    Run Bitmap2Component
> >     +   Convert Bitmap to Footprint
> >
> >     -    Run Pcb Calculator
> >     +   Run PCB Calculator
> >
> >     -    Run Page Layout Editor
> >     +   Edit Sheet Layout
> >
> >     Wayne, please feel free to change the content of this patch as you
> >     think it is best.
> >
> >     cheers
> >     Fabrizio
> >
> >
> >
> >
> >
> >     On Mon, Aug 28, 2017 at 9:00 PM, Wayne Stambaugh
> >     
> >> wrote:
> >
> >         Fabrizio,
> >
> >         I'm fine with the icon changes.  The menu entry changes could
> >         use some
> >         improvement.  I'm not sure removing "Run" from the KiCad
> >         launcher menu
> >         entries is a good idea.  Generally (at least in most of the
> >         applications
> >         that I've looked at), actions are used in menu string when the
> >         entry is
> >         an action.  I also think it's probably time to get rid of
> the old
> >         Eeschema/Pcbnew application names.  Since KiCad normally
> runs in a
> >         single process, better menu entries might be "Edit Schematic"
> >         and "Edit
> >         Board (or PCB)".  New users aren't going to know what
> Eeschema and
> >         Pcbnew are.
> >
> >         I would also would not refer to the footprint library "table"
> >         either.
> >         The word table seems to confuse users.  I know we refer to
> it as
> >         a table
> >         on the developers mailing list but I think users are more
> >         comfortable
> >         with "Manage Footprint Libraries".  I am aware that I used
> table
> >         for the
> >         symbol library table dialog menus entry but this is
> temporary. 
> >         Once I
> >         finish the symbol library table remapping code, this
> dialog will
> >         go away
> >         and "Manage Symbol Libraries" will open the symbol library
> table
> >         edit
> >         dialog.
> >
> >         The use of symbol was intentional so I would prefer that
> it not be
> >         changed.  There was a discussion about this not too long
> ago and the
> >         consensus was that symbol made the most sense versus component
> >         or part.
> >         I realize that component (and part) are used in the source
> code
> >         and most
> >         of the UI strings but I would prefer that we change the UI
> >         strings to
> >         symbol for the stable 5 release rather than continue to use
> >         component
> >         and/or part.  I will change the source when I get a chance so
> >         that the
> >         terminology is coherent between the source and the UI
> strings. 
> >         I know
> >         we still have the module/footprint distinction in the Pcbnew
> >         source but
> >         at least all of the UI strings are "footprint".
> >
> >         Cheers,
> >
> >         Wayne
> >
> >         On 8/22/2017 5:47 PM, Fabrizio 

Re: [Kicad-developers] disable icons in menus by default on osx

[Wayne Stambaugh]

On 9/11/2017 1:51 PM, Diogo Condeço wrote:
> While personally I won't use icons in the menus if that option is
> available to me, I can see why someone would like to use them. 
> 
> I can see it being useful to identify actions visually, but with that in
> mind, I can't understand why having icons and reusing them on different
> functions would help anyone. I've attached a screenshot where the same
> icon is used for 3 different actions

The "Component Libraries" menu entry is soon going to go away leaving
only the "Symbol Library Table" menu entry so there will not be a
duplicate bitmap once this work is complete.

> 
> BR,
> Diogo
> 
> On Thu, Sep 7, 2017 at 3:59 PM, Miguel Angel Ajo Pelayo
> > wrote:
> 
> I personally (as a user) find the icons visually more intuitive.
> Specially for newcomers and better adoption of KiCad.
> 
> I know it's out of some guidelines, but this is a very complex software.
> 
> My feeling is that it's better with a "on" by default setting, as
> long as people already used to the software, or not liking icons
> could disable them.
> 
> On Thu, Sep 7, 2017 at 4:34 PM, Michael Kavanagh
> > wrote:
> 
> Hi,
> 
> Sorry to bring this up again, but for me icons are still enabled
> by default on macOS (and Windows unsurprisingly). I deleted
> /Library/Application Support/kicad, ~/Library/Preferences/kicad
> and /Applications/Kicad, reinstalled from most recent nightly
> (07-Sep-2017) and the icons were there upon startup.
> 
> I think the problem was the default value was true when the key
> wasn't found (ie for new install),
> see 
> http://docs.wxwidgets.org/trunk/classwx_config_base.html#a93b700301e0b73f1b42f14497f2e6bc7
> 
> 
> 
> I have attached a patch to turn icons off by default on all
> platforms (doing away with "ugly" #if defined()/#endif). I think
> this would be preferable as per both the macOS and Windows
> guidelines. I am unfamiliar with Linux UI's but if Linux users
> want the icons enabled by default the #if will have to be added
> again.
> 
> Cheers,
> Michael
> 
> 
> On 13 April 2017 at 18:51, Wayne Stambaugh  > wrote:
> 
> Simon,
> 
> I committed your patch since osx expects the icons to be
> disabled by
> default.
> 
> Thanks,
> 
> Wayne
> 
> On 4/8/2017 6:42 AM, Simon Wells wrote:
> > Please see attached patch to disable icons in the menus by 
> default on osx
> >
> >
> >
> > ___
> > 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 

Re: [Kicad-developers] [PATCH] Make BRIGHT_BOX line width dependent on zoom level

[Jon Evans]

Bump

On Tue, Sep 5, 2017 at 10:21 PM, Jon Evans  wrote:

> OK, will wait to hear from Orson then.  I did test and it seems to do what
> I want on OpenGL + Cairo
>
> -Jon
>
> On Tue, Sep 5, 2017 at 10:03 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Jon,
>>
>> I submitted a very similar patch earlier this year, and Orson raised an
>> issue, saying that it would cause issues with cached targets on OpenGl?
>>
>> I don't know much about this particular issue but it would be good to get
>> his sign off on this patch.
>>
>> IIRC he said he would look into it when he had time. Perhaps he has not
>> had time ;)
>>
>> Something to consider.
>>
>> Cheers,
>> Oliver
>>
>> On 6 Sep 2017 10:25, "Jon Evans"  wrote:
>>
>>> Hi all,
>>>
>>> This patch is a quick one to make the line width of the BRIGHT_BOX
>>> dependent on the zoom level so that it remains basically the same apparent
>>> size on the screen.
>>>
>>> -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
>>>
>>>
>
___
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] Add support for panning with left and right mouse buttons

[Jon Evans]

Bump, are any of the GAL developers around to review this?

Thanks,
Jon

On Tue, Sep 5, 2017 at 9:31 PM, Jon Evans  wrote:

> Hi all,
>
> This patch extends the VIEW_CONTROLS to allow optional panning with left
> or right buttons in addition to middle.  I plan to make use of this in
> GerbView for an easy panning mode that works well on laptops and 2-button
> mice, and this might also be useful in other applications -- drag-to-pan
> with the right button is a handy thing to enable in editing tools to make
> them usable when you don't have a middle button.
>
> -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] minor icon improvements

[Fabrizio Tappero]

gentle reminder

cheers
Fabrizio


On Tue, Aug 29, 2017 at 7:12 PM, Wayne Stambaugh 
wrote:

> On 8/29/2017 12:44 PM, Simon Küppers wrote:
> > -Run Pcbnew
> >
> > +   Edit PCB
> >
> > What about "Edit PCB Layout" orientiert "Edit PCB Design"? Sounds more
> > professional imho.
>
> I'm fine with "Edit PCB Layout".
>
> >
> >
> > Am 29. August 2017 10:04:19 MESZ schrieb Fabrizio Tappero
> > :
> >
> > Hi Wayne,
> > it sound good.
> > I think "Run" should go and I think "Edit Schematic" in place of
> > "Run Eeschema" is a great step up.
> >
> > The considerations about the use of the words "Symbol" and "Table"
> > sound good too.
> >
> > I changed the patch accordingly and resubmitted here. Just as
> > reference, this is what I came up with:
> >
> > -Run Eeschema
> > +   Edit Schematic
> >
> > -Run Library Editor
> > +   Edit Schematic Symbol
> >
> > -Run Pcbnew
> > +   Edit PCB
> >
> > -Run Footprint Editor
> > +   Edit PCB Footprint
> >
> > -Run Gerbview
> > +   View GERBER
> >
> > -Run Bitmap2Component
> > +   Convert Bitmap to Footprint
> >
> > -Run Pcb Calculator
> > +   Run PCB Calculator
> >
> > -Run Page Layout Editor
> > +   Edit Sheet Layout
> >
> > Wayne, please feel free to change the content of this patch as you
> > think it is best.
> >
> > cheers
> > Fabrizio
> >
> >
> >
> >
> >
> > On Mon, Aug 28, 2017 at 9:00 PM, Wayne Stambaugh
> > > wrote:
> >
> > Fabrizio,
> >
> > I'm fine with the icon changes.  The menu entry changes could
> > use some
> > improvement.  I'm not sure removing "Run" from the KiCad
> > launcher menu
> > entries is a good idea.  Generally (at least in most of the
> > applications
> > that I've looked at), actions are used in menu string when the
> > entry is
> > an action.  I also think it's probably time to get rid of the old
> > Eeschema/Pcbnew application names.  Since KiCad normally runs in
> a
> > single process, better menu entries might be "Edit Schematic"
> > and "Edit
> > Board (or PCB)".  New users aren't going to know what Eeschema
> and
> > Pcbnew are.
> >
> > I would also would not refer to the footprint library "table"
> > either.
> > The word table seems to confuse users.  I know we refer to it as
> > a table
> > on the developers mailing list but I think users are more
> > comfortable
> > with "Manage Footprint Libraries".  I am aware that I used table
> > for the
> > symbol library table dialog menus entry but this is temporary.
> > Once I
> > finish the symbol library table remapping code, this dialog will
> > go away
> > and "Manage Symbol Libraries" will open the symbol library table
> > edit
> > dialog.
> >
> > The use of symbol was intentional so I would prefer that it not
> be
> > changed.  There was a discussion about this not too long ago and
> the
> > consensus was that symbol made the most sense versus component
> > or part.
> > I realize that component (and part) are used in the source code
> > and most
> > of the UI strings but I would prefer that we change the UI
> > strings to
> > symbol for the stable 5 release rather than continue to use
> > component
> > and/or part.  I will change the source when I get a chance so
> > that the
> > terminology is coherent between the source and the UI strings.
> > I know
> > we still have the module/footprint distinction in the Pcbnew
> > source but
> > at least all of the UI strings are "footprint".
> >
> > Cheers,
> >
> > Wayne
> >
> > On 8/22/2017 5:47 PM, Fabrizio Tappero wrote:
> > > Reminder.
> > >
> > > Regards
> > > Fabrizio
> > >
> > >
> > > On Aug 17, 2017 4:42 PM, "Fabrizio Tappero" <
> fabrizio.tapp...@gmail.com 
> > >  gmail.com>>>
> > wrote:
> > >
> > > Hello,
> > > the following patch does the following:
> > > 1) correct few pcbnew and eeschema menu text entries
> > > 2) add the library table icon (minor look change)
> > > 3) delete the redundant word "Run" into the KiCad - Tools
> menu entry
> > >
> > > cheers
> > > Fabrzio
> > >
> > >
> > >
> > > ___
> > > Mailing list: 

Re: [Kicad-developers] disable icons in menus by default on osx

[Fabrizio Tappero]

Hi Diogo,
thanks for point it our. This has been fixed in a patch that is currently
in the pipeline.

Cheers
Fabrizio


On Mon, Sep 11, 2017 at 7:51 PM, Diogo Condeço 
wrote:

> While personally I won't use icons in the menus if that option is
> available to me, I can see why someone would like to use them.
>
> I can see it being useful to identify actions visually, but with that in
> mind, I can't understand why having icons and reusing them on different
> functions would help anyone. I've attached a screenshot where the same icon
> is used for 3 different actions
>
> BR,
> Diogo
>
> On Thu, Sep 7, 2017 at 3:59 PM, Miguel Angel Ajo Pelayo <
> majop...@redhat.com> wrote:
>
>> I personally (as a user) find the icons visually more intuitive.
>> Specially for newcomers and better adoption of KiCad.
>>
>> I know it's out of some guidelines, but this is a very complex software.
>>
>> My feeling is that it's better with a "on" by default setting, as long as
>> people already used to the software, or not liking icons could disable them.
>>
>> On Thu, Sep 7, 2017 at 4:34 PM, Michael Kavanagh <
>> mich...@michaelkavanagh.me> wrote:
>>
>>> Hi,
>>>
>>> Sorry to bring this up again, but for me icons are still enabled by
>>> default on macOS (and Windows unsurprisingly). I deleted
>>> /Library/Application Support/kicad, ~/Library/Preferences/kicad and
>>> /Applications/Kicad, reinstalled from most recent nightly (07-Sep-2017)
>>> and the icons were there upon startup.
>>>
>>> I think the problem was the default value was true when the key wasn't
>>> found (ie for new install), see http://docs.wxwidgets.org/
>>> trunk/classwx_config_base.html#a93b700301e0b73f1b42f14497f2e6bc7
>>>
>>> I have attached a patch to turn icons off by default on all platforms
>>> (doing away with "ugly" #if defined()/#endif). I think this would be
>>> preferable as per both the macOS and Windows guidelines. I am
>>> unfamiliar with Linux UI's but if Linux users want the icons enabled by
>>> default the #if will have to be added again.
>>>
>>> Cheers,
>>> Michael
>>>
>>>
>>> On 13 April 2017 at 18:51, Wayne Stambaugh  wrote:
>>>
 Simon,

 I committed your patch since osx expects the icons to be disabled by
 default.

 Thanks,

 Wayne

 On 4/8/2017 6:42 AM, Simon Wells wrote:
 > Please see attached patch to disable icons in the menus by default on
 osx
 >
 >
 >
 > ___
 > 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
>>
>>
>
>
> --
> 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] [PATCH] Make RULER_ITEM generic

[jp charras]

Le 12/09/2017 à 04:56, Jon Evans a écrit :
> Hi,
> 
> Another in my series of patches leading up to GerbView GAL merge, this is a 
> quick one to enable the
> ruler to work in GerbView.
> 
> -Jon
> 

Committed. Thanks.


-- 
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] [PATCH] Don't force grid color to LAYER_GRID in EDA_DRAW_PANEL_GAL

[jp charras]

Le 12/09/2017 à 05:03, Jon Evans a écrit :
> Hi,
> 
> This patch removes a call that prevents other children of EDA_DRAW_PANEL_GAL 
> from using layers other
> than LAYER_GRID to specify grid color, and instead set the grid color in the 
> GAL when it is changed
> or updated.
> 
> -Jon

Committed. Thanks.

-- 
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] [PATCH] Add background color for subsheets

[Oliver Walters]

This small patch adds a configurable background color for hierarchical
sheets.

Image: http://i.imgur.com/53zgcy9.png

Oliver
From b6f06edf51e0772c3a85917160d779e809388041 Mon Sep 17 00:00:00 2001
From: Oliver Walters 
Date: Tue, 12 Sep 2017 19:07:00 +1000
Subject: [PATCH] Added SHEETBACKGROUND color

- Fill color for sub-sheet rectangle
- Added default color
- Added button to change color
---
 eeschema/eeschema.cpp |  1 +
 eeschema/sch_sheet.cpp| 10 ++
 eeschema/widgets/widget_eeschema_color_config.cpp |  1 +
 include/layers_id_colors_and_visibility.h |  1 +
 4 files changed, 13 insertions(+)

diff --git a/eeschema/eeschema.cpp b/eeschema/eeschema.cpp
index 593e5a8..47c4584 100644
--- a/eeschema/eeschema.cpp
+++ b/eeschema/eeschema.cpp
@@ -209,6 +209,7 @@ static PARAM_CFG_ARRAY& cfg_params()
 CLR( "Color4DNetNameEx",  LAYER_NETNAM,   COLOR4D( DARKGRAY ) )
 CLR( "Color4DPinEx",  LAYER_PIN,  COLOR4D( RED ) )
 CLR( "Color4DSheetEx",LAYER_SHEET,COLOR4D( MAGENTA ) )
+CLR( "Color4DSheetBackground",LAYER_SHEETBACKGROUND,  COLOR4D( 0.53f, 0.69f, 0.76f, 1.0f ) )
 CLR( "Color4DSheetFileNameEx",LAYER_SHEETFILENAME,COLOR4D( BROWN ) )
 CLR( "Color4DSheetNameEx",LAYER_SHEETNAME,COLOR4D( CYAN ) )
 CLR( "Color4DSheetLabelEx",   LAYER_SHEETLABEL,   COLOR4D( BROWN ) )
diff --git a/eeschema/sch_sheet.cpp b/eeschema/sch_sheet.cpp
index 9a975d2..bffc386 100644
--- a/eeschema/sch_sheet.cpp
+++ b/eeschema/sch_sheet.cpp
@@ -610,6 +610,7 @@ void SCH_SHEET::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDC,
 COLOR4D txtcolor;
 wxString Text;
 COLOR4D color;
+COLOR4D bgColor;
 int  name_orientation;
 wxPoint  pos_sheetname,pos_filename;
 wxPoint  pos = m_pos + aOffset;
@@ -617,12 +618,21 @@ void SCH_SHEET::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDC,
 EDA_RECT* clipbox  = aPanel? aPanel->GetClipBox() : NULL;
 
 if( aColor != COLOR4D::UNSPECIFIED )
+{
 color = aColor;
+bgColor = aColor;
+}
 else
+{
 color = GetLayerColor( m_Layer );
+bgColor = GetLayerColor( LAYER_SHEETBACKGROUND );
+}
 
 GRSetDrawMode( aDC, aDrawMode );
 
+GRFilledRect( clipbox, aDC, pos.x, pos.y, pos.x + m_size.x, pos.y + m_size.y,
+  lineWidth, bgColor, bgColor );
+
 GRRect( clipbox, aDC, pos.x, pos.y,
 pos.x + m_size.x, pos.y + m_size.y, lineWidth, color );
 
diff --git a/eeschema/widgets/widget_eeschema_color_config.cpp b/eeschema/widgets/widget_eeschema_color_config.cpp
index b9d7940..08222af 100644
--- a/eeschema/widgets/widget_eeschema_color_config.cpp
+++ b/eeschema/widgets/widget_eeschema_color_config.cpp
@@ -81,6 +81,7 @@ static COLORBUTTON componentColorButtons[] = {
 
 static COLORBUTTON sheetColorButtons[] = {
 { _( "Sheet" ), LAYER_SHEET },
+{ _( "Sheet background" ),  LAYER_SHEETBACKGROUND },
 { _( "Sheet file name" ),   LAYER_SHEETFILENAME },
 { _( "Sheet name" ),LAYER_SHEETNAME },
 { _( "Sheet label" ),   LAYER_SHEETLABEL },
diff --git a/include/layers_id_colors_and_visibility.h b/include/layers_id_colors_and_visibility.h
index 26404fe..4d06412 100644
--- a/include/layers_id_colors_and_visibility.h
+++ b/include/layers_id_colors_and_visibility.h
@@ -244,6 +244,7 @@ enum SCH_LAYER_ID: int
 LAYER_NETNAM,
 LAYER_PIN,
 LAYER_SHEET,
+LAYER_SHEETBACKGROUND,
 LAYER_SHEETNAME,
 LAYER_SHEETFILENAME,
 LAYER_SHEETLABEL,
-- 
2.7.4

___
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