meeting log January 30, 2001

[James LewisMoss]

15:19:28 <grib>	meeting.
15:19:49 <grib>	let's talk about a 1.6 release cycle/schedule.
15:20:29 <grib>	how close is the new user stuff to being prime-time-prepped?
15:21:19 <grib>	how far away is the currency-in-transaction? 
15:21:25 <grib>	how close is price-db?
15:21:45 <rlb>	I think, if I don't keep getting distracted, I can get the pricedb infrastructure and online bits finished in less than two weeks, maybe one.
15:21:51 *	dres is thinking.
15:21:53 <grib>	what can we get going for user registration and how obtrusive/unobtrusive do we want to be?
15:22:10 <rlb>	I'm not as sure about the pricedb GUI bits, but I don't think that should be too hard.
15:22:13 <grib>	what about the QIF import changes that have been bandied about?
15:22:31 <dres>	new user stuff: two to three weeks.
15:22:41 <dres>	grib: merging you mean?
15:23:02 <dres>	grib: some of that is included in what I'm doing (not a whole lot though)
15:23:50 <grib>	dres: merging is one of them,  the other is completely new: payee-to-account mapping for transactions with no Quicken Category.
15:24:16 <grib>	dres: on the new user stuff.  When does it get run? 
15:24:27 <dres>	grib: currently on first run.
15:24:46 <grib>	which means what?
15:25:06 <dres>	if a var hasn't been set and you have no list of files visited it's run
15:25:23 <dres>	the var is set when you let it run or cancel it and say you don't want to see it again.
15:25:37 <dres>	I'm also planning on adding it as a menu option.
15:25:44 <dave_p>	i think the new hierarchy import should run whenever you hit File->New
15:25:46 <grib>	ok.
15:26:03 <dres>	dave_p: seems reasonable.  adding it there should be simple
15:26:29 <rlb>	dres: wrt new-user -- I think having the "first" tip of the day pop up and say something like "Welcome to XXXX.  <other pleasantries>.  (link Gnumatic) has been founded to provide (link support) and (link enhancements).  Please (link register) if you'd like to be kept informed of future enhancements and services.
15:26:32 <grib>	dave_p: what do you think about the currency-in-transaction?  For 1.6, or wait until 1.8/2.0?
15:26:34 <rlb>	s/dres/grib/
15:26:47 <rlb>	grib: might be appropriate...
15:26:50 <dres>	rlb: ah.  sorry different new user thing. :)
15:27:05 *	dave_p thinking
15:27:07 <rlb>	dres: no, I think grib was asking about both.
15:27:14 <rlb>	s/no/no problem/
15:27:45 <rlb>	grib: that tip of the day (or special dialog) wouldn't show up more than once...
15:28:03 <grib>	unless you invoked it manually? 
15:28:21 <rlb>	grib: actually I'd say the "other way" would just be an option on the help menu.
15:28:21 <grib>	But I think the register-with-gnumatic part should definitely be in the top-level Help topics index.
15:28:55 <grib>	ok.
15:29:10 <dave_p>	grib: how do you see the cur-in-tr stuff working wrt reports? i.e., when you do currency conversions, do you use the share quantity or the value?
15:29:28 <rlb>	grib: also, I think that the "initial gnumatic intro dialog" should mention how to get to the relevant info on the Help menu, or just that the info is available on the help meny.
15:29:33 <rlb>	s/meny/menu.
15:29:35 <rlb>	s/meny/menu./
15:29:42 <grib>	dave_p: that's more related to the reporting currency IMO.  
15:30:04 <grib>	I think most reports would use damount and damount-as-reporting 
15:30:40 <grib>	the transaction currency will mostly be invisible.  this is all just IMO.
15:31:06 <grib>	it will be unobtrusive esp if we limit the xtn currency to be one split currency.
15:32:09 <grib>	linas already has most of the framework in the engine, we just need to figure out when to pop up the "give me a value" dialog and make it.
15:32:33 <grib>	and how to show the xtn currency info in the register. 
15:32:51 <dave_p>	grib: if we're not going to use the 'value' amounts in reporting, or rarely show them, it kind of begs the question, why have them at all?
15:33:05 <grib>	dave_p: we need them to balance transactions.
15:33:19 <grib>	they will show up in the register.
15:33:45 <dave_p>	grib: ok, but in the accounting books i've read, the values used as 'balancing' are also used in reporting. we seem to be bastardizing them
15:33:46 <grib>	maybe that means we need to show them in reports too, but the 'damount' is IMO the "native" amount of the split.
15:34:35 <grib>	dave_p: we are off the map of normal accounting.  that's why it's been so hard to find accountants who can tell us what to do.
15:35:39 <grib>	I haven't seen anything that even begins to describe what to do about keeping track of multiple different types of currencies and assets with exchanges between them.
15:35:49 <dave_p>	grib: it seems strange that you could change the value amounts around and not have the reports change at all.
15:36:00 <grib>	But could you?
15:36:11 <dave_p>	grib: sure, if you don't use them in reports
15:36:41 <grib>	no, I mean how would the interaction work that you could change the value of one split but not the damount of any split?
15:37:04 <dave_p>	grib: you could change the values of two splits
15:37:05 <grib>	if the transaction is balanced both before and after, and there's only 1 exchange rate per commodity pair?
15:37:22 <grib>	and the bal;ancing currency is required to be 1 split currency?
15:38:31 <grib>	i guess part of this depends on what values you enter in the "please value split" dialog.  It could either be an exchange rate or a value.
15:39:17 <grib>	Or, I guess, both, where if you enter a value in the 'value' box it autoprecalcs the rate box.
15:40:33 <grib>	am I totally offbase? 
15:40:49 <rlb>	dave_p: when you and grib are done, I wanted to run a "backend bit" by you.
15:41:32 <dave_p>	not all transactions will be entered in the register, so i don't think we can depend on register stuff for checking
15:41:50 <grib>	right. 
15:42:16 <grib>	but we can't count on that now, either.
15:42:20 <dave_p>	3 splits, one has damount == value == 0 in transaction currency. the other two can have any value +-X and it's in balance.
15:42:36 <dave_p>	if you change X, will any report change?
15:42:51 <grib>	yes.  here's why:
15:43:31 <grib>	- if both X and Y have accounts with same commodity, value == damount so reports will change
15:44:06 <grib>	- if X and Y accounts differ in commodity, either X or Y will have balancing commodity as their account commodity, so one will change.
15:44:39 <grib>	I guess if neither X nor Y accounts have balancing commodity as account commodity nothing will change in reports.
15:45:00 <grib>	But that wouldn't be enterable from the register, and could be edited from the register. 
15:45:09 <grib>	s/edited/corrected
15:45:32 <dave_p>	grib: why couldn't you enter that from the register?
15:45:47 <grib>	wouldn't be allowed. 
15:46:02 <dave_p>	why?
15:46:06 <grib>	Balancing commodity should be a split commodity.
15:46:14 <grib>	IMO.
15:46:23 <grib>	I can't think of a transaction where it's not.
15:46:31 <dave_p>	i said the first split had that commodity (3 splits)
15:46:31 <grib>	(I mean a real financial transaction)
15:47:42 <grib>	oh.. ok.  I guess I just don't understand what the problem is.  We could write a report that showed value in the balancing commodity if it's important to you, but generally the amounts that matter are reporting value and account-delta size.
15:47:50 <grib>	Right?
15:49:59 <grib>	I mean, value-in-balancing is shown in the register, so it's not invisible, and for most real transactions balancing currency will be reporting currency.
15:50:50 <grib>	(value-in-balancing would be shown at least in general ledger mode, or open-splits mode; don't know about single/double line?)
15:51:35 <dave_p>	right, i'm just concerned that the 'value' fields seem to be becoming less relevant. most transactions have splits in all one currency and it's just redundant. the only place they have meaning is in transactions with multiple currencies. if they're just used for checking balance, they seem even less needed. i don't know, maybe this isn't that important
15:52:35 <grib>	how else would you balance an xtn involving multiple currencies?  
15:52:52 <grib>	that's a very important problem IMO.
15:53:23 <grib>	... and all stock transactions (buy/sell at least) involve multiple commodities.
15:54:31 <grib>	For the most part, value is as irrelevant now as it will be 
15:54:55 <dave_p>	grib: right, but shouldn't the value you assign to the stock somehow figure into your reports? in the cost-basis?
15:55:32 <grib>	actually I think the basis is more like the credit amount to your bank account; it includes commission.
16:04:35 <dave_p>	grib: well, i don't want to dwell on this much more. but my understanding is that the 'importance' of balancing transactions stems from the fact that is helps you maintain the accounting equation correctly as reflected in reports. now, maybe the constraints we put on cit will continue to make that the case. but I think it's important to make sure that is really the case, with well though out examples. If gnucash becomes really popular, this will 
16:06:37 <grib>	I sort of agree and sort of not (well sort of each with what I could see of your message)
16:07:17 <grib>	I think xtns need to be bal;anced both for accounting and for user-error-catching.  The big X on the transaction that's unbalanced tells me I made a typo or the QIF import code is broken or something.
16:09:49 <grib>	dave_p: maybe you should write your concerns up in more detail and send them to me or the list. 
16:10:03 <dave_p>	grib: ok, i'll do that
16:10:16 <grib>	IOW, maybe this is a 1.8/2.0 thing? 
16:10:23 <dave_p>	grib: btw, we aren't coding for gnome 2.0 :)
16:10:24 <grib>	Let's decide in the next week/2
16:10:33 <grib>	we aren't?
16:10:50 <dave_p>	grib: no, gnome 2.0 deprecates api that we are using
16:11:01 <grib>	ah.  I confused 1.4 with 2.0
16:11:03 <dave_p>	grib: also i think gnome 2.0 is a ways off
16:11:24 <grib>	not that far if you believe the people on the foundation list.
16:11:30 <rlb>	I was surprised to see glib/gtk docs for 2.X on www.gtk.org...
16:11:35 <grib>	looks like the 1.4 feature freeze is in a week,.
16:11:49 <grib>	and 2.0 feature freeze this summer
16:11:54 <dres>	except for nautilus which gets special dispensation :)
16:12:44 <grib>	I need to take off (take my wife a late lunch)
16:12:49 <grib>	anything else?
16:12:59 <dave_p>	rlb: you had something
16:13:07 ---	grib is now known as grib-away
16:13:14 <rlb>	dave_p: not sure we really need to talk about it...
16:13:37 <rlb>	dave_p: adding pricedb == changing file io stuff.
16:14:19 <rlb>	dave_p: And it looks like in the medium run, the right thing to do is to switch everything over to using Backend.  i.e. file io becomes a card-carrying member of the backend infrastructure.
16:14:48 <rlb>	but for now, I'm not going to do that.  After talking to Linas, he's got to fix that up some more, so I'm just going to continue to modify the fileio stuff separately for now.
16:15:01 <dave_p>	ok
16:15:27 <dave_p>	backend wouldn't really work for flat file, would it?
16:15:32 <rlb>	dave_p: as it stands right now, I've deleted FileIO.* -- we don't need them anymore, and fixed up the IO code to take a GNCBook* as an arg rather than returning an AccountGroup...
16:15:37 <rlb>	dave_p: it should.
16:15:43 <rlb>	(I think).
16:16:25 <rlb>	The idea is that the book deals with a Backend* always, and the Backend* callbacks have to be rich enough to handle both flat-file and DB.
16:16:45 <dave_p>	ok
16:16:47 <rlb>	In the flat-file case, it'll grab all the data and push it into the GNCBook* argument directly.
16:17:03 <rlb>	In the DB case, it'll do nothing (more or less) until the data's queried for, etc.
16:17:30 <rlb>	So for each backend, the various callbacks may do very different things with very different costs -- that's the theory at least...
16:18:12 <rlb>	I think we may also have a real error stack in the backend in a while, so gnc_backend_get_error will return successive values until empty.
16:19:14 <rlb>	Linas has nearly convinced me that error stacks and error retrieval/pop func == good (as long as you're guaranteed to have thread-specific variables if/when you ever need to work right in a threaded envt).
16:19:39 <rlb>	Anything else interesting up?
16:20:03 <dave_p>	nothing from me
16:20:20 *	dres wishes C had exceptions then we could do good error handling.
16:20:48 <rlb>	dres: true, though the stack approach gets you much of what you need.
16:20:55 <dres>	i don't like an error stack on principle, but i can see it being the best solution available.
16:21:17 <rlb>	dres: as long as you have the thread-specific vars available for later, it's OK, I think.
16:21:24 <rlb>	(as a general API).
16:22:04 <dres>	it's not functional.  it still requires you to return at least a true/false condition from all functions.
16:22:04 <rlb>	dres: also it's potentially the most efficient option.  opengl uses it for exactly that reason.  You can try to draw a million polygons in a tight loop and then ask if anything went wrong at the end.
16:22:18 <dres>	it separates the error from the occurence in unpredictable ways
16:22:25 <rlb>	dres: keeps argument signatures smaller for those tight loops.
16:23:04 <dres>	gl is very different than what we are doing :)
16:23:07 <rlb>	dres: true -- that's one of, if not the biggest drawbacks, though if/when that's important, you can always put in more "checks".  It's definitely not optimal, though.
16:23:59 <rlb>	dres: not when we get singing/dancing 3-D lava-lamp stock tickers.
16:24:23 <rlb>	dres: graphic performance will be critical then.
16:24:27 <rlb>	:>
16:24:35 <dres>	:)
16:26:20 <rlb>	so we done meetin?
16:26:26 *	dres thinks so.

-- 
@James LewisMoss <dres@debian.org>      |  Blessed Be!
@    http://jimdres.home.mindspring.com |  Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach