Mail Archives: geda-user/2011/12/11/04:13:05
[Forwarding to user list, since someone might be interested]
Hi folks,
I thought it might be a good idea to write a general update on the state
of gEDA/gaf development, so here goes.
Warning: very long e-mail ahead!
gEDA/gaf 1.7.2 release schedule
-------------------------------
I've now completed pretty much all of the things I was hoping to do
before 1.7.2, so I was wondering whether it would be possible to make a
1.7.2 unstable release [1] before Christmas. What do you think?
The main problem with the blocking bug (translating the Scheme API error
messages) is getting information on the correct gettext domain into the
Scheme environment somehow. I've got a few ideas, but I've yet to find
an elegant one.
[1] https://launchpad.net/geda/+milestone/1.7.2
gEDA/gaf 1.8.0 release schedule
-------------------------------
In the longer term, geda-gaf 1.8.0 should be released at some point,
because unstable now has a *lot* of changes. On the other hand, the
delta in terms of number of patches from 1.6.0 is still smaller than the
delta between 1.4.0 and 1.6.0:
$ git rev-list 1.4.0-20080127..1.6.0-20091004 | wc -l
1048
$ git rev-list 1.6.0-20091004..origin/master | wc -l
743
Some idea of the user-visible changes between 1.6.0 and the current
master can be gained by reading NEWS [3], which I've made sure to keep
up-to-date. Obviously, many of the changes are "under-the-hood", such
as fixes to Windows support, the new Scheme API, Guile 2.x support, and
better warnings when rc files can't be loaded.
The main thing motivating me to push for 1.8.0 at the moment is that
some distributions are keen to move from Guile 1.8.x to Guile 2.x, and
geda-gaf 1.6.x can't ever feasibly support Guile 2.x.
So, what are the long poles for geda-gaf 1.8.0 [2]?
Here's a summary of the current status of the scheduled bugs:
1) #698603 Thick lines are longer when printed
Fixing this bug is really tricky. There are two options:
a) Very extensive changes to the libgeda printing code, so that more
than one line cap style can be used in a schematic file. This
would be a pain, because in the longer term I would like to...
b) ...rip out the libgeda printing code as part of moving to using
libgedacairo for all rendering (which fixes the bug). However,
libgedacairo is a way of being ready yet (of which more later).
I don't feel like either of these are really practical for 1.8.0
(although I would gladly accept patches to implement (a) above).
2) #698849 Add manpages for tools
As a rule, we should be providing manpages for all binaries installed
in the $PATH. Currently, the following lack manpages:
- convert_sym
- garchive
- gmk_sym
- gnet_hier_verilog.sh
- gschlas
- gschupdate
- gsymfix.pl
- gsymupdate
- olib
- pads_backannotate
- pcb_backannotate
- refdes_renum
- sarlacc_schem
- sarlacc_sym
- sch2eaglepos.sh
- smash_megafile
- sw2asc
- tragesym
I had a campaign in January to update & write manpages, and added
pages for gsch2pcb and gattrib. However, for most the remaining
tools listed above, I have *no idea* what they do, how they work, or
whether they're even still useful. What should we be doing about
this issue? Maybe some users on the mailing lists could help
out. :-)
3) #698578 error messages in status window should be more explicit
This mostly concerns errors that occur in rc files. In January, I
made some substantial changes to the way that system and user rc
files are loaded that allows libgeda-using applications to actually
do something useful about rc file problems, and gschem now pops up
helpful dialog boxes if the rc files read at startup are broken.
However, there's no sensible way of doing the same for the
per-directory rc files that are read later on without some pretty
extensive refactoring of the whole way in which rc files are read --
which I would like to do as part of moving to parsed config files
post-1.8.0. I'm tempted to close this bug for now as "Fix
Committed".
#707064 Remove unconnected net cues for netname connected nets
I'm not sure what the status of this bug is -- I've requested an
update from Krzysztof.
If there are any other bugs that you think are *absolutely essential* to be
fixed before 1.8.0, please let me know (preferably by commenting on the
bug report to that effect).
We also need to have a string freeze, and get translations updated! I'm
not sure what the process for that these days, or how long that would
take...
[2] https://launchpad.net/geda/+milestone/1.8.0
[3] http://git.gpleda.org/?p=gaf.git;a=blob;f=NEWS;hb=master
Status of my feature branches
-----------------------------
I currently have two feature branches running [4]:
1) libgedacairo
This branch factors out gschem's schematic rendering code into a
separate GObject- and Cairo-based shared library. This is designed
with several aims in mind:
- We should only have to maintain one rendering codebase (rather than
the current two).
- It would be nice to have a nice, easy-to-use command-line program
for batch conversion of schematics to e.g. PDF, rather than the
gschem + print.scm mess we currently have.
- Other applications might want to render or display gEDA
schematics/symbols.
- Support via GTK for using a standard print dialog in gschem to
print directly to a printer, get access to printer options via
CUPS, etc.
Currently, the state of the branch is that the library is
more-or-less complete. Most gschem rendering occurs via
libgedacairo, with the exception of "rubber" drawing operations.
It's 90% done, just the last fiddly 90% to go. ;-)
2) config-sys
This branch will convert almost all gEDA configuration to come from
static, standard format files instead of from Scheme scripts (but
extending gEDA with Scheme will still be supported, of course). The
need for this is explained by bug 700333 [5].
The current state of this branch is that I have written an API
specification [6], but no code yet.
[4] http://peter-b.co.uk/software/geda.html
[5] https://bugs.launchpad.net/geda/+bug/700333
[6] http://goo.gl/Lcbna
That's all, folks! I'd just like to remind you all to use the gEDA bug
tracker at http://bugs.launchpad.net/geda, and to feel free to e-mail me
with any comments on my branches.
Regards,
Peter
--
Peter Brett <peter AT peter-b DOT co DOT uk>
Remote Sensing Research Group
Surrey Space Centre
- Raw text -