Re: [GNC-dev] Gnome HIG

[David Hampton]

On Fri, 2018-09-14 at 14:57 -0400, David T. via gnucash-devel wrote:
> Hello,
> 
> In the course of another arduous and lengthy thread, the question of
> the Gnome HIG came up. I attach the text in question below.
> 
> My question is whether the Guide needs changing at 1.2.1, where it
> says:
> Easy to Use Menus: GnuCash menus conform to the GNOME Human Interface
> Guidelines. This means that they are simple and similar in appearance
> to many other GNOME applications. 
> 
> Is this statement inaccurate? Should it be removed?

I spent a fair amount of time making sure that it was accurate when it
was written (over a decade ago).  As John mentioned elsewhere, the HIG
has changed over time and Gnucash hasn't, so it should probably be
removed.

David

> David
> 
>  
> Previous discussion:
> 
> I don't know about allowing room for it, but it's pretty far in the
> future because we still have too many Gnome dependencies in the core
> and too many MVC violations to be able to implement a different
> toolkit.
> 
> Regards,
> John Ralls
> 
> 
> > On Sep 11, 2018, at 10:23 AM, Adrien Monteleone <
> > adrien.montele...@lusfiber.net  > adrien.montele...@lusfiber.net>> wrote:
> > 
> > Then I misunderstood some earlier discussions about the UI, at
> > least with respect to Linux. What toolkit is envisioned to be used?
> > What layout principles? Or are those questions so far in the future
> > as to not be worth spending time allowing room for?
> > 
> > Regards,
> > Adrien
> > 
> > > On Sep 11, 2018, at 12:18 PM, John Ralls  > > > wrote:
> > > 
> > > 
> > > 
> > > > On Sep 11, 2018, at 10:09 AM, Adrien Monteleone <
> > > > adrien.montele...@lusfiber.net  > > > adrien.montele...@lusfiber.net>> wrote:
> > > > 
> > > > 
> > > > 
> > > > > On Sep 11, 2018, at 8:13 AM, David T. via gnucash-devel <
> > > > > gnucash-devel@gnucash.org >
> > > > > wrote:
> > > > > 
> > > > > In other words, unless there is a change in function, there
> > > > > is no need to change the functional description. It seems to
> > > > > me that putting text that doesn’t change into code is
> > > > > essentially a one-time process. Not necessarily easy, but
> > > > > once completed, not particularly obtrusive. Putting the
> > > > > functional description into code has the added benefit,
> > > > > perhaps, of alerting developers to the fact that if they
> > > > > change a feature, the description (right there in the code)
> > > > > needs an update as well.
> > > > 
> > > > While the principles might not change, or even the name/label
> > > > of certain buttons, the UI layout (where those buttons are, the
> > > > fact that they are buttons instead of menu entries, etc.) will
> > > > very likely change as the Gnome HIG is more faithfully
> > > > implemented. But those code changes shouldn’t affect anything
> > > > generally in the Guide, and should auto update the context help
> > > > if it is drawn from the code itself. If not, then consider that
> > > > attempts to corral GnuCash within the confines of the Gnome
> > > > HIG, will produce such changes you’re thinking won’t happen.
> > > 
> > > Why do you think we're going to "more faithfully implement" the
> > > Gnome HIG? One of our long-term goals is to remove our Gnome
> > > dependencies. 
> > > 
> > > Regards,
> > > John Ralls
> 
> 
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

Re: UI Dogtail test harness, Some issues begin to appreas

[David Hampton]

On Sat, 2007-06-09 at 09:54 -0700, ahmad sayed wrote:
> Hi josh
> 
> 1 - There is a dialogs with no title like process payment, which i need 
> to make dogtail detect the existance of the dialog, so This issue could 
> be solved by 2 ways, 
> a - Add Title to this dialog.

Not an option for all dialogs.  Some dialog are explicitly called out in
the HIG as not having a title.

> b - add an accessible description for this widget.
> Both may require Code change.

I thought dogtail could uniquely identify widgets by their name?  Does
it requires a11y descriptions instead?  If so, we should add those
instead of making user visible changes that may or may not go against
the HIG depending up on the particular window.

> 2 - also, Dogtail sniffer as well as my code detect an invisible Cancel 
> Button in dialogs Like Find Customer and others,  anyone explain this 
> behavior, is this a gnucash issue or dogtail issue.

This is a shared dialog.  It shows either a close button or a cancel
button depending upon how the window was instantiated.  I can't tell
from my brief look at the code if this change can happen dynamically as
the user is interacting with the dialog, of if it is staticly set when
the dialog is instantiated.  If the latter, then perhaps the unused
button could be deleted instead of hidden.

David


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

Re: Questions about GObjectification in GnuCash

[David Hampton]

On Fri, 2007-06-01 at 12:05 -0400, Derek Atkins wrote:

> > Does any one know why QofInstance's functions use gpointer instead of
> > QofInstance* ?
> 
> Um, probably because they haven't been fixed, yet?  Yes, they
> should use QofInstance.

The changes I committed were designed after functions like
g_object_get/set/ref/unref that uses the gpointer style of argument
passing.  It made more sense to me, as using a QofInstance parameter
would require casing on every single call to these functions cluttering
up the code, and the casting does absolutely nothing at compile time
except disable compiler checking, same as using a gpointer argument.
The real checks to insure the argument is correct happen at runtime when
the arguments are checked inside of the functions with a call to
QOF_IS_INSTANCE().

> > What about string based type system?
> 
> EVENTUALLY we might want to change this, but again this is
> something that doesn't have to change right away.  Right now
> there's a duplication here, there's the string type name and
> the GObject type name/number.  We would need to change the way
> we define types in QOF before we could completely get rid of
> the string types.

I've looked at this, and its embedded quite deeply in the code.  It can
probably be removed, but it will be tedious work.  I though the effort
too much to do before the release of 2.2.

David


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

Re: Fedora 6.9

[David Hampton]

On Sat, 2007-05-12 at 14:32 -0500, John Newman wrote:
> GnuCash will not load within Fedora Core 6.9. Starts to load and then
> ends without any messages or errors.

I just ran gnucash on my F7 test system without an errors at all.  I
just updated with yum, so I have the very latest of everything.

David


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

Re: GnuCash 2.1.1 Released

[David Hampton]

On Tue, 2007-05-01 at 10:23 -0700, Vladimir Weinstein wrote:
> Filed http://bugzilla.gnome.org/show_bug.cgi?id=434944
> 
> In its infinite wisdom, bugzilla decided that I'm filing a bug  
> against gnome-applets, so someone needs to go and assign it to  
> gnucash maintainers.

Its definitely filed as a GnuCash Register bug.  No idea why it was
assigned to [EMAIL PROTECTED] though. I reassigned it as an
OFX bug and its now assigned to one of the gnucash developers.

David


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

Re: r16015 - gnucash/trunk/src/app-utils - Give the child process a real chance to die before we kill it.

[David Hampton]

On Sat, 2007-04-28 at 12:04 -0400, Andreas Köhler wrote:
 
> -  if (kill_it) {
> +  if (kill_it && !proc->dead) {
>  /* give it a chance to die */
> -g_main_context_iteration (NULL, FALSE);
> +while (g_main_context_iteration (NULL, FALSE) && !proc->dead)
> +  ;

Can this block forever waiting for the process to die?

David



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

Re: r15921 - gnucash/trunk - Move more account properties from the public data structure to a

[David Hampton]

On Sat, 2007-04-21 at 12:22 -0400, Derek Atkins wrote:
> David Hampton <[EMAIL PROTECTED]> writes:
> 
> >  GType gnc_numeric_get_type( void );
> > +#define GNC_NUMERIC (gnc_numeric_get_type ())
> 
> Shouldn't this be GNC_TYPE_NUMERIC?

Yes. I'm fixing it now.

David


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

Re: Extra accounts in template-transactions

[David Hampton]

On Fri, 2007-04-20 at 17:27 -0400, Mike Alexander wrote:

> When did you fix it?  I'm running SVN version 15911 and it doesn't seem 
> to be fixed there.  I deleted all the unreferenced accounts by hand and 
> when I open the SX editor on the file it creates a new root account. 
> The diff of the changes it made is below.  It didn't create a new BANK 
> account, but I didn't actually change anything in the SX editor so it 
> might under other circumstances.
I thought r15674 on 3/3 solved the problem with multiplying unreferenced SX 
accounts.

David



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

Re: Extra accounts in template-transactions

[David Hampton]

On Fri, 2007-04-20 at 15:10 -0400, Mike Alexander wrote:

> The parents of these seem to be the various ROOT accounts above.  Most 
> of these BANK accounts seem to be unreferenced, but some of them are 
> referenced in the transactions later in the template-transactions 
> section.
> 
> I have no idea when these appeared in the file, but they seem like they 
> might be a mistake.  I have 6 scheduled transactions in the file, all 
> of them very simple ones that just pay a bill with a fixed amount from 
> either a checking or credit card account.

I believe I've fixed the bug that caused the extra accounts to be
created.  That doesn't help with eliminating them though.

David


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

Re: bug day, string freeze

[David Hampton]

On Wed, 2007-04-18 at 08:44 -0400, Josh Sled wrote:

> 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. :)

I should be online.

David


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

Re: GObject in GC implementation Plan

[David Hampton]

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


___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: PATCH: convert some routines to take const object pointers

[David Hampton]

On Sat, 2007-04-07 at 14:26 -0400, Phil Longstaff wrote:
> The attached patch modifies some getter routine signatures to convert
> object pointers to const object pointers.

I applied this patch, also in two parts (the const changes and the
begin_edit/commit_edit changes).

David


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

Re: Import prices API

[David Hampton]

On Sat, 2007-04-07 at 16:39 +0200, nospamforas wrote:

> > Also, F::Q itself has an API; it's a plugin architecture so you could plug
> > in your own module.
> >
> > But I have to ask:   why would you want to NOT use F::Q?
> 
> It is of no use to me, for the following reasons:
> 
> (a) All modules do not fit. I would have to write my own one. I checked that 
> thoroughly and repeatedly.

And?

> (b) I don't know perl, and I don't want to dig into it. Time is one issue.

And this affects the gnucash universe how?

> (c) I already wrote my own module a couple of years ago. It was enough then 
> to 
> copy an existing module and change it a little bit. It only took one or two 
> days.
> 
> (d) Now I would have to write another module. This time it is much more 
> complicated and I estimate that I would have to spend a lot of time to learn 
> enough of perl to do it. -- Too much time. 

Its no more complicated now than it was a couple of years ago.

> (e) These modules have to be maintained once in a while. It would be even 
> more 
> inefficient for me to always relearn perl just for that matter.

Yes, and?  All software has to be maintained once in a while, including
whatever software you end up writing to scratch this itch.

> Well, I could write a module to read quotes from a file and write my own 
> program to get those quotes beforehand and write them to a file to be picked 
> up by the module. But I don't like this approach. I would have to install not 
> only Finance::Quote but also the modules it needs just to be able to read 
> quotes from a file. The whole stuff would just need to be present
> 
> It will be much more elegant to directly plug in my own program.

More elegant for you, and you will be the only one who can benefit from
the quote retrieval code you write.  If you write it as a F::Q module
then anyone in Germany who wants to get quotes from that source would
benefit.

> And if the 
> gnucash community would define and freeze an interface,

Its been defined and frozen for years.  Its just not documented.  I
added one extension a couple of years ago. No-one else has touched the
code in a long time.   That said, the current interface probably isn't
going to be around much longer.

> I guess it would help other people as well. But don't get me
> wrong: you don't need to do this just for me.

You're the only person that's asked for this in the six years I've been
involved with gnucash.

I'm planning rewriting this part of GnuCash in the near future so I'll
keep your request in mind, but I'm not promising anything.

David


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

Re: GObjectification status

[David Hampton]

On Thu, 2007-04-05 at 19:16 -0400, Josh Sled wrote:
> 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.

Same here.

David


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

Re: "make check" failure in test-lots

[David Hampton]

On Fri, 2007-04-06 at 02:57 +0200, Andreas Köhler wrote:

> > As of some recent changeset, "test-lots" is now failing dramatically
> > in a SEGV..  I need to head out, but maybe someone could test their
> > recent changes?
> 
> the changeset is likely r15790 as make check starts to fail for me at
> that point in history.

Fixed in r15838.

David



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

Re: gconf errors with r15774

[David Hampton]

On Mon, 2007-04-02 at 18:37 -0400, Josh Sled wrote:
> * 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 

I see no such errors.  Can you use gdb to see what directory name gconf
is complaining about?

David


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

Re: AUDIT: r15635 - gnucash/trunk/src/gnome - Remove extra argument to gtk_list_store_set. Fixes #409758.

[David Hampton]

On Fri, 2007-03-30 at 21:58 +0200, Derek Atkins wrote:
> David Hampton <[EMAIL PROTECTED]> writes:
> 
> > --- gnucash/trunk/src/gnome/lot-viewer.c2007-02-19 22:52:44 UTC (rev 
> > 15634)
> > +++ gnucash/trunk/src/gnome/lot-viewer.c2007-02-19 23:00:24 UTC (rev 
> > 15635)
> > @@ -431,7 +431,7 @@
> >}
> >else
> >{
> > -   gtk_list_store_set(store, &iter, LOT_COL_CLOSE, cbuff, _("Open"), -1);
> > +   gtk_list_store_set(store, &iter, LOT_COL_CLOSE, _("Open"), -1);
> >}
> 
> This can't be backported; there is no list_store here in 2.0
> Can you verify that bug #409758 actually exists in 2.0, and if
> it does I think we need to find another solution to it.

