Mail Archives: geda-user/2016/08/02/09:21:35
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-1370255553-1470143969=:1398
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
On Mon, 1 Aug 2016, Edward Hennessy (ehennes AT sbcglobal DOT net) [via
geda-user AT delorie DOT com] wrote:
> Let’s call this new library "libcore" for clarity in discussion, and
> “libgeda” for the existing legacy library.
>
> Does you vision of libcore support any of the following?
>
> 1. GObjectIntrospection and GIR files for language bindings?
No. 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.
> 2. Weak references to basic objects?
No. The objects would be either simple data structures or pointers to
opaque types.
> 3. Property change notifications of some sort? (gobject signals,
> listener/observer patterns, etc...)
No. 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.
> In regards to merging back into gschem, do you see gschem as the
> schematic editor going forward?
Originally, I started out writing my own editing GUI which was indended as
a replacement for both gschem and PCB. This is not realistically going to
happen any time soon, though, so I'd suggest sticking with gschem.
> If gschem is the editor going forward, I’d like to see:
>
> 1. GUI widgets moved out of gschem into a separate library, “libgschem,”
> which could be renamed from libedacairo.
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.
> 2. Migrate to GTK+3
That would mean losing multi-stroke hotkeys (as discussed in the past).
Migrating to an even more recent GTK would mean losing tear-off menus.
> 3. Potentially use a more productive language for gschem and libgschem,
> like Vala or C#.
C# uses the .NET framework, which would theoretically be an option via
Mono, but its political fate is uncertain. By using Vala, we'd lock in
even more than by using Scheme.
The options are really quite limited here. I think it would be best to
stick with C for the existing schematic editor, but C++ or an interpreted
language may be an option for a future project.
> What are your thoughts on a clean restart on the UI?
I already started such a project: http://hedmen.org/xi/
The problem is that this requires a non-trivial amount of work. I've been
working on Xi for a few years, and there's still a lot to do.
> I agree with you on the Guile dependency, but suspect it could be
> removed with a dependency inversion. In essence, “libcore” or “libgeda”
> would know about scripting, but it wouldn’t know that it is Guile,
> Python, or whatever. This pattern might also be applied to rendering
> too.
Why would the core library need to know about scripting?
--8323329-1370255553-1470143969=:1398--
- Raw text -