Re: [Kicad-developers] Patch: Open Datasheet in Project Dir

[Cheng Sheng]

Ah, sorry for the error. Just happened to have the whole OS
clean-reinstalled so didn't config Vim to get rid of all tabs.

On 6 June 2017 at 14:54, Wayne Stambaugh  wrote:

> Cheng,
>
> I committed you patch to the master branch.  Thank you for making the
> changes I suggested and your contribution to KiCad.  One minor note,
> your revised patch had tabs which violate the KiCad Coding Policy[1].  I
> fixed them this time.  In the future please make sure to have your
> editor configured to use spaces.
>
> Cheers,
>
> Wayne
>
> [1]
> http://docs.kicad-pcb.org/doxygen/md_Documentation_
> development_coding-style-policy.html
>
> On 6/6/2017 8:17 AM, Cheng Sheng wrote:
> > Thanks, Wayne. See the new attachment with "wxURL" for testing URLs and
> > updated AUTHORS.txt. Retested that both cases (http://... and
> > ${KIPRJMOD}/...) still work.
> >
> > Regards,
> > Cheng
> >
> > On 5 June 2017 at 20:30, Wayne Stambaugh  > > wrote:
> >
> > Hi Cheng,
> >
> > I just tested this patch and it seems to work as advertised without
> > breaking anything so I am going to commit it unless someone else has
> any
> > objections.  For future reference, you might want to us wxUrl[1] to
> test
> > for valid URL strings rather than a custom regex.  I would prefer
> that
> > you use your name in the AUTHORS.txt file rather than "Google, Inc.".
> > I'm OK if you add "Google, Inc." after your name and email address.
> If
> > you don't want to include your email address that's fine but you
> should
> > get credit for your work even if it is on behalf of the company you
> work
> > for.
> >
> >
> > Thanks,
> >
> > Wayne
> >
> > [1]:
> > http://docs.wxwidgets.org/3.0/classwx_u_r_l.html#
> a9837df16ff9f8daf91e5569265cfbe60
> >  a9837df16ff9f8daf91e5569265cfbe60>
> >
> > On 5/31/2017 5:43 PM, Cheng Sheng wrote:
> > > I see. This is also doable. I updated the patch to resolve env vars
> > > instead of relative path. Now "${KIPRJMOD}/Datasheets/tmp.pdf"
> will
> > > work. Thanks for the suggestion.
> > >
> > > Regards,
> > > Cheng
> > >
> > > On 31 May 2017 at 20:53, Nick Østergaard  
> > > >> wrote:
> > >
> > > For the 3D model paths the second example works, hence I would
> have
> > > assumed it would aslo for for other paths. Maybe that is a
> better
> > > solution in this case to keep things consistent.
> > >
> > > 2017-05-31 17:39 GMT+02:00 Cheng Sheng  
> > > >>:
> > > > Hi Nick,
> > > >
> > > > Could you be a little more specific? Do you mean:
> > > >
> > > > "KIPRJMOD/Datasheets/tmp.pdf"? or
> > > > "${KIPRJMOD}/Datasheets/tmp.pdf", or
> > > > "/path/to/my/project/dir/Datasheets/tmp.pdf" when
> > > > KIPRJMOD=/path/to/my/project/dir?
> > > >
> > > > The first two doesn't work because the strings are passed to
> the
> > > browser
> > > > address as is. The third case is not good because if I move
> the
> > > project
> > > > around, the path becomes invalid.
> > > >
> > > > Or none of the cases above is your proposal?
> > > >
> > > > Thanks.
> > > >
> > > > Regards,
> > > > Cheng
> > > >
> > > > On 31 May 2017 at 17:23, Nick Østergaard  
> > > >> wrote:
> > > >>
> > > >> Does it not work by using the KIPRJMOD as is?
> > > >>
> > > >> 2017-05-31 15:17 GMT+02:00 Cheng Sheng <
> jeru.sh...@gmail.com 
> > > >>:
> > > >> > Thanks, Fabrizio. It's good to know such info that is not
> > > mentioned in
> > > >> > the
> > > >> > doc. I'm indeed quite new to contributing code here.
> > > >> >
> > > >> > Regards,
> > > >> > Cheng
> > > >> >
> > > >> > On 31 May 2017 at 13:06, Fabrizio Tappero
> > >  > 
> >  gmail.com>>>
> > > >> > wrote:
> > > >> >>
> > > >> >> Hi Cheng,
> > > >> >>
> > > >> >> Don't worry you are doing just fine.
> > > >> >>
> > > >> >> Whenever somebody submits a patch, he does exactly what
> you did.
> > > >> >> Normally
> > > >> >> it takes some days for the patch 

Re: [Kicad-developers] [PATCH] Speed improvement for Duplicate functionality

[Wayne Stambaugh]

Orson,

Are you still out there?  I haven't heard from you in a while.  Would
you please take a look at this patch when you get a chance.  It looks
reasonable to me but you are the resident expert on the new tool framework.

Thanks,

Wayne

On 6/5/2017 5:59 AM, Jean-Samuel Reynaud wrote:
> Hi,
> 
> I had tested this patch and it's working good for me. For me it's a good
> improvement in term of speed.
> 
> Regards,
> Le 05/06/2017 à 10:13, Oliver Walters a écrit :
>> Friendly bump - has anyone had a chance to review this?
>>
>> On Sun, May 28, 2017 at 11:14 PM, Oliver Walters
>> >
>> wrote:
>>
>> As a follow-up to this, I also notice that if you select a large
>> number of items, the UI hangs for a *very long* time after the
>> selection is complete. The same occurs when you click at an empty
>> position to deselect all items. 
>>
>> Can be a minute or more for large numbers of items.
>>
>> I have not been able to find the cause for this but I do not think
>> it is the fault of SELECTION_TOOL in this case.
>>
>> Oliver
>>
>> On Sun, May 28, 2017 at 10:40 PM, Oliver Walters
>> > > wrote:
>>
>> Hey all,
>>
>> I noticed that the Duplicate functionality in pcbnew / modedit
>> was woefully slow when copying more than a handful of items.
>>
>> I benchmarked it with 1000 items, it took 58 seconds to perform
>> the duplication (KiCAD was at 100% CPU the whole time).
>>
>> I have attached a patch that reduces this time to ~200ms for the
>> same set of items.
>>
>> The speed issue is due to each item being passed through the
>> tool framework multiple times. The patch adds a tool function to
>> select / deselect a list of items with a single call
>>
>> Regards,
>> Oliver
>>
>>
>>
>>
>>
>> ___
>> 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] BOM component table dialog (quasi-)modality in osx

[Wayne Stambaugh]

Hey Dan,

I committed your patch to the master branch.  Thank you for your
contribution to KiCad.

Cheers,

Wayne

On 6/6/2017 12:31 PM, Dan Green wrote:
> Hi Wayne, here’s the patch.
> 
> I appreciate your comments about the confusion over quasi-modal boxes.
> In the future, what would be a good example to follow?
> Perhaps DIALOG_EESCHEMA_OPTIONS?
> 
> thanks
> Dan
> 
> 
> 
> 
> 
>> On Jun 6, 2017, at 8:47 AM, Wayne Stambaugh  wrote:
>>
>> Dan,
>>
>> Would you please send your patch using `git format-patch` as an
>> attachment or inline in an email directly to me so I can commit it?  I
>> tried using the response to your original message with `git am` but it
>> didn't like it and I inadvertently deleted you original post.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 6/5/2017 8:49 AM, Bernhard Stegmaier wrote:
>>> Hi,
>>>
>>> I can confirm that with latest official nightly build (also on 10.12.x).
>>> With my own builds using wxWidgets master (I know… officially unsupported) 
>>> it doesn’t hang but just crashes on closing the window.
>>> Different, but not better… :)
>>>
>>> I also can confirm that the proposed fix works for my own wxWidgets master 
>>> builds (no crash anymore, everything fine after closing the window).
>>> So, I’d vote for submitting it...
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
 On 2. Jun 2017, at 21:06, Wayne Stambaugh  wrote:

 Hello Dan,

 Welcome to the KiCad developer's mailing list and thank you for your
 interest in contributing to KiCad.  We can always use another OSX
 developer.  It's the one platform where we could use the extra help.

 The modal dialog issue became a problem when we moved from a multiple
 binary solution to a single binary solution.  The quasi-modal dialog
 mode allows the main application to continue to receive events while
 blocking events to the window that launched the dialog.  The problem is
 if another modal dialog is launched from the quasi-modal dialog then the
 same problem occurs.  I haven't tried to stack quasi-modal dialog calls
 so I'm not sure what the outcome would be but in theory it should work
 and would be a major improvement over what we have now.  The other
 option is to go modeless but that requires a lot of manual intervention
 between the window that launched the dialog and the dialog itself.  I
 agree that the BOM editor should be launched as quasi-modal rather than
 modal.   FYI, you really should be call EndQuasiModel from with the
 dialog because you cannot know ahead of time how the dialog was
 launched.  This is all handled correctly by the DIALOG_SHIM object close
 event handler.  We still seem to have trouble understanding how to
 properly close dialogs with wxWidgets.  Don't use the code in most of
 the dialogs in KiCad as they are incorrect and are poor examples of how
 to do it correctly.  There are a few that are correct and none of them
 call either EndQuasiModal or EndModal or even handle the OK and/or
 cancel button events.  They use TranferData{To,From}Window for updating
 the data between the controls and the object storage.

 Cheers,

 Wayne


 On 6/1/2017 4:47 PM, Dan Green wrote:
