Hi John, Am Freitag, 4. November 2011 schrieb John Ralls: > > Trac: http://svn.gnucash.org/trac/changeset/21517 > > > > Modified: > > gnucash/trunk/src/libqof/qof/qofsession-p.h > > gnucash/trunk/src/libqof/qof/qofsession.c > > gnucash/trunk/src/libqof/qof/qofsession.h > > > > Log: > > Add is_readonly attribute to QofSession class. > > Why do we need this? QofBook already has a read-only attribute which > prevents even editing instances, so there shouldn't ever be anything to > save in a read-only session.
I've seen the read-only attribute in QofBook. However, it is not sufficient. My goal is to implement a "read-only" operation mode of gnucash, so that our infamous "The database is locked" dialog offers the choice "Open read-only" (instead of or additionally to "Open anyway"). For this, the read-only attribute needs to be stored in the same place as the database URL. That one is stored in QofSession, so the fact it's a read-only URL needs to be stored in QofSession, too. Also, the fact that it's read-only needs to be stored already during qof_session_begin(), but at that time, no QofBook exists so far. The QofBook(s) won't be created before qof_session_load, but at that point the read-only attribute needs already be decided upon. So that's another reason for this addition. In my planned feature, if the QofSession is read-only == TRUE, all of the QofBook(s) inside that session will also have read-only == TRUE. > If there are leaks in QofBook's read-only > block, fix that. It's not a good plan to let the user do a bunch of edits > and then say "Oops, this session is read only, so you can't save your > work!" Both are needed, and both will have the same value - for this use case. There might be other use cases where the QofSession is read-write but (one of) its QofBook(s) is not. Best Regards, Christian _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
