X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com From: Peter TB Brett To: geda-user AT delorie DOT com Subject: [geda-user] Fwd: 1.7.2 before Christmas? Also, 1.8.0, and feature branch status. Date: Sun, 11 Dec 2011 08:30:32 +0000 Message-ID: <8739crldcn.fsf@mckeon.peter-b.co.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Reply-To: geda-user AT delorie DOT com [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 Remote Sensing Research Group Surrey Space Centre