> Hi, 
> I’ve lurked this list for quite some time, and finally applied to join,
> so thank you for approving me. I hope I can make some contributions to
> this excellent project.
>
> I use KiCAD in OSX 10.12 and noticed an issue with the recent BOM
> component table feature.
> When closing the dialog box, the main KiCAD windows and menus still
> behave as if a modal dialog box is still open: all menu items are
> greyed-out, and the windows don't respond to clicks or other events, and
> I have to kill the process from the OS.
>
> After reading some explanations in the comments, I can’t say I fully
> grasp the issue, but when I try invoking and closing the dialog as
> QuasiModal, it seems to work. I don’t know if this breaks it for other
> OS’s or if it violates a UI policy, so please let me know if there’s a
> better way!
>
> Attached is the simple hack I made.
>
> thanks!
>
> From 2253bec68af9b0b4ffc177bccc1325b4702ee084 Mon Sep 17 00:00:00 2001
>
> From: danngreen 
>
> Date: Thu, 1 Jun 2017 13:08:17 -0700
>
> Subject: [PATCH] Made BOM editor dialog quasi modal
>
>
> ---
>
> eeschema/dialogs/dialog_bom_editor.cpp | 4 +++-
>
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>
> diff --git a/eeschema/dialogs/dialog_bom_editor.cpp
> b/eeschema/dialogs/dialog_bom_editor.cpp
>
> index e5114e533..f1d9a9aee 100644
>
> --- a/eeschema/dialogs/dialog_bom_editor.cpp
>
> +++ b/eeschema/dialogs/dialog_bom_editor.cpp
>
> @@ -44,7 +44,7 @@
>
> int 

Re: [Kicad-developers] pull default PDF viewer

[Wayne Stambaugh]

On 6/6/2017 4:17 AM, Fabrizio Tappero wrote:
> ​Apologies for presenting this problem again and again
> 
>  I think this topic came up too many times but (on my linux system) the
> default PDF viewer is not pulled correctly by kiCad. From the terminal:
> 
> $ cat /usr/share/applications/defaults.list  | grep pdf
> application/pdf=xreader.desktop;evince.desktop;atril.desktop

Is this the same as the mime type?  Look at another app such as
Thunderbird and see what app it uses to open PDF files.

> 
> but KiCad insist using Gimp.

Is Preferences->PDF Viewer->System Default PDF Viewer in the KiCad
launcher checked?  If not, KiCad will attempt to fall back on some
reasonable default.  If it is checked, then there is most likely a bug
in wxMimeTypeManager which is used to determine the system command to
open a PDF file.

> 
> can anybody point me to the right direction? I am looking at preferences.cpp

The source file you are looking for is common/gestfich.cpp.  The
function is OpenPDF().

> 
> Cheers
> Fabrizio​
> 
> 
> ___
> 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] Standard field for manufacturer part number in schematic symbols

[Wayne Stambaugh]

I feel the same way.  My guess is that some of this is new users coming
from other EDA apps that provide default fields which we do not provide.
 I personally would rather let users configure fields in the way that
works best for them rather than the KiCad project forcing defaults upon
them.

On 6/6/2017 1:25 PM, Bernhard Stegmaier wrote:
> And why shouldn’t just make all those external tools the field names they 
> look for make configurable on their end?
> Instead of trying to satisfy them all with one field defined on KiCad side?
> I guess someone who wants to setup a serious BOM workflow should be able to 
> configure field names on both sides to match…
> 
> Just my 2 cents…
> 
> 
> Regards,
> Bernhard
> 
>> On 6. Jun 2017, at 18:51, Kristoffer Ödmark  
>> wrote:
>>
>> The main reason for the discussion ( From what i gather ) is that external 
>> tools then have a field they know will be there and can all gather around, 
>> since they know what it is called.
>>
>> I dont really think it needs to be hardcoded as such, it could just be a 
>> default preference to the "JP custom field" table, but then at least there 
>> would be some solid ground to parse or create scripts around, IE anyone can 
>> expect that the field "Manufacturer Part Number" ( for example!) is going to 
>> be there by default. If it has been renamed or removed, so be it. But it can 
>> reasonably be expected to be there.
>>
>> The only thing people agreed upon in this long discussion was that there 
>> should be some field that one can expect to hold a Manufacturer part number. 
>> The only way I see this happening (or not) at this point is that someone 
>> takes an executive decision here, and I believe that Wayne should be the one 
>> saying yay or nay, and decide upon a name. Adding it is probably not very 
>> hard. I could take that upon myself, in whatever form it takes.
>>
>> I also dont think that anyone should have problems creating a script or tool 
>> that parses a field with a spaces in it, if they do have problems with that, 
>> I do not expect that script to be any good anyway :)
>>
>> Regarding the UPN, I think it was just a compromise about the people wanting 
>> a house part number and the ones who wanted a manufacturer part number.
>>
>> - Kristoffer
>>
>> On 2017-06-06 17:48, Fabrizio Tappero wrote:
>>> talking about complains... back on the wild KiCad forum (I did not know 
>>> existed), people are kind of "destroying"  Kaspar's initiative to make 
>>> KiCad a better tool.
>>> Kaspar, I personally support your effort but I do not know how since I do 
>>> not have any special need in the BOM department. I am happy with JP's 
>>> custom table.
>>> One the other hand... I would find schematic variants a way more 
>>> interesting matter. But that is an other episode of the KiCad series.
>>> cheers
>>> Fabrizio
>>> On Tue, Jun 6, 2017 at 5:15 PM, Wayne Stambaugh >> > wrote:
>>>Are the KiCad library developers planning on providing atomic symbol
>>>libraries?  I'm guessing that is the end goal for reserving a name for
>>>an optional field.  I cannot think of any other reason to do this.
>>>On 6/6/2017 9:22 AM, Kristoffer Ödmark wrote:
>>>> Hi!
>>>>
>>>> I will bump this issue again, but to avoid bikesheeding I will ask for 
>>> a
>>>> decision from leader Wayne. Should there be a default field in kicad 
>>> for
>>>> part number and if, what should it be named?
>>>It doesn't matter what I decide.  Since these are optional fields, users
>>>can choose to ignore, change, or delete them.  In my own projects I use
>>>the obvious field name "Manufacturer Part Number".
>>>>
>>>> From what i gather, a field for a part number is the only thing 
>>> everyone
>>>> agrees on, after that everyone has some different standard and wishes
>>>> for default fields ( Tolerances, fitting, vendors, manufacturer,
>>>> housepart etc etc ).
>>>>
>>>> The name for a part number seem field to most favoured to be MPN or
>>>> ManufacturerPart (differs between github and the user forum), although
>>>> UPN for universal part number was suggested and not flamed.
>>>"MPN" it's not very descriptive (human readable).  "ManufacturerPart" is
>>>more descriptive but I'm not thrilled about the camel case name although
>>>I could stomach it.  Field names are not programming language syntax.
>>>They can have spaces in them for readability.  I'm guessing that someone
>>>is using an application where spaces in the field name causes issues but
>>>I'm not sure that should be a concern for KiCad.  I don't much care for
>>>"UPN".  Are manufacturer's even talking about a universal part numbering
>>>system?  I would be very surprised given that manufacturers do their
>>>best to differentiate there products even if they are functionally
>>>equivalent.
>>>I don't 

Re: [Kicad-developers] [RFC] Standard field for manufacturer part number in schematic symbols

[Wayne Stambaugh]

On 6/6/2017 12:51 PM, Kristoffer Ödmark wrote:
> The main reason for the discussion ( From what i gather ) is that
> external tools then have a field they know will be there and can all
> gather around, since they know what it is called.
> 
> I dont really think it needs to be hardcoded as such, it could just be a
> default preference to the "JP custom field" table, but then at least
> there would be some solid ground to parse or create scripts around, IE
> anyone can expect that the field "Manufacturer Part Number" ( for
> example!) is going to be there by default. If it has been renamed or
> removed, so be it. But it can reasonably be expected to be there.

I would be opposed to hard coding it.  It is not required internally by
KiCad.  I'm not sure what you mean by "JP custom field".  Please keep in
mind that if a custom field (the value not the name) is empty, it is not
saved in the schematic file so I'm not sure how we would address that if
that is what you are asking.

