From: Benny M. <ben...@gm...> - 2012-10-23 07:34:10
|
2012/10/22 Jérôme <rom...@ya...> > Hi, > > > I propose a simple patch[1] (not a revolution or the patch of the year!) > for setting 'False' by default on 'use-last-view' option (preferences). > > It should only limit this problem for new users (3.4.x). > I think this could be included for 3.4.2? > Ok, put it in. Benny > > Note, is it not possible to have something else than empty values on: > register('preferences.last-**view', '') > register('preferences.last-**views', []) > > > [1] http://www.gramps-project.org/**bugs/view.php?id=6142<http://www.gramps-project.org/bugs/view.php?id=6142> > > > Jérôme > > Le 08/10/2012 18:16, Benny Malengier a écrit : > >> 2012/10/8 John Ralls <jr...@ce...> >> >> >>> On Oct 8, 2012, at 8:02 AM, Benny Malengier <ben...@gm...> >>> wrote: >>> >>> >>> >>> 2012/10/8 John Ralls <jr...@ce...> >>> >>> >>>> On Oct 8, 2012, at 6:48 AM, Benny Malengier <ben...@gm...> >>>> wrote: >>>> >>>> >>>> >>>> 2012/10/7 Paul Franklin <pf....@gm...> >>>> >>>> I think automatically disabling "Remember last view" >>>>> whenever gramps is started with the database locked >>>>> is a wonderful idea, and should go into 3.4.2 as I have >>>>> seen dozens of users on the bug tracker asking what >>>>> to do in this situation. They are typically beginners >>>>> (and as Jerome says typically after trying a buggy >>>>> third-party addon) and we should prevent it happening. >>>>> >>>>> >>>> It is not related to the family tree though. It would be interesting to >>>> add to the config setting a clean-exit option. On opening of gramps it >>>> can >>>> be set to False, only the closing of gramps in a normal way should write >>>> True to it. >>>> >>>> Then on restart, if clean-exit is False, load the default Person View. >>>> >>>> >>>> Yes, that would be helpful. >>>> >>>> It would also be helpful to have a top-level exception handler that >>>> displays (or writes to a file in $HOME ) the traceback and cleans up and >>>> closes the database so that the user doesn't have to break the lock when >>>> s/he restarts. It won't help with segfaults, but almost all of the crash >>>> bugs I see are from unhandled exceptions . >>>> >>>> >>> We have a top level exception handler. >>> >>> With bugs, we don't always now the state of the database though, so you >>> would have to close and restart behind the scenes I suppose to do what >>> you >>> would like. >>> >>> In my view, best is to fix the bugs, not to give the impression to the >>> user all is fine while it is not. >>> >>> >>> Is Gramps not using Db Transactions to roll back to a known state before >>> shutdown? >>> >>> >> Yes, but the user interface might be in another state, or unfinished due >> to >> a crash. After all, the crash is handled on a low level. >> I can only think of closing and reopening, which would clean up the user >> interface. >> >> Benny >> >> >>> Regards, >>> John Ralls >>> >>> >>> >> >> >> ------------------------------**------------------------------** >> ------------------ >> Don't let slow site performance ruin your business. Deploy New Relic APM >> Deploy New Relic app performance management and know exactly >> what is happening inside your Ruby, Python, PHP, Java, and .NET app >> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >> http://p.sf.net/sfu/newrelic-**dev2dev<http://p.sf.net/sfu/newrelic-dev2dev> >> >> >> >> ______________________________**_________________ >> Gramps-devel mailing list >> Gramps-devel@lists.**sourceforge.net <Gra...@li...> >> https://lists.sourceforge.net/**lists/listinfo/gramps-devel<https://lists.sourceforge.net/lists/listinfo/gramps-devel> >> >> > |