[Gnucash-changes] Spruce up the delete window dialog to make it more HIG compliant.

[Chris Shoemaker]

On Wed, Jul 20, 2005 at 12:36:33PM -0400, David Hampton wrote:
> On Wed, 2005-07-20 at 14:42 +0100, Neil Williams wrote:
> > The HIG only specifies:
> > "The secondary text provides the user with some context about the number of 
> > changes that might be unsaved."
> 
> BTW, The HIG also suggests adding a '*' to the window title if there are
> unsaved change in the file.
> 
> http://developer.gnome.org/projects/gup/hig/2.0/windows-
> primary.html#primary-window-titles
> 
> Perhaps change notifications should be propagated to a central location.
> That way the code can test a single flag instead of scanning all the
> objects clases whenever you want to determine if the data file is clean
> or dirty.  Makes the test before presenting the save dialog trivial.
> Sadly it probably wouldn't allow counting of the number of changes, as
> one new transaction would likely generate three or more notifications
> (one for the transaction itself and one for each split.)

That reminds me of a question I've had.  ISTM, there's some vision of
"dirtiness" propagating from Instance to Collection.  However, I think
it would make sense if dirtiness propagated up the containment
hierarchy.  E.g. User dirties a Split, which dirties the split's
Transaction, and Account, which dirties the account's Group, which
dirties the Book.  Now, a check for the need to save can just check
the book.  And, the code that commits changes and clears the dirty
flag could also travserse the tree instead of committing whole
Collections, or searching in a Collection for the single split that was
dirtied.

Incidentally, why does Split not even have a dirty flag?  What design
decision governs whether a core engine object should derive from
Instance or Entity?

-chris

> 
> David
> 
> 
> _______________________________________________
> gnucash-patches mailing list
> gnucash-patches at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-patches