The 2.0 implementation is different, and is correct.  This doesn't need
to be back ported.  Sorry for the noise.

David


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

Re: [PATCH] Override GConf path for development separation

[David Hampton]

On Thu, 2007-03-22 at 21:21 +, James Radley wrote:

> After your comment above, I've had a play with the GConf settings as 
> well, and I've got a patch that allows you to override the gconf base 
> path. It's not quite as clean in use as the DOT_DIR override, but we can 
> set the base path ( currently fixed at /apps/gnucash ) to something 
> else, and ItWorksForMe :-)

I applied a variation of this patch earlier tonight as r15760.

David


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

Re: I'm beginning to really dislike gnomeprint...

[David Hampton]

On Sat, 2007-03-24 at 20:49 -0400, David Reiser wrote:
> r15752 is a wonderful step -- adding a preference for the check  
> printing font.
> 
> In the gnomeprint realm, however, the font name is never recognized.  
> Regardless of what font is selected in the preference pane, checks  
> are printed with a Sans font.
> 
> The font size, is recognized and used correctly.
> 
> This probably isn't worth spending a lot of time on, but it is a bit  
> weird.

Agreed.  I spent some time trying to figure this out, going as far as
embedding both a GtkFontButton and a GnomeFontPicker into the
preferences window and comparing their outputs to see if Gtk and Gnome
use different names for fonts.  They don't.  The output of the two
selectors was identical.  After that, I decided that since I was feeding
valid font names to Gnome, and that the size portion was recognized,
that the problem was somewhere in the gnome code.  [Someone prove me
wrong. Please. :-) ]   One I got to that point I felt like I was
spinning my wheels, especially since the size is recognized and that was
the main reason for making the font user selectable in the first place,
so I decided to stop pursuing the problem.

David


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

Re: r15733 - gnucash/trunk - Add support for printing reports with GtkPrint.

[David Hampton]

On Sat, 2007-03-17 at 13:29 -0400, Andreas Köhler wrote:

> Also add gnc_{save,restore}_print_settings so that those are shared
> between report and check prints.

Is this really a good idea?  Its very possible that a user may have
checks that are printed in landscape mode but their reports are printed
in portrait mode, or checks are printed simplex while reports are
printed duplex, etc., etc.

David



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

Re: Undo

[David Hampton]

On Mon, 2007-03-12 at 00:26 -0400, Jerry Quinn wrote:
> 
> I had talked to my dad a bit about features that he would need to use gnucash 
> in their business setting and audit trail was at the top of the list.  With 
> an 
> audit trail, you really can't have an undo that is indistinguishable from 
> never doing the operation.  You can enter a reversing transaction and hide 
> the 
> transaction pair, and other accounting systems do support this.

Gnucash can create a reversing transaction for you, but it doesn't hide
the transaction pair.

David


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

Re: indent

[David Hampton]

On Sat, 2007-03-10 at 14:28 -0400, Peter Selinger wrote:
> Josh Sled wrote:
> >
> > :(  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?
> 
> There is no way to say '-T *', because indent cannot figure out which
> identifiers are type names (if there were, then there would be no need
> for '-T' options). Only identifiers of the form *_t are automatically
> recognized as types

That's not a bad convention for types.  Its what I've always used for
work projects.

David



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

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

[David Hampton]

On Fri, 2007-03-09 at 15:46 -0500, Chris Shoemaker wrote:

>   2) encourage wrapping after the open parenthesis, e.g.:
> 
> foo_is_a_short_name = but_these_names_are_rather_too_long(
> argument1, argument2, argument3, argument4);
> 
> Do the ident settings permit 2)?

-nlp will tell indent not to indent to the open parenthesis.  I'm not
sure if there is an argument to to force a carriage return after an open
parenthesis.  With -nlp, this may look like the above, or may look like
this:

foo_is_a_short_name = but_these_names_are_rather_too_long(argument1,
argument2, argument3, argument4);

It would depend on whether or not argument1 runs over the line width.

David


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

indent

[David Hampton]

There's been some discussion on IRC about using the indent program to
reformat the sources into something consistent from file to file.  I'd
like to propose the following options as a starting point for
discussion.  I think some of these options will be agreed upon by all,
and I'm sure others will be contentious.  :-)

Indentation

-nutNo tabs. Indentation is done with spaces.
-i4 Add four spaces for each indent level
-ci4Continuation lines are indented by four spaces
-cli4   Case labels are indented by four spaces
-ppi4   Nested pre-processor defines are indented by four spaces
-nbcDo not force newlines after commas in declarations (default)
-nbfda  Don´t put each argument in a function declaration
on a separate line (default)
-lp Line up continued lines at parentheses (default)
-pslPut the type of a procedure on the line before its name.
-bboPrefer to break long lines before boolean operators.

Blank Lines

-nsob   Do not swallow optional blank lines (default)
-badForce a blank line after a declaration.
-bbbForce a blank line before a block comment.
-bapForce blank lines after procedure bodies.

Comments

-fcaReformat all comments except those starting in column 1
-fc1Reformat comments starting in column 1
-sc Continuation lines in a comments start with a '*'

Statements

-npcs   Do not put space after the function in function calls.
-nprs   Do not put a space after every ´(´ and before every ´)´.

-ncsDo not put a space after cast operators.
-safPut a space after each for.
-saiPut a space after each if.
-sawPut a space after each while.

-brsPut braces on struct declaration line.
-br Put braces on line with if, etc.
-ce Cuddle else and preceeding `}´.
-cdwCuddle while of do {} while; and preceeding `}´.

Other

-l80Line width of 80.

Attached is a small source file formatted with the above options.

Let the discussion begin. :-)

Of the above list of options, the ones I feel strongly about are lining
up continued lines at parentheses (-lp), the space-after-keyword group
(saf, -sai, -saw), and the cuddling-of-braces group (-br, -ce, -cdw).  I
feel most strongly about this last group.  The parts of an if/then/else
statement are clearly delineated by the indentation of the keywords vs.
the indentation of the code blocks.  I believe it a complete waste to
additionally add vertical separation my making the "else" take up three
lines.  One for a closing parenthesis, one for the word "else", and one
for an opening parenthesis.  Maybe that's just me.

What do the rest of the developers think?

David
 

#ifdef A
#ifdef B
#define C
#else
#define D
#endif
#else
#define E
#endif


/***
 * *
 ***/
struct foo {
int i, j;
char *s;
};

char *a;
char *b;

/* kssf */
char *g;


/* 
 * Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
 * tempor incididunt ut labore et dolore magna aliqua.
 . */
static void
example(int foo, char *bar, ExampleType * aligned_here)
{
Foo *bar = { 1, "foo" };	/* lorem ipsum */

for (int i = 0; i < 10; i++) {
	if (is_is_a_reasonable_value(i)
	&& (i < 10 || i < 11)) {
	// ...
	} else {
	break;
	}
}

this_is_a_long_function_name(and_this, function, has_a_very, large,
 number_of, arguments);

switch (foobar) {
	case 0:
	z = is_is_a_reasonable_value(i);
	break;
	default:
	z = !is_is_a_reasonable_value(i);
	break;
}

while (TRUE) {
	// ...
}

do {
	// ...
} while (TRUE);
}

static void
another_example(int and_this, char *function, ExampleType * has_a_very,
		char *large, double number_of, int arguments)
{
}
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gtkhtml3 - gnomeprint vs. GtkPrint

[David Hampton]

On Tue, 2007-02-27 at 11:25 -0500, Bill Nottingham wrote:
> I don't know if anyone else was already looking at this, but I took
> some time to look at handling the gtkhtml3-3.13.9x conversion to GtkPrint,
> in order to get gnucash building again for the Fedora devel tree.
> 
> In short, I'm not sure how workable any conversion to simultaneously
> handle both is -
> 
> 1) it changes the printing module from procedural to being done by
>attaching handlers to a GtkPrintOperation
> 2) gnucash exports pretty much a bare wrapper on the gnome-print APIs to
>scheme for the check-printing code, so that would have to be changed
>as well

I started converting the check printing code to GtkPrint last weekend.

> 3) Even if gnucash is fixed to work with a GtkPrint gtkhtml... goffice
>still uses gnomeprint in all released upstream versions.

This is where I see problems.  Gnucash embeds goffice pie charts and bar
charts into gtkhtml reports.  Not a problem today as both use
GnomePrint.  I'm not sure how we could do this if gtkhtml used GtkPrint
and goffice used GnomePrint.

> So, it would seem to me the best course of action is to just claim
> that gtkhtml-3.14 or later is unsupported; upstream is changing both
> the API and ABI version, so it should fail any configure check gnucash
> already has.

I'm afraid I agree.  Until goffice also converts to GtkPrint, I don't
know that we have any other course of action.

David



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

Re: crash when printing checks over $999, 2.0.X

[David Hampton]

On Sun, 2007-02-25 at 15:14 -0800, Dawning Sky wrote:

> I just upgraded to the latest svn, r15666.   It seems to me that the
> bug is still there.  Can you let me know what the patch is, so that I
> can apply to my installation?

That's odd.  r15653 is what fixed the crash for me.

David


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

Re: crash when printing checks over $999, 2.0.X

[David Hampton]

On Sun, 2007-02-25 at 14:34 -0800, Dawning Sky wrote:

> I did submitted a bug report.  
> http://bugzilla.gnome.org/show_bug.cgi?id=367705
> 
> But it was quickly marked as a duplicate of
> http://bugzilla.gnome.org/show_bug.cgi?id=352324, which I don't think
> really is the case.  And I just commented on this bug that bug#367705
> was still alive as of 2.0.5-svn.
> 
> I'm glad that someone has made a patch for it.

I'm remarked the bug in bugzilla.  If you don't want to wait for 2.0.6
the fix is pretty trivial.

David


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

Re: crash when printing checks over $999, 2.0.X

[David Hampton]

On Sun, 2007-02-25 at 12:54 -0800, Mike Carney wrote:
> David Hampton wrote:
> > BTW, I do see this crash and have a fix for it.
> 
> OK, that's great - when will it show up in the source?

Last night. :-)

If you're asking when it will show up in a release, that won't be until
2.0.6 comes out, which may be a while.  2.0.5 was released last weekend.

