Re: [Kicad-developers] Datasheet confusion

2017-10-23 Thread Wayne Stambaugh 
Kristoffer,

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

Cheers,

Wayne

On 10/19/2017 11:53 AM, Kristoffer Ödmark wrote:
> I tested the GetAssociatedDocument, works much better and has more
> features so i took the freedom of updating the dialog windows to use
> that instead of the wxLaunchDefaultBrowser as well
> 
> attaching patch :)
> 
> - Kristoffer
> 
> On 10/19/2017 02:07 PM, Wayne Stambaugh wrote:
>> On 10/19/2017 7:09 AM, Kristoffer Ödmark wrote:
>>> Yes indeed it breaks that, I would argue that having an "invisible"
>>> field opened when using the context field is the source of the
>>> confusion. So I am aware it breaks the context menu for old schematics
>>> but think it is necessary anyway.
>>
>> I'm OK with this change.  I'm not sure why we would use the document
>> field from the library symbol rather the schematic symbol.  AFAIK, we
>> don't do that for any other schematic symbol fields.
>>
>>>
>>> I can of course use GetAssociatedDocument instead.
>>>
>>> On Oct 19, 2017 12:54 PM, "jp charras" >> > wrote:
>>>
>>>  Le 18/10/2017 à 20:20, Kristoffer Ödmark a écrit :
>>>  > Glad to hear it, I fixed a patch up that will highlight the
>>>  differences a bit better than I explain it.
>>>  >
>>>  > Basically it will fill the field from the properties if the field
>>>  is empty when adding components to
>>>  > the schematic.
>>>  >
>>>  > It will also use the Field to determine when to show the context
>>>  menu instead of relying on the
>>>  > library.
>>>  >
>>>  > - Kristoffer
>>>  >
>>>
>>>  Unfortunately, it breaks access to the associated document for
>>>  existing schematics, that can have a
>>>  datasheet name set in library, but not in schematic.
>>>
>>>  and calling:
>>>  ::wxLaunchDefaultBrowser( text ); is incorrect
>>>  (text is not always a .pdf doc with a full absolute path or URI)
>>>  see:
>>>  GetAssociatedDocument()
>>>
>>>  --
>>>  Jean-Pierre CHARRAS
>>>
>>>  ___
>>>  Mailing list: https://launchpad.net/~kicad-developers
>>>  
>>>  Post to     : kicad-developers@lists.launchpad.net
>>>  
>>>  Unsubscribe : https://launchpad.net/~kicad-developers
>>>  
>>>  More help   : https://help.launchpad.net/ListHelp
>>>  
>>>
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> 
> ___
> 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] Datasheet confusion

2017-10-23 Thread Wayne Stambaugh 
On 10/23/2017 3:52 PM, Kevin Cozens wrote:
> On 2017-10-13 06:01 AM, Oliver Walters wrote:
>> Very interesting history JP! I think we are all looking forward to the
>> new library format :)
> 
> When I read about a new library format I start wondering (worrying?)
> what impact the change will have on my existing schematics. I have
> already seen cases where changes were made to github based libraries
> used by eeschema that caused a problem with an older schematic.
> 

There will be no impact unless the symbol changes in library.  The
library conversion process will not change the symbol, only the file
format.  Once the new schematic file format is complete, there will be
no impact once a symbol is added to a schematic because the symbol will
be embedded in the schematic similar to how footprints are embedded in
the board file.

___
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] Datasheet confusion

2017-10-23 Thread Kevin Cozens 

On 2017-10-13 06:01 AM, Oliver Walters wrote:
Very interesting history JP! I think we are all looking forward to the new 
library format :)


When I read about a new library format I start wondering (worrying?) what 
impact the change will have on my existing schematics. I have already seen 
cases where changes were made to github based libraries used by eeschema 
that caused a problem with an older schematic.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#include  | --Chris Hardwick

___
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] Datasheet confusion

2017-10-23 Thread Wayne Stambaugh 
Kristoffer,

Sorry about the delay.  I applied your patch and did some testing last
night but I just ran out of time.  I should get it pushed this evening
barring anything unexpected.

Wayne

On 10/23/2017 3:52 AM, Kristoffer Ödmark wrote:
> Seems there are no major objections :) Bumping this so it doesnt get
> lost in history :)
> 
> On 10/19/2017 09:57 PM, Wayne Stambaugh wrote:
>> Looks good to me.  If there are no major objections I will merge this
>> patch.
>>
>> On 10/19/2017 11:53 AM, Kristoffer Ödmark wrote:
>>> I tested the GetAssociatedDocument, works much better and has more
>>> features so i took the freedom of updating the dialog windows to use
>>> that instead of the wxLaunchDefaultBrowser as well
>>>
>>> attaching patch :)
>>>
>>> - Kristoffer
>>>
>>> On 10/19/2017 02:07 PM, Wayne Stambaugh wrote:
 On 10/19/2017 7:09 AM, Kristoffer Ödmark wrote:
> Yes indeed it breaks that, I would argue that having an "invisible"
> field opened when using the context field is the source of the
> confusion. So I am aware it breaks the context menu for old schematics
> but think it is necessary anyway.

 I'm OK with this change.  I'm not sure why we would use the document
 field from the library symbol rather the schematic symbol.  AFAIK, we
 don't do that for any other schematic symbol fields.

>
> I can of course use GetAssociatedDocument instead.
>
> On Oct 19, 2017 12:54 PM, "jp charras"  > wrote:
>
>   Le 18/10/2017 à 20:20, Kristoffer Ödmark a écrit :
>   > Glad to hear it, I fixed a patch up that will highlight the
>   differences a bit better than I explain it.
>   >
>   > Basically it will fill the field from the properties if the
> field
>   is empty when adding components to
>   > the schematic.
>   >
>   > It will also use the Field to determine when to show the
> context
>   menu instead of relying on the
>   > library.
>   >
>   > - Kristoffer
>   >
>
>   Unfortunately, it breaks access to the associated document for
>   existing schematics, that can have a
>   datasheet name set in library, but not in schematic.
>
>   and calling:
>   ::wxLaunchDefaultBrowser( text ); is incorrect
>   (text is not always a .pdf doc with a full absolute path or URI)
>   see:
>   GetAssociatedDocument()
>
>   --
>   Jean-Pierre CHARRAS
>
>   ___
>   Mailing list: https://launchpad.net/~kicad-developers
>   
>   Post to     : kicad-developers@lists.launchpad.net
>   
>   Unsubscribe : https://launchpad.net/~kicad-developers
>   
>   More help   : https://help.launchpad.net/ListHelp
>   
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

>>>
>>>
>>> ___
>>> 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] Datasheet confusion

2017-10-23 Thread Kristoffer Ödmark 
Seems there are no major objections :) Bumping this so it doesnt get 
lost in history :)


On 10/19/2017 09:57 PM, Wayne Stambaugh wrote:

Looks good to me.  If there are no major objections I will merge this patch.

On 10/19/2017 11:53 AM, Kristoffer Ödmark wrote:

