Since Last Run dialog concerns

Josh Sled jsled at
Mon Jun 18 21:49:42 EDT 2007

Tim Wunder <tim at> writes:
> It's not always a good thing to pile everything into a single view. Some 
> things need to be separated. Particularly reminders, or upcoming SXs, from 
> current SXs that require immediate action. 

I don't agree; I don't think it's piled ... in the regular case, I have maybe
one reminder and two to-create SXes ... so three things to see.  I guess it
could be 2 pages with 1 or 2 things each, but it seems like one "unit" of
interaction is better than two, here.  I'm not so sure about the need to
separate the reminders out from the others ...

> Additionally, it seemed 
> that /every/ SX was listed, regardless of its state, even those that were 
> neither reminders nor ready to be created. There is no reason that the SLR 
> should display SXs that are neither in a reminder state, nor in a to be 
> created state.

That's a good point ... they don't really deserve a line-item at all.  I've
noted this in <src/doc/sx.rst>.

> I have lots of SXs, yet I fail to see the usefulness of the expand/contract 
> widgets. It strikes me as clutter. Do you actually use that? I think the need 
> to expand and contract the SXs in the display would go away if there were an 
> ability to filter transactions.

No, I don't.

> Here's another thought I just had while looking at the SLR. Much of the 
> clutter I see are Reminder SXs with variables that are expanded by default in 
> the tree view. Would it be possible to only expand the variables if the SX is 
> in a to be created state and not a reminder? That would go a long way towards 
> de-cluttering the view, IMO.

Another really good idea, noted.

...jsled - a=jsled;; echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : 

More information about the gnucash-devel mailing list