> 
> The only thing people agreed upon in this long discussion was that there
> should be some field that one can expect to hold a Manufacturer part
> number. The only way I see this happening (or not) at this point is that
> someone takes an executive decision here, and I believe that Wayne
> should be the one saying yay or nay, and decide upon a name. Adding it
> is probably not very hard. I could take that upon myself, in whatever
> form it takes.

I am less concerned about the name than I am about the implementation
and it's impact on the code.  As of right now, custom fields are stored
in the eeschema config file in the "FieldNames" entry.  We could create
a single default custom field for the manufacturer part number in the
eeschema config code but that's not a very elegant solution.  Maybe we
should add a "FieldNames" entry to the default project file (.pro) that
gets copied to the project folder when a new project is created.  That
can be read and merged with the user's custom fields defined in the
eeschema config file.  This seems like a better solution.  This way if a
user just doesn't like the default, they can just modify their default
project file accordingly.  There may be other potential solutions but
this is the best I can think of at the moment.

> 
> I also dont think that anyone should have problems creating a script or
> tool that parses a field with a spaces in it, if they do have problems
> with that, I do not expect that script to be any good anyway :)
> 
> Regarding the UPN, I think it was just a compromise about the people
> wanting a house part number and the ones who wanted a manufacturer part
> number.
> 
> - Kristoffer
> 
> On 2017-06-06 17:48, Fabrizio Tappero wrote:
>> talking about complains... back on the wild KiCad forum (I did not
>> know existed), people are kind of "destroying"  Kaspar's initiative to
>> make KiCad a better tool.
>>
>> Kaspar, I personally support your effort but I do not know how since I
>> do not have any special need in the BOM department. I am happy with
>> JP's custom table.
>>
>> One the other hand... I would find schematic variants a way more
>> interesting matter. But that is an other episode of the KiCad series.
>>
>> cheers
>> Fabrizio
>>
>>
>> On Tue, Jun 6, 2017 at 5:15 PM, Wayne Stambaugh > > wrote:
>>
>> Are the KiCad library developers planning on providing atomic symbol
>> libraries?  I'm guessing that is the end goal for reserving a name
>> for
>> an optional field.  I cannot think of any other reason to do this.
>>
>> On 6/6/2017 9:22 AM, Kristoffer Ödmark wrote:
>> > Hi!
>> >
>> > I will bump this issue again, but to avoid bikesheeding I will
>> ask for a
>> > decision from leader Wayne. Should there be a default field in
>> kicad for
>> > part number and if, what should it be named?
>>
>> It doesn't matter what I decide.  Since these are optional fields,
>> users
>> can choose to ignore, change, or delete them.  In my own projects
>> I use
>> the obvious field name "Manufacturer Part Number".
>>
>> >
>> > From what i gather, a field for a part number is the only thing
>> everyone
>> > agrees on, after that everyone has some different standard and
>> wishes
>> > for default fields ( Tolerances, fitting, vendors, manufacturer,
>> > housepart etc etc ).
>> >
>> > The name for a part number seem field to most favoured to be MPN or
>> > ManufacturerPart (differs between github and the user forum),
>> although
>> > UPN for universal part number was suggested and not flamed.
>>
>> "MPN" it's not very descriptive (human readable). 
>> "ManufacturerPart" is
>> more descriptive but I'm not thrilled about the camel case name
>> although
>> I could stomach it.  Field names are not programming language syntax.
>> They can have spaces in them for readability.  I'm guessing that
>> someone
>> is using an application where 

Re: [Kicad-developers] [RFC] Standard field for manufacturer part number in schematic symbols

[Bernhard Stegmaier]

And why shouldn’t just make all those external tools the field names they look 
for make configurable on their end?
Instead of trying to satisfy them all with one field defined on KiCad side?
I guess someone who wants to setup a serious BOM workflow should be able to 
configure field names on both sides to match…

Just my 2 cents…


Regards,
Bernhard

> On 6. Jun 2017, at 18:51, Kristoffer Ödmark  
> wrote:
> 
> The main reason for the discussion ( From what i gather ) is that external 
> tools then have a field they know will be there and can all gather around, 
> since they know what it is called.
> 
> I dont really think it needs to be hardcoded as such, it could just be a 
> default preference to the "JP custom field" table, but then at least there 
> would be some solid ground to parse or create scripts around, IE anyone can 
> expect that the field "Manufacturer Part Number" ( for example!) is going to 
> be there by default. If it has been renamed or removed, so be it. But it can 
> reasonably be expected to be there.
> 
> The only thing people agreed upon in this long discussion was that there 
> should be some field that one can expect to hold a Manufacturer part number. 
> The only way I see this happening (or not) at this point is that someone 
> takes an executive decision here, and I believe that Wayne should be the one 
> saying yay or nay, and decide upon a name. Adding it is probably not very 
> hard. I could take that upon myself, in whatever form it takes.
> 
> I also dont think that anyone should have problems creating a script or tool 
> that parses a field with a spaces in it, if they do have problems with that, 
> I do not expect that script to be any good anyway :)
> 
> Regarding the UPN, I think it was just a compromise about the people wanting 
> a house part number and the ones who wanted a manufacturer part number.
> 
> - Kristoffer
> 
> On 2017-06-06 17:48, Fabrizio Tappero wrote:
>> talking about complains... back on the wild KiCad forum (I did not know 
>> existed), people are kind of "destroying"  Kaspar's initiative to make KiCad 
>> a better tool.
>> Kaspar, I personally support your effort but I do not know how since I do 
>> not have any special need in the BOM department. I am happy with JP's custom 
>> table.
>> One the other hand... I would find schematic variants a way more interesting 
>> matter. But that is an other episode of the KiCad series.
>> cheers
>> Fabrizio
>> On Tue, Jun 6, 2017 at 5:15 PM, Wayne Stambaugh > > wrote:
>>Are the KiCad library developers planning on providing atomic symbol
>>libraries?  I'm guessing that is the end goal for reserving a name for
>>an optional field.  I cannot think of any other reason to do this.
>>On 6/6/2017 9:22 AM, Kristoffer Ödmark wrote:
>>> Hi!
>>>
>>> I will bump this issue again, but to avoid bikesheeding I will ask for a
>>> decision from leader Wayne. Should there be a default field in kicad for
>>> part number and if, what should it be named?
>>It doesn't matter what I decide.  Since these are optional fields, users
>>can choose to ignore, change, or delete them.  In my own projects I use
>>the obvious field name "Manufacturer Part Number".
>>>
>>> From what i gather, a field for a part number is the only thing everyone
>>> agrees on, after that everyone has some different standard and wishes
>>> for default fields ( Tolerances, fitting, vendors, manufacturer,
>>> housepart etc etc ).
>>>
>>> The name for a part number seem field to most favoured to be MPN or
>>> ManufacturerPart (differs between github and the user forum), although
>>> UPN for universal part number was suggested and not flamed.
>>"MPN" it's not very descriptive (human readable).  "ManufacturerPart" is
>>more descriptive but I'm not thrilled about the camel case name although
>>I could stomach it.  Field names are not programming language syntax.
>>They can have spaces in them for readability.  I'm guessing that someone
>>is using an application where spaces in the field name causes issues but
>>I'm not sure that should be a concern for KiCad.  I don't much care for
>>"UPN".  Are manufacturer's even talking about a universal part numbering
>>system?  I would be very surprised given that manufacturers do their
>>best to differentiate there products even if they are functionally
>>equivalent.
>>I don't have a strong opinion on this but if I had to pick one of the
>>choices you have given me, I would pick "ManufacturerPart".  Let the
>>complaining commence. ;)
>>I hope this helps!
>>Cheers,
>>Wayne
>> >
>> > Pros:
>> > Easier with a standard for external tools.
>> > Every component has one, not every component has values, many
>>have both.
>> > Is optional to use, so will not break anything for 

Re: [Kicad-developers] [RFC] Standard field for manufacturer part number in schematic symbols

[Kristoffer Ödmark]

The main reason for the discussion ( From what i gather ) is that 
external tools then have a field they know will be there and can all 
gather around, since they know what it is called.


I dont really think it needs to be hardcoded as such, it could just be a 
default preference to the "JP custom field" table, but then at least 
there would be some solid ground to parse or create scripts around, IE 
anyone can expect that the field "Manufacturer Part Number" ( for 
example!) is going to be there by default. If it has been renamed or 
removed, so be it. But it can reasonably be expected to be there.


The only thing people agreed upon in this long discussion was that there 
should be some field that one can expect to hold a Manufacturer part 
number. The only way I see this happening (or not) at this point is that 
someone takes an executive decision here, and I believe that Wayne 
should be the one saying yay or nay, and decide upon a name. Adding it 
is probably not very hard. I could take that upon myself, in whatever 
form it takes.


I also dont think that anyone should have problems creating a script or 
tool that parses a field with a spaces in it, if they do have problems 
with that, I do not expect that script to be any good anyway :)


Regarding the UPN, I think it was just a compromise about the people 
wanting a house part number and the ones who wanted a manufacturer part 
number.


- Kristoffer

On 2017-06-06 17:48, Fabrizio Tappero wrote:
talking about complains... back on the wild KiCad forum (I did not know 
existed), people are kind of "destroying"  Kaspar's initiative to make 
KiCad a better tool.


Kaspar, I personally support your effort but I do not know how since I 
do not have any special need in the BOM department. I am happy with JP's 
custom table.


One the other hand... I would find schematic variants a way more 
interesting matter. But that is an other episode of the KiCad series.


cheers
Fabrizio


On Tue, Jun 6, 2017 at 5:15 PM, Wayne Stambaugh > wrote:


Are the KiCad library developers planning on providing atomic symbol
libraries?  I'm guessing that is the end goal for reserving a name for
an optional field.  I cannot think of any other reason to do this.

On 6/6/2017 9:22 AM, Kristoffer Ödmark wrote:
> Hi!
>
> I will bump this issue again, but to avoid bikesheeding I will ask for a
> decision from leader Wayne. Should there be a default field in kicad for
> part number and if, what should it be named?

It doesn't matter what I decide.  Since these are optional fields, users
can choose to ignore, change, or delete them.  In my own projects I use
the obvious field name "Manufacturer Part Number".

>
> From what i gather, a field for a part number is the only thing everyone
> agrees on, after that everyone has some different standard and wishes
> for default fields ( Tolerances, fitting, vendors, manufacturer,
> housepart etc etc ).
>
> The name for a part number seem field to most favoured to be MPN or
> ManufacturerPart (differs between github and the user forum), although
> UPN for universal part number was suggested and not flamed.

"MPN" it's not very descriptive (human readable).  "ManufacturerPart" is
more descriptive but I'm not thrilled about the camel case name although
I could stomach it.  Field names are not programming language syntax.
They can have spaces in them for readability.  I'm guessing that someone
is using an application where spaces in the field name causes issues but
I'm not sure that should be a concern for KiCad.  I don't much care for
"UPN".  Are manufacturer's even talking about a universal part numbering
system?  I would be very surprised given that manufacturers do their
best to differentiate there products even if they are functionally
equivalent.

I don't have a strong opinion on this but if I had to pick one of the
choices you have given me, I would pick "ManufacturerPart".  Let the
complaining commence. ;)

I hope this helps!

Cheers,

Wayne

 >
 > Pros:
 > Easier with a standard for external tools.
 > Every component has one, not every component has values, many
have both.
 > Is optional to use, so will not break anything for anyone not
wanting to
 > use it
 >
 > Cons:
 > Some are worried the fields will be impossible to keep updated in the
 > standard libs
 > Some people are using House numbers instead
 > Some think this data should not be in the schematic but handled
by other
 > tools
 >
 > Links to discussions I you want to read it:
 >

https://forum.kicad.info/t/default-manufacturers-part-number-field-in-kicad-libraries/4387/28


 >
 > 

Re: [Kicad-developers] BOM component table dialog (quasi-)modality in osx

[Dan Green]

Hi Wayne, here’s the patch.

I appreciate your comments about the confusion over quasi-modal boxes.
In the future, what would be a good example to follow?
Perhaps DIALOG_EESCHEMA_OPTIONS?

thanks
Dan



0001-Made-BOM-editor-dialog-quasi-modal.patch
Description: Binary data


> On Jun 6, 2017, at 8:47 AM, Wayne Stambaugh  wrote:
> 
> Dan,
> 
> Would you please send your patch using `git format-patch` as an
> attachment or inline in an email directly to me so I can commit it?  I
> tried using the response to your original message with `git am` but it
> didn't like it and I inadvertently deleted you original post.
> 
> Thanks,
> 
> Wayne
> 
> On 6/5/2017 8:49 AM, Bernhard Stegmaier wrote:
>> Hi,
>> 
>> I can confirm that with latest official nightly build (also on 10.12.x).
>> With my own builds using wxWidgets master (I know… officially unsupported) 
>> it doesn’t hang but just crashes on closing the window.
>> Different, but not better… :)
>> 
>> I also can confirm that the proposed fix works for my own wxWidgets master 
>> builds (no crash anymore, everything fine after closing the window).
>> So, I’d vote for submitting it...
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 2. Jun 2017, at 21:06, Wayne Stambaugh  wrote:
>>> 
>>> Hello Dan,
>>> 
>>> Welcome to the KiCad developer's mailing list and thank you for your
>>> interest in contributing to KiCad.  We can always use another OSX
>>> developer.  It's the one platform where we could use the extra help.
>>> 
>>> The modal dialog issue became a problem when we moved from a multiple
>>> binary solution to a single binary solution.  The quasi-modal dialog
>>> mode allows the main application to continue to receive events while
>>> blocking events to the window that launched the dialog.  The problem is
>>> if another modal dialog is launched from the quasi-modal dialog then the
>>> same problem occurs.  I haven't tried to stack quasi-modal dialog calls
>>> so I'm not sure what the outcome would be but in theory it should work
>>> and would be a major improvement over what we have now.  The other
>>> option is to go modeless but that requires a lot of manual intervention
>>> between the window that launched the dialog and the dialog itself.  I
>>> agree that the BOM editor should be launched as quasi-modal rather than
>>> modal.   FYI, you really should be call EndQuasiModel from with the
>>> dialog because you cannot know ahead of time how the dialog was
>>> launched.  This is all handled correctly by the DIALOG_SHIM object close
>>> event handler.  We still seem to have trouble understanding how to
>>> properly close dialogs with wxWidgets.  Don't use the code in most of
>>> the dialogs in KiCad as they are incorrect and are poor examples of how
>>> to do it correctly.  There are a few that are correct and none of them
>>> call either EndQuasiModal or EndModal or even handle the OK and/or
>>> cancel button events.  They use TranferData{To,From}Window for updating
>>> the data between the controls and the object storage.
>>> 
>>> Cheers,
>>> 
>>> Wayne
>>> 
>>> 
>>> On 6/1/2017 4:47 PM, Dan Green wrote:
 Hi, 
 I’ve lurked this list for quite some time, and finally applied to join,
 so thank you for approving me. I hope I can make some contributions to
 this excellent project.
 
 I use KiCAD in OSX 10.12 and noticed an issue with the recent BOM
 component table feature.
 When closing the dialog box, the main KiCAD windows and menus still
 behave as if a modal dialog box is still open: all menu items are
 greyed-out, and the windows don't respond to clicks or other events, and
 I have to kill the process from the OS.
 
 After reading some explanations in the comments, I can’t say I fully
 grasp the issue, but when I try invoking and closing the dialog as
 QuasiModal, it seems to work. I don’t know if this breaks it for other
 OS’s or if it violates a UI policy, so please let me know if there’s a
 better way!
 
 Attached is the simple hack I made.
 
 thanks!
 
 From 2253bec68af9b0b4ffc177bccc1325b4702ee084 Mon Sep 17 00:00:00 2001
 
 From: danngreen 
 
 Date: Thu, 1 Jun 2017 13:08:17 -0700
 
 Subject: [PATCH] Made BOM editor dialog quasi modal
 
 
 ---
 
 eeschema/dialogs/dialog_bom_editor.cpp | 4 +++-
 
 1 file changed, 3 insertions(+), 1 deletion(-)
 
 
 diff --git a/eeschema/dialogs/dialog_bom_editor.cpp
 b/eeschema/dialogs/dialog_bom_editor.cpp
 
 index e5114e533..f1d9a9aee 100644
 
 --- a/eeschema/dialogs/dialog_bom_editor.cpp
 
 +++ b/eeschema/dialogs/dialog_bom_editor.cpp
 
 @@ -44,7 +44,7 @@
 
 int InvokeDialogCreateBOMEditor( SCH_EDIT_FRAME* aCaller )
 
 {
 
DIALOG_BOM_EDITOR dlg( aCaller );
 
 -return dlg.ShowModal();
 
 +return dlg.ShowQuasiModal();

Re: [Kicad-developers] BOM component table dialog (quasi-)modality in osx

[Wayne Stambaugh]

Dan,

Would you please send your patch using `git format-patch` as an
attachment or inline in an email directly to me so I can commit it?  I
tried using the response to your original message with `git am` but it
didn't like it and I inadvertently deleted you original post.

Thanks,

Wayne

On 6/5/2017 8:49 AM, Bernhard Stegmaier wrote:
> Hi,
> 
> I can confirm that with latest official nightly build (also on 10.12.x).
> With my own builds using wxWidgets master (I know… officially unsupported) it 
> doesn’t hang but just crashes on closing the window.
> Different, but not better… :)
> 
> I also can confirm that the proposed fix works for my own wxWidgets master 
> builds (no crash anymore, everything fine after closing the window).
> So, I’d vote for submitting it...
> 
> 
> Regards,
> Bernhard
> 
>> On 2. Jun 2017, at 21:06, Wayne Stambaugh  wrote:
>>
>> Hello Dan,
>>
>> Welcome to the KiCad developer's mailing list and thank you for your
>> interest in contributing to KiCad.  We can always use another OSX
>> developer.  It's the one platform where we could use the extra help.
>>
>> The modal dialog issue became a problem when we moved from a multiple
>> binary solution to a single binary solution.  The quasi-modal dialog
>> mode allows the main application to continue to receive events while
>> blocking events to the window that launched the dialog.  The problem is
>> if another modal dialog is launched from the quasi-modal dialog then the
>> same problem occurs.  I haven't tried to stack quasi-modal dialog calls
>> so I'm not sure what the outcome would be but in theory it should work
>> and would be a major improvement over what we have now.  The other
>> option is to go modeless but that requires a lot of manual intervention
>> between the window that launched the dialog and the dialog itself.  I
>> agree that the BOM editor should be launched as quasi-modal rather than
>> modal.   FYI, you really should be call EndQuasiModel from with the
>> dialog because you cannot know ahead of time how the dialog was
>> launched.  This is all handled correctly by the DIALOG_SHIM object close
>> event handler.  We still seem to have trouble understanding how to
>> properly close dialogs with wxWidgets.  Don't use the code in most of
>> the dialogs in KiCad as they are incorrect and are poor examples of how
>> to do it correctly.  There are a few that are correct and none of them
>> call either EndQuasiModal or EndModal or even handle the OK and/or
>> cancel button events.  They use TranferData{To,From}Window for updating
>> the data between the controls and the object storage.
>>
>> Cheers,
>>
>> Wayne
>>
>>
>> On 6/1/2017 4:47 PM, Dan Green wrote:
>>> Hi, 
>>> I’ve lurked this list for quite some time, and finally applied to join,
>>> so thank you for approving me. I hope I can make some contributions to
>>> this excellent project.
>>>
>>> I use KiCAD in OSX 10.12 and noticed an issue with the recent BOM
>>> component table feature.
>>> When closing the dialog box, the main KiCAD windows and menus still
>>> behave as if a modal dialog box is still open: all menu items are
>>> greyed-out, and the windows don't respond to clicks or other events, and
>>> I have to kill the process from the OS.
>>>
>>> After reading some explanations in the comments, I can’t say I fully
>>> grasp the issue, but when I try invoking and closing the dialog as
>>> QuasiModal, it seems to work. I don’t know if this breaks it for other
>>> OS’s or if it violates a UI policy, so please let me know if there’s a
>>> better way!
>>>
>>> Attached is the simple hack I made.
>>>
>>> thanks!
>>>
>>> From 2253bec68af9b0b4ffc177bccc1325b4702ee084 Mon Sep 17 00:00:00 2001
>>>
>>> From: danngreen 
>>>
>>> Date: Thu, 1 Jun 2017 13:08:17 -0700
>>>
>>> Subject: [PATCH] Made BOM editor dialog quasi modal
>>>
>>>
>>> ---
>>>
>>> eeschema/dialogs/dialog_bom_editor.cpp | 4 +++-
>>>
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>>
>>> diff --git a/eeschema/dialogs/dialog_bom_editor.cpp
>>> b/eeschema/dialogs/dialog_bom_editor.cpp
>>>
>>> index e5114e533..f1d9a9aee 100644
>>>
>>> --- a/eeschema/dialogs/dialog_bom_editor.cpp
>>>
>>> +++ b/eeschema/dialogs/dialog_bom_editor.cpp
>>>
>>> @@ -44,7 +44,7 @@
>>>
>>> int InvokeDialogCreateBOMEditor( SCH_EDIT_FRAME* aCaller )
>>>
>>> {
>>>
>>> DIALOG_BOM_EDITOR dlg( aCaller );
>>>
>>> -return dlg.ShowModal();
>>>
>>> +return dlg.ShowQuasiModal();
>>>
>>> }
>>>
>>>
>>>
>>> DIALOG_BOM_EDITOR::DIALOG_BOM_EDITOR( SCH_EDIT_FRAME* parent ) :
>>>
>>> @@ -129,6 +129,7 @@ bool DIALOG_BOM_EDITOR::CloseDialog()
>>>
>>> {
>>>
>>> if( !m_bom->HaveFieldsChanged() )
>>>
>>> {
>>>
>>> +EndQuasiModal( wxID_CANCEL );
>>>
>>> Destroy();
>>>
>>> return true;
>>>
>>> }
>>>
>>> @@ -146,6 +147,7 @@ bool DIALOG_BOM_EDITOR::CloseDialog()
>>>
>>>break;
>>>
>>> }
>>>
>>>
>>>
>>> +EndQuasiModal( wxID_CANCEL );
>>>
>>> 

