X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Wed, 3 Aug 2016 00:40:14 +0200 (CEST)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: "Ouabache Designworks (z3qmtr45 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] Plans for gEDA/gaf (was: [OT] ngspice integration
 in KiCad)
In-Reply-To: <CAOP4iL2mhxmbjkkLKTgbtME-VEmAFwQCAQGc412KKNfAdzA1og@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1608030034050.9981@nimbus>
References: <CANqhZFwC48g07MUY411a20C5oipkmmkzUimhz8OgvL2Thi-yDg AT mail DOT gmail DOT com> <20160722171754 DOT GB17595 AT localhost DOT localdomain> <CAM2RGhRjABmejtuSz1PbGFFF+EHhznGGTODoh0bu2y4FJM=Cbw AT mail DOT gmail DOT com> <20160723065723 DOT GC17595 AT localhost DOT localdomain>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1607231009290 DOT 7286 AT igor2priv> <20160723092248 DOT GF17595 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 11 DOT 1607231423480 DOT 2224 AT nimbus> <20160724053502 DOT GM17595 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 11 DOT 1607271434200 DOT 1841 AT nimbus> <9719FF2C-AC85-4824-89E9-447216E7FA65 AT sbcglobal DOT net>
 <alpine DOT DEB DOT 2 DOT 11 DOT 1607301258260 DOT 1409 AT nimbus> <939E39F7-B4DA-4B56-A640-C7E6E4ECF955 AT sbcglobal DOT net> <alpine DOT DEB DOT 2 DOT 11 DOT 1608021426490 DOT 1398 AT nimbus> <CAOP4iL2MsJG+U45C83zWevHcWwLoJAnYa9uYzM0fqoXvxg66qg AT mail DOT gmail DOT com> <9ED612EF-E3F5-48CC-8FB3-B67CA7DEE432 AT noqsi DOT com>
 <CAOP4iL1TcA4nzvCBJuFQ7GaOA-Owub2ikedXOvrcWipr9=buxA AT mail DOT gmail DOT com> <9D554144-D41A-463F-955F-68227BC3D167 AT noqsi DOT com> <CAOP4iL2mhxmbjkkLKTgbtME-VEmAFwQCAQGc412KKNfAdzA1og AT mail DOT gmail DOT com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1663948507-1470177614=:9981"
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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1663948507-1470177614=:9981
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

Evan Foss:
> How about SDL?

SDL is a library for (among other things) drawing graphics on the screen. 
It is vaguely comparable with Cairo but more geared towards game 
development.  If we wanted to use SDL for the gschem GUI, we'd have to 
either use an additional library which provides a toolkit for SDL, or 
implement all GUI widgets ourselves.


Edward Hennessy:
> Roland Lutz:
> > The core library should not know about GObjects in any way.  Of 
> > course, it would be possible to create a GObject wrapper for the core 
> > library which could be used for creating language bindings.
>
> Sure, but its extra work to create all the wrapper objects. And wrapping 
> RIAA with reference counting is a mess.

RIAA and reference counting both don't make sense on this level.  We're 
talking about a simple C library which defines some structs and declares 
functions to work on them.  If you want a nice C++ class which allocates 
and frees e.g. a revision RIAA-like, just write it.  Having this kind of 
logic in the library API just makes things unnecessarily complicated.

> > The library would use a value-oriented approach: the properties of a 
> > schematic object are only defined in respect to a given revision.  If 
> > an application needed property change hooks, it could execute them 
> > itself from the command which replaces its current revision with a new 
> > one.
>
> Sure, the wrapper objects from above could provide property change 
> notification. It’s extra work to manage this layer. And when scripts 
> modify the “libcore” POD objects, it might not even be capable of 
> determining a property change occurred.

There's no such thing as a "change" in a value-oriented approach.  That's 
intentional because having a place-oriented approach would force that 
model on all code parts, while it's easy the other way around.

Detecting a property change is always possible because once you finalize a 
revision, no code part can change it (except by poking directly into 
memory).  When a script creates a modified copy of a revision and passes 
it back to the main application, it can query for differences between the 
two revisions and act accordingly.

> > I'm not sure what's your point here.  Do you want to facilitate using 
> > gschem widgets in other GTK applications?  The actual Cairo rendering 
> > code may be useful to non-GTK or even non-interactive applications.
>
> Exactly.

Exactly what?  libgedacairo is already available as a library which could, 
in theory, be used in other applications.  The only problem I see right 
now is that it depends on the internal libgeda object representation which 
doesn't make much sense for applications outside the main geda-gaf 
repository.

> What is the downside of using Vala?

Potential contributors would have to learn a new programming language.

> What can go wrong and what is the chance of it going wrong?

The single developer knowing Vala could leave the project.  Mono could be 
bought by Microsoft and discontinued.

> I disagree with you on the “libcore” responsibilities, because small 
> amounts of additional code at this level can significantly reduce the 
> amount of work needed to implement the GUI level.

There's a difference between crafting a good API and merging application 
specifics into a library.  What if a program should use the core library 
but isn't written in C++, or doesn't use GLib?

> > Why would the core library need to know about scripting?
>
> For example, libgeda has the capability of executing a script to load a 
> component.

The core library wouldn't have to know about scripting in order to allow 
that; providing a hook for adding custom library sources would be 
sufficient.


John Eaton:
> Tried it on Ubuntu 15.10 and I get:
>
> xi: XCreateFontSet: Unable to create font set

Xi uses a compiled-in list of X font names (Helvetica and Liberation). 
If neither of the fonts is installed on your system, you'll see this error 
message.  You can either install the fonts (I believe it's the 
"xfonts-75dpi" package in Debian) or change the list of fonts in 
src/toolkit/connection.cxx.

> If you start out with geda then that will drive how you architect the 
> entire tool.  You want to do that with a blank slate.

I want to start with a blank slate GUI-wise, but have it work like gEDA 
logic-wise.  I like the way how gEDA works and don't see a necessity to 
replace that with something else.


DJ Delorie:
> Please keep in mind that C is a subset of C++

Strictly speaking, it's not, as opposed to e.g. Objective C or "C with 
GObjects".

> Switching gaf and pcb to C++ - at least a minimal C-like subset of C++ - 
> would greatly improve maintainability, since the applications are highly 
> object-oriented already.

I doubt that.  People would start using all kinds of C++ idioms, and after 
a few years and developer changes, the code would be completely 
unmaintainable.  "A minimal C-like subset of C++", on the other hand, may 
work.


John Eaton:
> How about complete hierarchical design support with uniquification?

What do you mean by "uniquification"?

> How about Busses? IC's need support for wires, vectors and busses. 
> Gschem does wires with some graphic support for vectors but nothing for 
> busses.

I implemented busses in an experimental branch, but since I got mixed 
feedback, I didn't merge it back into master.

> Gschem supports small data designs. IC designers need support for big 
> data projects.

That's one of the reasons why the storage library exists.

--8323329-1663948507-1470177614=:9981--