Re: New SX editor sometimes crashes gnucash

[Josh Sled]

On Tue, 2007-01-23 at 11:40 -0500, Josh Sled wrote:
> I'm out of town on business this week, so I'm not really in a position to
> debug right now.  I'll take a look next week when I'm back.

David, try after r15455.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: new sx management always marks data file modified on open?

[Josh Sled]

On Mon, 2007-01-29 at 09:24 -0500, David Reiser wrote:
> It looks to me like the sx rewrite results in the data file being  
> marked as modified (the * shows up in the title bar) immediately upon  
[...]
> It isn't the end of the world, but does the sx checker really have to  
> modify the data file?

It shouldn't.  This was a (minor) goal.  The only time it should dirty
the datafile is if there are auto-create, no-notify SXes since-last-run.
I'll take a look; thanks!

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: new sx management always marks data file modified on open?

[Josh Sled]

On Mon, 2007-01-29 at 09:42 -0500, Josh Sled wrote:
> On Mon, 2007-01-29 at 09:24 -0500, David Reiser wrote:
> > It looks to me like the sx rewrite results in the data file being  
> > marked as modified (the * shows up in the title bar) immediately upon  
> [...]
> > It isn't the end of the world, but does the sx checker really have to  
> > modify the data file?
> 
> It shouldn't.  This was a (minor) goal.  The only time it should dirty
> the datafile is if there are auto-create, no-notify SXes since-last-run.
> I'll take a look; thanks!

David, try r15466.   If you see it again, please let me know.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: dense cal font size

[Josh Sled]

On Wed, 2007-01-31 at 00:01 -0500, David Reiser wrote:
> I just started lurking in the irc logs. I guess I should find a  
> client...

That'd be  for
those of you following along at home...


> But I noticed you asked about dense calendar font sizing. I'd much  
> prefer -1 or 0 for the font reduction. I was happy to see the switch  
> to pango, as that fixed a problem with the vertically oriented month  
> abbreviations. But the current -2 pts makes the dates almost  
> unreadable for me, and there's lots of room in the boxes. However, I  
> am using an old GTK+, so that might be complicating the rendering on  
> my Mac. Fink is working on getting GTK+ up to 2.10 from its current 2.6.

My system font is "DejaVu Sans Condensed Condensed 8", so with the
reduction, it's down to 6 pts, which is on the bubble for me too. But I
figure that if you have a font that you can tollerate as your system
font, then 2 points smaller is probably always going to be just on the
bubble.  Maybe 1 pt reduction is all that's reasonable.

Also, as you notice, there's something not quite right yet with the
dense-cal sizing, as even with the font reduction the days are still too
large.  I've only done the minimum to convert to pango at the moment,
which was the high priority task there; I'd really like to completely
overhaul the dense-cal layout/rendering/computation/&c., but that lower
prio...

Of course, maybe it should use whatever scaled font fits in the boxes,
as defined by the allocation area ... thus the font would shrink if it's
sized really small (to some limit), and grow if there's space available
(to some limit).  Probably unnecessary, though...


What I'll do is make the font-size reduction a gconf value, but not
exposed via prefs/ui.  We can manually change the value if we like to
gauge the effect and correct any problems, but the default will just be
what it is for users that don't care ... and the default will probably
be a reduction of 1 pt.


> While I was looking at the revision, I saw
> in gnc-dense-cal.c, line 305
> font_size -= font_size_reduction * PANGO_SCALE;
> 
> Is that '-=' really a legitimate operator? Code seems to work, but it  
> looks odd to me.

Sure.  It's just sugar for {foo = foo - bar}, of course.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: RFC - SX Projection Report ; Patch - SX enable/disable

[Josh Sled]

On Tue, 2007-01-30 at 22:23 -0500, Peter McAlpine wrote:
> I look forward to hearing your feedback regarding the patch and  
> feature proposal.

The patch generally looks fine.  Thanks for sticking (mostly) to the
coding style convention in the existing files ... even if it's often my
old, silly, everything( before_has_too_much_whitespace_and_after );
convention. :)

I've applied it as r15486, with the following notes and changes:

One problem I have is with the revised interface(s) for
'gnc_sx_get_instances(...)'.  By definition, disabled things don't
generate instances, so I don't see much need to have that spelled out in
the UI; the body of your 'gnc_sx_get_current_enabled_instances' can just
move into 'gnc_sx_get_instances(GDate*)' ... at least in spirit; I have
stylistic quibbles with the implementation [1].  I've made this change.

[1a]: there's no real win by constructing the list backwards and
reversing it; computers are sufficiently fast, especially for the very
small values of 'n' we're talking about here.
[1b]: while loops suck; iterations are a for-loop idiom.
[1c]: 'iterator' is never a good name; 'sx_iter' is better.
[1d]: 'filtered' isn't a great name; 'enabled_sxes' is better.

'_gnc_sx_instance_event_handler' should be modified to ignore
non-enabled SXes that it receives updates about; I've added a fixme in
the code about it.

It'd be nice to add an 'enabled' column to the sx-list model and view;
it'll become an optional column when that view switches over to using
the GncTreeView, at some point here.

There's no need to have configuration, let alone a gconf key, for the
default enabled state.   SXes are enabled by default.  I've removed
this.

Similarly, there's no need for the "newsxP" branch regarding enabled in
the SX Editor setup; the SX is already in the correct default state
(enabled) for new SXes, and its value can be set directly from the SX.

--

The new "enabled" field represents a non-backward-compatible file
change, but that's alright ... we'll probably have others.  We should
probably just release a 2.0.5 that fixes the "XML reader doesn't ignore
elements" problem, and buy ourselves some breathing room in the rest of
the 2.x series.

Tim raises a good point regarding SXes with variables.  Similar is
multi-currency template transactions (which are actually implmented by
creating "fake" variables for the currency conversion rates).  I think
"estimation" is the right solution for both, though with the pricedb,
there's maybe a better chance of forecasting pricedb values.

In any case, there's two major options for handling the problem:

1/ handle at the SX level: in the SX editor, and probably a first-order
part of the SX itself, allow the user to define the estimation of
variables and exchange rates.

- Pros: makes sense; general purpose; durable data entry
- Cons: not used elsewhere; heavyweight; big code changes (schema,
expression parser, SX editor)
  
2/ handle in the report: somewhere in the report, allow the user to
define the estimation for variables.
- Pros: simple; isolated; solves the problem at hand
- Cons: impermanent data entry; reports are already nasty


Reports aren't naturally formatted anything like the register, though
some of the General Ledger/Jounral reports -- with the right stylesheet
-- might be a reasonable facsimile.  Do you really want it to look like
a register, or just reflect the values of the accounts?


While imagining the report itself, I note that presently the only way to
create Transactions from a set of SX instances is by actually creating
them. There's no notion of "proposed" transactions [2], and the
interface that the GncSxInstanceModel provides is only the variables
that need binding. Certainly the SXes themselves have API to get the
transaction detail, but it seems like it'd be better to have the
template-transaction -> real-transaction conversion only be in one
place.  Thus, we should probably factor out that code.

[2] GnuCash (QOF, really), makes this a bit hard since it's non trivial
to create objects that simply aren't on the Books, like Transactions and
whatnot.  Sometimes code just wants to create a Transaction and Splits
that aren't real, and shouldn't be returned in a Query or whatever.  On
IRC we've talked about some notion of an "excursion", whereby code (hey,
exactly like this report! :) could create "provisional" engine objects
that have some sort of visibility or scope.  We probably don't need to
solve that problem right now, but it bears noting.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: r15486 - gnucash/trunk/src - SX "enabled" patch from Peter McAlpine <[EMAIL PROTECTED]>.

[Josh Sled]

On Thu, 2007-02-01 at 09:50 -0500, Derek Atkins wrote:
> Why not store the sx:enabled flag in the SX instance KVP?  Granted, I
> dont think 2.0 has an SX KVP, but we could maybe fix that...  

Besides the fact -- as you point out -- that it doesn't solve the
problem, KVP frames aren't actually data model.  I maintain that we
should try not to use them, and if we do, only with good reason; this
doesn't feel like one.


> I'll
> point out that the 2.0 parser will barf on unknown tags and fail
> to load the data file.

Yup; as I mentioned on -devel, it might be a good thing to fix for a
2.0.{5,6}, so we get a bit of breathing room for 2.{x>0}...

To preempt your question about "how do you tell a broken datafile from
one with simply new tags?", I say: "you don't".  You let XML
well-formed-ness deal with really corrupted datafiles, and you ignore
any tags or attributes that you don't recognize.   If you then ignore
valid future data, fine; if you ignore invalid/broken data, fine.  The
utility of reading a wider set of datafiles is higher than the risk of
reading inconsistent data, with some amount of care taken in the future.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: r15486 - gnucash/trunk/src - SX "enabled" patch from Peter McAlpine <[EMAIL PROTECTED]>.

[Josh Sled]

On Thu, 2007-02-01 at 20:10 -0500, Nathan Buchanan wrote:
> On 2/1/07, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Quoting Josh Sled <[EMAIL PROTECTED]>:
> 
> > To preempt your question about "how do you tell a broken
> datafile from
> > one with simply new tags?", I say: "you don't".  You let
> XML 
> > well-formed-ness deal with really corrupted datafiles, and
> you ignore
> > any tags or attributes that you don't recognize.   If you
> then ignore
> > valid future data, fine; if you ignore invalid/broken data,
> fine.  The 
> > utility of reading a wider set of datafiles is higher than
> the risk of
> > reading inconsistent data, with some amount of care taken in
> the future.
> 
> I still maintain that loading-and-ignoring is WORSE than
> failing-to-load. 
> When you load-and-ignore, then when you save you've now LOST
> data, and
> worse, you've lost it silently!  I think that's worse than
> just failing to
> load the datafile.
> 
> As a lurking user, I'd like to say that data should not be lost
> silently. At worst, display a message so that the user can abort the
> load. 

FTR, I never suggested that.  We're in all agreement that you can not
and should not be silent about losing data.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

file versioning [WAS: Re: r15486 - gnucash/trunk/src - SX "enabled" patch from Peter McAlpine <[EMAIL PROTECTED]>.]

[Josh Sled]

On Thu, 2007-02-01 at 11:58 -0500, Derek Atkins wrote:
> Ideally, EVERYTHING would be "like" a KVP-frame..  But using Gobject
> properties and GValue (or perhaps GNCValue, so we can define our own
> GValue types)...  Then we always load (and save) all properties, and
> hopefully don't have to know a-prori all the properties we might want
> (or need) to save.

We might be talking past each other, but I don't consider a named
property (gobject property or otherwise) any different from a named
struct/object field ... but I do consider it different from an arbitrary
dictionary of name/value pairs (e.g. a kvp-style structure).  I
certainly don't want every GNC object to be struct GncFooBar
{ g_hash_table *fields; }, but I don't think that's what you're
suggesting...


...we could consider having an "overflow" bucket on objects: all known
tags are copied into their fields, and unknown fragments are just copied
literally into this overflow area.  Then, on file-write, we could
re-emit the "unknown" sections literally in their containers.

The XML world has two terms that are useful in thinking about this:
must-understand and must-ignore.  In must-understand, processors must
refuse to load the file if there is an element they don't understand.
In must-ignore, processors must simply ignore them [*].

[*: In HTML/document oriented processing, there's two variants of
must-ignore [1]: must-ignore-all (the whole subtree is ignored) and
must-ignore-container (the intervening container is ignored, but any
recognized child elements (tags and text) are presented as if the
container wasn't there). We're talking about must-ignore-all, here.]

[1] http://dev2dev.bea.com/pub/a/2004/05/soa_orchard.html

In some technologies (e.g., SOAP), these concepts are explicitly in the
XML data, as attributes on tags; an element will indicate if it can must
be ignored or understood for the processor to process it.  I don't think
we want this level of granularity.  We have the overall file version
number as a global "must-understand" field. :)

I guess for processors that re-emit the content, there's two variants of
must-ignore processing: retain and discard.  We're talking about
"must-ignore+retain", here.


Of course, this is not without potential problems; here's an
semi-grounded example. Let's call the file-format and software versions
v1 and v2, for simplicity; these don't correspond to gnc data files v1
and v2, they're just sequential abstract versions.  In v2, the concept
of "Mumbles" are introduced.  These Mumbles hold references to Accounts.
As part of the v2 code, when an Account is removed, the user is queried
for the disposition toward the sub-Mumble which references the Account.
This is all pretty plausible; SX template transactions behave similarly.

If v1 opens the v2 data, under must-ignore+discard, the Mumbles are
discarded, and thus can never become inconsistent!  :)

If v1 opens the v2 data, under must-ignore+retain, the Mumbles are
retained, but ignored (and we informed the user as much :).  Invariably,
the user deletes an Account that a Mumble references.  :) As this is v1
code, it doesn't understand that the consistency of the Mumble must be
maintained.  v1 writes out the revised Accounts, and the unmodified
Mumbles.  When v2 opens the v1-saved datafile, it must run some sort of
consistency check to look for that potential condition, and query the
user for the repair activity.

I guess that this is really how gnc should behave anyways.  Anything
could happen to the data file, and the data file could contain anything.
But it bears noting that we don't really do much in the way of load-time
consistency checks now.


Must-ingore+discard is "pessimistic" versioning; its impossible to solve
all problems, so we refuse to allow any problems, at very high cost.
Must-ignore+retain is "optimistic" versioning; the Mumbles will
hopefully, probably not become inconsistent in most cases ... the user
can hopefully do the right thing ... the receiver (the v2 software)
makes it right, with respect to consistency of data only it can
understand.


For completeness, what are the use cases, here?

-- The "failed" upgrade: v1->v2->v1.

In this case, the user tries out the new version (2.0), tries new
features (budgets), but decides to revert to the old version (1.8).
Here, they probably do want to discard the novel data, so they have a
"pure 1.8" datafile again.

-- The "lateral", switching between processors.

In this case, the user or developer is switching between roughly the
same versions, but with different processing options enabled.  For
instance:

- gnucash-stable
- gnucash-stable, but built with OFX support
- gnucash-svn
- some "cashutil"/"gnc-cli" that only processes core/engine objects in
  a simplified manner on the command-line.

Especially in the modularized world we live in, modules (business, ofx,
even maybe user-specific reports) have module-specific content to save.
I also think we should do away with all data storage that'

Re: r15486 - gnucash/trunk/src - SX "enabled" patch from Peter McAlpine <[EMAIL PROTECTED]>.

[Josh Sled]

On Thu, 2007-02-01 at 22:24 -0500, Peter McAlpine wrote:
> In this case would it be possible to partially avoid the issue by not  
> outputting the enabled tag if the SX is enabled (because it defaults  
> to true)?

We shouldn't elide fields we are aware of.  Explicit is better than
implicit.


> Would this be a quicker solution than fully implementing KVPs:
> Whenever unrecognized tags are found just read the tag into some  
> buffer and when the the object is to be outputted then output the tag  
> just as it was read in.

I don't think it's quicker, actually, but it's probably the right thing.


> Increment the xml version whenever there's new tags added that are  
> completely incompatible. Refuse to load newer versions.