I tested the GetAssociatedDocument, works much better and has more
features so i took the freedom of updating the dialog windows to use
that instead of the wxLaunchDefaultBrowser as well

attaching patch :)

- Kristoffer

On 10/19/2017 02:07 PM, Wayne Stambaugh wrote:

On 10/19/2017 7:09 AM, Kristoffer Ödmark wrote:

Yes indeed it breaks that, I would argue that having an "invisible"
field opened when using the context field is the source of the
confusion. So I am aware it breaks the context menu for old schematics
but think it is necessary anyway.


I'm OK with this change.  I'm not sure why we would use the document
field from the library symbol rather the schematic symbol.  AFAIK, we
don't do that for any other schematic symbol fields.



I can of course use GetAssociatedDocument instead.

On Oct 19, 2017 12:54 PM, "jp charras" > wrote:

  Le 18/10/2017 à 20:20, Kristoffer Ödmark a écrit :
  > Glad to hear it, I fixed a patch up that will highlight the
  differences a bit better than I explain it.
  >
  > Basically it will fill the field from the properties if the field
  is empty when adding components to
  > the schematic.
  >
  > It will also use the Field to determine when to show the context
  menu instead of relying on the
  > library.
  >
  > - Kristoffer
  >

  Unfortunately, it breaks access to the associated document for
  existing schematics, that can have a
  datasheet name set in library, but not in schematic.

  and calling:
  ::wxLaunchDefaultBrowser( text ); is incorrect
  (text is not always a .pdf doc with a full absolute path or URI)
  see:
  GetAssociatedDocument()

  --
  Jean-Pierre CHARRAS

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




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



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




___
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



--
 -Kristoffer

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

Re: [Kicad-developers] Datasheet confusion

2017-10-19 Thread Wayne Stambaugh 
Looks good to me.  If there are no major objections I will merge this patch.

On 10/19/2017 11:53 AM, Kristoffer Ödmark wrote:
> I tested the GetAssociatedDocument, works much better and has more
> features so i took the freedom of updating the dialog windows to use
> that instead of the wxLaunchDefaultBrowser as well
> 
> attaching patch :)
> 
> - Kristoffer
> 
> On 10/19/2017 02:07 PM, Wayne Stambaugh wrote:
>> On 10/19/2017 7:09 AM, Kristoffer Ödmark wrote:
>>> Yes indeed it breaks that, I would argue that having an "invisible"
>>> field opened when using the context field is the source of the
>>> confusion. So I am aware it breaks the context menu for old schematics
>>> but think it is necessary anyway.
>>
>> I'm OK with this change.  I'm not sure why we would use the document
>> field from the library symbol rather the schematic symbol.  AFAIK, we
>> don't do that for any other schematic symbol fields.
>>
>>>
>>> I can of course use GetAssociatedDocument instead.
>>>
>>> On Oct 19, 2017 12:54 PM, "jp charras" >> > wrote:
>>>
>>>  Le 18/10/2017 à 20:20, Kristoffer Ödmark a écrit :
>>>  > Glad to hear it, I fixed a patch up that will highlight the
>>>  differences a bit better than I explain it.
>>>  >
>>>  > Basically it will fill the field from the properties if the field
>>>  is empty when adding components to
>>>  > the schematic.
>>>  >
>>>  > It will also use the Field to determine when to show the context
>>>  menu instead of relying on the
>>>  > library.
>>>  >
>>>  > - Kristoffer
>>>  >
>>>
>>>  Unfortunately, it breaks access to the associated document for
>>>  existing schematics, that can have a
>>>  datasheet name set in library, but not in schematic.
>>>
>>>  and calling:
>>>  ::wxLaunchDefaultBrowser( text ); is incorrect
>>>  (text is not always a .pdf doc with a full absolute path or URI)
>>>  see:
>>>  GetAssociatedDocument()
>>>
>>>  --
>>>  Jean-Pierre CHARRAS
>>>
>>>  ___
>>>  Mailing list: https://launchpad.net/~kicad-developers
>>>  
>>>  Post to     : kicad-developers@lists.launchpad.net
>>>  
>>>  Unsubscribe : https://launchpad.net/~kicad-developers
>>>  
>>>  More help   : https://help.launchpad.net/ListHelp
>>>  
>>>
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> 
> ___
> 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] Datasheet confusion

2017-10-19 Thread Kristoffer Ödmark 
I tested the GetAssociatedDocument, works much better and has more 
features so i took the freedom of updating the dialog windows to use 
that instead of the wxLaunchDefaultBrowser as well


attaching patch :)

- Kristoffer

On 10/19/2017 02:07 PM, Wayne Stambaugh wrote:

On 10/19/2017 7:09 AM, Kristoffer Ödmark wrote:

Yes indeed it breaks that, I would argue that having an "invisible"
field opened when using the context field is the source of the
confusion. So I am aware it breaks the context menu for old schematics
but think it is necessary anyway.


I'm OK with this change.  I'm not sure why we would use the document
field from the library symbol rather the schematic symbol.  AFAIK, we
don't do that for any other schematic symbol fields.



I can of course use GetAssociatedDocument instead.

On Oct 19, 2017 12:54 PM, "jp charras" > wrote:

 Le 18/10/2017 à 20:20, Kristoffer Ödmark a écrit :
 > Glad to hear it, I fixed a patch up that will highlight the
 differences a bit better than I explain it.
 >
 > Basically it will fill the field from the properties if the field
 is empty when adding components to
 > the schematic.
 >
 > It will also use the Field to determine when to show the context
 menu instead of relying on the
 > library.
 >
 > - Kristoffer
 >

 Unfortunately, it breaks access to the associated document for
 existing schematics, that can have a
 datasheet name set in library, but not in schematic.

 and calling:
 ::wxLaunchDefaultBrowser( text ); is incorrect
 (text is not always a .pdf doc with a full absolute path or URI)
 see:
 GetAssociatedDocument()

 --
 Jean-Pierre CHARRAS

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




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



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

>From fdefde7fa970feed57ce22ea478b7d81cd66167f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= 
Date: Wed, 18 Oct 2017 20:09:08 +0200
Subject: [PATCH] Use the Component Field when determining when to choose the
 "Show Documentation" context menu

This instead of using the library alias property. But to not break any library. When adding
new compononents to the schematic, copy the value from the library into the Field variable
only if the field variable would otherwise be empty.

This way, the context menu for showing the docs is more understandable for users, and is
also changeable from the schematic without having to modify the actual libraries.

Fixed: lp:1723104
---
 eeschema/dialogs/dialog_edit_component_in_schematic.cpp |  3 ++-
 eeschema/dialogs/dialog_edit_libentry_fields_in_lib.cpp |  3 ++-
 eeschema/getpart.cpp| 12 
 eeschema/onrightclick.cpp   |  2 +-
 eeschema/schedit.cpp| 13 -
 5 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/eeschema/dialogs/dialog_edit_component_in_schematic.cpp b/eeschema/dialogs/dialog_edit_component_in_schematic.cpp