David


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

Re: crash when printing checks over $999, 2.0.X

[David Hampton]

On Sat, 2007-02-24 at 11:23 -0800, Mike Carney wrote:
> What's the bugid for this problem? Usual search turned up nothing.

There isn't one.  The function that's crashing hasn't changed since it
was written in the year 2000.  Any chance you've recently upgraded from
guile 1.6 to guile 1.8?  The newer version is much pickier.

BTW, I do see this crash and have a fix for it.

David




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

Re: Google Summer of Code 2007?

[David Hampton]

On Wed, 2007-02-21 at 18:51 -0500, John Schmerge wrote:
> My thinking is that the account selector in the report option panels is
> much more difficult to use in the 2.0.x versions as compared with the
> 1.8.x versions... In order to select multiple accounts, you need to
> *know* to use the control and shift keys as modifiers depending on what
> you want to do... In the 1.8 series, all you had to do was click on an
> account to select or deselect it.

That's standard behavior for any tree in any gtk2 based program where
multiple selection is supported.

David


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

Re: Account Selector Usability Issue

[David Hampton]

On Wed, 2007-02-21 at 16:19 -0500, John Schmerge wrote:
> Is there a compelling reason to move to the GTK Tree viewer for the
> account register? The move to the new tree viewer in the 2.0.x series
> for the account selector in report option panels was a major regression
> in terms of usability, imho.

Please elaborate.  What exactly are you calling a regression.
Specifically, what do you think is wrong with the 2.0 report options
panel and how did 1.8 work better for you.

David


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

Re: gnucash patch

[David Hampton]

On Wed, 2007-02-21 at 16:37 -0500, Bill Nottingham wrote:
> Yoshihiro Ota ([EMAIL PROTECTED]) said: 
> > +--- src/gnome-utils/gnc-html.c.origTue Feb 20 23:18:48 2007
> >  src/gnome-utils/gnc-html.c Tue Feb 20 23:18:38 2007
> > +@@ -1325,7 +1325,7 @@
> > + return;
> > +   }
> > + 
> > +-  gtk_html_print(GTK_HTML(html->html), ps->context);
> > ++  gtk_html_print_page(GTK_HTML(html->html), ps->context);
> > +   gnc_print_session_done(ps);
> > + }
> > + 
> 
> It's nowhere near that simple. ps->context in gtk_html_print_page (for
> new gtkhtml3) is a GtkPrintContext, not a GnomePrintContext. I strongly
> supsect that making this change may make it build/link, but then all the
> print-session.c gnome_print_* calls will blow up spectacularly.

So is gtkhtml3 in the middle of a conversion from GnomePrint to GtkPrint
and they just haven't bumped the .so version yet?

David


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

Re: problems with gtk_html_print in gtkhtml.h

[David Hampton]

On Thu, 2007-02-15 at 19:15 -0500, Derek Atkins wrote:
> Quoting David Hampton <[EMAIL PROTECTED]>:
> 
> > On Thu, 2007-02-15 at 16:52 -0500, digger vermont wrote:
> >
> >> My reading skill (programming) is not very good but it seems that they
> >> are getting rid of the dependency on libgnomeprint.
> >
> > Well, that makes sense since libgnomeprint was obsoleted by the various
> > GtkPrint* functions in gtk 2.10.
> 
> Fun..  And of course FC5 still only has gtk 2.8..  So we need to support
> both interfaces...   *sigh*

Sorry, deprecated was the word I meant to use.  There is some overlap
where releases have both.

David


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

Re: problems with gtk_html_print in gtkhtml.h

[David Hampton]

On Thu, 2007-02-15 at 16:52 -0500, digger vermont wrote:

> My reading skill (programming) is not very good but it seems that they
> are getting rid of the dependency on libgnomeprint. 

Well, that makes sense since libgnomeprint was obsoleted by the various
GtkPrint* functions in gtk 2.10.

David


___
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)

[David Hampton]

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.
> 
> If the answer is "yes, GnuCash is to have a modular design but there
> isn't the time for the primary developers to finish its
> implementation" then please say so.

This is the correct answer to your question.

> As it is now I am unable to build trunk on my primary computer and 
> would consider resolving this problem to be an interesting exercise.

That would be great.

David



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

Re: r15549 - gnucash/trunk/lib/glib28 - Remove lib/glib28/gwin32-2.8.[ch] again.

[David Hampton]

On Sat, 2007-02-10 at 08:15 -0500, Andreas Köhler wrote:

> We depend on GLib >= 2.8 on Windows in configure.in, so there is no
> reason to include unused GLib 2.8 Windows-specific code. Oops. OTOH,
> gstdio-2.8.h is needed on Unix.

If we're going to require glib 2.8 to build on windows, then we should
require glib 2.8 across the board.  Having different levels of system
libraries depending on the platform being used sounds like a sure way to
confuse end users.  Glib 2.8 was released 18 months ago on August 12th
2005.

David
 


___
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.

[David Hampton]

On Sun, 2007-02-04 at 11:50 -0500, Josh Sled wrote:
> Author: jsled
> Date: 2007-02-04 11:50:27 -0500 (Sun, 04 Feb 2007)
> New Revision: 15499
> Trac: http://svn.gnucash.org/trac/changeset/15499
> 
> Modified:
>gnucash/trunk/lib/libqof/qof/gnc-date.c
>gnucash/trunk/lib/libqof/qof/gnc-date.h
>gnucash/trunk/src/gnome/window-reconcile.c
> Log:
> Remove basically-unused qof date manipulation code better provided by GDate.

This breaks end-of-the-month tracking that was intentionally built into
the reconciliation code.  The original code would track as follows:

1/31 -> 2/28 -> 3/31 -> 4/30 -> 5/31

The replacement code tracks like this:

1/31 -> 2/28 -> 3/28 -> 4/28 -> 5/28

David



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

Re: English wording proof-reading?

[David Hampton]

On Fri, 2007-01-19 at 14:22 +0100, Christian Stimming wrote:

> I'd like to improve the wording of UI texts in the HBCI/aqbanking module
> of GnuCash (trunk). A bunch of strings need to be modified anyway
> because the module supports not only HBCI but also OFX Direct Connect
> and other online banking techniques, as implemented in the aqbanking
> library.
> 
> Could I get some feedback about the wording in the attached patch? If I
> change those strings anyway, it would be better to remove bad wordings
> as well :-)

Here are a couple of proposed changes.

David




> @@ -612,13 +612,12 @@
>printf("on_aqhbci_button: Oops, aqhbci wizard return nonzero value: 
> %d. The called program was \"%s\".\n", res, wizard_path);
>gnc_error_dialog
>   (info->window,
> -   /* Each of the %s is the name of the backend, e.g. "aqhbci". */
> -  _("The external program \"%s Setup Wizard\" returned a nonzero "
> -"exit code which means it has not been finished successfully. "
> -"The further HBCI setup can only be finished if the %s "
> -"Setup Wizard is run successfully. Please try to start and "
> -"successfully finish the %s Setup Wizard program again."),
> -  backend_name, backend_name, backend_name);
> +  _("The external program \"AqBanking Setup Wizard\" returned a "
> +"nonzero exit code which means it has not been finished "
> +"successfully.  The further Online Banking setup can only "
> +"be finished if the AqBanking Setup Wizard is run successfully. "
> +"Please try to start and successfully finish the AqBanking "
> +"Setup Wizard program again."));

A 'nonzero exit code' is programmer speak.  How about this:

The external program "AqBanking Setup Wizard" returned an
indication that it failed to create .  Any further
Online Banking setup can only be performed if the AqBanking
Setup Wizard is run successfully.  Please try running the
AqBanking Setup Wizard again.

>druid_disable_next_button(info);
>  }
>} else {
> @@ -626,10 +625,10 @@
>  gnc_error_dialog
>(info->window,
> /* Each of the %s is the name of the backend, e.g. "aqhbci". */
> -   _("The external program \"%s Setup Wizard\" has not been found. \n\n"
> +   _("The external program \"AqBanking Setup Wizard\" has not "
> +  "been found. \n\n"
>"The package aqbanking is supposed to install the program "
> -  "\"%s-qt3-wizard\". Please check your installation of aqbanking."),
> -   backend_name, backend_name);
> +  "\"qt3-wizard\". Please check your installation of aqbanking."));

The aqbanking package should include the program "%
s-qt3-wizard". Please check your installation to ensure this
program is present.

Maybe add:

On some distributions this may require installing additional
packages.

> @@ -31,21 +31,21 @@
>   
> True
> GNOME_EDGE_START
> -   Initial HBCI 
> Setup
> -   This druid helps you setting 
> up your HBCI connection with your bank.
> +   Initial Online Banking 
> Setup
> +   This druid helps you setting 
> up your Online Banking connection with your bank.
>  
> -You first need to apply for HBCI access at your bank. If your bank  decides 
> to grant you HBCI access, the bank will send you a letter,  containing 
> +You first need to apply for Online Banking access at your bank. If your bank 
>  decides to grant you Online Banking access, the bank will send you a letter, 
>  containing 

You first need to apply for Online Banking access at your bank. If your
bank decides to grant you electronic access, they will send you a letter
containing 

>  
>  * The bank code of your bank
>  * The user ID that identifies you to your bank
> -* The Internet address of your bank's HBCI server
> -* Information about the cryptographic public key of your bank 
> ("Ini-Letter").
> +* The Internet address of your bank's Online Banking server
> +* For HBCI Online Banking, information about the cryptographic public key of 
> your bank ("Ini-Letter").
>  
>  This information will be needed in the following. Press "Forward" 
> now.
>  
> -NOTE: NO WARRANTIES FOR ANYTHING. Some banks are running a poorly 
> implemented HBCI. You should not rely on time-critical transfers through 
> HBCI, since sometimes your bank does not give you correct feedback when a 
> transfer has been rejected.
> +NOTE: NO WARRANTIES FOR ANYTHING. Some banks are running a poorly 
> implemented Online Banking. You should not rely on time-critical transfers 
> through Online Banking, since sometimes your bank does not give you correct 
> feedback when a transfer has been rejected.

NOTE: NO WARRANTIES FOR ANYTHING. Some banks run a poorly implemented
Online Banking server. You should not rely on time-critical transfers
through Online Banking, because sometimes the bank does not give you
correct feedback when a

Re: Problem getting quotes

[David Hampton]

On Sat, 2007-01-20 at 10:28 -0800, Phil Longstaff wrote:
> On a new installation, after I ran gnc-fq-update, I still got a "system 
> error" when trying to retrieve quotes.  gnc-fq-dump worked fine.  However, 
> when I ran gnc-fq-helper, it told me that Date::Manip was not found.  I have 
> modified gnc-fq-update and gnc-fq-check to check for Date::Manip (there is an 
> implicit "use Date::Manip" in gnc-fq-helper).  I don't know perl very well.  
> Is it possible to pull the set of required modules into a separate include 
> file?  I didn't change it, but an update for gnc-fq-dump might also be 
> required.
> 
> Patch attached to add Date::Manip to gnc-fq-check.in and gnc-fq-update.in.

This is already in trunk.  It needs to be back-ported to the 2.0
release.

David


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

Re: Raise dependency versions of GLib, Pango and GTK+

[David Hampton]

On Wed, 2007-01-17 at 20:42 -0500, Josh Sled wrote:
> On Tue, 2007-01-16 at 12:58 +0100, Andreas Köhler wrote:
> > currently the code base depends on GLib >= 2.4, Pango >= 1.6 and GTK+ >=
> > 2.4. I would like to propose higher base versions, at least for GLib,
> > better for all three of them.
> [deletia]
> > There might be other reasons, like removing the burden to check whether
> > a GLib/Gtk 2.6 feature is worth single-casing it. What do you think?
> 
> Yeah, we should treat them as a triple...

Agreed.

> Assuming we get 2.2 out the door in April, that means the 6 month
> dependency window is October 2006 ... which is about when Ubuntu,
> Mandriva and Fedora Core last released ... Suse was in December, and
> Debian just doesn't work that way.
> 
> In any case, gtk 2.8 seems acceptable, and gtk+-2.10 is almost in there
> (except for Suse).
> 
> So, should we go to 2.6, or 2.8?  I say 2.8. RHEL4 users have
> gnucash-2.0.4 to get them by, and we're not really helping them by
> restricting ourselves to 2.6 if they're still on 2.4.

I think we should migrate to at least 2.6 so that we can support a win32
release, eliminate the cloned glib 2.6 code in lib/glib26, and remove
the code that's conditionally compiled for pre/post glib26 and gtk26.
If we're not using any new-in-gtk-2.8 features I don't see any need to
bump the dependency that high.  If we are using 2.8 features, I have no
problem bumping the dependency given the timing windows mentioned above.

David



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

Re: r15383 - gnucash/trunk/src - Use GtkTreeModelFlags instead of guint.

[David Hampton]

On Sun, 2007-01-14 at 21:20 -0500, Chris Shoemaker wrote:
> On Sun, Jan 14, 2007 at 09:13:49PM -0500, David Hampton wrote:
> > On Sun, 2007-01-14 at 20:08 -0500, Chris Shoemaker wrote:
> > > Author: chris
> > > Date: 2007-01-14 20:08:54 -0500 (Sun, 14 Jan 2007)
> > > New Revision: 15383
> > > Trac: http://svn.gnucash.org/trac/changeset/15383
> > > 
> > > Modified:
> > >gnucash/trunk/src/gnome-utils/dialog-account.c
> > >gnucash/trunk/src/gnome-utils/gnc-tree-model-account.c
> > >gnucash/trunk/src/gnome-utils/gnc-tree-model-commodity.c
> > >gnucash/trunk/src/gnome-utils/gnc-tree-model-selection.c
> > >gnucash/trunk/src/gnome/dialog-sxsincelast.c
> > > Log:
> > > Use GtkTreeModelFlags instead of guint.
> > 
> > Should this be back-ported to 2.0?
> 
> No need, really.  It's not a bugfix.  Just protection against future
> gtk ABI changes.

Well, are you sure that GtkTreeModelFlags is always a guint?  Including
on the Alpha?  :-)

David


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

Re: r15383 - gnucash/trunk/src - Use GtkTreeModelFlags instead of guint.

[David Hampton]

On Sun, 2007-01-14 at 20:08 -0500, Chris Shoemaker wrote:
> Author: chris
> Date: 2007-01-14 20:08:54 -0500 (Sun, 14 Jan 2007)
> New Revision: 15383
> Trac: http://svn.gnucash.org/trac/changeset/15383
> 
> Modified:
>gnucash/trunk/src/gnome-utils/dialog-account.c
>gnucash/trunk/src/gnome-utils/gnc-tree-model-account.c
>gnucash/trunk/src/gnome-utils/gnc-tree-model-commodity.c
>gnucash/trunk/src/gnome-utils/gnc-tree-model-selection.c
>gnucash/trunk/src/gnome/dialog-sxsincelast.c
> Log:
> Use GtkTreeModelFlags instead of guint.

Should this be back-ported to 2.0?

David


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

Re: [Fwd: Bug#406378: gnucash bug #406378]

[David Hampton]

On Sun, 2007-01-14 at 12:52 -0800, Thomas Bushnell BSG wrote:
> See the attached message. :)
> 
> Please don't cast GType into guint; it breaks the API and fails on Alpha
> (at least).  If you look at http://bugs.debian.org/406378, there is a
> patch at the end of the bug log which Steve Langasek says fixes the
> current problems.  Can someone please check that into gnucash for the
> next release?

I've just committed a patch where I've (hopefully) corrected all
instances of something that should be a GType not being defined as such.

David


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

Re: Slightly smarter date parsing?

[David Hampton]

On Mon, 2007-01-08 at 08:26 -0800, Andrew Sackville-West wrote:
> On Sun, Jan 07, 2007 at 03:09:34PM -0800, Thomas Bushnell BSG wrote:
> > On Sun, 2007-01-07 at 15:16 -0600, Jamuraa wrote:
> > > I was putting my receipts in for the last half month or so recently
> > > and noticed that I had to be careful to notice the year that the
> > > receipts were in.  When putting in 12/23 or similar, I didn't get
> > > December 23, 2006, but December 23, 2007.  I thought this should be
> > > different, so I dove into the gnucash code and changed qof_scan_date
> > > slightly to choose the last year for December if the current month is
> > > January.  The patch is attached.
> > 
> > This behavior has also always annoyed me.
> 
> me too! but it only crops up once a year. How long after 1/1 are
> people still entering 12/xx items? Granted, I routinely enter 50+

Why not just type "xx[" to get the date you want?  I.E. For 12/27 you
would type the three characters "27[".  A single number is assumed to be
a day in the current month, and then the left bracket character
decrements the month by one.

David


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

Re: 2.0.4 release?

[David Hampton]

On Sat, 2006-12-30 at 21:05 -0500, Derek Atkins wrote:

> 2) Change the code to retry-on-failure (so we'd have to try each read
>and write twice).
> 
> Although I prefer #1, David seems to prefer #2.  He's doing the work so
> I'll let him decide.   IMNSHO for now the Debian package can just limit
> the compatible glib version.

I'm doing normal fallback behavior.  All writes will use new key names
without spaces.  Read will first attempt to retrieve from a new key name
without a space.  If that read fails, gnucash will attempt a reread
using the previous key name.  This double-read should only ever happen
once per person per data file.

David


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

Re: invalid glib key names in gnucash

[David Hampton]

On Fri, 2006-12-29 at 10:42 -0800, Thomas Bushnell BSG wrote:
> gnucash creates its own glib key files in ~/.gnucash/books.  The keys
> used in these files are filled with spaces.  Spaces are not allowed in
> glib keys.

Since when?  The g_keyfile documentation that appears in devhelp says
nothing about the space character being invalid in keys. In fact, it
implicitly implies that the space *is* a valid character, by
specifically stating that "to preserve initial and final spaces, these
can also be escaped as \s."  This documentation is generated directly
from the glib sources.

> As of glib version 2.12.5, key names are being validated and errors
> returned if invalid keys are used.

That's just rude.  At minimum there should be a transition period where
an error is spit out for these so-called invalid keys.

> This causes the stored data in ~/.gnucash/books to be ignored and
> also unsaved.

$%#&*#%^

> Upstream is opposed to changing glib to allow spaces, because in part
> the syntax is unclear (what about leading spaces? what about spaces
> around the equal sign?).  

Eh?  This is clearly spelled out in the documentation produced from the
current glib g_keyfile sources.

1) Space before and after the '=' character are ignored.
2) To preserve initial and final spaces, these can also
   be escaped as \s.

> Two things are necessary here:
> 
> 1) Make gnucash stop using the illegal keys,

They weren't illegal when the code was written.  They still aren't if
you have glib less then 2.12.5.  The glib developers have made them
illegal by fiat.

> 2) Transition for users with existing files so that they don't suddenly
> lose.

Duh.  Try telling that to the glib developers.

Sincerely pissed off,

David


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

Re: Patch for New Customer dialog

[David Hampton]

On Sat, 2006-12-16 at 07:13 +0100, Andreas Köhler wrote:

> * GtkDialogs should not have separators (glade: tab Widget, last option)
> 
> * GtkDialogs use a 5px border around the action area and a 2px border
> around the content in the default style. Therefore I suggest to set the
> border of the dialog to 7px, the border of the main child (notebook
> here) to 5px and the spacing between it and the buttons to 8px. That way
> the OK button is 12px to the lower right corner and the distance between
> the notebook and the buttons equals 18px. What do you think?
> 
> * I like the 6px border of the frames, but rather set a 6px border for
> the tab, make the frame borders 0px, but at a spacing of 12px.
> Visually
> it is the same, but I think it is more closely to what you want to
> design (and easier to raise to 12px if you decide to do that later)

Please don't use personal preferences in choosing offsets for dialog
layout.  The Gnome HIG goes into some detail on how windows should be
laid out.

http://developer.gnome.org/projects/gup/hig/2.0/design-window.html
http://developer.gnome.org/projects/gup/hig/2.0/design-text-labels.html
http://developer.gnome.org/projects/gup/hig/2.0/windows-alert.html#alert-spacing

If you can't find something listed there, then make dialogs consistent
with the existing dialogs.  If the existing dialogs are inconsistent, we
should make them consistent.  If we can't decide on that's the right
answer for consistency, we should ask questions of the HIG developers.

David


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

Re: #gnucash public logging?

[David Hampton]

On Mon, 2006-12-11 at 21:23 -0500, Derek Atkins wrote:
> Chris Shoemaker <[EMAIL PROTECTED]> writes:

> > 1) I'm for it.  
> > 2) I think a notice in the channel topic is sufficient.  
> > 3) I assume there would be some mechanism for an op to toggle logging off 
> > for the whole channel.
> 
> Yeah, I would choose option #2 (do it and then re-evaluate).
> I also agree with Chris' statements.

Agreed.

David


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

Re: 2.0.2 and GConf

[David Hampton]

On Wed, 2006-11-29 at 14:23 -0700, Mark Johnson wrote: 
> I ran gnucash --g-fatal-warnings, found the process, attached gdb.
> 
> Here is the backtrace, along with the value of the parameters from frame 6:
> (gdb) cont
> Continuing.
> 
> Program received signal SIGABRT, Aborted.
> [Switching to Thread -1229989664 (LWP 28567)]
> 0xb6b5a027 in raise () from /lib/tls/libc.so.6
> (gdb) bt
> #0  0xb6b5a027 in raise () from /lib/tls/libc.so.6
> #1  0xb6b5b747 in abort () from /lib/tls/libc.so.6
> #2  0xb6cc0b0d in g_logv () from /usr/lib/libglib-2.0.so.0
> #3  0xb6cc0b36 in g_log () from /usr/lib/libglib-2.0.so.0
> #4  0xb750368b in gconf_listeners_remove_if () from /usr/lib/libgconf-2.so.4
> #5  0xb751356f in gconf_client_notify_remove () from 
> /usr/lib/libgconf-2.so.4
> #6  0xb7529807 in gnc_gconf_remove_notification (object=0x814d940, 
> section=0x0, whoami=0x809aeb0 "\030Ý\t\b\017")
> at gnc-gconf-utils.c:867
> #7  0xb7e3410b in gnc_main_window_destroy (object=0x814d940) at 
> gnc-main-window.c:1817

The #6 call frame shouldn't be possible.  The calling function passes a
constant string to gnc_gconf_remove_notification as the section name,
and has done so since that argument was added to the function.  You're
also showing garbage for the whoami argument, another a constant string.
Any chance you have another copy of gnucash on your system, or didn't
get a complete compile of the tree?

David



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

Re: Finance::quote and bourso module

[David Hampton]

On Fri, 2006-11-17 at 11:35 +0100, Sébastien Monnet wrote:
> Hi all,
> 
> I had difficulties unsing finance-quote (I have french french mutual
> funds that are available almost nowhere expet Boursorama).
> 
> It appears that the boursorama search page has been change: the field
> for the stock code is not "searchKeywords" anymore but "query".

Thanks.  I'll update this in the Finance::Quote sources

David



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

Re: no help files

[David Hampton]

On Wed, 2006-11-08 at 13:20 -0500, Steve Holditch wrote:
> I just installed from source 2.0.2 on Centos 4.4, but there seems to
> be no help from the help/tutorial tab.  I see a few other people
> having the same trouble on the google.
> 
> Just wondering if there is a fix.

Check out and install the gnucash-docs package.

David


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

Re: r15098 - gnucash/trunk/src/gnome-utils - gnc_history_get_last() can return NULL.

[David Hampton]