This we do do, I think.  There's not a version number on the root
element, though the tag itself serves that purpose.  In fact, individual
objects have their own version numbers, including the , which
is the practical root of the datafile.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: A couple of questions

[Josh Sled]

On Fri, 2007-02-02 at 14:31 -0500, John Schmerge wrote:
>   I'm a developer who's been using gnucash for about six months and
> really like the program... It's allowed me to really start to track some
> things regarding my finances that I never thought about. Anyway, I'd
> like to start helping out with the development. Being that its a fairly
> large application and that my experience with scheme is fairly limited,
> can anyone give me some ideas of a couple of smaller tasks that I could
> start with that will get me some familiarity with the code-base as well
> as get me up to speed with scheme?

Very little of gnucash is in scheme.  At this point, mostly only the
reports.  Besides, if you have programming experience, you can pick up
enough scheme to be able to grok gnucash's use of it pretty easily.

As for getting yourself into development:

- build it from sources 

- fix a bug that's vexing you, or an existing bug


  There are a couple of gnome-love 
bugs there that are explicitly for beginners to the source,
unfortunately they both look to be scheme/report bugs...

- expand from there.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX event handler behaviour (was SX Projection Report/SX enable/disable)

[Josh Sled]

On Fri, 2007-02-02 at 22:54 -0500, Peter McAlpine wrote:
> On 31-Jan-07, at 10:39 PM, Josh Sled wrote:
> > 
> > '_gnc_sx_instance_event_handler' should be modified to ignore
> > non-enabled SXes that it receives updates about; I've added a fixme in
> > the code about it.
> 
> Am I correct in that this handler exists to update an open SLR when  
> SX's are edited/added/removed? If this is the case then is merely  
> ignoring non-enabled SXes what we want to do?

The handler exists to keep the GncSxInstanceModel up to date.  It
bridges the gap between QOF events and GObject signals.  One possible
listener is the SLR dialog, but the SX List and the dense calendars are
also listeners.

I was wrong about simply ignoring disabled SXes. The GncSxInstanceModel
serves two purposes: being a model of upcoming instances, but also being
a model of basic SX existance (with or without instances)... the SX List
in particular uses it for this second purpose, and needs disabled SXes
to be included.

With respect to these disabled sxes, there's the 3 users, plus the new
user, with slightly different demands on the model:

- SX List: wants disabled SXes in the model, but not projected.

- SLR: shouldn't have disabled SXes.

- dense cal: doesn't care; won't show things w/o instances anyways; 
  ideally wouldn't have disabled instances included.

- projection report: wants both disabled SXes, projected out (?) nd 
  enabled SXes, projected out as well (?)


Maybe, then, the callers should specify which they want in the model
they create:

   [...] gnc_sx_instance_model_new(GDate *range_end,
   gboolean include_disabled,
   gboolean project_disabled);

Following the discussion on IRC, that could be a more abstract flag
rather than a boolean, but as we don't have any other options, let's
just represent what we do have.

The model's event-handling/signaling behavior can then reflect the
creation option; there's a further wrinkle about SXes changing
{en,dis}abled state.  It should be pretty clear what the behaviours in
all cases are, along the lines you wrote, but with the new flag.


> REMOVED event:
[...]
> You've got a fixme at this event but I'm not sure why. Perhaps you  
> were assuming that if we ever removed an SX but no instance exists  
> then it'd be an error? Now that it's possible for a SX to not put any  
> instances into the model we can treat this as a potentially valid event?

The "fixme" was more about printf-based error "handling", but you're
correct: there's no error condition there ... it might be warn-level
condition, though, if we're asked to remove a non-disabled SX that
doesn't have instances.  That'd be a bit weird.


[...]
> Recurrence Frequency to "Weekly" and was incorrectly prompted to  
> confirm that I wanted to create a SX that would never run. I'm  
> assuming this should not have happened this way...?

No, that's just a bug.  I'll take a look...


> Another issue I've noticed is that the calendar should not show  
> instances for non-enabled SX's or SX's that will never run (if I can  
> ever create such a SX), do you agree?

Yup, there is nothing to show.

But ultimately, the dense cal will show whatever is represented in in
the DenseCalModel it's using.  With the model-creation API we're talking
about above, a calendar *could* be configured to show disabled
instances, though the ones that exist in the app right now wouldn't ever
do so.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: r15499 - gnucash/trunk - Remove basically-unused qof date manipulation code better provided by GDate.

[Josh Sled]

On Sun, 2007-02-04 at 14:35 -0500, David Hampton wrote:
> On Sun, 2007-02-04 at 11:50 -0500, Josh Sled wrote:
> > Trac: http://svn.gnucash.org/trac/changeset/15499
[...]
> This breaks end-of-the-month tracking that was intentionally built into
> the reconciliation code.  The original code would track as follows:

Sorry about that.  r15501 should be better.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Patch to README.dependencies for Mandriva 2007.0 package versions

[Josh Sled]

On Sun, 2007-02-04 at 22:22 -0700, Shocky wrote:
> While I was working on the autogen.sh problem I mentioned in my previous 
> thread, I noticed that the README.dependencies file had info for Mandriva 
> 2006, but not 2007, so I put it together as best I could. I wasn't sure if 
> the dates on the releases were release dates or dates the info was compiled, 
> so I chose the latter. I also couldn't reach the rutgers mirror, so I used 
> the proxad one I use for my updates. I also added a note about the need for 
> the -devel packages. I used "svn diff"; I hope this is the correct patch 
> format. I hope this is of some use.

Thanks for the update; applied @ r15507.

In the future, please attach patches as an, uh, attachment, rather than
in-lining them ... less formatting trauma.

Cheers...
-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX event handler behaviour (was SX Projection Report/SX enable/disable)

[Josh Sled]

On Mon, 2007-02-05 at 01:42 -0500, Peter McAlpine wrote:
> Please find the attached patch:
> 
> - SX instance models properly handle SX update/add/remove events with/ 
> without enabled transactions
> - New SX editors now show non-enabled transactions

Looks good; r15510.  It'd be great if you could add some unit tests for
disabled SX handling in the instance model, and the {en,dis}abled
transitions, but whatever.  I've made a note in sx.rst about the tests.



On Mon, 2007-02-05 at 14:46 -0500, Peter McAlpine wrote: 
> - add a check-box to the SX list tree-view to show the SX enabled  
> status.

On Mon, 2007-02-05 at 17:14 -0500, Peter McAlpine wrote:
> - don't show non-enabled SX's on the SX dense calendar

I combined these two; r15511.   There's a nasty flicker on the dense-cal
as OK is clicked, but I doubt that's related to this patch.


Thanks...
-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Failure in configuration for a Mac

[Josh Sled]

On Wed, 2007-02-07 at 03:50 -0600, Jim-Moore wrote:
> checking for pkg-config... no
> checking for pkgconfig... no
> configure: error: Could not find the pkg-config (or pkgconfig)
> program.

You need to install `pkgconfig`. :)

These days, that's a pretty fundamental package ... if you don't have it
installed, you might not have a bunch of other stuff installed.  Are you
building this through fink or macports ... and if not, why not?


> In examining the files on my one disk system, I don't find a file  
> named pkg-config or pkgconfig, although I do see a directory named  
> pkgconfig under /usr/lib/

You'll not often find a good answer to problems like this by examining
the filesystem for individual files, as it's usually the entirety of a
package that's required.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

FreqSpec -> Recurrence migration, SX XML version rev

[Josh Sled]

Summary: The SX code is going to migrate from FreqSpec to Recurrence,
which will require a datafile version revision of SXes.


FreqSpec and Recurrence are really similar in capabilities, but
Recurrence has one extra feature which has been desired by SX users for
a while: last-weekday of the month processing.

I've been hoping for a while -- without delving too deeply -- that the
migration could occur by adapting the Recurrence in the object model
with the FreqSpec XML serialization ... the code would use Recurrence
objects, but read/write 's back out; the datafile would be
compatible all the way back to gnucash-1.8...

This is still a possibility, I suppose.  The UI could intentionally
disallow last-weekday-of-month selection, only creating SX Recurrences
which are backward-compatible.  Pro: datafiles are good back to
gnucash-1.8, Con: users don't get the new feature.

I think the con outweighs the pro.  I'm planning on versioning the
 structure, and simply replacing the FreqSpec with a
Recurrence.

Note that the version number change is just the right thing to do, but
the 1.8/2.0 parsing code doesn't actually check the version number.  It
does, however, require that the  is present, and thus will
fail when it is not.  The 2.2 code will be a bit better, I guess.

After the change, there's a lower-priority, nice-to-have-for-2.2 feature
of including a {File > Export > GnuCash 1.8/2.0} (or maybe a drop-down
in the {File > Save As...} dialog, or whatever).  But I don't consider
it a 2.2 release blocker.  If users do complain and/or need to go back
to 1.8/2.0 from a 2.2-saved datafile, we could also have a stand-alone
converter script (in Your Favorite Scripting Language) that did the job.
I don't really intend to do either before 2.2.


Notes for posterity...

Looking at the XML handling code, there's no good way to report the
location or type of error during parsing.  It looks like most code does
PERR and PWARNS.  It'd be nice to extend the code to at least say "error
parsing at line # col #, xpath {/gnc-v2/gnc:book/gnc:schedXaction}:
element sx:recurrence not recognized."  Or whatever.  But it's a fair
bit of rework to plumb the appropriate error/value handling through the
sixtp parsing stuff.

It wouldn't be *too* bad to support such a "save as specific version"
option.  The setting would need to be plumbed from the UI to the
backend, then from the backend through the "sixtp_gdv2" structure, and
then into the individual gnc_mumble_dom_tree_create(...) functions, most
of which have *no* context about the serializing effort.  Probably the
bigger issue/change would be a front-end check to make sure that the
content *can* be saved in a previous version, and maybe error-ing out or
resolving conflicts before (while?) doing the writing.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

logging overhaul (please read)

[Josh Sled]

  *** Up-front apologies for the length.  Please at least read the  
summary and the questions in the text; search for "?".

Summary
---

r15537 contains a major overhaul of the logging subsystem in (qof and)
gnucash.

In short, on the surface, you *should* only notice:

- a change in the format in /tmp/gnucash.trace
- more output from make check
- maybe a *bit* more output from the app
- the disabling of --loglevel (with replacement; see below)


Overview


I've been growing frustrated with logging in gnucash; when I reworked
the SX code, I couldn't bring myself to write DEBUG or PINFO... I just
ended up using printf()s.  At least I could be sure they'd be printed to
the console, and without everything else at MOD_GUI. :/

More specifically, I've disliked the following things:

- No (easy) stdout/stderr support; I rue the day /tmp/gnucash.trace was
introduced.

- It's hard to change things at runtime; revising log-levels means
editing src/engine/ something.

- The granularity isn't good enough.  Each MOD_mumble is usually way too
much, MOD_GUI especially.  And adding a new level -- while much better
than before -- is a bit of a chore.

- Crap formatting.  No timestamps, no consistency.


In the mean time, I've been spoiled with log4j.  The log4x stuff is just
great.  It's proven to be a really good way to handle logging.  In
particular, the hierarchical leveling and appenders make life grand.

So I got a bee in my bonnet yesterday, and fixed our logging to be more
like that, without dep'ing on log4c or anything.  Let's call it
'log4glib'. :)


Core Changes


qof_log_init() now installs a handler that interprets the "log_domain"
as a "."-seperated path.  Log level thresholds can be set for each level
in the tree.  When a message is logged, the longest level match is
found, and used as the threshold.

For instance, we can set the levels as such:

  "qof"= WARN
  "gnc"= WARN
  "gnc.ui" = INFO
  "gnc.ui.plugin-page.sx-list" = DEBUG

When GNC_MOD_IMPORT (now="gnc.import") logs (at DEBUG, let's say), it
will attempt to match "", then "gnc", then "gnc.import".  As "gnc" will
match -- at "WARN" -- the debug log will be rejected.  When
"gnc.ui.plugin-page.sx-list" logs at DEBUG, however...


This system uses g_log pretty heavily.  As such, I've made the QOF_LOG
levels be G_LOG_LEVELs directly, in the following correspondence:

QOF_LOG_FATAL   = G_LOG_LEVEL_ERROR
QOF_LOG_ERROR   = G_LOG_LEVEL_CRITICAL
QOF_LOG_WARNING = G_LOG_LEVEL_WARNING
QOF_LOG_INFO= G_LOG_LEVEL_INFO
QOF_LOG_DEBUG   = G_LOG_LEVEL_DEBUG
QOF_LOG_DETAIL  = G_LOG_LEVEL_DEBUG
QOF_LOG_TRACE   = G_LOG_LEVEL_DEBUG

In auditing the code, however, DETAIL and TRACE are used in a very small
number of places, and wil be removed.


The historical PERR, INFO, TRACE, ... macros were changed to simply call
g_log.  Before, the macros would qof_log_check(...) against the
ever-present `log_module`, then (maybe) call g_log(...) using
G_LOG_DOMAIN.  Now, the calls just call with "log_module" as the log
domain directly, and let the log handler do it's thing.

However, we never define G_LOG_DOMAIN anywhere. :/ As well, we do have
"raw" calls to g_{message,warning,debug,...} throughout the code ... as
well without G_LOG_DOMAIN defined.  I've added an appropriate value to
the Makefile.am's throughout the tree where those calls are made; now
these calls take advantage of the same mechanism.  We should probably do
this more uniformly and simply for every source file.

As I aluded to before, I've changed all the {GNC_QOF}_MOD_* #defines
from the form "qof-foo" and "gnucash-bar" to "qof.foo" and "gnc.bar".  I
specifically chose "." rather than the "-" that was already in play
because it's both more natural as a path-separator, as well as a guess
that it will be used far less than "-" in existing strings.


Initialization
--

Initilization has seen some re-work.  I'm not thrilled with it, but it
works fine for now; in some ways, it's less broken than before.

By default (i.e., calling qof_log_init()), we log to stderr with a base
level of "warn".  GnuCash will default to logging to
"/tmp/gnucash.trace", as before, and with the same levels as before
("gnc"=warn, "gnc.test"=debug (it was "trace"))

There are two new command-line options:

  * --logto ["stdout"|"stderr"|file]

* logs to the given handle or file.

  * --log log.ger.path=level

* sets the log-level at runtime
* can be called multiply

  * e.g.,

  $ gnucash --logto stderr --log ""=info --log gnc.engine=warn --log 
gnc.ui=debug

The option "--loglevel" is presently disabled; is it used enough to
bring back, or can people just say <--log ""=whatever>?


Note that in this scheme, the "log4glib" handler sees messages from all
(unhandled) domains ... including "GLib" and "GnomeUI".  For instance,
to quiet GLib's CRITICAL's regarding "Invalid key name"s, one can say::

Re: r15537 - gnucash/trunk - Overhaul gnc/qof logging: Add default log handler that implements a "log4x"-style log level hierarchy. Correctly use G_LOG_DOMAIN, raw glib logging. Cleanup tests that ar

[Josh Sled]

On Fri, 2007-02-09 at 18:46 +0100, Christian Stimming wrote:
> Index: /gnucash/trunk/src/register/register-gnome/Makefile.am
> ===
> +
> +INCLUDES = -DG_LOG_DOMAIN=\"gnc.register.gnome\"
> 
> 
> Shouldn't this be defined in the automake variable DEFS? Or are there
> any reason not to do so?

I was working from the devhelp text for GLib, which suggests the form I
used.  My auto-fu is weak; I'd love a better suggestion about where/how
to specify it.

As well, it'd be nice if it was defined to something reasonable (say
just "gnc") at the top-level, which was used as a default elsewhere, but
over-ridden (or appended to) in the sub-dirs that are interested in
doing so.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: logging overhaul (please read)