Re: [Kicad-developers] [RFC] Standard field for manufacturer part number in schematic symbols

[Wayne Stambaugh]

Are the KiCad library developers planning on providing atomic symbol
libraries?  I'm guessing that is the end goal for reserving a name for
an optional field.  I cannot think of any other reason to do this.

On 6/6/2017 9:22 AM, Kristoffer Ödmark wrote:
> Hi!
> 
> I will bump this issue again, but to avoid bikesheeding I will ask for a
> decision from leader Wayne. Should there be a default field in kicad for
> part number and if, what should it be named?

It doesn't matter what I decide.  Since these are optional fields, users
can choose to ignore, change, or delete them.  In my own projects I use
the obvious field name "Manufacturer Part Number".

> 
> From what i gather, a field for a part number is the only thing everyone
> agrees on, after that everyone has some different standard and wishes
> for default fields ( Tolerances, fitting, vendors, manufacturer,
> housepart etc etc ).
> 
> The name for a part number seem field to most favoured to be MPN or
> ManufacturerPart (differs between github and the user forum), although
> UPN for universal part number was suggested and not flamed.

"MPN" it's not very descriptive (human readable).  "ManufacturerPart" is
more descriptive but I'm not thrilled about the camel case name although
I could stomach it.  Field names are not programming language syntax.
They can have spaces in them for readability.  I'm guessing that someone
is using an application where spaces in the field name causes issues but
I'm not sure that should be a concern for KiCad.  I don't much care for
"UPN".  Are manufacturer's even talking about a universal part numbering
system?  I would be very surprised given that manufacturers do their
best to differentiate there products even if they are functionally
equivalent.

I don't have a strong opinion on this but if I had to pick one of the
choices you have given me, I would pick "ManufacturerPart".  Let the
complaining commence. ;)

I hope this helps!

Cheers,

Wayne

> 
> Pros:
> Easier with a standard for external tools.
> Every component has one, not every component has values, many have both.
> Is optional to use, so will not break anything for anyone not wanting to
> use it
> 
> Cons:
> Some are worried the fields will be impossible to keep updated in the
> standard libs
> Some people are using House numbers instead
> Some think this data should not be in the schematic but handled by other
> tools
> 
> Links to discussions I you want to read it:
> https://forum.kicad.info/t/default-manufacturers-part-number-field-in-kicad-libraries/4387/28
> 
> https://github.com/KiCad/kicad-library/issues/808
> https://forum.kicad.info/t/standard-symbol-field-names-initiative/4870/3
> 
> 
> 
> On 2017-01-12 20:12, Kaspar Emanuel wrote:
>> I have put up a proposal for a "community standard" on the forum:
>> https://forum.kicad.info/t/standard-symbol-field-names-initiative/4870/1
>>
>> On 12 January 2017 at 18:33, Kaspar Emanuel > > wrote:
>>
>>
>> On 12 January 2017 at 16:44, Kaspar Emanuel
>> > wrote:
>>
>>
>> Is there actually any issue, internally to KiCAD, with creating
>> multiple fields with the same name? It seems to let me create
>> two fields called MPN and save and re-open without a problem.
>>
>>
>> Actually, just tested again and it doesn't like fields with the same
>> name, it simply overwrites them once you press ok, not sure what I
>> was doing before. That's a shame.
>>
>>
>>
>>
>> ___
>> 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] menu icons

[Marco Ciampa]

On Tue, Jun 06, 2017 at 09:46:42AM -0400, Wayne Stambaugh wrote:
> On 6/6/2017 3:14 AM, Marco Ciampa wrote:
> > On Mon, Jun 05, 2017 at 05:37:32PM -0500, José Ignacio wrote:
> >> Menu icons are disabled by default in gnome 3 in an effort to make it look
> >> more like an Apple product. You can enable them (on gtk 3.10+) with:
> >>
> >> gsettings set org.gnome.settings-daemon.plugins.xsettings overrides
> >> "{'Gtk/ButtonImages': <1>, 'Gtk/MenuImages': <1>}"
> > 
> > So the 
> > 
> > Preference->Icon options->Icons in menu
> > 
> > is there for what?
> 
> This controls the menu icon visibility at the application level.  

