On Wed, Jul 20, 2005 at 10:16:32PM +0100, Neil Williams wrote:
> On Wednesday 20 July 2005 9:28 pm, Chris Shoemaker wrote:
> > So you're saying that somehow, I don't have to search through 10
> > Splits
>
> Correct. When checking if the book is dirty, the object types are checked -
> one type
On Wednesday 20 July 2005 9:46 pm, Chris Shoemaker wrote:
> ISTM you have the two extreme cases: XML only needs to track dirtiness
> at the file (book?) level
But the book looks to it's collections to determine if it is dirty.
> , since it has to rewrite everything anyway.
That only considers t
On Wednesday 20 July 2005 8:51 pm, you wrote:
> On Wed, 2005-07-20 at 20:19 +0100, Neil Williams wrote:
> > ?? All core structs contain a QofInstance which itself contains a
> > QofEntity.
>
> Did QoF get extended to commodities and prices?
Not yet, but I do have ideas on how to do it and the CLI
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
> On Wed, Jul 20, 2005 at 04:09:38PM -0400, Derek Atkins wrote:
> > Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
> >
> > > On Wed, Jul 20, 2005 at 03:49:03PM -0400, David Hampton wrote:
> > > > On Wed, 2005-07-20 at 15:03 -0400, Chris Shoemaker wrote:
On Wednesday 20 July 2005 9:28 pm, Chris Shoemaker wrote:
> So you're saying that somehow, I don't have to search through 10
> Splits
Correct. When checking if the book is dirty, the object types are checked -
one type at a time. There are less than two dozen object types in GnuCash.
The cal
On Wed, Jul 20, 2005 at 04:09:38PM -0400, Derek Atkins wrote:
> Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
>
> > On Wed, Jul 20, 2005 at 03:49:03PM -0400, David Hampton wrote:
> > > On Wed, 2005-07-20 at 15:03 -0400, Chris Shoemaker wrote:
> > >
> > > > Incidentally, is this behavior specific t
On Wednesday 20 July 2005 9:20 pm, Derek Atkins wrote:
> I was just saying that right now we have a "mark_dirty()" static inline
> function in every object file that effectively does the same thing. We
> should abstract that out into qofinstance and have a
> "qof_instance_mark_dirty" API that lets
On Wed, Jul 20, 2005 at 04:20:15PM -0400, Derek Atkins wrote:
> Quoting Neil Williams <[EMAIL PROTECTED]>:
>
> > > I think this was what Derek meant when he
> > > was talking about supporting a different event for editing an account
> > > than for adding a transaction. One would dirty the Accoun
Quoting Neil Williams <[EMAIL PROTECTED]>:
> On Wednesday 20 July 2005 9:22 pm, Derek Atkins wrote:
> >
> > Huh? Why is CashUtil depending upon the QOF build-tree? Shouldn't it
> only
> > depend on what gets installed during "make install"?
>
> See other message regarding noinst_HEADERS. Yes, C
On Wednesday 20 July 2005 9:22 pm, Derek Atkins wrote:
>
> Huh? Why is CashUtil depending upon the QOF build-tree? Shouldn't it only
> depend on what gets installed during "make install"?
See other message regarding noinst_HEADERS. Yes, CashUtil, PilotQOF and all
the others will only depend on
On Wed, Jul 20, 2005 at 09:05:21PM +0100, Neil Williams wrote:
> On Wednesday 20 July 2005 8:35 pm, Chris Shoemaker wrote:
> > > With a backend that only stored dirty instances (e.g. by using a local
> > > cache - SQL), then marking the Trans, Account and Group as dirty is
> > > counter-productive.
On Wednesday 20 July 2005 9:02 pm, you wrote:
> > Ahh, I thought EXTRA_DIST controlled what went into the tarball.
Oops.
> > Removing any header files from this will cause 'make distcheck' to fail,
> > not that that would be anything new.
>
> Correct, all source files (including headers) must be
Quoting Neil Williams <[EMAIL PROTECTED]>:
> > I think this was what Derek meant when he
> > was talking about supporting a different event for editing an account
> > than for adding a transaction. One would dirty the Account, the other
> > would only indicate that the Account contained a dirty
On Wed, Jul 20, 2005 at 04:07:24PM -0400, David Hampton wrote:
> On Wed, 2005-07-20 at 15:35 -0400, Chris Shoemaker wrote:
> > On Wed, Jul 20, 2005 at 08:19:40PM +0100, Neil Williams wrote:
> > > On Wednesday 20 July 2005 7:53 pm, Chris Shoemaker wrote:
> > >
> > > Why such a tortuous path? Split
On Wednesday 20 July 2005 8:52 pm, you wrote:
> On Wed, 2005-07-20 at 20:03 +0100, Neil Williams wrote:
> > (As part of the CLI, I'll be reviewing the private headers exported by
> > QOF soon and qofinstance-p.h will be removed from EXTRA_DIST which should
> > prevent such shortcuts in the future.
Quoting Neil Williams <[EMAIL PROTECTED]>:
> On Wednesday 20 July 2005 8:52 pm, you wrote:
> > On Wed, 2005-07-20 at 20:03 +0100, Neil Williams wrote:
> > > (As part of the CLI, I'll be reviewing the private headers exported by
> > > QOF soon and qofinstance-p.h will be removed from EXTRA_DIST whi
On Wednesday 20 July 2005 8:35 pm, Chris Shoemaker wrote:
> > With a backend that only stored dirty instances (e.g. by using a local
> > cache - SQL), then marking the Trans, Account and Group as dirty is
> > counter-productive. Those haven't changed, only the Split has changed -
> > it could make
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
> On Wed, Jul 20, 2005 at 03:49:03PM -0400, David Hampton wrote:
> > On Wed, 2005-07-20 at 15:03 -0400, Chris Shoemaker wrote:
> >
> > > Incidentally, is this behavior specific to g2? I've never noticed it
> > > in 1.x, but I imagine the register code
On Wed, 2005-07-20 at 15:35 -0400, Chris Shoemaker wrote:
> On Wed, Jul 20, 2005 at 08:19:40PM +0100, Neil Williams wrote:
> > On Wednesday 20 July 2005 7:53 pm, Chris Shoemaker wrote:
> >
> > Why such a tortuous path? Split -> Collection -> Book. Checking the book
> > automatically checks all co
Quoting David Hampton <[EMAIL PROTECTED]>:
> On Wed, 2005-07-20 at 20:03 +0100, Neil Williams wrote:
>
> > (As part of the CLI, I'll be reviewing the private headers exported by QOF
>
> > soon and qofinstance-p.h will be removed from EXTRA_DIST which should
> prevent
> > such shortcuts in the f
On Wed, Jul 20, 2005 at 03:49:03PM -0400, David Hampton wrote:
> On Wed, 2005-07-20 at 15:03 -0400, Chris Shoemaker wrote:
>
> > Incidentally, is this behavior specific to g2? I've never noticed it
> > in 1.x, but I imagine the register code hasn't changed much.
>
> It was added in HEAD and pull
On Wed, 2005-07-20 at 20:03 +0100, Neil Williams wrote:
> (As part of the CLI, I'll be reviewing the private headers exported by QOF
> soon and qofinstance-p.h will be removed from EXTRA_DIST which should prevent
> such shortcuts in the future. qofid-p.h will also be removed.)
Ahh, I thought EX
On Wed, 2005-07-20 at 15:03 -0400, Chris Shoemaker wrote:
> Incidentally, is this behavior specific to g2? I've never noticed it
> in 1.x, but I imagine the register code hasn't changed much.
It was added in HEAD and pulled into g2. Derek thinks the blank split
code should be rewritten. I'm fo
On Wed, Jul 20, 2005 at 03:46:49PM -0400, David Hampton wrote:
> On Wed, 2005-07-20 at 15:16 -0400, Chris Shoemaker wrote:
>
> > We're already basically lying to the user about what he's done to his
> > data,
>
> Other that the bug that opening a register marks the book as changed, do
> you have
On Wed, 2005-07-20 at 20:19 +0100, Neil Williams wrote:
> ?? All core structs contain a QofInstance which itself contains a QofEntity.
Did QoF get extended to commodities and prices?
David
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
http
On Wed, 2005-07-20 at 15:16 -0400, Chris Shoemaker wrote:
> We're already basically lying to the user about what he's done to his
> data,
Other that the bug that opening a register marks the book as changed, do
you have other examples?
David
___
gnuc
On Wed, Jul 20, 2005 at 08:19:40PM +0100, Neil Williams wrote:
> On Wednesday 20 July 2005 7:53 pm, Chris Shoemaker wrote:
> > That reminds me of a question I've had. ISTM, there's some vision of
> > "dirtiness" propagating from Instance to Collection.
>
> There is now, yes.
>
> > However, I thi
On Wed, Jul 20, 2005 at 10:52:41AM -0400, David Hampton wrote:
> On Wed, 2005-07-20 at 14:42 +0100, Neil Williams wrote:
> > On Tuesday 19 July 2005 9:04 pm, David Hampton wrote:
> > > + /*
> > > + * *** THIS DIALOG IS NOT HIG COMPLIANT. ***
> > > + *
> > > + * According to the HIG, the seco
On Wednesday 20 July 2005 7:53 pm, Chris Shoemaker wrote:
> That reminds me of a question I've had. ISTM, there's some vision of
> "dirtiness" propagating from Instance to Collection.
There is now, yes.
> However, I think
> it would make sense if dirtiness propagated up the containment
> hierar
On Wed, Jul 20, 2005 at 10:59:20AM -0400, Derek Atkins wrote:
> Neil Williams <[EMAIL PROTECTED]> writes:
>
> > On Tuesday 19 July 2005 9:04 pm, David Hampton wrote:
> >> + /*
> >> + * *** THIS DIALOG IS NOT HIG COMPLIANT. ***
> >> + *
> >> + * According to the HIG, the secondary context sh
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 a
On Wednesday 20 July 2005 7:53 pm, Neil Williams wrote:
> When a collection is marked clean, does THAT have to iterate down to every
> instance?
Ignore that, I'll make it so that if the collection is clean,
qof_instance_is_dirty returns (and sets) FALSE.
...
if(qof_collection_is_dirty(coll)) {
On Wednesday 20 July 2005 7:28 pm, Neil Williams wrote:
> OK, all I need now is the time to replace every obj->inst.dirty = TRUE with
> qof_instance_set_dirty((QofInstance*)obj)
>
> :-(
>
> void qof_instance_set_dirty(QofInstance* inst)
> {
> QofBook *book;
> QofCollection *coll;
>
On Wednesday 20 July 2005 6:10 pm, Derek Atkins wrote:
> We really should have
> a single interface that we can call to mark an object/instance as
> dirty.
OK, all I need now is the time to replace every obj->inst.dirty = TRUE with
qof_instance_set_dirty((QofInstance*)obj)
:-(
void qof_instance
On Wednesday 20 July 2005 3:52 pm, David Hampton wrote:
> O.K. I'm confused. I thought the point of switching to SQL was that the
> data was always written through to the database, so that if gnucash
> crashed at any point there would be no lost work.
The SQL backend has a cache capability - with
David Hampton <[EMAIL PROTECTED]> writes:
> O.K. I'm confused. I thought the point of switching to SQL was that the
> data was always written through to the database, so that if gnucash
> crashed at any point there would be no lost work.
You're not confused. That is the point of moving the SQL.
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.
h
Derek Atkins wrote:
<< munch>>
How many people really do leave GnuCash running in the background?
Lots! Don't make assumptions about how people use the app; you'll
always be wrong. Whenever you find yourself thinking "user's wont do
that" you'll undoubtedly get hit with tons of bug rep
> > How many people really do leave GnuCash running in the background?
>
> Lots!
Yeah. I do. :)
Dan W.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Neil Williams <[EMAIL PROTECTED]> writes:
> On Tuesday 19 July 2005 9:04 pm, David Hampton wrote:
>> + /*
>> + * *** THIS DIALOG IS NOT HIG COMPLIANT. ***
>> + *
>> + * According to the HIG, the secondary context should include
>> + * context about the number of changes that will be lost
On Wed, 2005-07-20 at 14:42 +0100, Neil Williams wrote:
> On Tuesday 19 July 2005 9:04 pm, David Hampton wrote:
> > + /*
> > + * *** THIS DIALOG IS NOT HIG COMPLIANT. ***
> > + *
> > + * According to the HIG, the secondary context should include
> > + * context about the number of changes
On Tuesday 19 July 2005 9:04 pm, David Hampton wrote:
> + /*
> + * *** THIS DIALOG IS NOT HIG COMPLIANT. ***
> + *
> + * According to the HIG, the secondary context should include
> + * context about the number of changes that will be lost (either in
> + * time or a count). While it is
42 matches
Mail list logo