index 0804f8bba..e9500d830 100644
--- a/eeschema/dialogs/dialog_edit_component_in_schematic.cpp
+++ b/eeschema/dialogs/dialog_edit_component_in_schematic.cpp
@@ -54,6 +54,7 @@
 #endif /* KICAD_SPICE */
 
 #include "common.h"
+#include "eda_doc.h"
 #include 
 
 
@@ -590,7 +591,7 @@ void DIALOG_EDIT_COMPONENT_IN_SCHEMATIC::showButtonHandler( wxCommandEvent& even
 {
 wxString datasheet_uri = fieldValueTextCtrl->GetValue();
 datasheet_uri = resolveUriByEnvVars( datasheet_uri );
-::wxLaunchDefaultBrowser( datasheet_uri );
+GetAssociatedDocument( this, datasheet_uri );
 }
 else if( fieldNdx == FOOTPRINT )
 {
diff --git a/eeschema/dialogs/dialog_edit_libentry_fields_in_lib.cpp b/eeschema/dialogs/dialog_edit_libentry_fields_in_lib.cpp
index d70f05a86..23341a5bd 100644
--- a/eeschema/dialogs/dialog_edit_libentry_fields_in_lib.cpp
+++ b/eeschema/dialogs/dialog_edit_libentry_fields_in_lib.cpp
@@ -45,6 +45,7 @@
 #include

Re: [Kicad-developers] Datasheet confusion

2017-10-19 Thread Wayne Stambaugh 
On 10/19/2017 7:09 AM, Kristoffer Ödmark wrote:
> Yes indeed it breaks that, I would argue that having an "invisible"
> field opened when using the context field is the source of the
> confusion. So I am aware it breaks the context menu for old schematics
> but think it is necessary anyway. 

I'm OK with this change.  I'm not sure why we would use the document
field from the library symbol rather the schematic symbol.  AFAIK, we
don't do that for any other schematic symbol fields.

> 
> I can of course use GetAssociatedDocument instead. 
> 
> On Oct 19, 2017 12:54 PM, "jp charras"  > wrote:
> 
> Le 18/10/2017 à 20:20, Kristoffer Ödmark a écrit :
> > Glad to hear it, I fixed a patch up that will highlight the
> differences a bit better than I explain it.
> >
> > Basically it will fill the field from the properties if the field
> is empty when adding components to
> > the schematic.
> >
> > It will also use the Field to determine when to show the context
> menu instead of relying on the
> > library.
> >
> > - Kristoffer
> >
> 
> Unfortunately, it breaks access to the associated document for
> existing schematics, that can have a
> datasheet name set in library, but not in schematic.
> 
> and calling:
> ::wxLaunchDefaultBrowser( text ); is incorrect
> (text is not always a .pdf doc with a full absolute path or URI)
> see:
> GetAssociatedDocument()
> 
> --
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] Datasheet confusion

2017-10-19 Thread Kristoffer Ödmark 
Yes indeed it breaks that, I would argue that having an "invisible" field
opened when using the context field is the source of the confusion. So I am
aware it breaks the context menu for old schematics but think it is
necessary anyway.

I can of course use GetAssociatedDocument instead.

On Oct 19, 2017 12:54 PM, "jp charras"  wrote:

Le 18/10/2017 à 20:20, Kristoffer Ödmark a écrit :
> Glad to hear it, I fixed a patch up that will highlight the differences a
bit better than I explain it.
>
> Basically it will fill the field from the properties if the field is
empty when adding components to
> the schematic.
>
> It will also use the Field to determine when to show the context menu
instead of relying on the
> library.
>
> - Kristoffer
>

Unfortunately, it breaks access to the associated document for existing
schematics, that can have a
datasheet name set in library, but not in schematic.

and calling:
::wxLaunchDefaultBrowser( text ); is incorrect
(text is not always a .pdf doc with a full absolute path or URI)
see:
GetAssociatedDocument()

--
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] Datasheet confusion

2017-10-19 Thread jp charras 
Le 18/10/2017 à 20:20, Kristoffer Ödmark a écrit :
> Glad to hear it, I fixed a patch up that will highlight the differences a bit 
> better than I explain it.
> 
> Basically it will fill the field from the properties if the field is empty 
> when adding components to
> the schematic.
> 
> It will also use the Field to determine when to show the context menu instead 
> of relying on the
> library.
> 
> - Kristoffer
> 

Unfortunately, it breaks access to the associated document for existing 
schematics, that can have a
datasheet name set in library, but not in schematic.

and calling:
::wxLaunchDefaultBrowser( text ); is incorrect
(text is not always a .pdf doc with a full absolute path or URI)
see:
GetAssociatedDocument()

-- 
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] Datasheet confusion

2017-10-18 Thread Kristoffer Ödmark 
Glad to hear it, I fixed a patch up that will highlight the differences 
a bit better than I explain it.


Basically it will fill the field from the properties if the field is 
empty when adding components to the schematic.


It will also use the Field to determine when to show the context menu 
instead of relying on the library.


- Kristoffer

On 10/16/2017 07:33 PM, Fabrizio Tappero wrote:

Hi Kristoffer,
I am a big supporter of this option. I am often in need of showing a 
datasheet with a right click on component. It would be great to be able 
to do it in the completed schematic as well as in the completed pcb layout.


cheers
Fabrizio



On Fri, Oct 13, 2017 at 2:18 PM, Kristoffer Ödmark 
> wrote:


There is a "show documentation" context field, but it only uses the
documentation string, so if i put a value into the datasheet field.
The menu doesnt show, I do not think that adding a "Show
documentation" and a "Show Datasheet" is a good solution.

I will create a patch, probably this weekend and submit, I think it
will highlight the problem better. I believe its a trivial fix.

- Kristoffer


On 10/13/2017 01:54 PM, Wayne Stambaugh wrote:

On 10/13/2017 6:19 AM, Kristoffer Ödmark wrote:

Thanks you very much for that clarification, I for one would
really
enjoy a clarification of the documentation and Datasheet
string. KiCad
has been around for quite a while now, interesting how
technology has
changed during that time.

For another question, would It be okay to redirect the
context menu in
eeschema, so that the "Show documentation" context menu
would use the
Field "Datasheet"? And use the "documentation" string to
fill the
"Datasheet" field when adding the symbol to the schematic?


I'm OK with adding both a "Show Documentation" (should be
visible only
when the field is not empty) to the symbol context menu and an "Edit
Datasheet Field" entry to the "Properties" sub-menu.


I guess this would be considered a temporary fix if okay?

On 10/13/2017 08:51 AM, jp charras wrote:

FYI, in fact this confusion comes from a bug introduced
a long time ago:

Initially, the field name was "Sheet" not "Datasheet".
It should be "SchematicSheet"

The purpose was to be able to create a component acting as a
hierarchical sheet:
The component in a root sheet, and its internal sheet
("SchematicSheet") similar to a sub sheet.

But unfortunately, it was never done, and one day the
word "Sheet"
became "Datasheet", thus creating
a serious confusion.