Yes sorry, I was too precipitous as always... it works...

> The solution above applies to all applications build with gtk. 

> I don't understand why the gnome project made it so difficult 
> to enable them.
> This seems like a perfectly valid user preference.

Yes and the whole "registry" concept copied from the Windows world that
seems to me awkward at best...

As always, thanks for your patience,
Regards,

-- 


Marco Ciampa

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



 GNU/Linux User #78271
 FSFE fellow #364




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

Re: [Kicad-developers] [RFC] Standard field for manufacturer part number in schematic symbols

[Fabrizio Tappero]

​Hi there,​

Just in case somebody does not know what JP means here, I share my personal
​ preference setting​
:

 KiCad - Schematic - Preferences - Schematic Editor Options - Default Fields

​[image: Inline image 1]​

I personally think that JP suggestion is the solution to the basic problem
that Kaspar is talking about. I have to agree however with Kaspar when
 he says that a "MPN" is more meaningful than the
"datasheet" default field.

At the end of the day a schematic is made of components that deserve an
ID or a MPN.

my 2c
Fabrizio





On Wed, Dec 21, 2016 at 6:01 PM, jp charras  wrote:

> Le 21/12/2016 à 17:19, Kaspar Emanuel a écrit :
> > Thank you Clemens and Kevin for your responses.
> >
> > Clemens, you raise that you are not happy with hard-coding fields at all
> because there is no
> > standard way to do it. But KiCad’s symbols already come with a datasheet
> field for instance. To me,
> > the datasheet field is way less useful than an MPN field. In any case we
> are trying to come up with
> > a better, standard way to do it, what's the problem with that?
> >
> > You then go on to describe your method and say you have no use case for
> it. That’s fair enough but I
> > think its clean that I and a few other people /do/ have a use case.
> Furthermore, the proposal, if
> > implemented, shouldn’t affect your way of working at all.
> >
> > Kevin, you say that this would not work for generic components like
> resistors and capacitors. I
> > don’t think I was clear enough: the proposal is to add a standard MPN
> field to schematic symbols to
> > be populated /when they are part of a schematic/, i.e. their values (and
> tolerances etc) have been
> > assigned. Really we are talking about the schematic format.
>
> Kaspar,
>
> Adding a new field does not imply a schematic format change.
> You can already add any field to a schematic component or a library
> component (library part)
>
> I don't really understand why you are thinking the schematic file format
> should be modified.
>
> If you want to see a user field always existing in your component editor,
> just add this field name
> and a default value in the schematic editor options (Default fields).
>
> The feature you want is already available since many years in Eeschema.
>
> The spice simulator also uses predefined fields to store simulator
> parameters in lib or in schematic.
> AFAIK, it works without issues, and without any change in schematic file
> format.
>
> For me, the main question is:
> From the point of view of the *schematic editor*, what is the purpose of
> this field?
> (I am not talking about the user point of view)
>
> >
> > Your alternative system is interesting but/is/ a bit more complicated.
> Standardizing on an MPN field
> > is something existing tooling could make use of very quickly but with
> yours they would have to
> > change their way of working quite substantively. I think further
> discussion of your proposal is a
> > separate point and should continue in another thread.
> >
> > All the best,
> >
> > Kaspar
> >
>
> --
> 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] [PATCH] Reunion of zoom toolbar buttons

[Fabrizio Tappero]

Hi Wayne,
there are some little tiny quirks like this in kicad. It is just
matter of time and we will fix them all !

cheers
Fabrizio


On Tue, Jun 6, 2017 at 3:41 PM, Wayne Stambaugh  wrote:
> Bernhard,
>
> I committed your patch.  Good catch.  I never even noticed this before
> but it definitely makes more sense to group all of the zoom buttons
> together.
>
> Thanks,
>
> Wayne
>
> On 6/5/2017 2:17 PM, Bernhard Stegmaier wrote:
>> Hi,
>>
>> I use KiCad for some while now, but I only recently noticed that there is a 
>> “zoom to selection” function/button in the right toolbox.
>> Don’t know why, maybe because of an icon change.
>>
>> I guess the main reason that I didn’t notice it before was that I just 
>> didn’t expect it to be in the right toolbar with all the schema, PCB, etc. 
>> related (drawing) stuff. And, in contrast having all the other zoom buttons 
>> in the top toolbar.
>>
>> Attached a patch that moves “zoom selection” into top toolbar next to the 
>> other zoom buttons.
>> It further slightly switches buttons so that all zoom buttons are next to 
>> each other:
>>
>>
>>
>>
>>
>> For my taste it makes much more sense like this.
>> However, if there are good reasons against it or many don’t like it, then 
>> just ignore it… :)
>>
>>
>> Regards,
>> Bernhard
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> 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] menu icons

[Wayne Stambaugh]

On 6/6/2017 3:14 AM, Marco Ciampa wrote:
> On Mon, Jun 05, 2017 at 05:37:32PM -0500, José Ignacio wrote:
>> Menu icons are disabled by default in gnome 3 in an effort to make it look
>> more like an Apple product. You can enable them (on gtk 3.10+) with:
>>
>> gsettings set org.gnome.settings-daemon.plugins.xsettings overrides
>> "{'Gtk/ButtonImages': <1>, 'Gtk/MenuImages': <1>}"
> 
> So the 
> 
> Preference->Icon options->Icons in menu
> 
> is there for what?

This controls the menu icon visibility at the application level.  The
solution above applies to all applications build with gtk.  I don't
understand why the gnome project made it so difficult to enable them.
This seems like a perfectly valid user preference.

> 
> TIA
> 
> Regards,
> 
> --
> 
> 
> Marco Ciampa
> 
> I know a joke about UDP, but you might not get it.
> 
> 
> 
>  GNU/Linux User #78271
>  FSFE fellow #364
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] [PATCH] Reunion of zoom toolbar buttons

[Wayne Stambaugh]

Bernhard,

I committed your patch.  Good catch.  I never even noticed this before
but it definitely makes more sense to group all of the zoom buttons
together.

Thanks,

Wayne

On 6/5/2017 2:17 PM, Bernhard Stegmaier wrote:
> Hi,
> 
> I use KiCad for some while now, but I only recently noticed that there is a 
> “zoom to selection” function/button in the right toolbox.
> Don’t know why, maybe because of an icon change.
> 
> I guess the main reason that I didn’t notice it before was that I just didn’t 
> expect it to be in the right toolbar with all the schema, PCB, etc. related 
> (drawing) stuff. And, in contrast having all the other zoom buttons in the 
> top toolbar.
> 
> Attached a patch that moves “zoom selection” into top toolbar next to the 
> other zoom buttons.
> It further slightly switches buttons so that all zoom buttons are next to 
> each other:
> 
> 
> 
> 
> 
> For my taste it makes much more sense like this.
> However, if there are good reasons against it or many don’t like it, then 
> just ignore it… :)
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
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] Standard field for manufacturer part number in schematic symbols

[Kristoffer Ödmark]

Hi!

I will bump this issue again, but to avoid bikesheeding I will ask for a 
decision from leader Wayne. Should there be a default field in kicad for 
part number and if, what should it be named?


From what i gather, a field for a part number is the only thing 
everyone agrees on, after that everyone has some different standard and 
wishes for default fields ( Tolerances, fitting, vendors, manufacturer, 
housepart etc etc ).


The name for a part number seem field to most favoured to be MPN or 
ManufacturerPart (differs between github and the user forum), although 
UPN for universal part number was suggested and not flamed.


Pros:
Easier with a standard for external tools.
Every component has one, not every component has values, many have both.
Is optional to use, so will not break anything for anyone not wanting to 
use it


Cons:
Some are worried the fields will be impossible to keep updated in the 
standard libs

Some people are using House numbers instead
Some think this data should not be in the schematic but handled by other 
tools


Links to discussions I you want to read it:
https://forum.kicad.info/t/default-manufacturers-part-number-field-in-kicad-libraries/4387/28
https://github.com/KiCad/kicad-library/issues/808
https://forum.kicad.info/t/standard-symbol-field-names-initiative/4870/3



On 2017-01-12 20:12, Kaspar Emanuel wrote:
I have put up a proposal for a "community standard" on the forum: 
https://forum.kicad.info/t/standard-symbol-field-names-initiative/4870/1


On 12 January 2017 at 18:33, Kaspar Emanuel > wrote:



On 12 January 2017 at 16:44, Kaspar Emanuel
> wrote:


Is there actually any issue, internally to KiCAD, with creating
multiple fields with the same name? It seems to let me create
two fields called MPN and save and re-open without a problem. 




