scheduled transactions

[Aaron Peromsik]

Hi Josh,

A few notes on your email of last weekend.

Josh Sled <jsled@asynchronous.org> writes:
JS> On Sun, Jul 01, 2001 at 03:03:53AM -0400, Aaron Peromsik wrote:
JS> 
JS> For the Editor, I'm thinking that each area of the window is basically
JS> mutually-exclusive WRT editing.  You edit the options, then you edit the
JS> frequency, then you edit the template transaction.  You don't need to see
JS> and sub-section to correctly interpret/edit the other two... so, we can
JS> save a bunch of screen real-estate by making each sub-section ["options",
JS> "Frequency", "template transactions"] a page in a notebook...
JS> 
JS> As GTK/glade lends itself well to making a change like this, I might do
JS> this soon, unless I get a lot of bad feedback to the idea.

I don't particularly like this idea. It means adding extra clicks to
the process. I don't have a problem with the existing layout of the
editing dialog. Though I did like it better when you kept the calendar
in even for the frequencies that didn't really need it.

JS> The reminders section is moved out to a new dialog, containing a list
JS> of the upcoming-for-creation SX reminders.  The user has the option to
JS> select which of these she would like to create immediately [before it's
JS> officially come-due]... these are then moved into the auto/to-created
JS> [as appropriate] list of the since-last-run dialog.
JS> 
JS> The since-last-run dialog contains two GLs: one for the auto-created
JS> transactions and one for to-be-created transactions.  The to-create GL
JS> shares some horizontal space with the GtkTable which is allowing the user
JS> to input variable bindings, and thus get the template transaction created
JS> according to their desires...
JS> 
JS> Once all transactions are "valid", the dialog can be dismissed, and the
JS> books are now up-to-date.

This part sounds good. I agree that in this context just seeing
editable registers is more useful than a simple list of transactions.

JS> If this is what the user wants [via selecting the "create N days in
JS> advance" option for the SX], then so be it: they've acknowledged and asked
JS> for inconsistency.  But we shouldn't force transactions to be created in
JS> the books w/o the user's direct intervention.
JS> 
JS> OTOH, the register _should_ contain a forward-looking window of scheduled
JS> transactions, as you say; when viewing the ledger for an account it's
JS> helpful to see upcoming transactions in there.


JS> Then, there's the issue of informing the user that they have this function
JS> library available to them when creating a template transaction, but that's
JS> at some level just a user-reading-the-docs/tip-of-the-day issue.

For starters. But eventually it would be neat to have some kind of
help system plugged into the template creation UI. For example when
entering formulas in Quattro Pro or similar spreadsheets a message
shows in the status area reminding you of the required arguments for
the function you're entering, and the list of available functions is a
function-key away.

JS> Well, check src/doc/TODO-schedxactions ... it is intended to be a complete
JS> list of TODO-functionality.  So if you don't see stuff on there that you
JS> want [or see stuff spec'd incompletely/incorrectly], raise an alarm.

I have been watching that file... it generally has things which could
be interpreted as what I want but could also be interpreted
differently. But I hadn't actually read the list from last weekend
yet... doing so now, it looks like you've now covered most of the
stuff we've been discussing, in plain English even. :)

Have fun,

-- Aaron