Op vrijdag 30 december 2011 09:06:58 schreef u: > On Dec 30, 2011, at 2:57 AM, Geert Janssens wrote: > > Op donderdag 29 december 2011 14:18:38 schreef u: > >> On Dec 29, 2011, at 12:24 PM, Christian Stimming wrote: > >>> Am Mittwoch, 28. Dezember 2011, 18:16:48 schrieb John Ralls: > >>>> A release plan isn't a "list of features" to "get enough reasons" > >>>> for > >>>> a > >>>> 2.6.0 release. It's a list of features and existing bugs, whether > >>>> implemented or not, that the project team agrees should be what's > >>>> going to be in the 2.6.0 release. It guides the testers who use > >>>> the > >>>> development (2.5.x) releases, so that they know what to try out, > >>>> and > >>>> to write bugs against. > >>> > >>> Ok, let my re-phrase my original proposal, like so: > >>> > >>> Over the past months, several very useful features for small > >>> business > >>> usage have been added to trunk. I'd like to get those features out > >>> in > >>> the stable releases so that users who are asking for this can get > >>> them > >>> through their default distro package, which implies those features > >>> need > >>> to appear in a stable release series. > >>> > >>> Here's an (incomplete) list of new features for small business users > >>> which is now available in trunk but not in 2.4: > >>> > >>> * Customer / Vendor overview pages > >>> * Print to PDF for reports and invoices by a single button click > >>> * Allow "Filter By" settings to be saved and re-used > >>> * Customer overview reports > >>> * Line chart report for Net Worth (Bug #664862) > >>> * Re-assign existing transactions as payments > >>> * Duplicate invoices > >>> * Easier invoice / bill handling: Post, Print, or Duplicate multiple > >>> items directly from the search result list > >>> * Better invoice printing setup: Choose the default invoice report > >>> for > >>> printing in the preferences > >>> * Change the ordering of invoice entries by up/down buttons in the > >>> invoice window > >>> > >>> * and last but not least Geert has ongoing work to include Credit > >>> Notes > >>> > >>> I propose to start a new 2.5.0 / 2.6.0 release series in order to > >>> make > >>> those "small business user" improvements available in a stable > >>> release. > >>> As already discussed in length, there haven't been that much > >>> significant changes in gnucash apart from these features which might > >>> seem minor to all users who don't happen to use gnucash for running > >>> a > >>> business. On the upside, this means trunk in itself isn't that much > >>> unstable right now, which means we will probably get a 2.6.0 stable > >>> release ready with only very few unstable 2.5.x releases on the way. > >>> Because of this, the extra work to get trunk into shape for another > >>> stable branch is probably only a small distraction from longer- term > >>> work that will continue on trunk. > >>> > >>>> I doubt that either Gtk3 or the engine cleanup will be done in > >>>> another > >>>> year unless a lot of help shows up. Going through a development > >>>> release series while continuing that work in trunk will push both > >>>> further out: Time spent getting a release polished up is time not > >>>> spent on longer-term projects. > >>>> > >>>> By the way, the time between 2.2.0 and 2.4.0 was 42 months (July > >>>> 2007 > >>>> to > >>>> December 2010); it was 22 months between releasing 2.2.0 and the > >>>> first > >>>> 2.3 release (May 2009). What's special about a year? > >>> > >>> Point taken. My proposal is not based on particular time frames, but > >>> rather on making this collection of small business improvements > >>> available in a stable release, and do so in the near future (i.e. > >>> within the next 2-4 months). > >>> > >>> Other proposals / comments? > >> > >> Thank you. That's much better; perhaps we can turn it into a wiki page > >> to point testers at. > >> > >> Are there unit tests for all of those features? > > > > Most of what I've worked at are GUI related items. I don't think we have > > unit tests for any of the GUI's. > > I will check to add some unit tests for the small changes I did in the > > engine though. > > > >> I'll spend some more time chasing down edits that aren't immediately > >> committed, so that the SQL backend is sure to work properly (and also > >> add automated tests for that to setters). > >> > >> Is it feasible to remove Guile 1.6 support (by fixing the deprecation > >> warnings with Guile 1.8)? Will that be sufficient to make Guile 2.0 > >> work? (I'm willing to do the work.) > > > > I have been investigating this problem before. Here are my findings so > > far: > > > > GnuCash itself is no longer using any deprecated Guile routines. The > > deprecated warnings come from the autogenerated swig code. > > There are a number of related bugreports to give you some more > > information: Gnome's bugzilla (GnuCash): > > https://bugzilla.gnome.org/show_bug.cgi?id=655901 > > Fedora has two related bugs, the latter being the most relevant one: > > https://bugzilla.redhat.com/show_bug.cgi?id=752054 > > https://bugzilla.redhat.com/show_bug.cgi?id=704527 > > All these bugs eventually refer to a swig upstream bug: > > http://sourceforge.net/tracker/?func=detail&aid=1511038&group_id=1645&at > > id=301645 > > > > I left a comment there early November, but there's no response so far. > > > > If this has to be worked around from within GnuCash, the only option I > > see is to %include something similar to our old guile-mappings.h in > > every swig interface file we have to redefine the deprecated symbols > > into a valid equivalent. > > > > This could replace (amongst others) SCM_STRING_CHARS with > > scm_to_locale_string. The issue I see here is that the result of > > scm_to_locale_string should be freed, while the result of > > SCM_STRING_CHARS should be, but we can't easily add a freeing call in > > the autogenerated code (at least not that I know of). So we could > > eliminate the deprecated routines, but introduce a lot of memory leaks > > instead. > > > > I'm not sure that could be an acceptable solution. > > Geert, > > Did you intend for this to go off-list?
Oops, no. Even after all these years, I sometimes hit the wrong reply button. > > Testing: GUI testing is hard, and at present we have no facility for it -- > nor does Gtk+, really. I worked on a system for wxWidgets a few years ago > with a chap who'd done his doctoral dissertation on the problem. It might > be possible to work something similar up using GObject-Introspection, but > that's not something that's going to happen anytime soon, so don't worry > about that part. > Ok. > But pretty much anything you do in the GUI has at least two components, a > "view" (not easily testable) and a "controller" (quite testable); it might > also have a "model" component which is also testable. A lot of the existing > Gnucash GUI code doesn't do a very good job of separating the parts, but I > know you wouldn't make that mistake. > I try not to, at least... > Swig/Guile: It looks to me like we have a much broader problem: Swig's Guile > support is not maintained. For the short term we can try applying the patch > from the Swig bug report and see if that gets us Guile 2.0 support, but in > the longer run it looks like we need to either switch back to GWrap or > replace Guile with something that's better supported. > Yes, this is a bad problem. > As for the string problem, we may have to modify the C-side functions to > require gstrdup'd strings that the consumer function frees. I'll have to > have a look at how those strings are being used to suggest something more > concrete. > Ok, thanks. Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel