2007-08-08 GnuCash IRC logs

00:06:34 *** BlackBsd has quit IRC
00:24:40 *** twunder has quit IRC
00:34:45 *** johnsdafsdfasdf has quit IRC
00:46:06 *** jakin has quit IRC
01:50:59 *** wizkid238 has joined #gnucash
01:57:40 *** wizkid239 has quit IRC
03:12:49 *** Jaran has quit IRC
03:12:49 *** sjc has joined #gnucash
04:07:44 *** kielein has joined #gnucash
04:38:05 *** Jaran|zZzZzZz has joined #gnucash
05:07:53 *** Pepe66 has joined #gnucash
05:44:29 *** sjc has quit IRC
05:44:46 *** cortilap has joined #gnucash
06:11:37 *** andi5 has joined #gnucash
06:11:37 *** gncbot sets mode: +o andi5
07:22:54 *** warlord-afk is now known as warlord
07:28:12 *** warlord has quit IRC
07:53:05 *** andi5 has quit IRC
07:53:32 *** pecisk has joined #gnucash
08:02:27 *** pdc has quit IRC
08:05:26 *** pdc has joined #gnucash
08:41:01 *** warlord has joined #gnucash
08:41:01 *** gncbot sets mode: +o warlord
09:09:53 *** twunder has joined #gnucash
09:36:16 *** kielein has quit IRC
10:09:59 *** twunder has quit IRC
10:16:55 *** Pepe66 has quit IRC
10:20:48 *** warlord has quit IRC
10:59:58 *** warlord has joined #gnucash
10:59:58 *** gncbot sets mode: +o warlord
11:04:18 *** Demitar has quit IRC
11:42:19 *** nomeata has joined #gnucash
12:32:34 *** warlord has quit IRC
12:59:22 *** kielein has joined #gnucash
13:03:54 *** benoitg has left #gnucash
13:47:22 *** cortilap has quit IRC
14:01:57 *** nomeata has quit IRC
14:05:02 *** warlord has joined #gnucash
14:05:02 *** gncbot sets mode: +o warlord
14:15:28 *** Knight_Lord has joined #gnucash
14:15:44 *** roxy_ has joined #gnucash
14:20:17 *** pdc has quit IRC
14:24:44 *** twunder has joined #gnucash
14:26:35 *** roxy_ has quit IRC
14:29:10 *** roxy_ has joined #gnucash
14:34:26 *** cyb3rj has joined #gnucash
14:35:45 <cyb3rj> Building Debian documentation to enable HBCI has the --enable-mt940 switch in it. As of 2.2.0 (maybe 2.1.x) this is no longer required.
14:35:54 <cyb3rj> http://wiki.gnucash.org/wiki/Debian
14:36:23 <cyb3rj> Just an FYI for some documentation/instructions maintenance.
14:38:44 <warlord> cyb3rj: feel free to fix it. it IS a wiki after all.
14:38:56 <warlord> (just be sure to make it clear that "this is not needed in 2.2.0")
14:39:14 <cyb3rj> I'll be a noob... the instructions say to make an MD5 passwd and "send it" ... err... send it where?
14:39:33 <warlord> Oh, wait.. It's NOT required.
14:39:39 <warlord> But some users may still want it.
14:39:45 <warlord> and the --enable option is still there.
14:40:13 <warlord> Wow, you ARE a n00b!
14:40:24 <cyb3rj> :^)
14:40:28 <warlord> (and you can't read, either, but that's okay)
14:41:56 <warlord> Regardless, there's no need to change the wiki.
14:42:30 <cyb3rj> ok. i'm going to rerun configure after it installs. I just want to verify my insanity, blindness, and illiteracy here.
14:43:01 *** roxy_ has quit IRC
14:43:17 <warlord> what insanity?
14:43:31 <cyb3rj> configure: error: --enable-mt940 is obsolete -- all functionality is already included in --enable-hbci
14:43:45 <cyb3rj> that's what set me off. it stops the configure script (or appears to)
14:44:24 <cyb3rj> configure --help ==>
14:44:25 <warlord> Oh. * slaps forehead *
14:44:31 <cyb3rj> --enable-mt940 Obsolete, included in --enable-hbci
14:44:35 <cyb3rj> :D
14:44:39 <warlord> Yes, you are right. I'm sorry.
14:44:46 <warlord> Anyways, on the wiki page, click "Edit"
14:44:51 <cyb3rj> did
14:45:04 <warlord> the follow the instructions.
14:45:07 <warlord> then
14:45:18 <cyb3rj> grr... ok... so can edit now. O_o
14:45:47 <cyb3rj> ne way... um... my documentation is better than my questions...??? ;)
14:46:09 <warlord> Heh.
14:50:09 <cyb3rj> Thanks for entertaining my insanity. Edits made.
14:50:48 <warlord> ok
14:51:36 *** cyb3rj has quit IRC
14:57:14 *** pdc has joined #gnucash
15:06:08 *** tyler has joined #gnucash
15:09:25 <tyler> why doesn't gnucash track intended transactions separately from actual transactions?
15:10:01 <chris> tyler: It does. It's called SX (scheduled transactions.)
15:10:25 <jsled> Heh. I was going to say "it just doesn't".
15:10:46 <chris> well, it's a matter of perspective, I s'pose. :)
15:11:12 <tyler> but when I set up a schedule to get paid every two weeks for the next 5 years, those transactions don't get recorded into the future
15:11:24 *** gunnicom_ has joined #gnucash
15:11:35 <jsled> yeah. But SXes can only create acutal future-dated transactions ... not "hypothetical" ones.
15:12:06 <tyler> I guess that's my question: why can't it track both?
15:12:06 <jsled> tyler: you can set the SX to create in advance. But, they're just created as actual transactions. There's no facility to un-create them if you then change the SX schedule or anything.
15:12:20 <jsled> It could. It just doesn't.
15:12:42 <tyler> was it by design or just "we haven't gotten that far yet"?
15:12:45 <jsled> It wasn't written that way, &c. I never really know how to answer questions of that form.
15:13:12 <jsled> Yes.
15:13:17 <tyler> would the main developers oppose such a request?
15:13:30 <chris> tyler: gnucash isn't really strong in hypothetical accounting.
15:13:50 *** benoitg has joined #gnucash
15:13:54 <jsled> I don't think anyone would oppose such a request, though it's a huge undertaking, &c.'
15:14:48 <tyler> isn't it just adding a 2nd timestamp to each transaction?
15:15:04 <jsled> I mean, it'd pretty much touch every piece of code.
15:15:07 <jsled> 2nd timestamp?
15:15:19 <tyler> every transaction has a timestamp now, right?
15:15:30 <tyler> to indicate when that transaction happened
15:15:31 <jsled> every transaction has two, I think. entry date and posted date.
15:15:51 <warlord> chris: HBCI is required for OFX Direct Connect.
15:16:20 <tyler> ok, so this would be a 3rd timestamp then
15:16:25 <chris> warlord: oh, I didn't know that.
15:16:38 <tyler> entry, intended, posted
15:17:24 <warlord> yeah, hbci really means "aqbanking". We should probably change the configure switch in trunk once we really branch 2.2
15:17:36 <warlord> jsled: and reconcile date
15:17:42 <jsled> why would intended be different from posted? I suppose that could be one way to do it. I'd be inclined to just add a 'hypothetical' bit or something...
15:18:15 <warlord> tyler: you'd be better served by getting the reports to take SXes into account in forward-looking reports.
15:18:19 <jsled> But that's the easy change. Adding it to the GUI and reporting subsystems is the bigger volume of work.
15:21:26 <tyler> well what's the reconcile date for?
15:21:45 <warlord> The date you reconcile the transaction.
15:22:16 <warlord> (actually, the date you reconcile that Split)
15:22:28 <warlord> -- it's a Split datum, not a Txn datum
15:22:32 <tyler> having a transaction be reconciled might relay the same information that i'm thinking of
15:22:57 <tyler> ok, done at split level, makes sense
15:23:36 <warlord> well, you can get your statements at different times so you may reconcile different sides of a transaction at different times.. hense different reconcile dates.
15:23:58 <tyler> yes
15:25:03 <tyler> so a reconciled event is what i'm calling an "actual" event
15:25:26 <tyler> if it's not reconciled, it's an "intended" or hypothetical event
15:26:09 <tyler> in that sense, that information is already recorded in the transaction
15:26:14 <warlord> No, a reconciled event is when you reconcile gnucash against a printed, periodic statement.
15:26:52 <warlord> There's also "cleared", which is probably closer to what you mean.. Cleared is when a transaction actually hits the account (e.g. you go online and notice that the transaction happened).
15:26:57 <warlord> But I dont think there's a cleared_date.
15:27:48 <tyler> But until you reconcile against that statement, you can't really declare the transaction occured
15:28:20 <warlord> sure you can.
15:28:42 <tyler> how?
15:28:55 <warlord> I can go to my bank or CC website and see all the transactions that have cleared.
15:29:13 <tyler> and that's a form of reconciliation
15:29:42 <warlord> I suppose at some level, technically, but really, reconciliation is a process based off your periodic statements.
15:30:07 <warlord> there are many ways to determine that a transaction "cleared" the account.
15:32:39 <tyler> i mean, whether you do it off of a website every day, or off a piece of paper every month,
15:32:45 <tyler> or both if you're paranoid,
15:33:29 <tyler> it's still a process you go through to convince yourself that the event took place at the time you intended it to
15:34:42 *** sjc has joined #gnucash
15:35:33 <tyler> and i think that's very different from "clearing" a transaction
15:37:42 <tyler> but that's a different topic
15:38:13 <tyler> so when i went through the transaction scheduler in gnucash,
15:38:37 <tyler> i was expecting something like my PDA's calendar scheduler
15:39:32 <tyler> I enter a start & end time, followed by a recurrance formula, and hit OK
15:40:05 <jsled> Did you use the "Schedule..." action from a register, or the "SX List" from the "Action" menu?
15:40:16 <jsled> Also, what version of gnucash are you using?
15:41:05 <tyler> v2.0.5
15:41:37 <tyler> and i went through the Action menu
15:42:09 <tyler> so i see the same recurrence fomula GUI here as i do my PDA calendar, that's fine
15:43:00 <tyler> but after I apply it, i was expecting to see those transactions get recorded
15:43:42 <jsled> That's not how it works. AT that point, you're just setting up the schedule. You need to use the "since-last-run" dialog to create transactions.
15:44:15 <tyler> "There are no transactions to be entered at this time"
15:44:31 <jsled> Again, if you want them to be created in advance, you need to adjust that item on the individual SX ... one of the spin buttons in the editor.
15:44:39 <jsled> "Create N days in advance" I think it says.
15:46:01 <tyler> right, except I came into this GUI expecting something like my PDA calendar system, which doesn't ask me for that
15:46:08 <jsled> http://bugzilla.gnome.org/show_bug.cgi?id=460989 was filed recently, though.
15:46:30 <jsled> Okay.
15:47:21 *** kielein has quit IRC
15:48:38 <jsled> I think most people don't expect future transactions to be created.
15:49:06 * tyler scratches his head
15:49:20 <warlord> I dont what the transaction to be created until the transaction actually happens..
15:49:52 <tyler> i don't see why not, it's a great tool to figure out what life will be like down the road
15:50:02 <jsled> right. I'll allow mine a few days into the future if I'm scheduling the payment via BofA check-paying webapp.
15:50:15 <jsled> tyler: except the transactions that would be created can't easily be removed.
15:50:16 <warlord> tyler: that's what budgeting is for.. Or, as I said earlier, getting future-looking reports to understand SXes
15:51:25 <tyler> jsled: and that gets to my next question....why does gnucash lose track of where a transaction came from or why it was entered, making it hard to undo when i change a schedule?
15:51:32 <jsled> Though if they were removed if the {requested by the user, the schedule changed, &c.}, it'd be a lot more interesting.
15:51:55 <jsled> It doesn't. But the code to look for that field and Do The Right Thing just doesn't exist.
15:52:26 <jsled> At the same time, I think SXes are the only thing that "tags" the transactions it creates. Import might, too.
15:53:07 <jsled> That mechanism is a bit ad-hoc; it uses an arbitrary-storage facility on Transactions, rather than being a first-order part of the data model.
15:53:36 <tyler> is there any plan to move that into the data model?
15:53:50 <jsled> There's no real "plans" at all.
15:54:44 <jsled> It's actually fine in the KVP frames (that arbitrary-storage facility) ... as much as I dislike them. :)
15:55:26 <jsled> Though we do have enough things (> 3) that create transactions that we could probably create such a facility without mucking it up too bad.
15:55:51 <jsled> We need a sufficiently-motivating feature to do it. I'm not sure what that would be.
15:56:13 <jsled> Perhaps if we had the "batch transaction processing" stuff, it'd be good to be able to query/search for transaction by creation-source.
15:58:05 <tyler> well, i've actually been thinking about accounting prog design for quite a while now
15:58:25 <tyler> and just want to throw some ideas out here to see if i'm going too far
15:59:26 <tyler> and what started my on this path was i wanted to "try" different plans and see what my accounts would look like 2 or 3 years down the road as a result
16:00:40 <tyler> but since gnu cash assumes a recorded transaction == real transactions, that prevented me right now
16:00:49 <tyler> er...prevented me right there
16:02:05 <tyler> of course, this all gets into reports & budgets, and from what i've read from the wiki it looks like that topic is a hairy one
16:03:16 <warlord> jsled: business features tag their transactions.
16:03:26 <jsled> Awesome.
16:03:39 <warlord> Although probably "differently"
16:03:46 <jsled> Oh, I'm sure.
16:03:53 <jsled> More extensively, too, I'd imagine.
16:03:56 <tyler> is it the transaction itself that gets tagged? or the split datum?
16:05:14 <jsled> SXes tag the Transaction.
16:05:22 <warlord> Depends.. invoice transactions get tagged in the transaction, but splits get put into lots and lots also get tied to invoices or customers.
16:06:06 <jsled> (<http://svn.gnucash.org/trac/browser/gnucash/trunk/src/app-utils/gnc-sx-instance-model.c#L1156>, if you care to see...)
16:08:10 <tyler> so the model is in place to support schedule changes
16:08:27 <jsled> right.
16:08:55 <tyler> if i change the recurrence, for example, code could rip up the tagged transactions and record the new ones
16:09:05 <jsled> yup.
16:09:21 <jsled> It'd be pretty straightforward, in fact.
16:10:41 <jsled> Changes to the template transaction structure/values, too.
16:11:51 <jsled> If you're inclined filing that as an RFE would be appreciated. If you're further inclined, a patch would be very much appreciated! :)
16:11:56 <warlord> I still want to see a way to use "acct_balance_as_of()" as an SX function.
16:12:06 <tyler> here's a wild request: what if SX's were automatically recorded up to the date the user jumps to in the ledger?
16:12:27 <jsled> (sorry ... phone call)
16:14:37 <tyler> this way, if the user only ever looks as far as the current date or a few days ahead, the behavior works as it does now: only those few transactions are recorded as their time approaches
16:15:27 <warlord> what do you mean by "date the user jumps to in the ledger"?
16:15:35 <warlord> How are you "jumping to a date"?
16:16:20 <tyler> via the usual methods of browsing the ledger's history
16:16:31 <tyler> scroll up/down, page up/down,
16:16:48 <warlord> That only scrolls through the existing transactions.
16:17:41 <tyler> i know, but does it have to be that way?
16:17:47 <warlord> which implies that you only would get SXes through "today" (or through the most future-looking manually entered transaction)
16:17:59 <warlord> Does the sky have to be blue?
16:18:04 <tyler> :-)
16:18:18 <tyler> i'm comparing it to my PDA calendar again
16:18:28 <warlord> Yes, which is a bogus comparrison.
16:18:31 <warlord> Gnucash isn't a calendar
16:18:33 <tyler> whY?
16:18:40 <tyler> sure it is!
16:18:41 <warlord> it's a financial application.
16:18:50 <tyler> so it's a financial calendar
16:18:52 <warlord> no, calendaring is secondary.
16:19:12 <warlord> It's not a database, either.
16:19:16 <tyler> what's primary then?
16:19:24 <warlord> storing financial transactions)
16:19:31 <warlord> s/\)//
16:20:34 <warlord> (and reporting on those transactions)
16:20:52 <tyler> isn't that a subset of using a calendar to store generic events?
16:21:01 <warlord> No.
16:21:05 <tyler> on this day, that happened
16:21:15 <warlord> The day is relatively irrelevant.
16:21:17 <tyler> money transferred from one account to another
16:21:59 <tyler> i don't follow
16:22:10 <warlord> Yes, I know, because "a calendar" is your hammer.
16:22:28 <warlord> just like "gda" is esodan's hammer.
16:22:37 <warlord> and "qof" is (was?) neil's hammer.
16:23:05 <warlord> you get focused on a particular technology and see how everything else fits into that technology.
16:23:12 <tyler> how can you track financial transactions while stating the day is irrelevent?
16:23:23 <warlord> I said "relatively irrelevant"
16:24:03 <tyler> you mean only the order of transactions matters?
16:24:13 <warlord> It all depends on what you want reported.
16:24:19 <warlord> Not all reports depend on dates.
16:25:10 <warlord> it's the moving of money that's important. the "when" is secondary, depending on what kind of analysis you're trying to do.
16:25:44 <warlord> granted, it's an important secondary, just as important as the 'who' or 'why'.
16:27:06 <warlord> But thinking of gnucash is a calendar is just as bogus as thinking of your email client as a calendar.
16:27:34 <warlord> sure, email email has a date it in, but the primary purpose isn't the date, it's the content.
16:28:04 <warlord> [ sorry, in a talk -- need to concentrate ]
16:28:07 *** warlord is now known as warlord-slow
16:29:00 <tyler> if my email client was used to automatically generate and send emails on a scheduled date, i would actually treat it more as a calendar program
16:30:11 <tyler> it would just be a calendar program with narrow data type support: email
16:30:26 <warlord-slow> again, that's not gnucash's primary function, either. MOST people don't use it to automatically generate transactions; most use it to enter transactions that happen in real-time. E.g., you go out ot dinner and then record that txn. For me, the only SXes I have are my mortgage, and sometimes I think I'd be better off doing it by hand because the numbers are off.
16:31:39 <tyler> well i guess that's one of the answers I was looking for: how many other people are like me who want these kinds of features from a financial program
16:32:44 <warlord-slow> I think you'll find a wide range of users, from non-SX-users to heavy-SX-users. I also think that having reports understand (and include) SXes would solve 80-90% of the requests we get.
16:34:19 <tyler> or pivot the model so that everything you view is technically a report, including the ledger
16:34:51 <warlord-slow> Maybe.. although currently reports are all HTML
16:35:02 <warlord-slow> and GtkHtml doesn't really do data entry well..
16:35:29 <warlord-slow> But I dont think that's the right approach given the current architecture.
16:36:54 <tyler> in the model i defined, SX's are not recorded, just the schedule definition itself is
16:37:03 <jsled> yeah, that could be interesting ... the idea of infinite scrolling forward in time.
16:37:39 <warlord-slow> tyler: also, you're assuming that SXes dont require user input when they get converted to a real txn
16:39:20 <jsled> But, it's probably a bit tricky from a usability perspective.
16:39:50 <tyler> manual transactions are recorded,
16:39:50 <tyler> actually, no...in my model the act of reconciliation is when a transaction converts from being an intended one to a real one
16:39:53 <jsled> That's a good point. There's another bug about adding an "estimated" value in the template transactions to partially address it.
16:40:21 <warlord-slow> jsled: yes, i was pointing that out to tyler
16:40:52 <jsled> warlord-slow: yes, I was continuing along the same lines...
16:40:56 <warlord-slow> tyler: I want my SXes entered into my register WELL before reconciliation. I want them entered close to the estimated date of execution.
16:42:48 <jsled> tyler: that terminology strikes me as cumbersome. The transaction is still "real", and is not "intended". It might just be recorded a bit differently (slightly different date/time, (hopefully not) different amount) than the bank's view.
16:43:56 <warlord-slow> tyler: think about a cheque. When you write it you enter it into your books, because the amount is "promised". Once it hits your account it's "cleared". Then at the end of the month when you compare your accounts to the statement, it's "reconciled".
16:43:58 <tyler> example: i set up a schedule to get paid salary every two weeks for the next 5 years
16:44:28 <tyler> i view my ledger at some date in 2009, i can see those transactions
16:44:36 <jsled> yeah. Those really are "intended".
16:44:37 <jsled> :)
16:44:42 <tyler> :-)
16:44:57 <warlord-slow> how do you "view [your] ledger at some date in 2009" when it's currently 2007?
16:45:01 <tyler> and they remain that way, until I reconcile them
16:45:40 <tyler> i can't answer that question without bringing in the "calendar" thing again
16:46:06 <jsled> I don't know what it has to do with a "calendar", exactly. If the transactions exist with dates of 2009, then they do.
16:46:06 <warlord-slow> the ledger is just a display of a set of existing transaction.
16:46:09 <warlord-slow> SXes dont "exist"
16:50:03 <twunder> perhaps what tyler wants is a way to look ahead based on SXs. If the report system could see SX's, and SX's that use variables had a way to provide estimates of what those values are, a report could address his desire. (maybe, possibly)
16:50:26 <warlord-slow> twunder: maybe; I've certainly been arguing that.
16:50:36 <tyler> see to me no transaction exists until it is reconciled
16:51:07 <tyler> and that difference in terminology makes me sound confusing I'm sure
16:51:12 <warlord-slow> tyler: unfortunately you're wrong. transactions exist WELL before they are reconciled. See my "cheque" example above.
16:51:17 <twunder> no transaction is reconciled 'til it's reconciled... they certainly exist. My bank takes the money whether I've reconciled the transaction or not ;)
16:51:34 <chris> see to me, no tyler exists until I see code.
16:51:39 <jsled> heh.
16:51:42 <warlord-slow> LOL!
16:52:04 <tyler> :-)
16:52:11 * chris sticks his head back in the sand.
16:52:21 <warlord-slow> No, chris ... come.. come join us!
16:52:21 * twunder too
16:52:46 *** twunder has quit IRC
16:52:56 <jsled> I think chris's comment from earlier sums it up well: gnucash doesn't deal very well with hypothetical/forward-looking accounting.
16:53:16 <tyler> well, i'm not crazy about the whole "clearing" term either
16:53:39 <warlord-slow> tyler: they are financial terms. please stop thinking about calendars.
16:53:46 <tyler> :-)
16:54:00 <jsled> It's an area that we all have wanted to improve. My own initial involvement with gnucash was proposing a "workbench" for forward-looking planning.
16:54:03 <warlord-slow> you may not like them, but there they are. I dont like "Credit" and "debit"..
16:54:26 <tyler> yeah, part of my beef is with the formal financial terms, but from a programming point of view i'm trying to generalize the model
16:55:13 <warlord-slow> Are you planning to stick around and develop for the next decade?
16:55:16 <tyler> after i can define a good generic model, then i'll define the method to translate different views of that model into what the financial world uses
16:55:56 <tyler> that's the plan, i suppose
16:56:52 <warlord-slow> well, then, I suggest you think about your generic model, then translate it back into financial terms, and then come back.
16:57:03 <jsled> Why would you start with the generic model? Start with the well-proven model in use, then make it generic if need be.
16:57:10 <tyler> but i before I could commit to working on gnu cash i'd need to know which ideas of mine would be rejected
16:57:24 <warlord-slow> well, "gnucahs is a calendar" would get rejected. ;)
16:57:34 *** andi5 has joined #gnucash
16:57:34 *** gncbot sets mode: +o andi5
16:58:26 <jsled> Well, FWIW, I'm happy to keep chatting; though I do have low tolerance for idle speculation about matters of code.
16:58:27 <warlord-slow> but I'm with jsled.. Start with the currently proven model and then work to extend it to meet the functionality you need.. Keeping in mind that you may need to change how you think about the problem.
17:00:38 <tyler> "gnucash doesn't deal very well with hypothetical/forward-looking accounting"
17:01:13 <warlord-slow> tyler: yes, but there are some small things that can get 80-90% of the desired effect: e.g. some modified reports.
17:03:13 <tyler> I don't suppose it'd be easy to have interactive reports?
17:03:23 <warlord-slow> define "interactive"
17:03:55 <jsled> The reports are HTML, and probably will remain so going forward.
17:04:03 <jsled> So, they could be as interactive as your standard web app.
17:04:16 <jsled> Or, with some massive extension, as interactive as any flashy/modern web 2.0 thing.
17:04:37 <jsled> But right now, it's really not easy, no. About the best we can do is hyperlinks that open registers.
17:04:43 <warlord-slow> well, jsled, that would probably require migration to Gecko
17:04:44 <tyler> well, html interaction should suffice
17:04:51 <jsled> warlord-slow: right.
17:04:59 <jsled> We had clickable graphs at one point, but that regressed.
17:05:02 <warlord-slow> tyler: again, define "interaction"
17:05:15 <jsled> Or, I guess webkit was open-sourced, and is well-regarded.
17:05:25 <jsled> But moving to gecko seems like a good idea, anyways.
17:05:33 <jsled> (anything but gtkhtml! :)
17:05:52 <tyler> for starters, basically any GUI that we use to kick off the report, have it embedded in the report
17:06:03 <tyler> so changing one value can cause an effect right away
17:06:31 <tyler> maybe this means changing the start-end dates that a report covers
17:06:52 <warlord-slow> tyler: have you looked at gnucash's current reports?
17:07:13 <warlord-slow> I'm assuming not, based on that last statement.
17:07:13 <tyler> very briefly
17:07:18 <warlord-slow> Take a closer look.
17:07:23 <warlord-slow> We already have that.
17:07:26 <jsled> Yeah, I mis-spoke. The report options do provide a good bit of interactivity.
17:07:39 <andi5> jsled: http://arstechnica.com/journals/linux.ars/2007/07/26/using-epiphany-with-webkit ... maybe not overly unrealistic, even
17:07:44 <jsled> Just not via controls embedded in the report rendering.
17:08:04 <warlord-slow> but I dont think the controls need to be embedded in the report rendering.
17:08:09 <jsled> andi5: exactly.
17:08:23 <cortana> inline controls would improve discoverability
17:08:34 <cortana> i'm always pointing the 'report options' button out to people
17:08:58 <jsled> yeah. There's something really broken with the report options ... I guess it's the icon, maybe?
17:09:31 <warlord-slow> or the icon location in the toolbar?
17:09:57 <cortana> i think a combination
17:09:59 <warlord-slow> Maybe the layout of the report page should change to make the report options hooks more prominent/distinctive.
17:10:07 <cortana> what if it looked like this;
17:10:08 <warlord-slow> (without putting the options into the HTML)
17:10:11 <cortana> actually i won't attempt ascii art on irc
17:10:13 <jsled> Maybe if we fixed that RFE for opening the options when the report is created, people would realize that reports *had* options. :)
17:10:22 <warlord-slow> LOL
17:10:27 <warlord-slow> Maybe.
17:11:02 <cortana> but what about splitting the widget that currently contains the report in two
17:11:14 <cortana> the top half would have a 'adjust report options' button
17:11:19 <jsled> Oh, interesting.
17:11:20 <cortana> (and would collapse)
17:11:23 <jsled> yup.
17:11:26 <cortana> the bottom half would have the actual report
17:11:34 <cortana> kind of like MSIE's "information bar"
17:11:41 <jsled> Though given the aspect ratio of the options, it'd probably be better as a left/right split.
17:11:46 <warlord-slow> cortana: that would be the "change the layout of the report page" ;)
17:11:52 <cortana> oh ok :)
17:12:00 <cortana> well, i don't mean to put the actual options into the other pane
17:12:08 <cortana> just a prominent button that brings up the existing dialog
17:12:17 <jsled> Oh, just the button? Well, we have that in the toolbar. :)
17:12:22 <tyler> well here's an example: transaction report
17:12:40 <tyler> it reports on all accounts
17:12:43 <cortana> yeah, but i think it would be more discoverable if it was in the area that the user is looking at hte report, rather than in the toolbar which they're not looking at
17:13:02 <tyler> so what if in my report i had an [X] button next to the acct name
17:13:11 <tyler> i could click it to remove it from the report
17:13:19 <warlord-slow> tyler: that would print out TERRIBLY!
17:14:03 <warlord-slow> and look ugly
17:14:05 <tyler> then you have another button to "prepare for print" that removes the controls
17:14:23 <warlord-slow> Blah!
17:14:29 <andi5> =warlord_slow
17:14:34 <tyler> or put another way, maybe it pops up another report without controls
17:14:40 <jsled> I don't know if it'd look bad. With CSS support, one could hide the controls until the area is hovered over, or something.
17:14:51 <jsled> Certainly printing would want to be addressed.
17:14:54 <warlord-slow> tyler: first, we can't do that with gtkhtml.
17:15:14 <jsled> but, yeah, having a better user experience in the reports is a good thing. :)
17:15:18 <warlord-slow> so it's a moot point until someone (you?) supplies a drop-in to use something else.
17:15:29 <andi5> not to mention that nice little buttons trash accessibility
17:15:54 <andi5> at least one would have to take that into account
17:16:21 <warlord-slow> andi5: well, playing devil's advocate, the current report options dialog pretty much break accessibility, too, I thnk.
17:16:38 <andi5> that is why we need something _better_ :-D
17:17:41 <cortana> well you can have a print media stylesheet that hides the non-printing stuff automatically
17:17:52 <tyler> yes
17:18:08 <cortana> i don't know why web sites insist on having separate 'format for printing' links instead of doing the right thing automatically
17:18:41 <warlord-slow> cortana: because there are still browsers out there that dont support css. think command-line text-based.
17:20:56 <jsled> yeah. I'm not sure how good IE's media-specific or print-specific CSS support is.
17:23:40 <tyler> new question: does current gnucash model support the idea of having one transaction cause the automatic generation of another transaction?
17:24:01 <jsled> no.
17:24:46 <warlord-slow> although an SX can generate multiple transactions.
17:25:01 <warlord-slow> but again, an SX is only a template txn, not a "real" txn
17:25:04 *** Demitar has joined #gnucash
17:25:19 <tyler> but the triggering source there is only a time thing
17:25:56 <warlord-slow> yes, when the SX fires it can create multiple txns
17:26:25 <warlord-slow> Actually.... Wait.. The Scrubber can cause additional transactions to get created, but that code's broken.
17:26:47 <jsled> tyler: are you thinking more of a "standing query" sort of thing?
17:27:51 <warlord-slow> okay, this talk is over. almost time to shut down.
17:27:52 *** warlord-slow is now known as warlord
17:28:05 <jsled> What was the talk?
17:28:13 <warlord> How to Assert and Obtain Composable Security
17:28:19 <jsled> Ooh. Sexy.
17:28:32 <tyler> for example, to automatically handle overdraft protection
17:28:33 <jsled> heh.
17:28:45 <jsled> oh, interesting.
17:29:04 <jsled> Cause there it's not even really about the transaction that's created, so much as the resulting balance of the accounts.
17:29:35 <tyler> true, but when do you check the resulting balance?
17:30:14 <jsled> "check"?
17:31:02 <tyler> some how the system must learn that the balance dipped below 0
17:31:13 <jsled> oh. Well, nowhere right now.
17:31:47 <jsled> Oh, I see what you were saying.
17:31:54 <tyler> but there could be a set of registered rules that inspect a transaction when it is entered
17:31:59 <jsled> right.
17:32:16 <jsled> or a post-commit hook or something.
17:32:20 <tyler> yes
17:33:30 <tyler> so if a transaction attempted to bring the balance to -$10, then the hook could transfer $10 from another account
17:33:36 <warlord> i've been meaning to add post-commit hooks to the register to handle manual entry of "business" transactions.
17:34:10 <warlord> This will be much easier after the register rewrite when we can just create new g_signals from the register.
17:34:31 <jsled> aye.
17:37:38 <tyler> so, if the ledger view could show a mix of SX's and real transactions
17:38:08 <tyler> and would permit browsing into the future (thus just SX's would show up there),
17:38:24 <jsled> yeah.
17:38:36 <tyler> combined with tracking the source of transactions, I think gnucash could be a lot more powerful
17:38:53 <jsled> Even the existing register vs. ledger makes this that model/view distinction, somewhat. Or tries to.
17:39:40 <jsled> But one could *conceivably* populate maybe a different ledger (a concrete instantiation of a register, if you will) with both "real" Transactions and "fake" Transactions.
17:39:55 <jsled> Where "Transaction" there is a "Transaction-interface implementing object".
17:40:16 <jsled> (Or maybe a "RegisterViewable" interface implementor, or something.)
17:42:47 <tyler> yeah
17:47:00 <Knight_Lord> I have a strange problem of having gnucash saying that Finance::Quote is not correctly installed but gnc-fq-dump works fine
17:48:32 <Knight_Lord> I have Crypt::SSLeay installed
17:49:35 <Knight_Lord> How does gnucash checks if quite is installed
17:49:43 <Knight_Lord> ?
17:49:43 <andi5> gnc-fq-check?
17:50:55 <Knight_Lord> andi5: how does that work?
17:51:15 <Knight_Lord> andi5: I only get a list
17:51:27 <jsled> Knight_Lord: `less $(which gnc-fq-check)` :)
17:51:53 <jsled> It looks like it iterates over the required modules and tries to eval "require $mod".
17:51:57 <Knight_Lord> it's in the path
17:52:08 <Knight_Lord> gnc-fq-check runs fine
17:52:15 <Knight_Lord> it's in /sw/bin/gnc-fq-check
17:52:16 <jsled> Where did you obtain gnucash?
17:52:21 <andi5> great... so gnucash works in the same environment like your active shell?
17:52:35 <Knight_Lord> andi5: yes i call it from my shell
17:52:39 <Knight_Lord> jsled: fink
17:52:52 * andi5 stops here ;-)
17:52:56 <Knight_Lord> andi5: gnc-fq-dump works fine
17:53:26 <Knight_Lord> It's compiled from source
17:53:43 <andi5> i would say that is almost always the case :-)
17:53:57 <Knight_Lord> On my computer I mean
17:54:00 <Knight_Lord> not binary package
17:54:08 <jsled> heh.
17:54:24 <jsled> Knight_Lord: is anything output to the console or /tmp/gnucash.trace when you provoke the error?
17:54:53 <Knight_Lord> the only interesting error i get seems to be this gnc.bin-Message: main: binreloc relocation support was disabled at configure time.
17:54:58 <Knight_Lord> But i'll check again
17:55:01 <andi5> ignore that one
17:55:07 <Knight_Lord> This error is at startup
17:55:18 <andi5> yes, fq is checked at startup as well
17:55:52 <Knight_Lord> /tmp/gnucash.trace does not exist
17:56:15 <Knight_Lord> no other error is reported
17:56:20 <Knight_Lord> is there a verbose flag or something?
17:56:38 <andi5> Knight_Lord: perl is in your PATH?
17:57:00 <Knight_Lord> andi5: it is
17:57:04 <tyler> jsled: you could also make a transaction object be even more generic, in that it describes when a particular change was made to the system, not just specifically a balance transfer
17:57:30 <andi5> what version of gnucash?
17:57:36 <Knight_Lord> 2.2.0
17:58:09 <jsled> tyler: genericity comes with a cost. When Transactions are merely "change events", it's really hard to write useful code about them.
17:58:23 <Knight_Lord> I found the problem I think
17:58:43 <Knight_Lord> Seems like fink installed its own perl
17:58:45 <Knight_Lord> in /opt
17:58:51 <Knight_Lord> and put it in front in the PATH
17:58:59 <andi5> and the one in /bin works, right?
17:59:14 <Knight_Lord> now gnc-fq-dump has /usr/bin/perl as #!
17:59:22 <Knight_Lord> so when i call it from the shell that's what is used
17:59:26 <Knight_Lord> and that works fine
17:59:30 <andi5> oh right... that is filled in while.... compilation or so
17:59:39 <Knight_Lord> but if gnucash does "perl gnc-fq-dump"
17:59:51 <jsled> Alright. Time to play "gnucash-devel moderation queue: ham or spam?"
17:59:59 <Knight_Lord> it calls the perl in /opt which does NOT hve the module installed
18:00:19 <andi5> Knight_Lord: 2.2.0 switched from just calling the script to calling "perl -w $thescript"... windows users wanted it that way
18:00:35 <jsled> Today's entry: From: <hikingxzcp wilprint1 com> Subject: for Xacc
18:00:38 <Knight_Lord> seems like it screwed up the macs :D
18:00:53 <andi5> ham?
18:01:05 <Knight_Lord> Actually it wouldn't screw if the gnc-fq-update would also be done in the same fashion i think
18:01:14 <jsled> andi5: legit mail. the inverse of spam
18:01:15 <tyler> jsled: yeah, it certainly adds complexity...though I would still limit it to describing very few kinds of changes
18:01:27 <andi5> jsled: yes,... i asked whether it is ham
18:01:35 <warlord> okay, gotta run! later, all.
18:01:38 <jsled> andi5: Oh. Heh. *BZZZZT*
18:02:00 *** warlord has quit IRC
18:02:07 <jsled> Sorry, the answer we were looking for was "spam". The content gives it away.
18:02:20 <andi5> Knight_Lord: i guess you are right
18:02:31 <andi5> Knight_Lord: would you mind filing a bug about that?
18:03:05 <jsled> Oh, I see. It's actually To: <xacc linas org>, forwarded somehow. Which makes more sense; it's the same as the "Buy Rolexes, jsled-gnomebugs!"
18:03:23 <Knight_Lord> andi5: but i don't know how to fix it
18:04:14 <jsled> tyler: I've come to believe it's more useful to thing about all those types indepdently representing a "change event" interface, rather than thinking about them in some abstract (inheritance) hierarchy.
18:04:20 <jsled> s/thing/think/
18:04:21 <andi5> Knight_Lord: well, ... you know... then you are not allowed to use gnucash anyway... you need to give when you want to take ;-)
18:04:52 <jsled> Knight_Lord: you might want to file the bug downstream with fink, in fact.
18:04:58 <andi5> Knight_Lord: oh, you mean in your situation? ... fix up your path :-D
18:05:33 <Knight_Lord> i'm checking if the problem is from Fink but it actually is not
18:05:49 <Knight_Lord> it's with a Perl installation from MacPorts
18:05:55 <andi5> jsled: well, gnc-fq-check should work always the same, nonetheless... currently we call it differently from what the shebang does
18:06:15 <Knight_Lord> exactly that's the gnucash part of the bug
18:06:39 <Knight_Lord> andi5: because i was following the tutorial and it says to run gnc-fq-update by hand which is gonna use the shebang
18:07:02 <andi5> the she-bang needs an absolute path, right? .... may i assume /usr/bin/env then?
18:07:33 <Knight_Lord> supposed to be POSIX but that's not gonna work in windows i think
18:07:51 <andi5> Knight_Lord: the she-bang is a simple comment on windows anyway
18:07:59 <Knight_Lord> right
18:08:19 <tyler> jsled: last wild idea for me for now: what if the account hierarchy was less like a tree of connected boxes and more like boxes within boxes
18:08:42 <Knight_Lord> andi5: can't you test the platform? In this case it might make sense
18:08:59 <andi5> what platform?
18:09:02 <Knight_Lord> andi5: and just call it on POSIX OSes and use perl script on windows
18:09:07 <Knight_Lord> andi5: if it's windows or not
18:09:38 <andi5> maybe
18:09:48 <tyler> jsled: an account would contain its own, "loose" balance plus also everything each sub-account contains
18:11:02 <tyler> much like you could put pennies in a box, and also put pennies into a smaller box within that box
18:11:28 <jsled> Right. That's (sometimes) the case alread.
18:12:15 <andi5> gnutroschka?
18:12:35 <jsled> tyler: the Total column in the Account tree behaves that way. As well, one can choose to "include subaccounts" during reconiliation.
18:13:42 <tyler> yes, but the transaction log of a parent account does not reflect the same model
18:14:06 <tyler> the total column does, but not the specific transactions
18:15:34 <tyler> doing so may not be much use when you look at the top level or two of accounts,
18:15:37 <andi5> Knight_Lord: well, actually i prefer our first solution, i.e. change the she-bang to "/usr/bin/env perl" and let the fink guys fix up their system.... in the end the /bin/perl stems from a simple search for perl in PATH, iirc.... just not at run time, but configure time
18:15:58 <tyler> but it's a big help if you want to set up sub-accounts to your bank checking account
18:15:58 <jsled> tyler: Sure.
18:16:08 *** gunnicom_ has quit IRC
18:16:45 <jsled> tyler: yeah, that would be.
18:17:06 <jsled> And one could even enter transactions against the subaccounts from that register.
18:17:12 <tyler> the ledger would only reflect money moving into or out of that box
18:17:34 <tyler> even if it specifically went into or out of a contained box
18:17:46 * jsled nods
18:17:54 <andi5> somehow i have never put my money into boxes...
18:18:20 <jsled> That one should be even easier, given either register. In fact, one could probably do it with a search results window right now.
18:18:36 <tyler> so you could create sub accounts "a" and "b" within your checking account, and transferring between them would not & should not be reflected on your overall bank account ledger or bank statement
18:18:46 <jsled> Though I think you'd have to enumerate the accounts.
18:19:22 <jsled> Yeah. We only have "matches {any account,no accounts}".
18:19:47 <jsled> Oh, that's tougher.
18:19:59 <tyler> which is?
18:20:04 <jsled> (eliding "self-contained" transctions.)
18:21:35 <tyler> i would think the other way would be tougher
18:22:13 <jsled> No, cause it's less discriminate. Like I say, you can get the same effect using the existing "Find Transactions" functionality.
18:22:58 <jsled> But if you want to then filter out transactions for which the splits are both within the account sub-tree ... well ... you need to filter the split list that the register is viewing.
18:24:55 <tyler> so you're looking at the transaction list for some account to first include every transaction involving all its subaccounts?
18:25:53 <tyler> and then from that filter out the ones that happen to have no external account in its split
18:29:07 <tyler> actually, filter out those that have don't reference to an external account or that target account directly
18:29:20 <jsled> Not exactly; the model is the reverse. There is only a big list of Splits, which reference Accounts and their containing Transaction.
18:29:34 <jsled> We generate the contents for a register from running a query against the split list.
18:30:10 <tyler> ah
18:30:12 <jsled> So, the query could become a lot more complex ... or we could just do a query, then filter.
18:30:46 <jsled> Not that the latter is hard. It's just the difference between basically using the existing stuff vs. writing new code.
18:31:47 <tyler> sounds like a DB query
18:31:51 <jsled> right.
18:31:56 <jsled> Except without the DB.
18:32:43 <jsled> Or, better said, without a requirement for a DB. The queries could be transliterated to SQL if the backend is a DB
18:33:08 <jsled> But they're constructed as objects and can be evaluated against the in-memory object graph.
18:33:32 <tyler> right, it's got a DB interface
18:33:39 <tyler> but not a DB backing
18:34:35 <jsled> Kinda. There can be a DB backend. And the queries can be rendered as SQL to be evaluated on the DB.
18:35:25 <tyler> and in that case it'd just be the transactions that get stored in DB?
18:36:49 <jsled> with a db backend? Everything's in the DB.
18:37:24 *** andi5 has left #gnucash
18:39:15 <tyler> does the query interface support the SX's?
18:39:59 <jsled> yes.
18:40:26 <tyler> i mean, before the system actually uses the schedule definition to record the transactions
18:40:43 <tyler> i guess it'd be more like a calendar query now that i think about it
18:40:58 <tyler> "give me the transactions between these two future dates"
18:41:11 <jsled> No, that data is not queryable.
18:41:48 <tyler> because that would be more like a calendar query
18:43:16 <tyler> but it would be interesting to have the current query engine internally make a calendar query against each defined SX
18:43:22 <tyler> er..each defined schedule
18:44:47 <tyler> so it returns not just the recorded transactions, but also the scheduled ones too
18:45:06 <jsled> yeah. That'd be a fair bit of work, right now.
18:45:20 <jsled> In part because, as we've discussed, the scheduled transactions aren't actually transactions.
18:45:54 <jsled> Er, the futures scheduled transaction instantiations aren't actually transactions.
18:46:01 <jsled> (the SX'es aren't either, of course.)
18:47:55 <tyler> so there's the schedule definition that holds a transaction template and directs the system when to instantiate that template
18:49:16 <jsled> Yeah. The dialog-sx-since-last-run.c creates a GncSxInstanceModel over a set of SXes and looking forward to some date. That model contains a tree of {GncSxInstances}, each containing a list of {GncSxInstance}s, representing a single (date,transaction[,variable-binding table]).
18:49:17 <tyler> if an instantiation isn't actually a transaction, what is it?
18:49:23 <jsled> A GncSxInstance.
18:49:46 <jsled> Until it's created. At which point the Transaction/Splits are made from it.
18:51:48 <tyler> so the instantiation is more like my "intended" transaction that is used to create the actual transaction
18:51:50 <tyler> close?
18:52:48 <jsled> Somewhat. I think we came to understand that you meant "unreconciled" by "intended". But the GncSxInstance really is an intended transaction ... that's it's whole deal, is to represent the intent to create a transaction at some date.
18:53:11 <tyler> the instance must be used to generate the reminder, if that's what's been defined in the schedule definition,
18:53:28 <tyler> and/or invoke the automatic transaction creation, if that's what's been defined in the schedule definition
18:54:00 <jsled> Right. Another part of that GncSxInstance tuple/struct is the "state". to-create, remind, postponed
18:54:37 <tyler> makes sense
18:56:55 <tyler> so really i'm looking to fold the instance into the transaction, extending the transaction with that "state" property, and adding "performed" as a new state value
18:57:36 <tyler> i.e., to me the transaction *is* the instance
18:59:05 <jsled> yeah. Which is why I was thinking of it more as a bit or flag on the transaction. :)
18:59:13 <jsled> s/trans/Trans/
18:59:58 <tyler> ok
19:00:20 * tyler is hungry
19:00:49 <tyler> thanks for the chat...will be back soon
19:00:57 <jsled> tyler: you're welcome. take care.
19:01:00 *** tyler is now known as tyler|away
19:12:35 *** Demitar has quit IRC
19:39:34 *** Knight_Lord has quit IRC
19:55:17 *** Demitar has joined #gnucash
20:00:03 <jsled> @echo jsled: hello
20:00:03 <gncbot> jsled: Error: "echo" is not a valid command.
20:00:18 <jsled> @echo jsled: hello
20:00:18 <gncbot> jsled: Error: "echo" is not a valid command.
20:01:29 *** linas has joined #gnucash
20:02:32 <linas> according to my calculations, gnucash is technically about 10 years old, now, and my 10 year anniversary will be this octobre ...
20:02:58 <jsled> whoo hoo! :)
20:03:14 <linas> A fellow named Robin .. I forget his last name, write xacc and released version 0.9 in summer 1997
20:03:35 <jsled> Clark says AUTHORS
20:04:01 <linas> and I was the second coder, hacking in nearly two dozen patches in a few weeks, starting in october 1997 ...
20:04:35 <linas> yes, Robin Clark ... I guess that sounds right ... I admit my memory is fading
20:05:02 <linas> (I'm pretty darn sure its 1997...)
20:05:20 <linas> Its october, tat I know, cause it was my birthday ...
20:05:51 <linas> it got renamed to gnucash in 1998 or 1999 ...
20:06:23 <linas> anyway, I'm planning on celebrating.
20:07:06 <linas> actually, I'm planning on gong home right now, bt I thought I'd bring this up for further discussion
20:07:41 <jsled> heh. Indeed. A coordinated, distributed party could be quite ... well, curious, anways. :)
20:32:31 *** cparker has joined #gnucash
21:38:57 *** sjc has quit IRC
22:20:01 *** twunder has joined #gnucash
22:23:12 *** BlackBsd has joined #GnuCash
22:37:13 *** dbr has joined #gnucash
22:38:43 <dbr> I've been banging my head against gnome printing insanity for several days. Is a request to have gnucash have a Page Setup gconf widget reasonable?
22:38:58 <dbr> gnome seems to have a4 paper hardcoded somewhere
23:04:55 *** BlackBsd has quit IRC
23:35:25 *** warlord has joined #gnucash
23:35:25 *** gncbot sets mode: +o warlord