Perhaps the "DATASHEET" field (attached to the symbol)
and the
"documentation" string (attached to a
alias) should be clearly redefined for the V5.

By the way, do you know why the .dcm file exists?
It is similar to the .idx index file of old spice libs.

In the early time of eeschema, Kicad was stored on a
server and was
used in classrooms and on PCs
connected by a "slow" network link: network cards were
ISA cards and
the link speed was roughly 2400
bps.

So loading all needed schematic libraries to choose a
symbol was a too
time costly process, making
Eeschema barely usable.
Using small .dcm files to display a list of symbols and
some info
fixed this issue.

Nowadays, link speed, PC speed and memory sizes have 3
order of
magnitude, and .dcm files (a relic
of this time) is more an annoying feature.





___
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



-- 
  -Kristoffer



___
Mailing list: https://launchpad.net/~kicad-developers

Post to     : kicad-developers@lists.launchpad.net

Re: [Kicad-developers] Datasheet confusion

2017-10-16 Thread Fabrizio Tappero 
Hi Kristoffer,
I am a big supporter of this option. I am often in need of showing a
datasheet with a right click on component. It would be great to be able to
do it in the completed schematic as well as in the completed pcb layout.

cheers
Fabrizio



On Fri, Oct 13, 2017 at 2:18 PM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> There is a "show documentation" context field, but it only uses the
> documentation string, so if i put a value into the datasheet field. The
> menu doesnt show, I do not think that adding a "Show documentation" and a
> "Show Datasheet" is a good solution.
>
> I will create a patch, probably this weekend and submit, I think it will
> highlight the problem better. I believe its a trivial fix.
>
> - Kristoffer
>
>
> On 10/13/2017 01:54 PM, Wayne Stambaugh wrote:
>
>> On 10/13/2017 6:19 AM, Kristoffer Ödmark wrote:
>>
>>> Thanks you very much for that clarification, I for one would really
>>> enjoy a clarification of the documentation and Datasheet string. KiCad
>>> has been around for quite a while now, interesting how technology has
>>> changed during that time.
>>>
>>> For another question, would It be okay to redirect the context menu in
>>> eeschema, so that the "Show documentation" context menu would use the
>>> Field "Datasheet"? And use the "documentation" string to fill the
>>> "Datasheet" field when adding the symbol to the schematic?
>>>
>>
>> I'm OK with adding both a "Show Documentation" (should be visible only
>> when the field is not empty) to the symbol context menu and an "Edit
>> Datasheet Field" entry to the "Properties" sub-menu.
>>
>>
>>> I guess this would be considered a temporary fix if okay?
>>>
>>> On 10/13/2017 08:51 AM, jp charras wrote:
>>>
>>> FYI, in fact this confusion comes from a bug introduced a long time ago:

 Initially, the field name was "Sheet" not "Datasheet".
 It should be "SchematicSheet"

 The purpose was to be able to create a component acting as a
 hierarchical sheet:
 The component in a root sheet, and its internal sheet
 ("SchematicSheet") similar to a sub sheet.

 But unfortunately, it was never done, and one day the word "Sheet"
 became "Datasheet", thus creating
 a serious confusion.

 Perhaps the "DATASHEET" field (attached to the symbol) and the
 "documentation" string (attached to a
 alias) should be clearly redefined for the V5.

 By the way, do you know why the .dcm file exists?
 It is similar to the .idx index file of old spice libs.

 In the early time of eeschema, Kicad was stored on a server and was
 used in classrooms and on PCs
 connected by a "slow" network link: network cards were ISA cards and
 the link speed was roughly 2400
 bps.

 So loading all needed schematic libraries to choose a symbol was a too
 time costly process, making
 Eeschema barely usable.
 Using small .dcm files to display a list of symbols and some info
 fixed this issue.

 Nowadays, link speed, PC speed and memory sizes have 3 order of
 magnitude, and .dcm files (a relic
 of this time) is more an annoying feature.


>>>
>>>
>>
>> ___
>> 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
>>
>>
> --
>  -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
>
___
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] Datasheet confusion

2017-10-13 Thread Kristoffer Ödmark 
There is a "show documentation" context field, but it only uses the 
documentation string, so if i put a value into the datasheet field. The 
menu doesnt show, I do not think that adding a "Show documentation" and 
a "Show Datasheet" is a good solution.


I will create a patch, probably this weekend and submit, I think it will 
highlight the problem better. I believe its a trivial fix.


- Kristoffer

On 10/13/2017 01:54 PM, Wayne Stambaugh wrote:

On 10/13/2017 6:19 AM, Kristoffer Ödmark wrote:

Thanks you very much for that clarification, I for one would really
enjoy a clarification of the documentation and Datasheet string. KiCad
has been around for quite a while now, interesting how technology has
changed during that time.

For another question, would It be okay to redirect the context menu in
eeschema, so that the "Show documentation" context menu would use the
Field "Datasheet"? And use the "documentation" string to fill the
"Datasheet" field when adding the symbol to the schematic?


I'm OK with adding both a "Show Documentation" (should be visible only
when the field is not empty) to the symbol context menu and an "Edit
Datasheet Field" entry to the "Properties" sub-menu.



I guess this would be considered a temporary fix if okay?

On 10/13/2017 08:51 AM, jp charras wrote:


FYI, in fact this confusion comes from a bug introduced a long time ago:

Initially, the field name was "Sheet" not "Datasheet".
It should be "SchematicSheet"

The purpose was to be able to create a component acting as a
hierarchical sheet:
The component in a root sheet, and its internal sheet
("SchematicSheet") similar to a sub sheet.

But unfortunately, it was never done, and one day the word "Sheet"
became "Datasheet", thus creating
a serious confusion.

Perhaps the "DATASHEET" field (attached to the symbol) and the
"documentation" string (attached to a
alias) should be clearly redefined for the V5.

By the way, do you know why the .dcm file exists?
It is similar to the .idx index file of old spice libs.

In the early time of eeschema, Kicad was stored on a server and was
used in classrooms and on PCs
connected by a "slow" network link: network cards were ISA cards and
the link speed was roughly 2400
bps.

So loading all needed schematic libraries to choose a symbol was a too
time costly process, making
Eeschema barely usable.
Using small .dcm files to display a list of symbols and some info
fixed this issue.

Nowadays, link speed, PC speed and memory sizes have 3 order of
magnitude, and .dcm files (a relic
of this time) is more an annoying feature.







___
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



--
 -Kristoffer

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

Re: [Kicad-developers] Datasheet confusion

2017-10-13 Thread Wayne Stambaugh 
On 10/13/2017 6:19 AM, Kristoffer Ödmark wrote:
> Thanks you very much for that clarification, I for one would really
> enjoy a clarification of the documentation and Datasheet string. KiCad
> has been around for quite a while now, interesting how technology has
> changed during that time.
> 
> For another question, would It be okay to redirect the context menu in
> eeschema, so that the "Show documentation" context menu would use the
> Field "Datasheet"? And use the "documentation" string to fill the
> "Datasheet" field when adding the symbol to the schematic?

