Re: [GNC-dev] Documentation update problems

[John Ralls]

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 gnucash` 
installs everything you need to build 2.6; there are a few additional packages 
(cmake, ninja, swig, xsltproc, libgtk-3-dev, libboost-all-dev, googletest, and 
libwebkit2gtk-3.0-dev) to build 3. After that it’s the same directory creation, 
clone gnucash.git, cmake, and ninja reqardless of distro version.

Regards,
John Ralls


> On Sep 18, 2018, at 6:52 PM, David Cousens  wrote:
> 
> 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 supported by Canonical.
>> (wasn’t even a Long Term Support release) And there is not even a hardware 
>> reason that anyone should be running it. I
>> don’t even think the repos for it are even available any longer.
>> 
>> The oldest supported Ubuntu version is 14.04 (and then only until next 
>> April) I shouldn’t think any build instructions
>> are necessary (unless in an archived page if desired) for anything older 
>> than this.
>> 
>>> 
 The main building page is a massive tome. I did start breaking out some
 parts of it into smaller logical chunks when I updated the BuildUbuntu16.04
 ( which covers 16.04, 18.04 and Linux MInt 18 and 19 in effect.). 
>>> 
>>> Shouldn’t it be renamed to BuildUbuntu then?
>> 
>> I agree, the link text/page title is confusing and there have already been 
>> questions about what instructions to use
>> for building on 18.04.(yes, I see that it says this is for 18.04 as well, 
>> but clearly someone didn’t or they wouldn’t
>> have asked)
>> 
>> If replacing content with a link to a dedicated page is desired practice for 
>> cleaning up the wiki, then I’d propose
>> all of the material for building on Ubuntu be moved to that page, that it be 
>> renamed simply BuildUbuntu and that the
>> main build page be left with a link to it for the Ubuntu section. As it is, 
>> the original build page still contains
>> long outdated info. I would have instead expected to see the most current 
>> instructions there and then maybe a link for
>> older versions.
> 
> Adrien ,John
> 
> I too think the break out from that main page  could be better structured and 
> the BuildingUbuntu16.04 renamed something
> like BuildingUbuntu I had intended to address that after 
> rewriting the BuildUbuntu16.04 but ended up
> distracted with other priorities. 
> 
> Also the main page could perhaps have a one line breakout to a Building on 
> Linux page. The page name as long as it is
> descriptive to some extent is less important than the information in the link 
> specifying what it links to e.g.
> [[BuildingUbuntu | Building on Ubuntu 16.04, 18.04 and Linux 
> Mint]]. Despite this I think it is important to
> get to the information the user will actually use in the minimum number of 
> steps. Wiki navigation can be  dodgy at
> times. I would propose a link to the at least the general Building page 
> somewhere on the wiki entry point page might
> help achieve that given John's comment and info in another post on searching 
> of wiki pages.
> 
> David Cousens
>> 
>> 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 instructions is a
>> bit messy in that regard.
>> 
>> Regards,
>> Adrien
>> ___
>> 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 
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Documentation update problems

[David Cousens]

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 supported by Canonical.
> (wasn’t even a Long Term Support release) And there is not even a hardware 
> reason that anyone should be running it. I
> don’t even think the repos for it are even available any longer.
> 
> The oldest supported Ubuntu version is 14.04 (and then only until next April) 
> I shouldn’t think any build instructions
> are necessary (unless in an archived page if desired) for anything older than 
> this.
> 
> > 
> > > The main building page is a massive tome. I did start breaking out some
> > > parts of it into smaller logical chunks when I updated the 
> > > BuildUbuntu16.04
> > > ( which covers 16.04, 18.04 and Linux MInt 18 and 19 in effect.). 
> > 
> > Shouldn’t it be renamed to BuildUbuntu then?
> 
> I agree, the link text/page title is confusing and there have already been 
> questions about what instructions to use
> for building on 18.04.(yes, I see that it says this is for 18.04 as well, but 
> clearly someone didn’t or they wouldn’t
> have asked)
> 
> If replacing content with a link to a dedicated page is desired practice for 
> cleaning up the wiki, then I’d propose
> all of the material for building on Ubuntu be moved to that page, that it be 
> renamed simply BuildUbuntu and that the
> main build page be left with a link to it for the Ubuntu section. As it is, 
> the original build page still contains
> long outdated info. I would have instead expected to see the most current 
> instructions there and then maybe a link for
> older versions.

Adrien ,John

I too think the break out from that main page  could be better structured and 
the BuildingUbuntu16.04 renamed something
like BuildingUbuntu I had intended to address that after rewriting 
the BuildUbuntu16.04 but ended up
distracted with other priorities. 

Also the main page could perhaps have a one line breakout to a Building on 
Linux page. The page name as long as it is
descriptive to some extent is less important than the information in the link 
specifying what it links to e.g.
[[BuildingUbuntu | Building on Ubuntu 16.04, 18.04 and Linux 
Mint]]. Despite this I think it is important to
get to the information the user will actually use in the minimum number of 
steps. Wiki navigation can be  dodgy at
times. I would propose a link to the at least the general Building page 
somewhere on the wiki entry point page might
help achieve that given John's comment and info in another post on searching of 
wiki pages.

David Cousens
> 
> 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 instructions is a
> bit messy in that regard.
> 
> Regards,
> Adrien
> ___
> 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: [GNC-dev] Documentation Redo

[David Cousens]

On Tue, 2018-09-18 at 10:58 -0400, David T. via gnucash-devel wrote:
> Hello,
> 
> Once again, my words have gotten the better of me. I apologize for the length 
> of this message...
> 
> I have to admit that I do not understand what part of this research qualifies 
> it for an IgNobel—was it the “well,
> duh!” aspect, or was it that these folks took seven years to determine this, 
> or was it that they were able to convince
> some funding agency to support it the whole time?
> 
> Setting that aside for a moment, it *is* useful to acknowledge that most 
> people’s help preference is “to click around
> and get help when I need it.” TBH, that’s my style—although once I’ve done 
> that a while, I am quite likely to sit down
> and read in more depth. While I doubt anyone is eager to strip out features 
> from GnuCash (Budgets, anyone?), I think
> we *can* consider that perhaps our assistance modes might need to be 
> reconsidered.
> 
> I have been focused on moving detailed information OUT of Help and putting it 
> INTO the Guide, based on my own
> preferences and experiences with GnuCash. Perhaps that is misguided, insofar 
> as most users aren’t turning to this
> resource consistently.

David,

I spent a lot of time documenting a program a colleague and I wrote in the 
1980s for trace element analyis using nuclear
methods on an accelerator for a non-technical user base (largely geologists). 
We found the most useful way was not to
try and explain the physics and technical details of the process up front, but 
to give the user a basic process recipe
to follow to achieve the desired outcome and then only provide deeper levels of 
information as users requested it when
they understood they had a need to know more. We had a captive geologist in our 
group of physicists who we used as a
test subject (ex Professor of Geology at University of Oslo) to refine our 
efforts. Geologists at that time generally
didn't have much computing background but knew what they wanted to do whereas 
we knew 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 much the same manner as you. Deeply enough to achieve 
my current objective and (sometimes)
returning for more depth when required - git/github is a current example there 
for me.

I think it is possible to build a system with the guide as the primary 
interface linking to the specific more detailed
"what does this button do" type of information and simultaneously provide a 
second interface to the same detailed
information which is structured more around the program interface structure 
linking to the same basic material. To get
that sort of flexibility though you have to invest deeper into the docbook (or 
similar) technology.

> 
> Assuming that a well-written but overlooked Guide is the proverbial falling 
> tree in the forest, how should we be
> leading the Roaming Clicker to our oasis of Help? I think it is clear from 
> the list traffic that we have quite 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 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 it 
> here. We should transition the Context Help
> to contain brief descriptions with a “For more on this topic, see” link to 
> the Guide in every instance. I believe this
> would support the needs of Roaming Clickers reasonably well, using the 
> resources we have already got.
> 
> One major impediment to this is the linking features in our sources. There is 
> little that can be done about this,
> however, short of changing our platform altogether—which past experience 
> shows is doomed to stir up a lot of
> discussion with no ultimate change (“Full of sound and fury” comes to mind). 
> As I see it, one of the major challenges
> in creating links is that we currently have no naming practices for the 
> documents. This causes burdens: which elements
> receive tags? how do we form the names to assign? and on the other side, what 
> name do I need to put in to link to the
> other? If we can establish *what* should get labels, and *how* we label them, 
> I believe it would smooth a great deal
> of this process out. (Even better would be a means to use variables for 
> these, so that references could automagically
> be generated without a user keying in a long link label. How cool would that 
> be?).

docbook at least,  has a structure for addressing this problem. (I haven't 
looked 

Re: [GNC-dev] Documentation Redo

[Frank H. Ellenberger]

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 
> there some way to add a canned search of the wiki to context help? This 
> canned search would allow the user to retrieve information on the wiki as it 
> existed at the time of the search, rather than at the time of the help 
> authorship.

I don't know off hand, but we can at least add the following and could
probably add menu point in gnucashs help menu :
>From 8f3d722a8830394e8916fc2a72ba4a8e3a17445c Tue, 18 Sep 2018 20:38:08
+0200
From: Frank H. Ellenberger 
Date: Tue, 18 Sep 2018 20:36:37 +0200
Subject: [PATCH] Add Wiki Search page to Getting Help

diff --git a/help/C/Help_ch_GettingHelp.xml b/help/C/Help_ch_GettingHelp.xml
index d940810..5e5a659 100644
--- a/help/C/Help_ch_GettingHelp.xml
+++ b/help/C/Help_ch_GettingHelp.xml
@@ -115,6 +115,8 @@
  Questions page should be a first stop whenever you
  encounter difficulty using
  .
+ You should also try its
+ https://wiki.gnucash.org/wiki/Special:Search;>search
page





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

Re: [GNC-dev] Documentation update problems

[Adrien Monteleone]

> 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 
>> instructions is a bit messy in that regard.
> 
> Older content should be removed altogether, not archived.

I should have specified that what I meant by ‘older material’ was the 
instructions for say building 2.6.x using Autotools instead of Cmake, or 
building either 2.6.x or 3.x on 14.04. (which admittedly will be unsupported in 
less than 8 months) Obsolete instructions should be removed entirely. But if 
something changes between now and say Ubuntu 20.04 that would necessitate 
different treatment, then the current instructions should be archived or bumped 
down the page, not removed, because 16.04 & 18.04 will still be supported and 
in active use.

Though, and I may be misunderstanding the GnuCash support policy, if 2.6.x is 
not being actively developed (is that not the same thing as ‘not supported’?) 
then the recipe should be for 3.x with Cmake only.

As for different architectures and distros, I should think any notes are just 
specific quirks based on what may or may not be on the system by default. I 
should think the dependencies are what they are, and the recipe should be the 
same. (disclosure - I’m not familiar with building on a regular basis on 
different systems other than MacOS and Ubuntu/Debian)

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

Re: [GNC-dev] ImpEx Sample files

[Frank H. Ellenberger]

Am 18.09.18 um 18:47 schrieb David T.:
> 
> 
>> On Sep 18, 2018, at 11:46 AM, Frank H. Ellenberger 
>>  wrote:
>>
>> DTA
>> https://de.wikipedia.org/wiki/Datentr%C3%A4geraustauschverfahren
>> Was introduced by the german bank association ZKA
>> - today: https://die-dk.de/en/ -
>> in 1976 for magnetic tapes, later floppies, ...
>> 2016-02-01 it was officially abandoned and replaced by
>> B2B:
>> https://en.wikipedia.org/wiki/Electronic_Banking_Internet_Communication_Standard,
>> else: the above-mentioned ISO20022 (XML-Format).
>>
>> While the wikipedia page describes the structure IMHO there is no need
>> to document a abandoned format.
>>
> 
> If the format is abandoned, does GnuCash have to import it?
> 

Good question! I will ask on gnucash-de, if there are still users.
If we get no feedback, we can consider to remove it.

Frank


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

Re: [GNC-dev] Documentation update problems

[David T. via gnucash-devel]

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 obtain source code and compile it on their 
machines? IOW, rather than offer voluminous directions on how to obtain the 
sources and compile GnuCash on every variant of YetiCompute, could we simply 
advise the majority of the community (yetis included) to use git to clone our 
repos and compile using git? It seems to me to be a colossal waste of community 
effort to attempt to account for every flavor of every distro. I contrast this 
with the (IMHO correct) stance on encryption, in which circumstance we advise 
users to find appropriate encryption tools, rather than build a half-crap 
version of our own.

Focusing our efforts on *a* GnuCash Way of building the program would simplify 
the wiki immensely.

> On Sep 18, 2018, at 12:18 PM, Adrien Monteleone 
>  wrote:
>> 
>>> The main building page is a massive tome. I did start breaking out some
>>> parts of it into smaller logical chunks when I updated the BuildUbuntu16.04
>>> ( which covers 16.04, 18.04 and Linux MInt 18 and 19 in effect.). 
>> 
>> Shouldn’t it be renamed to BuildUbuntu then?
> 
> I agree, the link text/page title is confusing and there have already been 
> questions about what instructions to use for building on 18.04.(yes, I see 
> that it says this is for 18.04 as well, but clearly someone didn’t or they 
> wouldn’t have asked)

If we continue with the Massive Tome Approach, I would recommend a title of 
“Building on Ubuntu"

> 
> If replacing content with a link to a dedicated page is desired practice for 
> cleaning up the wiki, then I’d propose all of the material for building on 
> Ubuntu be moved to that page, that it be renamed simply BuildUbuntu and that 
> the main build page be left with a link to it for the Ubuntu section. As it 
> is, the original build page still contains long outdated info. I would have 
> instead expected to see the most current instructions there and then maybe a 
> link for older versions.
> 
> 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 instructions is a 
> bit messy in that regard.

Older content should be removed altogether, not archived.


> 
> Regards,
> Adrien
> ___
> 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: [GNC-dev] Documentation Redo

[John Ralls]

> On Sep 18, 2018, at 7:58 AM, David T.  wrote:
> 
> Hello,
> 
> Once again, my words have gotten the better of me. I apologize for the length 
> of this message...
> 
> I have to admit that I do not understand what part of this research qualifies 
> it for an IgNobel—was it the “well, duh!” aspect, or was it that these folks 
> took seven years to determine this, or was it that they were able to convince 
> some funding agency to support it the whole time?
> 
> Setting that aside for a moment, it *is* useful to acknowledge that most 
> people’s help preference is “to click around and get help when I need it.” 
> TBH, that’s my style—although once I’ve done that a while, I am quite likely 
> to sit down and read in more depth. While I doubt anyone is eager to strip 
> out features from GnuCash (Budgets, anyone?), I think we *can* consider that 
> perhaps our assistance modes might need to be reconsidered.
> 
> I have been focused on moving detailed information OUT of Help and putting it 
> INTO the Guide, based on my own preferences and experiences with GnuCash. 
> Perhaps that is misguided, insofar as most users aren’t turning to this 
> resource consistently.
> 
> Assuming that a well-written but overlooked Guide is the proverbial falling 
> tree in the forest, how should we be leading the Roaming Clicker to our oasis 
> of Help? I think it is clear from the list traffic that we have quite 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 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 
> it here. We should transition the Context Help to contain brief descriptions 
> with a “For more on this topic, see” link to the Guide in every instance. I 
> believe this would support the needs of Roaming Clickers reasonably well, 
> using the resources we have already got.
> 
> One major impediment to this is the linking features in our sources. There is 
> little that can be done about this, however, short of changing our platform 
> altogether—which past experience shows is doomed to stir up a lot of 
> discussion with no ultimate change (“Full of sound and fury” comes to mind). 
> As I see it, one of the major challenges in creating links is that we 
> currently have no naming practices for the documents. This causes burdens: 
> which elements receive tags? how do we form the names to assign? and on the 
> other side, what name do I need to put in to link to the other? If we can 
> establish *what* should get labels, and *how* we label them, I believe it 
> would smooth a great deal of this process out. (Even better would be a means 
> to use variables for these, so that references could automagically be 
> generated without a user keying in a long link label. How cool would that 
> be?).
> 
> 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 
> there some way to add a canned search of the wiki to context help? This 
> canned search would allow the user to retrieve information on the wiki as it 
> existed at the time of the search, rather than at the time of the help 
> authorship.
> 
> I imagine here that the Context Help writer would enter a couple of terms 
> into a slot in the Help entry that would then be tacked on to a wiki search 
> (and, yes, I am already thinking that a structured storage such as SQL might 
> be a better approach to manage this). I will note that such wiki search 
> functionality would of necessity require improvement of the wiki search 
> feature, and perhaps a restructuring of how the wiki is created. My attempt 
> to search the wiki for the entry on adjusting column widths 
> (https://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_resize_my_register_columns.3F_Why_can_I_not_shrink_the_description_column.3F)
>  was less than successful. Any search I entered at the wiki search box 
> returned a link to the general FAQ page, which doesn’t help. Similar attempts 
> using Google were unsuccessful as well (why *are* the pdf copies of the 
> documentation stored on wiki.gnucash.org as well at www.gnucash.org—or are 
> they the same files?).

Well, the title made *me* laugh, and the paper has clearly gotten us thinking, 
so it fulfills the IgNobel mission, to identify research “that makes you laugh, 
then makes you think”.

Anyway, on to how to structure the documentation.

Links between context help and the Guide should be pretty straightforward, 
though at present they depend on the DocBook xslt doing the right thing across 

Re: [GNC-dev] ImpEx Sample files

[David T. via gnucash-devel]

> On Sep 18, 2018, at 11:46 AM, Frank H. Ellenberger 
>  wrote:
> 
> DTA
> https://de.wikipedia.org/wiki/Datentr%C3%A4geraustauschverfahren
> Was introduced by the german bank association ZKA
> - today: https://die-dk.de/en/ -
> in 1976 for magnetic tapes, later floppies, ...
> 2016-02-01 it was officially abandoned and replaced by
> B2B:
> https://en.wikipedia.org/wiki/Electronic_Banking_Internet_Communication_Standard,
> else: the above-mentioned ISO20022 (XML-Format).
> 
> While the wikipedia page describes the structure IMHO there is no need
> to document a abandoned format.
> 

If the format is abandoned, does GnuCash have to import it?


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

Re: [GNC-dev] Documentation update problems

[Adrien Monteleone]

> 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 not even a hardware reason that anyone should be running it. I don’t 
even think the repos for it are even available any longer.

The oldest supported Ubuntu version is 14.04 (and then only until next April) I 
shouldn’t think any build instructions are necessary (unless in an archived 
page if desired) for anything older than this.

> 
>> The main building page is a massive tome. I did start breaking out some
>> parts of it into smaller logical chunks when I updated the BuildUbuntu16.04
>> ( which covers 16.04, 18.04 and Linux MInt 18 and 19 in effect.). 
> 
> Shouldn’t it be renamed to BuildUbuntu then?

I agree, the link text/page title is confusing and there have already been 
questions about what instructions to use for building on 18.04.(yes, I see that 
it says this is for 18.04 as well, but clearly someone didn’t or they wouldn’t 
have asked)

If replacing content with a link to a dedicated page is desired practice for 
cleaning up the wiki, then I’d propose all of the material for building on 
Ubuntu be moved to that page, that it be renamed simply BuildUbuntu and that 
the main build page be left with a link to it for the Ubuntu section. As it is, 
the original build page still contains long outdated info. I would have instead 
expected to see the most current instructions there and then maybe a link for 
older versions.

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 instructions is a 
bit messy in that regard.

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

Re: [GNC-dev] ImpEx Sample files

[Frank H. Ellenberger]

Am 18.09.18 um 15:00 schrieb David Cousens:
> One problem I will have is getting sample files for the MT940, MT942 and 
> DTAUS formats so I can run through the
> interfaces. I have a friend who was a manager with Deutsche Bank a few years 
> ago but Klaus is now working for another
> company in Melbourne.
>
> If you know where I can find any sample files I would appreciate getting hold 
> of them.  It would be good to have a
> collection of  sample files for testing Gnucash in any case as part of the 
> program. No problem for the internal ones
> that Gnucash can export. 

In theory we keep a set of sample files in
https://github.com/Gnucash/gnucash/tree/maint/doc/examples and might add
the missing there, if we get them, too.

MTxxx formats
https://en.wikipedia.org/wiki/SWIFT_message_types
are defined by SWIFT
https://en.wikipedia.org/wiki/Society_for_Worldwide_Interbank_Financial_Telecommunication

There is Transition in progess from ISO 7775 over ISO 15022 to ISO 20022
The genaral standard
https://en.wikipedia.org/wiki/ISO_15022
has in 2 flavours:
traditional line oriented MT-formats (message types)
and modern UNIFI (ISO 20022) xml files aka MX-format
https://en.wikipedia.org/wiki/ISO_20022
Often the german wiki page has more details like field descritions. But
I didn't see nice example files.

DTA
https://de.wikipedia.org/wiki/Datentr%C3%A4geraustauschverfahren
Was introduced by the german bank association ZKA
- today: https://die-dk.de/en/ -
in 1976 for magnetic tapes, later floppies, ...
2016-02-01 it was officially abandoned and replaced by
B2B:
https://en.wikipedia.org/wiki/Electronic_Banking_Internet_Communication_Standard,
else: the above-mentioned ISO20022 (XML-Format).

While the wikipedia page describes the structure IMHO there is no need
to document a abandoned format.

So, if you think we should add example files we should ask on
gnucash-user and gnucash-de.

> Best wishes 
> David (Cousens)

~Frank

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

Re: [GNC-dev] Documentation Redo

[David T. via gnucash-devel]

Hello,

Once again, my words have gotten the better of me. I apologize for the length 
of this message...

I have to admit that I do not understand what part of this research qualifies 
it for an IgNobel—was it the “well, duh!” aspect, or was it that these folks 
took seven years to determine this, or was it that they were able to convince 
some funding agency to support it the whole time?

Setting that aside for a moment, it *is* useful to acknowledge that most 
people’s help preference is “to click around and get help when I need it.” TBH, 
that’s my style—although once I’ve done that a while, I am quite likely to sit 
down and read in more depth. While I doubt anyone is eager to strip out 
features from GnuCash (Budgets, anyone?), I think we *can* consider that 
perhaps our assistance modes might need to be reconsidered.

I have been focused on moving detailed information OUT of Help and putting it 
INTO the Guide, based on my own preferences and experiences with GnuCash. 
Perhaps that is misguided, insofar as most users aren’t turning to this 
resource consistently.

Assuming that a well-written but overlooked Guide is the proverbial falling 
tree in the forest, how should we be leading the Roaming Clicker to our oasis 
of Help? I think it is clear from the list traffic that we have quite 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 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 it 
here. We should transition the Context Help to contain brief descriptions with 
a “For more on this topic, see” link to the Guide in every instance. I believe 
this would support the needs of Roaming Clickers reasonably well, using the 
resources we have already got.

One major impediment to this is the linking features in our sources. There is 
little that can be done about this, however, short of changing our platform 
altogether—which past experience shows is doomed to stir up a lot of discussion 
with no ultimate change (“Full of sound and fury” comes to mind). As I see it, 
one of the major challenges in creating links is that we currently have no 
naming practices for the documents. This causes burdens: which elements receive 
tags? how do we form the names to assign? and on the other side, what name do I 
need to put in to link to the other? If we can establish *what* should get 
labels, and *how* we label them, I believe it would smooth a great deal of this 
process out. (Even better would be a means to use variables for these, so that 
references could automagically be generated without a user keying in a long 
link label. How cool would that be?).

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 
there some way to add a canned search of the wiki to context help? This canned 
search would allow the user to retrieve information on the wiki as it existed 
at the time of the search, rather than at the time of the help authorship.

I imagine here that the Context Help writer would enter a couple of terms into 
a slot in the Help entry that would then be tacked on to a wiki search (and, 
yes, I am already thinking that a structured storage such as SQL might be a 
better approach to manage this). I will note that such wiki search 
functionality would of necessity require improvement of the wiki search 
feature, and perhaps a restructuring of how the wiki is created. My attempt to 
search the wiki for the entry on adjusting column widths 
(https://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_resize_my_register_columns.3F_Why_can_I_not_shrink_the_description_column.3F)
 was less than successful. Any search I entered at the wiki search box returned 
a link to the general FAQ page, which doesn’t help. Similar attempts using 
Google were unsuccessful as well (why *are* the pdf copies of the documentation 
stored on wiki.gnucash.org as well at www.gnucash.org—or are they the same 
files?).

Cheers,
David

> On Sep 16, 2018, at 11:11 PM, 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 Documentation and "Excess 
> Features in Consumer Products”, 
> https://academic.oup.com/iwc/article/28/1/27/2363584 
> .
> 
> Maybe instead of doing a rewrite we should just bin the lot and put the 
> effort into stripping GnuCash down to the bare essentials.
> 
> 
> ;-)
> 
> Regards,
> John Ralls
> 
> 
> 

Re: [GNC-dev] Git Questions With Documentation

[John Ralls]

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 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 a second repo on my
> computer so I should be able to feed any material to him through that. David 
> suggested I add sections on the other
> import  facilities i.e. DTAUS MT940 and MT942 I'm happy to do that but it 
> will be easier if I can do the changes here
> then send david a pull request. 
> 
> One problem I will have is getting sample files for the MT940, MT942 and 
> DTAUS formats so I can run through the
> interfaces. I have a friend who was a manager with Deutsche Bank a few years 
> ago but Klaus is now working for another
> company in Melbourne.
> 
> If you know where I can find any sample files I would appreciate getting hold 
> of them.  It would be good to have a
> collection of  sample files for testing Gnucash in any case as part of the 
> program. No problem for the internal ones
> that Gnucash can export. 
> Best wishes 
> David (Cousens)
> 
> On Tue, 2018-09-18 at 13:15 +0200, Frank H. Ellenberger wrote:
>> 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 repository github wasn't letting me fork your repository
>>> separately. It basically told me I already had that repository so no go. I
>>> could delete my copy of the main Gnucash repository and maybe then it would
>>> let me do it.
>> 
>> You can at least pull branches of forks like "BugXXX" in the repo on
>> your local machine. Usually you do not want to pull the maint and master
>> branch from forks under the same name.
>> 
>> I don't know, if it can also be done on the Github Web interface.
>> Perhaps David T. and Geert should document their progress in the wiki?
>> 
>>> One other way to do it may be to create the bug branch for the doc update   
>>> in the main Gnucash repository if John and Geert are willing to do that.   
>> 
>> David T. already pulled your work in
>> https://github.com/Gnucash/gnucash-docs/pull/115/commits
>> 
>>> something along the lines of the approach in the answer to this may be
>>> useful.
>>> https://stackoverflow.com/questions/14865283/proper-git-workflow-scheme-with-multiple-developers-working-on-same-tas
>>> k.
>>> 
>>> David Cousens
>> 
>> Frank
>> 
> ___
> 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: [GNC-dev] Git Questions With Documentation

[David T. via gnucash-devel]

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 experience, and have reasonable technical 
writing sensibilities, I have demonstrated over the years a profound and 
preternatural ability to mess up this documentation process. Placing your trust 
in my skills and abilities is likely to lead to trouble.

David

> On Sep 18, 2018, at 9: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 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 a second repo on my
> computer so I should be able to feed any material to him through that. David 
> suggested I add sections on the other
> import  facilities i.e. DTAUS MT940 and MT942 I'm happy to do that but it 
> will be easier if I can do the changes here
> then send david a pull request. 
> 
> One problem I will have is getting sample files for the MT940, MT942 and 
> DTAUS formats so I can run through the
> interfaces. I have a friend who was a manager with Deutsche Bank a few years 
> ago but Klaus is now working for another
> company in Melbourne.
> 
> If you know where I can find any sample files I would appreciate getting hold 
> of them.  It would be good to have a
> collection of  sample files for testing Gnucash in any case as part of the 
> program. No problem for the internal ones
> that Gnucash can export. 
> Best wishes 
> David (Cousens)
> 
> On Tue, 2018-09-18 at 13:15 +0200, Frank H. Ellenberger wrote:
>> 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 repository github wasn't letting me fork your repository
>>> separately. It basically told me I already had that repository so no go. I
>>> could delete my copy of the main Gnucash repository and maybe then it would
>>> let me do it.
>> 
>> You can at least pull branches of forks like "BugXXX" in the repo on
>> your local machine. Usually you do not want to pull the maint and master
>> branch from forks under the same name.
>> 
>> I don't know, if it can also be done on the Github Web interface.
>> Perhaps David T. and Geert should document their progress in the wiki?
>> 
>>> One other way to do it may be to create the bug branch for the doc update   
>>> in the main Gnucash repository if John and Geert are willing to do that.   
>> 
>> David T. already pulled your work in
>> https://github.com/Gnucash/gnucash-docs/pull/115/commits
>> 
>>> something along the lines of the approach in the answer to this may be
>>> useful.
>>> https://stackoverflow.com/questions/14865283/proper-git-workflow-scheme-with-multiple-developers-working-on-same-tas
>>> k.
>>> 
>>> David Cousens
>> 
>> Frank
>> 
> ___
> 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: [GNC-dev] Git Questions With Documentation

[David Cousens]

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 a second repo on my
computer so I should be able to feed any material to him through that. David 
suggested I add sections on the other
import  facilities i.e. DTAUS MT940 and MT942 I'm happy to do that but it will 
be easier if I can do the changes here
then send david a pull request. 

One problem I will have is getting sample files for the MT940, MT942 and DTAUS 
formats so I can run through the
interfaces. I have a friend who was a manager with Deutsche Bank a few years 
ago but Klaus is now working for another
company in Melbourne.

If you know where I can find any sample files I would appreciate getting hold 
of them.  It would be good to have a
collection of  sample files for testing Gnucash in any case as part of the 
program. No problem for the internal ones
that Gnucash can export. 
Best wishes 
David (Cousens)

On Tue, 2018-09-18 at 13:15 +0200, Frank H. Ellenberger wrote:
> 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 repository github wasn't letting me fork your repository
> > separately. It basically told me I already had that repository so no go. I
> > could delete my copy of the main Gnucash repository and maybe then it would
> > let me do it.
> 
> You can at least pull branches of forks like "BugXXX" in the repo on
> your local machine. Usually you do not want to pull the maint and master
> branch from forks under the same name.
> 
> I don't know, if it can also be done on the Github Web interface.
> Perhaps David T. and Geert should document their progress in the wiki?
> 
> > One other way to do it may be to create the bug branch for the doc update   
> > in the main Gnucash repository if John and Geert are willing to do that.   
> 
> David T. already pulled your work in
> https://github.com/Gnucash/gnucash-docs/pull/115/commits
> 
> > something along the lines of the approach in the answer to this may be
> > useful.
> > https://stackoverflow.com/questions/14865283/proper-git-workflow-scheme-with-multiple-developers-working-on-same-tas
> > k.
> >   
> > David Cousens
> 
> Frank
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Documentation update problems

[Frank H. Ellenberger]

Hi David Cousens,

In general the wiki needs some modularization to reduce redundancy. That
means, where ever you see similar text, create a new page with the best
parts and replace the pold texts with a link.

OTOH there are different target groups from expirienced coders to less
techie first 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 instructions given in the Building Gnucash page.

It has been an orphan until yesterday because it has been a draft with
the intension to clarify some confusion about terms around "make". After
David T. confirmed the usability, we should replace similar texts in
other pages by a link, e.g.
https://wiki.gnucash.org/wiki/The_Make_Utility

> There is a fairly good example of dupllcation with it and the following for
> the Gnucash progarm build. 
> 
> https://wiki.gnucash.org/wiki/Building
> 
> and the breakout from it for recent Ubuntu versions
> 
> https://wiki.gnucash.org/wiki/BuildUbuntu16.04

In general I do not watch distro specific pages. While other created one
page, Ubunteros are "spamming" the wiki:
BuildGutsy, BuildUbuntu16.04, UbuntuShortcuts, Unity Shortcuts ...

Perhaps you can do some cleanup: Is Gutsy outdated?

> The main building page is a massive tome. I did start breaking out some
> parts of it into smaller logical chunks when I updated the BuildUbuntu16.04
> ( which covers 16.04, 18.04 and Linux MInt 18 and 19 in effect.). 

Shouldn't it be renamed to BuildUbuntu then?

> The Build Tools page may be a logical breakout from there with some
> of the detail in the first page cut into it. There is also a short
> summary recipe for building the Docs at the end of the
> BuildUbuntu16.04 page which lacks detail but does work on Ubuntu and
> most linux distros. It has no details about the dependencies in it
> though.
ISTR there are some fine parts, which should either go to Building or
get their own page linked from both.

> Would a page on building the docs be better as a breakout from the main
> building Gnucash page perhaps with a shared section on the build tools
> referenced from both. 

The Docs update page was once created by a documenter, who found the
general build page ways to complicate and was for a long time almost
untouched by code developers.

> For build instructions I ususaly find the recipe the
> most useful bit with explantions of the specific tools as breakouts. If you
> need the information and background you can follow the links. If you only do
> a build occasionally you follow the recipe.  I.e only read the manual when
> you have to.
> 
> David Cousens

Frank

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

Re: [GNC-dev] Git Questions With Documentation

[Geert Janssens]

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 repository github wasn't letting me fork your repository
> separately. It basically told me I already had that repository so no go. I
> could delete my copy of the main Gnucash repository and maybe then it would
> let me do it.
> 
Indeed it appears github will only allow one fork of a repo.

> One other way to do it may be to create the bug branch for the doc update
> in the main Gnucash repository if John and Geert are willing to do that.
> 
I prefer not to and I don't really see the need. There are other ways to 
collaborate.

There is not really anything special about the Gnucash/gnucash-docs repo. What 
you can do there, you can equally do with your personal forks.

And for that you even don't need to fork David T's repo. You can still pull 
requests against it from your current Gnucash/gnucash-docs fork. You would do 
so like any other pull request. The difference is that instead of going with 
the defaults proposed by github, you change the target repo to David T's repo 
(sunfish62).

You can publish your changes to your own fork and David T. can look at them 
there. Or you create PR's and then David T. can review them as part of his 
builds.

Yet another method could be that one of you adds the other as collaborator to 
your personal fork. In that case both of you can work directly on the same 
repo.

Regardless of the chosen route, be aware this will require more than basic 
understanding of how git works. You'll now be on the pulling end of a pull 
request, which means git's merge mechanics need to be understood.

Regards,

Geert


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

[GNC-dev] Git Questions With Documentation

[Frank H. Ellenberger]

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 repository github wasn't letting me fork your repository
> separately. It basically told me I already had that repository so no go. I
> could delete my copy of the main Gnucash repository and maybe then it would
> let me do it.

You can at least pull branches of forks like "BugXXX" in the repo on
your local machine. Usually you do not want to pull the maint and master
branch from forks under the same name.

I don't know, if it can also be done on the Github Web interface.
Perhaps David T. and Geert should document their progress in the wiki?

> One other way to do it may be to create the bug branch for the doc update   
> in the main Gnucash repository if John and Geert are willing to do that.   

David T. already pulled your work in
https://github.com/Gnucash/gnucash-docs/pull/115/commits

> something along the lines of the approach in the answer to this may be
> useful.
> https://stackoverflow.com/questions/14865283/proper-git-workflow-scheme-with-multiple-developers-working-on-same-task.
>   
> David Cousens

Frank

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

Re: [GNC-dev] gnucash maint: Update Overview of README

[Frank H. Ellenberger]

Hi Geert

Am 18.09.18 um 09:39 schrieb Geert Janssens:
> It looks like the actual changes in the README file didn't make it in this 
> commit ?
> 
> There's only a change in .gitignore.
> 
> Geert

Sorry, Eclipse had changed the commit dialog. Redone a commit 10811b8 .

Frank

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

Re: [GNC-dev] Git Questions With Documentation

[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 repository github wasn't letting me fork your repository
separately. It basically told me I already had that repository so no go. I
could delete my copy of the main Gnucash repository and maybe then it would
let me do it.

One other way to do it may be to create the bug branch for the doc update 
in the main Gnucash repository if John and Geert are willing to do that. 

something along the lines of the approach in the answer to this may be
useful.
https://stackoverflow.com/questions/14865283/proper-git-workflow-scheme-with-multiple-developers-working-on-same-task.

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.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Documentation update problems

[David Cousens]

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. 

https://wiki.gnucash.org/wiki/Building

and the breakout from it for recent Ubuntu versions

https://wiki.gnucash.org/wiki/BuildUbuntu16.04

The main building page is a massive tome. I did start breaking out some
parts of it into smaller logical chunks when I updated the BuildUbuntu16.04
( which covers 16.04, 18.04 and Linux MInt 18 and 19 in effect.). The Build
Tools page may be a logical breakout from there with some of the detail in
the first page cut into it. There is also a short summary recipe for
building the Docs at the end of the BuildUbuntu16.04 page which lacks detail
but does work on Ubuntu and most linux distros. It has no details about the
dependencies in it though.

Would a page on building the docs be better as a breakout from the main
building Gnucash page perhaps with a shared section on the build tools
referenced from both. For build instructions I ususaly find the recipe the
most useful bit with explantions of the specific tools as breakouts. If you
need the information and background you can follow the links. If you only do
a build occasionally you follow the recipe.  I.e only read the manual when
you have to.

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.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnucash maint: Update Overview of README

[Geert Janssens]

It looks like the actual changes in the README file didn't make it in this 
commit ?

There's only a change in .gitignore.

Geert

Op maandag 17 september 2018 22:31:16 CEST schreef Frank H. Ellenberger:
> Updatedvia  https://github.com/Gnucash/gnucash/commit/586cd704 
> (commit)
>   from  https://github.com/Gnucash/gnucash/commit/83b1b8ad (commit)
> 
> 
> 
> commit 586cd70432d4b9027a5e7f855ce6283c2098674f
> Author: Frank H. Ellenberger 
> Date:   Mon Sep 17 22:18:00 2018 +0200
> 
> Update Overview of README
> 
> based on
> https://lists.gnucash.org/pipermail/gnucash-devel/2018-September/042748.htm
> l
> 
> Additional changed "http" to "https", where available.
> 
> diff --git a/.gitignore b/.gitignore
> index 478f7a1..b74a6cf 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -243,3 +243,4 @@ DerivedData/
>  xcuserdata/
>  messages.mo
>  /.settings/
> +/build/
> 
> 
> 
> Summary of changes:
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
> 
> ___
> gnucash-changes mailing list
> gnucash-chan...@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-changes




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