geda-developers team mailing list archive

[Peter TB Brett <peter@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre

Attachment: pgpJ_vrNofjnz.pgp
Description: PGP signature