Mail Archives: geda-user/2016/08/02/18:42:01
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--
- Raw text -