[Josh Sled]

On Fri, 2007-02-09 at 13:10 -0500, Derek Atkins wrote:
> Quoting Josh Sled <[EMAIL PROTECTED]>:
> 
> [snip]
> > The space-based indentation as per ENTER/LEAVE has been disabled.
> > Before, the {in,de}dent calls were conditional on qof_log_check, but
> > that no longer exists.  I'm pretty sure it can fit back in by creating
> > two new log levels... but I'd like to hear feedback first?  I personally
> > don't find it useful, but I think others do, and it's a pretty big
> > regression.
> 
> I personally like this functionality and would miss it if it's gone
> for good.  It's EXTREMELY useful when you're trying to trace the
> program to see when you get out of a particular call tree by
> looking at the indentation level.  It's most helpful when you have
> a re-entrant function.

*nod* I'll work to restore this functionality.


> I think I like the log-level test short->long, because it means
> if I set e.g. "gnc" -> debug then I get ALL "gnc.*" messages,
> even if gnc.foo.bar is set to "error"..

In both approaches, un-specified levels inherit from the longest
sub-match, but the longest match is always used.  In the example you
gave, (gnc.foo.bar,info) would not be logged, but (gnc.notfoo,info)
would be.

This can be very useful to run the overall system at (say) "info", but
to quiet down a particularly uninteresting/stable/noisy subsystem (e.g.
our xml layer) ... and conversely to get more detail from a problematic
layer (e.g., "gnc.gui.plugin-page.sx-list").


Going long->short is only to get slightly better performance:
"gnc.notfoo" would still match at "debug" (with 3 lookups: "gnc.notfoo",
"gnc", "") while "gnc.foo.bar" would match at "error" in 1 lookup
(instead of 4).

(But now that I think about it, you only get better performance in the
relatively uncommon case of having a lot of highly-specific overrides.
I probably won't make that change.)

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX not entered to Register

[Josh Sled]

On Fri, 2007-02-09 at 01:19 -0500, Volker Englisch wrote:

> a) Enter Values
> I just build GC 2.0.4 (R15521) on FC6.  I have a scheduled transaction 
> for a utility bill coming up.  I click the "(need value)" field and 
> enter the amount for the transaction and then I click OK.
> However, the transaction is not being entered to the register of the 
> utility.
> Maybe I'm not using the new interface correctly?

No, that sounds like the right path through the dialog.  One thing to do
is check the "Review created transactions" checkbox, make sure the list
contains what you expect, and then compare that to the normal register
for the involved accounts.


> b) Delete Values
> I am entering a value for a scheduled transaction in the SLR window and 
> realize I have entered the amount for the wrong transaction.
> How can I delete this value?
> When I delete the value, it is repopulated as soon as I select another 
> transaction.

Yeah, that's a bug.  Noted.


> c) Delete Auto-created transactions
> I have a daily expense that I'm keeping track of which is auto-created 
> using a scheduled transaction.  Once in a while I do not have this 
> expense (i.e. didn't by lunch due to vacation).
> With the old interface I was able to delete auto-created transactions 
> before they were added to the register.
> How do I delete an auto-created transaction from the SLR interface or 
> will I have to go to the expense account to delete those transactions?

Here, I was about to suggest you use the "Review created transactions"
list, they're not present in that list/search.  It seems like they
should be, so I guess that's a bug.  Would that be sufficent ... it
seems like it's similar to the review page you'd get in the old UI.

Another option would be to make the "Created" state -- instead of
insensitive -- a combo box with {"create as planned", "ignore"}, but I'd
rather not.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: logging overhaul (please read)

[Josh Sled]

On Fri, 2007-02-09 at 13:41 -0500, Josh Sled wrote:
> On Fri, 2007-02-09 at 13:10 -0500, Derek Atkins wrote:
> > Quoting Josh Sled <[EMAIL PROTECTED]>:
> > 
> > [snip]
> > > The space-based indentation as per ENTER/LEAVE has been disabled.
> > > Before, the {in,de}dent calls were conditional on qof_log_check, but
> > > that no longer exists.  I'm pretty sure it can fit back in by creating
> > > two new log levels... but I'd like to hear feedback first?  I personally
> > > don't find it useful, but I think others do, and it's a pretty big
> > > regression.
> > 
> > I personally like this functionality and would miss it if it's gone
> > for good.  It's EXTREMELY useful when you're trying to trace the
> > program to see when you get out of a particular call tree by
> > looking at the indentation level.  It's most helpful when you have
> > a re-entrant function.
> 
> *nod* I'll work to restore this functionality.

This is back (r15539).

As penance for breaking it in the first place, I started to go through
the sources ensuring the balance on ENTER/LEAVE pairs.  One of the
problem is that mismatched pairs end up leaving the current indent
counter floating at some absurdly high value; on a run just now, the
last log statement has 904 spaces (226 indents). :/

But after going through a fraction of the uses, I decided to stop.
Generally doing this stuff in a language without structured exception
handling is hard, but in particular, the g_return{,_val}_if_fail
construct makes it a bit more painful.

To that end, I've added gnc_leave_return{,_val}_if_fail macros to
qoflog.h, and even used them in a few places, but they're not ideal ...
you can't set the message of the LEAVE, for example.

In any case, someone should still go through and audit the balance of
ENTER/LEAVE statements. At worst because it's the Right Thing to do, but
also because mis-matched pairs can (pretty early on) render the
indentation level confusing or maybe misleading ... :/

Also, I removed the TRACE and DETAIL levels, the DEBUGCMD macro, and
some other unused stuff.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

~/.gnucash/log.conf

[Josh Sled]

 Forwarded Message 
> Date: Fri, 9 Feb 2007 20:29:30 -0500
> Trac: http://svn.gnucash.org/trac/changeset/15545
[...]
> Support for ~/.gnucash/log.conf, a key-value file of logging settings; see 
> comment-doc for qof_log_parse_log_config(...) for the file format.
[...]
> Modified: gnucash/trunk/lib/libqof/qof/qoflog.h
[...]
> +/** Parse a log-configuration file.  A GKeyFile-format file of the schema::
> + *
> + *  [levels] 
> + *  # log.ger.path=level
> + *  gnc.engine.sx=debug
> + *  gnc.gui.sx=debug
> + *  gnc.gui.freqspec=debug
> + *  [output]
> + *  # to=["stderr"|"stdout"|filename]
> + *  to=stderr
> + **/
> +void qof_log_parse_log_config(const char *filename);

After this, I recommend a "dev" ~/.gnucash/log.conf like::

[levels]
gnc=mess

[output]
to=stderr

Which will put a bit more detail in your face without being too
overwhelming.  At least, you should know it's possible. :)

(I do suggest trying 'gnc=info', and seeing how many times we populate
the gnc_commodity table :)

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Problem running svn r 15552

[Josh Sled]

On Sat, 2007-02-10 at 11:02 -0700, Dave Herman wrote:
> I start with:
> 
> [EMAIL PROTECTED] GnuCash-svn]$ LANG=en_US /opt/gnucash-svn/bin/gnucash
> --nofile --loglevel=6
[...]
> Any suggestions on additional data to isolate problem ?

"--loglevel" is currently unsupported, as per
.

I assumed it would just be ignored, but it turns out that not only do we
not enable the "ignore unknown" option in the command-line parser, but
it's set to unknown-is-error by default, and we don't even check if the
parsing resulted in error.  As such, if any argument is ill-formed, we
treat all the command-line arguments as file names, and thus (in your
example) will try to load the specified file "--nofile".

However, this shouldn't haved failed in the way you describe ... it
should have just said via dailog "The file "/path/to/--nofile" could not
be found.", but generally stayed running.  Weird.

In short, to work around the problem, don't specify "--loglevel=6" as an
option.  I'll correct the other issues in a while.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Problem running svn r 15552

[Josh Sled]

On Sat, 2007-02-10 at 13:21 -0500, Josh Sled wrote:
> However, this shouldn't haved failed in the way you describe ... it
> should have just said via dailog "The file "/path/to/--nofile" could not
> be found.", but generally stayed running.  Weird.

Well, I found another 3 bugs looking at this, and while I've never seen
the problem before, I did start seeing it after you mentioned it. :/

I hope that r15554 resolves the problem for you.  I think I saw the
problem after making very similar changes, but maybe I didn't see that
there was a syntax error, or something, in what I thought I tested.

In any case, try r15554.  If you still see the problem, try running it
under gdb:

$ /opt/gnucash-svn/bin/gnucash-env gdb /opt/gnucash-svn/bin/gnucash-bin
[gdb output]
(gdb) run --nofile

If you get dumped back to a (gdb) prompt, then provide the output of the
command "backtrace".

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Problem running svn r 15552

[Josh Sled]

On Sat, 2007-02-10 at 12:19 -0700, Dave Herman wrote:
> On Sat, 2007-02-10 at 13:21 -0500, Josh Sled wrote:
> > On Sat, 2007-02-10 at 11:02 -0700, Dave Herman wrote:
> > > I start with:
> > > 
> > > [EMAIL PROTECTED] GnuCash-svn]$ LANG=en_US /opt/gnucash-svn/bin/gnucash
> > > --nofile --loglevel=6
> > [...]
> > > Any suggestions on additional data to isolate problem ?
> > 
> > "--loglevel" is currently unsupported, as per
> > <http://lists.gnucash.org/pipermail/gnucash-devel/2007-February/019836.html>.
> > 
> 
> Whoops sorry I missed that message.  However startup still fails, I was
> merely trying to capture a log.

Besides the gdb stuff I mentioned in the other mail, you might try
running with "--log gnc=debug", and see if/what is printed
to /tmp/gnucash.trace.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Problem running svn r 15552

[Josh Sled]

On Sat, 2007-02-10 at 14:42 -0700, David V Herman wrote:
> Don't want to sound pickey however when I try to build r 15559
> on a FC6 x86_64 system make ends with;
[...]

No, not picky at all, that's indeed a problem. Fixed in r15560.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: logging overhaul (please read)

[Josh Sled]

On Fri, 2007-02-09 at 22:51 +0100, Christian Stimming wrote:
> Am Freitag, 9. Februar 2007 18:38 schrieb Josh Sled:
> > The option "--loglevel" is presently disabled; is it used enough to
> > bring back, or can people just say <--log ""=whatever>?
> 
> I'd suggest to have *one* option that can be used by the average Joe Linux 
> user which will increase logging to a useful value (maybe INFO). I don't know 
> whether --debug is used currently - that one would be a useful candidate.

That's a good way to look at it.

The --debug flag presently has two effects:

- enable the Extensions menu
- allow (gnc:debug ...) logging.

It seems right to have two options: one for enabling the Extensions
menu, and one for getting log detail.  I like --debug for the latter,
and some new flag for the former.  As there's a small set of people devs
who need to be "retrained" for an extension menu option, that seems
better than the other way around, and "--debug" is a promising candidate
to the eyes of Joe Linux when scanning --help...

So, maybe:
--extend?  meh.
--enable-extensions?  too long.
--extra?  Hmm...

I'll probably go with --extra in the absence of a better suggestion.


(I note, as well, that the scheme logging should probably call wrapped
g_«log»... calls, rather than just (write ) the lines out.  Oooh,
that'll be a good way to figure out how to swig-ify some api... :)

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: logging overhaul (please read)

[Josh Sled]

On Sun, 2007-02-11 at 10:25 -0500, Derek Atkins wrote:
> Quoting Josh Sled <[EMAIL PROTECTED]>:
> > I'll probably go with --extra in the absence of a better suggestion.
> 
> Or --debug-menu ?   I suppose --extra or --extensions or --devel-menu
> or..  whatever.. would work.

I ended up going with --extra; it enables the Extensions menu.

--debug now sets the log-level of {"","qof","gnc"} to INFO.  I tried
DEBUG, but it's really impressively too verbose.  INFO isn't, but it's
also not as detailed as it should be.  We'll have to re-level things
over time...

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: 1 question

[Josh Sled]

On Tue, 2007-02-13 at 10:54 +0400, AnAs wrote:
> If I want to enter a journal entry, for example: 
> -Rent (Debit)   10,000
> -  Cash (Credit)  10,000
> How can I open the general journal? 

It's in the Tools menu, listed as "General Ledger"; we are aware that
that's a misnomer.

While you can do this in the General Journal, the "normal" way to entery
transactions in gnucash is from an Account register ... usually the
Assets or Liabilities account register, and likely, here, the cash
account register.


(This question should really have been to gnucash-user, not
gnucash-devel.)

...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX not entered to Register

[Josh Sled]

On Fri, 2007-02-09 at 21:10 -0500, Volker Englisch wrote:
> On 02/09/2007 02:01 PM Josh Sled wrote:
> > On Fri, 2007-02-09 at 01:19 -0500, Volker Englisch wrote:
> >> a) Enter Values
> >> I just build GC 2.0.4 (R15521) on FC6.  I have a scheduled transaction 
> >> for a utility bill coming up.  I click the "(need value)" field and 
> >> enter the amount for the transaction and then I click OK.
> >> However, the transaction is not being entered to the register of the 
> >> utility.
> >> Maybe I'm not using the new interface correctly?
> > 
> > No, that sounds like the right path through the dialog.  One thing to do
> > is check the "Review created transactions" checkbox, make sure the list
> > contains what you expect
> 
> No, that list does not contain the transaction I'm trying to enter.
> In fact, I have multiple transactions that are listed with the Instance 
> State of 'Created' but they aren't included in the 'Review Register'.
> I am wondering if the transaction doesn't get created because it has the 
>   status of 'Reminder'?
> 
> Let me know if you'd like me to create screen shots to see this.

No need, I've seen this as well; the auto create transactions just
aren't included in the "created transaction" list.

BTW, r15546 added the ability to reset the variable back to blank/"need
value".


> > Here, I was about to suggest you use the "Review created transactions"
> > list, they're not present in that list/search.  It seems like they
> > should be, so I guess that's a bug.  Would that be sufficent ... it
> > seems like it's similar to the review page you'd get in the old UI.
> 
> Yes, this would work.  However, I don't see how this would allow someone 
> to hold back a transaction for a couple of days, if necessary?
> For instance, I am getting a rent check every month which is due on the 
> first of the month but I delay the entry to the register until I have 
> the check in my hand.  The old UI allowed me to set the status of such a 
> transaction to 'Postpone' until I release it.

This is still true for non-auto-create transactions ... say, those that
have come due, or are created in advance.  The "State" column cells,
when clicked, are a combo box of the options.