Actually, just tested again and it doesn't like fields with the same
name, it simply overwrites them once you press ok, not sure what I
was doing before. That's a shame.




___
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: Open Datasheet in Project Dir

[Wayne Stambaugh]

Cheng,

I committed you patch to the master branch.  Thank you for making the
changes I suggested and your contribution to KiCad.  One minor note,
your revised patch had tabs which violate the KiCad Coding Policy[1].  I
fixed them this time.  In the future please make sure to have your
editor configured to use spaces.

Cheers,

Wayne

[1]
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html

On 6/6/2017 8:17 AM, Cheng Sheng wrote:
> Thanks, Wayne. See the new attachment with "wxURL" for testing URLs and
> updated AUTHORS.txt. Retested that both cases (http://... and
> ${KIPRJMOD}/...) still work.
> 
> Regards,
> Cheng
> 
> On 5 June 2017 at 20:30, Wayne Stambaugh  > wrote:
> 
> Hi Cheng,
> 
> I just tested this patch and it seems to work as advertised without
> breaking anything so I am going to commit it unless someone else has any
> objections.  For future reference, you might want to us wxUrl[1] to test
> for valid URL strings rather than a custom regex.  I would prefer that
> you use your name in the AUTHORS.txt file rather than "Google, Inc.".
> I'm OK if you add "Google, Inc." after your name and email address.  If
> you don't want to include your email address that's fine but you should
> get credit for your work even if it is on behalf of the company you work
> for.
> 
> 
> Thanks,
> 
> Wayne
> 
> [1]:
> 
> http://docs.wxwidgets.org/3.0/classwx_u_r_l.html#a9837df16ff9f8daf91e5569265cfbe60
> 
> 
> 
> On 5/31/2017 5:43 PM, Cheng Sheng wrote:
> > I see. This is also doable. I updated the patch to resolve env vars
> > instead of relative path. Now "${KIPRJMOD}/Datasheets/tmp.pdf" will
> > work. Thanks for the suggestion.
> >
> > Regards,
> > Cheng
> >
> > On 31 May 2017 at 20:53, Nick Østergaard  
> > >> wrote:
> >
> > For the 3D model paths the second example works, hence I would have
> > assumed it would aslo for for other paths. Maybe that is a better
> > solution in this case to keep things consistent.
> >
> > 2017-05-31 17:39 GMT+02:00 Cheng Sheng  
> > >>:
> > > Hi Nick,
> > >
> > > Could you be a little more specific? Do you mean:
> > >
> > > "KIPRJMOD/Datasheets/tmp.pdf"? or
> > > "${KIPRJMOD}/Datasheets/tmp.pdf", or
> > > "/path/to/my/project/dir/Datasheets/tmp.pdf" when
> > > KIPRJMOD=/path/to/my/project/dir?
> > >
> > > The first two doesn't work because the strings are passed to the
> > browser
> > > address as is. The third case is not good because if I move the
> > project
> > > around, the path becomes invalid.
> > >
> > > Or none of the cases above is your proposal?
> > >
> > > Thanks.
> > >
> > > Regards,
> > > Cheng
> > >
> > > On 31 May 2017 at 17:23, Nick Østergaard  
> > >> wrote:
> > >>
> > >> Does it not work by using the KIPRJMOD as is?
> > >>
> > >> 2017-05-31 15:17 GMT+02:00 Cheng Sheng  
> > >>:
> > >> > Thanks, Fabrizio. It's good to know such info that is not
> > mentioned in
> > >> > the
> > >> > doc. I'm indeed quite new to contributing code here.
> > >> >
> > >> > Regards,
> > >> > Cheng
> > >> >
> > >> > On 31 May 2017 at 13:06, Fabrizio Tappero
> >  
> >>
> > >> > wrote:
> > >> >>
> > >> >> Hi Cheng,
> > >> >>
> > >> >> Don't worry you are doing just fine.
> > >> >>
> > >> >> Whenever somebody submits a patch, he does exactly what you 
> did.
> > >> >> Normally
> > >> >> it takes some days for the patch to get submitted because in
> > these days
> > >> >> several people express opinions and feedback, as in your case.
> > >> >>
> > >> >> If nobody is against it and if the patch is useful for KiCad,
> > the patch
> > >> >> is
> > >> >> applied to the main repo in few days. A gentle reminder is a
> > good way
> > >> >> to
> > >> >> communicate with 

Re: [Kicad-developers] Patch: Open Datasheet in Project Dir

[Cheng Sheng]

Thanks, Wayne. See the new attachment with "wxURL" for testing URLs and
updated AUTHORS.txt. Retested that both cases (http://... and
${KIPRJMOD}/...) still work.

Regards,
Cheng

On 5 June 2017 at 20:30, Wayne Stambaugh  wrote:

> Hi Cheng,
>
> I just tested this patch and it seems to work as advertised without
> breaking anything so I am going to commit it unless someone else has any
> objections.  For future reference, you might want to us wxUrl[1] to test
> for valid URL strings rather than a custom regex.  I would prefer that
> you use your name in the AUTHORS.txt file rather than "Google, Inc.".
> I'm OK if you add "Google, Inc." after your name and email address.  If
> you don't want to include your email address that's fine but you should
> get credit for your work even if it is on behalf of the company you work
> for.
>

> Thanks,
>
> Wayne
>
> [1]:
> http://docs.wxwidgets.org/3.0/classwx_u_r_l.html#
> a9837df16ff9f8daf91e5569265cfbe60
>
> On 5/31/2017 5:43 PM, Cheng Sheng wrote:
> > I see. This is also doable. I updated the patch to resolve env vars
> > instead of relative path. Now "${KIPRJMOD}/Datasheets/tmp.pdf" will
> > work. Thanks for the suggestion.
> >
> > Regards,
> > Cheng
> >
> > On 31 May 2017 at 20:53, Nick Østergaard  > > wrote:
> >
> > For the 3D model paths the second example works, hence I would have
> > assumed it would aslo for for other paths. Maybe that is a better
> > solution in this case to keep things consistent.
> >
> > 2017-05-31 17:39 GMT+02:00 Cheng Sheng  > >:
> > > Hi Nick,
> > >
> > > Could you be a little more specific? Do you mean:
> > >
> > > "KIPRJMOD/Datasheets/tmp.pdf"? or
> > > "${KIPRJMOD}/Datasheets/tmp.pdf", or
> > > "/path/to/my/project/dir/Datasheets/tmp.pdf" when
> > > KIPRJMOD=/path/to/my/project/dir?
> > >
> > > The first two doesn't work because the strings are passed to the
> > browser
> > > address as is. The third case is not good because if I move the
> > project
> > > around, the path becomes invalid.
> > >
> > > Or none of the cases above is your proposal?
> > >
> > > Thanks.
> > >
> > > Regards,
> > > Cheng
> > >
> > > On 31 May 2017 at 17:23, Nick Østergaard  > > wrote:
> > >>
> > >> Does it not work by using the KIPRJMOD as is?
> > >>
> > >> 2017-05-31 15:17 GMT+02:00 Cheng Sheng  > >:
> > >> > Thanks, Fabrizio. It's good to know such info that is not
> > mentioned in
> > >> > the
> > >> > doc. I'm indeed quite new to contributing code here.
> > >> >
> > >> > Regards,
> > >> > Cheng
> > >> >
> > >> > On 31 May 2017 at 13:06, Fabrizio Tappero
> > >
> > >> > wrote:
> > >> >>
> > >> >> Hi Cheng,
> > >> >>
> > >> >> Don't worry you are doing just fine.
> > >> >>
> > >> >> Whenever somebody submits a patch, he does exactly what you
> did.
> > >> >> Normally
> > >> >> it takes some days for the patch to get submitted because in
> > these days
> > >> >> several people express opinions and feedback, as in your case.
> > >> >>
> > >> >> If nobody is against it and if the patch is useful for KiCad,
> > the patch
> > >> >> is
> > >> >> applied to the main repo in few days. A gentle reminder is a
> > good way
> > >> >> to
> > >> >> communicate with people with kicad repo writing rights.
> > >> >>
> > >> >> I hope you will submit more stuff. Contributing can be quite a
> > >> >> rewarding
> > >> >> experience, I think. Just remember that the dev. community
> > decides what
> > >> >> goes
> > >> >> in and what stays out. And normally common good is paramount.
> > >> >>
> > >> >> cheers
> > >> >> Fabrizio
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Wed, May 31, 2017 at 11:49 AM, Cheng Sheng
> > >
> > >> >> wrote:
> > >> >>>
> > >> >>> okay, thanks for the info, Sergey.
> > >> >>>
> > >> >>> Don't find any explicit rule on how to select reviewers on
> > the how to
> > >> >>> contribute page. So cc Jean-Pierre because you did a lot of
> > commits
> > >> >>> recently. Let me know or reassign if there's some duty
> > partitioning.
> > >> >>> Thanks.
> > >> >>>
> > >> >>> Regards,
> > >> >>> Cheng
> > >> >>>
> > >> >>> On 31 May 2017 at 11:01, Sergey A. Borshch
> > >> >>>  > >
> > >> >>> wrote:
> > >> 
> > >>  On 