On Thu, 2006-11-09 at 08:14 +0100, Andreas Köhler wrote:

> g_free can handle NULL pointers just fine, now we are double-checking
> again. There is even a bug about these checks in gtk+:
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=369666
> 
> I do not suggest to fix all of them in the source, but I will whenever I
> am editing the surrounding code block anyway.
> 
> Or is there some reason for these checks?

Because I come from a time and place when free() didn't check for
NULL. :-(  Thanks for the education.

David



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

Re: r15094 - gnucash/branches/gda-dev - Initial commit of initial gda backend framework. See GDA_STATUS.

[David Hampton]

On Thu, 2006-11-09 at 10:12 +0100, Herbert Thoma wrote:

> I don't remember any more. But what did we do back at 1.2? 1.4? 1.6?
> when we switched from binary fromat to xml? I don't think that
> the new version was able to wirte the old binary format.
> 
> This does not mean that we should do it the same way now.
> I will probably switch to SQLite asap, but I would not like
> this to happen automatically without my explicit consent.

And what happens if you say "no, don't convert me to sql yet".  Are you
unable to save in the new version?  This is exactly why Gnucash should
support writing the XML file for at least one release after the new SQL
back end is introduced.

David


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

Re: r15094 - gnucash/branches/gda-dev - Initial commit of initial gda backend framework. See GDA_STATUS.

[David Hampton]

On Wed, 2006-11-08 at 17:22 -0500, Derek Atkins wrote:
> Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> 
> > Question: A user updates to GC 2.2 (or whatever rev has the new backend)
> > and opens his XML file.  He then saves the file using the Save button.
> > Is it saved as SQLite?  Does the need for the Save button disappear
> > because he runs from then on with the GDA backend?  Or, does he
> > specifically need to Save As to convert to SQLite?
> 
> This is still an open question.  There are multiple ways to consider
> handling this.  One way is to do as you suggest; if you open an XML
> file it stays as an XML file, but if you create a new file it's SQLite.
> In this approach users much manually convert from XML to SQLite via Save-As.
> In another approach GnuCash would automatically upgrade a user from XML
> to SQLite..

That would completely break backward compatibility.  Gnucash should
automatically *offer* to upgrade any XML file to its Sql equivalent, but
it should never take that action without explicit user approval.  The
user should be informed that if they convert to SQL then they cannot go
back to the Gnucash 2.0 without either a) using a backup file, or b)
jumping through hoops to create a new XML file.  The user should have
the option of continuing to use the XML file format in GnuCash 2.2
without any further inquiries about upgrading.  I would have no problem
pulling the XML back end in GnuCash 2.4 and relegating XML to a pure
import/export format, but I don't believe its appropriate to do that
with the first release of the new SQL back end.

David



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

Re: AUDIT: r15088 - gnucash/trunk - Fix some scheme inexact errors. Fixes 347462.

[David Hampton]

On Mon, 2006-11-06 at 09:41 -0500, Chris Shoemaker wrote:
> On Sun, Nov 05, 2006 at 11:45:29PM -0500, David Hampton wrote:
> > Author: hampton
> > Date: 2006-11-05 23:45:27 -0500 (Sun, 05 Nov 2006)
> > New Revision: 15088
> > Trac: http://svn.gnucash.org/trac/changeset/15088
> > 
> > Modified:
> >gnucash/trunk/ChangeLog
> >gnucash/trunk/src/report/standard-reports/account-piecharts.scm
> >gnucash/trunk/src/report/standard-reports/category-barchart.scm
> > Log:
> > Fix some scheme inexact errors.  Fixes 347462.
> > BP
> > 
> 
> Perhaps it's better to fix this inside options.scm,
> in gnc:make-number-range-option.

That function specifically allows for non-integer values.  One of the
parameters to the function is the number of decimal places to use in the
display to the user.  That said, the only report that currently uses the
capability to input non-integer numbers is the "Hello World" report.

David


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

Re: GC, QOF and queries

[David Hampton]

On Thu, 2006-11-02 at 21:27 -0500, Phil Longstaff wrote:
> On Thu, 2006-02-11 at 16:53 -0500, Chris Shoemaker wrote:

> > Anyway, try to avoid writing the SQL emitter, if you can.
> 
> I don't really want to gut the core of GC and rebuild it around Gda.

I've been thinking of gutting the core of GC and rewriting everything
based on GObjects.  :-)

David


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

Re: FAILURE xaccResolveFilePath test-resolve-file-path.c:81

[David Hampton]

On Mon, 2006-09-25 at 08:12 -0400, Derek Atkins wrote:

> Perhaps we should use something like:
> 
>   homedir = getenv("HOME")
>   if (!homedir)
> homedir = g_get_home_dir();

Unless that's common usage, I see no point in modifying GnuCash's
behavior to be inconsistent with other applications that use the
g_get_home_dir function.

David


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

Re: r14794 - gnucash/trunk/packaging/win32 - Add Glade-3, as it seems to run smoothly with gnome widgets and simply

[David Hampton]

On Mon, 2006-09-04 at 04:11 -0400, Andreas Köhler wrote:
> One day someone could try to integrate devhelp.

Why would you do that?  devhelp is the "man pages" for the gtk/gnome
apis.

David



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

Re: Dependency increase in trunk: aqbanking >= 1.6.0?

[David Hampton]

On Mon, 2006-08-21 at 22:38 +0200, Christian Stimming wrote:

> Objections, anyone from the dev side? Again, this only concerns trunk and not 
> branch-2.0.

No objections from me.  FC5 ships with 1.8.1beta.

David


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

AUDIT: r14675 - gnucash/trunk - Remove overloading of an argument passed to the

[David Hampton]

Audit please.  :-)

David

--- Begin Message ---
Author: hampton
Date: 2006-08-15 01:11:07 -0400 (Tue, 15 Aug 2006)
New Revision: 14675
Trac: http://svn.gnucash.org/trac/changeset/14675

Modified:
   gnucash/trunk/ChangeLog
   gnucash/trunk/src/core-utils/gnc-gconf-utils.c
   gnucash/trunk/src/core-utils/gnc-gconf-utils.h
   gnucash/trunk/src/gnome-utils/dialog-preferences.c
   gnucash/trunk/src/gnome-utils/dialog-reset-warnings.c
   gnucash/trunk/src/gnome-utils/gnc-main-window.c
   gnucash/trunk/src/gnome-utils/gnc-plugin.c
   gnucash/trunk/src/gnome-utils/gnc-plugin.h
   gnucash/trunk/src/gnome-utils/gnc-tree-view.c
Log:
Remove overloading of an argument passed to the
gnc_gconf_add/remove_notification functions..  This will solve a crash
on Solaris caused by g_vasprintf being passed a "%s" format string and
a NULL as argument.  BP


Modified: gnucash/trunk/ChangeLog
===
--- gnucash/trunk/ChangeLog 2006-08-15 04:13:46 UTC (rev 14674)
+++ gnucash/trunk/ChangeLog 2006-08-15 05:11:07 UTC (rev 14675)
@@ -1,3 +1,16 @@
+2006-08-15  David Hampton  <[EMAIL PROTECTED]>
+
+   * src/core-utils/gnc-gconf-utils.[ch]:
+   * src/gnome-utils/dialog-preferences.c:
+   * src/gnome-utils/gnc-plugin.[ch]:
+   * src/gnome-utils/gnc-main-window.c:
+   * src/gnome-utils/dialog-reset-warnings.c:
+   * src/gnome-utils/gnc-tree-view.c: Remove overloading of an
+   argument passed to the gnc_gconf_add/remove_notification
+   functions..  This will solve a crash on Solaris caused by
+   g_vasprintf being passed a "%s" format string and a NULL as
+   argument.
+
 2006-08-14  David Hampton  <[EMAIL PROTECTED]>
 
* doc/tip_of_the_day.list.in: Add a tip for raising the accounts