I'm OK with adding both a "Show Documentation" (should be visible only
when the field is not empty) to the symbol context menu and an "Edit
Datasheet Field" entry to the "Properties" sub-menu.

> 
> I guess this would be considered a temporary fix if okay?
> 
> On 10/13/2017 08:51 AM, jp charras wrote:
> 
>> FYI, in fact this confusion comes from a bug introduced a long time ago:
>>
>> Initially, the field name was "Sheet" not "Datasheet".
>> It should be "SchematicSheet"
>>
>> The purpose was to be able to create a component acting as a
>> hierarchical sheet:
>> The component in a root sheet, and its internal sheet
>> ("SchematicSheet") similar to a sub sheet.
>>
>> But unfortunately, it was never done, and one day the word "Sheet"
>> became "Datasheet", thus creating
>> a serious confusion.
>>
>> Perhaps the "DATASHEET" field (attached to the symbol) and the
>> "documentation" string (attached to a
>> alias) should be clearly redefined for the V5.
>>
>> By the way, do you know why the .dcm file exists?
>> It is similar to the .idx index file of old spice libs.
>>
>> In the early time of eeschema, Kicad was stored on a server and was
>> used in classrooms and on PCs
>> connected by a "slow" network link: network cards were ISA cards and
>> the link speed was roughly 2400
>> bps.
>>
>> So loading all needed schematic libraries to choose a symbol was a too
>> time costly process, making
>> Eeschema barely usable.
>> Using small .dcm files to display a list of symbols and some info
>> fixed this issue.
>>
>> Nowadays, link speed, PC speed and memory sizes have 3 order of
>> magnitude, and .dcm files (a relic
>> of this time) is more an annoying feature.
>>
> 
> 


___
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] Datasheet confusion

2017-10-13 Thread Wayne Stambaugh 
On 10/13/2017 2:51 AM, jp charras wrote:
> Le 13/10/2017 à 00:23, Wayne Stambaugh a écrit :
>> On 10/12/2017 1:52 PM, Kristoffer Ödmark wrote:
>>>
>>> On 10/12/2017 06:56 PM, Wayne Stambaugh wrote:
 Kristoffer,

 There is no confusion and there is nothing to fix.  The document field
 is just like any other field.  It is initially imported from the library
 symbol to the schematic symbol (they are *not* the same nor should they
 be) when a symbol is added to the schematic.  Once you modify a field in
 a schematic symbol it takes precedence over the the field in the library
 symbol that was linked when the symbol was added to the schematic.  It
>>>
>>> But it doesnt? If i set the variable Datasheet, which is mandatory, I do
>>> not get a context menu option to "Open documentation". I am not
>>> complaining about the document field, I am complaining that It is stored
>>> in two different ways, once in the dcm file and once in the library.
>>
>> I'm not sure why there is not an "Edit Datasheet" entry in the
>> "Properties" submenu of the symbol context menu.  I guess no one ever
>> noticed it before.  It probably would not be that difficult to add.  The
>> dcm file is for storing the description, key word, and datasheet URL
>> information for all library symbols.  The library symbol fields are
>> stored in the lib file and are only stored for the root symbol.  What
>> should happen is the alias document file text should be copied to the
>> schematic symbol DATASHEET field when it is added to the schematic.  If
>> it isn't, this is a bug.
> 
> FYI, in fact this confusion comes from a bug introduced a long time ago:
> 
> Initially, the field name was "Sheet" not "Datasheet".
> It should be "SchematicSheet"
> 
> The purpose was to be able to create a component acting as a hierarchical 
> sheet:
> The component in a root sheet, and its internal sheet ("SchematicSheet") 
> similar to a sub sheet.
> 
> But unfortunately, it was never done, and one day the word "Sheet" became 
> "Datasheet", thus creating
> a serious confusion.
> 
> Perhaps the "DATASHEET" field (attached to the symbol) and the 
> "documentation" string (attached to a
> alias) should be clearly redefined for the V5.
> 
> By the way, do you know why the .dcm file exists?
> It is similar to the .idx index file of old spice libs.
> 
> In the early time of eeschema, Kicad was stored on a server and was used in 
> classrooms and on PCs
> connected by a "slow" network link: network cards were ISA cards and the link 
> speed was roughly 2400
> bps.
> 
> So loading all needed schematic libraries to choose a symbol was a too time 
> costly process, making
> Eeschema barely usable.
> Using small .dcm files to display a list of symbols and some info fixed this 
> issue.
> 
> Nowadays, link speed, PC speed and memory sizes have 3 order of magnitude, 
> and .dcm files (a relic
> of this time) is more an annoying feature.
> 

Thank you JP for the history lesson.  Even as long as I have been with
the project, I am always amazed how much I don't know about KiCad's history.

Cheers,

Wayne

>>
>>>
>>> Or are you saying that there is a difference between documentation and
>>> datasheet?
>>
>> Yes.  There is a mandatory (must exist but can be empty) DATASHEET field
>> for both the root library symbol and it's associated schematic symbol.
>> If you add a library symbol by it's alias, then the root DATASHEET field
>> would be incorrect so the "Document" (this is inconsistent but it's
>> legacy baggage which will be addressed by the new file formats) entry in
>> the dcm file would contain the appropriate datasheet link.
>>
>>>
 has to be this way.  You would not want your schematic symbol fields
 updated every time the library symbol fields are changed.  This only
 makes sense for atomic (fully defined ) symbols and would completely
 fall apart for generic symbols like op-amps and logic gates.  I believe
 Orson recently added a tool to refresh the schematic symbol fields with
 the linked library symbol fields.  I haven't tried it yet but you may
 find that useful.

 Cheers,

 Wayne

 On 10/12/2017 9:12 AM, Kristoffer Ödmark wrote:
> Sorry for double messages but one solution could be to use the Library
> stored documentation to autofill the FIELD variable IF it is empty. And
> then base all the functionality on the field variable?
>
> I could probably fix this if it seems an okay solution to everyone? This
> would basically be making the field variable overriding the properties
> information. But still not break anything from the libs.
>
> Or should this just be left as is until the new symbool format is
> implemented?
>
> On 10/12/2017 03:00 PM, Kristoffer Ödmark wrote:
>> Hey!
>>
>> I noticed today that there are two places to store the datasheet
>> information, one is in the Mandatory Field "Datasheet", and one is in

Re: [Kicad-developers] Datasheet confusion

2017-10-13 Thread Kristoffer Ödmark 
Thanks you very much for that clarification, I for one would really 
enjoy a clarification of the documentation and Datasheet string. KiCad 
has been around for quite a while now, interesting how technology has 
changed during that time.


For another question, would It be okay to redirect the context menu in 
eeschema, so that the "Show documentation" context menu would use the 
Field "Datasheet"? And use the "documentation" string to fill the 
"Datasheet" field when adding the symbol to the schematic?


I guess this would be considered a temporary fix if okay?

On 10/13/2017 08:51 AM, jp charras wrote:


FYI, in fact this confusion comes from a bug introduced a long time ago:

Initially, the field name was "Sheet" not "Datasheet".
It should be "SchematicSheet"

