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 <[EMAIL PROTECTED]> | Blessed Be!
@ http://jimdres.home.mindspring.com | Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