Unfortunately, the GtkTreeView doesn't give any affordance that controls
might be available when cells are activated ... neither these combo
boxes or the variable-binding text entry fields.  :(



> To be honest, I am not too crazy about the new SLR interface.  I have 65 
> scheduled transactions and with the new interface I will always have to 
> scroll through the list to find one that may need to have values 
> entered.  The old interface only showed those transactions I needed to 
> act upon but not the entire list.  I could imagine having the list 
> sorted by 'Instance State' so that the relevant transactions would 
> bubble to the top.

The Ok button on this dialog will have a similar behavior to the "Next"
button on the to-create-transaction page from the old SLR druid: if
there is a transaction with unbound variable(s), it will focus it.

Perhaps it'd be better if there was a seperate "Find Unfinished" button,
and the Ok-button sensitivity was a function of the overall completeness
of the transactions; a count of the need-variables transactions
remaining would also be nice.

As well, it sound like a "hide complete" toggle might be welcome.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: ~/.gnucash/log.conf

[Josh Sled]

On Sun, 2007-02-11 at 15:18 +0100, Christian Stimming wrote:
> Could you add a short overview of what you'd recommend somewhere in the wiki? 
> Like, http://wiki.gnucash.org/wiki/Logging or such? I think that would be 
> helpful. Thank you very much.

Done, at that location.  I've also updated the qoflog.h doxygen (the
link in the wiki page should become valid when the docs are regenerated
tonight).

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Developing the documentation

[Josh Sled]

On Wed, 2007-02-14 at 12:19 +, Leom Burke wrote:
> I am planning on working on the documentation to improve it for other
> new users.  I have the SVN trunk for the docs but the XML does not seem
> to be standardised - no tabs and the tags dont line up in any editor.
> I would like to tweak the code slightly to improve the readability for
> new contributors by tabbing the tags properly...etc.  As this is a

The tags all line up fine.  What editor are you using?  What file are
you looking at?

(FWIW, I don't consider the use of the 'tab' character to be proper at
all.)

> rather large task i am asking if anyone minds me doing it first :).  I
> would then start a page-by-page analysis of the documentation as it
> appears to be something that gets overlooked by the developers (i didn't
> mean to offend anyone then) and needs someone to take stock and ensure
> that it is fully up to date and flows correctly.

No offense taken; we're all volunteers and we all contribute as much,
and in the ways, we can ... and contributions are welcome! :)   Like all
writing -- code and docs -- more time spent simplifying usually improves
clarity, and is time well spent.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Modules and GnuCash (was: MacIntel trunk build failure)

[Josh Sled]

On Thu, 2007-02-15 at 12:43 -0500, Peter McAlpine wrote:
> And so I pose this question: is GnuCash to have a modular design or
> not? If yes, then the modules need to be ripped apart and made to use
> a strict interface. If no, then the GNCModule code should be ripped
> out and everything should (go back?) to being treated as a library.

No, we don't need runtime loadable {G,GNC}Modules.  We should just have
a collection of shared libraries.  Features and apps are configured at
buildtime, not runtime.

We might want to change that in the future, but we'd probably do it
differently.  We'll win much more than we lose by removing the GNCModule
stuff.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Commodities and reports

[Josh Sled]

On Thu, 2007-02-15 at 17:38 -0500, John Schmerge wrote:
> Also, I'm wondering if the current report rendering engine can support
> anything more advanced than basic scatter-plots... Can someone provide
> me a link to some info on this? I'm almost leaning towards having this
> type of graphing capability be an actual tool, hanging off of the tools
> menu, rather than a report. Any thoughts?

We use goffice for graphing.  It's the graphing engine from gnumeric, so
it fundamentally supports everything that gnumeric can do.

The gnucash reports, however, only support basic scatter, box and pie
charts.

It's relatively straightforward to support new types, however.  See the
handle_{piechart,barchart,scatter} in
src/gnome-utils/gnc-html-graph-gog.c to get an idea of how much is
involved.  That's the side that gets a callback from GtkHtml for an
 tag in the report-generated html that contains a particular
type of chart data.  Note that there's a corresponding chunk of code on
the scheme report side to emit the appropriately-formatted 
block in the HTML, of course.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Modules and GnuCash

[Josh Sled]

On Fri, 2007-02-16 at 12:28 -0500, Derek Atkins wrote:
> > Example:
> > business-core
> > business-core-file
> > business-gnome
> > business-utils
> >
> > Could these be merged into one "business" module? Are there any  
> > others that should definately be merged?
> 
> MAYBE.  I'd have to think about this more.  I'm thinking this should
> be two modules, "libgncmod-business" and "libgncmod-business-backend-file".
> Maybe..

Is dialog-tax-table a library in the module as well?

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Modules and GnuCash

[Josh Sled]

On Thu, 2007-02-15 at 21:15 -0500, Derek Atkins wrote:

> And these should be modules (or combined together):
[...]
> > gnucash/import-export/binary-import

I don't think this is used, anywhere, and can go away.

