QIF doc pages
Charles Day
cedayiv at gmail.com
Tue Feb 26 19:33:26 EST 2008
On Tue, Feb 26, 2008 at 6:58 AM, Derek Atkins <warlord at mit.edu> wrote:
> Yes, that sounds like the right list of things to you.
> You should commit Makefile.am. Makefile.in is generated.
> You can test #6 by removing the schema file from your gconf.
>
I've thrown just about everything I can at gconf and I can't get it to
generate an error when it looks up the show_doc setting. I've discovered
that you have to do more than blowing the schema away, because if the key
doesn't exists then gconf simply returns FALSE with no indication of an
error. See gconf bug 90843<http://bugzilla.gnome.org/show_bug.cgi?id=90843>.
So there is no way to distinguish between "gconf found the setting and the
value is FALSE" and "gconf didn't find the setting". They don't seem to
think this is an important problem!! So while I think my error-handling code
is written properly, I don't know that I can test it or that it will ever
get executed.
I've attached a diff that shows the entire patch, in case anyone wants to
read or test it.
Now... about adding the new "schemas" directory into SVN... I tried doing a
simple "svn add schemas" but that added Makefile.in along with the rest of
the files. So I did "svn remove Makefile.in --force", and that got rid of
it. However, I noticed that the "schemas" directory doesn't have the same
property for svn:ignore as others in the repository. How do I set that up
correctly? Are there any other steps I need to take before committing these
changes?
Cheers,
Charles
>
> -derek
>
> "Charles Day" <cedayiv at gmail.com> writes:
>
> > On Mon, Feb 25, 2008 at 11:07 PM, Ian Lewis <ianmlewis at gmail.com> wrote:
> >
> > Yah, but you might want to test #6 anyway since you are technically
> never
> > guaranteed to be able to read from the gconf database. Techically
> programs
> > should work with their default values even if gconf decides to fail
> on
> > every lookup.
> >
> > How can I make the gconf lookup fail so I can test #6? Right now it is
> always
> > succeeding, even if I blow away my .gconf directory. -Charles
> >
> > 2008/2/26, Charles Day <cedayiv at gmail.com>:
> >
> > On Sun, Feb 24, 2008 at 9:10 AM, Derek Atkins <warlord at mit.edu>
> wrote:
> >
> > Hi,
> >
> > Quoting Charles Day <cedayiv at gmail.com>:
> >
> > > On Sat, Feb 23, 2008 at 9:32 AM, Derek Atkins <
> warlord at mit.edu>
> > wrote:
> > >
> > >> Yeah, I thought they should be shown by default.. Are
> you sure
> > >> that you're picking up the default schema settings?
> > >>
> >
> > >
> > > The option to turn on/off QIF doc pages doesn't seem to be
> part
> > of the
> > > default schema settings. I guess I should put together one
> of
> > those
> > > "schemas" directories for the QIF importer, right?
> > Alternatively, we could
> > > just change the sense of the setting to "Hide
> documentation"
> > rather than
> > > "Show documentation" so that doc pages are on by default,
> even
> > if you blow
> > > away your .gconf settings.
> >
> > I've gone the schema route, and although I know nothing about
> gconf or
> > automake except what I skimmed today, by some miracle it seems
> to have
> > worked. Here's what I did, so tell me if this sounds right:
> > 1. Created a new "schemas" directory under qif-import (I copied
> the
> > one in import-generic)
> > 2. Rename "apps_gnucash_import_generic_matcher.schemas.in" to
> > "apps_gnucash_import_qif.schemas.in" and adjust its content.
> > 3. Edit Makefile.am in the new schemas directory and replace
> > "apps_gnucash_import_generic_matcher.schemas.in" with
> > "apps_gnucash_import_qif.schemas.in"
> > 4. Edit Makefile.am in the qif-import directory and add
> "schemas" as a
> > subdirectory (SUBDIRS).
> > 5. Edit configure.in and add a line for
> "src/import-export/qif-import/
> > schemas/Makefile"
> > 6. Add error checking to druid-qif-import.c so that doc pages
> are
> > turned on by default if the gconf lookup fails.
> > 7. Build and test gnucash from scratch.
> >
> > Does the above sound like everything I need to do? It seems to
> work -
> > and not by getting defaulted from #6.
> >
> > I notice that the Makefile.in files got rebuilt at some point...
> but
> > "svn status" doesn't reflect that. Is SVN ignoring Makefile.in
> > differences on purpose? Would I need to include the new
> Makefile.in in
> > the new schemas directory as part of my "svn commit"?
> >
> > Cheers,
> > Charles
> >
> > >
> > > Any opinion?
> >
> > That would work...
> >
> > > -Charles
> >
> > -derek
> >
> > >
> > >> -derek
> > >>
> > >> "Ian Lewis" <ianmlewis at gmail.com> writes:
> > >>
> > >> > Charles,
> > >> >
> > >> > Oh shoot. I was under the impression that they were
> shown by
> > default. I
> > >> > definitely agree with this. There is no point if they
> are not
> > shown by
> > >> > default. On a side note, perhaps we should have a check
> box
> > in the druid
> > >> > that allows users to turn them off from the druid
> itself
> > (like on the
> > >> apply
> > >> > page)? The check box is in the preferences and I might
> not
> > have known
> > >> about
> > >> > it if I hadn't done development on the QIF druid.
> > >> >
> > >> > As far as how to do it, I would imagine you would have
> to do
> > something
> > >> along
> > >> > the lines of editing a default schema somewhere in the
> source
> > tree but I
> > >> > couldn't tell you for sure as the code isn't in front
> of me
> > atm.
> > >> >
> > >> > Ian
> > >> >
> > >> > 2008/2/23, Charles Day <cedayiv at gmail.com>:
> > >> >>
> > >> >> The QIF importer druid has "doc pages" that benefit
> new
> > users by
> > >> >> explaining
> > >> >> the import process a step at a time, as the user makes
> his
> > way through
> > >> the
> > >> >> druid. I think that new users would really benefit if
> these
> > pages were
> > >> >> shown
> > >> >> by default (I certainly would have). However, GnuCash
> > currently hides
> > >> >> these
> > >> >> pages by default.
> > >> >>
> > >> >> Do you agree that these pages should be shown by
> default,
> > and if so,
> > >> how
> > >> >> do
> > >> >> I make this happen? The setting is controlled via
> gconf, so
> > would I
> > >> have
> > >> >> to
> > >> >> add one of those gconf schemas perhaps?
> > >> >>
> > >> >> Cheers,
> > >> >> Charles
> > >> >> _______________________________________________
> > >> >> gnucash-devel mailing list
> > >> >> gnucash-devel at gnucash.org
> > >> >>
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > >> >>
> > >> > _______________________________________________
> > >> > gnucash-devel mailing list
> > >> > gnucash-devel at gnucash.org
> > >> >
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > >> >
> > >> >
> > >>
> > >> --
> > >> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media
> Laboratory
> > >> Member, MIT Student Information Processing Board
> (SIPB)
> > >> URL: http://web.mit.edu/warlord/ PP-ASEL-IA
> N1NWH
> > >> warlord at MIT.EDU PGP key
> available
> > >>
> > >
> >
> > --
> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media
> Laboratory
> > Member, MIT Student Information Processing Board
> (SIPB)
> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA
> N1NWH
> > warlord at MIT.EDU PGP key
> available
> >
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord at MIT.EDU PGP key available
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: show_doc.txt
Url: http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080226/89b255be/attachment.txt
More information about the gnucash-devel
mailing list