The purpose was to be able to create a component acting as a hierarchical sheet:
The component in a root sheet, and its internal sheet ("SchematicSheet") 
similar to a sub sheet.

But unfortunately, it was never done, and one day the word "Sheet" became 
"Datasheet", thus creating
a serious confusion.

Perhaps the "DATASHEET" field (attached to the symbol) and the "documentation" 
string (attached to a
alias) should be clearly redefined for the V5.

By the way, do you know why the .dcm file exists?
It is similar to the .idx index file of old spice libs.

In the early time of eeschema, Kicad was stored on a server and was used in 
classrooms and on PCs
connected by a "slow" network link: network cards were ISA cards and the link 
speed was roughly 2400
bps.

So loading all needed schematic libraries to choose a symbol was a too time 
costly process, making
Eeschema barely usable.
Using small .dcm files to display a list of symbols and some info fixed this 
issue.

Nowadays, link speed, PC speed and memory sizes have 3 order of magnitude, and 
.dcm files (a relic
of this time) is more an annoying feature.




--
 -Kristoffer

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

Re: [Kicad-developers] Datasheet confusion

2017-10-13 Thread Oliver Walters 
Very interesting history JP! I think we are all looking forward to the new
library format :)

On 13 Oct 2017 17:51, "jp charras"  wrote:

> Le 13/10/2017 à 00:23, Wayne Stambaugh a écrit :
> > On 10/12/2017 1:52 PM, Kristoffer Ödmark wrote:
> >>
> >> On 10/12/2017 06:56 PM, Wayne Stambaugh wrote:
> >>> Kristoffer,
> >>>
> >>> There is no confusion and there is nothing to fix.  The document field
> >>> is just like any other field.  It is initially imported from the
> library
> >>> symbol to the schematic symbol (they are *not* the same nor should they
> >>> be) when a symbol is added to the schematic.  Once you modify a field
> in
> >>> a schematic symbol it takes precedence over the the field in the
> library
> >>> symbol that was linked when the symbol was added to the schematic.  It
> >>
> >> But it doesnt? If i set the variable Datasheet, which is mandatory, I do
> >> not get a context menu option to "Open documentation". I am not
> >> complaining about the document field, I am complaining that It is stored
> >> in two different ways, once in the dcm file and once in the library.
> >
> > I'm not sure why there is not an "Edit Datasheet" entry in the
> > "Properties" submenu of the symbol context menu.  I guess no one ever
> > noticed it before.  It probably would not be that difficult to add.  The
> > dcm file is for storing the description, key word, and datasheet URL
> > information for all library symbols.  The library symbol fields are
> > stored in the lib file and are only stored for the root symbol.  What
> > should happen is the alias document file text should be copied to the
> > schematic symbol DATASHEET field when it is added to the schematic.  If
> > it isn't, this is a bug.
>
> FYI, in fact this confusion comes from a bug introduced a long time ago:
>
> Initially, the field name was "Sheet" not "Datasheet".
> It should be "SchematicSheet"
>
> The purpose was to be able to create a component acting as a hierarchical
> sheet:
> The component in a root sheet, and its internal sheet ("SchematicSheet")
> similar to a sub sheet.
>
> But unfortunately, it was never done, and one day the word "Sheet" became
> "Datasheet", thus creating
> a serious confusion.
>
> Perhaps the "DATASHEET" field (attached to the symbol) and the
> "documentation" string (attached to a
> alias) should be clearly redefined for the V5.
>
> By the way, do you know why the .dcm file exists?
> It is similar to the .idx index file of old spice libs.
>
> In the early time of eeschema, Kicad was stored on a server and was used
> in classrooms and on PCs
> connected by a "slow" network link: network cards were ISA cards and the
> link speed was roughly 2400
> bps.
>
> So loading all needed schematic libraries to choose a symbol was a too
> time costly process, making
> Eeschema barely usable.
> Using small .dcm files to display a list of symbols and some info fixed
> this issue.
>
> Nowadays, link speed, PC speed and memory sizes have 3 order of magnitude,
> and .dcm files (a relic
> of this time) is more an annoying feature.
>
> >
> >>
> >> Or are you saying that there is a difference between documentation and
> >> datasheet?
> >
> > Yes.  There is a mandatory (must exist but can be empty) DATASHEET field
> > for both the root library symbol and it's associated schematic symbol.
> > If you add a library symbol by it's alias, then the root DATASHEET field
> > would be incorrect so the "Document" (this is inconsistent but it's
> > legacy baggage which will be addressed by the new file formats) entry in
> > the dcm file would contain the appropriate datasheet link.
> >
> >>
> >>> has to be this way.  You would not want your schematic symbol fields
> >>> updated every time the library symbol fields are changed.  This only
> >>> makes sense for atomic (fully defined ) symbols and would completely
> >>> fall apart for generic symbols like op-amps and logic gates.  I believe
> >>> Orson recently added a tool to refresh the schematic symbol fields with
> >>> the linked library symbol fields.  I haven't tried it yet but you may
> >>> find that useful.
> >>>
> >>> Cheers,
> >>>
> >>> Wayne
> >>>
> >>> On 10/12/2017 9:12 AM, Kristoffer Ödmark wrote:
>  Sorry for double messages but one solution could be to use the Library
>  stored documentation to autofill the FIELD variable IF it is empty.
> And
>  then base all the functionality on the field variable?
> 
>  I could probably fix this if it seems an okay solution to everyone?
> This
>  would basically be making the field variable overriding the properties
>  information. But still not break anything from the libs.
> 
>  Or should this just be left as is until the new symbool format is
>  implemented?
> 
>  On 10/12/2017 03:00 PM, Kristoffer Ödmark wrote:
> > Hey!
> >
> > I noticed today that there are two places to store the datasheet
> > information, one is in the Mandatory Field "Datasheet", and

Re: [Kicad-developers] Datasheet confusion

2017-10-13 Thread jp charras 
Le 13/10/2017 à 00:23, Wayne Stambaugh a écrit :
> On 10/12/2017 1:52 PM, Kristoffer Ödmark wrote:
>>
>> On 10/12/2017 06:56 PM, Wayne Stambaugh wrote:
>>> Kristoffer,
>>>
>>> There is no confusion and there is nothing to fix.  The document field
>>> is just like any other field.  It is initially imported from the library
>>> symbol to the schematic symbol (they are *not* the same nor should they
>>> be) when a symbol is added to the schematic.  Once you modify a field in
>>> a schematic symbol it takes precedence over the the field in the library
>>> symbol that was linked when the symbol was added to the schematic.  It
>>
>> But it doesnt? If i set the variable Datasheet, which is mandatory, I do
>> not get a context menu option to "Open documentation". I am not
>> complaining about the document field, I am complaining that It is stored
>> in two different ways, once in the dcm file and once in the library.
> 
> I'm not sure why there is not an "Edit Datasheet" entry in the
> "Properties" submenu of the symbol context menu.  I guess no one ever
> noticed it before.  It probably would not be that difficult to add.  The
> dcm file is for storing the description, key word, and datasheet URL
> information for all library symbols.  The library symbol fields are
> stored in the lib file and are only stored for the root symbol.  What
> should happen is the alias document file text should be copied to the
> schematic symbol DATASHEET field when it is added to the schematic.  If
> it isn't, this is a bug.