Re: [Kicad-developers] [PATCH] More aggressive sheet-selection

[Kristoffer Ödmark]

Hello again!

I understand that everyone is pretty busy, but I would appreciate if 
someone took a quick glance at this and said what they think.


- Kristoffer

On 2017-05-03 15:51, Kristoffer Ödmark wrote:

Hello everyone!

I made a small change to the "select hierarchical sheet" function. I 
would love if someone tried this and gave some feedback.


Before the function only selected segments belonging to a netlist unique 
to that hierarchical sheet. Now it will use the "select logical 
connection" to every segment connected to module from the subsheet as 
well. presonally I think it is more useful now, but I want confirmation 
if possible :)


- 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

[Kicad-developers] pull default PDF viewer

[Fabrizio Tappero]

​Apologies for presenting this problem again and again

 I think this topic came up too many times but (on my linux system) the
default PDF viewer is not pulled correctly by kiCad. From the terminal:

$ cat /usr/share/applications/defaults.list  | grep pdf
application/pdf=xreader.desktop;evince.desktop;atril.desktop

but KiCad insist using Gimp.

can anybody point me to the right direction? I am looking at preferences.cpp

Cheers
Fabrizio​
___
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] Reunion of zoom toolbar buttons

[Fabrizio Tappero]

totally needed patch!

cheers
Fabrizio


On Mon, Jun 5, 2017 at 8:17 PM, Bernhard Stegmaier 
wrote:

> Hi,
>
> I use KiCad for some while now, but I only recently noticed that there is
> a “zoom to selection” function/button in the right toolbox.
> Don’t know why, maybe because of an icon change.
>
> I guess the main reason that I didn’t notice it before was that I just
> didn’t expect it to be in the right toolbar with all the schema, PCB, etc.
> related (drawing) stuff. And, in contrast having all the other zoom buttons
> in the top toolbar.
>
> Attached a patch that moves “zoom selection” into top toolbar next to the
> other zoom buttons.
> It further slightly switches buttons so that all zoom buttons are next to
> each other:
>
>
>
> For my taste it makes much more sense like this.
> However, if there are good reasons against it or many don’t like it, then
> just ignore it… :)
>
>
> Regards,
> Bernhard
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
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] kicad right click menu corrections and few icons corrections

[Fabrizio Tappero]

Thank you for point it out.

I am on it.

cheers
Fabrizio


On Mon, Jun 5, 2017 at 6:40 PM, Wayne Stambaugh 
wrote:

> I second this.  The biggest offender that I can see is the new library
> viewer icon.  There are also a few images with a while border around
> them as well and the don't look very good with your typical grey toolbar
> color.
>
> On 6/5/2017 8:09 AM, Nick Østergaard wrote:
> > I see some buggy icons, they contain a white background which makes
> > them look funky. Could you please fix those?  See attached.
> >
> > 2017-05-30 17:17 GMT+02:00 Fabrizio Tappero  >:
> >> here you go.
> >>
> >> Fabrizio
> >>
> >> On Tue, May 30, 2017 at 4:05 PM, Nick Østergaard 
> wrote:
> >>>
> >>> I don't see any patches attached.
> >>>
> >>> 2017-05-30 14:54 GMT+02:00 Fabrizio Tappero <
> fabrizio.tapp...@gmail.com>:
>  Hello Wayne,
>  In attachment you can find a good review of approx 30 icons and a
> global
>  simplification of approx 30 icons.
>  I have also corrected some menu labels.
> 
>  Since there is a lot of corrected text that is very much related to
>  English, it would be great if you could review it before submitting
> it.
>  A
>  not so fun work but I think it will make kicad a much better tool.
> 
>  I think it would be recommendable to avoid "a" and "the" in button and
>  menu
>  tooltips. So that it way easier to understand what the button or
> tooltip
>  is
>  about. The use of singular plural is also inconsistent and I tried to
>  fix
>  it. Please Wayne feel free to make any changes you think is important.
> 
>  I have also notices that several menus are a little inconstant. I will
>  try
>  work on it since I think the current kicad UI is very usable but it
>  needs
>  to be more consistent.
> 
>  I have tried to fixed a lot of icons so that their meaning is more
>  immediate to understand. I have as well started a process of
>  simplification
>  of many redundant icons. I think it is important that we begin
>  simplifing
>  the kicad icon set because at the moment is really too large.
> 
>  Here below a detailed description of the changes.
> 
>  Cheers
>  Fabrizio
> 
> 
>  ### Deleted the following icons(deleted: svg, cpp and png):
>  edit_component
>  edit_part
>  move_text
>  rotate_field
>  rotate_glabel
>  rotate_module_cw
>  rotate_module_ccw
>  rotate_pin
>  rotatehlabel
>  many_good_icons
>  dismiss
>  move_track
>  move_track_segment
>  library2
>  copy_button
>  copyblock
>  edit_sheet
>  icon_text
>  pagelayout_new
>  sch_new
>  rescue_pcbnew
>  schematic
>  pagelayout_load_default
>  gerbview_open_recent_ziparchive_files
>  gerbview_open_recent_drill_files
>  gerber_recent_files
>  pagelayout_recent
>  revert_pcbnew
> 
>  ### Lightly modified icons:
>  bom
>  autoplace_fields
>  flip_board
>  duplicate_module
>  delete
>  new_sch
>  new_pcb
>  new_component
>  general_deletions
>  reload
>  pagelayout_load
>  add_line
>  add_entry
>  add_tracks
>  add_tracks_and_vias
>  about
>  array_module
>  image
>  noconn
>  add_dashed_line.svg
>  add_bus.svg
>  scheamatic
>  resize_sheet
>  eeschema
>  netlist
>  pagelayout_load_default
>  datasheet
>  svg_file
>  pagelayout_normal_view_mode
>  pagelayout_special_view_mode
>  unknow
>  export
>  import
>  pcb_update
>  pcbnew
>  editor
>  edit
>  directory
>  browse_files
>  icon_gerbview_small
>  post_drill
> 
> 
> 
>  ### created few new icons that replace few icons used inproperly
>  (created
>  svg, cpp, png):
>  exchange
>  icon
>  drag
>  rescue
>  path
>  copy
>  new_generic
>  recent
>  pcbcalculator
> 
>  ### Corrected some label content. It is important here to be rigorus
>  about
>  it. Inkscape could
>  be a good tool that can be used as reference:
>  eescheam rightclick menu
>  cvpcb rightclick menu
>  pcbnew rightclick menu
>  libedit rightclick menu
>  icon tooltips
>  gerber and drill file menu
>  main kicad hotkey icon menu
>  fixes several tooltip phrases like "Opens a new schematic" into "Open
>  new
>  schematic sheet"
>  few more menues and sub menus here and there (see git log for
> details).
> 
>  Beside makes many icons more effective, this massive patch is trying
> to
>  rise the quality of the kicad UI. Few examples are:
>  write all words in a menu  with capital letter. Tooltip sentence
> should
>  start with capital letter.
>  do not end a menu item is with a dot "."

Re: [Kicad-developers] menu icons

[Fabrizio Tappero]

hi,
on (probably last) linux mint, menu icons work well and are 100% controlled
t the preference option.

cheers
Fabrizio


On Tue, Jun 6, 2017 at 9:14 AM, Marco Ciampa  wrote:

> On Mon, Jun 05, 2017 at 05:37:32PM -0500, José Ignacio wrote:
> > Menu icons are disabled by default in gnome 3 in an effort to make it
> look
> > more like an Apple product. You can enable them (on gtk 3.10+) with:
> >
> > gsettings set org.gnome.settings-daemon.plugins.xsettings overrides
> > "{'Gtk/ButtonImages': <1>, 'Gtk/MenuImages': <1>}"
>
> So the
>
> Preference->Icon options->Icons in menu
>
> is there for what?
>
> TIA
>
> Regards,
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> 
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] menu icons

[Marco Ciampa]

On Mon, Jun 05, 2017 at 05:37:32PM -0500, José Ignacio wrote:
> Menu icons are disabled by default in gnome 3 in an effort to make it look
> more like an Apple product. You can enable them (on gtk 3.10+) with:
> 
> gsettings set org.gnome.settings-daemon.plugins.xsettings overrides
> "{'Gtk/ButtonImages': <1>, 'Gtk/MenuImages': <1>}"

So the 

Preference->Icon options->Icons in menu

is there for what?

TIA

Regards,

--


Marco Ciampa

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



 GNU/Linux User #78271
 FSFE fellow #364




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