Peter:
> k...@aspodata.se (Karl Hammar) writes:
> >[about code that enables recursion in component-library-search]
> Nack, for a number of reasons.
>
*
> 1) GRegex was introduced in GLib 2.14, and during the 1.7.x cycle we are
> targetting GLib 2.12 or later.
Regular expression is actually
On Tue, 24 May 2011 07:57:28 -0400
DJ Delorie wrote:
>
> > It might be useful to include a UUID in symbols so that once a
> > particular symbol is in use, the identity of that symbol can be
> > guaranteed through a UUID reference.
>
> Do you mean a UUID for a symbol template in a library, or a
On May 24, 2011, at 2:34 PM, DJ Delorie wrote:
>
>> but I avoid name conflicts in project libraries.
>
> If we find ourselves gaining popularity and a plethora of libraries
> comes into being, we may no longer have the luxury of avoiding name
> conflict. "name scoping" came up a few times in t
> It might be useful to include a UUID in symbols so that once a
> particular symbol is in use, the identity of that symbol can be
> guaranteed through a UUID reference.
Do you mean a UUID for a symbol template in a library, or a UUID for a
specific instance of a symbol in a schematic?
On Tue, 24 May 2011 01:34:04 -0400
DJ Delorie wrote:
> > but I avoid name conflicts in project libraries.
>
> If we find ourselves gaining popularity and a plethora of libraries
> comes into being, we may no longer have the luxury of avoiding name
> conflict. "name scoping" came up a few times
> but I avoid name conflicts in project libraries.
If we find ourselves gaining popularity and a plethora of libraries
comes into being, we may no longer have the luxury of avoiding name
conflict. "name scoping" came up a few times in the library
discussion, I think keeping the issue in mind, ev
Colin D Bennett wrote:
>> In the library browser you have the choise to embed the component
>> in the .sch file. I think that might be the solutions for your
>> scenarios.
>
> That would be a reasonable solution. I guess I've always overlooked
> that option.
There is a catch: Unembed works only
On May 24, 2011, at 5:18 AM, Karl Hammar wrote:
> In the library browser you have the choise to embed the component
> in the .sch file. I think that might be the solutions for your
> scenarios.
There are a couple of problems with embedded symbols:
1. You can't edit them.
2. Once embedded, they
> I would like to see some options added to the symbol library dialogue:
>
> 1. Create a new (e.g. local) library
> 2. Copy an existing symbol to another (e.g. local) library
> 3. Create a completely new symbol (perhaps using a wizard interface)
Incorporating DJboxsym (or similar) into the wizard
On May 24, 2011, at 12:29 AM, Peter Brett wrote:
> 3) I strongly recommend *not* using component-library-search because it
> gives you no control over the precedence ordering of libraries when
> searching for a symbol name match -- you're entirely at the mercy of the
> order in which the filesyst
On 05/23/2011 11:44 AM, Karl Hammar wrote:
comment on the functionality which the screen dump hints
you at?
Like it.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
On 05/23/2011 10:13 AM, Karl Hammar wrote:
changed component-library-search to descend
into subdirectories (see diff).
The result is as seen in attachment (dump.jpg).
Dang, that was quick Karl!
John
___
geda-user mailing list
geda-user@moria.seul
On Mon, 2011-05-23 at 13:31 -0700, Colin D Bennett wrote:
> On Mon, 23 May 2011 22:18:54 +0200 (CEST)
> k...@aspodata.se (Karl Hammar) wrote:
>
> > In the library browser you have the choise to embed the component
> > in the .sch file. I think that might be the solutions for your
> > scenarios.
>
On Mon, 23 May 2011 22:18:54 +0200 (CEST)
k...@aspodata.se (Karl Hammar) wrote:
> In the library browser you have the choise to embed the component
> in the .sch file. I think that might be the solutions for your
> scenarios.
That would be a reasonable solution. I guess I've always overlooked
th
> On Mon, 23 May 2011 17:13:01 +0200 (CEST)
> k...@aspodata.se (Karl Hammar) wrote:
> > The result is as seen in attachment (dump.jpg).
> Very nice!
Thank you.
> However, for this to be usable wouldn't it be important to have a good
I think it usable as is (though not finished).
> way to import
On Mon, 23 May 2011 17:13:01 +0200 (CEST)
k...@aspodata.se (Karl Hammar) wrote:
> There are a lot of symbols available at cvs.gedasymbols.org.
>
> To make them all available to gschem I have added:
>
> (component-library-search
> "${HOME}/Net/cvs/cvs.gedasymbols.org/www/user")
>
> to my ~/.gEDA
Peter:
> k...@aspodata.se (Karl Hammar) writes:
> > [about code that enables recursion in component-library-search]
> Nack, for a number of reasons.
>
> 1) GRegex was introduced in GLib 2.14, and during the 1.7.x cycle we are
> targetting GLib 2.12 or later.
>
> 2) This is an absolutely *textbook*
k...@aspodata.se (Karl Hammar) writes:
> The code that executes the ...-search command is in libgeda/src/g_rc.c
> (relative the top of the git repo.), in the function:
>
> SCM g_rc_component_library_search(SCM path);
>
> I have changed that function to a wrapper around
>
> int C_g_rc_component_l
18 matches
Mail list logo