Modified: gnucash/trunk/src/core-utils/gnc-gconf-utils.c
===
--- gnucash/trunk/src/core-utils/gnc-gconf-utils.c  2006-08-15 04:13:46 UTC 
(rev 14674)
+++ gnucash/trunk/src/core-utils/gnc-gconf-utils.c  2006-08-15 05:11:07 UTC 
(rev 14675)
@@ -743,7 +743,8 @@
 void
 gnc_gconf_add_notification (GObject *object,
const gchar *section,
-   GConfClientNotifyFunc callback)
+   GConfClientNotifyFunc callback,
+   const gchar *whoami)
 {
GConfClient *client;
GError *error = NULL;
@@ -752,6 +753,7 @@
 
g_return_if_fail(G_IS_OBJECT(object));
g_return_if_fail(callback != NULL);
+   g_return_if_fail(whoami != NULL);
 
client = gconf_client_get_default();
path = gnc_gconf_section_name(section);
@@ -785,8 +787,8 @@
/*
 * Save the values needed to undo this later.
 */
-   client_tag = g_strdup_printf(CLIENT_TAG, section);
-   notify_tag = g_strdup_printf(NOTIFY_TAG, section);
+   client_tag = g_strdup_printf(CLIENT_TAG, whoami);
+   notify_tag = g_strdup_printf(NOTIFY_TAG, whoami);
g_object_set_data(object, client_tag, client);
g_object_set_data(object, notify_tag, GUINT_TO_POINTER(id));
g_free(notify_tag);
@@ -843,22 +845,24 @@
 
 void
 gnc_gconf_remove_notification (GObject *object,
-  const gchar *section)
+  const gchar *section,
+  const gchar *whoami)
 {
GConfClient *client;
gchar *path, *client_tag, *notify_tag;
guint id;
 
g_return_if_fail(G_IS_OBJECT(object));
+   g_return_if_fail(whoami != NULL);
 
/*
 * Remove any gconf notifications
 */
-   client_tag = g_strdup_printf(CLIENT_TAG, section);
+   client_tag = g_strdup_printf(CLIENT_TAG, whoami);
client = g_object_get_data(object, client_tag);
path = gnc_gconf_section_name(section);
if (client) {
- notify_tag = g_strdup_printf(NOTIFY_TAG, section);
+ notify_tag = g_strdup_printf(NOTIFY_TAG, whoami);
  id = GPOINTER_TO_UINT(g_object_get_data(object, notify_tag));
  gconf_client_notify_remove(client, id);
  gconf_client_remove_dir(client, path, NULL);

Modified: gnucash/trunk/src/core-utils/gnc-gconf-utils.h
===
--- gnucash/trunk/src/core-utils/gnc-gconf-utils.h  2006-08-15 04:13:46 UTC 
(rev 14674)
+++ gnucash/trunk/src/core-utils/gnc-gconf-utils.h  2006-08-15 05:11:07 UTC 
(rev 14675)
@@ -765,10 +765,15 @@
  *  @param callback The function to call when a value changes.  This
  *  function will receive the key/value pair as one argument, and the
  *  'object' argument to this function as another of its arguments.
+ *
+ *  @param whoami A magic value that must match up this call to the
+ *  corresponding call to gnc_gconf_remove_notification().  This value
+ *  should be unique across all call

Re: vasnprintf SEGV when %s arg is NULL

[David Hampton]

On Tue, 2006-08-15 at 10:54 -0400, Derek Atkins wrote:
> David Jafferian <[EMAIL PROTECTED]> writes:
> > It looks like that NULL has been there since this function was first
> > created, but something should replace it.  I don't know enough
> > about this code to suggest what should be put there, but replacing
> > NULL with "(nil)" made the crash go away.
> 
> Yep.  See above..
> 
> Maybe David will respond to this.

I committed a fix for this last night.  I'm waiting for a review to
back-port the fix into the 2.0 branch.

David


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

[Audit] Re: r14670 - gnucash/trunk - Add a tip for raising the accounts menu in a register page.

[David Hampton]

Forgot to request this be audited for back-port into 2.0.

David


On Mon, 2006-08-14 at 15:00 -0400, David Hampton wrote:
> Author: hampton
> Date: 2006-08-14 15:00:20 -0400 (Mon, 14 Aug 2006)
> New Revision: 14670
> Trac: http://svn.gnucash.org/trac/changeset/14670
> 
> Modified:
>gnucash/trunk/ChangeLog
>gnucash/trunk/doc/tip_of_the_day.list.in
> Log:
> Add a tip for raising the accounts menu in a register page.
> 
> 
> Modified: gnucash/trunk/ChangeLog
> ===
> --- gnucash/trunk/ChangeLog   2006-08-14 10:31:55 UTC (rev 14669)
> +++ gnucash/trunk/ChangeLog   2006-08-14 19:00:20 UTC (rev 14670)
> @@ -1,3 +1,8 @@
> +2006-08-14  David Hampton  <[EMAIL PROTECTED]>
> +
> + * doc/tip_of_the_day.list.in: Add a tip for raising the accounts
> + menu in a register page.
> +
>  2006-08-10  David Hampton  <[EMAIL PROTECTED]>
>  
>   * src/import-export/qif-import/druid-qif-import.c: Fix account
> 
> Modified: gnucash/trunk/doc/tip_of_the_day.list.in
> ===
> --- gnucash/trunk/doc/tip_of_the_day.list.in  2006-08-14 10:31:55 UTC (rev 
> 14669)
> +++ gnucash/trunk/doc/tip_of_the_day.list.in  2006-08-14 19:00:20 UTC (rev 
> 14670)
> @@ -78,6 +78,9 @@
>  a style sheet for your report as a report option, and use \
>  the Edit -> Style Sheets menu to customize style sheets.")
>  
> + N_( "To raise the accounts menu in the transfer field of a register \
> +page, press the Menu key or the Ctrl-Down key combination.")
> +
>   N_( "The GnuCash developers are easy to contact.  As well \
>  as several mailing lists, you can chat to them live on IRC! \
>  Join them on #gnucash at irc.gnome.org")
> 
> ___
> gnucash-changes mailing list
> [EMAIL PROTECTED]
> https://lists.gnucash.org/mailman/listinfo/gnucash-changes

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

Re: r14588 - gnucash/trunk - Remove the majority of the remaining deprecated widgets by collapsing

[David Hampton]

On Fri, 2006-08-11 at 22:02 +0200, Christian Stimming wrote:

> Did these changes also change the behaviour of the "import-main-matcher" so 
> that clicking on the "action" column requires a double-click now instead of a 
> single-click? I'm referring to the place where one chooses either the 
> to-be-reconciled existing transaction, or the target account for a new 
> transaction. The change from single-click to double-click is quite 
> surprising. Are there technical reasons that require this change? If yes, 

Yes.  As far as I can determine, there is no way with a GtkTreeView
widget to determine the cursor column location when the user performs a
single-click, only the cursor row location.  (Double-clicking does
provide column information.)  That meant I had to choose between a
single-click anywhere in the row activating the account selection
dialog, or using a double-click to activate the dialog.  Since the
typical gtk application behavior is that a single-click selects an item
and a double click activates an item, I chose to apply that same
behavior pattern here.  That's why it now takes a double-click to open
the account selection dialog.  BTW, a side effect of this change is that
you can now navigate the transaction matcher dialog with the keyboard.

> then it would have to be documented clearly in multiple places, or otherwise 
> everyone using this regularly will be very confused at the next upgrade.

Has a 2.0 documentation branch been pulled yet?  If so, I will update
the trunk version immediately.

David


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

Re: Build failure: Ubuntu 6.06 CVS

[David Hampton]

On Wed, 2006-08-09 at 13:18 -0400, Derek Atkins wrote:
> You've got the debian-broken libtool. I bet you're not pulling
> in libcore-utils.
> 
> I'll also point out that this is a bug that "core-utils" now depends
> on gtk.  That shouldn't have happened.  This code should go into
> gnome-utils.

I disagree.  I created the core-utils directory as a place to put code
that augments the core gxxx libraries (glib, gconf, etc. including gtk),
but doesn't have anything to do with GnuCash proper.  The gnc_cbe_xxx
functions have nothing to do with GnuCash, and everything to do with
requiring a GtkComboBox to always match an entry in the completion.  At
some point I'd like to try and push them into the gtk itself.

I would have accepted your argument that this code should be in a
gtk/gnome specific directory if gnucash was still trying to be UI
neutral, but that requirement fell by the wayside before I joined the
development group.  As far as I'm concerned, gtk is part of the core
library set that gnucash is built on.

David


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

Re: OS X/Intel Mac Update (Success!)

[David Hampton]

On Mon, 2006-08-07 at 23:44 -0400, Kevin Foss wrote:

> The 'fix' is to recompile libgnomecanvas at optimization level - 
> O1.I adjusted fink's .info file for libgnomecanvas2 accordingly,  
> rebuilt and installed the debs, and installed gnucash 2.0.1 from the  
> tarball using the wiki instructions for OS X.
> 
> Seems to work fine -- registers, reports, etc., and I'm impressed  
> with the speed on this machine.

That's great news.

David


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

Re: compile errors in svn current

[David Hampton]

On Sat, 2006-08-05 at 21:06 -0400, David Reiser wrote:
> in gnc-gtk-utils.h, it looks like you're missing an 'A'
> 
> line 45: #ifndef HVE_GTK26

Thanks.  Fixed.

David


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

Re: compile errors in svn current

[David Hampton]

On Fri, 2006-08-04 at 23:51 -0400, Derek Atkins wrote:
> I just tried on FC3 and I got this failure:
> 
> ...
> 
> I didn't try on FC4..   Maybe David can respond.

These errors should all be fixed.

David


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

Re: No splash screen in trunk?

[David Hampton]

On Mon, 2006-07-31 at 10:26 -0400, Derek Atkins wrote:
> Ahh, looks like I was pointing to an old set of gconf schemas..  Thanks
> to cstim for pointing this out to me.  

We need to be more intelligent about adding new gconf keys.  Had that
new key been added as "hide_splash_screen" instead of
"show_splash_screen", then the default value for unknown boolean keys
(i.e. false) would have produced the same behavior after the patch as
gnucash had before the patch.

I'm not criticizing andi5.  I should have caught this in my review, only
I wasn't think in terms of the behavior across the transition from pre-
to post- patch, only whether the patch was technically correct.  This
transition is something that should be considered any time a new gconf
key is added.

> I think the fact that gnucash can't (at runtime) point to gconf 
> schemas is going to bite us in the long run...

No application can do this.  Gconf is a client/server architecture where
the keys are read/written by the gconfd process and passed via an ipc
mechanism to gnucash.  AFAICT, to do what you propose would require
bypassing gconfd or just ditching gconf completely and reimplementing a
private configuration storage mechanism.

Also, remember that you're a developer who has multiple, sometimes
incompatible versions of gnucash installed.  Users with a single
installed version of gnucash should never see this problem.

David


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

Re: Questions on v2.0 for Help rework

[David Hampton]

On Wed, 2006-07-26 at 13:56 -0600, Dave Herman wrote:

> Fantastic explanation - too good to leave just in the archives, with
> your permission I'd like to include it in either Help or the
> Tutorial/Concept Guide.

Sure, you have my permission.

David


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

Re: Questions on v2.0 for Help rework

[David Hampton]

On Fri, 2006-07-21 at 14:41 -0600, Dave Herman wrote:
> I have a couple of questions while working on the "custom" section of
> the HELP.
> 
> 1) What does "Renumber subaccount" do?

It rewrites the account codes for all children of the current account.
For example, you have the following account structure:

CodeName

10  Colors
10-1-Red
10-2-Orange
10-3-Yellow
10-4-Blue
10-5-Violet

You now need to add the "Green" account, but you want it to sort between
the Yellow and Blue accounts.  Instead of having to manually renumber
all the accounts starting with Blue, you can use the "renumber
subaccount" command on the Colors account.  In the popup dialog the
prefix value should default to "10", the account code for the colors
account.  If you set an interval value of 5 and click "Renumber" you
will end up with the following account structure:

10  Colors
10-05   -Red
10-10   -Orange
10-15   -Yellow
10-20   -Blue
10-25   -Violet

Now you have room in the account code numbering space to add the Green
account with an account code to force the proper ordering.

10  Colors
10-05   -Red
10-10   -Orange
10-15   -Yellow
10-18   -Green
10-20   -Blue
10-25   -Violet

> 2) What does "Reset Warnings" in the Action Menus do?

In many of the dialog boxes in the system there are two checkboxes at
the bottom labeled "Remember and don't ask me again" and "Remember and
don't ask me again this session".  If you have told gnucash to remember
an answer and no longer show you the warning message, this menu item
allows you to specify which warning boxes should be shown again.

> 3) Where is the text that is displayed as additional help in the
> "setting preferences" windows?
> I would like to use some of it in the "help" document.  I've done a
> search for the text string, but did not find them.

All the text in the preferences window comes from glade files.

> 5) Has anything significant changed in the Tax Report section? Where did
> all those codes came from?  All the Tax references in "TXF Export -
> Known Anomalies and Limitations" seem to be "really old", are there
> updates?  Is anyone on the Intuit TXF list?

I've checked the TXF site and there hasn't been an updated document
posted in years.

David


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

Re: gnucash on alpha?

[David Hampton]

On Sat, 2006-07-15 at 18:01 -0700, Thomas Bushnell BSG wrote:
> Does anyone have any positive evidence of the new gnucash (post 1.8)
> working on alpha?  A debian user (bugs.debian.org/378346) gets a fatal
> crash every time, and got such a crash with 1.9 as well.  The 1.9
> crash was mentioned on debian-user, but there was no list traffic
> about it beyond the initial report.

The initial report sounded like the same problem gnucash 1.9/2.0 has on
a MacIntel system.  The application runs correctly until a register is
opened.  On the MacIntel the crash is in the gnome canvas library in a
place that seems unrelated to gnucash.  However, none of the developers
have a MacIntel system to be able to recreate the crash and investigate
further.  I haven't seen a stack trace for the Alpha crash so I have no
way to correlate to determine if it truly is the same problem.

David


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

Re: Copyright notice

[David Hampton]

On Sun, 2006-07-09 at 19:54 +0200, Eneko Lacunza wrote:

> I think the copyright ought to be something enforceable by law. I don't
> think 1, 2, 3 are enforceable in any ways. I think #4 is very doubtful.

My understanding is that the "copyright enforceable by law" is the
copyright notice on each of the individual source code files that
comprise GnuCash, not the general copyright notice displayed in the
"About" box.

> What about asking some lawyer in GNU project? 

Good idea.

David


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

Re: problem in configure

[David Hampton]

On Mon, 2006-07-03 at 11:25 -0400, David Reiser wrote:
> I'm trying to do a make distclean in preparation for building  
> svn14458, and I get:
> 
> checking if guile needs our copy of (guile www)... ./configure: line  
> 15593: syntax error near unexpected token `gnc_have_guile_www,'
> ./configure: line 15593: `GUILE_MODULE_AVAILABLE(gnc_have_guile_www, 
> (www main))'
> make: *** [config.status] Error 2

Maybe a silly question, but did you run 'guile16-build make distclean'?

David


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

Re: F::Q broken after update

[David Hampton]

On Sat, 2006-07-01 at 23:39 +0200, Sigve Indregard wrote:

> After updating to SVN HEAD yesterday, GnuCash' integration with F::Q is
> broken on my system.

There's a bug in the gnc-fq-helper script that I fixed this morning.
You'll need to update again.

David


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

Re: Gnucash Close Tab Ordering

[David Hampton]

On Fri, 2006-06-30 at 13:31 -0400, Adam Rosi-Kessel wrote:

> Who is responsible for the tab behavior? I assume it's too late to request a
> change before 2.0 releases?

That would be me.  Yes, its too late for the initial release of 2.0.

David


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

Re: Gnucash Close Tab Ordering

[David Hampton]

