[Bokeep-devel] the bo-keep way and the way to be obtrusive

[Mark Jenkins]

As a follow-up up to the discussion on bug 32814
https://savannah.nongnu.org/bugs/?32814
and as some much needed bo-keep core dump from me:

I think I could try to summarize my version of "the bokeep way" as:
 * Don't be obtrusive
   - stay out of the user's way
   - don't interrupt their workflow with error dialogs
   - if necessary display errors non-obtrusively in places like labels
   - let the user do what they want, including browse away when things 
aren't perfect
 * Exception -- disabling a widget whoes use doesn't make sense at a 
given moment isn't obtrusive; it's effective communication
 * Save everything the user throws at you, even if it's garbage, and 
let them move on and fix it later

The separation of Bo-Keep's database from the underlying accounting 
program and the design of the Bo-Keep api enables this non-obtrusive, 
"user-trusting" philosophy without compromising the integrity of 
underlying books.

The most important responsibility for a plugin is to raise 
BoKeepTransactionNotMappableToFinancialTransaction when 
get_financial_transactions() is called if it's unhappy with the state of 
a Bo-Keep transaction and doesn't consider it worthy of the accounting 
backend. Backend plugins pay attention to this, they remember dirty 
bo-keep transactions that fail to successfully provide good offerings 
via get_financial_transactions(), and they keep trying to call 
get_financial_transactions() everytime there is a backend flush until 
things have been righted by the user.

I'm not into idiot proofing. As a /user/ I can't stand it, and as a 
developer who has to eat his own dog food, I'm not going to impose it on 
myself.

Good news is that the bo-keep api allows me to have my dogfood and 
others to choose to live in their bird cages as needed.

The way to keep everyone happy isn't to give plugins the power to decide 
if things should be obtrusive or not (e.g. barking orders at the shell 
such as "don't leave me, I'm not right!" ) . The 
BoKeepTransactionNotMappableToFinancialTransaction raised by 
get_financial_transactions() can be dealt with non-obtrusively as my 
current shell does, or obtrusively if a different shell (or shell 
configuration) so wishes.

Long term I could imagine many different bo-keep shells emerging and 
folks choosing what suites their taste. But, seeing how the shell is 
responsible for the GUI side of the plugin API we do need to be careful 
-- we want all shells to be able to run all plugins, so we have to keep 
them all to the same API.

Fragmentation can be dangerous.

For now, I think the following tasks (to be posted  would suffice for 
our needs:

 * http://savannah.nongnu.org/task/index.php?11090
   We develop the ultimate idiot proof shell where you don't have the 
power to configure bo-keep, configure plugins, change books, change 
transaction type, navigate between transactions, and explicitly create 
or delete them. This one will operate plugins in a stand-alone mode 
where you are only responsible for one transaction of a particular type 
at a time. When you reach and signal some kind of "done point", your 
relationship with the transaction is "done" and you're then working on 
another new transaction of the specified type.

  I envision this being most useful for folks using the "end of night 
cashout" example configuration that will be developed for the 
multi-page-glade plugin and the eventual port of the ParIT Cash Register 
(http://parit.ca/products/parit-cash-register) to being a Bo-Keep plugin.

  And I imagine some variations for this -- at the "done" point we can 
either close the window and have the new transaction start once the 
shell is re-launched (cashout case) or keep the same window and continue 
operating on the same transaction there.

  Further -- an idiot-proof stand-alone shell can be configured to be 
obtrusive on close or at the "done" point if it makes sense (cashout 
case) -- perhaps by checking get_financial_transactions() and saying "we 
don't have something book worthy yet, are you sure you want to leave me?"



* http://savannah.nongnu.org/task/index.php?11091
  You can manually look for bo-keep transactions in the current shell 
that have not had a successful call to get_financial_transactions() 
after a backend flush, but it would be good if there was a way to find 
this specifically. Broadly speaking, it would be nice if this was done 
as the beginings of a bo-keep shell search infrastructure.

* http://savannah.nongnu.org/task/index.php?11092
  The current bo-keep shell could have an optional obtrusive mode (my 
kryptonite!) where it refuses to let you browse away from a transaction 
with get_financial_transactions() not being happy. We'd still allow 
closing the entire window and walking away (after an annoying prompt) of 
course.


Mark