(I thought it was the pre-1.6, binary file import code, but that's
actually in backend/file/.  That can probably go away as well, but
that's just a separate issue.)


> > gnucash/report/standard-reports
> > gnucash/report/stylesheets
> > gnucash/report/utility-reports

Sure.  Probably all as a single module, just for simplicity.


> > gnucash/report/locale-specific/de_DE
> > gnucash/report/locale-specific/us
> > gnucash/tax/de_DE
> > gnucash/tax/us

As well, there's probably just one module for all the txf stuff, to make
life easier.  It's unclear if some of the de_DE stuff is loaded/used as
per comments in the files.  I also love how the de_DE files are under
the us/ subdir. :/

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Current data file incompatibility of branch-2.0 vs. SVN-trunk

[Josh Sled]

On Sun, 2007-02-18 at 12:40 +0100, Christian Stimming wrote:
> My suggestions:
> 
> * First of all, I would like to have a quick'n'dirty solution for us 
> developers who frequently swith back and forth between SVN-trunk and 
> branch-2.0, but still want to use the same data file. This could even be an 
> external command line script [3], but it should be in SVN anyway so that we 
> keep track of what it does.

After chatting with David Reiser in IRC the other day about the
FreqSpec->Recurrence migration, I'd been convinced to do something along
these lines.

For the two incompatabilities we're talking about, we have recourse.  In
the case of the enabled flag, just don't write it and lose the info.  In
the case of the FreqSpec/Recurrence stuff, I'm planning on keeping the
FS and Recurrences in the object model, in parallel, and just writing
out the appropriate one.  At some point we'll need to drop the FS'es,
but not right away ... probably just before 2.1.0.  Also,
new-with-Recurrence features will obviously not be written, but
shouldn't write an incompatible datafile (just a broken one).


A gconf key seems like a simple way to specify this.  Probably something
generic like "apps/gnucash/development/data-file-compatability
(boolean)"?  I'm already modifying the SX XML code, so I'll add it in in
a soon commit.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Current data file incompatibility of branch-2.0 vs. SVN-trunk

[Josh Sled]

On Sun, 2007-02-18 at 09:24 -0500, Josh Sled wrote:
> A gconf key seems like a simple way to specify this.  Probably something
> generic like "apps/gnucash/development/data-file-compatability
> (boolean)"?  I'm already modifying the SX XML code, so I'll add it in in
> a soon commit.

After some hiccups this evening (details in the irc logs), there's now a
new /apps/gnucash/dev/allow_file_incompatibility gconf key.   This
controls writing both the sx:enabled option as well as the "version 2"
SXes with a recurrence list.

As I found out, in order to enable this option, you'll want to run
${top_srcdir}/bin/update-gnucash-gconf, and/or add and
appropriately-modified line like:

xml:readonly:/opt/gnc/unstable/etc/gconf/gconf.xml.defaults

to your ~/.gconf.path (thanks andi5! :).


(On a related note, the SXes are now using Recurrences instead of
FreqSpecs for most of their periodic goodness, including new support for
the "last weekday of month" frequency, and a much-simplified
GncFrequency widget. :)

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash patch

[Josh Sled]

On Wed, 2007-02-21 at 01:18 -0500, Yoshihiro Ota wrote:
> I fixed the #2 problem as well.  The problem is that "gtk_html_print" is 
> renamed to "gtk_html_print_page"; refere to 
> http://svn.gnome.org/viewcvs/gtkhtml/trunk/src/gtkhtml.h?r1=8386&r2=5139.

Yeah, this naming change appears to be on a pretty recent dev release of
gtkhtml3.  What version is FreeBSD providing/using?

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Google Summer of Code 2007?

[Josh Sled]

On Tue, 2007-02-20 at 10:20 -0500, Derek Atkins wrote:
> to oversee the google aspect but we would need to have the other
> developers willing to mentor the students and help them along.

I'd be happy to mentor.


> We'd also need a list of potential projects..

The ones you suggest at  are good.

I hate pre-announcing stuff (especially that I'm not working on at the
moment), but I'm hoping to have at least a branched version of a new
reporting framework in place by summer (before, actually).  I'd like it
to exist along-side the existing reports at first for a couple of
reasons... in any case, converting reports into the new framework would
be a nice, bounded, project.


Others that come to mind just perusing RFEs:

- CSV/general-delimited-file importer
- bulk/multi-transaction operations
- scheduled invoices
- basic inventory module
- business object list views (rather than searches)
- accessibility review
- gnome-vfs support
- move app logic out of ui-handling code

Also, .

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Google Summer of Code 2007?

[Josh Sled]

On Wed, 2007-02-21 at 12:31 -0500, Josh Sled wrote:

> Others that come to mind just perusing RFEs:

Another nice self-contained project is a grammar-based expression parser
and editor UI.  The goal would be to simplify/clarify the existing
(recursive descent) expression parser, but also to support expressions
including a function like...

  accountBalanceAsOf(account, asOfDate)

...where the user would want to edit `account` and `date` differently
from how gnucash would want to represent/store the values.  To get a bit
more sophisticated, the function definition might be able to specify
constraints/ranges for the values that the editor would represent.

(For bonus points, once functions can contain these values, the SX
subsystem would want to listen for changes to those accounts, and
interrogate the user for appropriate updates...)

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: ChangeLog

[Josh Sled]

On Wed, 2007-02-21 at 20:06 -0500, Derek Atkins wrote:
> As of 2.2 the plan is to automate the ChangeLog entries as part
> of "make dist".  This still wont have the per-file information you
> seem to want, but I believe the format does have revision numbers
> which allows for easily looking up the information in Trac.

FWIW, here's a sample of the output from `make ChangeLog.svn` on trunk:
The thing we lose is the function-level information.

2007-02-21 19:50  andi5

* [r15641] trunk/src/business/business-gnome/dialog-invoice.c:
  Reenable search for Voucher Owner. Fixes #410511. In the "Find
  Expense Voucher" search dialog one cannot search for voucher
  owners because of this typo. BP

2007-02-21 18:46  andi5

* [r15640] trunk/src/business/business-core/business-core.scm:
  gnc:job-get-owner is gncJobGetOwner now. Fixes #410407.

2007-02-21 06:59  hampton

* [r15639] trunk/src/engine/Account.c, trunk/src/engine/Account.h,
  trunk/src/engine/Group.c,
  trunk/src/gnome-utils/gnc-tree-view-account.c: Simplify function
  parameters.
[...]

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: ChangeLog

[Josh Sled]

On Wed, 2007-02-21 at 20:19 -0800, Thomas Bushnell BSG wrote: 
> On Wed, 2007-02-21 at 20:13 -0500, Josh Sled wrote:
> > On Wed, 2007-02-21 at 20:06 -0500, Derek Atkins wrote:
> > > As of 2.2 the plan is to automate the ChangeLog entries as part
> > > of "make dist".  This still wont have the per-file information you
> > > seem to want, but I believe the format does have revision numbers
> > > which allows for easily looking up the information in Trac.
> > 
> > FWIW, here's a sample of the output from `make ChangeLog.svn` on trunk:
> > The thing we lose is the function-level information.
> 
> Presumably it would be easy to get that information if it were recorded
> in the svn info in the first place, right?

Yes, in fact it's nearly exactly as if it was in the ChangeLog; all
we've really done is change which is the "system of record", as we all
got tired of manually copy-and-pasting ChangeLog messages to the
commit-log (or vice-versa).  And the changed-file list itself can be
more conveniently, correctly and completely generated from the version
control system.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: How about plans for a 2.1.x/2.2.0 release?

[Josh Sled]

On Thu, 2007-02-22 at 16:20 +0100, Christian Stimming wrote:
> For that reason, I would propose unstable/beta releases as early as
> mid-March, and planning for a stable 2.2.0 release in mid-May. What do
> you think?

I like it.  I hope we can do with at only ~4 releases ... on 2-week
cycles, that's 8 weeks.  Starting mid-March, that puts us -- as you say
-- at mid-May.  If we get it out earlier, that'd be great, but this
sounds like a reasonable timeframe.

The SX rewrite stuff should be readily closed out in the next couple of
weeks, though I doubt that gives prock time to both get modularization
fixed and subsequently finish his SX-based-budget work. :(  At the same
time, the sooner we get 2.2 out, the sooner we can talk about 2.4. :)


> With regards to the ideas about Summer of Code, I think those projects
> would be good for after-2.2.0, which IMHO is yet another reason to plan
> for a 2.2.0 before the summer. Also, I know a 2.2.0 in May probably
> means the register-rewrite won't make it this time, which is indeed
> unfortunate, but OTOH there are already enough other features which
> would IMHO justify a new stable series.

All very pragmatic; sounds right.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: r15658 - gnucash/trunk - Remove src/network-utils/, module [...]

[Josh Sled]

Hopefully you intend to track trunk/ changes, but this one in particular
will affect the module-cleanup branch.

 Forwarded Message 
> Author: jsled
> Date: 2007-02-25 11:21:46 -0500 (Sun, 25 Feb 2007)
> New Revision: 15658
> Trac: http://svn.gnucash.org/trac/changeset/15658
> 
> Removed:
>gnucash/trunk/src/network-utils/

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Google Summer of Code 2007?

[Josh Sled]

On Thu, 2007-02-22 at 11:00 -0500, Derek Atkins wrote:
> Could you add some of these to the SoC2007 page?

Done.  I dropped "business object list views" on second thought, because
it didn't really seem like a big-enough project.  Also, "accessibility
review" isn't really well defined enough.   If that seems wrong to
anyone, feel free to update the page.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Google Summer of Code 2007?

[Josh Sled]

On Tue, 2007-02-27 at 19:36 -0500, Derek Atkins wrote:
> I wonder if we want to add something like "Dogtail set harness"
> to the list as a project for someone who wants to help write some
> initial DogTail UI tests?

I'd rather much of the core testable code moved out of the UI, but
there's still plenty of goodness to be gained -- and probably in the
near term (with someone who's not familiar with all the gory details of
gnucash) -- by having UI-based testing.  +1 from me.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Possible bug in the expenses system

[Josh Sled]

On Tue, 2007-03-06 at 06:14 -0500, John Schmerge wrote:
> I have a bunch of personal data in my books that I'm not willing to give
> anyone, but am looking to solve the issue. If anyone can tell me who to
> talk to about this, I'd be happy to debug the issue.
> 
> Please email me if you're the owner of the expenses report.

There's no particular owner of the reports; in many cases the primary
author is no longer around.  I note that Christian Stimming does have a
copyright/authorship notice on many of them, so he may assert otherwise.


Which report in particular?  Expenses piechart?  Barchart?

I suggest removing relevant transactions from (perhaps a copy of) your
datafile until you find the one that makes a difference.  If there is a
large number, perhaps a binary search will allow you to find it faster.

Another option would be to output a message — perhaps the transaction
(txn) guid, description and amount — for each txn included in the
report; you should then see the one stand out ... or not, in which case
we can try something else.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX: Created Transactions disappear from Register

[Josh Sled]

On Sat, 2007-03-03 at 23:52 -0500, Volker Englisch wrote:
> A new register tab is being created with the created transactions 
> listed.  When I click on one of the transactions to change the date or 
> the memo all of the transactions suddenly disappear.

I can reproduce; this review page is done by providing a list of the
created transaction guids to the transaction search-results page ...
similar to the Edit > Find ... menu.  As this is done on the way out of
the SLR dialog, it probably frees the list before it's appropriate to do
so.  One probably gets lucky until the second or third attempt, at which
point the already-freed memory is being used inappropriately, and boom.

Thanks for the report!

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX: Created Transactions disappear from Register

[Josh Sled]

On Sat, 2007-03-03 at 23:52 -0500, Volker Englisch wrote:
> listed.  When I click on one of the transactions to change the date or 
> the memo all of the transactions suddenly disappear.
[...]
> ***MEMORY-ERROR***: gnucash[17614]: GSlice: assertion failed:
> sinfo->n_allocated > 0

Fixed in r15687.  Thanks again.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Drop internal copies of libgsf and goffice

[Josh Sled]

On Fri, 2007-03-09 at 00:50 +0100, Andreas Köhler wrote:
> I wonder whether we can remove the internal copies of libgsf-1.12.3 and
> goffice-0.0.4 from trunk for GnuCash 2.2.  Are there any major
> distributions 2.2 targets left without packages containing libgsf-1.pc,
> or goffice-1.pc and goffice-3.pc?

RHEL4, I believe.  I don't think we should target it, however ...
especially with RHEL5 imminent.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

80-column width [WAS: Re: indent]

[Josh Sled]

On Thu, 2007-03-08 at 23:46 -0500, David Hampton wrote:
> -l80  Line width of 80.

This one I find problematic.  I understand the arguments for it, and
have made them myself.  But identifiers and type names are just too long
these days.  An 80-char limit can cause frequent and unnatural
line-breaking; I think 100-char limit is more realistic.

I do think a 80-char limit is a good guideline ... but an unbroken
(e.g.) 95-character line is better than an 80-character line followed by
a 15-character line.

See the attached example of over-zealous wrapping differences of
gnc-plugin-page-register.c.

If we persist, I think we should have a convention for where the '='
goes, and that is at the beginning of the next line (like other
"continuing" operators).


Note that I think -lc80 is very reasonable, though.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]
[EMAIL PROTECTED] [~/stuff/proj/gnucash/src-trunk]$ egrep -n -A1 "= *$" 
~/tmp/register-80.c ; egrep -n -B1 "^ *=" ~/tmp/register-80.c 
381:static guint gnc_plugin_page_register_n_actions =
382-G_N_ELEMENTS(gnc_plugin_page_register_actions);
--
535:gnc_plugin_page_register_type =
536-g_type_register_static(GNC_TYPE_PLUGIN_PAGE,
--
640:gnc_plugin_class->update_edit_menu_actions =
641-gnc_plugin_page_register_update_edit_menu;
--
669:action_group =
670-gnc_plugin_page_create_action_group(parent,
--
877:priv->component_manager_id =
878-gnc_register_gui_component(GNC_PLUGIN_PAGE_REGISTER_NAME,
--
948:priv->gsr->window =
949-GTK_WIDGET(gnc_window_get_gtk_window(GNC_WINDOW(window)));
--
1080:use_double_line =
1081-g_key_file_get_boolean(key_file, group_name, KEY_DOUBLE_LINE, 
&error);
--
1126:account =
1127-
gnc_account_lookup_by_full_name(gnc_book_get_root_account(book),
--
1844:name =
1845-g_strconcat(account_name, " ", _("and subaccounts"), " - ",
--
2457:window =
2458-
gnc_window_get_gtk_window(GNC_WINDOW(GNC_PLUGIN_PAGE(page)->window));
--
3029:label =
3030-
gnc_plugin_page_register_get_tab_name(GNC_PLUGIN_PAGE(page));
--
3050:visible_page =
3051-gnc_main_window_get_current_page(GNC_MAIN_WINDOW(window));
[EMAIL PROTECTED] [~/stuff/proj/gnucash/src-trunk]$ egrep -n -A1 "= *$" 
~/tmp/register-100.c
781:priv->component_manager_id =
782-gnc_register_gui_component(GNC_PLUGIN_PAGE_REGISTER_NAME,


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: indent

[Josh Sled]

On Fri, 2007-03-09 at 01:17 -0500, Chris Shoemaker wrote:
> I would recommend adding -ss, and I would have defaulted to -cli0,
> which is also K&R, but I don't feel strongly about it.

+1 on -ss .

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: indent

[Josh Sled]

On Fri, 2007-03-09 at 02:21 -0400, Peter Selinger wrote:
> I also recommend
> 
>   -T ExampleType
> 
> for every 'typedef', so that you get:

:(  We have nearly a thousand typedefs in the code some are relatively
anonymous, but most aren't... I wonder if there's a way to say '-T *',
or something similar?

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: 80-column width

[Josh Sled]

On Fri, 2007-03-09 at 11:00 -0500, Perry E. Metzger wrote:
> You can rail against how stupid this is, but it won't get you very far
> with those of us who live this way. You can thus choose to make the
> code unreadable by a large chunk of the developer community, or stick
> to 80 columns.

I'm not saying it's stupid and it shouldn't make it "unreadable".
Actually, I'm suggesting the code is more readable.

I've made these arguments myself in the past...  literally, all the same
points you bring up.  I think they focus on the wrong things.  I'm also
not being capricious; I've spent years trying it both ways, and I find
the code is clearer with an 80-column guideline, but without an
80-column limit.


Editors shouldn't wrap preformated code.  In the common case, the bulk
of the code fits clearly w/in 80-columns ... with a few lines where the
ends trail off and need to be scrolled.  In my experience, you can get
the gist of the line from seeing the first 80 characters, and need to
scroll over very rarely.  My normal emacs window is 198x75, and I much
more often split it horizontally than vertically; when I do, though, I
can still fit code into the ~80-wide sub-windows, especially for
comparing stuff side-by-side.

Over-deep nesting is an orthogonal issue.  Similarly, too-long functions
are something else entirely.  I'm guilty of both, at times, but I'm not
looking for a 100-wide limit to work around either of those smells.

Printing to the page often requires reformatting (in other contexts as
well).  I don't think it is useful to optimize for this (increasingly)
special case.

Yes, some part of this proposal is due to editing files in 2007 on a big
monitor, with a good IDE, &c.  But that's how we spend 99% of our time,
so it's what we should focus on.


> As an aside, generally speaking, I think identifiers and type names
> are no longer than they were in the early 1980s. I also think humans
> are no smarter, so we can't deal with keeping larger blocks of code in
> our heads at once than we could 25 years ago.

Identifier lengths, perhaps ... function-local variables and class-local
field names tend to have the benefit of scoping and context to allow
them to continue to be short.  I think too much code uses meaningless
abbreviations, but ...

But functions and type names are clearly getting longer, especially as
libraries do more and higher-level stuff.  I think this is especially
true in C and Gnome-ville, where there's no language support for
packaging and aliasing (as in, say, Java and C#).


Take, for example,
http://svn.gnucash.org/trac/browser/gnucash/trunk/src/gnome-utils/gnc-tree-model-account.c#L55

We've taken to shortening names like these to something like
'gtma_[...]', and that works much -- but not all -- of the time.


Or, take for example the dozen cases from real code that I presented in
the previous email; those are reasonable cases from a not-exceptional
file.


> The biggest consideration in style choices is making sure as many
> people as possible can read and understand your code, since the

This is my motivation.  I think a >80-character unbroken line is more
readable than one "unnaturally" split at 80 columns.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Screenshot page?

[Josh Sled]

On Sun, 2007-03-11 at 13:02 +, Andreas Köhler wrote:

> So what do you think?  There are plenty of screenshots at 
> http://svn.gnucash.org/trac/browser/gnucash-docs/trunk/guide/C/figures 
> already, but maybe we want something special, like a shot of several 
> features at once or so.  Anyone willing to set up such a page?

.  It definitely could use some
more and better screenshots.

The website content is in svn at
 (or svn+ssh, if you're
enabled).

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX: Created Transactions not removed from SLR list

[Josh Sled]

On Sun, 2007-03-11 at 18:45 -0400, Volker Englisch wrote:
> It seems the transactions that are either listed to be ignored or to be 
> created are not cleared from the SLR list and are displayed again the 
> next time the SLR runs.  Here it doesn't matter if the SLR is started 
> from the menu option or starts automatically when GC starts.
> Also, it doesn't matter if the 'Review created Transactions' box is 
> checked or not.

I can't reproduce this ... with either normally-created or postponed
transactions (and ignored instances are ignored).  Can you narrow the
reproduction critera?  Can you describe the SXes?

When you reproduce, please do so with the attached log config file as
~/.gnucash/log.conf, and post the output of /tmp/gnucash.trace ?

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]
[levels]
gnc.engine.sx=debug
gnc.engine.recurrence=debug
gnc.app-util.sx=debug
gnc.backend.file.sx=debug
gnc.gui.sx=debug
gnc.gui.frequency=debug


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX: Created Transactions not removed from SLR list

[Josh Sled]

On Mon, 2007-03-12 at 22:42 -0400, Volker Englisch wrote:
> I have the feeling just the content without the debug options will help you:
> * 22:15:28  CRIT  g_date_set_julian: assertion 
> `g_date_valid_julian (j)' failed

> This also explains why - as I noticed today - a transaction scheduled 
> for weekly is automatically being added daily.  Something must be wrong 
> with getting the dates.  However, my system date is correct (updated 
> regularly with NTP).

This is likely in the "promotion" of the <=gnucash-2.0 FreqSpecs into
Recurrences.  I realized a while ago that the first cut of the
conversion code doesn't handle the start date setup very well.  It'll be
a little while before I can fix it ... hopefully this week.

The weekly->daily case is unexpected, though.  Would you mind isolating
the  XML for that SX and sending it over ... here or
privately?


> Would it make sense to try a clean build of GC?

Not likely; I'll advise when I commit code that I'm happier about.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: 80-column width [WAS: Re: indent]

[Josh Sled]

On Fri, 2007-03-09 at 15:46 -0500, Chris Shoemaker wrote:
> Let me speak up in favor of the 80-char limit.  However, I'm okay with
> treating it as "strongly encouraged" rather than rigorously enforced.

I think after discussion in #gnucash that we've come to consensus that
the goal is an 80-column line width, but that it's not a hard rule.

I think breaking after '(' is a good idea, as well, and should be part
of the style.


I mentioned at the time that it'd be interesting to know what the
"natural" width is.  Not rigorously, just looking at the number of
line-ending "="s after re-formatting with -l{80,85,90,95,100}, we see:

src/engine/Transaction.c
txn-80.c:  4
txn-85.c:  2
txn-90.c:  2
txn-95.c:  1
txn-100.c:  1

src/gnome/gnc-plugin-page-register.c:
register-80.c:   12
register-85.c:   6
register-90.c:   6
register-95.c:   2
register-100.c:  1

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: indent

[Josh Sled]

On Sat, 2007-03-10 at 14:57 +0100, Christian Stimming wrote:
> (If I speak for myself, I rather prefer -bl -bli0 i.e. the braces after if on 
> a new line, but I know this style is used only by a minority and in this case 
> I think the benefit of a uniform style outweighs by far the discomfort of not 
> seeing my individual preferences applied.) 

Agreed.  I certainly prefer the '-bl -bli0' style, but it's far more
important that we're consistent.


> So: When will the One Great Indentation Commit happen in SVN, who will do it, 
> and how do we enforce this style for future commits? 

The timing argument is similar to the Great Renaming we've discussed ...
probably best immediately before a public pre-release series, such as
the upcoming 2.1.0.  At that point, any outstanding changes are
minimized, and we're at a point where we won't need to back-port fixes
to a previous release line with a different style.

Part of the motivation for doing the Great Renaming at that point is to
minimize the amount of "public" stack traces from testing of builds that
are contain the "old" names.  That argument doesn't really apply here.

The bigger issue is the other major "pending" changes right now: the
gobject-dev, gda-dev and modules-cleanup branches.  I suppose each of
them could be separately "ident-ified", and then any cross-merging that
needed to occur could simply skip the reformatting changeset.  Of
course, they'd all want to merge up to the revision of pre-reformatted
trunk before being re-formatted themselves.  A bit messy, but I don't
think it's horrible with communication.

I think David should do the reformatting.


I'd imagine editor configuration is the primary way the formatting will
occur; I've not yet come up with the proper emacs incantations for the
style.  Perhaps a 'gnucash-c-mode' for convenience.  We could add emacs-
or vi-style mode lines to individual files as well, but if devs already
have their editor configured, that becomes redundant.  HACKING should be
updated to include the details.

Social mechanisms are probably the best enforcement.  I don't think we
want to automate running indent on every commit or anything.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX: Created Transactions not removed from SLR list

[Josh Sled]

On Tue, 2007-03-13 at 01:18 -0400, Volker Englisch wrote:
> On 03/12/2007 11:35 PM Josh Sled wrote:
> 
> > The weekly->daily case is unexpected, though.  Would you mind isolating
> > the  XML for that SX and sending it over ... here or
> > privately?
> 
> Is this what you are looking for?
> 
> 
>
>  0

Yup.  Let me know if it's better @15723, and also if the day-of-week of
the transaction is correct.

BTW, I committed the "better" code I was referring to in another email;
though I think — while better — it's unrelated to this issue.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX: Created Transactions not removed from SLR list

[Josh Sled]

On Thu, 2007-03-15 at 01:59 -0400, Volker Englisch wrote:
> Strange thing happened:  It looks like some of my transactions were 
> incorrectly scheduled for Jan. 1st.
> For instance, I have an annual subscription to a magazine scheduled as a 
> reminder for Sept. 1st.  This has now been included in the SLR list of 
> items with a date of Jan 1st.  When I look at the "Last Occur", "Next 
> Occur" columns this SX is listed with a date of Jan 1st but editing this 
> SX the date is listed as Sep. 1.

Hmm, well that's wrong.  I guess the handful of SXes I'm testing against
aren't sufficient ... I'll come up with a better test suite.


>  > and also if the day-of-week
>  > of the transaction is correct.
> 
> I wasn't able to compile the new version before midnight so I'll have to 
> wait until tomorrow to see if the change fixed the problem but I'll 
> report back as soon as I know more.

This shouldn't be sensitive to day-transition around midnight ... maybe
I'm misunderstanding you.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GnuCash password features

[Josh Sled]

On Tue, 2007-03-20 at 16:22 +, Mendy, Gaspard (UK - London) wrote:
> I am conducting a review of some of the key applications used by our
> clients at Deloitte Enterprise Risk Services, particluarly around
[...]
> provide me with the following information relating to the password
> setting capbilities of the GnuCash application:

GnuCash has no "password setting capaibilties".

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GObject in GC implementation Plan

[Josh Sled]

On Wed, 2007-03-21 at 00:42 -0600, Daniel Espinosa wrote: 
> Get GObject as the base of GC's objects. With the following advantages:
>   - Get ref counting
>   - Get signals events

Using GObject is a prerequisite of either of the separate "ref counting"
and "signals" projects, but aren't advantages that directly follow from
using GObject.


> **OPTION 1: PORT QofEntity TO USE GObject AS BASE CLASS
> ***OPTION 2: PORT QofInstance TO USE GObject AS BASE CLASS
> ***OPTION 3: PORT GC's OBJECT TO USE GObject AS BASE CLASS

I read Option1-Step1 and Option2-Step2 as basically the same thing:
"everything will just happen".  They're not really "steps"; I don't take
away from them a clear plan of action.

Option 3 is broken out better, but it doesn't seem as suitable as Option
2.  In particular, I don't see why one would change the type hierarchy
twice (in Steps 2 and 5).  As well, it seems pretty agreeable all around
to merge QofInstance and QofEntity from the start.  At least for the
purposes of discussion, let's call this merged type "GncObject".

I'd agree with Chris; Option 2 is probably the better path.  Or maybe a
modified version of Option 3, where:

- QofInstance and QofEntity are combined

- The GnuCash types then subclass GncObject.

  - QofInstance fields are just inherited (not included by pointer)

- Minimal changes to use G[nc]Object.  I'm thinking, here, for example:

// ..._get_type() { ...g_type_static_register()... }
// ...

Account*
xaccAccountMalloc()
{
Account *a = g_object_new(GNC_ACCOUNT_TYPE, NULL);
// ...existing Account setup...
return a;
}

  ...and, well, that's about all.  No signal or property registration,
  in particular.


[from Option 3...] 
> Step 4:
> Setup QofInstance to be a GObject and be sure to have a correct
> construction/destruction process, this will ensure a correct
> refcounting.

I'd suggest — in any plan — deferring handling "correct"
construction/destruction and ref counting to a later phase of work.


In particular, here's what I see happening.  Once you start to modify
(say) xaccFreeTransaction() to be "correct", it will want to look like:

xaccFreeTransaction(Transaction *t)
{
g_object_unref(t);
}

...then it only makes sense for its dispose handler to look like...

{
GList *splits = ...;
g_list_foreach(splits, g_object_unref, ...);
}

...which means you have to have "correct" both ref and unref behavior
for the Splits, which means, they need a "correct" dispose handler
like...

{
g_object_unref(split->account);
}

...which means ... for it to be "correct", everything needs to happen
all at once.  It quickly gets to a point where a bunch of changes need
to be made to every file at the same time, increasing the chance that
the whole set isn't clear or clearly acceptable.

I don't think that that necessarily needs to be the case. Better
construction/destruction and ref-counting can be phased in.  In
particular, I think there are related groups of objects (Maybe {Account,
Split, Transaction}.  {GncCommodity, GncPrice, GncNumeric} ... &c.) that
could ref-count with each other, probably while intentionally ignoring
other groups of objects.  Along the way it wouldn't be fully "correct"
nor complete, but it'd be much more tractable.

Maybe you mean something else by "correct", though.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GObject in GC implementation Plan

[Josh Sled]

On Thu, 2007-03-22 at 10:39 -0400, Chris Shoemaker wrote:
> I think his point is that you can convert the engine objects to
> GObjects, using the g_object_new() and g_object_unref() in place of
> the current allocation/deallocation functions, but without actually
> tracking references between objects.
[...]
> the objects are all GObjects.  Conceptually, it's as if the "Engine"
> maintains a single reference on all engine objects.  There will only
> be the one reference added by the g_object_new(), and then unrefed at
> the end of the object's lifetime.  No calls to g_object_ref().

Yes, that is what I meant exactly.
Sorry I didn't make it as clear as this.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Ping: Re: [patch] FIx loan druid when auto_decimal is enabled

[Josh Sled]

On Tue, March 27, 2007 8:05 am, Derek Atkins wrote:
> Jerry Quinn <[EMAIL PROTECTED]> writes:
>> Derek Atkins wrote:
>>> I haven't.  I don't know if Josh has.  Has anyone tested this patch?
>>> Have you?  Does it work?
>>
>> It works as expected for me when I test it, both with auto-decimal
>> enabled and
>> disabled.
>>
>> What else would you like me to do?
>
> Convince JSled to look at it?  He knows that code better than I do.
> The patch looks okay to me, but I don't understand the code..

I'd be happy to, but I'm out of town on business this week, and am not
really in a place to (comfortably) apply the patch.  I'll take a closer
look next week.

Can you attach the patch to the bug, please?

-- 
...jsled
http://asynchronous.org/ | a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [Inquiry]GNUCash SoC - Implementing Undo

[Josh Sled]

On Wed, March 28, 2007 11:29 am, Ariel wrote:
> Actually, I'd like to turn this around - why aren't those things written
> to the log? I think they should. If I invoice a customer, and then loose
> data, I'd certainly like to be able to replay that.

In large part because the transaction log is basically a reimplementation
of a database, and we're not a database project.  In large part because
it's not trivial to create a domain object that modifies the txn log for
free.  In no serious part because it's named "Transaction" log ... how
could you put anything else in there... ;)


> Because of that, is why I suggested that undo has a window of it's own,

Does any other app handle undo this way?  Why should gnucash be different?

What does gnumeric do when you undo a change not on the local workbook
page/tab?  We should do that.


> I don't think it's possible to make undo local to each view.

Of course it is possible, anything's possible.

-- 
...jsled



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [Inquiry]GNUCash SoC - Implementing Undo

[Josh Sled]

On Wed, March 28, 2007 5:37 am, Derek Atkins wrote:
> But I ALSO think that there needs to be an application-wide UNDO
> list, for operations that don't have a locality..  E.g. imports,
> accounts/budget/business object creation, etc.
>
> This is clearly a VERY big problem, but how can we scope it to make it
> doable in a summer.  Perhaps each QOF Instance has an undo log and
> there's some way to merge all those logs into some serialized list
> based on the current context?  But of course you still have to worry
> about the atomicity.  For example, an import operation will create (or
> modify -- setting the cleared status) a bunch of accounts and
> transactions at one time, so if you're in an account register of one
> of those transactions you shouldn't be able to remove that WHOLE
> transaction without removing the whole import -- and gnucash should
> warn you about that somehow.

I always think of Undo in terms of the GoF Command pattern ... when app
actions (maybe literally the GtkActions implementations, maybe not) are
undertaken, they append sufficient state to an app-wide undo list.  These
objects implement a trivial interface for undo/redo.  That implementation
perhaps involves:

- detecting object freshness (the transaction is dirty, I don't want to
automatically undo)

- switching the UI view to the place the undo is about to be performed

- actually mutating the object/UI.


I think we should continue with some user-focused use-cases, rather than
thinking about the transaction log/QOF and some particular solution.

Use Case 0: The user mis-enters a credit/debit cell and wants to undo.
  - need to enter the pre/post values for the cell.

Use Case 1: The user realizes they just undid the correct value, and wants
to redo.

Use Case 2: The user realizes they just entered the last 3 transactions in
the wrong register.  For some reason, they don't want to cut/paste the
transactions, but want to undo them one by one.
  - should the change to each cell of the txns be undone separately?
  - when does the user undo a "txn entry" vs. a "xfer cell edit"?

Use Case 3: Mis-import.

Use Case 4: Invoice creation/rollback.

Use Case 5: SX frequency and start-date change.

[...]


FWIW, I think the first 2 use cases solve most users immediate needs for
undo.  I'd rather solve those two specifically than have a high-risk
change that solves some undefined general problem.


I'm pretty sure that all more complex use-cases will require UI/app
involvement to delineate the quanta of operation to be undone.  There's
probably some application support in terms of keeping a stack of this
context, so import can push IMPORT_BEGIN, import account creation can add
ACCOUNT_CREATE, transaction creation can add TXN_CREATE, ... then the
import can pop off a coherent entity.

Perhaps it's possible to leverage the transaction log for some of that so
we're not reinventing that part.  Say, the "txn_create" undo state is just
a pointer to "the txn log" (note that it's not even an object in memory,
so there's a lot of hand-waving here).  But given the txn log doesn't
cover everything, there's still call for a app-level "undo operations
list".

-- 
...jsled
http://asynchronous.org/ | a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [Inquiry]GNUCash SoC - Implementing Undo

[Josh Sled]

On Wed, March 28, 2007 2:51 pm, Derek Atkins wrote:
> See, I disagree.  I consider a gnucash Book (set of accounts) to be the
> same
> as a gnumeric (or Excel, or OOo) spreadsheet/set-of-workbooks.  Each
> account
> is akin is a single workbook, but it's really the set of accounts (and
> other ancillary data) all shared within the same book that's one data
> file.

Right.  In the same way that a chart might be visual presented on one
worksheet, it could contain content from any worksheet ... the scope of
the application is the entire workbook.  In the same way, the registers
are simply "views" of all the account/transaction/split state, as are the
reports.

-- 
...jsled


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Again font size when printing (reporting system help!!!)

[Josh Sled]

On Thu, March 29, 2007 5:02 am, two old wrote:
> It sounds like a challenge. Is there a place where I can read some of the
> discussion about the reporting system and the thoughts the dev have?

I think the IRC logs contain some of that, though we've not talked about
it formally much.  Over the years, I there are a few aspects that we agree
on:

- the reports should not have scheme scripts emitting HTML (i.e.,
"(simple-format #f "")" or even the "(gnc:html-p-element
paragraph-content)"  form we have now, but instead have a script that
generates the report content, then applies it to a templated HTML file.

- we should modernize our use of the printing libraries, especially as
it's moved into gtk in recent times; some of this is already in progress.

- (maybe optionally) allowing gecko would get a capable HTML rendering
engine, importantly supporting CSS for both display and printing.  As yelp
already defaults to dep'ing against firefox/gecko, this shouldn't be a
huge burden, but I understand that this is a problem for some people.  I'm
not sure that we care or have time to support both gecko and gtkhtml,
however.


I could add more detail, but I'm not sure what you're after, exactly.

(We should probably limit followups to gnucash-devel.)

-- 
...jsled
http://asynchronous.org/

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New reporting system (Re: Again font size when printing)

[Josh Sled]

On Thu, March 29, 2007 3:16 pm, two old wrote:
> First I agree a script should output content to a HTML template. The
> template would secure the way my invoices or reports look on every update
> of GnuCash or even an update of the script.

There's a separate set of concerns about customizing reports.  If we
install a revised report as a script + template, and you customize the
template in the install location, it'll still get over-written at upgrade
time.  There are use-cases for both customizing only the template, and
more so customizing the whole report (and likely the template).

In my experience -- particuarly: customizing bugzilla both before and
after they introduced explicit UI templates -- it can be almost as hard
either way.  Effort is required to revise a report in a way that
customized templates are guaranteed to work going forward.  Most likely,
one wants to enhance the report, and thus the template, which will to some
degree invalidate the customized templates as well.

It's a pretty standard problem, so I'm not sure that we should do anything
more than make it: a/ easier to customize the reports and templates, b/
encourage those customizations to be conditional/config-driven and c/
encourage contribution and thus our re-distribution.  Basically: remove
the reasons why individuals users need to have a customized/non-installed
report that can be overwritten or invalidated.


> If we can make a script that put content into a HTML template and then
> launch a web-browser to view and/or print it, this would be a huge step
> forward.

That's an interesting idea ... I'm not sure that it's the best user
experience, though, in terms of the interactive refinement of the standard
reports... where you change the date range, change the graph parameters,
and don't really want to see another spawned browser instance.  Moreover,
we do support hyperlinking strings (and historically plot/graph elements)
with other GnuCash interface elements like accounts registers and
customers.  In that case, you even more so want the browser embedded for
practical/integration concerns.

But if we do embed or use a browser component to which we can offload most
of the heavy lifting of printing, we should leverage that.


> Besides that, step one can be developed without interfering with the
> printing libraries as they are now. I think ...

The printing libraries are changing, so we do need to modify gnucash's use
of them to stay "current" with our dependent libraries.  The reports are
the major consumer of printing services in GnuCash, but there are others.


> So first of all I'm looking for an understanding of how this
> printing/reporting/scripting business essentially works. I understand C
> but I know nothing of Scheme. Nevertheless maybe I can make a start

For the existing code, there is some documentation in the source tree; in
short...

The report (a scheme script) is evaluated; it calls on the
gnucash-provided reporting system to install itself into the report list
and menu.  When the menu item is invoked, a report-defined callback is
called to generate a (html) document, which is then rendered in the
gnc-plugin-page-report window, using gtkhtml.  The report also defines an
operation generator (another callback function), which is used to create
the report options UI; when Apply (or Ok) is pressed in the options
dialog, the old document is thrown away and the report's rendering
callback is re-run.

-- 
...jsled
http://asynchronous.org/

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New reporting system

[Josh Sled]

On Fri, March 30, 2007 2:53 pm, two old wrote:
> if custom script exist -> execute ([user dir]/script)
> else use standard script.
>
> if custom template exist -> use it ([user dir]/template)
> else use standard template

It's simpler to always just have the user create a custom report, which is
a copy of the existing report.  If they care to revise the script,
template, both (, or neither), then that's their prerogative.  But the
only option should be to create a new whole report.

Also, it's simpler to require all custom reports have a different
name/identity than the "standard" one.  So it's not so much "invoke
 and use the override if it exists", but "invoke "
and/or "invoke ".


> switch (option-browser)
> case internal browser:
> case external browser:

The reports would need to target the LCD of functionality between the
browsers (internal and external[s]) for most of their work, and the
reports do expect to be able to use gnucash-specific URLs to open GnuCash
resources.  We can't support using an external browser exclusively for
report content.

The option to Export should (continue to) exist, and we should probably
add a "... and launch browser" checkbox on the Export dialog.  But it
bears noting that preparing a report for export is different than
preparing a report for internal viewing.  Specifically, the graphs and
gnucash-specific URLs need to be handled very differently.  Also, a
different printing stylesheet may want to be used (though this might be
combined with a media=screen stylesheet).  Generally, an Exported report
needs to be more self-contained and less gnucash-coupled than a normal
report can get away with.

I think our best bet is to have a more capable internal browser (gecko),
and raise the level of reports to support its features for rendering,
formatting and printing.  Frankly, I don't think it's an unreasonable
dependency for a "top of the stack" desktop app.  Note that other parts of
gnome (yelp and epiphany, maybe devhelp indirectly via yelp) already
depend on it, so we can safely assume that it will be available for "GNOME
desktops".

I'm aware of two objections to a dep on firefox: political and technical. 
AFAIUI most political/freeness objections around firefox concern branding
and graphics, not the core rendering and browser component.  The technical
objections are mostly package-management concerns.  I'm aware that certain
Gentoo users don't want to have to build all of mozilla/firefox, and the
binary distribution can't be used in a development context.  But these are
distribution concerns, really, and can be resolved independently.


> In my opinion the individuals will customize the script/template, this is
> a fact. Therefor you have to define the restrictions rather then program
> for every eventuality.

The goal isn't to eliminate the reasons why people need customized
reports, but to minimize them.  If the common use-case is to add a logo
into an Invoice, then that should be a first-order configuration option of
the standard Invoice report.  If there's some more special-case concern,
then it's probably valid for the user to have a customized report.


As you've expressed, your goal is nicely-printed invoices.  Here are the
problems between here and there:

- the existing report is hard to customize (generally true...)

- the existing HTML engine cannot represent basic modern formatting
features (HTML > v3, CSS at all)

- HTML element creation via the reporting infrastructure only knows to
emit basic HTML 3 constructs.

- exporting is done *through* GtkHTML, which will munge any "complex"
HTML+CSS embedded in the output.

This last point is important, because it means we can't even have the
current reports generate "modern" HTML+CSS for export that gtkhtml could
display in a degraded capacity.

One more direct solution would be to have Export not use gtkhtml, but
instead to serialize the original report-generated document, which could
be enhanced to emit HTML 4 + CSS, and maybe have a "downsampler" between
that document and the input to GtkHTML.  There's a fair amount of work
there.


All that being said, it's not just a case of having an external browser,
but of some substantial changes to the way reports are architected.  I'm
hoping to detail how I think that should work in the coming months.

-- 
...jsled
http://asynchronous.org/


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

gconf errors with r15774

[Josh Sled]

I'm seeing the attached gconf-related criticals after `svn up`ing to
15774 and `make install`ing.  I also get the "Cannot find default
values" dialog on startup.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]
[EMAIL PROTECTED] [~/stuff/proj/gnucash/src-trunk]$ !/
/opt/gnc/svn/bin/gnucash


This is a development version. It may or may not work.
Report bugs and other problems to [EMAIL PROTECTED]
You can also lookup and file bug reports at http://bugzilla.gnome.org
The last stable version was GnuCash 2.0.5
The next stable version will be GnuCash 2.2

* 18:22:38  CRIT  gconf_client_add_dir: assertion `gconf_valid_key 
(dirname, NULL)' failed
* 18:22:38  CRIT  ltable_insert: assertion `gconf_valid_key(where, 
NULL)' failed
* 18:22:38  CRIT  gconf_client_add_dir: assertion `gconf_valid_key 
(dirname, NULL)' failed
* 18:22:38  CRIT  ltable_insert: assertion `gconf_valid_key(where, 
NULL)' failed
* 18:22:38  WARN  failed to load gnc-backend-postgres from 
/a/opt/gnc/svn/lib/gnucash
* 18:22:47 MESSG  loading system configuration
* 18:22:47 MESSG  loading user configuration
* 18:22:47 MESSG  loading auto configuration
* 18:22:47 MESSG  loading saved reports
* 18:22:47 MESSG  loading stylesheets
Found old maxfiles: 4
Setting maxfiles: 4

Found old file 0: /home/jsled/documents/finances/gnucash/books-2006.gnc
Setting file0: /home/jsled/documents/finances/gnucash/books-2006.gnc

Found old file 1: 
/home/jsled/stuff/programming/projects/gnucash-budget/misc/devel-data-files/2001-books.gml2
Setting file1: 
/home/jsled/stuff/programming/projects/gnucash-budget/misc/devel-data-files/2001-books.gml2

Found old file 2: /home/jsled/documents/finances/gnucash/books-2004.gnc
Setting file2: /home/jsled/documents/finances/gnucash/books-2004.gnc

Found old file 3: /home/jsled/tmp/coa
Setting file3: /home/jsled/tmp/coa

* 18:22:47  CRIT  gconf_client_add_dir: assertion `gconf_valid_key 
(dirname, NULL)' failed
* 18:22:47  CRIT  ltable_insert: assertion `gconf_valid_key(where, 
NULL)' failed
* 18:22:47  CRIT  gconf_client_add_dir: assertion `gconf_valid_key 
(dirname, NULL)' failed
* 18:22:47  CRIT  ltable_insert: assertion `gconf_valid_key(where, 
NULL)' failed
Found Finance::Quote version 1.11
* 18:22:49 MESSG  Found Finance::Quote version 1.11
/home/jsled/documents/finances/gnucash/books-2006.gnc:31: element gnc-v2: 
Schemas validity error : Element 'gnc-v2': No matching global declaration 
available for the validation root.
/home/jsled/documents/finances/gnucash/books-2006.gnc:31: element gnc-v2: 
Schemas validity error : Element 'gnc-v2': No matching global declaration 
available for the validation root.
/home/jsled/documents/finances/gnucash/books-2006.gnc:31: element gnc-v2: 
Schemas validity error : Element 'gnc-v2': No matching global declaration 
available for the validation root.
* 18:22:49  INFO  [gnc_post_file_open] 
logpath=/home/jsled/documents/finances/gnucash/books-2006.gnc
* 18:22:50 DEBUG  sx named [MORTGAGE SERVICE CENTER Bill 
Payment]
* 18:22:50 DEBUG  parsed from freqspec [Every month 
beginning 01/24/1]
* 18:22:50 DEBUG  setting recurrence [Every month 
beginning 01/24/1] start date to [01/24/2006]
* 18:22:50 DEBUG  sx attribute name[version] value[1.0.0]
* 18:22:50 DEBUG  sx named [NetFlix]
* 18:22:50 DEBUG  parsed from freqspec [Every month 
beginning 01/19/1]
* 18:22:50 DEBUG  setting recurrence [Every month 
beginning 01/19/1] start date to [01/19/2006]
* 18:22:50 DEBUG  sx attribute name[version] value[1.0.0]
* 18:22:50 DEBUG  sx named [CUBESOFT COMMUNICATION]
* 18:22:50 DEBUG  parsed from freqspec [Every month 
beginning 01/18/1]
* 18:22:50 DEBUG  setting recurrence [Every month 
beginning 01/18/1] start date to [01/18/2006]
* 18:22:50 DEBUG  sx attribute name[version] value[1.0.0]
* 18:22:50 DEBUG  sx named [(cubesoft) foreign txn fee]
* 18:22:50 DEBUG  parsed from freqspec [Every month 
beginning 01/18/1]
* 18:22:50 DEBUG  setting recurrence [Every month 
beginning 01/18/1] start date to [01/18/2006]
* 18:22:50 DEBUG  sx attribute name[version] value[1.0.0]
* 18:22:50 DEBUG  sx named [Spoke Salary]
* 18:22:50 DEBUG  parsed from freqspec [Every month 
beginning 01/16/1 + Every month beginning 01/30/1]
* 18:22:50 DEBUG  setting recurrence [Every month 
beginning 01/16/1] start date to [01/16/2006]
* 18:22:50 DEBUG  setting recurrence [Every month 
beginning 01/30/1] start date to [01/30/2006]
* 18:22:50 DEBUG  sx attribute name[version] value[1.0.0]
* 18:22:50 DEBUG  sx named [DirecTV]
* 18:22:50 DEBUG  parsed from freqspec [Every month 
beginning 01/29/1]
* 18:22:50 DEBUG  setting recurrence [Every month 
beginning 01/29/1] start date to [01/29/2006]
* 18:22:50 DEBUG  sx attribute name[version] value[1.0.0]
* 18:22:50 DEBUG  sx named [SOVERNETBill Payment]
* 18:22:50 DEBUG  parsed from freqspec [Every month 
beginning 01/19/1]
* 18:22:50 DEBUG  setting recurrence [Every month 
beginning 01/19/1] start date to [01/19/2006]
* 18:22:50 DEBUG  sx attribu

Re: gconf errors with r15774

[Josh Sled]

On Mon, 2007-04-02 at 19:57 -0400, David Hampton wrote:
> I see no such errors.  Can you use gdb to see what directory name gconf
> is complaining about?

I should have done this before reporting, but after touching files in
 and , the problem has gone away.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: r15777 - gnucash/trunk/src/gnome - Bug#343795: Be explicit about number of months so auto-decimal-point doesn't bite us. Patch from Jerry Quinn .

[Josh Sled]

On Tue, 2007-04-03 at 07:44 -0400, Derek Atkins wrote:
> Should this be slated for backport to 2.0?

It can be.  Please review.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GObject in GC: A new Library

[Josh Sled]

On Tue, 2007-04-03 at 23:26 -0700, Daniel Espinosa wrote:
> Of course, reach this state in the current GC implementation will take
> a lot of time and code. That's way I'm considering to create a pure
> GObject library that wraps the actual one. 

I can't see how another layer of abstraction will result in less time or
code spent than making a set of straightforward changes to the
gnucash/qof sources.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GObjectification status

[Josh Sled]

On Wed, 2007-04-04 at 23:34 -0400, Derek Atkins wrote:
> Take a look at the gobject-engine-dev-warlord branch.  I'd
> like to merge this back into trunk this weekend unless I
> hear objections.

No objection here; this looks good.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX: Created Transactions not removed from SLR list

[Josh Sled]

On Sun, 2007-04-08 at 10:55 -0400, Volker Englisch wrote:
> Looking through my list of scheduled transactions it appears that all of 
>   these transactions that were incorrectly set to January 1st were 
> originally entered to be scheduled annually.  Since the option to 
> schedule a transaction annually doesn't exist anymore (at least I think 
> the older version allowed you to schedule annually) they got converted 
> to 'monthly (x12)' and this 'conversion' may have changed the actual 
> date to Jan 1st.

There were some date computation problems in the original versions of
the conversion code.  Can you re-try with your clean stable/2.0
datafile, or maybe a backup?


> Along these lines, when I click the up/down arrow in the 'Edit Scheduled 
> Transaction' window to increment/decrement the recurrence frequency for
> 'Every  N  months'
> it seems that all but the 'weekly' option increments the value by two 
> instead of one.

Huh.  That's weird.  It's certainly not consistent.  It's almost like
the button "sticks" every once in a while – both up and down – and moved
the value 2 or 3 units at a time.


> The display of this option is centered (?) under the 'Start Date' field 
> for most options except for the 'Semi-monthly', where it is left aligned 
> with the fields in that block.

Noted.


> Also, the window that comes up to enter/edit a scheduled transaction 
> extends the width of the screen and there is a new button at the upper 
> right-hand corner of the calendar name 'View' which doesn't do anything 
> at the current time.

To the right of the "View:" label there should be a combobox with
options for changing the view of the dense cal (1,2,3,4,6,12 months).
No?  Are you use src/gnome-utils/ was cleanly re-built and installed?


> Please let me know if you'd like me to provide additional information 
> and/or screenshots.

BTW, any opinion about the new/tabbed SX editor?

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: umlauts in online help

[Josh Sled]

On Tue, 2007-04-10 at 15:14 +0200, Sebastian Menge wrote:
> Am Dienstag, den 10.04.2007, 08:59 -0400 schrieb Derek Atkins:
> > Oh, it's probably a UTF vs. ISO issue.
> > Which URL are you reaching?
> 
> http://www.gnucash.org/docs/v2.0/de_DE/gnucash-help/help.html
> http://www.gnucash.org/docs/v2.0/C/gnucash-help/help.html
> 
> Even in the english version there are artefacts in the navigation parts.

The content is UTF-8.  There is a  in the HTML saying as such.  I
can't seem to get apache on www.gnucash.org to serve the content as
UTF-8, however.


> >From my experience the cause is often mixing iso and utf in one file.
> e.g. template=iso and content=utf, or script=iso, content=utf.
> 
> vim is nice to switch encodings (:set fileencoding and :help encodings).

If you're suggesting that we open each file in `vim` and re-write its
encoding, I'd suggest that `iconv` is scriptably easier, and we could
just re-generate the content with a non-conflicting encoding.  I'd
rather we just served UTF-8 properly.

Firefox also has a "Character Encoding" option, here in the View menu.


This problem's has been happening for a while, but in part because
making changes to www.gnucash.org is painful, it's gone unresolved.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[Fwd: Re: umlauts in online help]

[Josh Sled]

Hey Linas...

I can't seem to use .htaccess files in the website to control the
Content-Type of the served content.  Can you please modify the
server-wide config to return UTF-8 as a default, rather than ISO-8859-1?

Thanks...

 Forwarded Message 
> From: Josh Sled <[EMAIL PROTECTED]>
> To: Sebastian Menge <[EMAIL PROTECTED]>
> Cc: Derek Atkins <[EMAIL PROTECTED]>, gnucash-devel@gnucash.org
> Subject: Re: umlauts in online help
> Date: Tue, 10 Apr 2007 09:22:59 -0400
> 
> On Tue, 2007-04-10 at 15:14 +0200, Sebastian Menge wrote:
> > Am Dienstag, den 10.04.2007, 08:59 -0400 schrieb Derek Atkins:
> > > Oh, it's probably a UTF vs. ISO issue.
> > > Which URL are you reaching?
> > 
> > http://www.gnucash.org/docs/v2.0/de_DE/gnucash-help/help.html
> > http://www.gnucash.org/docs/v2.0/C/gnucash-help/help.html
> > 
> > Even in the english version there are artefacts in the navigation parts.
> 
> The content is UTF-8.  There is a  in the HTML saying as such.  I
> can't seem to get apache on www.gnucash.org to serve the content as
> UTF-8, however.
> 
> 
> > >From my experience the cause is often mixing iso and utf in one file.
> > e.g. template=iso and content=utf, or script=iso, content=utf.
> > 
> > vim is nice to switch encodings (:set fileencoding and :help encodings).
> 
> If you're suggesting that we open each file in `vim` and re-write its
> encoding, I'd suggest that `iconv` is scriptably easier, and we could
> just re-generate the content with a non-conflicting encoding.  I'd
> rather we just served UTF-8 properly.
> 
> Firefox also has a "Character Encoding" option, here in the View menu.
> 
> 
> This problem's has been happening for a while, but in part because
> making changes to www.gnucash.org is painful, it's gone unresolved.
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [Fwd: Re: umlauts in online help]

[Josh Sled]

On Tue, 2007-04-10 at 12:04 -0500, Linas Vepstas wrote:
> On Tue, Apr 10, 2007 at 09:39:13AM -0400, Josh Sled wrote:
> > Hey Linas...
> > 
> > I can't seem to use .htaccess files in the website to control the
> > Content-Type of the served content.  
> 
> Hmm. Looks to me like its in svn, so it should be accessible to you...

They're there, yes; they just don't seem to have any effect.


> > Can you please modify the
> > server-wide config to return UTF-8 as a default, rather than ISO-8859-1?
> 
> I just did. Should be working now.

> Welcome.

Great!  Thanks again! :)


The translations aren't correct, being encoded in iso-8859-{1,15} ...
but that's pretty easily fixable.  I might not be able to get to it
until the evening, though.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX: Created Transactions not removed from SLR list

[Josh Sled]

On Wed, 2007-04-11 at 00:56 -0400, Volker Englisch wrote: 
> I've tried an older data file but saw the same problem.  However, the 
> file may not have been old enough.  I'll go searching on my backups to 
> find a file that's definitely old enough and try again as soon as I have 
> a little more time (this weekend maybe).

I went through a small number of random SX-containing datafiles created
with 1.8 I had lying around, and they seemed to convert the SXes
correctly.  I'll still need to do some more exhaustive testing, but the
cases I've thrown at it work so far.


> After your remark I tried to rebuild gnucash from scratch with a fresh 
> SVN checkout.  Unfortunately, I'm unable to build GC now because of a 
> compile error:
> 
>   gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DG_LOG_DOMAIN=\"gnc.core-utils\" 
> -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DORBIT2=1 
> -pthread -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include 
> -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 
> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
> -I/usr/lib/glib-2.0/include -Werror -Wdeclaration-after-statement 
> -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -g -O2 -Wall -Wunused 
> -Wmissing-prototypes -Wmissing-declarations -MT swig-core-utils.lo -MD 
> -MP -MF .deps/swig-core-utils.Tpo -c swig-core-utils.c  -fPIC -DPIC -o 
> ..libs/swig-core-utils.o
> cc1: warnings being treated as errors
> swig-core-utils.c: In function '_wrap_g_find_program_in_path':
> swig-core-utils.c:1215: warning: unused variable 'gswig_list_p'
[...]

I've just committed r15872, which reverts r15855, which removed the
"-Wno-unused" flag from configure.in.  On #gnucash some of us had
convinced ourselves that swig-1.3.31 – which doesn't generate code that
barfs with -Wunused – was required to build trunk, but we've come to
understand that's not true.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GObject in GC implementation Plan

[Josh Sled]

On Thu, 2007-04-12 at 09:24 -0400, Derek Atkins wrote:
> "Daniel Espinosa" <[EMAIL PROTECTED]> writes:
> > I have some ideas, to add this feature:
> >
> > - Add a GdaDataModel interface to QofCollection object
> > - Try to create a GdaServerProvider for the actual XML file
> > - Create a wrapper library to allow other applications access the XML
> > file (or even the GDA backend) using GDA
> 
> Again, I dont think we need any of this, because we already HAVE
> all of this.  (well, except for GDA, but Phil Longstaff is working
> on that in the gda-dev branch).

We don't have any of this, as it's described.  Phil is working on
GnuCash using GDA, not wraping GnuCash as a GDA data-source.


I don't think the QofCollection or the "XML file" is the right thing to
expose, exactly ... in all integration cases, I think there's a set of
application constraints that need to be enforced; binding to the XML or
raw data is insufficient.  Note that this doesn't preclude some use of
XML as the integration point.


I can see the abstract utility of having GnuCash data exposed via GDA,
but I note that no one has asked for that specifically ... it feels a
bit like a solution in search of a problem.  There are some known
integration requests (problems) that it could solve, so maybe it works
out, but the focus should be on solving the problems.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GObject in GC implementation Plan

[Josh Sled]

On Wed, 2007-04-11 at 18:27 -0500, Daniel Espinosa wrote:
> See other projects use Anjuta to create GObject templates, and you'll
> see what I mean.

Daniel, you continue to indicate that you believe that we don't
understand what a "proper" gobject looks like.

Evidence that we do can be found in:

- GncPlugins and GncPluginPages, which use gobject pretty "fully".

- the GncTreeModel abstract util class, used by the GncTreeModelAccount 
  and GncTreeModelPrice, as well as the corresponding Views.

- the GncDenseCal widget and it's model interface, store 
  implementation, and adapter-implementation.  Much – but not all – of 
  the new SX code, as well.

- The gobject refcount-debugging code.

- `find src -iname '*.c' |xargs grep -Hn "g_type_register_static" | grep 
"G_TYPE_OBJECT"`

These might not use every feature of gobject, but sometimes there's no
compelling reason to use every feature of gobject; properties come to
mind.  This is especially true with an existing code base such as
GnuCash.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GObject in GC implementation Plan

[Josh Sled]

On Thu, 2007-04-12 at 17:42 -0500, Daniel Espinosa wrote:
> 2007/4/12, David Hampton <[EMAIL PROTECTED]>:
> > On Thu, 2007-04-12 at 14:06 -0500, Daniel Espinosa wrote:
> > > I can understand why you feel that; the reason is that I don't think
> > > that convert QOF to GObject will be a good idea because its
> > > implementation doesn't allow it, you'll never have a full GObject
> > > system if you insist to use QOF.
> >
> > You keep making that statement, but you haven't explained what you mean
> > by it.  Why can't we eventually migrate to a full GObject, what will be
> > missing, and what will that mean to the project?  Please either explain
> > yourself, or stop spreading what (at this point) I can only call FUD.
> >
> > David
> 
> I don't want to create FUD, sorry. But you're right, I need to explain
> in more details:

I will point out that nothing you said or the responses you've received
indicate that:

- gnucash can never have a full GObject system
- anyone is insisting to use QOF (in its current form)
- anyone does not want to migrate to GObject features

The issue has always been one of timing and planning, that the changes
are made as a set of small, stable, understandable, auditable changes.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GObject in GC implementation Plan

[Josh Sled]

On Fri, 2007-04-13 at 12:04 -0500, Daniel Espinosa wrote:
> I insist to wrap QOF and step by step migrate QOF into a new pure
> GObject implementation (move the code from QOF to the new)

I still don't think adding another layer will help, and in fact I think
it will make the process harder.

It's quite clear how to make small, measured changes in the existing
QOF/GNC objects toward using gobject correctly and completely.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: ChangeLog policy needed (was: Release problems)

[Josh Sled]

On Sun, 2007-04-15 at 12:58 +0200, Christian Stimming wrote:
> http://lists.gnucash.org/logs/2007-02-01.html#T09:21:30 ; however, the manual 
> ChangeLog contains some (very few!) texts that do not appear in the 
> auto-generated one. For that reason the IRC discussion ended with no result 
> and we still have both the auto-generated and the manual ChangeLog of 2006. 

I (again) suggest that we identify the different messages and update the
svn:log, so that a svn-generated 2006 ChangeLog will have parity with
the manual one.  I will take it as a task to identify and copy these
messages, hopefully later today.


> As for 2007 and the future, we need to decide:
> - Which branches should be used by the ChangeLog.svn rule?

All those that are merged into the sources being released / trunk.


> - Which filename should the auto-generated Changelog have? I propose simply 
> ChangeLog.

Yes.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

bug day, string freeze

[Josh Sled]

In #gnucash yesterday, hampton made an excellent suggestion that we
should work to reduce the number of open bugs before the string freeze.

Not necessarily related, but I think it would be interesting to have a
proper Bug Day early-ish in the release schedule.

As per the schedule at ,
I propose:

- pushing the string freeze out to the 2.1.2 release of May 12th.

- scheduling two bug days, off-schedule with the releases.
  Specifically, on:
  - Sat Apr 21
  - Sat May 5

Thoughts?

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX: SLR Problem when changing instance state

[Josh Sled]

On Sat, 2007-04-14 at 17:06 -0400, Volker Englisch wrote:
> When I'm running Since Last Run (GC r15872 on FC5) the split description 
> changes every time I change the instance state.  Please see the snapshot 

Ick.  Should be fixed in 15899.  Thanks!

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX: Created Transactions not removed from SLR list

[Josh Sled]

On Thu, 2007-04-12 at 00:05 -0400, Volker Englisch wrote:

> /home/venglisc/g2-test/test1.8.gc:199386: namespace error : Namespace 
> prefix fs on day is not defined
>  20

I've seen this as well on 1.8 files without namespace decls.  I'm not
quite sure what happened – if anything – with the code to handle old XML
files that didn't have namespaces declared ... maybe libxml2 is just
getting stricter.  In any case, this'd be nice to fix before 2.2.


> it did open the data file but all of my transactions scheduled annually 
> were converted to a January date.  The day of the month is correct 
> though.  For instance,
> March   23rd is converted to January 23rd,
> June15th is converted to January 15th,
> October 1st  is converted to January 1st, ...
> The monthly transactions are converted correctly.

Ah, yeah, I see now... I broke this.   I was trying to be crafty. :(
I hope to have a fix in early this week.


> Coming back to the View button in the Edit Scheduled Transactions window 
> this is still not doing anything for me even with the latest version 
> using a complete new checkout from SVN.

This is really weird.  What version of GTK?  Is there anything on the
console when you load a dense cal (any of them; the SX list tab is
sufficient)?


> The one thing that I'm not crazy about are the two drop down menus for 
> Frequency and Start Date of the Frequency tab spanning over the entire 
> width of the window when the text fills hardly 20% of the width.  Even 
> though this is not new to the tabbed display it probably appears worse 
> now because the layout is not as crowded.

The GncFrequency widget doesn't like to have so much space.  I've a todo
to tweak the layout, here.


> The little window displays when you hover over the calendar of the SXs 
> only adjusts in size to display additional information but it does not 
> shrink.

Fixed in r15900.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GNUcash Tango icon

[Josh Sled]

On Sat, 2006-11-04 at 22:42 +0100, Hylke Bons wrote:
> of the current gnucash icons). So if you like them, they can be used in
> the next release of GNUcash under any free license you'd like. Hope you
> like the icons and keep up the good work!

This is very nice.  I've added these to the source tree in art/tango/.
Thanks! :)


Especially as our other custom toolbar buttons are already in the Tango
style (and hopefully GTK will be as well, soon), I've changed from the
Blue GNU Card to these.  At the same time, I've modified the code to
register the set of default icons at 16x16, 32x32 and 48x48.

The packaging will want to update to use the Tango icon as well ...
probably the SVG version, though.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: calendar proposal WAS: 2.1.0 Release

[Josh Sled]

On Mon, 2007-04-16 at 22:32 -0400, Nathan Buchanan wrote:
> Thoughts? Objections? Suggestions? If this seems like a good idea, I'd like
> to work with everyone who sets the release schedule to get this going.

I don't know why spreading the information out more is going to help.

Please follow the mailing list and
.  There is an RSS feed
of changes in the wiki, though I don't think you can target that page
alone.  Also, coordination in IRC is a good idea.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: bug day, string freeze

[Josh Sled]

On Sun, 2007-04-15 at 19:00 +0200, Christian Stimming wrote:
> Am Sonntag, 15. April 2007 17:48 schrieb Josh Sled:
> > - pushing the string freeze out to the 2.1.2 release of May 12th.
> >
> > - scheduling two bug days, off-schedule with the releases.
> >   Specifically, on:
> >   - Sat Apr 21
> >   - Sat May 5
> >
> > Thoughts?
> 
> Sounds great!

I've updated <http://wiki.gnucash.org/wiki/Release_Schedule#Schedule>
with these dates, and I'll pull together some Bug Day info over the next
couple of days.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: bug day, string freeze

[Josh Sled]

On Tue, 2007-04-17 at 11:30 -0400, Derek Atkins wrote:
> >> - scheduling two bug days, off-schedule with the releases.
> >>   Specifically, on:
> >>   - Sat Apr 21
> >>   - Sat May 5
> >>
> >> Thoughts?
> 
> I'm not sure I have much time on these two days, but I think it's
> a good idea.

I'm thinking of announcing this – at least for the 21st – as 1500 UTC
(11am EDT) to 2200 UTC (6pm EDT).


Is anyone else going to be able to commit to being around, if only for
part of it?  It'd be nice to know if/when I can step out to run errands
during the day. :)

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Bug Day: Sat, Apr 21, 1500-2200 UTC

[Josh Sled]

This Saturday, April 21st, we're going to have the first GnuCash Bug
Day.

Of course, you're welcome to help triage, find, file and even resolve
bugs at any point, but this Saturday we're going to focus on this
explicitly, and would like your time and support to do so.

The primary things to do this Bug Day are:

- join irc://irc.gnome.org/gnucash
- help with any/all of the following
  - testing the 2.1.0 release (or SVN)
  - triage and confirming bugs

Specifically, we need to focus on the areas that the 2.1 code touched
heavily:

- running the whole app on Windows
- reports (core and business)
- check printing
- scheduled transactions: data file reading/writing and UI

Bug Day will be ongoing from 15:00 [1] - 22:00 UTC in #gnucash on
irc.gnome.org ... please join us there! :)


[1] 
http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=21&year=2007&hour=15&min=0&sec=0&p1=0

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX: Created Transactions not removed from SLR list

[Josh Sled]

On Sun, 2007-04-15 at 13:48 -0400, Josh Sled wrote:
> > it did open the data file but all of my transactions scheduled annually 
> > were converted to a January date.  The day of the month is correct 
[...]
> Ah, yeah, I see now... I broke this.   I was trying to be crafty. :(
> I hope to have a fix in early this week.

Fixed in r15929; please let me know if not.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Welcome to our 2007 Google Summer of Code Students

[Josh Sled]

On Wed, 2007-04-18 at 22:24 -0400, Derek Atkins wrote:
> Let me be the first to congratulate you on being selected.

Welcome and congrats!  :)

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SX: Created Transactions not removed from SLR list

[Josh Sled]

On Thu, 2007-04-19 at 00:47 -0400, Volker Englisch wrote:
> When I enter a value for a scheduled transaction the transaction is 
> being created in the register (and in the review register) but both 
> splits are empty:

This is fixed in r15940.  Also, clicking OK in the SX editor no longer
results in a crash. :/

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Bug Day: Sat, Apr 21, 1500-2200 UTC

[Josh Sled]

On Wed, 2007-04-18 at 18:17 -0400, Josh Sled wrote:
> This Saturday, April 21st, we're going to have the first GnuCash Bug
> Day.

Thanks to the devs; it seemed that we had a bit more focus and a
more-active-than-normal channel today.  I was hoping that we'd get a bit
more end users firing up 2.1.0, but maybe next time...


I decided to attack the "Bugs without a response" list [1], and got it
down from 49 entries to 14.  Most of the 14 remaining are in areas
(stocks, HBCI, Lots, Business features) that I'm not well-positioned to
reproduce.  Maybe the relevant devs/users can take a look; it would be
great it we could get that number to zero and keep it there, of course.


[1] 
http://bugzilla.gnome.org/buglist.cgi?query=product:GnuCash+responders:0+severity!=enhancement+reporter!=developer

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

2.1.x and allow_file_incompatability

[Josh Sled]

There are two places we use the gconf
key /apps/gnucash/dev/allow_file_incompatibility:

- Scheduled Transactions (FreqSpec->Recurrence)
- ROOT Account Group

I propose that we flip the default for these two immediately before the
2.1.2 release.  Thus, starting with 2.1.2, files would no longer be
backward compatible.

I suppose another way we can go is to /strongly encourage/ people to
manually set the gconf key, but that just seems to delay the inevitable.
Also, at some point I actually need to remove the FreqSpec code, which
will require the flag to be set.  I'd rather do it sooner than later.


Thoughts?  Objection?

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel