The web has changed a lot since GnuCash documentation was first accessible
online. What are the thoughts about changing online documentation to browse
by Chapter rather than Chapter Section? The ability to scroll forward and
back gives much more context to the documentation. The effect s shown
lem with building the documentation caused by a bad merge
> of the updated Portuguese translation of the Tutorial and Concept Guide,
> resulting in the macOS and Windows all-in-one bundles to have only the
> Portuguese translation.
>
> There were also some Gtk bugs in the macOS bundle.
&
There was a problem with building the documentation caused by a bad merge of
the updated Portuguese translation of the Tutorial and Concept Guide, resulting
in the macOS and Windows all-in-one bundles to have only the Portuguese
translation.
There were also some Gtk bugs in the macOS bundle
I had only looked in line 408:
* @return The color for this page. This string is owned by the page and
not 419:
* @param The color for this page. This string is owned by the page and
Am 01.03.22 um 06:55 schrieb john:
>
>
>> On Feb 28, 2022, at 9:26 PM, Frank H. Ellenberger
>> wrote:
>>
Thanks,
I have pushed your suggested fix to maint.
Regards,
Geert
Op zondag 27 februari 2022 08:47:09 CET schreef Kevin Buckley:
> This stanza in gnucash/gnome-utils/gnc-plugin-page.h
>
> /** Set the color of this page. This is the color string used
> * in the notebook tab.
> *
> *
> On Feb 28, 2022, at 9:26 PM, Frank H. Ellenberger
> wrote:
>
> Hi Kevin,
>
> Am 27.02.22 um 08:47 schrieb Kevin Buckley:
>> appears to be missing the parameter name color
>>
>> Line 408 should presumably be
>>
>> * @param color The color for this page. This string is owned by the page
Hi Kevin,
Am 27.02.22 um 08:47 schrieb Kevin Buckley:
> appears to be missing the parameter name color
>
> Line 408 should presumably be
>
> * @param color The color for this page. This string is owned by the page
> and
np, it is the return value. Because a function can have multiple
This stanza in gnucash/gnome-utils/gnc-plugin-page.h
/** Set the color of this page. This is the color string used
* in the notebook tab.
*
* @param page The page whose name should be retrieved.
*
* @param The color for this page. This string is owned by the page and
* should not be
Op donderdag 27 januari 2022 07:31:33 CET schreef Chris Good:
> Hi,
>
> It's been quite a while since I built the documentation and much has
> changed.
>
> https://wiki.gnucash.org/wiki/Documentation_Improvement#In_HTML_and_Other_Fo
> rmats
> says:
>
> The b
Hi,
It's been quite a while since I built the documentation and much has
changed.
https://wiki.gnucash.org/wiki/Documentation_Improvement#In_HTML_and_Other_Fo
rmats
says:
The built html files with be placed in an automatically created directory,
which if using the example directories
Hi Lionel,
merged, thanks! But in the future better create a pull request. Patches
by mailing list tend to get forgotten.
https://wiki.gnucash.org/wiki/An_Introduction_to_Git
Regards
Frank
Am 13.11.21 um 10:12 schrieb Lionel Élie Mamane:
[Patch]
___
commit c4d4ee37801e4709b7c47f0cb2434dcee97d5ac0
Author: Lionel Elie Mamane
Date: Sat Nov 13 07:34:22 2021 +0100
code is in git now
diff --git a/HACKING b/HACKING
index 6cfa80f1a..56534a2ae 100644
--- a/HACKING
+++ b/HACKING
@@ -7,7 +7,7 @@ Related Documents
-
In
A complex topic is brought up here.
I agree with the issues you bring up. I don't know if or how we can solve them
all.
In the gnucash project we currently only have experience with docbook for user
oriented documentation and doxygen for our api documentation.
On the premise what we have so
Am 17.02.21 um 05:15 schrieb John Ralls:
>
>
>> On Feb 16, 2021, at 4:16 PM, Frank H. Ellenberger
>> wrote:
>>
>> Most of the static part of the GUI is in the glade files, which are XML.
>> It should not be very hard to XSLT the nodes for the structure, and
>> finally labels and tooltips.
>
> On Feb 16, 2021, at 4:16 PM, Frank H. Ellenberger
> wrote:
>
> Most of the static part of the GUI is in the glade files, which are XML.
> It should not be very hard to XSLT the nodes for the structure, and
> finally labels and tooltips.
Dunno about most. There's a surprising amount of
xt help buttons throughout the UI. ISTM that should make it
> more amenable to translation with gettext.
>
> I think that if the help documentation was kept close to the UI code that it
> would be both easier for developers to keep it in sync with code changes and
> for code
throughout the UI. ISTM that should make it
more amenable to translation with gettext.
I think that if the help documentation was kept close to the UI code that it
would be both easier for developers to keep it in sync with code changes and
for code reviewers to insist that they do so. Integrating
Hi David,
Am 10.04.20 um 07:36 schrieb David Cousens:
> Gunter Kamp
> seemed to have a related but slightly different issue associated with
> AQbanking. Banks here haven't generally allowed any direct server access
> other than downloads from their web portals so i have no familiarity with AQ
>
Thanks Frank
That was pretty much what i thought the situation would be. Perhaps we
should add a note about the flow somewhere That is easily accessible to
users in the documentation so that users have a better idea of where to look
for up to date recent and rapidly changing information. I
nks to the
wiki are not nice. Most users get the docs together with the program
installed.
Frank
Am 10.04.20 um 01:08 schrieb David Cousens:
:
> The other obvious thing is to update the documentation with appropriate
> instructions and in the shorter term put this up on the wiki in the
>
. So I assigned the bugs to
> myself, and have started fixing them locally. I have also started updating
> the doxygen information in the code. And I have created new user
> documentation for import bills & invoices. I am now in the process of
> investigating the import customers &
to the GnuCash project, starting with the
documentation. Is there someone coordinating the documentation effort?
My intention is to start with an update of chapter 18 Importing
Business Data, of the Concepts en Tutorial Guide.
Some background on myself: I started using GnuCash just a few months
ago
reakouts from
> BuildUbuntu16.04
> so I will copy them back to the Build on Linux page.
Ok.
> The autotools build also
> applies to building the documentation so it could also be linked from there
I believe that's not completely accurate. The documentation build system is
also autotoo
Op vrijdag 21 september 2018 01:16:51 CEST schreef David Cousens:
> Adrien,
>
> I think it is better to leave packaging apps to specialists rather than the
> general user.
> Using flatpak and snap can be better addressed on the
> Installation page rather than a building page which also addresses
o building the documentation so it could also be linked from there
David Cousens
-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.o
Adrien,
I think it is better to leave packaging apps to specialists rather than the
general user. Using flatpak and snap can be better addressed on the
Installation page rather than a building page which also addresses using ,
Software Mmanager and installation of the version supported by the
On Thu, 2018-09-20 at 11:42 -0500, Adrien Monteleone wrote:
> While you’re tweaking this, consider changing the debian/derivative
> instructions to use ‘apt’ instead of ‘apt-get’ as
> my understanding the distro preferences are for the newer ‘apt’ user tool.
> (not to be confused, due to
I was thinking more along the lines of .deb/.rpm but if it adds complexity to
get up and running, certainly, it should not be included. (or perhaps as a
breakout page option)
I don’t take that route for my own installations as I’m more familiar with
building and cleaning up after myself.
Op donderdag 20 september 2018 19:09:10 CEST schreef Adrien Monteleone:
> > On Sep 20, 2018, at 5:46 AM, David Cousens
> > wrote:
> >
> >
> > I'll set the examples up to default to a /home/user/.local install and
> > then perhaps add an extra section on installing for all users and the
> >
> On Sep 20, 2018, at 5:46 AM, David Cousens wrote:
>
>>
> I'll set the examples up to default to a /home/user/.local install and then
> perhaps
> add an extra section on installing for all users and the various options
> there and
> the need for administrator privileges. Most Linux users
using the equivalent of apt-cache search. I'll do as
> much as I can from the online documentation
> for the other distros. I I'll have a closer look and if I can get away
> perhaps with a subsitute "dnf" and "yum"and
> "apt" for apt-get as a note alo
ses pacman, Sabayon uses equo,
> OpenSuse uses or used to use yast,...)
>
> > I'll do as much as I can from the online
> > documentation for the other distros. I I'll have a closer look and if I
> > can get away perhaps with a subsitute "dnf" and &
I don't know
what other package managers support (Arch uses pacman, Sabayon uses equo,
OpenSuse uses or used to use yast,...)
> I'll do as much as I can from the online
> documentation for the other distros. I I'll have a closer look and if I
> can get away perhaps with a subsitute "dn
on
board. Some distros do seem to use slightly different names for some libraries
and headers so perhaps a warning to check
your own distros naming using the equivalent of apt-cache search. I'll do as
much as I can from the online documentation
for the other distros. I I'll have a closer look
For users to be able to obtain the latest (or otherwise particularly desired)
version not in their repos, I would agree with David C. & Geert here that a
single generic linux recipe for tarballs, augmented with links to quirks for
particular *non-deprecated* distributions and/or historical
On Tue, 2018-09-18 at 13:16 -0400, David T. via gnucash-devel wrote:
> Hello,
>
> I have a general question about building. Forgive me if this is naive. The
> last time I used Linux was last century,
> and I believe that Linux has changed just a tad since then.
>
> Since GnuCash is now
David,
Considering David T's expressed concern regarding git, setting up
collaboration in one repo is probably the least complicated. That would allow
you to help out with the more subtle git operations, and allow David T. to
worry less about that part.
Geert
Op dinsdag 18 september 2018
structions for the older distro(s) (adding for
which distro this matters). That will make it easier to maintain the
documentation in the future:
- if nothing changes when a new disto release comes out, documentation doesn't
need to be updated
- if a distro
series until they are comfortable to make the switch. There
are even users on 2.4 still. We decided recently that any wiki information
older than that release should be considered obsolete. Which inversely also
means anything more recent is not.
That's why we still have build documentation for 2
It’s Debian and derivatives: Ubuntu is a derivative--or these days maybe a
symbiote, there are Canonical reps on the Debian board--of Debian.
I frankly don’t understand why Ubuntu needs a per-release explanation of how to
build it, especially since Debian doesn’t. `sudo apt-get build-dep
On Tue, 2018-09-18 at 11:18 -0500, Adrien Monteleone wrote:
> > On Sep 18, 2018, at 7:53 AM, Frank H. Ellenberger
> > wrote:
> >
> >
> > Perhaps you can do some cleanup: Is Gutsy outdated?
>
> That was version 7.10 of Ubuntu, that is, released October 2007. By far, it
> is no longer
how to do things but not why you
would want to (not totally true but enough to make the point). I think there
are some analogies to the gnucash user base
and documenters and developers that hold here and it does fit in with the
general thrust of the article John referenced.
I access documentation in
Am 18.09.18 um 16:58 schrieb David T. via gnucash-devel:
> The wild card in this Assistance Continuum is the wiki. There is a lot of
> useful information there; how would a user know to find it? Placing an actual
> link to the wiki is doomed to fail, since the wiki is by nature dynamic. Is
>
> On Sep 18, 2018, at 12:16 PM, David T. wrote:
>
>>
>> Along with that, if older material for older systems and versions isn’t
>> going to be moved to its own ‘archive’ page, then it should always appear
>> down the page in chronological order. The current state of the build
>>
Hello,
I have a general question about building. Forgive me if this is naive. The last
time I used Linux was last century, and I believe that Linux has changed just a
tad since then.
Since GnuCash is now developed over git, can't users|developers|writers|yetis
use git for most distros to
uite a bit
> of room for improvement: new users regularly ask for help on topics that have
> coverage in the Help, the Guide and/or the wiki. So, we need to be looking
> for Something Better.
>
> Bearing in mind the amount of work already placed in the existing
> documentation, I b
> On Sep 18, 2018, at 7:53 AM, Frank H. Ellenberger
> wrote:
>
>
> Perhaps you can do some cleanup: Is Gutsy outdated?
That was version 7.10 of Ubuntu, that is, released October 2007. By far, it is
no longer supported by Canonical. (wasn’t even a Long Term Support release) And
there is
.
Bearing in mind the amount of work already placed in the existing
documentation, I believe that we can establish a clear Assistance Continuum
that uses context help to direct users to specific sections of the Guide. I
have mentioned this in other discussions recently, but I want to reiterate
David,
Doesn’t GitKraken allow you to have multiple remotes in a repo?
Regards,
John Ralls
> On Sep 18, 2018, at 6:00 AM, David Cousens wrote:
>
> Hi Frank,
>
> The problem I was having is that until David Ts changes are merged into the
> main repo
> I can't pull them using either GitHub or
David,
I am glad that you are taking on this aspect of the docs. Thank you.
I would like to note to you (and reiterate for the larger group) the following
important information:
I am a POOR CHOICE to be considered some kind of documentation expert. While I
have a great deal of editorial
Hi Frank,
The problem I was having is that until David Ts changes are merged into the
main repo
I can't pull them using either GitHub or GitKraken to my local repo from the
GnuCash-docs github.
I use Gitkraken and it has just allowed me to clone
https://github.com/sunfish62/gnucash-docs into
time contributors to the documentation or translation.
The special art is now to find the right balance.
Am 18.09.18 um 10:19 schrieb David Cousens:
> John, David, Frank
>
> I wonder at the value of the Build Tools page as a separate orphan entity
> given the more detailed instru
Op dinsdag 18 september 2018 10:36:14 CEST schreef David Cousens:
> David,
>
> It was the master branch which was 139 commits behind. I looked at the maint
> branch and noticed it was up to date.
>
> I have tried forking your repository but as I already had a fork of the main
> gnucash-docs
Hi David Cousens,
Am 18.09.18 um 10:36 schrieb David Cousens:
> David,
>
> It was the master branch which was 139 commits behind. I looked at the maint
> branch and noticed it was up to date.
>
> I have tried forking your repository but as I already had a fork of the main
> gnucash-docs
David,
It was the master branch which was 139 commits behind. I looked at the maint
branch and noticed it was up to date.
I have tried forking your repository but as I already had a fork of the main
gnucash-docs repository github wasn't letting me fork your repository
separately. It basically
John, David, Frank
I wonder at the value of the Build Tools page as a separate orphan entity
given the more detailed instructions given in the Building Gnucash page.
There is a fairly good example of dupllcation with it and the following for
the Gnucash progarm build.
John,
Thank you for stepping in. This looks much better now, and I believe I
understand it, maybe. I have added a link to this page from the broader
Documentation Update Instructions page (so it won’t be lonely).
David
> On Sep 17, 2018, at 3:04 PM, John Ralls wrote:
>
>
>
s a waste
> of space, and pushes actual content off screen.
>
>>
>> The order was historical, so one could add "CMake has the following
>> benefits over autotools …”
>>
>
> I changed the order so that information about compiling the program would b
al content off screen.
If I can not right-click->copy the link of the section, it is a waste of
my time. Guess wich one is cheaper.
>> The order was historical, so one could add "CMake has the following
>> benefits over autotools …”
>>
>
> I changed the order s
wing
> benefits over autotools …”
>
I changed the order so that information about compiling the program would be
covered before the information about compiling the documentation. I don’t see
any text that lists CMake benefits versus Autotools, so perhaps this is no
longer an issue
Am 17.09.18 um 17:24 schrieb David T.:
> Frank,
>
>> On Sep 17, 2018, at 10:47 AM, Frank H. Ellenberger
>> wrote:
>>
>> Hi David,
>>
>> Am 17.09.18 um 14:59 schrieb David T.:
>>> Hello,
>>>
>>> Can anyone give me clear langua
,
>>>
>>> Can anyone give me clear language on when and why a documentation creator
>>> would need to reissue the commands in Initializing Documentation Build
>>> Environment? I’d like to clear this issue up on the wiki before it gets
>>> lost.
>>>
Thanks for the background. I wasn’t thinking of the case of other types of
servers, as I so far only deal with Apache.
> On Sep 15, 2018, at 9:28 AM, John Ralls wrote:
>
> If an attacker guesses the path a -Indexes directive won’t stop him from
> requesting the directory from the server. It
David,
I did not see this message previously; it got flagged as spam.
> On Sep 15, 2018, at 6:12 PM, David Cousens wrote:
>
> David
>
> Main reason I pushed it through to the current Help manual is that I had it
> completed to slot in there already apart
> from a bit of minor debugging. If
Frank,
> On Sep 17, 2018, at 10:47 AM, Frank H. Ellenberger
> wrote:
>
> Hi David,
>
> Am 17.09.18 um 14:59 schrieb David T.:
>> Hello,
>>
>> Can anyone give me clear language on when and why a documentation creator
>> would need to reissue the co
Hi David,
Am 17.09.18 um 14:59 schrieb David T.:
> Hello,
>
> Can anyone give me clear language on when and why a documentation creator
> would need to reissue the commands in Initializing Documentation Build
> Environment? I’d like to clear this issue up on the wiki befo
Hello,
Can anyone give me clear language on when and why a documentation creator would
need to reissue the commands in Initializing Documentation Build Environment?
I’d like to clear this issue up on the wiki before it gets lost.
David
> On Sep 14, 2018, at 10:21 AM, David T. wr
ary visual learners. The
remainder of us utilize a mixture of styles.
David Cousens
On Sun, 2018-09-16 at 20:11 -0700, John Ralls wrote:
> So the IgNobel Prizes are out, and the “winner" of the literature prize is
> "Life Is Too Short to RTFM: How Users Relate to Documentati
e “winner" of the literature prize is
> "Life Is Too Short to RTFM: How Users Relate to Documentation and "Excess
> Features in Consumer Products”,
> https://academic.oup.com/iwc/article/28/1/27/2363584
> <https://academic.oup.com/iwc/article/28/1/27/2363584>.
>
>
So the IgNobel Prizes are out, and the “winner" of the literature prize is
"Life Is Too Short to RTFM: How Users Relate to Documentation and "Excess
Features in Consumer Products”,
https://academic.oup.com/iwc/article/28/1/27/2363584
<https://academic.oup.com/iwc/artic
David,
I am not sure what is the best way to work on the new documentation with
you. One way fo doing it would be for me to fork your personal repository
into mine. I can then add the changes into your bug branch, push them to my
PR and then create a pull request to your PR to pull the changes
le to get it by rebasing your repository to the maint
> > branch of the gnucash-docs Github repository. I only know enough git to be
> > dangerous so am not the best source of advice on how exactly to do that at
> > this stage. I am starting to understand what is going on now. I ha
If an attacker guesses the path a -Indexes directive won’t stop him from
requesting the directory from the server. It should return a 403 if there’s no
index.html, but perhaps there are servers out there that fail, or perhaps the
web design folks think that a blank page is better than a 403.
Op vrijdag 14 september 2018 16:55:33 CEST schreef David T. via gnucash-devel:
> Hello,
>
> As I am toiling through the depths of the documentation generation process,
> I am struck by the fact that the base page of the Help is “help.html”,
> while the base page for the guide
Interesting. I’ll investigate. I’ve never had an issue that I’m aware of. If
the server won’t even let you get there due to the directive...?
Regards,
Adrien
> On Sep 14, 2018, at 5:38 PM, John Ralls wrote:
>
> It's my understanding that that's less than perfect. It's standard practice
> in
xactly to do that at
> this stage. I am starting to understand what is going on now. I have used
> git for quite a few years to my own repository but am now getting used to
> the 3 way operation for code and documentation updates to GnuCash.
>
> David Cousens
>
>
>
>
is going on now. I have used
git for quite a few years to my own repository but am now getting used to
the 3 way operation for code and documentation updates to GnuCash.
David Cousens
-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> On Sep 14, 2018, at 9:24 AM, Adrien Monteleone
> wrote:
>
>
>
>> On Sep 14, 2018, at 11:10 AM, John Ralls wrote:
>>
>>
>> We should change the name of gnucash-guide/index.html, but we should also
>> insert an index.html into every directory that raises an error to prevent
>> direct
evel@gnucash.org>> wrote:
>>
>> Hello,
>>
>> As I am toiling through the depths of the documentation generation process,
>> I am struck by the fact that the base page of the Help is “help.html”, while
>> the base page for the guide is “index.html”.
>&g
> On Sep 14, 2018, at 11:10 AM, John Ralls wrote:
>
>
> We should change the name of gnucash-guide/index.html, but we should also
> insert an index.html into every directory that raises an error to prevent
> direct browsing; user access should be via https://www.gnucash.org/docs.phtml
>
> On Sep 14, 2018, at 7:55 AM, David T. via gnucash-devel
> wrote:
>
> Hello,
>
> As I am toiling through the depths of the documentation generation process, I
> am struck by the fact that the base page of the Help is “help.html”, while
> the base page for
ct via GitHub.com.
While true I doubt this is what Frank was referring to. As I understood he was
referring to the directory structure where the nightly documentation builds
are uploaded. And to make this upload easier the built docs are structured the
way they are.
And yes, this may be slightl
>> My build folder hierarchy is:
>>>
>>> build
>>>
>>> \guide
>>>
>>> \C
>>> \de
>>>
>>> [etc.]
>>>
>>> \help
>>>
>>> \C
>>> \de
>>>
>>> [et
; \help
> >
> >\C
> >\de
> >
> > [etc.]
> >
> > IOW, the guide and help have separate hierarchies in build. I have no
> > connection to code.gnucash.org, and have no knowledge as to how the
> > information is stored there. IS
> On Sep 14, 2018, at 7:38 AM, David T. via gnucash-devel
> wrote:
>
>
>
>> On Sep 14, 2018, at 10:28 AM, Frank H. Ellenberger
>> wrote:
>>
>>
>>
>> Am 14.09.18 um 15:57 schrieb David T. via gnucash-devel:
>>> For fullest consistency, I would opt to have each of the formats placed in
Hello,
As I am toiling through the depths of the documentation generation process, I
am struck by the fact that the base page of the Help is “help.html”, while the
base page for the guide is “index.html”.
For consistency, I suggest naming the guide base page “guide.html”; moreover, I
suggest
> On Sep 14, 2018, at 10:28 AM, Frank H. Ellenberger
> wrote:
>
>
>
> Am 14.09.18 um 15:57 schrieb David T. via gnucash-devel:
>> For fullest consistency, I would opt to have each of the formats placed in
>> their own folder, named for tehir format:
>>
>> epub *
>> html
>> mobi *
>> pdf *
Am 14.09.18 um 15:57 schrieb David T. via gnucash-devel:
> For fullest consistency, I would opt to have each of the formats placed in
> their own folder, named for tehir format:
>
> epub *
> html
> mobi *
> pdf *
*: Why do you want to create a directory for one file?
>
> (adding
tps://wiki.gnucash.org/wiki/Initializing_Documentation_Build_Environment>)
and the reference to this information was moved up to Section 2. Setting Up
Your System.
Here we have an example of how duplicative information ends up in our ecosystem!
For the future, we should change the Documen
Geert,
> On Sep 14, 2018, at 3:17 AM, Geert Janssens
> wrote:
> This was done to be able to separate html output from the other formats.
>
> pdf, ebub and mobi all output one single file. html outputs a whole series of
> files. Putting those in their own directory creates one entry point per
Op vrijdag 14 september 2018 04:05:14 CEST schreef David T. via gnucash-devel:
> Hello,
>
> In trying to deal with compiling the documentation, I have been trying to
> use the newer “make” methods for building the html docs. I am wondering why
> these commands create the output in
Hello,
In trying to deal with compiling the documentation, I have been trying to use
the newer “make” methods for building the html docs. I am wondering why these
commands create the output in a new directory within the language
trees—respectively, “gnucash-guide” and "gnucash-help”. I
The typo came about because threw the changes back together quickly before
dinner
I adopted option 1, and it seems to have worked. Not sure how this is any
better.
David
> On Sep 13, 2018, at 8:05 PM, Frank H. Ellenberger
> wrote:
>
> Am 14.09.18 um 00:38 schrieb David T.:
>> Updated as
Am 14.09.18 um 00:38 schrieb David T.:
> Updated as requested. My commit message includes the full output of "xmllint
> --valid --noout gnucash-guide.xml”
>
> BTW, this sort of experience is yet another example of why I find this
> overall process to be inordinately painful. Some docbook guru
Updated as requested. My commit message includes the full output of "xmllint
--valid --noout gnucash-guide.xml”
BTW, this sort of experience is yet another example of why I find this overall
process to be inordinately painful. Some docbook guru will probably know
immediately why this fails,
Op donderdag 13 september 2018 14:32:12 CEST schreef D via gnucash-devel:
> Frank,
>
> It's not in my repo because I couldn't get it to compile. To get it to
> compile, I had to incorporate the content of each file into ch_basics.xml.
>
> AFAICT, the new files, ch_importing.xml and
Frank,
It's not in my repo because I couldn't get it to compile. To get it to compile,
I had to incorporate the content of each file into ch_basics.xml.
AFAICT, the new files, ch_importing.xml and ch_configuring.xml, are in my repo,
attached to my bug-796855 branch. So are ch_accts.xml and
Help manual -Transactions chapter 6
>covering importing from OFX/QFX, CSV, and QIF
>including the changes to the import matcher, which is nearly complete and
>fitted in before the stub that is there for
>online actions. As yet I haven't raised a documentation bug about that
>If
David,
Am 13.09.2018 um 02:46 schrieb David T. via gnucash-devel:
> I tried to retain ch_accts.xml and ch_txns.xml in gnucash-guide.xml
> and simply edit the three files so that they became parts of a single
> chapter, but this resulted in mysterious “Failure to process entity chapter2”
>
QFX, CSV, and QIF
including the changes to the import matcher, which is nearly complete and
fitted in before the stub that is there for
online actions. As yet I haven't raised a documentation bug about that
If you haven't started writing the importing section, I could feed what I have
done so far to
1 - 100 of 874 matches
Mail list logo
