X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Message-ID: <1423790149.1017.18.camel@cam.ac.uk>
Subject: Re: [geda-user] gschem refactoring ideas  -- overall architecture
 document.
From: Peter Clifton <pcjc2 AT cam DOT ac DOT uk>
To: geda-user AT delorie DOT com
Date: Fri, 13 Feb 2015 01:15:49 +0000
In-Reply-To: <20150212090824.GA3142@visitor2.iram.es>
References: <54DBDFF1 DOT 1010409 AT ecosensory DOT com>
	 <FE92BD5F-0CB3-4CAE-B3BC-D63D22B579DA AT noqsi DOT com>
	 <mbgul5$j8i$1 AT ger DOT gmane DOT org>
	 <220C1787-45BF-459E-B217-29686DC25DF2 AT noqsi DOT com>
	 <20150212090824 DOT GA3142 AT visitor2 DOT iram DOT es>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.7-0ubuntu1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Thu, 2015-02-12 at 10:08 +0100, Gabriel Paubert wrote:
> On Wed, Feb 11, 2015 at 05:08:32PM -1000, John Doty wrote:
> > 
> > On Feb 11, 2015, at 3:19 PM, Kai-Martin Knaak <knaak AT iqo DOT uni-hannover DOT de> wrote:
> > 
> > > A unambiguous sort of symbols on save would finally solve a still standing 
> > > issue you may remember: gnetlist behaves differently depending on the 
> > > order symbols were added. 
> > 
> > I agree this is an annoyance. However, take account of the problem of filled graphics, where one may manipulate that order to get the appearance you want. That might require the addition of layer numbers to the format in to work with canonicalization. 
> 
> I believe filled graphics are a rather recent addition to gschem 
> (I can't see any in my schematics), this rather shows that they 
> were not properly designed in the first place IMO.

Thanks for that rather unhelpful pronouncement. I believe my design for
their rendering is "solid" (pardon the pun). It uses a file order
implied Z-order. What is lacking is the controls in gschem to shift the
objects around.. a simple "bring to front" and "send to back" should
suffice in the first instance.

What is the really lacking part though, is any way to create complex
paths (open or closed) within gschem... I implemented the file-format
and rendering support, but did not manage to write a decent "inkscape
like" path editor.

The easiest way to get a complex path in gshcem is actually to fire up
inkscape, (with an appropriate coordinate system), draw (or import) the
complex thing you want, then paste the resulting SVG path string(s) into
gschem path object(s).

Our path syntax was deliberately copied as a subset of SVG's. As an
implementation detail, our parser was stolen from librsvg. I
deliberately did not remove support for the parts of path syntax we
don't explicitly support, so as a bonus, gschem will read most/all SVG
path strings, then and regularise them to our expected sub-set on save.

You need to load and save with gschem once to regularise and stabilise
the file contents if you paste in an arbitrary SVG path string, but that
shouldn't be a big deal.

Peter

-- 
Peter Clifton <peter DOT clifton AT clifton-electronics DOT co DOT uk>

Clifton Electronics