FYI, in fact this confusion comes from a bug introduced a long time ago:

Initially, the field name was "Sheet" not "Datasheet".
It should be "SchematicSheet"

The purpose was to be able to create a component acting as a hierarchical sheet:
The component in a root sheet, and its internal sheet ("SchematicSheet") 
similar to a sub sheet.

But unfortunately, it was never done, and one day the word "Sheet" became 
"Datasheet", thus creating
a serious confusion.

Perhaps the "DATASHEET" field (attached to the symbol) and the "documentation" 
string (attached to a
alias) should be clearly redefined for the V5.

By the way, do you know why the .dcm file exists?
It is similar to the .idx index file of old spice libs.

In the early time of eeschema, Kicad was stored on a server and was used in 
classrooms and on PCs
connected by a "slow" network link: network cards were ISA cards and the link 
speed was roughly 2400
bps.

So loading all needed schematic libraries to choose a symbol was a too time 
costly process, making
Eeschema barely usable.
Using small .dcm files to display a list of symbols and some info fixed this 
issue.

Nowadays, link speed, PC speed and memory sizes have 3 order of magnitude, and 
.dcm files (a relic
of this time) is more an annoying feature.

> 
>>
>> Or are you saying that there is a difference between documentation and
>> datasheet?
> 
> Yes.  There is a mandatory (must exist but can be empty) DATASHEET field
> for both the root library symbol and it's associated schematic symbol.
> If you add a library symbol by it's alias, then the root DATASHEET field
> would be incorrect so the "Document" (this is inconsistent but it's
> legacy baggage which will be addressed by the new file formats) entry in
> the dcm file would contain the appropriate datasheet link.
> 
>>
>>> has to be this way.  You would not want your schematic symbol fields
>>> updated every time the library symbol fields are changed.  This only
>>> makes sense for atomic (fully defined ) symbols and would completely
>>> fall apart for generic symbols like op-amps and logic gates.  I believe
>>> Orson recently added a tool to refresh the schematic symbol fields with
>>> the linked library symbol fields.  I haven't tried it yet but you may
>>> find that useful.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 10/12/2017 9:12 AM, Kristoffer Ödmark wrote:
 Sorry for double messages but one solution could be to use the Library
 stored documentation to autofill the FIELD variable IF it is empty. And
 then base all the functionality on the field variable?

 I could probably fix this if it seems an okay solution to everyone? This
 would basically be making the field variable overriding the properties
 information. But still not break anything from the libs.

 Or should this just be left as is until the new symbool format is
 implemented?

 On 10/12/2017 03:00 PM, Kristoffer Ödmark wrote:
> Hey!
>
> I noticed today that there are two places to store the datasheet
> information, one is in the Mandatory Field "Datasheet", and one is in
> the porperty of the part in the lib. These have different
> functionality in the schematic editor and in the library part editor.
>
> I think these should somehow be merged or one of them removed. As it
> is now, it is a bit confusing with the "Open Documentation" context
> menu, and the "Show Datasheet" button in the

Re: [Kicad-developers] Datasheet confusion

2017-10-12 Thread Wayne Stambaugh 
On 10/12/2017 1:52 PM, Kristoffer Ödmark wrote:
> 
> On 10/12/2017 06:56 PM, Wayne Stambaugh wrote:
>> Kristoffer,
>>
>> There is no confusion and there is nothing to fix.  The document field
>> is just like any other field.  It is initially imported from the library
>> symbol to the schematic symbol (they are *not* the same nor should they
>> be) when a symbol is added to the schematic.  Once you modify a field in
>> a schematic symbol it takes precedence over the the field in the library
>> symbol that was linked when the symbol was added to the schematic.  It
> 
> But it doesnt? If i set the variable Datasheet, which is mandatory, I do
> not get a context menu option to "Open documentation". I am not
> complaining about the document field, I am complaining that It is stored
> in two different ways, once in the dcm file and once in the library.

I'm not sure why there is not an "Edit Datasheet" entry in the
"Properties" submenu of the symbol context menu.  I guess no one ever
noticed it before.  It probably would not be that difficult to add.  The
dcm file is for storing the description, key word, and datasheet URL
information for all library symbols.  The library symbol fields are
stored in the lib file and are only stored for the root symbol.  What
should happen is the alias document file text should be copied to the
schematic symbol DATASHEET field when it is added to the schematic.  If
it isn't, this is a bug.

> 
> Or are you saying that there is a difference between documentation and
> datasheet?

Yes.  There is a mandatory (must exist but can be empty) DATASHEET field
for both the root library symbol and it's associated schematic symbol.
If you add a library symbol by it's alias, then the root DATASHEET field
would be incorrect so the "Document" (this is inconsistent but it's
legacy baggage which will be addressed by the new file formats) entry in
the dcm file would contain the appropriate datasheet link.

> 
>> has to be this way.  You would not want your schematic symbol fields
>> updated every time the library symbol fields are changed.  This only
>> makes sense for atomic (fully defined ) symbols and would completely
>> fall apart for generic symbols like op-amps and logic gates.  I believe
>> Orson recently added a tool to refresh the schematic symbol fields with
>> the linked library symbol fields.  I haven't tried it yet but you may
>> find that useful.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 10/12/2017 9:12 AM, Kristoffer Ödmark wrote:
>>> Sorry for double messages but one solution could be to use the Library
>>> stored documentation to autofill the FIELD variable IF it is empty. And
>>> then base all the functionality on the field variable?
>>>
>>> I could probably fix this if it seems an okay solution to everyone? This
>>> would basically be making the field variable overriding the properties
>>> information. But still not break anything from the libs.
>>>
>>> Or should this just be left as is until the new symbool format is
>>> implemented?
>>>
>>> On 10/12/2017 03:00 PM, Kristoffer Ödmark wrote:
 Hey!

 I noticed today that there are two places to store the datasheet
 information, one is in the Mandatory Field "Datasheet", and one is in
 the porperty of the part in the lib. These have different
 functionality in the schematic editor and in the library part editor.

 I think these should somehow be merged or one of them removed. As it
 is now, it is a bit confusing with the "Open Documentation" context
 menu, and the "Show Datasheet" button in the properties editor.

 For me, mergin every functionality into the field variable seems like
 the most robust way, since most other tools are using these field
 variables and that is the most accesible way, and since the Datasheet
 field is mandatory anyway, but can still be empty.


>>>
>>
>> ___
>> 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] Datasheet confusion

2017-10-12 Thread Kristoffer Ödmark 


On 10/12/2017 06:56 PM, Wayne Stambaugh wrote:

Kristoffer,

There is no confusion and there is nothing to fix.  The document field
is just like any other field.  It is initially imported from the library
symbol to the schematic symbol (they are *not* the same nor should they
be) when a symbol is added to the schematic.  Once you modify a field in
a schematic symbol it takes precedence over the the field in the library
symbol that was linked when the symbol was added to the schematic.  It


But it doesnt? If i set the variable Datasheet, which is mandatory, I do 
not get a context menu option to "Open documentation". I am not 
complaining about the document field, I am complaining that It is stored 
in two different ways, once in the dcm file and once in the library.


Or are you saying that there is a difference between documentation and 
datasheet?



has to be this way.  You would not want your schematic symbol fields
updated every time the library symbol fields are changed.  This only
makes sense for atomic (fully defined ) symbols and would completely
fall apart for generic symbols like op-amps and logic gates.  I believe
Orson recently added a tool to refresh the schematic symbol fields with
the linked library symbol fields.  I haven't tried it yet but you may
find that useful.

Cheers,

Wayne

On 10/12/2017 9:12 AM, Kristoffer Ödmark wrote:

Sorry for double messages but one solution could be to use the Library
stored documentation to autofill the FIELD variable IF it is empty. And
then base all the functionality on the field variable?

I could probably fix this if it seems an okay solution to everyone? This
would basically be making the field variable overriding the properties
information. But still not break anything from the libs.

Or should this just be left as is until the new symbool format is
implemented?

On 10/12/2017 03:00 PM, Kristoffer Ödmark wrote:

Hey!

I noticed today that there are two places to store the datasheet
information, one is in the Mandatory Field "Datasheet", and one is in
the porperty of the part in the lib. These have different
functionality in the schematic editor and in the library part editor.

I think these should somehow be merged or one of them removed. As it
is now, it is a bit confusing with the "Open Documentation" context
menu, and the "Show Datasheet" button in the properties editor.

For me, mergin every functionality into the field variable seems like
the most robust way, since most other tools are using these field
variables and that is the most accesible way, and since the Datasheet
field is mandatory anyway, but can still be empty.






___
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



--
 -Kristoffer

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

Re: [Kicad-developers] Datasheet confusion

2017-10-12 Thread Wayne Stambaugh 
Kristoffer,

There is no confusion and there is nothing to fix.  The document field
is just like any other field.  It is initially imported from the library
symbol to the schematic symbol (they are *not* the same nor should they
be) when a symbol is added to the schematic.  Once you modify a field in
a schematic symbol it takes precedence over the the field in the library
symbol that was linked when the symbol was added to the schematic.  It
has to be this way.  You would not want your schematic symbol fields
updated every time the library symbol fields are changed.  This only
makes sense for atomic (fully defined ) symbols and would completely
fall apart for generic symbols like op-amps and logic gates.  I believe
Orson recently added a tool to refresh the schematic symbol fields with
the linked library symbol fields.  I haven't tried it yet but you may
find that useful.

Cheers,

Wayne

On 10/12/2017 9:12 AM, Kristoffer Ödmark wrote:
> Sorry for double messages but one solution could be to use the Library
> stored documentation to autofill the FIELD variable IF it is empty. And
> then base all the functionality on the field variable?
> 
> I could probably fix this if it seems an okay solution to everyone? This
> would basically be making the field variable overriding the properties
> information. But still not break anything from the libs.
> 
> Or should this just be left as is until the new symbool format is
> implemented?
> 
> On 10/12/2017 03:00 PM, Kristoffer Ödmark wrote:
>> Hey!
>>
>> I noticed today that there are two places to store the datasheet
>> information, one is in the Mandatory Field "Datasheet", and one is in
>> the porperty of the part in the lib. These have different
>> functionality in the schematic editor and in the library part editor.
>>
>> I think these should somehow be merged or one of them removed. As it
>> is now, it is a bit confusing with the "Open Documentation" context
>> menu, and the "Show Datasheet" button in the properties editor.
>>
>> For me, mergin every functionality into the field variable seems like
>> the most robust way, since most other tools are using these field
>> variables and that is the most accesible way, and since the Datasheet
>> field is mandatory anyway, but can still be empty.
>>
>>
> 

___
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] Datasheet confusion

2017-10-12 Thread Rene Pöschl 

On 12/10/17 15:12, Kristoffer Ödmark wrote:

Sorry for double messages but one solution could be to use the Library
stored documentation to autofill the FIELD variable IF it is empty. And
then base all the functionality on the field variable?

I could probably fix this if it seems an okay solution to everyone?
This would basically be making the field variable overriding the
properties information. But still not break anything from the libs.

Or should this just be left as is until the new symbool format is
implemented?

On 10/12/2017 03:00 PM, Kristoffer Ödmark wrote:

Hey!

I noticed today that there are two places to store the datasheet
information, one is in the Mandatory Field "Datasheet", and one is in
the porperty of the part in the lib. These have different functionality
in the schematic editor and in the library part editor.

I think these should somehow be merged or one of them removed. As it is
now, it is a bit confusing with the "Open Documentation" context menu,
and the "Show Datasheet" button in the properties editor.

For me, mergin every functionality into the field variable seems like
the most robust way, since most other tools are using these field
variables and that is the most accesible way, and since the Datasheet
field is mandatory anyway, but can still be empty.



The field variable is the same for all aliases.

That's why the kicad library convention does not allow it's use.

We only use the datasheet property that is stored in the dcm file. (This 
property can differ for every alias.)



___
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] Datasheet confusion

2017-10-12 Thread Kristoffer Ödmark 
Sorry for double messages but one solution could be to use the Library 
stored documentation to autofill the FIELD variable IF it is empty. And 
then base all the functionality on the field variable?


I could probably fix this if it seems an okay solution to everyone? 
This would basically be making the field variable overriding the 
properties information. But still not break anything from the libs.


Or should this just be left as is until the new symbool format is 
implemented?


On 10/12/2017 03:00 PM, Kristoffer Ödmark wrote:

Hey!

I noticed today that there are two places to store the datasheet 
information, one is in the Mandatory Field "Datasheet", and one is in 
the porperty of the part in the lib. These have different functionality 
in the schematic editor and in the library part editor.


I think these should somehow be merged or one of them removed. As it is 
now, it is a bit confusing with the "Open Documentation" context menu, 
and the "Show Datasheet" button in the properties editor.


For me, mergin every functionality into the field variable seems like 
the most robust way, since most other tools are using these field 
variables and that is the most accesible way, and since the Datasheet 
field is mandatory anyway, but can still be empty.





--
 -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] Datasheet confusion

2017-10-12 Thread Kristoffer Ödmark 

Hey!

I noticed today that there are two places to store the datasheet 
information, one is in the Mandatory Field "Datasheet", and one is in 
the porperty of the part in the lib. These have different functionality 
in the schematic editor and in the library part editor.


I think these should somehow be merged or one of them removed. As it is 
now, it is a bit confusing with the "Open Documentation" context menu, 
and the "Show Datasheet" button in the properties editor.


For me, mergin every functionality into the field variable seems like 
the most robust way, since most other tools are using these field 
variables and that is the most accesible way, and since the Datasheet 
field is mandatory anyway, but can still be empty.



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