On Fri, 2006-06-30 at 12:45 -0400, Adam Rosi-Kessel wrote:

> But this isn't true at all. Firefox doesn't maintain a tab stack. If you
> close the rightmost tab, you are always moved to the tab immediately to the
> left of it. If you close the leftmost tab, you are moved to the tab to the
> right of it. If you close a tab in the middle, you are also moved to the
> next tab to the right. This has been true with Firefox as long as I can
> remember Firefox supporting tabs at all.

You're right.  Its a function of the "Tab Mix Plus" extension.  I guess
I've been using that extension so long I assumed it was the built-in
behavior.

David


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

Re: Problem using checkinstall for G2 svn

[David Hampton]

On Tue, 2006-06-13 at 15:12 -0400, digger vermont wrote: 
> Hello All,
> 
> I'm trying to make a deb pkg using checkinstall.  In the end I get these
> errors:
> 
> Selecting previously deselected package gnucash-svn.
> (Reading database ... 147597 files and directories currently installed.)
> Unpacking gnucash-svn (from .../gnucash-svn_r14358-1_powerpc.deb) ...
> dpkg: error
> processing /home/digger/src/SVN/gnucash/gnucash-svn_r14358-1_powerpc.deb
> (--install):
>  trying to overwrite `/usr/share/automake-1.9/COPYING', which is also in
> package automake1.9
> dpkg-deb: subprocess paste killed by signal (Broken pipe)
> Errors were encountered while processing:
>  /home/digger/src/SVN/gnucash/gnucash-svn_r14358-1_powerpc.deb
> 

Someone else reported this problem earlier in the week.  It was solved
by adding the --copy argument to the invocation of automake in the
autogen.sh file.

> Given that I don't have this problem using checkinstall to build other
> packages, does this look like a problem with G2's installation?

Absolutely not.  I just checked the output of my last install and the
COPYING files was copied to the /share/gnucash/doc directory.

Given that a) when the file is a link to /usr/share/automake-1.9/COPYING
checkinstall prints an error message, and b) when that file is a copy
of /usr/share/automake-1.9/COPYING then checkinstall works fine, I'd say
that checkinstall can't handle symlinks properly.

David


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

Re: GnuCash 1.9.7 doesn't run

[David Hampton]

On Thu, 2006-06-15 at 18:11 -0500, Daniel Espinosa wrote:
> I compile and install on a Ubuntu 6.06, the version 1.9.7, but it just shows
> the splash intent to open the main window but close inmediately with the
> next message:
> 
> : In procedure scm-error in expression (scm-error (quote
> misc-error) #f ...):
> : no code for module (g-wrap gw standard)

http://wiki.gnucash.org/wiki/FAQ#Q:_Running_1.9.x_on_Debian.2FUbuntu_crashes_with_.22no_code_for_module_.28g-wrap_gw_standard.29.22.__What_does_this_mean.3F

David


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

Re: Problem using checkinstall for G2 svn

[David Hampton]

On Wed, 2006-06-14 at 18:53 -0400, digger vermont wrote:

> Okay.  It a stretch for me to understand all this stuff at once stuff.
> 
> It looks to me like autogen.sh calls automake-1.9 with the option
> "--add-missing".  By default the option links the files rather than
> copy. So that links some files in the /usr/share/automake-1.9 directory
> to the gnucash directory including COPYING and INSTALL.
> 
> Regardless of who's problem it is, adding the option "--copy" to
> automake-1.9 in autogen.sh solved my problem.  If it could be helpful to
> anyone else I can file a bugreport for it.

I still think its a bug in the install script.  It shouldn't matter
whether that file is a link or a copy.  The installation should always
attempt to install the file as /share/gnucash/doc/COPYING
and never as /usr/share/automake-1.9/COPYING.

David


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

Re: r14363 - gnucash/trunk - Similarly ensure for aqbanking/mt940 import that all retrieved strings

[David Hampton]

On Wed, 2006-06-14 at 15:49 -0400, Christian Stimming wrote:
> Author: cstim
> Date: 2006-06-14 15:49:25 -0400 (Wed, 14 Jun 2006)
> New Revision: 14363
> Trac: http://svn.gnucash.org/trac/changeset/14363
> 
> Modified:
>gnucash/trunk/ChangeLog
>gnucash/trunk/src/import-export/hbci/gnc-hbci-utils.c
> Log:
> Similarly ensure for aqbanking/mt940 import that all retrieved strings
> will be valid utf8.

I noticed that the hbci protocol specifies utf-8 and then the data is
converted to the local code set.  I was going to commit the following
change so that hbci data remained as utf8.


Index: src/import-export/hbci/gnc-hbci-utils.c
===
---src/import-export/hbci/gnc-hbci-utils.c  (revision 14353)
+++ src/import-export/hbci/gnc-hbci-utils.c (working copy)
@@ -628,12 +628,7 @@
 
 const char *gnc_hbci_book_encoding()
 {
-#if HAVE_LANGINFO_CODESET
-  char* encoding = nl_langinfo(CODESET);
-#else
-  char* encoding = "UTF-8";
-#endif
-  return encoding;
+  return "UTF-8";
 }


Would this change have fixed my940 as well, or is it hbci specific?

David


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

Re: problems with mt940, compiling revision 14345

[David Hampton]

On Wed, 2006-06-07 at 23:28 +0200, Flavio Rump wrote:
> Hi
> 
> Trying to compile revision 14345 with --enable-mt940 ang getting
> following errors. (aqbanking 2.0.0 is installed)
> 
> thx alot for any help
>
> ...
>
> make[5]: *** No rule to make target
> `../../../src/import-export/hbci/libgncmod-hbci.la', needed by
> `libgncmod-mt940.la'.  Stop.
> make[5]: Leaving directory
> `/home/flavio/downloads/gnucash-trunk/src/import-export/mt940'

You need to fix the errors in src/import-export/hbci before you can
cleanly compile mt940.  Did you enable hbci?

David


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

Re: Debian bug: QIF import causes data loss

[David Hampton]

On Mon, 2006-06-05 at 20:13 -0400, Derek Atkins wrote:
> Quoting David Hampton <[EMAIL PROTECTED]>:
> 
> > If nothing else, the various gnucash importers should check that the
> > data is valid utf8 during import.
> 
> And what if they are not?  If you're running a non-UTF8 locale the
> imported data could be ISO or something else..  QIF for example has
> nothing to specify the encoding.  I suppose we could add a page to
> the importer druid that asks the user for the input encoding, but most
> likely they'd have no clue what it is.

I don't know.  Ask for the encoding?  Drop the invalid character?
Refuse the data entirely?  Something else?  Anything other than
accepting invalid utf8 would be preferable.

If invalid utf8 is imported and the data saved to an xml file, there is
know way I know to recover except by hand editing the file.  As far as I
can tell libxml2 simply stops parsing when it encounters a invalid utf8
character.  Period.  I can't find any available exception handler that
could be used for automated recovery. 

David


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

Re: Debian bug: QIF import causes data loss

[David Hampton]

On Mon, 2006-06-05 at 16:49 -0700, Thomas Bushnell BSG wrote:
> Derek Atkins <[EMAIL PROTECTED]> writes:
> 
> > The first thing that comes to mind is "The QIF importer doesn't deal
> > with charset/encoding and doesn't do any kind of conversion", which
> > would mean that it's possible to push a non-utf8 character string into
> > the data set through the importer.  That could be what's happening.
> 
> Uh huh, that would be a problem!  Once I get some test files that
> demonstrate the bug from the submitter, I'll verify that I can produce
> it and file it in bugzilla.

If nothing else, the various gnucash importers should check that the
data is valid utf8 during import.

David


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

Re: r14333 - gnucash/trunk - Fix "missing icon" menu icons on FC6.

[David Hampton]

On Tue, 2006-06-06 at 02:26 +0300, Nikos Charonitakis wrote:
> you mean fc5.
> fc6 is scheduled for September. ;)

No, I actually meant FC6.  This problem only occurs on redhat rawhide,
or whatever its now called.

David


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

Re: 1.9.6 ter

[David Hampton]

On Mon, 2006-05-29 at 14:10 -0400, David Hampton wrote:
> On Sat, 2006-05-27 at 13:38 -0400, don Paolo Benvenuto wrote:
> > 
> > Besides that, ctl-alt-pgup/down works only when I am in the main
> > accounts tab. After passing to a register with crl-alt-pgdown, then
> > ctl-alt-pgup moves upwards in the txns
> 
> I am investigating why the register widget doesn't pass along the
> ctl-alt-pgup/down keystrokes.  This widget is part of gnucash and can be
> modified.

I have fixed the register code to pass the ctl-alt-pgup/down keystrokes
on to the notebook.  You should now be able to use these key
combinations to switch into and out of register pages.

David


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

Meet the developers

[David Hampton]

On June 10th, several of the developers are getting together in
Manhattan for lunch.  I will be there, as well as Derek Atkins
, Josh Sled , and Christian Stimming  from
Germany.  Anyone who wants is welcome come join us for food and drinks.
Feel free to bring spouses/significant others too.

We're planning on meeting at 2PM at the Heartland Brewery near Times
Square and should be there for until 5PM or 6PM.  This is a pretty
convenient location for anyone coming in either to Grand Central or Penn
Station, and has great subway access.  The restaurant address is 127 W.
43rd Street, and its just east of Times Square.  Their web site is
http://www.heartlandbrewery.com/ .

Please RSVP directly to me if you are coming so I can make the
appropriate reservation at the restaurant.

David

P.S. We'll be doing a mini key-signing, so bring a copy of your PGP/GPG
key fingerprint if you want it signed.


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

Re: 1.9.6 ter

[David Hampton]

On Sat, 2006-05-27 at 13:38 -0400, don Paolo Benvenuto wrote:
> El sáb, 27-05-2006 a las 13:32 -0400, don Paolo Benvenuto escribió:
> > Gnucash uses ctl-alt-pgup/down to move between tabs.
> > 
> > Why doesn't it use the standard gnome shortcut ctl-pgup/down (without
> > alt)?

It does.  Keystrokes are first provided to the selected widget.  If that
widget does nothing with the keystroke, then the keystroke will be
passed in turn to each successive containing widget.  In gnucash the
widgets used for the account tree page and the register page also use
ctl-pgup/down as a shortcut, so the behavior you see will depend on
which widget currently has focus.  If the account tree has focus, then
it process the ctl-pgup keystroke and the notebook never sees it.  If
the notebook has focus, then it is the first widget to see the ctl-pgup
and functions like you would expect.  Try clicking on a notebook tab
then then typing ctl-pgup/down.

The accounts page and the notebook are not behavior that can be changed
by gnucash.  This behavior is embedded into the underlying GtkNotebook
and GtkTreeView widget used by gnucash.

> Besides that, ctl-alt-pgup/down works only when I am in the main
> accounts tab. After passing to a register with crl-alt-pgdown, then
> ctl-alt-pgup moves upwards in the txns

I am investigating why the register widget doesn't pass along the
ctl-alt-pgup/down keystrokes.  This widget is part of gnucash and can be
modified.

David



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

Re: Logo final candidates?

[David Hampton]

On Sun, 2006-05-28 at 16:13 -0400, Chris Shoemaker wrote:
> On Sun, May 28, 2006 at 03:49:50PM -0400, Derek Atkins wrote:
> > You should ask this of gnucash-devel, not me personally.  :)
> > 
> > -derek
> > 
> > Quoting Joshua Facemyer / Impressus Art <[EMAIL PROTECTED]>:
> > 
> > >Ok, so since the 1.9.7 release, as RC1, should probably have the new
> > >logo stuff in them, and it looks like nobody has any problems with the
> > >current versions, and many people actually like them, what do I do with
> > >them?
> > >
> > >Also, do we want to put together a set of pixmap (png) icons in various
> > >sizes as well as have an svg icon?  I'm not sure how that's all handled,
> > >is anyone else?

See http://developer.gnome.org/projects/gup/hig/2.0/icons-types.html .

> > >
> 
> I was about the grab splash11 and commit it, but www.impressusart.com
> is down.

I committed the new splash screen.  It will appear in the 1.9.7 release
later today.  Copies of the logo and banner have been committed to the
web site, but I didn't change any HTML to reference them.

David


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

Re: Complete en_GB translation

[David Hampton]

On Sun, 2006-05-28 at 20:50 +0100, Nigel Titley wrote:
> Please find the current en_GB po file. I normally send this in through
> the Translation project but delays on the TP are running at 2 weeks or
> more at the moment.

Committed.

David


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

Re: 1.9.6 ter

[David Hampton]

On Sun, 2006-05-28 at 15:20 -0400, don Paolo Benvenuto wrote:
> El sáb, 27-05-2006 a las 13:32 -0400, don Paolo Benvenuto escribió:
> > Gnucash uses ctl-alt-pgup/down to move between tabs.
> > 
> > Why doesn't it use the standard gnome shortcut ctl-pgup/down (without
> > alt)?
> 
> Besides that, when closing a tab, apparently there isn't a clear logic
> in the tab the user is left after closing the tab.

Its always the tab that was most recently in front.  Has nothing to do
with the ordering of the tabs in the notebook.  For example, say you
have five tabs open and looked at them in the order 1, 3, 5, 2, 4.  If
you close the open tab, which it tab 4, you will go back to tab 2.  If
you then close that tab, you go back to what was originally tab 5.
Close that, and you're back to what was originally tab 3.  This is
exactly the same way the Firefox functions.

David 



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

Re: 1.9.6

[David Hampton]

On Fri, 2006-05-26 at 22:48 -0400, don Paolo Benvenuto wrote:

>   When I put the cursor over a drop down lists, the letters get the
> colors of the tool, and so I can't read the string (the same thing is
> present in all gnucash2)

Is this only a problem with gnucash?  Do any other gnome2 applications
do this?  Gnucash itself does not specify any colors except for the
register widget, and then only when you set a specific preference.
Otherwise all colors displayed by gnucash from the system theme.  GTK
themes do contain  a "pre-light" color that is used when you hover the
mouse over a widget.  It sounds like maybe the background and text
"pre-light" values are set to the same value.  Try changing your system
them and see if the problem goes away.

> - In the preferences (I'm using spanish localization), when passing
> from the 1st to the 2nd tab, something weird appears (see screenshot).

I have seen this behavior but don't know how to reproduce it.  The
problem occurs because the tab labels are of different widths when
printed in normal vs. bold type.  On my system I don't see the selected
tab name printed in bold type.

>   When the preferences are opened, shouldn't the program be unusable?

Yes.  I can use gnucash without any problems while the preferences
window is open.  Might be a window manager problem.  I'm using FC5 and
Metacity.

>   Separation character: changing it reloading of the data file (2
> minutes for me...). 

Yes, there is some delay while gnucash rebuilds the internal data
structures used for register completion.  The length of the delay
depends upon the number of accounts that you have defined.

> Besides that, I found "colon": shouldn't it be ":"?
> Note that in 1.8.9 I used the dot ".": the preferences wasn't preserved.

The word "colon" was used as a backward compatible default for anyone
whose tested with 1.9.x in the last year.  It is fully equivalent to the
single character ':'.

>   File -> compress wasn't preserved neither. Neither the "days to retain
> log files"

Gnucash 1.8 and 2.0 use completely different systems for saving
preferences.  The 1.8 system was a home-grown system while 2.0 uses the
standard gnome preference system.

> - Preferences: Toolbar style, text besides icons: not all icons show
> text

This is normal.  The "text beside icon" setting is also know as the
"priority text" setting.   Only the most important should be labeled in
this setting.  The Human Interface Guidelines explicitly say that no
more than four buttons should be labeled in this mode.  See:
http://developer.gnome.org/projects/gup/hig/2.0/toolbars-labels-tooltips.html

> - In the main window I miss a command to expand or shrink all the
> account hierarchy

Try select and account and then holding the shift key and typing the
plus key on the keypad.  This is a standard GTK key for expanding all
levels of the selected tree item.

David


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

Re: 1.9.6

[David Hampton]

On Fri, 2006-05-26 at 23:34 -0400, Chris Shoemaker wrote:
> On Fri, May 26, 2006 at 10:48:07PM -0400, don Paolo Benvenuto wrote:
> >
> > - Building a report is
> > veeery long (>15
> > min) with my data file (a problem from 1.8.9). At least gnucash should
> > be usable in the registry while the report is calculated
> 
> I'm not sure about this.  I mean to ask hampton about it but forgot.
> I *think* the original motivation for disabling the gui during
> progress-bar use was re-entrancy problems related to file save/load.
> If so, myabe there a way to solve that that doesn't also disable the
> gui during report rendering.  David?

Gnucash has never supported performing other action while a report is
being built.  If it worked before, it was an unsupported and unexpected
side effect of updating the progress bar.  Explicitly disabling the GUI
was done to prevent crashes that occur when commands are unexpectedly
received during report generation (or any other function that provides a
progress bar) and cannot be handled by gnucash.

Yes, this is a problem.  It should be possible to abort a report that is
in the process of being built, or better yet, reports should be built in
the background.  Both of those will have to wait for a later release of
gnucash.  The latter will be a particularly hard nut to crack.

David


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

Re: Reconcile window rebuilds

[David Hampton]

On Fri, 2006-05-12 at 22:50 +0200, Thomas Klausner wrote:
> Hi!
> 
> Found with 1.9.5 and still there in r14032:
> When I reconcile and click on items so they get their check mark,
> sometimes the whole dialog window is rebuilt. It looks like gnucash
> decides that a column width is too small and makes it bigger (only
> a few pixels I think), and that affects all columns to the right
> of it.
> 
> Usually, it ends up looking nearly the same as before, but there's
> a second of unrest while the columns are rebuilt.
> 
> ...
> 
> Has anyone else seen this? Should I bugzilla it?

I see this too.  I believe its true that the two item lists are
completely rebuilt with each change, but I haven't checked.

David


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

Re: Splash Screen Revisited

[David Hampton]

On Fri, 2006-05-19 at 21:11 -0500, Joshua Facemyer / Impressus Art
wrote:

> http://www.impressusart.com/download/splash2.png

My only concern is that it explicitly says "version 2.0".  That means
that the splash screen will have to be updated with each release (2.1,
2.2, etc).  I'm hoping these will be much more frequent than the time
interval between 1.8 and 2.0.

David


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

Re: Fix test?

[David Hampton]

On Wed, 2006-05-17 at 13:56 -0400, Mike Alexander wrote:
> --On May 15, 2006 2:36:00 AM -0400 Mike Alexander <[EMAIL PROTECTED]> wrote:
> > I've attached a patch that seems to fix the errors found by
> > test-period when automatic lot scrubbing is enabled.  Even though it
> > is no longer enabled, these bugs should probably be fixed.  I think
> > the patch is ok, but others who know more about the internals of the
> > GnuCash engine should take a look at it.
> >
> > With these patches I get only one error when running test-period with
> > parameters from 10 to 299.  At 207 it gets an "xaccSplitSetValue():
> > numeric error in converting the split value's denominator" error, but
> > that's because the test code generates a value that is too big to
> > represent with the chosen denominator of 100.
> 
> I put this in bugzilla as bug 342153 so it won't get lost.

Applied.

David


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

Re: [Gnucash-changes] r13931 - gnucash/trunk - Add support for directly marking the book dirty, for recording the

[David Hampton]

On Sun, 2006-05-07 at 22:18 -0400, Chris Shoemaker wrote:
> On Sat, May 06, 2006 at 05:10:01PM -0400, David Hampton wrote:
> > Modified: gnucash/trunk/lib/libqof/qof/qofutil.c
> > ===
> > --- gnucash/trunk/lib/libqof/qof/qofutil.c  2006-05-06 14:53:22 UTC (rev 
> > 13930)
> > +++ gnucash/trunk/lib/libqof/qof/qofutil.c  2006-05-06 21:09:59 UTC (rev 
> > 13931)
> > @@ -302,8 +302,10 @@
> >  return TRUE;
> >  }
> >  
> > -if (dirty && qof_get_alt_dirty_mode())
> > +if (dirty && qof_get_alt_dirty_mode()) {
> >qof_collection_mark_dirty(inst->entity.collection);
> > +  qof_book_mark_dirty(inst->book);
> > +}
> >  if (on_done)
> >  on_done(inst);
> >  return TRUE;
> 
> Is this a semantic change or just an optimization? 

Neither.  The qof_book_mark_dirty() function also records the time when
the book is first marked dirty, and invokes any registered callback
function.  Gnucash uses the former when you quit without saving, and the
latter to immediately indicate that the book is dirty in the window
title bar.

David


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

Re: [Gnucash-changes] r13926 - gnucash/trunk - Add an alternate mode for handling the dirty state of instances and

[David Hampton]

On Sun, 2006-05-07 at 22:07 -0400, Chris Shoemaker wrote:

> Why is this after the "on_free" case?

So that deleting the blank transaction will not cause the collection to
be dirtied.

> Deleting an object will result
> in calling qof_commit_edit_part2() with do_free set, so this
> qof_collection_mark_dirty() will never be reached.

> So, if the collection isn't marked dirty on committing a deleted
> object, and if the freeing functions, which call
> qof_instance_release(), which calls qof_entity_release(), which calls
> qof_collection_remove() also no longer dirties the collections, then I
> don't see how the book would be dirtied when an object is deleted.

I tested these changes when deleting an existing transaction and the
book was dirtied.

> Somehow, sometime, deleting an object needs to result in a dirty book,
> even though it contain collections of only clean instances (entities).

If you have a solution for dirtying the book when deleting a
pre-existing object that also doesn't dirty the book when deleting the
blank split or blank transaction, I'd love to hear it.

David


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

Re: Scheduled Transactions dead list

[David Hampton]

On Fri, 2006-05-05 at 10:57 -0400, Josh Sled wrote:

> I guess the two biggest deprecated pieces in the SX ui right now are the
> clists: a few in the SLR dialog and the one in the SX List.

GtkCList/GtkCTree is the big one.

> Those are the biggest deprecated usages I'm aware of, but I'm not on top
> of what is and isn't deprecated... what else is there?

There's a handful of functions in gnc-dense-cal.c that's been
deprecated.  Mostly gdk functions related to font manipulation and
sizing strings.  All that type stuff should use Pango functions now.
Maybe a couple of uses of GtkOptionMenu.  That's all I saw in the SX
files.

GtkCList is the biggest issue throughout GnuCash, followed by
GtkOptionMenu.

David



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

Re: Scheduled Transactions dead list

[David Hampton]

On Thu, 2006-05-04 at 18:57 -0400, Josh Sled wrote:
> On Thu, 2006-05-04 at 18:49 -0400, Andrew Duggan wrote:
> > I've been hacking around in there trying to see if I can get sx processing 
> > working a little more closely to the way I do my thing. So the first step 
> 
> Oh, what're you thinking?  I'm planning on re-writing most of the SX
> stuff in the next month or two, so we might want to coordinate now,
> before things diverge too much...

Good to know.  I'm in the process of trying to eliminate all the
deprecated gtk/gnome functions from gnucash.  I'll skip the sx code
since you're going to rewrite it.

David


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

Re: Are we ready for the 2.0.0 release in mid-May?

[David Hampton]

On Sun, 2006-04-30 at 17:47 -0400, Mike Alexander wrote:

> In this sort of situation you would likely have separate GnuCash 
> accounts for the two portfolios.  Both the stock split druid and the 
> lots manager are specific to a particular GnuCash account 

I totally misread your previous message.  I thought you were suggestion
to make the stock split druid aggregate all the *accounts*, not all the
lots in an account.  I withdraw my objection.

David



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