Re: Proposed Additional Reports - provide simple comparison between multiple time periods e find capability

[Adrien Monteleone]

In the report options, use the accounts tab to select or de-select the accounts 
you want to include or not include. Trading accounts are listed at the bottom. 
If you don’t see them, drag the options window border down so it is taller.

Regards,
Adrien

> On Jun 23, 2017, at 2:44 PM, Vojtěch Fried  wrote:
> 
> Hi again,
> 
> one more thing I found playing with the report. It seems it is confused when
> there are transaction splits to/from Trading accounts. When sorting by Other
> account name, all transactions in my base currency are ok, but transactions
> in a foreign currency are all grouped together and the group header and
> footer (subtotal title) show different account names. I think the report
> should either ignore Trading accounts or group those transactions as Split
> transactions.
> 
> Vojtěch
> 
> 
> 
> --
> View this message in context: 
> http://gnucash.1415818.n4.nabble.com/Proposed-Additional-Reports-provide-simple-comparison-between-multiple-time-periods-e-find-capability-tp4692158p4692340.html
> Sent from the GnuCash - Dev mailing list archive at Nabble.com.
> ___
> 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: Time Frame on Wiki Edits

[Adrien Monteleone]

David,

It seems the edits you committed took care of most of the spelling/grammatical 
errors I noticed. I fixed a remaining one in the External Documentation section.

Concerning content, do we still need to point to the three ‘particular 
enhancement’ discussions at the bottom of the page? If anything, perhaps they 
should be listed under Old Discussions since all three of them have been 
implemented and their pages are dated by several years to a decade. I’d also 
think the Concept Guide link should perhaps have more to do with Documentation 
than an application feature. Perhaps it should be under Developing 
Documentation, or even not on this page at all and linked from the Developing 
Documentation page.

Just a thought.

Regards,
Adrien

> On Jun 14, 2017, at 9:01 AM, David T. <sunfis...@yahoo.com> wrote:
> 
> Thanks for the feedback. I’ve modified the page and incorporated most of your 
> changes. If there are specific typos or grammatical errors, could you either 
> fix them or point them out? My eyes aren’t what they used to be!
> 
> David
> 
>> On Jun 14, 2017, at 12:02 AM, Adrien Monteleone 
>> <adrien.montele...@gmail.com> wrote:
>> 
>> I see a few typos and grammatical errors, so I wouldn’t say it’s ready for 
>> publication yet.
>> 
>> As for organization, perhaps change [Scripting and Programming] to 
>> [“Advanced” Usage] or [“Advanced” Usage - Scripting & Programming]
>> 
>> I’d expect to find the info on Logging and Stack Trace to be either under 
>> Help or Filing Bugs. You could then probably eliminate the odd sounding 
>> ‘Error Seaching’ (sic) heading.
>> 
>> Also the way [Getting Involved in the Project] reads, the rest of the 
>> material that follows should be nested under it, which might be odd. Perhaps 
>> just keep the sentence but remove that heading entirely. It doesn’t seem 
>> necessary. Or since all of those topics including developing code are 
>> "getting involved” replace the main heading—[Developing for GnuCash] with 
>> [Getting Involved in the Project] or something similar like [Contributing to 
>> GnuCash]. The other headings and text can remain as is.
>> 
>> Overall though, this is laid out much better than the current version.
>> 
>> -Adrien
>> 
>> 
>>> On Jun 13, 2017, at 11:17 AM, David T. via gnucash-devel 
>>> <gnucash-devel@gnucash.org> wrote:
>>> 
>>> Hello,
>>> 
>>> Two weeks ago, after a flurry of discussion in this list, I and Don 
>>> (doncram) worked to put together a modified wiki landing page, which was 
>>> placed as a sandbox page at https://wiki.gnucash.org/wiki/GnuCash/sandbox 
>>> <https://wiki.gnucash.org/wiki/GnuCash/sandbox>.
>>> 
>>> Since that time, there has been no further activity on any front, and 
>>> although two weeks is not a very long time to let this season (as it were), 
>>> I do wonder whether the Developer team has any sense of what amount of time 
>>> constitutes “the right” amount of time for such a proposal to sit before 
>>> the changes are sent live. I’d like to get the page pushed out before it 
>>> gets lost in the mists of time…
>>> 
>>> David
>>> 
>>> @doncram: once it’s time to move this along, how exactly does one convert 
>>> the sandbox to its real counterpart?
>>> ___
>>> 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: Some Assistance Please

[Adrien Monteleone]

> On May 24, 2017, at 11:43 AM, Geert Janssens  
> wrote:
> 
> On woensdag 24 mei 2017 17:16:41 CEST Derek Atkins wrote:
>> Michael Ferrara  writes:
>>>There's no good way to translate from Wiki to PDF
>>> 
>>> Really? PDF can handle hard links within a document. Reference books with
>> 
>> Yes, really.  And it's more than just PDF.  We currently build the docs
>> into HTML, PDF, Mobi, and at least one other format.  There are no tools
>> that take wiki content and do that *and* make the results look good.
>> This is why we chose DocBook, and this is why we've stuck with it.
>> 
> The other formats:
> Windows HtmlHelp
> On linux the docboook files are used directly by yelp
> Both serve for for tight integration of our help and guide into the native 
> platforms.
> 
>> We've been down this road before.  I have no reason to believe that
>> today's tools do this any better than the tools last time we went down
>> this path of exploration.
> 
> Yes we never found a suitable replacement in the past. I'd love to be proven 
> wrong over this one though. If someone can show us new system that suits all 
> our requirements and is easier to use by non-developer volunteer that are 
> willing to help out, I'm all ears.
> 
> Geert

Geert,

If the opposite were possible, would that meet the needs?

If using the wiki as the collaboration platform opened up documentation editing 
to non-developer types but still gave you the desired formats, is that what you 
are looking for or are there other needs?

Looking over mediawiki.org, there are methods using our own render server (or a 
public one if so desired) and extension plugins to export a variety of formats 
including XHTML, PDF, ePUB, ZIM, ODF, and yes, DocBook XML. There’s also the 
option of using PediaPress for people to order a physical bound copy if they so 
desire.

The only one presently offered I don’t see included as an extension is MOBI 
though there are many tools to take any of those other formats to MOBI if 
really needed. I would think it not too difficult to script the conversion of a 
resulting ePUB into MOBI. Clicking the MOBI download link could take a trip 
through ePUB and then the ePub2Mobi conversion to serve the desired file. Is 
there still a significant case for .mobi files due to .mobi only readers? Is 
there a current comparison of download stats from gnucash.org?

An additional advantage of using the wiki as the working and publishing 
platform is that formats are generated on-demand by the render server. Thus any 
time someone downloads a copy of the documentation it will always be the most 
up to date, rather than a milestone-released static version. If that is not 
desired I suppose some method of drafts vs. published approved pages would 
suffice, but that will more than likely be handled by control of editing 
credentials.

The render server can also be configured to ‘publish’ specific collections of 
articles so that the wiki could contain the entirety of the help, tutorial and 
concepts guide, developer documentation, et cetera, and then particular links 
will give you a single file of any one of those. So if someone wanted a printed 
copy of the help and a pdf of the tutorial and concepts guide, they could get 
each separately all from the wiki and all with the most current approved edits.

Just a thought.

-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: Some Assistance Please

[Adrien Monteleone]

> On May 23, 2017, at 8:50 PM, Adrien Monteleone <adrien.montele...@gmail.com> 
> wrote:
> 
>> 
>> On May 23, 2017, at 3:22 PM, Derek Atkins <de...@ihtfp.com> wrote:
>> 
>> Hi,
>> 
>> On Tue, May 23, 2017 1:11 pm, doncram wrote:
>>> Wow the process to change documentation (at
>>> http://wiki.gnucash.org/wiki/Documentation_Update_Instructions ) seems
>>> pretty complicated, even impossible for Windows users.
>> 
>> What's so complicated about a git checkout and using the appropriate
>> DocBook tools to edit the DocBook sources of the manual?
>> 
>>> I would hope it
>>> should be possible to have a full working version of the Tutorial and
>>> Concepts Guide that is open for edits/improvement by users informed about
>>> accounting and trying to make the Guide more useful for basic users, in a
>>> wiki document (where changes can be seen and there can be discussion at
>>> Talk pages).
>> 
>> There's no good way to translate from Wiki to PDF.  There was a conscious
>> decsion a while ago that we wanted offline help, which meant a non-wiki
>> form.
> 
> I’m certainly no expert on the matter and I have no beef with the GIT process 
> for documentation, but that seems odd at first glance since wikis are 
> markdown inside HTML which is a subset of XML which the doc procedures turn 
> into PDF. Or did I misunderstand something?
> 
> -Adrien

On that note, I already knew about html2pdf for *nix, but even better - there’s 
this: Extension:Pdf_Export on the mediawiki site.

-Adrien

>> 
>>>  Then periodically when the Wiki editors get consensus that a
>>> new version is ready, just one programmer type person with Linux could go
>>> through those complicated steps to get it published.  Allow different
>>> parties to specialize in how they contribute.  I for one would like to
>>> contribute in improving the Concepts guide text.
>> 
>> The publication side is fine, and we do already go through that.  As for
>> people reading/editing -- github pull requests provide that.
>> 
>> [snip]
>>> Currently I am trying to log into the Wiki but keep getting error message:
>>> There seems to be a problem with your login session; this action has been
>>> canceled as a precaution against session hijacking. Go back to the
>>> previous
>>> page, reload that page and then try again.
>> 
>> I think you need to clear your cache/cookies and try again.  Not sure what
>> happened here.
>> 
>>> Recent changes shows that Jrall opened an account for me, which I reported
>>> did not allow me to edit, because I need to get some user group rights
>>> added, and I don't yet know if I was able to log in again whether I would
>>> be able to edit yet.
>> 
>> This is correct; you have not validated your email.  At least according to
>> the database, you are not "email authenticated" which is a requirement to
>> edit the wiki.  I do not know why it says "email_authenticated" is NULL
>> for both you and Buddha.  Did you actually confirm your email?  Can you
>> try confirming it again?
>> 
>> The previous users in the list appear to have done so -- but it also
>> appears there are a number of users who have not.
>> 
>> This COULD be a bug in the ConfirmAccount plugin where it does not
>> properly translate the email authentication across.  Or it could be a bad
>> interaction between CA and the built-in email confirmation.
>> 
>> So can you confirm you confirmed your email?  Can you try confirming
>> again?  Let me know if/when you attempt this.  Better yet, can you come
>> onto IRC during 9a-5p EDT and we can work on trying to track down the
>> issue.
>> 
>> Yes, I could just go into the database and fix it manually (which I'll
>> gladly do as a last resort), but I'd rather get down to the bottom of the
>> actual issue.
>> 
>> Thanks,
>> 
>> -derek
>> 
>> -- 
>>  Derek Atkins 617-623-3745
>>  de...@ihtfp.com www.ihtfp.com
>>  Computer and Internet Security Consultant
>> 
>> ___
>> 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: Some Assistance Please

[Adrien Monteleone]

> On May 23, 2017, at 3:22 PM, Derek Atkins  wrote:
> 
> Hi,
> 
> On Tue, May 23, 2017 1:11 pm, doncram wrote:
>> Wow the process to change documentation (at
>> http://wiki.gnucash.org/wiki/Documentation_Update_Instructions ) seems
>> pretty complicated, even impossible for Windows users.
> 
> What's so complicated about a git checkout and using the appropriate
> DocBook tools to edit the DocBook sources of the manual?
> 
>>  I would hope it
>> should be possible to have a full working version of the Tutorial and
>> Concepts Guide that is open for edits/improvement by users informed about
>> accounting and trying to make the Guide more useful for basic users, in a
>> wiki document (where changes can be seen and there can be discussion at
>> Talk pages).
> 
> There's no good way to translate from Wiki to PDF.  There was a conscious
> decsion a while ago that we wanted offline help, which meant a non-wiki
> form.

I’m certainly no expert on the matter and I have no beef with the GIT process 
for documentation, but that seems odd at first glance since wikis are markdown 
inside HTML which is a subset of XML which the doc procedures turn into PDF. Or 
did I misunderstand something?

-Adrien
> 
>>   Then periodically when the Wiki editors get consensus that a
>> new version is ready, just one programmer type person with Linux could go
>> through those complicated steps to get it published.  Allow different
>> parties to specialize in how they contribute.  I for one would like to
>> contribute in improving the Concepts guide text.
> 
> The publication side is fine, and we do already go through that.  As for
> people reading/editing -- github pull requests provide that.
> 
> [snip]
>> Currently I am trying to log into the Wiki but keep getting error message:
>> There seems to be a problem with your login session; this action has been
>> canceled as a precaution against session hijacking. Go back to the
>> previous
>> page, reload that page and then try again.
> 
> I think you need to clear your cache/cookies and try again.  Not sure what
> happened here.
> 
>> Recent changes shows that Jrall opened an account for me, which I reported
>> did not allow me to edit, because I need to get some user group rights
>> added, and I don't yet know if I was able to log in again whether I would
>> be able to edit yet.
> 
> This is correct; you have not validated your email.  At least according to
> the database, you are not "email authenticated" which is a requirement to
> edit the wiki.  I do not know why it says "email_authenticated" is NULL
> for both you and Buddha.  Did you actually confirm your email?  Can you
> try confirming it again?
> 
> The previous users in the list appear to have done so -- but it also
> appears there are a number of users who have not.
> 
> This COULD be a bug in the ConfirmAccount plugin where it does not
> properly translate the email authentication across.  Or it could be a bad
> interaction between CA and the built-in email confirmation.
> 
> So can you confirm you confirmed your email?  Can you try confirming
> again?  Let me know if/when you attempt this.  Better yet, can you come
> onto IRC during 9a-5p EDT and we can work on trying to track down the
> issue.
> 
> Yes, I could just go into the database and fix it manually (which I'll
> gladly do as a last resort), but I'd rather get down to the bottom of the
> actual issue.
> 
> Thanks,
> 
> -derek
> 
> -- 
>   Derek Atkins 617-623-3745
>   de...@ihtfp.com www.ihtfp.com
>   Computer and Internet Security Consultant
> 
> ___
> 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: Wiki Landing Page

[Adrien Monteleone]

I see some buttons now in the business features. But that’s all. Those don’t 
work either.

> On May 27, 2017, at 11:25 PM, Adrien Monteleone <adrien.montele...@gmail.com> 
> wrote:
> 
> Thanks, I’ll have to try installing again. Maybe something is amiss with the 
> bundle I downloaded. I’m still getting no response from those menu entries. 
> And I don’t see any help buttons in any window anywhere. Not sure where those 
> ‘Context help buttons’ are supposed to be.
> 
> 
>> On May 27, 2017, at 11:12 PM, John Ralls <jra...@ceridwen.us> wrote:
>> 
>> 
>>> On May 27, 2017, at 9:02 PM, Adrien Monteleone 
>>> <adrien.montele...@gmail.com> wrote:
>>> 
>>> FYI, I don’t believe the help or the guide comes with the Mac bundle 
>>> either. I tried the links in the help menu for both and nothing happened. I 
>>> should think if they aren’t installed, they should at least point to the 
>>> appropriate locations on the web. (I think there is already a bug for this)
>>> 
>> 
>> Nope, they're included in the bundle and open in your default browser. 
>> Context help buttons even open the right page of Help.
>> 
>> Regards,
>> John Ralls
>> 
> 

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

Re: Wiki Landing Page

[Adrien Monteleone]

> On May 27, 2017, at 11:52 PM, John Ralls <jra...@ceridwen.us> wrote:
> 
> 
>> On May 27, 2017, at 9:49 PM, John Ralls <jra...@ceridwen.us> wrote:
>> 
>> 
>>> On May 27, 2017, at 9:25 PM, Adrien Monteleone 
>>> <adrien.montele...@gmail.com> wrote:
>>> 
>>> Thanks, I’ll have to try installing again. Maybe something is amiss with 
>>> the bundle I downloaded. I’m still getting no response from those menu 
>>> entries. And I don’t see any help buttons in any window anywhere. Not sure 
>>> where those ‘Context help buttons’ are supposed to be.
>> 
>> Seems pretty unlikely that a download error could lose the documentation and 
>> still have a valid signature. More likely your default browser is rejecting 
>> the page load signal for some reason. Eh, what locale do you use? It occurs 
>> to me that I might have messed up so that it works only

I didn’t think a corrupt download would cause that either, but wasn’t sure what 
might be the issue.
> 
> Oops, got distracted and hit send before I was finished. I might have messed 
> up so that it works only if your locale matches one of the existing 
> translations, English, German, Italian, and Japanese. I see that I forgot to 
> add the new Portuguese docs to the bundle.

My locale is English-US. My default browser is Firefox. It normally runs in 
private mode. Perhaps that has something to do with it? I’ll test with private 
mode off and I’ll also test with other browsers as the default and see what 
happens. I’ll also test FF with no extensions. One of them might be 
interfering. (I suspect uBlock Origin as that is usually the culprit when 
something isn’t working right)

> 
> Regards,
> John Ralls
> 

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

Re: Website Platform Discussion

[Adrien Monteleone]

Adrien Monteleone
adrien.montele...@gmail.com
337-593-8208
103 Rosalind street
Lafayette, Louisiana

> On Jun 16, 2017, at 2:47 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> 
> wrote:
> 
> My (limited) experience is with drupal as well.
> 
> Regarding your first question (how to map version management on a cms driven 
> website): usually only the cms code, modules and themes are version managed. 
> The data resides in a database which is not well suited for version 
> management. So code, module and theme updates would be done in much the same 
> way as is done for the current website. One clones the git repository holding 
> all the website code, make changes, create a PR/push upstream. The only 
> additional step would be to run db updates right after this. Perhaps even 
> that 
> could be scripted.
> The actual content needs something else, just like we need something else for 
> our wiki pages. Both mediawiki (for our wiki pages) and drupal support "page 
> revisions". So just as in the wiki we could follow the history of changes 
> made 
> to each page.
> 
> A side effect of the content being in a db rather than in git is it is no 
> longer stored in a distributed way. So it will be important to implement a 
> backup plan for the data.
> 
> That goes for the current wiki as well by the way. Do we have a backup in 
> place there ?
> 
> For your second question: translations are handled pretty well in drupal. I 
> have played with multilingual websites and from my experience this worked 
> well.
> 
> One additional note: dynamic websites frequently need security updates 
> applied. So switching to a cms (any non-static one) would require more 
> maintenance work than we did so far on the website. Someone will have to take 
> this time.

A staging/dev subdomain works well for this since testing is usually necessary 
to discover likely breakage. It’s very easy to set up. You can use Git for 
pushing updates and then do a clone from the staging site to the live site when 
it is ready. How much work is involved depends on how manual the present set up 
is. If this is a personally hosted site as jralls indicates, it might involve 
some bit of work, but I’m sure most of that can be reduced with scripting. 
(that’s all the big hosts do anyway save they add a control panel button for 
the function)

I’m not sure about Drupal, but Wordpress has built-in auto security updates for 
point releases (which you could turn off if you desire) and you only need to 
intentionally update minor and major versions.

I’ve never noticed breakage from security point releases so I generally leave 
those as automatic. All other updates, especially plugin updates, should be 
read over and tested on the staging site first. The more well maintained and 
actively developed plugins frequently (once or more a week even) push point 
releases that include compatibility fixes in addition to security fixes. This 
is why breakage is likely in these areas. (you’d think compatibility 
improvements with the main CMS would decrease breakage, but not always 
depending on work arounds used and the method used to improve compatibility)

That may sound rough but in practice it really is simple and easy.

-Adrien
> 
> However all things considered, this is yet another project I had queued for 
> "when I will have some spare time", which I never seem to have any more. So 
> I'm quite pleased there are several people already willing to help out on 
> this!
> 
> Regards,
> 
> Geert
> 
> On vrijdag 16 juni 2017 03:55:59 CEST Adrien Monteleone wrote:
>> I’ve used Drupal in the past but haven’t touched it in any meaningful way
>> for about 5 years. From what I understand, it has been abstracted from a
>> CMS to a framework for building a CMS.
>> 
>> I presently develop Wordpress sites. Not sure what the present host offers,
>> but some like SiteGround offer staging tools using sub-domains or
>> sub-folders. (that can all be set up manually of course, but some offer it
>> in a few clicks) You can use Git for edits and updates. But that’s really
>> only necessary for the site structure itself like themes, plugins, etc.
>> 
>> Actual content can easily be saved as drafts that can then be later approved
>> and published.
>> 
>> There are plenty of options for user roles with editing and publishing
>> rights.
>> 
>> I haven’t looked, but I would be surprised to not find translation plugins.
>> 
>> You could also integrate a web store really easy using the Woocommerce
>> plugin for donations, developer support, swag, etc.
>> 
>> There are also calendar and project management plugins. Not sure if ya’ll
>> are using any online project management tools yet, b

Re: Website Platform Discussion

[Adrien Monteleone]

> On Jun 16, 2017, at 1:40 PM, Geert Janssens <geert.gnuc...@kobaltwit.be> 
> wrote:
> 
> On vrijdag 16 juni 2017 19:25:25 CEST Adrien Monteleone wrote:
>> Adrien Monteleone
>> adrien.montele...@gmail.com
>> 337-593-8208
>> 103 Rosalind street
>> Lafayette, Louisiana
>> 
>>> On Jun 16, 2017, at 2:47 AM, Geert Janssens <geert.gnuc...@kobaltwit.be>
>>> wrote:
>>> 
>>> My (limited) experience is with drupal as well.
>>> 
>>> Regarding your first question (how to map version management on a cms
>>> driven website): usually only the cms code, modules and themes are
>>> version managed. The data resides in a database which is not well suited
>>> for version management. So code, module and theme updates would be done
>>> in much the same way as is done for the current website. One clones the
>>> git repository holding all the website code, make changes, create a
>>> PR/push upstream. The only additional step would be to run db updates
>>> right after this. Perhaps even that could be scripted.
>>> The actual content needs something else, just like we need something else
>>> for our wiki pages. Both mediawiki (for our wiki pages) and drupal
>>> support "page revisions". So just as in the wiki we could follow the
>>> history of changes made to each page.
>>> 
>>> A side effect of the content being in a db rather than in git is it is no
>>> longer stored in a distributed way. So it will be important to implement a
>>> backup plan for the data.
>>> 
>>> That goes for the current wiki as well by the way. Do we have a backup in
>>> place there ?
>>> 
>>> For your second question: translations are handled pretty well in drupal.
>>> I
>>> have played with multilingual websites and from my experience this worked
>>> well.
>>> 
>>> One additional note: dynamic websites frequently need security updates
>>> applied. So switching to a cms (any non-static one) would require more
>>> maintenance work than we did so far on the website. Someone will have to
>>> take this time.
>> 
>> A staging/dev subdomain works well for this since testing is usually
>> necessary to discover likely breakage. It’s very easy to set up. You can
>> use Git for pushing updates and then do a clone from the staging site to
>> the live site when it is ready. How much work is involved depends on how
>> manual the present set up is. If this is a personally hosted site as jralls
>> indicates, it might involve some bit of work, but I’m sure most of that can
>> be reduced with scripting. (that’s all the big hosts do anyway save they
>> add a control panel button for the function)
>> 
> This is indeed not too hard to set up. We already have a beta setup for the 
> current website so this can be reused for this purpose. It lives on a 
> separate 
> branch in our gnucash-htdocs repo.
> 
>> I’m not sure about Drupal, but Wordpress has built-in auto security updates
>> for point releases (which you could turn off if you desire) and you only
>> need to intentionally update minor and major versions.
> 
> I'm not aware of this in drupal. Anyway this would not work in a git driven 
> setup as we currenly have. Changes to the website sources are pushed to the 
> gnucash-htdocs repo which has a trigger to update the live website (or beta 
> if 
> you prefer) on a remote host. If the updates would be automatic, they would 
> happen on the remote host, not in the git repo. Subsequent updates in the git 
> repo would probably either result in merge conflicts when the trigger updates 
> the live websites or the automatic updates would get discarded.

It shouldn’t be an issue. Both versions will automatically get security updates 
at the same time. Alternatively, you could turn this off and use GIT for all of 
it, but that requires more diligence.

> 
>> 
>> I’ve never noticed breakage from security point releases so I generally
>> leave those as automatic. All other updates, especially plugin updates,
>> should be read over and tested on the staging site first. The more well
>> maintained and actively developed plugins frequently (once or more a week
>> even) push point releases that include compatibility fixes in addition to
>> security fixes. This is why breakage is likely in these areas. (you’d think
>> compatibility improvements with the main CMS would decrease breakage, but
>> not always depending on work arounds used and the method used to improve
>> compatibility)
> 
> I think in our process the updates shoul

Re: Website Platform Discussion

[Adrien Monteleone]

I just pulled down a copy of GnuCash.org with SiteSucker. Total size is 228MB, 
210MB of which are docs in various formats and translations. (ePub, etc.)

There is less than 1MB of images, though I’d suppose that may change in the 
future.

And this is uncompressed.

The site itself is nill. The infrastructure and theme for the CMS will likely 
be larger than content for some time.

I should think since the docs are built separately anyway, they can remain in 
sub-folder and be backed up separately if desired. Worst case would be someone 
would have to regenerate the various formats and translations if they were lost.

Not that I’d go that route, but a thumdrive could handle it.

Regards,
Adrien

> On Jun 16, 2017, at 12:39 PM, Derek Atkins  wrote:
> 
> Jon Daley  writes:
> 
>> On Fri, 16 Jun 2017, Derek Atkins wrote:
>>> Code performs a nightly mysql dump, and I have a nightly backup of all
>>> my servers (including code) to a backup server with storage on my
>>> FreeNAS box.  This is all completely automated.  The only thing I do not
>>> have, yet, is a an offsite backup plan to protect against fire, tornado,
>>> etc.
>>> 
>>> Linas and I have discussed using each other for offsite backups, but
>>> then he disappeared for 6 weeks and we haven't returned to the topic.
>> 
>>  How much data do you have that needs to be backed up?  I have
>> space that I can offer, depending on how big it is.
> 
> Right now the backup volume uses 645GB:
> 
> [root@freenas] ~# df -h /mnt/freenas-0/backups/
> Filesystem   SizeUsed   Avail Capacity  Mounted on
> freenas-0/backups5.3T645G4.6T12%/mnt/freenas-0/backups
> 
> Note, however, this is all my servers' backups, not just code.  Code's
> backup is a fraction of this, but I couldn't tell you offhand how much
> it is.
> 
> What I can show you is how mych the htdocs repos take:
> 
> [root@code repositories]# du -sh gnucash-htdocs*
> 2.5G  gnucash-htdocs-docs.git
> 20M   gnucash-htdocs.git
> 
> -derek
> -- 
>   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
>   warl...@mit.eduPGP key available
> ___
> 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: Time Frame on Wiki Edits

[Adrien Monteleone]

Sure, I’ll need to sign up for an account first. I’m heading out of town till 
Thursday and will get to it when I get back.

-Adrien

> On Jun 14, 2017, at 9:01 AM, David T. <sunfis...@yahoo.com> wrote:
> 
> Thanks for the feedback. I’ve modified the page and incorporated most of your 
> changes. If there are specific typos or grammatical errors, could you either 
> fix them or point them out? My eyes aren’t what they used to be!
> 
> David
> 
>> On Jun 14, 2017, at 12:02 AM, Adrien Monteleone 
>> <adrien.montele...@gmail.com> wrote:
>> 
>> I see a few typos and grammatical errors, so I wouldn’t say it’s ready for 
>> publication yet.
>> 
>> As for organization, perhaps change [Scripting and Programming] to 
>> [“Advanced” Usage] or [“Advanced” Usage - Scripting & Programming]
>> 
>> I’d expect to find the info on Logging and Stack Trace to be either under 
>> Help or Filing Bugs. You could then probably eliminate the odd sounding 
>> ‘Error Seaching’ (sic) heading.
>> 
>> Also the way [Getting Involved in the Project] reads, the rest of the 
>> material that follows should be nested under it, which might be odd. Perhaps 
>> just keep the sentence but remove that heading entirely. It doesn’t seem 
>> necessary. Or since all of those topics including developing code are 
>> "getting involved” replace the main heading—[Developing for GnuCash] with 
>> [Getting Involved in the Project] or something similar like [Contributing to 
>> GnuCash]. The other headings and text can remain as is.
>> 
>> Overall though, this is laid out much better than the current version.
>> 
>> -Adrien
>> 
>> 
>>> On Jun 13, 2017, at 11:17 AM, David T. via gnucash-devel 
>>> <gnucash-devel@gnucash.org> wrote:
>>> 
>>> Hello,
>>> 
>>> Two weeks ago, after a flurry of discussion in this list, I and Don 
>>> (doncram) worked to put together a modified wiki landing page, which was 
>>> placed as a sandbox page at https://wiki.gnucash.org/wiki/GnuCash/sandbox 
>>> <https://wiki.gnucash.org/wiki/GnuCash/sandbox>.
>>> 
>>> Since that time, there has been no further activity on any front, and 
>>> although two weeks is not a very long time to let this season (as it were), 
>>> I do wonder whether the Developer team has any sense of what amount of time 
>>> constitutes “the right” amount of time for such a proposal to sit before 
>>> the changes are sent live. I’d like to get the page pushed out before it 
>>> gets lost in the mists of time…
>>> 
>>> David
>>> 
>>> @doncram: once it’s time to move this along, how exactly does one convert 
>>> the sandbox to its real counterpart?
>>> ___
>>> 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

Help Documents not firing on El Capitan (was Re: Wiki Landing Page)

[Adrien Monteleone]

Tested everything. Also tested with default browser as Safari, Chromium-canary, 
Opera, Vivaldi, and Firefox Developer Edition.

Nothing happens when I click anything in the help menu or any context help 
buttons.

I do see that there are links in the GnuCash directory pointing to Help & the 
Guide.

Personally, it’s not a big deal for me because I know where to find those docs 
already online, but those menu entries and buttons should work.

Should I expect to find something in the logs when those are fired? or if they 
fail?

-Adrien


> On May 28, 2017, at 9:21 AM, Adrien Monteleone <adrien.montele...@gmail.com> 
> wrote:
> 
>> On May 27, 2017, at 11:52 PM, John Ralls <jra...@ceridwen.us> wrote:
>> 
>> 
>>> On May 27, 2017, at 9:49 PM, John Ralls <jra...@ceridwen.us> wrote:
>>> 
>>> 
>>>> On May 27, 2017, at 9:25 PM, Adrien Monteleone 
>>>> <adrien.montele...@gmail.com> wrote:
>>>> 
>>>> Thanks, I’ll have to try installing again. Maybe something is amiss with 
>>>> the bundle I downloaded. I’m still getting no response from those menu 
>>>> entries. And I don’t see any help buttons in any window anywhere. Not sure 
>>>> where those ‘Context help buttons’ are supposed to be.
>>> 
>>> Seems pretty unlikely that a download error could lose the documentation 
>>> and still have a valid signature. More likely your default browser is 
>>> rejecting the page load signal for some reason. Eh, what locale do you use? 
>>> It occurs to me that I might have messed up so that it works only
> 
> I didn’t think a corrupt download would cause that either, but wasn’t sure 
> what might be the issue.
>> 
>> Oops, got distracted and hit send before I was finished. I might have messed 
>> up so that it works only if your locale matches one of the existing 
>> translations, English, German, Italian, and Japanese. I see that I forgot to 
>> add the new Portuguese docs to the bundle.
> 
> My locale is English-US. My default browser is Firefox. It normally runs in 
> private mode. Perhaps that has something to do with it? I’ll test with 
> private mode off and I’ll also test with other browsers as the default and 
> see what happens. I’ll also test FF with no extensions. One of them might be 
> interfering. (I suspect uBlock Origin as that is usually the culprit when 
> something isn’t working right)
> 
>> 
>> Regards,
>> John Ralls
>> 
> 

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

Re: Help Documents not firing on El Capitan (was Re: Wiki Landing Page)

[Adrien Monteleone]

I’m using 2.6.16 as well. I don’t think it has ever worked for me though. (not 
sure exactly which version I started on when I moved to Mac, probably somewhere 
around 2.6.12 or so.)

> On Jun 15, 2017, at 3:24 PM, Eric Theise <ericthe...@gmail.com> wrote:
> 
> In case you two are talking about a yet unreleased version, I apologize for 
> introducing noise, but I'm using 2.6.16 on OS 10.12.5 and, from the Help > 
> Tutorial and Concepts Guide, Chrome opens up an unstyled page from 
> file:///private/var/folders/... and the links it contains work just fine.
> 
> 
> On Wed, Jun 14, 2017 at 8:09 PM, John Ralls <jra...@ceridwen.us 
> <mailto:jra...@ceridwen.us>> wrote:
> 
> > On Jun 14, 2017, at 9:00 AM, Adrien Monteleone <adrien.montele...@gmail.com 
> > <mailto:adrien.montele...@gmail.com>> wrote:
> >
> > Tested everything. Also tested with default browser as Safari, 
> > Chromium-canary, Opera, Vivaldi, and Firefox Developer Edition.
> >
> > Nothing happens when I click anything in the help menu or any context help 
> > buttons.
> >
> > I do see that there are links in the GnuCash directory pointing to Help & 
> > the Guide.
> >
> > Personally, it’s not a big deal for me because I know where to find those 
> > docs already online, but those menu entries and buttons should work.
> >
> > Should I expect to find something in the logs when those are fired? or if 
> > they fail?
> >
> 
> I completely agree that it should work and I think it strange that it does 
> for me and not for you. I wonder if there’s some obscure defaults setting 
> that either blocks or allows it.
> 
> There won’t be anything in the logs, and since it’s just pushing the URI off 
> to the default browser I’m not sure that GnuCash will even know whether it 
> succeeds or fails. Something might show up in Console but I wouldn’t bet on 
> it.
> 
> Regards,
> John Ralls
> 
> >> On May 28, 2017, at 9:21 AM, Adrien Monteleone 
> >> <adrien.montele...@gmail.com <mailto:adrien.montele...@gmail.com>> wrote:
> >>
> >>> On May 27, 2017, at 11:52 PM, John Ralls <jra...@ceridwen.us 
> >>> <mailto:jra...@ceridwen.us>> wrote:
> >>>
> >>>
> >>>> On May 27, 2017, at 9:49 PM, John Ralls <jra...@ceridwen.us 
> >>>> <mailto:jra...@ceridwen.us>> wrote:
> >>>>
> >>>>
> >>>>> On May 27, 2017, at 9:25 PM, Adrien Monteleone 
> >>>>> <adrien.montele...@gmail.com <mailto:adrien.montele...@gmail.com>> 
> >>>>> wrote:
> >>>>>
> >>>>> Thanks, I’ll have to try installing again. Maybe something is amiss 
> >>>>> with the bundle I downloaded. I’m still getting no response from those 
> >>>>> menu entries. And I don’t see any help buttons in any window anywhere. 
> >>>>> Not sure where those ‘Context help buttons’ are supposed to be.
> >>>>
> >>>> Seems pretty unlikely that a download error could lose the documentation 
> >>>> and still have a valid signature. More likely your default browser is 
> >>>> rejecting the page load signal for some reason. Eh, what locale do you 
> >>>> use? It occurs to me that I might have messed up so that it works only
> >>
> >> I didn’t think a corrupt download would cause that either, but wasn’t sure 
> >> what might be the issue.
> >>>
> >>> Oops, got distracted and hit send before I was finished. I might have 
> >>> messed up so that it works only if your locale matches one of the 
> >>> existing translations, English, German, Italian, and Japanese. I see that 
> >>> I forgot to add the new Portuguese docs to the bundle.
> >>
> >> My locale is English-US. My default browser is Firefox. It normally runs 
> >> in private mode. Perhaps that has something to do with it? I’ll test with 
> >> private mode off and I’ll also test with other browsers as the default and 
> >> see what happens. I’ll also test FF with no extensions. One of them might 
> >> be interfering. (I suspect uBlock Origin as that is usually the culprit 
> >> when something isn’t working right)
> >>
> >>>
> >>> Regards,
> >>> John Ralls
> >>>
> >>
> >
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel 
> > <https://lists.gnucash.org/mailman/listinfo/gnucash-devel>
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel 
> <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: Website Platform Discussion

[Adrien Monteleone]

I’ve used Drupal in the past but haven’t touched it in any meaningful way for 
about 5 years. From what I understand, it has been abstracted from a CMS to a 
framework for building a CMS.

I presently develop Wordpress sites. Not sure what the present host offers, but 
some like SiteGround offer staging tools using sub-domains or sub-folders. 
(that can all be set up manually of course, but some offer it in a few clicks) 
You can use Git for edits and updates. But that’s really only necessary for the 
site structure itself like themes, plugins, etc.

Actual content can easily be saved as drafts that can then be later approved 
and published.

There are plenty of options for user roles with editing and publishing rights.

I haven’t looked, but I would be surprised to not find translation plugins.

You could also integrate a web store really easy using the Woocommerce plugin 
for donations, developer support, swag, etc.

There are also calendar and project management plugins. Not sure if ya’ll are 
using any online project management tools yet, but that’s a definite option.

I’d be happy to assist with the build if needed.

-Adrien


> On Jun 15, 2017, at 2:05 PM, Eric Theise  wrote:
> 
> Hi all,
> 
> My trajectory with site-building is somewhat similar to David's except that
> I ended up building less sites through CMSs and more using frameworks such
> as Rails, Django, and Express. But lately I've taken a few steps back and
> I've found Jekyll to be an excellent way to get the job done. I'll advocate
> for it here because of its tight integration with GitHub. Updating a site
> is a git push, and content updates can go through the same evaluation as
> any other pull request.
> 
> Perhaps not immediately obvious is Jekyll's use of yaml objects to
> replace/simulate database reads and I've found this incredibly useful in
> situations where updates are infrequent.
> 
> http://jekyllrb.com/
> 
> Eric
> 
> 
> On Thu, Jun 15, 2017 at 10:57 AM, David T. via gnucash-devel <
> gnucash-devel@gnucash.org> wrote:
> 
>> In Bug 783240, I made some suggestions about modifying the website
>> structure to improve the new user experience. As the discussion has
>> developed, the implications of some of the suggestions have become more
>> substantial, and John Ralls suggested that we bring the discussion to the
>> devel list for broader discussion. Most significantly, John raised the
>> possibility of changing the website from being a hand-coded PHP site, to
>> one that uses a content management system (CMS).
>> 
>> I think a CMS would be a good idea, assuming that the GnuCash website’s
>> look and feel can be reasonably approximated—or an alternative look and
>> feel can be accepted as the new norm. Having built websites manually, then
>> coding my own php sites, and finally using a CMS, I can vouch for the
>> benefits of a CMS. Creating and managing content and features is much
>> easier with an established CMS. Creating a new version in a CMS that is
>> tightly locked down would allow the focus to be on the content but still
>> allow a broader number of contributors to possibly add to the GnuCash web
>> presence—something that the current system doesn’t do well. As I see it,
>> the GnuCash website doesn’t offer any significant special formatting or
>> whiz-bang web features, so I think its basic content could be ported
>> without a herculean effort.
>> 
>> Two major questions occur to me:
>> 
>> How would the current version control method of website management port
>> over to a CMS? and,
>> How would translations be handled in a CMS?
>> 
>> I am sure there are other big questions as well...
>> 
>> There are numerous CMS platforms out there; I am personally familiar with
>> Drupal, and know that it can quickly provide a robust and feature-laden
>> website. It seems to have tools for managing page translations, although I
>> admit to only a superficial glance at what’s there, and I am not sure how
>> that issue would get handled for the GnuCash use case. It even has the
>> potential for providing a wiki experience, which might allow these two
>> pieces of the GnuCash web experience to become more closely linked.
>> 
>> I welcome your comments!
>> 
>> Best,
>> David
>> ___
>> 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: Website Platform Discussion

[Adrien Monteleone]

> On Jun 16, 2017, at 2:47 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> 
> wrote:
> 
> My (limited) experience is with drupal as well.
> 
> Regarding your first question (how to map version management on a cms driven 
> website): usually only the cms code, modules and themes are version managed. 
> The data resides in a database which is not well suited for version 
> management. So code, module and theme updates would be done in much the same 
> way as is done for the current website. One clones the git repository holding 
> all the website code, make changes, create a PR/push upstream. The only 
> additional step would be to run db updates right after this. Perhaps even 
> that 
> could be scripted.
> The actual content needs something else, just like we need something else for 
> our wiki pages. Both mediawiki (for our wiki pages) and drupal support "page 
> revisions". So just as in the wiki we could follow the history of changes 
> made 
> to each page.
> 
> A side effect of the content being in a db rather than in git is it is no 
> longer stored in a distributed way. So it will be important to implement a 
> backup plan for the data.

The site host should provide a facility for this either through cPanel/Plex, or 
you can set a cron job via SSH. Many have options to schedule backups to an 
offsite FTP server.

You’d need to regularly back up both the db and the site structure.


> 
> That goes for the current wiki as well by the way. Do we have a backup in 
> place there ?
> 
> For your second question: translations are handled pretty well in drupal. I 
> have played with multilingual websites and from my experience this worked 
> well.
> 
> One additional note: dynamic websites frequently need security updates 
> applied. So switching to a cms (any non-static one) would require more 
> maintenance work than we did so far on the website. Someone will have to take 
> this time.
> 
> However all things considered, this is yet another project I had queued for 
> "when I will have some spare time", which I never seem to have any more. So 
> I'm quite pleased there are several people already willing to help out on 
> this!
> 
> Regards,
> 
> Geert
> 
> On vrijdag 16 juni 2017 03:55:59 CEST Adrien Monteleone wrote:
>> I’ve used Drupal in the past but haven’t touched it in any meaningful way
>> for about 5 years. From what I understand, it has been abstracted from a
>> CMS to a framework for building a CMS.
>> 
>> I presently develop Wordpress sites. Not sure what the present host offers,
>> but some like SiteGround offer staging tools using sub-domains or
>> sub-folders. (that can all be set up manually of course, but some offer it
>> in a few clicks) You can use Git for edits and updates. But that’s really
>> only necessary for the site structure itself like themes, plugins, etc.
>> 
>> Actual content can easily be saved as drafts that can then be later approved
>> and published.
>> 
>> There are plenty of options for user roles with editing and publishing
>> rights.
>> 
>> I haven’t looked, but I would be surprised to not find translation plugins.
>> 
>> You could also integrate a web store really easy using the Woocommerce
>> plugin for donations, developer support, swag, etc.
>> 
>> There are also calendar and project management plugins. Not sure if ya’ll
>> are using any online project management tools yet, but that’s a definite
>> option.
>> 
>> I’d be happy to assist with the build if needed.
>> 
>> -Adrien
>> 
>>> On Jun 15, 2017, at 2:05 PM, Eric Theise <ericthe...@gmail.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> My trajectory with site-building is somewhat similar to David's except
>>> that
>>> I ended up building less sites through CMSs and more using frameworks such
>>> as Rails, Django, and Express. But lately I've taken a few steps back and
>>> I've found Jekyll to be an excellent way to get the job done. I'll
>>> advocate
>>> for it here because of its tight integration with GitHub. Updating a site
>>> is a git push, and content updates can go through the same evaluation as
>>> any other pull request.
>>> 
>>> Perhaps not immediately obvious is Jekyll's use of yaml objects to
>>> replace/simulate database reads and I've found this incredibly useful in
>>> situations where updates are infrequent.
>>> 
>>> http://jekyllrb.com/
>>> 
>>> Eric
>>> 
>>> 
>>> On Thu, Jun 15, 2017 at 10:57 AM, David T. via gnucash-devel <
>>> 
>&

Re: Website Platform Discussion

[Adrien Monteleone]

Then I don’t suppose it’s a major issue. You’d just need a backup of 
public_html (or WWW folder, whichever is used) like is probably being done now, 
and a dump of whatever db is used for the cms. Since there is already a dump of 
the wiki db, it would just be an extra one of those for the cms db. A straight 
dump by the db software or a tar.gz by the OS will do. Whatever procedure is 
currently used for the wiki should be fine for the cms.

> On Jun 16, 2017, at 10:58 AM, John Ralls <jra...@ceridwen.us> wrote:
> 
>> 
>> On Jun 16, 2017, at 8:30 AM, Adrien Monteleone <adrien.montele...@gmail.com 
>> <mailto:adrien.montele...@gmail.com>> wrote:
>> 
>>> 
>>> On Jun 16, 2017, at 2:47 AM, Geert Janssens <geert.gnuc...@kobaltwit.be 
>>> <mailto:geert.gnuc...@kobaltwit.be>> wrote:
>>> 
>>> My (limited) experience is with drupal as well.
>>> 
>>> Regarding your first question (how to map version management on a cms 
>>> driven 
>>> website): usually only the cms code, modules and themes are version 
>>> managed. 
>>> The data resides in a database which is not well suited for version 
>>> management. So code, module and theme updates would be done in much the 
>>> same 
>>> way as is done for the current website. One clones the git repository 
>>> holding 
>>> all the website code, make changes, create a PR/push upstream. The only 
>>> additional step would be to run db updates right after this. Perhaps even 
>>> that 
>>> could be scripted.
>>> The actual content needs something else, just like we need something else 
>>> for 
>>> our wiki pages. Both mediawiki (for our wiki pages) and drupal support 
>>> "page 
>>> revisions". So just as in the wiki we could follow the history of changes 
>>> made 
>>> to each page.
>>> 
>>> A side effect of the content being in a db rather than in git is it is no 
>>> longer stored in a distributed way. So it will be important to implement a 
>>> backup plan for the data.
>> 
>> The site host should provide a facility for this either through cPanel/Plex, 
>> or you can set a cron job via SSH. Many have options to schedule backups to 
>> an offsite FTP server.
>> 
>> You’d need to regularly back up both the db and the site structure.
> 
> Adrien,
> 
> Our “hosting provider” is Linas Vepstas, one of the original developers of 
> GnuCash, on a machine at his home. There is no CPanel or Plex interface and 
> AFAIK nobody has remote shell access to it. OTOH he knows how to set up 
> backups, we'll just need to tell him what to back up. An obvious offsite 
> location would be code.gnucash.org <http://code.gnucash.org/> hosted at Derek 
> Atkins’s house, which is where the wiki and canonical git repositories live. 
> 
> Regards,
> John Ralls

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

Re: Website Platform Discussion

[Adrien Monteleone]

> On Jun 16, 2017, at 11:54 AM, Jon Daley  wrote:
> 
> On Fri, 16 Jun 2017, Derek Atkins wrote:
>> Code performs a nightly mysql dump, and I have a nightly backup of all
>> my servers (including code) to a backup server with storage on my
>> FreeNAS box.  This is all completely automated.  The only thing I do not
>> have, yet, is a an offsite backup plan to protect against fire, tornado,
>> etc.
>> 
>> Linas and I have discussed using each other for offsite backups, but
>> then he disappeared for 6 weeks and we haven't returned to the topic.
> 
>   How much data do you have that needs to be backed up?  I have space 
> that I can offer, depending on how big it is.

We could get the current backup size as a starting point and then add a blank 
cms install size on top of that. (content + structure) Of course, we won’t 
really know till at least a staging version is up and running and content has 
been ported over.

As with any site, images take the most room. I suspect though these will be 
limited to screen shots so I wouldn’t anticipate the requirement being high.

For a ballpark idea, I have backups for an e-commerce and blog site that has 
about 100 blog posts of 250+ words each and about 500 product images of fair 
quality (usually 800-1000px longest side and stored as 75% quality JPGs) and 
that db takes up 500K and the site with images takes up 2GB. Both backup files 
are tar.gz.

-Adrien

> 
> -- 
> Jon Daley
> http://jon.limedaley.com
> ~~
> Work is the curse of the drinking classes.
> -- Rev. William Spooner
> ___
> 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: Time Frame on Wiki Edits

[Adrien Monteleone]

I see a few typos and grammatical errors, so I wouldn’t say it’s ready for 
publication yet.

As for organization, perhaps change [Scripting and Programming] to [“Advanced” 
Usage] or [“Advanced” Usage - Scripting & Programming]

I’d expect to find the info on Logging and Stack Trace to be either under Help 
or Filing Bugs. You could then probably eliminate the odd sounding ‘Error 
Seaching’ (sic) heading.

Also the way [Getting Involved in the Project] reads, the rest of the material 
that follows should be nested under it, which might be odd. Perhaps just keep 
the sentence but remove that heading entirely. It doesn’t seem necessary. Or 
since all of those topics including developing code are "getting involved” 
replace the main heading—[Developing for GnuCash] with [Getting Involved in the 
Project] or something similar like [Contributing to GnuCash]. The other 
headings and text can remain as is.

Overall though, this is laid out much better than the current version.

-Adrien


> On Jun 13, 2017, at 11:17 AM, David T. via gnucash-devel 
>  wrote:
> 
> Hello,
> 
> Two weeks ago, after a flurry of discussion in this list, I and Don (doncram) 
> worked to put together a modified wiki landing page, which was placed as a 
> sandbox page at https://wiki.gnucash.org/wiki/GnuCash/sandbox 
> .
> 
> Since that time, there has been no further activity on any front, and 
> although two weeks is not a very long time to let this season (as it were), I 
> do wonder whether the Developer team has any sense of what amount of time 
> constitutes “the right” amount of time for such a proposal to sit before the 
> changes are sent live. I’d like to get the page pushed out before it gets 
> lost in the mists of time…
> 
> David
> 
> @doncram: once it’s time to move this along, how exactly does one convert the 
> sandbox to its real counterpart?
> ___
> 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: Some Assistance Please

[Adrien Monteleone]

Thank you Derek,

This improves my understanding of the current situation considerably.

Certainly as I noted, I have no issue using the present methods.

Thank you for taking the time to explain this.

Regards,

Adrien

> On May 25, 2017, at 9:45 AM, Derek Atkins <warl...@mit.edu> wrote:
> 
> Adrien,
> 
> Adrien Monteleone <adrien.montele...@gmail.com> writes:
> 
>> Geert,
>> 
>> If the opposite were possible, would that meet the needs?
>> 
>> If using the wiki as the collaboration platform opened up
>> documentation editing to non-developer types but still gave you the
>> desired formats, is that what you are looking for or are there other
>> needs?
> 
> This was the road we've looked at and attempted in the past -- moving
> the documentation development onto the Wiki and then using that to
> produce the various formats required for yelp, windows help, etc.  The
> results were less than stunning.
> 
> This is why we're reluctant to try again without an existence proof that
> the tools have significantly improved and will produce documentation
> that is at least as good as the current process.
> 
>> Looking over mediawiki.org, there are methods using our own render
>> server (or a public one if so desired) and extension plugins to export
>> a variety of formats including XHTML, PDF, ePUB, ZIM, ODF, and yes,
>> DocBook XML. There’s also the option of using PediaPress for people to
>> order a physical bound copy if they so desire.
> 
> If we could translate into Docbook then we could leverage the existing
> tools to generate the outputs we require.  However, how well does the
> tool translate from wiki -> Docbook?
> 
>> The only one presently offered I don’t see included as an extension is
>> MOBI though there are many tools to take any of those other formats to
>> MOBI if really needed. I would think it not too difficult to script
>> the conversion of a resulting ePUB into MOBI. Clicking the MOBI
>> download link could take a trip through ePUB and then the ePub2Mobi
>> conversion to serve the desired file. Is there still a significant
>> case for .mobi files due to .mobi only readers? Is there a current
>> comparison of download stats from gnucash.org?
> 
> I dont know if there are download stats available from code and/or www.
> 
>> An additional advantage of using the wiki as the working and
>> publishing platform is that formats are generated on-demand by the
>> render server. Thus any time someone downloads a copy of the
>> documentation it will always be the most up to date, rather than a
>> milestone-released static version. If that is not desired I suppose
>> some method of drafts vs. published approved pages would suffice, but
>> that will more than likely be handled by control of editing
>> credentials.
> 
> That's not desired; we want the documentation to match the release.
> Someone with 2.4 is better served with the 2.4 documentation.  Someone
> with 2.6 with the 2.6 documentation.  Someone running 2.4 who looks at
> the 2.6 docs might get confused.
> 
>> The render server can also be configured to ‘publish’ specific
>> collections of articles so that the wiki could contain the entirety of
>> the help, tutorial and concepts guide, developer documentation, et
>> cetera, and then particular links will give you a single file of any
>> one of those. So if someone wanted a printed copy of the help and a
>> pdf of the tutorial and concepts guide, they could get each separately
>> all from the wiki and all with the most current approved edits.
> 
> The developer documentation is generated by doxygen from the source
> code.  Moving that into the wiki would be, IMHO, the wrong thing to do.
> The dev docs should live with the code.
> 
>> Just a thought.
>> 
>> -Adrien
> 
> -derek
> -- 
>   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
>   warl...@mit.eduPGP key available

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

Re: Please, Oh, Please, Can we delete the (10 year old and counting) Draft Concept Guide on the Wiki?

[Adrien Monteleone]

They should go, but if there are any objections for some reason, I recommend at 
least adding a NO FOLLOW rule to the site’s htaccess file. That way these 
archives won’t show up in search results. I would say such rules should be 
included for any outdated material.

Regards,
Adrien


> On Nov 11, 2017, at 9:20 AM, Geert Janssens  
> wrote:
> 
> Op zaterdag 11 november 2017 15:55:37 CET schreef David T. via gnucash-devel:
>> Okay,
>> 
>> Once again, I search Google for some aspect of GnuCash functionality, and
>> ONCE AGAIN, one of the top hits there is the 10 year old Draft Concept
>> Guide lurking on the wiki. Not the ACTUAL, CURRENTLY-MAINTAINED Tutorial
>> and Concept Guide. No. The ***Draft Concept Guide*** (ostensibly invisible
>> on the gnucash wiki).
>> 
>> As my subject line suggests, I believe this set of pages should BE REMOVED
>> FROM THE WIKI. I know, I know—I’ve said it before. But, since the pages are
>> still there, it bears repeating.
>> 
>> I continue to question what purpose this inaccurate, outdated, unmaintained,
>> and misleading set of pages serves. The only reason I have heard is that
>> they might serve as a set of templates for other pages. I think that this
>> is a specious argument; first, there does not seem to be much on the wiki
>> that uses many wiki features; and second, if users need more technical
>> guidance, there are numerous sources online to serve as guidance.
>> 
>> I say, “Draft Concept Guide—BEGONE!”
>> 
>> David
>> 
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> As far as I'm concerned they can go.
> 
> Geert
> ___
> 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: GnuCash Draft Concept Guide, or, Whose WIki Is This, Anyway?

[Adrien Monteleone]

David,

I recall replying to such a thread and being in agreement. Perhaps there was 
more than one.

I see no reason to keep out of date pages on a wiki. The entire purpose of a 
wiki is to be able to keep it up to date and to have multiple editors.

If a static info section is desired, then a basic HTML page can be used instead.

The wiki software has ‘templates’ as a feature. We can define our own. We don’t 
need to keep old pages around as ‘samples.’

As for ALL search engines, someone just needs to do two things:

1. remove ALL links TO the outdated pages if they will not be updated. 
(otherwise, just update them)
2. insert a NOFOLLOW rule in the robots.txt file for those pages. (again, only 
if they won’t be updated)

Optionally, a permanent redirect rule on those pages can be added to the 
.htaccess file for the site.

Doing all three would prevent any search engine from finding the pages. The 
only way they could be found is via a scraper or trying to hit the page 
directly via it’s URL - very unlikely.

If that’s still not enough. The pages or section in question could even be 
restricted with a DENY rule in .htaccess and limited only to certain IP 
addresses or people with a certain password. That way, even a scraper or 
someone entering the URL directly can’t see them unless they are so privileged.

But really, the pages should just be removed. A wiki is not a place for a 
‘working draft’ especially one that is so out of date. There are documentation 
procedures and a place for the working copy to be stored.

Regards,
Adrien

> On Nov 30, 2017, at 9:57 PM, David T. via gnucash-devel 
>  wrote:
> 
> Frank,
> 
> I am struggling right now to find the right way to bring up the issue of the 
> Gnucash Draft Concept Guide, which still resides on the wiki.
> 
> As you know, I have proposed on numerous occasions (most recently, two and a 
> half weeks ago) to have these pages removed from the wiki, since they are out 
> of date, inaccurate, poorly written, superceded, and can turn up in search 
> results, giving users incorrect information about Gnucash and its features 
> and functions. 
> 
> In that recent thread, four people responded to my request to remove the 
> Draft Concept Guide. Only you appeared to support retaining these pages, 
> although your primary concern was with the mechanical aspects of Google’s 
> search algorithm, upon which I have no expertise to comment. (I will note 
> that fixing one search engine result set does not preclude some OTHER search 
> engine now or in the future from finding and returning these pages despite 
> your best intentions). 
> 
> You actually offered to move these pages to your own user area, but John 
> noted that might not actually hide the results.
> 
> Two days ago, I went to the wiki to search for information about creating 
> reconciliation reports in response to a question on the user list, and when I 
> entered “reconciliation” into the wiki’s OWN search box, 4 of the first 5 
> hits were for the Draft Concept Guide.
> 
> Since there had been no support for your position to keep the pages, and 
> since you had had two and a half weeks to take whatever action you had 
> proposed to do (and not taken any), I felt it was time to address the Draft 
> Concept Guide issue directly. 
> 
> I did not delete the pages outright (since I do not have the rights to do 
> that), but I did what I considered to be the next best thing, which was to 
> replace all the text in those pages with the latin nonsense that printers 
> have used for hundreds of years to mock up page layouts (“Lorem ipsum”). I 
> even made sure to retain the various structural elements in the pages, going 
> so far as to replace headings and bullet points with latin phrases of similar 
> length.
> 
> Since, as far as I understand, your only reason for retaining these pages is 
> to serve as some sort of model for the Gnucash community to use for wiki 
> pages, my technique allowed these model pages to be retained *without* their 
> turning up in any search results, anywhere. So, that’s the best of both 
> worlds, right?
> 
> Apparently not, as within hours, you had gone and reverted all my changes.
> 
> So, I have a few questions to ask of you, Frank, and of the community.
> 
> 1) First, Frank: What exactly is so special to you about these pages? Why do 
> you insist that they remain forever on the wiki? The only reason I have heard 
> from you is this idea that the pages could provide wiki page template 
> examples. But, my most recent changes preserved the template aspect without 
> retaining the problematic language—and you still reverted the changes. So, 
> there seems to be something *else* with these pages that makes you feel so 
> protective. What is it? My recent changes seem to prove that there is 
> something in the text itself that you are attached to. Can you explain 
> clearly what that attachment is?
> 
> 2) Frank, in the past, you have chastised me 

Re: [GNC-dev] Bugzilla Migration Status -- phase 2 -- please test

[Adrien Monteleone]

I suppose you’re still revising things.

Currently, I see components listed, but no bugs found.

I also tried a password reset but never received the email.

Is this only for official developers to test right now, or anyone who has a 
Gnome Bugzilla account and participated in bug reports?

Regards,
Adrien

> On May 14, 2018, at 4:00 PM, Derek Atkins  wrote:
> 
> Hi Everyone,
> 
> tl;dr: I have a partial migration up and running (~105 / 8588 bugs) and I
> think my migration script is "complete" -- please test.  Also, please let
> me know if you know of any bugs that use the see_also field.
> 
> Long Version:
> 
> As you all know, we use Gnome's bugzilla instance, and they are
> transitioning to gitlab (soon, like by June).  Since we only used Gnome
> infrastructure for BZ and nothing else, we decied to migrate to our own BZ
> instance.  Part of this migration is moving the bug data from Gnome's BZ
> to our own.  To that end I've been working on a script using
> Bugzilla::Migrate and the JSON RPC to pull the data from GnomeBZ and then
> migrate it into our instance.
> 
> At this point in time I *BELIEVE* I am migrating all the data we can get. 
> I think we're ready for the next stage of testing, which is making sure
> the data has been migrated correctly, nothing is missing (from the
> migrated data), and that the BZ instance is, effectively "configured".
> 
> To that end, please check the bugs that I've imported.  They are early in
> the sequence (numerically), but three out-of-sequence bugs I pulled in for
> dependencies and one for attachment testing from early on.   Let me know
> if you need some specific bug #s to search for.
> 
> One thing my data does NOT have is a bug with anytihng in the see_also
> data.  Does anyone know of any bugs that use that field?
> 
> A quite note on user accounts:  Users are created with crandom passwords. 
> If you made any comments/changes/etc to a bug then you have an account,
> and should be able to ask for a password reset.  I would ask that right
> now we make this a read-only test.  We can do write tests soon.
> 
> Also note that I will be blowing away the database regularly as we
> continue testing, so if you do reset your password, it will likely be
> resert again out from under you in the not too distant future.
> 
> Thanks for testing.  If you find any issues please let me know.  Also let
> me know if you have any questions.
> 
> Thanks!
> 
> -derek
> 
> -- 
>   Derek Atkins 617-623-3745
>   de...@ihtfp.com www.ihtfp.com
>   Computer and Internet Security Consultant
> 
> ___
> 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] GnuCash Bugzilla URLs -- /bugzilla or not?

[Adrien Monteleone]

I like the idea to either use a sub-domain OR a sub-folder, but not both. (for 
the same purpose)

I suppose to stay consistent with other practices on gnucash.org, stick with 
the sub-domain.

My usual rule is that if you are providing something that is running a separate 
process from the webserver (such as a bugzilla instance, mailman, webmail, 
wiki, online store, etc.) then use a sub-domain. If you’re just accessing a 
separately organized area of the main website, use a sub-folder.

Though you could have sub-folders that are specifically for specially organized 
info/instances for each sub-domain as applicable. For example, if you have 
several help pages for BZ, those might all be collected under 
bugzilla.gnucash.org/help/ rather than throwing all of them at the top level.

I’m not sure how BZ is organized, but an exception to this rule might be if you 
maintained separate bug lists for the different branches, you might do that 
with sub-folders, but if you have to run separate BZ instances, then probably 
use another level of subdomain—i.e., bugzilla.gnucash.org/maint/ or 
maint.bugzilla.gnucash.org. (probably a bad example since such separation is 
going to be likely messy if someone files a bug under the wrong instance, but 
not so much if there’s one instance with branch organization, which I think is 
already provided from within BZ anyway)

As a side question, will this be a more up-to-date version of BZ? (is there 
one?) I find the organization used by current version a little cumbersome, 
though perhaps that might go away when this becomes a dedicated GnuCash BZ 
instance without any other projects.

Regards,
Adrien

p.s. - don’t forget if you don’t already have it, you’ll need a wildcard 
certificate to handle the subs.

> On May 10, 2018, at 4:52 AM, Mike Evans  wrote:
> 
> On Thu, 10 May 2018 05:37:31 -0400
> "Derek Atkins"  wrote:
> 
>> Hi,
>> 
>> As you are aware, we are looking at migrating from gnome bugzilla to our
>> own instance because gnome is shutting their BZ off.  I've been working on
>> migrating the data, and have what I think is a good migration process in
>> place.  We are at the early stages of testing the migration, but I wanted
>> to open up some high-level questions to everyone.
>> 
>> My first question to you all:  The BZ URL.
>> 
>> The current URLs at gnome are bugzilla.gnome.org/show_bug.cgi
>> 
>> Currently, the URLs for us are bugzilla.gnucash.org/bugzilla/show_bug.cgi
>> 
>> Do people care?  Do you want me to look at removing that /bugzilla in there?
>> 
>> Let me know your thoughts.  I'll post more questions later.
>> 
>> Thanks!
>> 
>> -derek
>> 
> 
> The extra /bugzilla does seem superfluous to me.
> 
> Mike E
> ___
> 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] GnuCash Bugzilla URLs -- /bugzilla or not?

[Adrien Monteleone]

I would think that’s a permalink type setting. BZ is writing that in because 
it’s specified. I’d be shocked (and saddened a little) to discover it was hard 
coded. (editable of course, but then you’d have to recompile BZ!)

Regards,
Adrien

> On May 10, 2018, at 10:00 AM, Derek Atkins  wrote:
> 
> 
> On Thu, May 10, 2018 10:43 am, John Ralls wrote:
>> 
>>> The extra /bugzilla does seem superfluous to me.
>> 
>> On the face of it, yeah, especially since you’ve made the effort to create
>> a “bugzilla.gnucash.org ” vhost.
>> 
>> OTOH, it’s pretty rare to type out a URI these days so it’s not harmful,
>> just ugly.
> 
> I did a simple test to try to remove the extra /bugzilla but it failed and
> locked me out of the server (yay fail2ban).  When I get home I'll take
> more time to try to figure it out.  So it stays for now.  I consider it
> low priority to fix; all existing URLs will be broken anyways, so when we
> mass convert it's not a big deal to re-add the extra /bugzilla in there.
> 
>> Regards,
>> John Ralls
> 
> -derek
> 
> -- 
>   Derek Atkins 617-623-3745
>   de...@ihtfp.com www.ihtfp.com
>   Computer and Internet Security Consultant
> 
> ___
> 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] GnuCash Bugzilla URLs -- /bugzilla or not?

[Adrien Monteleone]

Does setting ‘Administration > Parameters > urlbase' to simply 
“https://bugzilla.gnucash.org/” not do the trick?

Regards,
Adrien

> On May 10, 2018, at 10:00 AM, Derek Atkins  wrote:
> 
> 
> On Thu, May 10, 2018 10:43 am, John Ralls wrote:
>> 
>>> The extra /bugzilla does seem superfluous to me.
>> 
>> On the face of it, yeah, especially since you’ve made the effort to create
>> a “bugzilla.gnucash.org ” vhost.
>> 
>> OTOH, it’s pretty rare to type out a URI these days so it’s not harmful,
>> just ugly.
> 
> I did a simple test to try to remove the extra /bugzilla but it failed and
> locked me out of the server (yay fail2ban).  When I get home I'll take
> more time to try to figure it out.  So it stays for now.  I consider it
> low priority to fix; all existing URLs will be broken anyways, so when we
> mass convert it's not a big deal to re-add the extra /bugzilla in there.
> 
>> Regards,
>> John Ralls
> 
> -derek
> 
> -- 
>   Derek Atkins 617-623-3745
>   de...@ihtfp.com www.ihtfp.com
>   Computer and Internet Security Consultant
> 
> ___
> 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] GnuCash Bugzilla URLs -- /bugzilla or not?

[Adrien Monteleone]

If it is not an Apache problem, one other consideration might be an .htaccess 
rule inserted there by BZ.

Regards,
Adrien

> On May 10, 2018, at 10:19 AM, Derek Atkins <de...@ihtfp.com> wrote:
> 
> Hi,
> 
> BZ is Perl, so no recompiling needed.
> Changing that parameter is not sufficient.  Indeed, when I was testing it
> was set without the added /bugzilla.
> I think the issue is an Apache configuration issue.
> 
> -derek
> 
> On Thu, May 10, 2018 11:10 am, Adrien Monteleone wrote:
>> Does setting ‘Administration > Parameters > urlbase' to simply
>> “https://bugzilla.gnucash.org/” not do the trick?
>> 
>> Regards,
>> Adrien
>> 
>>> On May 10, 2018, at 10:00 AM, Derek Atkins <de...@ihtfp.com> wrote:
>>> 
>>> 
>>> On Thu, May 10, 2018 10:43 am, John Ralls wrote:
>>>> 
>>>>> The extra /bugzilla does seem superfluous to me.
>>>> 
>>>> On the face of it, yeah, especially since you’ve made the effort to
>>>> create
>>>> a “bugzilla.gnucash.org <http://bugzilla.gnucash.org/>” vhost.
>>>> 
>>>> OTOH, it’s pretty rare to type out a URI these days so it’s not
>>>> harmful,
>>>> just ugly.
>>> 
>>> I did a simple test to try to remove the extra /bugzilla but it failed
>>> and
>>> locked me out of the server (yay fail2ban).  When I get home I'll take
>>> more time to try to figure it out.  So it stays for now.  I consider it
>>> low priority to fix; all existing URLs will be broken anyways, so when
>>> we
>>> mass convert it's not a big deal to re-add the extra /bugzilla in there.
>>> 
>>>> Regards,
>>>> John Ralls
>>> 
>>> -derek
>>> 
>>> --
>>>  Derek Atkins 617-623-3745
>>>  de...@ihtfp.com www.ihtfp.com
>>>  Computer and Internet Security Consultant
>>> 
>>> ___
>>> 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
>> 
> 
> 
> -- 
>   Derek Atkins 617-623-3745
>   de...@ihtfp.com www.ihtfp.com
>   Computer and Internet Security Consultant
> 
> 


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

Re: [GNC-dev] AppImage

[Adrien Monteleone]

FYI,

There is already a Flatpak and a Snap available, but it looks like both are 
still at 2.6.x

https://flathub.org/apps/details/org.gnucash.GnuCash
https://snapcraft.io/gnucash-jz

I don’t see a size on the Flatpak, but the Snap is a tad under 111MB.

Interestingly, the .dmg went from ≈112MB to ≈184MB and the .exe went from 
≈120MB down to ≈94MB from 2.6.21 to 3.1.

Regards,
Adrien


> On May 10, 2018, at 4:42 PM, cicko  wrote:
> 
> I just learned a bit more about application packages (AppImage, Snap,
> Flatpak) on Linux after downloading KeePassXC image and find them quite
> convenient. 
> Nabble does not find anything if I search for AppImage so I'd like to see
> you opinion about using one of these for distributing Linux version of
> GnuCash. I've only used AppImage so far and it works fine. Apparently it
> would work on any distribution because all the libraries are packaged with
> the executable.
> If this was applied to GnuCash, would the distribution size be much larger?
> Has anyone tried?
> Even though I'm on Tumbleweed, a rolling OpenSuse distribution with the
> apparently latest software, GnuCash 3.1 is still not available as a
> compatible rpm. Somehow, the distribution of software for Windows still has
> the upper hand in terms of being easy and simple. At least for the end
> users.
> Having an AppImage of the latest GnuCash would, I guess, enable all Linux
> users to have the latest binary version without needing to build it
> themselves and/or depending on multitude of development tools and libraries.
> 
> Is there anything preventing building and packaging the latest (either
> stable or nightly) version of GnuCash in this way? Have you thought about it
> before? Have you tried it already? What were the findings?
> 
> Cheers
> 
> 
> 
> --
> 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
> 


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

Re: [GNC-dev] pricedb policy

[Adrien Monteleone]

On the contrary, there is such a thing.

Certainly, in near real-time, as you describe, no there isn’t.

But when booking an existing asset at current market prices when starting a 
book, there is. There might be various reasons for this approach, not the least 
of which is that the original actual price paid in the home currency is no 
longer available. (and not relevant to any balancing with other accounts - this 
will balance with Equity:Opening Balances)

And I was able to edit the ‘first’ user:price. So if it is supposed to be 
read-only, it’s not. (or at least wasn’t in 2.6.19)

Regards,
Adrien

> On May 13, 2018, at 9:42 AM, Christopher Lam <christopher@gmail.com> 
> wrote:
> 
> I'm sorry there's no complication.
> 
> There's no such thing as "price source was not correct" while entering a 
> transaction.
> 
> Let's say I transfer 100 GBP to 150 USD, currently generating a pricedb entry 
> of GBP/USD=1.5, later "realize" the price source was incorrect and should 
> have been GBP/USD=1.6, it would mean that the USD expense or account would 
> not have received $150USD in the first place, causing all sorts of USD 
> imbalances or incomplete funds for purchase.
> 
> My view is that "user:price"-type pricedb entries are usually directly 
> generated from transactional transfers, therefore can be considered a 
> lookup-table for existing transfers, and should not be user-editable.
> 
> 
> On 13/05/18 22:20, Adrien Monteleone wrote:
>> Christopher,
>> 
>> I’ll add a complication for you.
>> 
>> Suppose one enters a transaction and later realizes the price source was not 
>> correct.
>> 
>> Does editing the originally generated user:price affect the transactions in 
>> the register? Are they in-sync or now unrelated?
>> 
>> If editing user:price does not change the register, does that mean you have 
>> to edit the register entries (or use correcting entries) and if so, does 
>> this alter the original user:price? (or add another?)
>> 
>> If the two get out of sync, how do you determine what is the true source to 
>> use to regenerate upon loading and Check?
>> 
>> Regards,
>> Adrien
>> 
>>> On May 13, 2018, at 5:34 AM, Christopher Lam <christopher@gmail.com> 
>>> wrote:
>>> 
>>> Hi Devs
>>> 
>>> I wish to enquire about policy on pricedb.
>>> 
>>> As far as I can understand, pricedb receives entries from 3 different
>>> sources:
>>> 
>>> 1. from entering transactions into the register, if the transaction
>>> involves a foreign currency conversion or stock. e.g. originating account
>>> is GBP, target currency is USD --> creates a pricedb entry GBP/USD. (can't
>>> determine which one is deemed to be the base currency). These pricedb
>>> entries are tagged "user:price" or "user:xfer-dialog".
>>> 
>>> 2. from online sources eg alphavantage. This requires careful setup, and
>>> seems to create price entries for all foreign currencies / commodities,
>>> compared to the book currency (in my case AUD). These are tagged
>>> "Finance::Quote".
>>> 
>>> 3. entries added by the user. These are tagged "user:price-editor".
>>> 
>>> From my review of code so far, pricedb entries are rather important in
>>> reports... an incorrect pricedb entry will lead to incorrect foreign
>>> currency reporting, even if the transaction contains the exact transfer
>>> amount.
>>> 
>>> My concerns relate to (1) above. I believe these transactional prices are
>>> always more accurate than online quotes, because they describe the exact
>>> prices achieved.
>>> 
>>> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
>>> same day, the second entered price will overwrite the first. (<- according
>>> to my last test)
>>> 
>>> I'd think it would be important for accuracy that, upon book opening, and
>>> Check, the user:price data should be *overwritten* by the actual
>>> prices obtained from the transactions. Moreover if there are several
>>> transactions involving commodities, Check should **add** relevant
>>> amounts to ensure accurate pricing.
>>> 
>>> e.g.
>>> 01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
>>> 01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)
>>> 
>>> should generate a price for "200 GBP to 302 USD -> pricing 1.51 USD/GBP)
>>> 
>>> Unfortunate

Re: [GNC-dev] pricedb policy

[Adrien Monteleone]

Christopher,

I’ll add a complication for you.

Suppose one enters a transaction and later realizes the price source was not 
correct.

Does editing the originally generated user:price affect the transactions in the 
register? Are they in-sync or now unrelated?

If editing user:price does not change the register, does that mean you have to 
edit the register entries (or use correcting entries) and if so, does this 
alter the original user:price? (or add another?)

If the two get out of sync, how do you determine what is the true source to use 
to regenerate upon loading and Check?

Regards,
Adrien

> On May 13, 2018, at 5:34 AM, Christopher Lam  
> wrote:
> 
> Hi Devs
> 
> I wish to enquire about policy on pricedb.
> 
> As far as I can understand, pricedb receives entries from 3 different
> sources:
> 
> 1. from entering transactions into the register, if the transaction
> involves a foreign currency conversion or stock. e.g. originating account
> is GBP, target currency is USD --> creates a pricedb entry GBP/USD. (can't
> determine which one is deemed to be the base currency). These pricedb
> entries are tagged "user:price" or "user:xfer-dialog".
> 
> 2. from online sources eg alphavantage. This requires careful setup, and
> seems to create price entries for all foreign currencies / commodities,
> compared to the book currency (in my case AUD). These are tagged
> "Finance::Quote".
> 
> 3. entries added by the user. These are tagged "user:price-editor".
> 
> From my review of code so far, pricedb entries are rather important in
> reports... an incorrect pricedb entry will lead to incorrect foreign
> currency reporting, even if the transaction contains the exact transfer
> amount.
> 
> My concerns relate to (1) above. I believe these transactional prices are
> always more accurate than online quotes, because they describe the exact
> prices achieved.
> 
> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
> same day, the second entered price will overwrite the first. (<- according
> to my last test)
> 
> I'd think it would be important for accuracy that, upon book opening, and
> Check, the user:price data should be *overwritten* by the actual
> prices obtained from the transactions. Moreover if there are several
> transactions involving commodities, Check should **add** relevant
> amounts to ensure accurate pricing.
> 
> e.g.
> 01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
> 01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)
> 
> should generate a price for "200 GBP to 302 USD -> pricing 1.51 USD/GBP)
> 
> Unfortunately I don't do C so cannot help with coding, but would think that*
> the "user:price" prices should *always* be regenerated from the transaction
> amounts during Check & Repair and upon loading datafile.*
> 
> Thoughts?
> ___
> 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] pricedb policy

[Adrien Monteleone]

I didn’t think of that one. Pondering that accounting nightmare makes me glad I 
wasn’t concerned with accounting last time I was out of country and shopping in 
just such a fashion. Most of the time even receipts weren’t available. I 
probably paid a different exchange rate at each vendor. (It’s harder than many 
think to keep fractional rates in your head and do math with them while making 
purchasing decisions if you’re not used to doing so.)

Regards,
Adrien

> On May 13, 2018, at 9:44 AM, Alen Siljak  wrote:
> 
> I'll add a simple case that maybe does not happen often in real accounting 
> but happens to me all the time.
> 
> When traveling and exchanging cash at various small shops, the exchange rate 
> varies wildly. This, however, should not have the precedence compared to the 
> official central bank's rate. Also, what happens when the currency is 
> exchanged a few times per day?
> 
> These are the negative side-effects of your proposal. It is, however a very 
> valid question if the reports are using only one rate.
> 
> In that case, I would prefer to be in control of the rate used. 
> 
> Another important item is that the Australian Tax Office, for example, 
> publishes the official exchange rates for the tax year and I would really 
> need to be able to use that rate for all my tax reports, irrespective of what 
> the other entered prices may be.
> 
>> Sent: Sunday, May 13, 2018 at 12:34 PM
>> From: "Christopher Lam" 
>> To: gnucash-devel@gnucash.org
>> Subject: [GNC-dev] pricedb policy
>> 
>> My concerns relate to (1) above. I believe these transactional prices are
>> always more accurate than online quotes, because they describe the exact
>> prices achieved.
>> 
>> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
>> same day, the second entered price will overwrite the first. (<- according
>> to my last test)
>> 
> ___
> 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] Bugzilla Migration Status -- phase 2 -- please test

[Adrien Monteleone]

Interesting...

From a non-developer perspective:

When logging into gnome.bugzilla.org, the very first link in the center with 
the ‘circle icons’ is “My Bugs”. As well, in my footer, the *only* thing there 
is a link “My Bugs” on the left. Both link to the URL John provided.

I watch some bugs, though I may not have touched any in two weeks, yet see 
neither of these links.

Regards,
Adrien

> On May 15, 2018, at 1:35 PM, Derek Atkins  wrote:
> 
> 
>> Gnome's BZ also has a custom "My Bugs" link at the left end of the footer
>> that produces another custom page
>> https://bugzilla.gnome.org/page.cgi?id=describeuser.html. The one at the
>> right end runs a search just like the one on bugzilla.gnucash.org.
> 
> Hmm.  I do not see a My Bugs link on the footer of my Gnome BZ page
> (although I do see it on our BZ instance).  When logged in to Gnome my
> footer says:
> 
> Gnucash Bugs | My GC Bugs
> Bugs I watch with patches | Bugs I've touched in the last two weeks
> 


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

Re: [GNC-dev] Request to mailing list gnucash-devel rejected

[Adrien Monteleone]

This happens to me when I don’t catch my e-mail client selecting the wrong 
e-mail account as the sender. (I manage several)

Regards,
Adrien

> On May 22, 2018, at 8:01 AM, Dennis Powless  wrote:
> 
> I'm registered to the list, at least on my end.  I'll direct to the git
> mailing list.
> 
> Let me know if this is different on your end?
> 
> Dennis
> 
> 
> 
> On Tue, May 22, 2018 at 2:00 AM,  wrote:
> 
>> Your request to the gnucash-devel mailing list
>> 
>>Posting of your message titled "Git"
>> 
>> has been rejected by the list moderator.  The moderator gave the
>> following reason for rejecting your request:
>> 
>> "Non-members are not allowed to post messages to this list. I suggest
>> you ask this on a "Git list"."
>> 
>> Any questions or comments should be directed to the list administrator
>> at:
>> 
>>gnucash-devel-ow...@gnucash.org
>> 
> ___
> 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] GDPR and gnucash as a project

[Adrien Monteleone]

Psuedonymization can be used in most if not all cases of removal requests to 
maintain data but render it ’not personal’.

There are also exceptions for data deemed necessary for and that is still being 
used for its original intended purpose which should drastically reduce even 
those cases.

Regards,
Adrien


> On May 22, 2018, at 8:02 AM, Geert Janssens  
> wrote:
> 
> Yesterday John raised some concerns about GDPR compliance of the gnucash 
> project itself.
> 
> This is a different question from the one Mike Evans asked in April this year 
> about GDPR compliance by people *using* gnucash.
> 
> This requires some thought as the GDPR has many aspects.
> 
> The essence of the GDPR (global data protection regulation) is to regulate 
> the 
> processing of EU citizen's personal data.
> 
> The first question this raises is which personal data does the gnucash 
> project 
> process ? So far I have come up with:
> - e-mail addresses on the gnucash mailing lists
> - user accounts in bugzilla
> - user accounts in our wiki
> - user accounts on Uservoice
> The above are pretty clear. There are others that are less clear to me 
> whether 
> they constitute personal data or not:
> - the actual messages people send to mailing lists and which are stored in a 
> public archive
> - the actual comments on bugs
> - the actual page edits in wiki
> And also what about things like our irc channel ? Does that fall under 
> processing personal data ? We don't really run the irc channel, we only use 
> it. But on the other hand we do publish irc logs. Does GDPR apply to those ? 
> I 
> can't tell really.
> And the same question could be asked about our code itself in a way. Does a 
> code contribution represent personal data ? Each commit logs an e-mail 
> address 
> of a committer which can't easily be removed.
> 
> Once we have established what constitutes personal data we need to formulate 
> a 
> "privacy policy" in which we explain how we process this data and whether 
> third parties are involved (think github, uservoice, travis-ci, our social 
> media presence,...).
> 
> An open source project is a bit in an odd situation because we do almost 
> everything in public so there's very little being kept private. We publish 
> archives of our mailing list conversations, irc logs, commits and so on. We 
> have to inform our users of this in a clear manner. The good thing is we only 
> do keep the absolute minimum amount of information to function: a username 
> (which can be an e-mail address) and a password is usually sufficient. Unless 
> the message content also falls under personal data.
> 
> We also require explicit consent to use the personal data. We're reasonably 
> good in this respect as for all services we offer we require the user to opt-
> in. We will never use for example mail addresses gathered from bugzilla user 
> accounts to automatically enroll the same people in a mailing list. We 
> probably should more clearly indicate what people subscribe to in each case 
> while they are registering. So when registering for a mailing list, it should 
> be pretty clear that anything the person contributes will end up on a public 
> web page. The same goes for all other services we offer and make use of.
> 
> Next a person should be allowed to make corrections to the personal data we 
> were provided with and "the right to be forgotten". For user accounts in the 
> various services we offer this is not really a problem. Most of these do 
> allow 
> the user to change passwords, user names or e-mail addresses. However if the 
> message content is also part of private data it becomes much harder. In that 
> case the question becomes whether a user can request a mail message to be 
> removed from our mailing list archive. I have no answer to this.
> 
> Next there is the requirement to protect children. I don't know for sure if 
> this applies to us. If it does our registration processes should ask a 
> minimum 
> age and require consent of a parent or equivalent in order to continue with 
> the registration. This is mostly mentioned in the context of social networks. 
> But as we publish all communication in public it may apply to us as well.
> 
> And finally in case of data breaches we should inform the affected people of 
> this. Again one I don't know exactly how to deal with.
> 
> This mail is meant as a kick-off to start thinking about this. Any feedback 
> is 
> very welcome.
> 
> Regards,
> 
> Geert
> 
> 
> ___
> 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] Bugzilla Migration Status -- phase 2 -- please test

[Adrien Monteleone]

Thanks for the clarification.

Regards,
Adrien

> On May 15, 2018, at 10:03 AM, John Ralls <jra...@ceridwen.us> wrote:
> 
> The bugs Derek’s imported so far are (which 3 exceptions) from 10 years ago 
> so only the users who were involved in those 103 bugs are in the system and 
> can get a password reset. That will change as he gets comfortable with the 
> imports and does larger ones. 
> 
> Browse is broken, searching by component returns “zarro” even if there are 
> bugs with that category.
> 
> Regards,
> John Ralls
> 
> 
>> On May 14, 2018, at 8:56 PM, Adrien Monteleone 
>> <adrien.montele...@lusfiber.net> wrote:
>> 
>> I suppose you’re still revising things.
>> 
>> Currently, I see components listed, but no bugs found.
>> 
>> I also tried a password reset but never received the email.
>> 
>> Is this only for official developers to test right now, or anyone who has a 
>> Gnome Bugzilla account and participated in bug reports?
>> 
>> Regards,
>> Adrien
>> 
>>> On May 14, 2018, at 4:00 PM, Derek Atkins <de...@ihtfp.com> wrote:
>>> 
>>> Hi Everyone,
>>> 
>>> tl;dr: I have a partial migration up and running (~105 / 8588 bugs) and I
>>> think my migration script is "complete" -- please test.  Also, please let
>>> me know if you know of any bugs that use the see_also field.
>>> 
>>> Long Version:
>>> 
>>> As you all know, we use Gnome's bugzilla instance, and they are
>>> transitioning to gitlab (soon, like by June).  Since we only used Gnome
>>> infrastructure for BZ and nothing else, we decied to migrate to our own BZ
>>> instance.  Part of this migration is moving the bug data from Gnome's BZ
>>> to our own.  To that end I've been working on a script using
>>> Bugzilla::Migrate and the JSON RPC to pull the data from GnomeBZ and then
>>> migrate it into our instance.
>>> 
>>> At this point in time I *BELIEVE* I am migrating all the data we can get. 
>>> I think we're ready for the next stage of testing, which is making sure
>>> the data has been migrated correctly, nothing is missing (from the
>>> migrated data), and that the BZ instance is, effectively "configured".
>>> 
>>> To that end, please check the bugs that I've imported.  They are early in
>>> the sequence (numerically), but three out-of-sequence bugs I pulled in for
>>> dependencies and one for attachment testing from early on.   Let me know
>>> if you need some specific bug #s to search for.
>>> 
>>> One thing my data does NOT have is a bug with anytihng in the see_also
>>> data.  Does anyone know of any bugs that use that field?
>>> 
>>> A quite note on user accounts:  Users are created with crandom passwords. 
>>> If you made any comments/changes/etc to a bug then you have an account,
>>> and should be able to ask for a password reset.  I would ask that right
>>> now we make this a read-only test.  We can do write tests soon.
>>> 
>>> Also note that I will be blowing away the database regularly as we
>>> continue testing, so if you do reset your password, it will likely be
>>> resert again out from under you in the not too distant future.
>>> 
>>> Thanks for testing.  If you find any issues please let me know.  Also let
>>> me know if you have any questions.
>>> 
>>> Thanks!
>>> 
>>> -derek
>>> 
>>> -- 
>>> Derek Atkins 617-623-3745
>>> de...@ihtfp.com www.ihtfp.com
>>> Computer and Internet Security Consultant
>>> 
>>> ___
>>> 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

[GNC-dev] New bugs still okay to file? - status of migration

[Adrien Monteleone]

Derek,

Would it be better to wait to file any new bugs at the moment?

I have some to file, but they are not critical, so they can wait, but if it’s 
no issue I’ll put them in now. I just don’t want to forget about them.

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

Re: [GNC-dev] BZ-emails; was: Bugzilla Migration Status -- phase 2

[Adrien Monteleone]

Perhaps a bug, perhaps a feature. You’d have to check with the BZ devs.

I’ve seen some site security recommendations to NOT show a different message.

Personally, I doubt it really discourages hackers or makes their task harder 
and it just frustrates a user who isn’t sure what address he/she signed up with.

Regards,
Adrien

> On May 15, 2018, at 3:55 PM, Frank H. Ellenberger 
>  wrote:
> 
> At first, IMHO there is a bg in bugzilla:
> "A token for changing your password has been emailed to
> frank.h.ellenber...@gmail.com. Follow the instructions in that email to
> change your password."
> But there is no email. If the user is not in the database the message
> should be different.
> Or an email should be sent "Sorry, I don't know you..."
> 
> Creating a new account with a different address works. Email gets sent.
> 
> Am 15.05.2018 um 20:35 schrieb Derek Atkins:
> :
> ___
> 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] BZ: Comments

[Adrien Monteleone]

> On May 23, 2018, at 7:28 AM, Derek Atkins  wrote:
> 
>> However as we host bugzilla at gnucash.org, it should be
>> obvious the database is about gnucash.
>> So perhaps we can reuse the product field for a more useful
>> separation of bugs
>> How about having "Gnucash" for that program, "Documentation"
>> for all documentation related bugs and "Website" for our website related
>> bugs
>> Documentation and Website are currently components of gnucash so they
>> would be moved.
>> This split more or less follows the same separation as we have in
>> git. If we take that as a guide we may also want an "OS integration"
>> product covering issues specific to the Windows and OS X integration
>> repos (gnucash-on-windows and gnucash-on-osx)

If creating a product for ‘Website’ would a ‘Wiki’, ‘Mailman’ and and dare I 
say, ’GnuCash-Bugzilla’ products section also be in order? (the last being not 
for the software, but for the GnuCash instance of it)

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

Re: [GNC-dev] Register text selection

[Adrien Monteleone]

David,

I just repeated your steps verbatim and I don’t get the same result.

Note, I’m using 3.1-2 on High Sierra. (Your screenshot looks like 2.6x)

When I start typing ‘12345', the field in focus is the NUM field in the first 
blank transaction in the Checking register and it reflects my typing. (as does 
the status bar.)

Though I don’t understand why you are hitting TAB after cancelling the 
Reconcile Window.

If I don’t hit tab, the focus (and active editing as expected) is on the date 
field in that same transaction. TAB only advances me to the NUM field.

Also, before sending this I remembered I still had 2.6.21 installed. So I 
tested your steps there and sure enough, I get the same result as you.

So, this is fixed in 3.1-2. (or earlier)

Regards,
Adrien

> On May 22, 2018, at 9:40 AM, David T. via gnucash-devel 
>  wrote:
> 
> Dang. The list doesn't like how Mac Mail handles attachments!
> Let's see if this will work...
> 
> 
> 
>  From: David T. via gnucash-devel 
> To: Geert Janssens  
> Cc: gnucash-devel@gnucash.org
> Sent: Tuesday, May 22, 2018 7:21 PM
> Subject: Re: [GNC-dev] Register text selection
> 
> Geert,
> 
>> On May 22, 2018, at 1:22 PM, Geert Janssens  
>> wrote:
>> 
>> Op maandag 21 mei 2018 19:44:57 CEST schreef David T.:
 On May 21, 2018, at 6:14 PM, Geert Janssens >
 wrote:> 
 Op maandag 21 mei 2018 13:08:05 CEST schreef Robert Fewell:
> I have been looking at getting the middle mouse button to work for
> pasting
> selected text and whilst trying to do that started to wonder about the
> existing preselected text.
> 
> Currently...
> If you open a register, the blank transaction date text is preselected.
> If you start Gnucash with saved open registers, the last register in the
> list to load has the blank date text preselected, this may not be the
> current open register.
>>> 
>>> I would like to point out that I find *this* aspect of the register behavior
>>> highly confusing.
>>   
>> I had to re-read the description to get what you guys mean. I have *never* 
>> seen this precise behavior as described by Bob.
>>   
>> When I open gnucash the any keypresses I type before using my mouse will 
>> always go to the currently active tab. If that's a register tab it will 
>> alter the data field as that's the field selected by default.
>>   
>> The only variation I can think of would be if you have configured gnucash to 
>> open each tab in a separate window. I don't do that and haven't tested how 
>> it behaves in that case.
> 
> I am talking about multiple tabs open in one main window.
> 
> Here is the way I can demonstrate the problem.
> 
> Open GnuCash and close all tabs except the main Chart of Accounts.
> 
> Now, in sequence, open:
> 1) Your Checking account
> 2) Your Cash account
> 
> This will result in your GnuCash having the following tabs, in order: 
> Accounts, Checking, Cash.
> 
> Next, click on the Checking account tab.
> Click Reconcile, and OK in the Reconcile Information Window. Next, in the 
> Reconcile window, immediately click Cancel.
> 
> Now, the status bar at the bottom will show the date. Press Tab. Enter a 
> number (like 12345). The status bar will show the number you are entering, 
> ***but the register on screen will NOT show any change.*** This is because 
> the data is going into the Cash tab at the bottom. 
> 
> I am attaching a screen shot of my GnuCash at this particular juncture, which 
> shows: 
> 
> * the Checking account register (as indicated in the title bar at the top)
> * the status bar with my “12345” entry indicated
> * the register itself, which shows NO 12345.
> 
> If I access the Cash tab, the information is there. Interestingly, if one 
> clicks the Cancel button while still viewing the Checking register, there is 
> no effect on the (hidden) transaction that is being edited. You can only 
> cancel the transaction when it is in the current view.
> 
> David T.
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> 
>  PM.png>___
> 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] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

[Adrien Monteleone]

Folks,

Perhaps my comments are not wanted, or out of place, but as an active user, 
someone who contributes a bit of assistance on the mailing list, and just 
someone who in general helps people less knowledgable with software selections 
and support, I have to ask, “Christian, did you consider the impact on complete 
newbies who might stumble upon and install, for whatever reason, the 2.6.x 
branch?” Or even someone who is still running it and contemplating an upgrade? 
As someone who helps out mom and pop businesses adopt GnuCash, the prospect of 
installing a full major version behind, bugs and all, less functionality, et 
cetera, and WASTING their time would leave me and them, nothing short of 
extremely perturbed when we eventually find out there is a more recent version. 
(*I* know now, but *they* won’t and they might not find me until afterwards, 
and what of others like me just entering this journey?) Sure, *I* can see where 
it would be ’nice’ to maintain an older version for certain ‘cut-off’ 
compatibility reasons, but those *are* the reason for a fork. (really, though, 
your initial stated reason was a compiling problem, which I though John 
answered adequately) I sure don’t want to have to repeatedly explain to people 
that 2.6.x is not supported if there is an ‘official’ branch in the Git repo 
available. (not that newbies would be looking there mind you, but one thing 
I’ve learned with this project is you can’t count on what you expect from how 
people ‘find’ you or install the software.)

I’m not a dev so I have a less than important perspective, but perhaps you 
should be aware, that there are some out here who aren’t devs who would not be 
appreciative of more than one official version that wasn’t actually an actively 
and officially supported version. I don’t know of any software project where 
that is acceptable. (If it isn’t supported, it isn’t ‘official’) It isn’t a 
matter of what is possible that can function or not, it’s a matter of 
expectation of what is supported and what isn’t. If the main devs don’t want 
to, or don’t have the resources to, support more than one version, then the 
answer is a fork. Please consider you might be making life unpleasant for more 
than just whatever you are willing to take one. You are obligating many others 
and you are creating an expectation you can’t even fully scope, much less 
fulfill. (or even at least initially be called to fulfill) Others are going 
have to have to deal with this ‘old version’ for as long as it exists, not just 
you.

Regards,
Adrien

 

> On Jun 2, 2018, at 7:28 PM, John Ralls  wrote:
> 
> 
> 
>> On Jun 2, 2018, at 2:05 PM, Christian Stimming  
>> wrote:
>> 
>> Am Samstag, 2. Juni 2018, 08:16:35 schrieb John Ralls:
> But why do we keep a "gnucash" repo at all and not only everyone's
> personal
> repository? Of course there is some sort of project belonging. My
> proposal
> is to still keep the 2.6 branch a little bit more alive, and one or two
> maintenance releases might be spun off from there. I'd be the one who
> does
> the housekeeping there, as discussed already.
 
 Considering you do offer to take care of that 2.6 branch I can live with
 having one. If John disagrees you may need to make it a core policy
 decision request and check for a broader opinion there.
>>> 
>>> I disagree for the user and contributor confusion reasons already stated,
>>> because I think that the old Windows build system should be retired, and
>>> because I think Christian has forgotten how much work goes into support and
>>> won’t have time to devote to it.
>>> 
>>> If Christian wants to fork GnuCash to maintain 2.6.x, he’s free to do so,
>>> but it should be clear to all that it’s Christian’s fork and not “Official"
>>> GnuCash. It’s much clearer and cleaner if the fork lives in Christian’s own
>>> public repository with its own bug tracker and its own support mailing
>>> list. It’s 10 minutes work to set all of that up on Github, so what’s the
>>> point of keeping it in the Github repository?
>> 
>> *sigh* Of course there is already a private fork, just as everyone else 
>> around 
>> here is free to privately fork anything that he/she wants. 
>> https://github.com/cstim/gnucash/tree/branch-2.6
>> However, that's not the point of our common project gnucash. "Official", as 
>> you call it.
>> 
>> Talking of core policy decision: Ultimately the decision is about whether 
>> there might be another 2.6.x release after the 2.6.20 in April, which in 
>> turn 
>> is the reason for the existence of any 2.6 branch. John, it seems you 
>> decided 
>> that there should not be any such release anymore under any circumstances. 
>> Had 
>> this been a decision following our decision process,
>> https://wiki.gnucash.org/wiki/Decision_process
>> , I would have been the voice that raises a objection to that decision.
>> 
>> From my point of view, April isn't too far away and there might indeed be a 
>> 

Re: Beyond 2.8 - version numbering

[Adrien Monteleone]

> On Jan 10, 2018, at 11:00 AM, Geert Janssens  
> wrote:
> 
> Op donderdag 4 januari 2018 00:23:57 CET schreef Frank H. Ellenberger:
>> Am 03.01.2018 um 17:41 schrieb Derek Atkins:
>>> I see no reason that we can't jump from 2.7.x to 3.0[.0] when we release.
>>> And since we DID upgrade to GTK3, I think we should do that.
>> 
>> +1
> 
> How is the upgrade to gtk3 (from gtk3, so a fundamental version change) 
> important in the decision to make a fundamental version change for gnucash as 
> well ?
> 
> We didn't do so when we started to support guile 2 for example, nor when we 
> changed from aqbanking 4 to aqbanking 5.
> 
> Your reply also alludes we should follow Gtk's fundamental numbering as 
> gnucash has done in the past as well.
> 
> However I currently see several reasons *not* to continue that scheme. In no 
> particular order:
> 
> * The currently active developers plan to replace gtk eventually. This is 
> still far away and conceptual, but if it does happen gtk's numbering wouldn't 
> make sense.
> 
> * Gtk itself has recently decided to change its numbering policy. The project 
> has decided to release incompatible changes every two years, in effect 
> updating the fundamental number at the same pace. Our release cycle is much 
> slower than that (typically 3-4 years). So our release numbers will start 
> falling behind on gtk's after some time. So it would mean in the best case 
> we'd go from 3.0.x to 4.0.x if we try to keep up with gtk, or in the worst 
> case from 3.2.x to 5.0.x if we decide to skip a gtk release. In the first 
> case 
> the middle number would never be used any more, in the latter we'd get 
> unexpected version jumps. I think we all agree that latter is not an option.

I should think that the major version jump does not necessarily need to be the 
same exact specific gtk number. It just needs to increment. So if you skipped 
gtk3 and opted to work straight on moving to gtk4, then your next major version 
would still be 3.0. If you make 3.0 now in the move to gtk3, and you skip on to 
gtk5 because of the differences in Gnome’s and GnuCash's development schedules, 
that GnuCash major version would be 4.0. It’s the next version because it is a 
fundamental change, but I don’t think the guideline means you have to be tied 
to someone else’s actual number or else every app following that scheme would 
use the same version numbers as gtk. That might work fine for the Gnome desktop 
and Gnome applications that are released as part of the desktop environment by 
Gnome developers, but I don’t see that it makes sense for outside projects, and 
certainly not cross platform apps.

Would you switch numbering schemes entirely if you switched to Qt? I suppose 
until GnuCash adopts an MVC approach, incrementing the major version with gtk 
(or Qt) changes has merit, but I would think the ‘cleaner’ approach would be to 
have your own versioning scheme independent of platform, toolkits, or even 
underlying language.


> 
> 
> We clearly all agree the jump to 3.0 is in order. Personally however I'd not 
> do it because the version of gtk we now depend on is also 3.x.
> 
> Perhaps that's not what you meant to imply. In which case the above is just a 
> confirmation of why we shouldn't from my point of view.
> 
>> 
>>> As for whether to drop the third entry is less important to me, but I
>>> still think it makes sense to have 3.0.0, 3.0.1, etc., for bugfixes and
>>> leave 3.1/3.2 for more major changes.
>> 
>> +1
> 
> So this indirectly advocates to keep a distinction between fundamental 
> changes 
> and major changes. What criteria make this distinction in a way that's 
> relevant enough to a maintainer and - even more importantly - an end user to 
> do so ?

I would think file incompatibility is a clear distinction. But if that’s not 
the case, the developers will have to come up with their own guidelines. 
Rebasing major portions of the code (as you are currently doing) might be just 
such a reason.

Personally, I’d be confused as a user if an update was only a bug fix and the 
minor number changed. I’d expect to see new features as well in that case. That 
may be simply a matter of habit, though since that usage is so pervasive, I’m 
sure I’m not the only one with such expectations.

> 
>> 
>> Maintainers might have a policy to update bugfixes in their current
>> release, mayor changes in the next release and for fundamental changes
>> both versions.
>> 
> I understand "bugfixes in their current release" and "major changes in the 
> next release", but I don't understand what you tried to convey with "and for 
> fundamental changes both versions". Can you explain it ?
> 
> I will assume with "maintainer" you are mostly referring to distro packagers 
> and similar, people that take our sources and offer it in a larger context.
> 
> I understand these people need information to decide whether a new release 
> can 
> be considered maintenance or not. I don't see 

Re: On development/release processes and version numbers

[Adrien Monteleone]

For clarification, Ubuntu supports their LTS for 5 years, (both desktop and 
server) but they release one every 2 years. Debian adopted a similar approach, 
but the two are a year out of sync.

As most know, Ubuntu uses a date based version numbering scheme with point 
releases for bug fixes. Debian also uses a timed-release model, but they use 
x.y.z notation instead of yy.mm.z

RHEL offers standard support for 5 years, but they have 3 additional support 
levels topping out at 10 years total, with the option for special add-on 
support long beyond that. (for the right price I’m sure) I didn’t check their 
release cadence against Debian/Ubuntu.

Libreoffice also uses a time-based release x.y.z scheme where ’x’ is the next 
major release (in their case, every 2.5 years), ‘y’ includes new features and 
is released every 6 months (supported for 9) and ‘z’ is a monthly bug-fix 
release. They support 2 released x.y versions at a time (for about 9 months 
each) with a third being always bleeding edge as the next release. They do note 
that this process is resource intensive despite (or because of) their large 
team. I would think this has more to do with the tight schedule though rather 
than the general scheme itself.

If the goal is to look ‘fresh’ for users, then I’d think a time-based numbering 
scheme is the way to go. (either by dates, or x.y.z) But if semantic versioning 
is more important, then you’re destined to appear ‘stale’ since development of 
major improvements is slow to occur due to a small team and limited resources. 
(not that I think anyone is complaining, everyone working on this project is 
much appreciated)

Based on the GnuCash release cadence I would think a 2 year LTS policy would be 
sufficient to maintain with bug-fixes only, while all new features (even minor 
ones) and major changes go into the ‘fresh’ version. Two versions seems like 
the least amount of work and is pretty fair.

There are two other topics that might assist with the ‘stale vs. fresh’ 
impression: reports and modules. Judging by the mailing list topics, it seems 
reporting is the area users care most about having as a new ‘feature’ than 
actual application functionality. Certainly, reports can be added or improved 
for the LTS users since they are able to be installed separately and don’t 
really constitute new ‘features’ in the main app. As long as the plugin-module 
model is supported, that route can offer ‘new features’ as well until they are 
integrated into main. With those two in mind, the LTS policy could even be 5 
years since it would be possible to add-on needed improvements while the core 
dev work is on toolkits, MVC, language rebasing and moving to full database 
usage. (those report writers and plugin maintainers would have to keep up with 
the ‘fresh’ version of course, maybe even merging into it for the next major 
release, but their original code will last as long as the LTS policy)

Just some thoughts,
Adrien

> On Jan 25, 2018, at 1:41 PM, cicko  wrote:
> 
> Looks like a start of an interesting discussion.
> I'll chip in just a few drops at this time and won't repeat myself in terms
> of personal preferences for the version numbers because there are other
> concerns to take into consideration there, as well.
> 
> The release management need not necessarily be tied to the development and
> code branching strategy. Here is an interesting model that I've tried to
> emulate in practice but never got as far as having the full spectre of
> branches in a repo (mostly because I never had git in professional projects
> and Open Source ones are fairly small for the full model :'( ). It is
> interesting, nonetheless, to read into it and utilize the ease of switching
> and merging branches git provides.
> http://nvie.com/posts/a-successful-git-branching-model/
> In brief, you could still have two main branches: unstable and stable. There
> are numerous other branches in practice. The feature branches merge to
> unstable, while hotfixes merge to stable branch. In this model, master is
> the stable branch, the mirror image of the GnuCash branch stability, but the
> practical difference is just in branch names. The code flow is likely still
> the same. What I find quite practical with git is that there can be lots of
> active branches that span from the main two - unstable and stable - and are
> used for new feature development or bug fixes.
> An opposite, perpendicular approach would be a branch per version number.
> This model is more oriented towards end-users and, in my opinion, makes more
> sense for large providers with a large and profitable user base. This seems
> very demanding on the development team as well as the release management
> process.
> 
> As far as product management goes, with release version numbers, there will
> be lots of factors, I guess. As you mentioned, supporting certain versions
> in order to follow other vendors' policies might be one. But, politics
> aside, 

Re: Access to code.gnucash.org

[Adrien Monteleone]

Certainly that is preferred when typing a link, but is the server not set up to 
force TLS? (not just a redirect)

Regards,
Adrien

> On Jan 30, 2018, at 10:40 AM, Derek Atkins  wrote:
> 
> John Ralls  writes:
> 
>> Yes, only core developers have the ssh keys neededto access
>> code.gnucash.org . Since not all of the core
> 
> Just a quick suggestion that this should be https://  and not http://
> 
> -derek
> 
> -- 
>   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
>   warl...@mit.eduPGP key available
> ___
> 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: Future allocated money, aka Envelope Budgeting

[Adrien Monteleone]

> On Jan 31, 2018, at 2:48 PM, Phil Longstaff <phil.longst...@gmail.com> wrote:
> 
> 
> On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone 
> <adrien.montele...@gmail.com <mailto:adrien.montele...@gmail.com>> wrote:
> 
> 
> > On Jan 31, 2018, at 10:09 AM, Christopher Lam <christopher@gmail.com 
> > <mailto:christopher@gmail.com>> wrote:
> >
> > Hi Matt- I thought this should move to the devel list, because of technical 
> > details, and this discussion will be very speculative.
> >
> > I had a thought about how envelope budgeting could work: "divide your 
> > paycheck into separate envelopes for different purposes".
> >
> > A solution: *Create another type of transaction.*
> >
> > There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid 
> > transactions. And (f)rozen I believe is unused. Let's create a new type - 
> > (b)udget. But the balances are handled differently.
> >
> > It would require some UI and calculations changes --
> >
> > 1. The account budget balance is always maintained similarly to 
> > Running/Reconciled/Cleared Balances. But it would count all previous 
> > split-values *and* the (b)udget split amounts. However the budget running 
> > balance is not shown in the default register. This means, existing 
> > balances/register are unchanged.
> 
> Having transactions in an account register that don’t affect the balance is 
> going to be very problematic. I think this would really confuse users.
> 
> I would think budget levels for each expense account could be exposed in the 
> properties/preferences for each one.
> 
> That's basically how it's done now. It uses the kvp (key-value pair) 
> mechanism and each account has a kvp per budget per period with the budget 
> amount.

But I see they aren’t exposed in the Account Edit window. The only way to see 
what was budgeted is to open the budget module, or to see what’s left is to run 
a budget report. And even that part is limited as it’s only a all-or-nothing 
figure for the year, not year-to-date.

Regards,
Adrien
>  
> 
> The allocation of budget money would have to be handled with a special dialog 
> on demand, or as part of an income/asset account preferences with 
> percentages/formulas. (essentially a template transaction that fires when 
> entries are made in that account)
> 
> We already have a budgeting mechanism to set how much we *want* to spend on a 
> particular expense.
> 
> What we’re discussing here is a way to ‘save up’ funds received for each of 
> those expenses.
> 
> If I understand correctly, the budget module uses hidden accounts to keep 
> track of everything. I would think these same accounts, or other hidden 
> accounts paired with them, could do the job.
> 
> This is incorrect. It uses kvp (key-value pair) structures attached to each 
> account.
>  
> Phil

Thanks for clearing that up. Certainly, that seems the more sane route. I would 
think another set of kvp could be implemented to handle the envelope system 
then. One set to hold the amount already allocated and another to hold the 
allocation formula. The original budget pair could be used as the goal.

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

Re: Future allocated money, aka Envelope Budgeting

[Adrien Monteleone]

> On Feb 1, 2018, at 8:22 AM, Christopher Lam <christopher@gmail.com> wrote:
> 
> Hi Adrien,
> 
> From reviewing the code, I still believe the (b)udget transactions system 
> works better. The current code calculates all Reconciled/Cleared/Unreconciled 
> balances on the fly, and it'll be pretty easy to add one for Budget balances. 
> If I'm right, a book with large number of transactions over years will 
> require perhaps 20 (b)udget transactions per year, which will hardly be 
> straining the datafile or the code.
> 
> It is also compatible with the suggestion for "manually triggered SX" or 
> "transaction templates”.

That enhancement was only for an actual transaction that moves money from a 
parent to sub-accounts. I didn’t intend that as a separate layer ‘virtual’ 
transaction. But yes, I see it could work for both.

> 
> The only feature that the envelope system doesn't support is an 'expiry date' 
> for the budget -- some people may prefer monthly/quarterly/annual budgets, 
> and so far I can't think how this would work. The register would really just 
> need color coding to identify 'balance too close to budget' situations.

My understanding is that the envelopes don’t expire, it’s a retained ‘savings’ 
so I get they don’t have a date. That doesn’t preclude budgeting by period 
though. Say you set a spending budget of $100/$300/$1200 for dining out 
(monthly, quarterly, yearly) then you use that as your envelope goal. As you 
allocate, you can see if you have hit your goal. (if so, the allocation stops) 
If you end up spending under budget, that money remains allocated. (unless you 
flow it somewhere else) You’ll just have a head start in your savings plan when 
the next period cycles around. An additional calculation would be needed here. 
At any point in time, you’d need to see the remaining goal to be saved for. 

There should also be a mechanism for letting the user decide how to control the 
allocation or flow of money to the envelopes. This could be a ‘stop’ situation 
based on if either the monthly, quarterly, or yearly goals are reached. Someone 
might want to set a high % to be allocated until perhaps one or two quarters 
are saved up, then back off a bit. Or they might want to leave it high until 
the goal is reached, but keep saving at a lower level. (that part is good for 
emergency funds or debt retirement) Or they might want to only allocate each 
month until the goal is reached (which might be the first pay check) and then 
stop until the month rolls over.

I know this is sounding more complicated, but if the user can’t control their 
savings rate and plan, they probably aren’t going to use the feature much.

By the way, I do like the idea of some sort of color warning with respect to 
hitting budget limits.
> 
> Try opening a register and see View > Filter by... > Status you'll see all 5 
> statuses are ticked. If by default the suggested "b" transactions are 
> disabled then the average user will never see them.

That changes things entirely. I see no UX issues then.
> 
> My suggestion also obviates the need for the shadow accounts as your 
> recommendation.
> 
> IMHO Using a separate kvp system will lead to performance issues similar to 
> current Budget on Windows.
I’ve heard there was some problems there but didn’t realize that was the cause. 
I wonder why that is. Since the user doesn’t have to be exposed to the budget 
transactions by default, I don’t see an issue changing to that method then. 
Whatever is most efficient.

On that note you might need two status levels. A ‘b’ for ‘budget’ to handle the 
current functionality and an ‘e/s’ for ‘envelopes/savings’ to handle savings 
toward those budget goals.
> 
> I'm rather tempted to hack the code to calculate the budgeted amounts by 
> abusing the current (v)oid transactions UI, and it seems very doable :-o

Let me know when you do. I’d be interested in seeing the work and in testing. 
And I’ll be happy to help where I can.

Regards,
Adrien


> 
> Chris
> 
> 
> On 01/02/18 22:05, Adrien Monteleone wrote:
>>> On Jan 31, 2018, at 2:48 PM, Phil Longstaff <phil.longst...@gmail.com> 
>>> wrote:
>>> 
>>> 
>>> On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone 
>>> <adrien.montele...@gmail.com <mailto:adrien.montele...@gmail.com>> wrote:
>>> 
>>> 
>>>> On Jan 31, 2018, at 10:09 AM, Christopher Lam <christopher@gmail.com 
>>>> <mailto:christopher@gmail.com>> wrote:
>>>> 
>>>> Hi Matt- I thought this should move to the devel list, because of 
>>>> technical details, and this discussion will be very speculative.
>>>> 
>>>> I had a thought about how envelope budgeting could work: "d

Re: Future allocated money, aka Envelope Budgeting

[Adrien Monteleone]

n the account register, we'll see regular transactions which 
> can be reconciled with the bank statement. We'll also see budget 
> transactions, not reconcilable with the bank statement. Perhaps they should 
> be a different color/background. But this is ok, because their amounts do not 
> affect the account running balance. The Reconcile window can also filter them 
> out. The existing reports are unaffected. The query mechanism should ignore 
> them by default.
> 
> What do we think of this?
> 
> The budget balance for an asset account represents "money remaining to 
> allocate", and the budget balance for an expense account effectively 
> represents "the upper limit that I'll allow this account to be". The budget 
> balance, minus running balance represents "money left in envelope". I can 
> increase envelope contents by transferring budget money from asset to the 
> expense accounts.
> 
> I wouldn't know how to handle credit card nor loan interest.
> 
> I think it's an interesting thought experiment. The devil will be in the 
> details.
> 
> The advantage will be that the underlying code can handle this augmented 
> functionality without major difficulty (famous last words.)
> 
> Chris

In the short term, if the code for SX could either be borrowed, or amended to 
allow for saving a template of a transaction that is then fired on demand (say 
with a button) instead of on a date stamp, that could help tremendously paired 
with the sub-account method outlined in the user thread. I think template 
transactions are already an enhancement request, so there are other use cases 
for this feature. The most prominent I can think of is payroll.

Regards,
Adrien

> 
> On 31/01/18 15:59, David T. via gnucash-user wrote:
>> Matt,
>> I have to admit that I misread the tally; I did not see that the first $500 
>> (AllocatedCash) was balancing the others. My apologies.
>> I'll let you and Adrien work this out, since I don't have a lot of 
>> background in this.
>> David
>> 
>>   On Wed, Jan 31, 2018 at 8:58, Matt Graham<matt_graham2...@hotmail.com> 
>> wrote:   #yiv0595440679 #yiv0595440679 -- _filtered #yiv0595440679 
>> {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0595440679 
>> {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv0595440679 
>> #yiv0595440679 p.yiv0595440679MsoNormal, #yiv0595440679 
>> li.yiv0595440679MsoNormal, #yiv0595440679 div.yiv0595440679MsoNormal 
>> {margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;}#yiv0595440679 a:link, 
>> #yiv0595440679 span.yiv0595440679MsoHyperlink 
>> {color:blue;text-decoration:underline;}#yiv0595440679 a:visited, 
>> #yiv0595440679 span.yiv0595440679MsoHyperlinkFollowed 
>> {color:#954F72;text-decoration:underline;}#yiv0595440679 
>> .yiv0595440679MsoChpDefault {} _filtered #yiv0595440679 {margin:72.0pt 
>> 72.0pt 72.0pt 72.0pt;}#yiv0595440679 div.yiv0595440679WordSection1 
>> {}#yiv0595440679
>> Hi Dave!
>> 
>> Yep, that is pretty much the conclusion I’ve come to. Not sure what you 
>> are asking about in “where are you balancing the funds”. The Cr and Dr are 
>> balanced in the example. Maybe you are asking the location in the hierarchy 
>> for the accounts? It all goes up to the root account “Assets”. For this 
>> idea, I had Current Assets, Fixed assets, and Allocated Assets. All the 
>> little allocation accounts were stored in the Allocated Assets branch.
>> 
>> They were balanced by a single account under current assets called 
>> “AllocatedCash” (as per the example below). This is the weird one – a 
>> negative asset account that reflects how much I SHOULDN’T spend out of 
>> current assets unless I am spending on my allocated causes.
>> 
>> As per Adrian’s discussions, if you are spending out of the account that 
>> you have put your sub-account into, then there are less splits and it is far 
>> easier to understand. Using Adrien’s idea, at WORST you have a couple of 
>> transactions that are just as complex as every transaction the other way – 
>> but this is only in the rare event that you spend out of a different account 
>> from that which your sub-account is in.
>> 
>> I still haven’t fully wrapped my head around Adrien’s most recent email, 
>> so that could create some more “Aha!” moments too.
>> 
>> Thanks and regards,
>> 
>> Matt
>> 
>> From: David T.
>> Sent: Wednesday, 31 January 2018 2:31 PM
>> To: matt_graham2...@hotmail.com;Adrien Monteleone; gnucash-u...@gnucash.org
>> Subject: RE: Subaccounts [WAS Re: Future allocated money vs Budgets]
>> 
>> Matt,
>>   I se

Re: Scope of GNUCash

[Adrien Monteleone]

Michael,

I agree completely on the separation point, especially with regard to controls.

I’ve seen first hand when sales clerks have the ability to void and edit their 
own transactions from a point of sales system. I can’t imagine the damage that 
WOULD be done if they also had the ability to access the inventory system AND 
the general accounting software. (even just the ability to partially close a 
ticket is dangerous)

As for interoperability, the devil is always in the details but I see three 
main hangups. First, any software should be able to import it’s own exports. 
Second, any software with imports should be able to allow the user an easy way 
to map fields and save that mapping for future use. Third, importing and 
exporting should be possible to schedule or trigger without manual user 
intervention. (so apps can talk to each other reliably without lag)

I think 3.0 is going to partially address the first and second case. I don’t 
think the third is contemplated yet. The third is also dangerous for accounting 
so it should be very carefully implemented and certainly not a default 
condition.

Regards,
Adrien

> On Feb 13, 2018, at 8:10 AM, Mike or Penny Novack 
>  wrote:
> 
> On 2/13/2018 2:55 AM, Wm via gnucash-devel wrote:
> 
>> 
>>> A couple of times I have noticed that people have said "That's not what 
>>> GNUCash is for". It begs the question - where is it defined what GNUCash is 
>>> and isn't for? The charter for GNUCash doesn't seem to ever been formalised.
>> There is a long term plan, we never write it down because people ask us 
>> about it :) Is it intended that people should establish a complementary but 
>> separate project for functionality they want, but is not included in GNUCash 
>> scope?
>> 
>> I don't see why not if that is what they want to do.
> 
> Since I have been one of the people arguing for "separation" (I think this is 
> being misunderstood) I want to clarify the reasons and what I mean when I use 
> the term.
> 
> a) I do NOT mean that needs to be a separate project. Could be part of a 
> PACKAGE (even installed together) but not a single program.
> 
> b) The reason for separate "packages" that interact with each other rather 
> than a single program (that a user is or is not allowed to use) is so that 
> ONE "system" (interacting parts) can be used for all. Those people who are 
> running "one man band" businesses do not see the problem, do not see why 
> things like (proposed extensions) like "inventory", "point of sales", 
> "payroll",  etc. cannot be PART of the "general ledger" program. Call these 
> "one man band" users businesses of class A.
> 
> But there is another sort of business user, call these class B. They have 
> employees, they have division of responsibility and authority. They may have 
> need of safeguards. I am not meaning JUST businesses since even a larger 
> non-profit (call these class C, they might have other needs too) might need 
> safeguards making embezzlement more difficult.
> 
> These need separation. They need to be able to have people "log in and use" 
> things like an inventory system or "point of sales" system WITHOUT being able 
> to access "general ledger. Does not have to be a very large small business 
> before it has people waiting on customers, stocking inventory, etc. These 
> people need to be able to do their jobs without being able to access "general 
> ledger".
> 
> c) A solution with separated subsystems that feed each other would satisfy 
> the needs of these entities (class B and C) while at the same time satisfy 
> the needs of entities of class A. The reverse is not true AND not practical 
> to "first build what would just work for class A and then modify that to work 
> for classes B and C". That would be pretty much a complete rewrite.
> 
> d) However, the IS a common element for all the proposed additions (if 
> separate). They need a way to FEED (send transactions to) general ledger. So 
> general ledger (gnucash as it is) would need a way to accept feeds. And that 
> includes a component to "input edit" feeds (make sure all the transactions 
> coming in are valid, in balance, accounts they refer to exists, etc.) so that 
> "general ledger" can reject (hopefully with meaningful explanations of the 
> problems) a feed.
> 
> e) Not discussing at the present time feeds that might be required between 
> these proposed extensions. For example, we would want a point of sales system 
> to feed an inventory system. But things like that would not be "in common". 
> Likewise not yet discussing safeguards (if a feed was not accepted, how is 
> the system producing this feed temporarily blocked from adding to it. However 
> I will say that to start, these systems should be designed to work 
> "asynchronous batch" and only later consider expanding to supporting "real 
> time update". Again this is a matter of "would work for all" while small 
> entities could not safely make the 

Re: Scope of GNUCash

[Adrien Monteleone]

Not sure what the current POTUS office holder has to do with anything related, 
but, whatever…

I was just in NOLA for a few days, now back home in Lafayette. Happiness is 
measured in beer, or something similar, here. I’ve had several beers today, so 
my happiness meter is reading high at the moment.

I have zero demands on the developer team. I hope they accomplish all they set 
out to. (and quickly!) But I’m thankful they’ve laid out a road map for me to 
decide where (and how) to hop on the train should I manage to chime in with 
something useful. (*note, validated code is useful, ideas? not so much)

For now, I’m going to attempt to tackle some report issues. Sure, I could wait 
till full SQL arrives, but that wouldn’t serve needs NOW. I don’t ‘want’ to 
learn scheme, but I’ll take one for the team if it means being able to offer 
some out of the box ‘features’ people keep asking for.

After that, or in the middle of doing so, I might decide to get my feet wet 
with GC code. I’d ‘like’ to work on things I want to see implemented, but I 
understand certain other tasks have to be taken care of first, most notably, 
the move to full C++ and GTK3. Once that is done, lots of legacy code and ways 
of doing things can or will be quickly discarded which will then clear the way 
for more ‘features’ that users are looking for. So when I do jump into code, my 
focus will always be to try to work on what the project needs, not what I need. 
If I can squash some bugs in the process, all the better.

Happy Mardi Gras,
Adrien

> On Feb 13, 2018, at 6:34 PM, Wm via gnucash-devel  
> wrote:
> 
> On 13/02/2018 21:53, Matt Graham wrote:
>>  I think I would love to sit down in a pub with the three of you (Wm, 
>> Adrien, and Mike). I think we could have such awesome semi-drunken 
>> discussions about the nature of life, the universe and everything!
> 
> I'm in London. Mike is in a Trump voting bit of Merka. Don't know where 
> Adrien is and he shouldn't have to say.
> 
> Accounting is a way of measuring life.  Happiness is harder to quantify.  
> Life should be enjoyable and measuring money shouldn't occupy too much of our 
> time.
> 
> Most crass philosophical sayings are also guaranteed to be crap.
> 
>> I think you have basically answered my question, and I think we all 
>> basically agree on the rough direction things *should* go in (separate 
>> interacting packages).
> 
> I'm the person arguing for stuff to be taken *out* of the basic package so 
> the important stuff can more easily be better interpreted or used, the 
> important stuff being the data that each of us owns or has responsibility for.
> 
> Meanwhile, since I have a good understanding of accounting and databases and 
> related stuff, I just do the bits I need that gnc doesn't cover using plain 
> text accounting.  My point in that regard being that almost all the *thought* 
> problems have been solved in the plain text accounting universe and plain 
> text accounting has also solved some problems you and I didn't even know 
> existed and are way more esoteric than a budget being to your specific needs 
> or a report being formatted one column to the left for the convenience of 
> your tax accountant.
> 
> The problems have been solved, it is the presentation you are struggling with.
> 
> > I’m just not sure how to help make it happen (I’m an enthusiastic amateur 
> > when it comes to programming).
> 
> The gnc code is almost impenetrable in parts.  I'm considerably above average 
> when it comes to programmings skills but there are, when I drill down, bits 
> that simply don't parse.  I know exactly what the code is meant to be doing 
> but someone has written it in such an obscure way I just give up and return 
> to understanding the data.
> 
> It is *this* that the seniors are working on rather than adding a bell or a 
> whistle.
> 
> If the code can't be brought into a form where more than a handful of people 
> can understand it the project is going to die with the seniors as they 
> naturally retire to caring more for their grandchildren than people on the 
> internet thing that demand they do this or that.
> 
> You seem like one of the demanding people to me, Matt
> 
>> I think I’ll start by updating the budget part of the tuts and concept guide 
>> like I have promised elsewhere, and then start looking into how the C++ 
>> modules have been structured (to see what connection will be possible within 
>> the 3.0 releases).
> 
> 
> Ufff, you are welcome to try to understand the budgets but you are warned, 
> you aren't the first to think it makes sense to contribute there.  You are 
> also unlikely to succeed in explaining the way the existing budgets work to 
> anyone's satisfaction, possibly even your own satisfaction.  I am not joking, 
> by the time you have figured out how the existing budgets work you will 
> already be wondering why they were included at all which brings us neatly 
> back to you, Matt, wondering 

Re: RFP: Generic Comparison Report

[Adrien Monteleone]

David,

As I noted in another thread, I'm interested in tackling this. I have a few
other ideas I want to try as well. (multi-step Income Statement and
Analytic/Activity style Income Statement)

Chris, thanks for the link. I'll take a look at Grid also.

While it is good to have a 'flexible and cover many use cases' report, most
people aren't going to be thinking in those terms. Users are more likely
going to want a Balance Sheet and then want it to be multi-column, or an
Income Statement and then see each month or quarter. So there should be
default reports with those names that do this. Ideally, those current
reports should be modified to include the new options rather than creating
separate new reports. (less clutter in the report menus the better)

I'm in the middle of Mardi Gras festivities at the moment, but I'll dive in
on Wednesday.

Regards,
Adrien

On Sat, Feb 10, 2018 at 1:32 AM, David T. via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> Chris,
>
> I think that users would like to know what is happening on this front.
> Users are very interested in these developments, and there are far more
> readers on users, who may have additional suggestions for use-cases and
> features. Given the fact that there are current threads on the user list
> that ask this very question, it seems to me unhelpful to split this off to
> the devel list, where those users will not learn of this.
>
> For what it’s worth, I have yet to see or use the new transaction report,
> since my system hates both me and custom reports. I doubt most normal users
> are aware of the new version of the report and its features, for the same
> reasons.
>
> David
>
> > On Feb 10, 2018, at 11:24 AM, Christopher Lam 
> wrote:
> >
> > Hi D
> >
> > Wish to move to devel, technical and policy details abound.
> >
> > There's already work done to enable periodic subtotals comparison. This
> feature has been named "Subtotal Summary Grid". This is done by reusing and
> augmenting the (most excellent) transaction report's grouping and
> subtotals. I'm not sure whether this allows 100% coverage of users'
> requirements for periodic comparison, but I suspect it would.
> > For example, setting accounts = expense accounts (+ children),
> primary-key = account, secondary-key = date, secondary-subtotals = monthly,
> subtotal-summary-grid = enabled -> will provide a nice 2D grid whereby
> Y-axis = accounts, X-axis = monthly expense subtotals. This feature will
> reuse the subtotals already generated within the transaction report,
> therefore any errors in subtotals are not from my code. Example at
> https://imgur.com/a/unDAD 
> > Unfortunately it was completed after string and feature-freeze for
> upcoming 3.0 -- I'm afraid that inclusion into 3.0 isn't guaranteed yet.
> Although, as I have notified devs, if this feature is renamed "Grid", it
> could be written into 3.0. The translated string "Grid" already exists.
> >
> > If you wish to experiment, the code is currently available at
> https://github.com/Gnucash/gnucash/pull/266/commits/
> 4d2ee75b4fa138c0534ae739089d4df70d6d4117  gnucash/pull/266/commits/4d2ee75b4fa138c0534ae739089d4df70d6d4117> -
> (note, this commit link isn't permanent).
> >
> > C
> >
> > On 10/02/18 13:35, D via gnucash-user wrote:
> >> Hello,
> >>
> >> I want to raise a discussion here about the creation of a generic
> comparison report.
> >>
> >> I would preface this discussion by saying that, although I am a long
> time user of Gnucash, I have repeatedly demonstrated my utter inability to
> generate useful code for the project, so any ultimate action on the results
> of this discussion would have to be applied by someone else.
> >>
> >> As we have seen recently, and as I have seen repeatedly over the years,
> one of the more common requests for reporting is to be able to see numbers
> from different time periods in order to evaluate a financial situation.
> >>
> >> As far as I can tell, other than the multi column report, nothing of
> the sort exists in Gnucash. I started thinking that it might be good to
> begin the process of detailing what features might go into such a report in
> order to make it generally useful, with the idea of perhaps stirring up
> someone's interest in creating such a report.
> >>
> >> Some initial ideas include:
> >>
> >> * Definable periods. Should be able to set the unit period, with
> options for common units (month, quarter, year).
> >> * Definable numbers of periods.
> >> * Definable accounts, but with some common groupings (Assets,
> Liabilities, Investments... Are there others?)
> >> * Perhaps the option to use another report as a template? I have no
> idea how that might work, but the fact that folks seem to want side by side
> balance sheets suggests this to me.
> >>
> >> Does anyone else think this would be helpful? Is it a reasonable idea?
> Is it something that someone in the community with Scheme 

Re: trial balance - how to find mismatch question

[Adrien Monteleone]

At least on my version of the Trial Balance report, there is no ‘Imbalance 
entry’ specifically.

There is at the bottom, the Imbalance-XXX and Orphan-XXX accounts listed along 
with the others.

There is also a line for ‘Unrealized Gains’ or ‘Unrealized Losses’ (I have the 
latter, even though the report duration was a single day with no price changes, 
I gave up trying to figure that one out)

The ‘imbalance’ I’m speaking of trying to resolve, or at least finally 
attributed to a rounding error with the XAG account, was simply the difference 
between what the report shows as Total Debits & Total Credits. (note, these 
aren’t labeled as such on the report - but they appear at the bottom, and 
that’s clearly what they are) There is no figure on the report that shows this 
difference. I had to calculate it manually. When I decided to audit the report 
for each account is when I found the foreign currency account out of whack. The 
remaining difference was attributable entirely to the ‘unrealized losses’ line.

So, the full difference between debits and credits is the SUM of the 
‘Unrealized Gains/Losses’ line and the discrepancy due to rounding.

At least in my case.

So there are two problems with the report:

1) There should be no losses or gains if there were no trading transactions. 
Certainly, this is impossible if there is only one day on the range of the 
report and the price is the same. If all you have are opening entries and you 
attempt to run a trial balance for that same day, you can’t have either a gain 
or a loss, unrealized or not.

2) Because the Equity:Opening Balances account is the result of rounded figures 
for each entry in a foreign currency, the report’s method of taking the foreign 
currency ending balance as of a date and doing the exchange rate calculation at 
the end, will always produce a discrepancy. The report would have to sum the 
book-default currency amounts individually or somehow a book-default currency 
balance would have to be maintained and that used instead. Alternatively, a 
foreign currency account could use the same precision as the foreign currency 
itself, thus removing the potential for rounding errors if not eliminating them.

Possibly, increasing the decimal places and re-entering the transactions for 
the XAG account might resolve the rounding issue. (only because now the USD 
amounts sum correctly to match since they don’t round enough) But then ALL USD 
accounts would have this extra precision which is not desirable generally.

The alternative would be to reduce the precision of the XAG account, but again, 
that is undesirable for accurate tracking of ownership quantities of the actual 
metal. (or currency if that’s the case)

The per-account precision setting seems to only affect the default currency for 
that account, in this case, XAG, not USD, which seems only to be controlled by 
the book setting.


Regards,
Adrien

> On Feb 15, 2018, at 10:55 PM, David T. <sunfis...@yahoo.com> wrote:
> 
> I don’t believe I’ve seen anywhere in this thread any attempt to explain that 
> there is a difference between IMBALANCE-XXX (an indication that you have 
> transactions that lacked a balancing split) and the Imbalance entry in the 
> Trial Balance report. This latter most likely indicates (as David C. has 
> hinted) that your books have capital or currency gains or losses that haven’t 
> been entered into the books. If you buy a stock for $100 using a balanced 
> transaction, and later sell that share for $150 (we wish!) in a balanced 
> transaction, GnuCash will wonder where you got an additional $50. Both 
> transactions balance, but the books don’t. That is why you usually have an 
> entry (either as a separate transaction, or as splits in the sell 
> transaction) that account for this gain.
> 
> Of course, it can get complex. 
> 
> David T.
> 
>> On Feb 16, 2018, at 7:31 AM, Christopher Lam <christopher@gmail.com> 
>> wrote:
>> 
>> Hi Adrien, could you distil this to a minimal test file and submit in a bug
>> report and include relevant report and report parameters? C
>> 
>> On 16 Feb 2018 10:09, "Adrien Monteleone" <adrien.montele...@gmail.com>
>> wrote:
>> 
>>> How timely.
>>> 
>>> Any way to solve this or do I just chalk it up?
>>> 
>>> Regards,
>>> Adrien
>>> 
>>>> On Feb 15, 2018, at 8:00 PM, David Carlson <david.carlson@gmail.com>
>>> wrote:
>>>> 
>>>> If you have multiple currencies  or if you buy and sell commodities or
>>> securities  there is another level of opportunities for issues.
>>>> 
>>>> David  C
>>>> 
>>>> On Feb 15, 2018 5:55 PM, "Adrien Monteleone" <
>>> adrien.montele...@gmail.com> wrote:
>>

[GNC-dev] Old 'Latest Version' on SourceForge

[Adrien Monteleone]

I went to SourceForge and noticed that the big green ‘Download Latest Version’ 
and ‘Download’ buttons are set to 3.1 and not 3.2. At least this is for the 
.dmg. On Windows the file offered is the 3.1 tarball, not the .exe. (I turned 
scripts on just in case auto-detection was the issue, but it still offered the 
tarball instead of the .exe installer. Could this be a ‘private browsing’ or 
‘cookie’ issue?)

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

Re: [GNC-dev] Old 'Latest Version' on SourceForge

[Adrien Monteleone]

Roger that.

Regards,
Adrien

> On Jul 26, 2018, at 5:22 PM, John Ralls  wrote:
> 
> 
> 
>> On Jul 26, 2018, at 12:09 PM, Adrien Monteleone 
>>  wrote:
>> 
>> I went to SourceForge and noticed that the big green ‘Download Latest 
>> Version’ and ‘Download’ buttons are set to 3.1 and not 3.2. At least this is 
>> for the .dmg. On Windows the file offered is the 3.1 tarball, not the .exe. 
>> (I turned scripts on just in case auto-detection was the issue, but it still 
>> offered the tarball instead of the .exe installer. Could this be a ‘private 
>> browsing’ or ‘cookie’ issue?)
>> 
> 
> Adrien,
> 
> No, it's a setting in the SourceForge file manager. It has a (somewhat 
> flakey) automatic setting that it guesses from the file type and always 
> offers the latest file of an appropriate type unless it's overridden in the 
> file properties. We do that because we don't want the BGB to offer betas when 
> we're in a beta cycle. Sometimes the bit seems to revert on its own and 
> sometimes I fail to reset it when I upload a new release (in spite of it 
> being in the checklist).
> 
> I've just changed the settings for all of the 3.2 files.
> 
> Regards,
> John Ralls
> 
> 


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

Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[Adrien Monteleone]

> On Aug 8, 2018, at 10:02 PM, Christopher Lam  
> wrote:
> 
> Hi devs,
> 
> 
> Account Balances are either displayed indented (same as account-depth, with a 
> few exceptions) or single-column. I'd rather not do indenting in CSS because 
> I can't figure out CSS. The CSS style would be “:n columns" or something and 
> I have not idea how this works.

CSS3 does columns, but I don’t see anything yet looking over the Gtk+ CSS docs 
to indicate they’ve implemented it.

My guess would be to set classes on the accounts for the column position and 
set left margin or padding on the classes accordingly. (I think Geert mentioned 
something along these lines in an earlier reply)

Having not taken much of a gander at the report code, I certainly don’t know 
how difficult that would be or if it is even possible.

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

Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[Adrien Monteleone]

> On Aug 9, 2018, at 7:37 AM, Geert Janssens  wrote:
> 
> For reports on the other hand it's not important what Gtk+ implements as the 
> reports are html rendered via webkit (essentially a built-in webbrowser) so 
> the W3C css rules matter here..

Can’t believe I didn’t remember that. This makes the solution much easier. I’m 
generally not a fan of table layouts, but being this is tabular data, it’s 
probably the most semantic approach. In that case, the columns feature of CSS3 
wouldn’t come into play. But they will be useful with respect to 
multi-vs-single column presentation. Setting a 2-column preference would set a 
CSS rule for 2 columns and then set a rule for the second column data to be in 
column ‘2’. Each section of the report would have to be its own table for that 
to work. I don’t think floats are needed. (and would only move the sections 
around based on the width of the report window anyway)

> 
>> My guess would be to set classes on the accounts for the column position and
>> set left margin or padding on the classes accordingly. (I think Geert
>> mentioned something along these lines in an earlier reply)
>> 
> That's indeed what I had in mind, but I haven't tried myself either. So I 
> can't tell how feasible it is anyway. I don't see an issue for accounts as 
> they are left-justified. I don't know for the right-justified amounts though. 
> People with more html/css experience may want to share their views here.
> 


I’ve yet to generate an HTML table via code (certainly not scheme) but I’ll 
take a crack at it with PHP and see what works, then that could be translated. 
I should think padding-right rules could be used on the amounts that are 
right-justified.

All of this now makes me curious to start examining the current HTML being 
generated for reports to see what’s at play.

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

Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[Adrien Monteleone]

> On Aug 7, 2018, at 5:00 PM, Frank H. Ellenberger 
>  wrote:
> 
> 
> 
> No, the grouping should be part of the account template - at least in
> the current state. At some point in the future one could think about
> additional account attributes to improve reporting...
> 

I think this is only a limitation of the current report. If it’s being 
re-written anyway, I’d suggest:

Default sections for the report, each section having it’s own account selection 
option(s). (not one all-encompassing set of accounts for the entire report)

In the long term, default sections could be labeled based on a preference 
setting for the book/entity. But short term, There could be multiple balance 
sheet ‘reports’ each with the appropriate sections for entity types and/or 
jurisdictions. Or, simply have a set number of sections and you get to name 
each one whatever you want and select its own accounts to include.

This way the user can specify which accounts are ‘current vs. fixed’ or ’short 
term vs. long’, which accounts constitute ‘cash’ and so on. (or whatever the 
sections may be)

Of course, it’s just a suggestion. I can’t say how much extra work that would 
be, but that approach might cover many use cases.

> 
> BTW has somebody a better expression here? For "source" I would expect a
> selection from transaction, price database and online quotes.
> 

’Source’ with those options seems pretty reasonable as to what is being asked 
for. (though maybe preface ’transaction’ with ‘previous’ or something similar)

> 
> From
> https://screenshotscdn.firefoxusercontent.com/images/556716da-ba2e-4bed-9bd7-c7232542ab6f.png
> I am confused. I would have expected:
> Liability and Equity (header)
>  Equity (group)
>  Liability (group)
> Liability and Equity (footer)

I agree, they should appear once, combined is fine as that’s pretty standard, 
but they should only appear once.

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

[GNC-dev] Budgets (was Re: Training)

[Adrien Monteleone]

{from gnucash-devel since this is more user stuff than dev related}

David,

After creating a budget, have you not tried the Budget Report?

That can show you actual vs. budgeted by period with variance and include 
yearly totals. The report also now lets you choose what periods you want to 
show detail for or report on at all. (vs. the old 12 periods and that’s it) You 
can choose for example to only show August, or you can show Jan-June as 
consolidated, with July, August, and September broken out, and then Q4 
consolidated. (or any combination of periods you like or not at all) Just play 
with the settings to get a feel for it.

You can use the estimating feature when first setting up a budget to set the 
initial budget figures as averages based on prior transaction history. This is 
a nice starting point to use to populate your budget based on your actual 
spending habits.

The transfer line is for money into and out of assets and liabilities rather 
than income and expenses.

So if you budget to put say $100 in savings and $400 towards a mortgage, those 
will show up in the transfer line. (neither are income or expense)

Note, there is a bug (sorry, no bug number handy) concerning at least income 
totals for the actual column. If your invoice is dated on the first of the 
month, it will likely be counted in the prior month. I think it’s 
time-stamp/time-zone related but I have to investigate more. Other than that, 
it works reasonably well.

Note too, parts of the budget module (not all) do NOT honor the ‘reverse 
balanced accounts’ settings. So some accounts you normally may not be used to 
seeing as negative, will be negative. (I think the budget itself shows credit 
accounts as negative, but the budget report shows them as positive)

I find the budget module and report to be much more useful when used in 
combination with the transaction comparison report. If you’re trying to get a 
handle on a particular spending area discipline wise, the comparison report can 
show you the ‘direction’ you are headed, not just a variance from budgets.

Regards,

Adrien

> On Aug 13, 2018, at 10:52 PM, Christopher Lam  
> wrote:
> 
> It's customary here to keep discussions public. I don't use the budgets
> feature at all and cannot help sorry.
> 
> My preference is to implement envelope budgeting, and the inbuilt budget is
> not envelope budgeting at all.
> 
> On Tue, 14 Aug 2018, 00:08 David Tinoco  wrote:
> 
>> Hi Christopher,
>> 
>> Thanks for getting back to me. Yes, I know the basics. I have been using
>> it for about 2 years now.
>> 
>> I have really wanted to get into the budget feature but I simply cannot
>> figure it out.
>> 
>> I am trying to figure out a way to create a budget and then report on the
>> categories to show how much I have spent on an expense account compared to
>> my budget.
>> 
>> Currently, the only thing I can figure out is making a budget and then
>> separately running an expenses report.
>> 
>> But if there was a way to calculate the expenses automatically for that
>> budget it would be great. Can this be done?
>> 
>> Also, I don't understand the transfer row in the budget window and how
>> that works with accounts.
>> 
>> There are so many great features to this program--wish I could work with a
>> guru and make a bunch of videos for you guys.
>> 
>> Thanks,
>> David
>> 
>> On Mon, Aug 13, 2018 at 2:28 AM Christopher Lam 
>> wrote:
>> 
>>> Hi David
>>> 
>>> There is definitely a gap in this space. The old video
>>> https://youtu.be/aqAaScYVeRQ is still covering the basics. Perhaps you
>>> can focus on more more modern aspects?
>>> 
>>> On Thu, 9 Aug 2018, 22:18 David Tinoco  wrote:
>>> 
 I am very interested in learning the ins and outs of GnuCash.
 
 I am also a professional videographer/animator and web developer.
 
 I was wondering if there is an interest in creating video tutorials for
 the
 various aspects of GnuCash. I think this would be very useful; even if
 the
 basics were covered (accounts setup, transaction entry, budget feature,
 reports, etc.)
 
 I would be willing to undertake the videos if I could have another person
 on the team that got me through the ropes on this.
 
 Is there a need for/interest in this?
 ___
 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] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[Adrien Monteleone]

Chris,

Here are my impressions and questions, perhaps I’m not understanding what you 
were trying to show with the screenshot. (does this contain illustrations of 
multiple presentation possibilities all-in-one or is this intended as how the 
report will look by default?)

The asset summary at the top seems confusing and isn’t labeled. If I don’t know 
who or what this entity is or how their books are arranged, how do I know what 
these figures represent?

Each section seems to be missing the standard headings. (Current/Non, 
Short/Long Term, Fixed/Intangible etc.) I know other discussions have touched 
on the duplication in some reports in the menus, but maybe this is how it’s 
addressed - have a basic report that has multiple entries based on the report 
type desired for a particular entity. (or determined by book/app preferences, 
say report defaults for a particular jurisdiction) So there might be a Personal 
Balance Sheet, Small Business Balance Sheet, Public Entity / Non-Profit 
Statement of Financial Position, etc. Each would have the appropriate major 
sections in the report with the standard headings expected for each. The 
account structure *might* mimic this but it shouldn’t have to. The report 
options should ask the user to select the accounts to include for each section. 
(rather than just one account list for the entire report) So you would select 
the accounts to include in Current Assets, the accounts to include in Fixed 
Assets, the accounts to include in Short Term Liabilities, etc. Perhaps this 
can be somewhat determined or guessed by default, but that might be lots of 
work. The same would be needed for Income/P

I find totals/subtotals above the child amounts to be odd. Perhaps less 
emphasis on the parent label, with maybe a colon indicator (like on the 
wikipedia entry) would be cleaner with a bold subtotal/total line will make the 
important numbers stand out more. (that is, not showing the amount on the 
initial label line at all)

Also, usually single lines are to delineate figures from subtotals and double 
lines to indicate totals from subtotals. (again like the wikipedia sample)

I don’t think the figures need to be indented as well, just marked off with 
single/double lines and appropriate line-spacing. For account indentions, does 
the report indent contra-accounts? Most statements I’ve seen that have them do 
so.

I understand and like that I have the option for levels deeper than 1 or 2, but 
usually such official statements are intended as an overview, not for detailed 
analysis. They should be very easy to read and decipher without extraneous info 
or styling. And ideally, you should accomplish this with plain-text monospaced. 
Perhaps work it back to that point and then embellish if needed.

A few minor points:
---

Is there is a reason why the child totals are also links? It lends a sense of 
clutter.

I noticed in the Equities & Liabilities section that some figures have no 
currency symbol. While I might be able to figure out what they are by studying 
the document, that info should be more readily discern-able at a glance. I’m 
puzzled by that section though. Usually it’s one or the other (separated or 
consolidated) but not both. Also, the total for Assets and the total for 
Liabilities & Equity should be on the same horizontal line when in 2-column 
mode.

I see too that some child amounts show in two currencies but not others. (looks 
like just the GBP accounts) Is this intended or just an illustration (or an 
omission)?

Regards,
Adrien

> On Jul 27, 2018, at 8:01 AM, Christopher Lam  
> wrote:
> 
> Latest iteration of balsheet
> 
> * restored amount-indenting. IMHO this is now producing sane indenting
>   for any subtotal strategy
> * restore dual columns (i.e. left=asset/income, right=liability/expense)
> * the above two only enabled when multicols are disabled
> * option to toggle amount/account indenting
> * incorporated bug 623381 recommendations for sections labels/totals
> * added sections for equity, liability+equity
> * modify 'original-currency' display to match eguile report i.e.
>   smaller font, precedes converted currency
> 
> I would really like feedback on
> 
> * accuracy of amounts
> * accuracy of sections
> o further tweaking of option names/sections/ordering
> 
> Screenshot:
> https://screenshots.firefox.com/nhaiX1ehSA2GXA97/null
> 
> On 25/07/18 15:53, Frank H. Ellenberger wrote:
>> Am 19.07.2018 um 13:09 schrieb Christopher Lam:
>>> Hi Frank
>>> Thank you - I can restore the dual-columns when the periods have been
>>> disabled.
>>> I'd prefer to limit the number of options; so, if the "period duration" is
>>> disabled, the report will automatically show dual columns
>> while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous
>> years in the Income statement.
>> https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge
>> 
>>> (Asset/Income=left, Liability+Equity/Expense = right). 

Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[Adrien Monteleone]

Frank,

I’ve been following this for a while, and perhaps I’m not understanding, but 
are the groupings just presentational?

If that’s the case, I would think the place to address this is in the report 
options, not the account structure. (you could use any structure you need, and 
easily re-group based on the rule you decide or need to follow.)

Regards,
Adrien

> On Jul 25, 2018, at 2:53 AM, Frank H. Ellenberger 
>  wrote:
> 
> Am 19.07.2018 um 13:09 schrieb Christopher Lam:
>> Hi Frank
>> Thank you - I can restore the dual-columns when the periods have been
>> disabled.
>> I'd prefer to limit the number of options; so, if the "period duration" is
>> disabled, the report will automatically show dual columns
> 
> while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous
> years in the Income statement.
> https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge
> 
>> (Asset/Income=left, Liability+Equity/Expense = right). This works?
> 
>> Can you please show me good examples of idealised T-account balance
>> sheet/income statement? Or the scaled form? I have no idea.
> 
> To get an impression you could starting from:
> 
> https://en.wikipedia.org/wiki/Balance_sheet - which has
> #US_small_business in account form and #Sample in scaled form -
> or
> 
> https://en.wikipedia.org/wiki/Income_statement and an example in account
> form: https://debitoor.de/lexikon/gewinn-und-verlustrechnung-guv
> 
> Note: There are several different methods for grouping the positions
> with differrent pros and cons allowed for different company types:
> Gesamtkostenverfahren, Umsatzkostenverfahren & IFRS. Currently I have no
> better idea for the grouping than adjusting the account structure.
> 
> Optionally select other languages e.g.
> https://de.wikipedia.org/wiki/Bilanz#Aufbau_der_Bilanz
> 
> HTH
> 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] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[Adrien Monteleone]

Are not Retained Earnings part of Equity? And then, that account would only be 
used in a close books process, not without it. Closing the books should zero 
the income and expense accounts TO Retained Earnings.

Regards,
Adrien

> On Aug 13, 2018, at 12:04 AM, Christopher Lam  
> wrote:
> 
> Hi Jralls
> 
> So just wish to double check my understanding of gnucash's data format for a 
> balance-sheet on date X
> 
> There are two possibilities for displaying the right-hand-side
> 
> 1. Liabilities + Equity + Retained Earnings + Trading Balances
> 2. Liabilities + Equity + Retained Earnings + Unrealized Gains
> 
> "Retained Earnings" should be NULL if the user has properly closed the books 
> on the balance sheet date X.
> 
> In my understanding, "Trading Balances" and "Unrealized Gains" are one and 
> the same -- in balance-sheet.scm the unrealized-gain-collector is only 
> populated if book->trading-accounts setting is disabled. (btw this causes a 
> 'bug' whereby a book with 'enable-trading-accounts', but was later switched 
> to 'disable-trading-accounts' will then add both the 
> unrealized-gain-collector and the trading-balance the right-hand-side).
> 
> This seems to be deconstruct current balance-sheet?
> 
> (I can't seem to find any unrealized-gain issue... from using different 
> price-sources... perhaps this is beyond my understanding.)
> 
> 
> On 11/08/18 22:41, John Ralls wrote:
>> Chris,
>> 
>> Remember that we’ve long advised users that they need not close their books, 
>> they can run a balance sheet report for any day. IMO removing that 
>> capability would be a major breakage.
>> 
>> I suspect that you needed to use trading accounts because you didn’t book 
>> the trading gains and losses as income. Users should do that regardless of 
>> using trading accounts and doing so should make it unnecessary for the 
>> balance sheet report to include trading accounts.
>> 
>> Unrealized gains are another matter entirely and are a result of using 
>> prices from the price database instead of actual cost from the transaction 
>> data. IMO the balance sheet report shouldn’t be taking prices from the price 
>> db and shouldn’t be able to see unrealized gains, but if price source is 
>> going to be an option then an unrealized gains line flows from that so that 
>> users don’t waste a bunch of time chasing an imbalance caused by price 
>> differences.
>> 
>> https://bugs.gnucash.org/show_bug.cgi?id=775368 is related because that’s 
>> currently how the balance sheet report gets the “actual” costs.
>> 
>> Regards,
>> John Ralls
>> 
>>> On Aug 10, 2018, at 11:40 PM, Christopher Lam >> > wrote:
>>> 
>>> Hi John
>>> 
>>> I've managed to make the left-side (activa?) match the right-side (passiva?)
>>> 
>>> https://screenshots.firefox.com/RNvkjaxnYyxpGkYn/null
>>> 
>>> 1) it does require closing books on the balance-sheet date
>>> 
>>> 2) it does require adding trading-accounts
>>> 
>>> The existing balsheet introduces/calculates the "Retained Earnings", 
>>> "Trading Gains" and "Unrealized Gains", whereas the current iteration of 
>>> new-balsheet will not.
>>> 
>>> To me this is the easiest method to ensure both sides produce the same 
>>> total, and is now technically correct - if the user has not closed their 
>>> books, the balance sheet won't balance.
>>> 
>>> This is giving me a headache :(
>>> 
>>> Should a new balsheet calculate and report these '(fake) retained 
>>> earnings', and 'unrealized gains' ???
>>> 
>>> C
>>> 
>>> 
>>> On 09/08/18 08:32, John Ralls wrote:
 
> On Aug 8, 2018, at 8:51 AM, Geert Janssens  
> wrote:
> 
> I haven't been following every detail of this. However I note on most 
> balance
> sheets the total assets doesn't match total net worth (or 
> liabilities/equity).
> In most, this is fixed by including the retained earnings.
> 
> I believe at least in most European countries the "left hand side" 
> (Assets,
> Active) and "right hand side" (Passive or liabilities + equity) of the
> multicolumn view should balance (it's called balance sheet for a reason).
> That would suggest retained earnings does have to be part of the balance
> sheet.
> 
> However I'm not an accountant and perhaps your book is slightly contrived 
> so I
> don't know the exact answer here.
> 
> As for the "multi-column" vs one column debate, both present the same 
> data.
> The only difference is visual representation or style.
> 
> As of recently I have become a strong proponent of separating structure 
> (or
> accounting functionality in a different context) from style, I think this
> should be delegated to the realm of css. This particular layout variation 
> can
> IMO be handled by making divs for each large group and either let them 
> follow
> normal flow or use float to move them next to each other. If you will you 
> can
> have a 

Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[Adrien Monteleone]

John,

Mailman was hungry. It ate your screenshots.

Regards,
Adrien

> 
> 
> Chris,
> 
> To demonstrate the price difference on assets creating an “Unrealized Gain” 
> line, I created a fake account with Trading Accounts off and purchased on 1 
> January 100 shares of a stock for $100, then created a new price for the 
> stock of $200. The resulting Balance Sheet report is the first screenshot 
> below. Price source is set to “nearest in time”.
> 
> I repeated the process in a new book with trading accounts enabled and got 
> the second screenshot. As you pointed out, the “Unrealized Gains” line 
> changes to “Trading Gains”. Selling the stock made no difference on the 
> report unless I also booked the 10,000 gain to Income:Short Term Cap Gains, 
> after which the calculated line became “Retained Earnings” as illustrated by 
> the third screen shot.
> 
> I went back and did the sale on the non-trading-accounts book and found that 
> indeed “Unrealized Gains” didn’t change after I sold the stock; that’s wrong, 
> it’s a realized gain at that point. Booking the gain to Income changed the 
> line to “Retained Earnings” as it did with trading accounts enabled and as 
> expected.
> 
> Finally, to illustrate the effect of price source I removed the sell 
> transaction and changed the price source in report options to “Avg Cost”. The 
> result is the last screenshot, showing the stock at book value and the 
> “Unrealized Gains” line at 0.
> 
> 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: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[Adrien Monteleone]

Sorry John,

I forgot that GnuCash used the same term for the calculated amount.

Yet another case where my fingers need to slow down and let my brain ponder 
things.

Regards,
Adrien

> On Aug 13, 2018, at 9:08 AM, John Ralls  wrote:
> 
> Adrien,
> 
> Yes, that’s formally correct. As I’ve said repeatedly in this thread, GnuCash 
> has long had a design feature that one can get a balanced Balance Sheet 
> report without closing one’s book. The Balance Sheet report does that by 
> summing up the expense and income accounts’ balances and reporting the total 
> in a “Retained Earnings” line. If one has closed one’s book in the past and 
> so has a “Retained Earnings” account, the Balance Sheet report will have two 
> lines called “Retained Earnings”.
> 
> Regards,
> John Ralls
> 
> 
>> On Aug 12, 2018, at 10:26 PM, Adrien Monteleone 
>>  wrote:
>> 
>> Are not Retained Earnings part of Equity? And then, that account would only 
>> be used in a close books process, not without it. Closing the books should 
>> zero the income and expense accounts TO Retained Earnings.
>> 
>> Regards,
>> Adrien
>> 
>>> On Aug 13, 2018, at 12:04 AM, Christopher Lam  
>>> wrote:
>>> 
>>> Hi Jralls
>>> 
>>> So just wish to double check my understanding of gnucash's data format for 
>>> a balance-sheet on date X
>>> 
>>> There are two possibilities for displaying the right-hand-side
>>> 
>>> 1. Liabilities + Equity + Retained Earnings + Trading Balances
>>> 2. Liabilities + Equity + Retained Earnings + Unrealized Gains
>>> 
>>> "Retained Earnings" should be NULL if the user has properly closed the 
>>> books on the balance sheet date X.
>>> 
>>> In my understanding, "Trading Balances" and "Unrealized Gains" are one and 
>>> the same -- in balance-sheet.scm the unrealized-gain-collector is only 
>>> populated if book->trading-accounts setting is disabled. (btw this causes a 
>>> 'bug' whereby a book with 'enable-trading-accounts', but was later switched 
>>> to 'disable-trading-accounts' will then add both the 
>>> unrealized-gain-collector and the trading-balance the right-hand-side).
>>> 
>>> This seems to be deconstruct current balance-sheet?
>>> 
>>> (I can't seem to find any unrealized-gain issue... from using different 
>>> price-sources... perhaps this is beyond my understanding.)
>>> 
>>> 
>>> On 11/08/18 22:41, John Ralls wrote:
>>>> Chris,
>>>> 
>>>> Remember that we’ve long advised users that they need not close their 
>>>> books, they can run a balance sheet report for any day. IMO removing that 
>>>> capability would be a major breakage.
>>>> 
>>>> I suspect that you needed to use trading accounts because you didn’t book 
>>>> the trading gains and losses as income. Users should do that regardless of 
>>>> using trading accounts and doing so should make it unnecessary for the 
>>>> balance sheet report to include trading accounts.
>>>> 
>>>> Unrealized gains are another matter entirely and are a result of using 
>>>> prices from the price database instead of actual cost from the transaction 
>>>> data. IMO the balance sheet report shouldn’t be taking prices from the 
>>>> price db and shouldn’t be able to see unrealized gains, but if price 
>>>> source is going to be an option then an unrealized gains line flows from 
>>>> that so that users don’t waste a bunch of time chasing an imbalance caused 
>>>> by price differences.
>>>> 
>>>> https://bugs.gnucash.org/show_bug.cgi?id=775368 is related because that’s 
>>>> currently how the balance sheet report gets the “actual” costs.
>>>> 
>>>> Regards,
>>>> John Ralls
>>>> 
>>>>> On Aug 10, 2018, at 11:40 PM, Christopher Lam >>>> <mailto:christopher@gmail.com>> wrote:
>>>>> 
>>>>> Hi John
>>>>> 
>>>>> I've managed to make the left-side (activa?) match the right-side 
>>>>> (passiva?)
>>>>> 
>>>>> https://screenshots.firefox.com/RNvkjaxnYyxpGkYn/null
>>>>> 
>>>>> 1) it does require closing books on the balance-sheet date
>>>>> 
>>>>> 2) it does require adding trading-accounts
>>>>> 
>>>>> The existing balsheet introduces/calculates the "Reta

Re: [GNC-dev] Import PDF to GnuCash

[Adrien Monteleone]

A company I work with just started using QB Pro 2018, so I’ll check on this 
feature, but a web search turned up this forum topic: 
https://quickbooks.intuit.com/community/Do-more-with-QuickBooks/Pdf-Conversion-to-QBO/td-p/145466

which seems to indicate that it’s nothing new. You need 3rd party software to 
convert an *electronically generated* pdf to QBO format which QuickBooks can 
then upload. Scans of paper are not recommended due to the OCR issues, so OCR 
isn’t their method. They seem to be ’scanning’ the text of the file, but they 
specify ALL of the text has to be selectable and they recommend only PDF 
statements generated by the bank. So most likely, these are programmatically 
generated plain text files that have styling and formatting applied and shipped 
in a PDF container. The rather expensive software, reverses the process back to 
plain text and then interprets what the transactions are. I guess it’s possible 
the banks are doing EDI and simply offering customers a ‘pretty printable 
version’ in PDF format but with the EDI fields embedded so the file could still 
be used with EDI and this special software is just taking advantage of that to 
generate an importable format.

Other solutions mentioned for various incarnations of Intuit software is to 
skip the QBO step and go to CSV, which puts us in GnuCash territory. But I’d 
bet dimes to dollars, you don’t need $100+ software to accomplish that task if 
OCR isn’t part of the workflow.

Regards,
Adrien

> On Aug 6, 2018, at 4:47 AM, c.holterm...@gmx.de wrote:
> 
> Am 2018-07-26 21:56, schrieb deltatango:
>> Hello,
>> Very interested in the possibility of importing PDF statements into GnuCash.
>> I know Quickbooks now has this functionality.
>> I searched online and found a few clunky possibilities that would convert
>> the data into excel which can then be converted to csv and then imported
>> into GnuCash.
>> I was envisioning a system where you select a PDF statement to be imported.
>> The program then asks you to select the area of the statement which contains
>> the transactions, much like a photoshop selection. (And perhaps you could
>> save templates of selections for different statements).
>> Then some kind of OCR scanning reads the columns and data and convert it to
>> columns/rows.
>> Is this in the realm of possibility for some future release?
>> It is so common now that exporting csv or qfx ,etc files from your bank only
>> go so far back and you have to download PDFs instead...
>> I dream, I hope...
>> But in vain I wish not...
>> --
>> 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
> 
> Hello !
> 
> I haven't heard of PDF statements before. Is it some sort of embedded data ?
> Quick googling led me to https://pdftables.com/blog/convert-bank-statement.
> It seems to be some sort of standard embedding mechanism. Am I right here ?
> 
> Anyway the way would be to extract the data from the PDF. That would either be
> through this statement data or through OCR. The data could be converted to CSV
> and be imported to gnucash.
> 
> The missing link seems to be extraction of data from PDFs.
> 
> Is there a FOSS tool to extract statement data and convert it to CSV ?
> Or when we go OCR. Is there a tool capable of extracting tables ?
> 
> With OCR you usually only get a text file. It does not recognize that it is
> structured table data. At least with the software I used some years ago that
> had been the case.
> 
> The OCR way would be interesting if there are possible right issues as John
> has pointed out about statement data or reverse engineering.
> 
> regards,
> 
> Christoph
> ___
> 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

[GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[Adrien Monteleone]

David,

The confusion as to which document you were in I think is that the link text 
says ‘gnucash-guide’. There are also several references scattered on the 
website/wiki that refer to the ‘Help Guide’ though it appears the Documentation 
page calls it the ‘Help Manual’. That folder name I should think is a bug.

How did you get to that /docs/v3 link? I can’t find any path to it from the 
website. The links I find are all /viewdoc links which don’t tell me where I 
am. (at least not in the URL, just as you discovered - which brings up another 
navigation bug, the pages have no indication of what document you are viewing)

Also, I’ve changed the subject for you, and moved it to gnucash-devel. (I 
thought about doing the same on the last reply, I suppose the thread is 
officially hijacked now)

In Gmail, in the reply box, there is a down arrow next to the reply 
left-pointing arrow. (just to the left of the recipient(s)) Click it for a 
context menu and use “Edit Subject”

Regards,
Adrien



> On Aug 20, 2018, at 12:04 PM, David Carlson  
> wrote:
> 
> Adrien,
> 
> Thank you for your research and detailed response. 
> I fully agree with your conclusions.
> 
> 
> I got the reference to section 4.2 directly from 
> https://www.gnucash.org/docs/v3/C/gnucash-guide/txns-register-oview.html#txns-regstyle1
>  which I arrived at when I followed the link called " Tutorial and Concepts 
> Guide, Choosing a Register Style). " in 
> https://www.gnucash.org/viewdoc.phtml?doc=help.  Naturally, I thought I was 
> in the Tutorial...
> 
> David C
> 
> On Mon, Aug 20, 2018 at 11:45 AM, Adrien Monteleone 
>  wrote:
> I’ve never seen any documentation on it. I only confirmed it’s there after I 
> read Derek’s comment and expanded the column myself to see it.
> 
> I just did a search of the GnuCash site, wiki and html docs and I don’t see 
> anything on the column, other than a pair of IRC logs from 2009 where someone 
> asked what it was for, and a couple of hits (appears duplicated) documenting 
> commits from 2017-09-4. I didn’t read the commit itself, but it was 
> summarized by Robert Fewell as “Add a heading for the Rate column.”
> 
> Concerning where to put the info, I’m not sure the Tutorial is the right 
> place. (there is no 4.2, for example)
> 
> However, the help guide has 4.3.5 List of Transactions which documents the 
> column headings. I think if that section were more detailed with screenshots, 
> lots of questions could be answered or even avoided.
> 
> Some things to add here:
> 
> The ability to resize columns and an explanation of how the Description 
> column is special and how resizing works.
> 
> An explanation with screenshots of the different types of registers showing 
> the respective columns. (unless they are all the same, save terminology 
> choices, then you’d only need one screenshot)
> 
> An explanation of the formal vs. non-formal labels for each account type. (a 
> full listing of what the non-formal labels are for each type)
> 
> Screenshots depicting each of the modes: single-line, double-line, 
> transaction journal.
> 
> An explanation of what each cell in the transaction is for. (many don’t know 
> the utilit(ies) of NUM or Action for example.) Not everything is 
> self-evident. Perhaps here include a link to a special wiki page or to Using 
> GnuCash where the different ’tricks’ for using those and other fields to 
> accomplish user specific goals are (or should be) documented.
> 
> I would be happy to get set up for editing and start on this unless you 
> already planned on running with it.
> 
> Finally, “Tutorial & Concepts Guide” is a bit winded. Could it simply be 
> “Tutorial” or “Using GnuCash”? (and then incorporate any ‘official’ methods 
> from that wiki page into the document, with a link to that page for the 
> non-standard methods)
> 
> Regards,
> Adrien
> 
> > On Aug 20, 2018, at 10:57 AM, David Carlson  
> > wrote:
> > 
> > I just tried to find reference to the rate field in the Tutorial and I 
> > found nothing.
> > 
> > I think it should probably be mentioned in chapter 4 section 4.2.  That 
> > section even fails to explain single line vs two line view or dragging 
> > around field widths, so it has a long way to go before it could describe 
> > the presence of the rate field and how to access it.
> > 
> > Is this information posted elsewhere? 
> > 
> > David C 
> > 
> > On Mon, Aug 20, 2018, 9:44 AM Adrien Monteleone 
> >  wrote:
> > It’s still there as of 3.2.
> > 
> > Regards,
> > Adrien
> > 
> > > On Aug 20, 2018, at 9:17 AM, Derek Atkins  wrote:
> > > 
> > > John Ralls  writes:
> > >

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[Adrien Monteleone]

I just filed: https://bugs.gnucash.org/show_bug.cgi?id=796823

On the title issue as that’s a basic website usability bug.

I’ll wait for someone else to chime in on the case of the gnucash-guide folder.

Regards,
Adrien

> On Aug 20, 2018, at 1:06 PM, Adrien Monteleone 
>  wrote:
> 
> David,
> 
> The confusion as to which document you were in I think is that the link text 
> says ‘gnucash-guide’. There are also several references scattered on the 
> website/wiki that refer to the ‘Help Guide’ though it appears the 
> Documentation page calls it the ‘Help Manual’. That folder name I should 
> think is a bug.
> 
> How did you get to that /docs/v3 link? I can’t find any path to it from the 
> website. The links I find are all /viewdoc links which don’t tell me where I 
> am. (at least not in the URL, just as you discovered - which brings up 
> another navigation bug, the pages have no indication of what document you are 
> viewing)
> 
> Also, I’ve changed the subject for you, and moved it to gnucash-devel. (I 
> thought about doing the same on the last reply, I suppose the thread is 
> officially hijacked now)
> 
> In Gmail, in the reply box, there is a down arrow next to the reply 
> left-pointing arrow. (just to the left of the recipient(s)) Click it for a 
> context menu and use “Edit Subject”
> 
> Regards,
> Adrien
> 
> 
> 
>> On Aug 20, 2018, at 12:04 PM, David Carlson  
>> wrote:
>> 
>> Adrien,
>> 
>> Thank you for your research and detailed response. 
>> I fully agree with your conclusions.
>> 
>> 
>> I got the reference to section 4.2 directly from 
>> https://www.gnucash.org/docs/v3/C/gnucash-guide/txns-register-oview.html#txns-regstyle1
>>  which I arrived at when I followed the link called " Tutorial and Concepts 
>> Guide, Choosing a Register Style). " in 
>> https://www.gnucash.org/viewdoc.phtml?doc=help.  Naturally, I thought I was 
>> in the Tutorial...
>> 
>> David C
>> 
>> On Mon, Aug 20, 2018 at 11:45 AM, Adrien Monteleone 
>>  wrote:
>> I’ve never seen any documentation on it. I only confirmed it’s there after I 
>> read Derek’s comment and expanded the column myself to see it.
>> 
>> I just did a search of the GnuCash site, wiki and html docs and I don’t see 
>> anything on the column, other than a pair of IRC logs from 2009 where 
>> someone asked what it was for, and a couple of hits (appears duplicated) 
>> documenting commits from 2017-09-4. I didn’t read the commit itself, but it 
>> was summarized by Robert Fewell as “Add a heading for the Rate column.”
>> 
>> Concerning where to put the info, I’m not sure the Tutorial is the right 
>> place. (there is no 4.2, for example)
>> 
>> However, the help guide has 4.3.5 List of Transactions which documents the 
>> column headings. I think if that section were more detailed with 
>> screenshots, lots of questions could be answered or even avoided.
>> 
>> Some things to add here:
>> 
>> The ability to resize columns and an explanation of how the Description 
>> column is special and how resizing works.
>> 
>> An explanation with screenshots of the different types of registers showing 
>> the respective columns. (unless they are all the same, save terminology 
>> choices, then you’d only need one screenshot)
>> 
>> An explanation of the formal vs. non-formal labels for each account type. (a 
>> full listing of what the non-formal labels are for each type)
>> 
>> Screenshots depicting each of the modes: single-line, double-line, 
>> transaction journal.
>> 
>> An explanation of what each cell in the transaction is for. (many don’t know 
>> the utilit(ies) of NUM or Action for example.) Not everything is 
>> self-evident. Perhaps here include a link to a special wiki page or to Using 
>> GnuCash where the different ’tricks’ for using those and other fields to 
>> accomplish user specific goals are (or should be) documented.
>> 
>> I would be happy to get set up for editing and start on this unless you 
>> already planned on running with it.
>> 
>> Finally, “Tutorial & Concepts Guide” is a bit winded. Could it simply be 
>> “Tutorial” or “Using GnuCash”? (and then incorporate any ‘official’ methods 
>> from that wiki page into the document, with a link to that page for the 
>> non-standard methods)
>> 
>> Regards,
>> Adrien
>> 
>>> On Aug 20, 2018, at 10:57 AM, David Carlson  
>>> wrote:
>>> 
>>> I just tried to find reference to the rate field in the Tutorial and I 
>>> found nothing.
>>

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[Adrien Monteleone]

Strange, I followed that path and I still only get /viewdoc links. I can’t seem 
to hit the /docs/v3 section of the site. (notice your link is also to the 
/viewdoc URL, not /docs/v3)

Anyway, as for Gmail, it’s there, you have to click in the reply box to start 
your reply for it to appear. (I tested that on both the older and the newer 
version of Gmail before my last reply) You can also use the drop down in the 
upper right of the message with the same arrow which will move your keyboard 
focus to the reply box. (same as clicking in it directly)

Regards,
Adrien

> On Aug 20, 2018, at 1:54 PM, David Carlson  
> wrote:
> 
> OK.
> 
> For my complete itinerary, I started at the GnuCash home page 
> https://www.gnucash.org/.
> Clicked on Downloads > Documentation in the left column 
> https://www.gnucash.org/docs.phtml
> from there I scrolled down the right to
> GnuCash v3 (current stable release)
> 
> then I selected Download Stable Help Manual English Browse Documentation 
> Online "
>   https://www.gnucash.org/viewdoc.phtml?rev=3=C=help
> 
> There is where I found the incorrectly titled and badly worded link.
> 
> Also, I am still using the aout to be replaced Gmail version on the internet, 
> and I do nt see what you described by the reply arrow, although my memory 
> tells me that it used to be there.
> 
> David C
> 
> 
> On Mon, Aug 20, 2018 at 1:06 PM, Adrien Monteleone 
>  wrote:
> David,
> 
> The confusion as to which document you were in I think is that the link text 
> says ‘gnucash-guide’. There are also several references scattered on the 
> website/wiki that refer to the ‘Help Guide’ though it appears the 
> Documentation page calls it the ‘Help Manual’. That folder name I should 
> think is a bug.
> 
> How did you get to that /docs/v3 link? I can’t find any path to it from the 
> website. The links I find are all /viewdoc links which don’t tell me where I 
> am. (at least not in the URL, just as you discovered - which brings up 
> another navigation bug, the pages have no indication of what document you are 
> viewing)
> 
> Also, I’ve changed the subject for you, and moved it to gnucash-devel. (I 
> thought about doing the same on the last reply, I suppose the thread is 
> officially hijacked now)
> 
> In Gmail, in the reply box, there is a down arrow next to the reply 
> left-pointing arrow. (just to the left of the recipient(s)) Click it for a 
> context menu and use “Edit Subject”
> 
> Regards,
> Adrien
> 
> 
> 
> > On Aug 20, 2018, at 12:04 PM, David Carlson  
> > wrote:
> > 
> > Adrien,
> > 
> > Thank you for your research and detailed response. 
> > I fully agree with your conclusions.
> > 
> > 
> > I got the reference to section 4.2 directly from 
> > https://www.gnucash.org/docs/v3/C/gnucash-guide/txns-register-oview.html#txns-regstyle1
> >  which I arrived at when I followed the link called " Tutorial and Concepts 
> > Guide, Choosing a Register Style). " in 
> > https://www.gnucash.org/viewdoc.phtml?doc=help.  Naturally, I thought I was 
> > in the Tutorial...
> > 
> > David C
> > 
> > On Mon, Aug 20, 2018 at 11:45 AM, Adrien Monteleone 
> >  wrote:
> > I’ve never seen any documentation on it. I only confirmed it’s there after 
> > I read Derek’s comment and expanded the column myself to see it.
> > 
> > I just did a search of the GnuCash site, wiki and html docs and I don’t see 
> > anything on the column, other than a pair of IRC logs from 2009 where 
> > someone asked what it was for, and a couple of hits (appears duplicated) 
> > documenting commits from 2017-09-4. I didn’t read the commit itself, but it 
> > was summarized by Robert Fewell as “Add a heading for the Rate column.”
> > 
> > Concerning where to put the info, I’m not sure the Tutorial is the right 
> > place. (there is no 4.2, for example)
> > 
> > However, the help guide has 4.3.5 List of Transactions which documents the 
> > column headings. I think if that section were more detailed with 
> > screenshots, lots of questions could be answered or even avoided.
> > 
> > Some things to add here:
> > 
> > The ability to resize columns and an explanation of how the Description 
> > column is special and how resizing works.
> > 
> > An explanation with screenshots of the different types of registers showing 
> > the respective columns. (unless they are all the same, save terminology 
> > choices, then you’d only need one screenshot)
> > 
> > An explanation of the formal vs. non-formal labels for each account type. 
> > (a full listing of what the non-formal la

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[Adrien Monteleone]

David C,

So for clarification this is the first link you posted about:

> https://www.gnucash.org/docs/v3/C/gnucash-guide/txns-register-oview.html#txns-regstyle1

Notice this is in the folder /docs/v3/C/gnucash-guide/

But the link on the Documentation page and the link you included (both in that 
first post and in the last one) that said how you got there was this:

> https://www.gnucash.org/viewdoc.phtml?rev=3=C=help

So yes, that IS version 3 (listed here as ‘rev=3’) but that’s not the same link 
as above. (though it might be the exact same content, I didn’t check)

I can’t find any way, other than typing it in directly, to get to the 
/docs/v3/C/ directory wherein lies the /gnucash-guide/ and /gnucash-help/ 
folders and contents. All of the links on the documentation page seem to point 
instead to the /viewdoc.phtml which never changes the URL as you navigate the 
document. (my guess is the viewdoc.phtml template is serving the pages 
physically located in /docs/v3/C/, we just can’t see the real URL)



And now after I backed up a few directories from the first link above, I see 
regardless, *I* was in the wrong place. I didn’t see a ‘4.3' because I was 
looking at the section numbers which are roman numerals, not the chapter 
numbers. Section IV in the Guide are for the Appendices which are organized by 
letters. The only notation I saw then for 4.3 was in the Help Manual, which is 
where my confusion came from. (but that really is where I think this info 
should be - see my previous comment)

And sure enough there is https://www.gnucash.org/docs/v3/C/gnucash-help/ which 
I would have expected to see.

So, we can put aside the naming of the folder since that’s correct. But what 
certainly would be helpful is if the page itself indicated which document you 
were viewing. That bug is still there.

Regards,
Adrien


> On Aug 20, 2018, at 6:52 PM, David Carlson  
> wrote:
> 
> I too am confused now.  First, I think David  stated in 
> the other documentation thread that the document names need to be clarified, 
> and that may be part of why I am confused.  I think that the short names seem 
> to be Guide and Tutorial, which, if they were used consistently, would work 
> for me.  I may be wrong about the names.
> 
> Second, I think that there may be an alias issue, and I am not sure where I 
> am sometimes because of that. In my last foray into online documentation I 
> was specifically trying to get to the current stable (Release 3) version of 
> the documentation, and when I repeat my itinerary as I tried to describe in 
> previous posts, I do end up in pages identified as ../v3/..  So I am puzzled 
> that Adrien does not seem to get to the same place, or how some of my 
> previous attempts to document the trip do not seem to be leading to pages 
> identified as ../v3/..
> 
> Third, I think that document title and chapter numbers do not appear on every 
> page in each form of the documentation, and that has not helped me to keep 
> track of where I am.
> 
> Fourth, the label on the link in the tip just below figure 4.3 of the help 
> manual is named Tutorial and Concepts Guide and it does seem to point to the 
> Tutorial ../v3/..section 4.2, so it seems correct for the current document 
> structure.
> 
> I am not trying to rant, just document my confusion and agreement that 
> simplification would be helpful.  
> 
> David C
> 
> On Mon, Aug 20, 2018 at 4:30 PM, Adrien Monteleone 
>  wrote:
> Hmm.. Not sure how I missed that recently. (I’ve read it before)
> 
> But then if it’s there, I wonder why so many questions still? Perhaps the 
> organization or presentation isn’t very discoverable? User laziness?
> 
> Also, I still don’t think after several years that I’m clear on the 
> difference between the Help Manual and the Tutorial & Concepts Guide. I get 
> what their names imply and I understand the explanation on the website, but 
> here is a case of info that I would expect to find in the other document. 
> This is info about the GUI itself, not ‘how to use’ GnuCash to accomplish an 
> accounting task. (which the name “Tutorial & Concepts Guide” implies and even 
> the website itself defines as the document’s function)
> 
> Should this be relocated to the Help Manual?
> 
> Regards,
> Adrien
> 
> > On Aug 20, 2018, at 3:44 PM, D  wrote:
> > 
> > And you will find said documentation in the Guide at 2.3.3.
> > 
> > David
> > 
> > On August 20, 2018, at 2:32 PM, Derek Atkins  wrote:
> > 
> > 
> > On Mon, August 20, 2018 2:20 pm, Adrien Monteleone wrote:
> >> Of course, that all makes sense.
> >> 
> >> The other improvements, specifically how to resize columns, particularly
> >> the Description column I think should be documente

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[Adrien Monteleone]

Hmm.. Not sure how I missed that recently. (I’ve read it before)

But then if it’s there, I wonder why so many questions still? Perhaps the 
organization or presentation isn’t very discoverable? User laziness?

Also, I still don’t think after several years that I’m clear on the difference 
between the Help Manual and the Tutorial & Concepts Guide. I get what their 
names imply and I understand the explanation on the website, but here is a case 
of info that I would expect to find in the other document. This is info about 
the GUI itself, not ‘how to use’ GnuCash to accomplish an accounting task. 
(which the name “Tutorial & Concepts Guide” implies and even the website itself 
defines as the document’s function)

Should this be relocated to the Help Manual?

Regards,
Adrien

> On Aug 20, 2018, at 3:44 PM, D  wrote:
> 
> And you will find said documentation in the Guide at 2.3.3.
> 
> David
> 
> On August 20, 2018, at 2:32 PM, Derek Atkins  wrote:
> 
> 
> On Mon, August 20, 2018 2:20 pm, Adrien Monteleone wrote:
>> Of course, that all makes sense.
>> 
>> The other improvements, specifically how to resize columns, particularly
>> the Description column I think should be documented. There are enough
>> questions on the list about it to address the topic.
> 
> Absolutely!
> 
>> Regards,
>> Adrien
> 
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
> 
> -derek
> -- 
>   Derek Atkins 617-623-3745
>   de...@ihtfp.com www.ihtfp.com
>   Computer and Internet Security Consultant

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

Re: [GNC-dev] Main WIki Page edit

[Adrien Monteleone]

Nice.

How about this for a tad more clarity on the two official documentation items:

* [http://www.gnucash.org/viewdoc.phtml?doc=help The Help Manual] - a quick 
reference manual for ~~specific~~ _basic accounting_ tasks, and
* [http://www.gnucash.org/viewdoc.phtml?doc=guide The Tutorial and Concepts 
Guide] - an in-depth guide ~~to the concepts~~ _on using GnuCash to implement 
specific accounting concepts_. It is highly recommended to read at least the 
~~first chapters~~ _Getting Started section_ of the guide.

That last edit of course could be more specific with a number of chapters, 
especially if the recommendation is beyond Section I. My point is just that 
‘first chapters’ is a bit vague. (ideally, users should read it all of course, 
save maybe the business or investing sections if they aren’t applicable.)

Regards,
Adrien


> On Aug 20, 2018, at 7:30 PM, John Ralls  wrote:
> 
> 
> 
>> On Aug 20, 2018, at 6:57 AM, David T. via gnucash-devel 
>>  wrote:
>> 
>> OK. I have looked over this issue with an eye to clarifying the text, and I 
>> believe that the User Documentation section should be simplified. As 
>> currently written, as you all have noted, the User Documentation section 
>> includes different layers of content, presented at the same tier of 
>> coverage. Thus, the Help and Tutorial are presented alongside two wiki pages 
>> and two glossaries. That’s inconsistent. 
>> 
>> So, first up is to level things off. That means eliminating the separate 
>> headings for the Glossaries, the FAQ and Using Gnucash, and changing the 
>> main section to refer to the wiki at the same level as the Help and 
>> Tutorial. In the interest of helping people in dire need, I choose to retain 
>> the references to the FAQ and Using GnuCash pages, but as a descriptive list 
>> under the wiki in general (I will note that I also changed the Getting Help 
>> page to parallel this approach). As suggested, mention of the Glossaries 
>> isn’t particularly appropriate here, so I remove it altogether. [FWIW, I 
>> think the proper approach would be to make sure that all uses of special 
>> terminology in the wiki and the documentation receive reference to their 
>> glossary definitions, ideally as tool tips—but that solution is beyond my 
>> ability]
>> 
>> I also don’t like “User Documentation” since we aren’t documenting users, so 
>> I prefer “Documentation for Users”, which requires the following heading to 
>> be changed to “Documentation for Developers”
>> 
>> Here is my final suggestion for the section in question:
>> 
>> === Documentation for Users ===
>> GnuCash offers two major pieces of documentation: 
>> * [http://www.gnucash.org/viewdoc.phtml?doc=help The Help Manual] - a quick 
>> reference manual for specific tasks, and
>> * [http://www.gnucash.org/viewdoc.phtml?doc=guide The Tutorial and Concepts 
>> Guide] - an in-depth guide to the concepts. It is highly recommended to read 
>> at least the first chapters of the guide.
>> The [http://www.gnucash.org/docs.phtml Documentation page on the gnucash.org 
>> ''website''] also contains these documents in
>> * '''other languages:''' de, it, ja, pt; 
>> * '''other formats:''' ''PDF'', ''ePub'' or ''mobi''; as well as
>> * '''other releases:''' nightly (unstable),  previous and earlier stable 
>> releases.
>> The GnuCash wiki includes extensive information regarding all aspects of 
>> GnuCash, contributed by the developers and users of GnuCash. Information in 
>> the wiki covers a broad variety of topics, and includes detailed technical 
>> information, as well as information that applies to specific use cases. Of 
>> particular interest on the wiki are: 
>> * The [[FAQ|GnuCash FAQ]], which contains a collection of frequently asked 
>> questions about GnuCash, including administration, accounting, and glossary 
>> questions, and
>> * [[Using GnuCash]], which collects real life experiences using GnuCash. You 
>> may find (user) solutions here that are not covered by the documentation.
> 
> An excellent start, but I find the “Documentation for Users” section to be a 
> bit stilted, so I’ve changed it to
> 
>> === Documentation for Users ===
>> GnuCash offers two primary instructional documents: 
>> * [http://www.gnucash.org/viewdoc.phtml?doc=help ''The Help Manual''] - a 
>> quick reference manual for specific tasks, and
>> * [http://www.gnucash.org/viewdoc.phtml?doc=guide ''The Tutorial and 
>> Concepts Guide''] - an in-depth guide to the concepts. It is highly 
>> recommended that new users read at least the first chapters of the ''Guide''.
>> These are accessible via the '''Help''' menu in the program (if you've 
>> installed via a package manager you may need to install an additional 
>> package called something like "gnucash-docs") and from the 
>> [http://www.gnucash.org/docs.phtml Documentation page on the gnucash.org 
>> ''website''].
>> The ''Help Manual'' is available in English, German, Italian, and Japanese; 
>> the ''Guide'' in English, Italian, 

Re: [GNC-dev] Main WIki Page edit

[Adrien Monteleone]

Thanks John,

That makes things very clear.

Regards,
Adrien

> On Aug 20, 2018, at 10:39 PM, John Ralls  wrote:
> 
> Adrien,
> 
> I’ve redone the descriptions of the help manual and T to be more correct 
> and I hope clearer. See what you think.
> 
> Regards,
> John Ralls
> 
>> On Aug 20, 2018, at 7:50 PM, John Ralls  wrote:
>> 
>> Adrien,
>> 
>> Neither “clarification” is correct.
>> 
>> The “Tutorial and Concepts Guide” contains a *very* basic introduction to 
>> double-entry accounting, enough to get a new user going if all they have is 
>> a simple bank account and credit card. The rest of it is “how-to” on using 
>> GnuCash to perform some more complex tasks like managing capital gains and 
>> the business module. The emphasis is on using GnuCash and understanding its 
>> quirks. Mostly GnuCash tutorial with an introduction to concepts. 
>> 
>> The “Help Manual” is called that because it’s the document underneath the 
>> context-sensitive help; it has detailed explanations of some of GnuCash’s 
>> windows and dialogs, on the “this button activates foo, the buttons on this 
>> radio control selects which sort of bar you want” level. It’s strung 
>> together to form a document, but it’s not the sort of thing one would want 
>> to read like a book. There’s nothing at all about accounting in it.
>> 
>> Regards,
>> John Ralls
>> 
>>> On Aug 20, 2018, at 5:55 PM, Adrien Monteleone 
>>>  wrote:
>>> 
>>> Nice.
>>> 
>>> How about this for a tad more clarity on the two official documentation 
>>> items:
>>> 
>>> * [http://www.gnucash.org/viewdoc.phtml?doc=help The Help Manual] - a quick 
>>> reference manual for ~~specific~~ _basic accounting_ tasks, and
>>> * [http://www.gnucash.org/viewdoc.phtml?doc=guide The Tutorial and Concepts 
>>> Guide] - an in-depth guide ~~to the concepts~~ _on using GnuCash to 
>>> implement specific accounting concepts_. It is highly recommended to read 
>>> at least the ~~first chapters~~ _Getting Started section_ of the guide.
>>> 
>>> That last edit of course could be more specific with a number of chapters, 
>>> especially if the recommendation is beyond Section I. My point is just that 
>>> ‘first chapters’ is a bit vague. (ideally, users should read it all of 
>>> course, save maybe the business or investing sections if they aren’t 
>>> applicable.)
>>> 
>>> Regards,
>>> Adrien
>>> 
>>> 
>>>> On Aug 20, 2018, at 7:30 PM, John Ralls  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Aug 20, 2018, at 6:57 AM, David T. via gnucash-devel 
>>>>>  wrote:
>>>>> 
>>>>> OK. I have looked over this issue with an eye to clarifying the text, and 
>>>>> I believe that the User Documentation section should be simplified. As 
>>>>> currently written, as you all have noted, the User Documentation section 
>>>>> includes different layers of content, presented at the same tier of 
>>>>> coverage. Thus, the Help and Tutorial are presented alongside two wiki 
>>>>> pages and two glossaries. That’s inconsistent. 
>>>>> 
>>>>> So, first up is to level things off. That means eliminating the separate 
>>>>> headings for the Glossaries, the FAQ and Using Gnucash, and changing the 
>>>>> main section to refer to the wiki at the same level as the Help and 
>>>>> Tutorial. In the interest of helping people in dire need, I choose to 
>>>>> retain the references to the FAQ and Using GnuCash pages, but as a 
>>>>> descriptive list under the wiki in general (I will note that I also 
>>>>> changed the Getting Help page to parallel this approach). As suggested, 
>>>>> mention of the Glossaries isn’t particularly appropriate here, so I 
>>>>> remove it altogether. [FWIW, I think the proper approach would be to make 
>>>>> sure that all uses of special terminology in the wiki and the 
>>>>> documentation receive reference to their glossary definitions, ideally as 
>>>>> tool tips—but that solution is beyond my ability]
>>>>> 
>>>>> I also don’t like “User Documentation” since we aren’t documenting users, 
>>>>> so I prefer “Documentation for Users”, which requires the following 
>>>>> heading to be changed to “Documentation for Developers”
>>>>> 
>>>>> Here is my final suggesti

Re: [GNC-dev] Main WIki Page edit

[Adrien Monteleone]

Much better.

Regards,
Adrien

> On Aug 20, 2018, at 8:57 AM, David T.  wrote:
> 
> OK. I have looked over this issue with an eye to clarifying the text, and I 
> believe that the User Documentation section should be simplified. As 
> currently written, as you all have noted, the User Documentation section 
> includes different layers of content, presented at the same tier of coverage. 
> Thus, the Help and Tutorial are presented alongside two wiki pages and two 
> glossaries. That’s inconsistent. 
> 
> So, first up is to level things off. That means eliminating the separate 
> headings for the Glossaries, the FAQ and Using Gnucash, and changing the main 
> section to refer to the wiki at the same level as the Help and Tutorial. In 
> the interest of helping people in dire need, I choose to retain the 
> references to the FAQ and Using GnuCash pages, but as a descriptive list 
> under the wiki in general (I will note that I also changed the Getting Help 
> page to parallel this approach). As suggested, mention of the Glossaries 
> isn’t particularly appropriate here, so I remove it altogether. [FWIW, I 
> think the proper approach would be to make sure that all uses of special 
> terminology in the wiki and the documentation receive reference to their 
> glossary definitions, ideally as tool tips—but that solution is beyond my 
> ability]
> 
> I also don’t like “User Documentation” since we aren’t documenting users, so 
> I prefer “Documentation for Users”, which requires the following heading to 
> be changed to “Documentation for Developers”
> 
> Here is my final suggestion for the section in question:
> 
> === Documentation for Users ===
> GnuCash offers two major pieces of documentation: 
> * [http://www.gnucash.org/viewdoc.phtml?doc=help The Help Manual] - a quick 
> reference manual for specific tasks, and
> * [http://www.gnucash.org/viewdoc.phtml?doc=guide The Tutorial and Concepts 
> Guide] - an in-depth guide to the concepts. It is highly recommended to read 
> at least the first chapters of the guide.
> The [http://www.gnucash.org/docs.phtml Documentation page on the gnucash.org 
> ''website''] also contains these documents in
> * '''other languages:''' de, it, ja, pt; 
> * '''other formats:''' ''PDF'', ''ePub'' or ''mobi''; as well as
> * '''other releases:''' nightly (unstable),  previous and earlier stable 
> releases.
> The GnuCash wiki includes extensive information regarding all aspects of 
> GnuCash, contributed by the developers and users of GnuCash. Information in 
> the wiki covers a broad variety of topics, and includes detailed technical 
> information, as well as information that applies to specific use cases. Of 
> particular interest on the wiki are: 
> * The [[FAQ|GnuCash FAQ]], which contains a collection of frequently asked 
> questions about GnuCash, including administration, accounting, and glossary 
> questions, and
> * [[Using GnuCash]], which collects real life experiences using GnuCash. You 
> may find (user) solutions here that are not covered by the documentation.
> 
> === Documentation for Developers ===
> 
> 
>> On Aug 18, 2018, at 8:53 AM, D via gnucash-devel  
>> wrote:
>> 
>> The glossary entry has historically been included separately on this page. 
>> When I last suggested changes for the page, it didn't occur to me to remove 
>> that separate section and incorporate references to them (there are two 
>> glossaries: one in the Guide, and the one on the wiki, each with slightly 
>> didn't vintage) in other locations.
>> 
>> Incorporating these references into other sections makes sense to me. It 
>> simplifies the main page structure a little, and reflects the fact that the 
>> glossaries are part of the Guide and wiki, respectively.
>> 
>> I'll look into a rewrite, and send it in for adjustment in the next few days.
>> 
>> David T.
>> 
>> On August 18, 2018, at 7:15 AM, Adrien Monteleone 
>>  wrote:
>> 
>> In combination with making the T glossary sentence a part the Official 
>> documentation paragraph, I think the second sentence should be moved down to 
>> the Developer Documentation paragraph.
>> 
>> Also, the following line needs a number correction:
>> 
>> "The Documentation page on the gnucash.org website also contains ~~this~~ 
>> _these_ documents in”
>> 
>> I’d do either myself, but I see the main page is above my pay grade. (I’m 
>> sure for very good reason)
>> 
>> Regards,
>> Adrien
>> 
>>> On Aug 18, 2018, at 8:53 AM, John Ralls  wrote:
>>> 
>>> 
>>> 
>>>> On Aug 17, 2018, at 11:45 PM, David T. via gnucash-devel 
>>&g

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[Adrien Monteleone]

> On Aug 23, 2018, at 3:00 AM, Geert Janssens  
> wrote:
> 
> Op dinsdag 21 augustus 2018 21:36:58 CEST schreef John Ralls:
>>> On Aug 21, 2018, at 11:50 AM, Geert Janssens 
>>> wrote:
>>> Aside from that they also expect there writers to work with git.
>> 
>> Version control is an obvious hard requirement. I don't know if it
>> completely fulfills your "manageability" requirement, but it's crucial in a
>> collaborative environment to be able to track who-did-what-when and to be
>> able to restore an earlier version if something goes awry.
>> 
> In my requirements I deliberately wrote "manageability". Today we use git for 
> this and from my developer's point of view it has all the features we need. 
> So 
> I consider it an excellent candidate. Unfortunately most non-developers 
> experience it as a major hurdle.
> 
> So I'm open for alternatives that would equally handle version control, but 
> is 
> easier for documentation writers to cope with.
> 
> This can be a completely different tool that feels more intuitive or it can 
> be 
> a system layered on top of git which would hide git's technicalities. For 
> example a web interface that offers online documentation editing and that 
> behind the scenes stores changes in git. I don't know of such project 
> off-hand 
> though, but it may be worth looking around for.

Such a thing does exist.

I’ve been investigating this for some client projects that use Wordpress. There 
are plugins that interface with git for version control both for the site as a 
whole and for specific pages/posts. Wordpress itself has a revisions control 
built in, though it doesn’t work with git out of the box, you can see who made 
what changes and revert specific ones if needed.

I think I also found some time ago that Wikimedia has plugins for generating 
the needed formats.

Regards,
Adrien


> Those who need more advanced access can clone the git repo and work locally.
> 
> 
>> That said I'm perfectly happy to copy a rewritten section of a document into
>> my working directory and create a commit out of it on behalf of a
>> non-technical author who can't get their head around git.
> 
> Of course. Same for me. Anything that lowers the barrier.
> 
> Geert
> 
> 
> ___
> 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 Version Display

[Adrien Monteleone]

Without cluttering up titles and chapter names, utilizing the footer of each 
page to include the version number would work as well.

Regards,
Adrien

> On Aug 24, 2018, at 9:57 AM, John Ralls  wrote:
> 
> 
> 
>> On Aug 24, 2018, at 5:51 AM, David T. via gnucash-devel 
>>  wrote:
>> 
>> Hello,
>> 
>> Today, I had the opportunity to examine the online Help text, where I saw 
>> detailed information about the Transaction Report, which has recently 
>> changed radically. The information provided on the online Help clearly 
>> references the new version of this report, which I surmise because I am 
>> still running 2.6.21, and I do not have this version of the report.
>> 
>> Here is the problem: there is no indication in the online resources (either 
>> in the document itself, or on Gnucash.org ) the version 
>> of GnuCash to which the documentation refers. This could lead to user 
>> confusion, as they see help that refers to functionality that they do not 
>> have.
>> 
>> I am sure that the stock answer here will be: “GnuCash is currently on 
>> release 3.2, and therefore the documentation available at Gnucash.org 
>>  reflects the current release.” I respect that. 
>> 
>> However, at any given time, there will be people who choose for one reason 
>> or another not to upgrade to the latest and greatest version—or more 
>> problematically, are unaware that they are not running the latest version. 
>> These users would benefit from being informed *somewhere* that the 
>> documentation that they are consulting is for a particular version. Is there 
>> some way to add the version number to the header of the documentation pages? 
>> (The footer is also an option, but is less preferable online since the 
>> footer is often well off screen, and may not be noticed by a distressed user 
>> trying to figure out a problem). If the version covered were presented on 
>> screen on every page, then the user would have a clear reminder of this.
> 
> David,
> 
> Sure there is.
> 
> On https://www.gnucash.org/docs.phtml there’s a huge header above each set of 
> document links: "GnuCash v3 (current stable release)”, “GnuCash v2.6 (old 
> stable release)”,
> “Nightly Documentation Builds”, and “Older GnuCash Documentation”.
> 
> Once you’re browsing the document, go to “About this Document” from the table 
> of contents. After “Legal Notice” and “Feedback” you’ll find “History”, the 
> top entry of which indicates the exact release for which the documentation 
> applies.
> 
> Of course it’s possible to add the version into the header. I suppose the 
> simplest would be to change the chapter titles e.g. “Chapter 4. GnuCash 
> Windows & Menus Overview” to “Chapter 4. GnuCash v3.2  Windows & Menus 
> Overview”, just change the chapter title from 
>  Windows  Menus Overview
> to
>   Windows  Menus Overview
>  Chapter titles (“Getting Started”) that don’t include the application tag 
> would need to be reworded, e.g. “Getting Started with GnuCash 3.2”.
> 
> 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: [GNC-dev] Documentation Version Display

[Adrien Monteleone]

David,

I agree the pages should have both the document title (per another thread) and 
the version either in the header or footer.

But I can’t fathom clicking the ‘main’ documentation link and thinking that I’m 
getting anything other than the most current version. If I knew I was running 
an older version of the software and slightly down the page I see a link for 
documentation for that version, I’m going to grab that one instead, making a 
fairly safe assumption that the main link isn’t for me.

The only solution I can think of for this situation is to remove those two 
links at the top of the page and users will then click the links for their 
chosen version. (with each already well labeled) Adding the version to those 
links is, to me, unnecessary clutter. (links should be as concise and 
accurately descriptive as possible, and changing that link text each release 
will reduce search juice for those links.)

Regards,
Adrien

> On Aug 24, 2018, at 12:03 PM, David T. via gnucash-devel 
>  wrote:
> 
> John, 
> 
> 
>> On Aug 24, 2018, at 10:57 AM, John Ralls  wrote:
>> 
>> 
>> 
>>> On Aug 24, 2018, at 5:51 AM, David T. via gnucash-devel 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> Today, I had the opportunity to examine the online Help text, where I saw 
>>> detailed information about the Transaction Report, which has recently 
>>> changed radically. The information provided on the online Help clearly 
>>> references the new version of this report, which I surmise because I am 
>>> still running 2.6.21, and I do not have this version of the report.
>>> 
>>> Here is the problem: there is no indication in the online resources (either 
>>> in the document itself, or on Gnucash.org ) the 
>>> version of GnuCash to which the documentation refers. This could lead to 
>>> user confusion, as they see help that refers to functionality that they do 
>>> not have.
>>> 
>>> I am sure that the stock answer here will be: “GnuCash is currently on 
>>> release 3.2, and therefore the documentation available at Gnucash.org 
>>>  reflects the current release.” I respect that. 
>>> 
>>> However, at any given time, there will be people who choose for one reason 
>>> or another not to upgrade to the latest and greatest version—or more 
>>> problematically, are unaware that they are not running the latest version. 
>>> These users would benefit from being informed *somewhere* that the 
>>> documentation that they are consulting is for a particular version. Is 
>>> there some way to add the version number to the header of the documentation 
>>> pages? (The footer is also an option, but is less preferable online since 
>>> the footer is often well off screen, and may not be noticed by a distressed 
>>> user trying to figure out a problem). If the version covered were presented 
>>> on screen on every page, then the user would have a clear reminder of this.
>> 
>> David,
>> 
>> Sure there is.
>> 
>> On https://www.gnucash.org/docs.phtml there’s a huge header above each set 
>> of document links: "GnuCash v3 (current stable release)”, “GnuCash v2.6 (old 
>> stable release)”,
>> “Nightly Documentation Builds”, and “Older GnuCash Documentation”.
> 
> You overlook the large section above this which prominently proclaims the 
> "two major GnuCash documentation packages” and provides direct links to each 
> of these ***without making any statement of version***. Moreover, the 
> structure of the page would imply that the documents behind *these* links are 
> somehow different from the ones beneath the "current stable release” header. 
> Perhaps the ones at the top are newer and better? It’s difficult to tell. 
> I’ll note that the links behind these entries even differ, making it 
> practically speaking impossible for a user to know whether these two 
> documents are in fact the same. I would finally suggest that “current stable 
> release” is not as universal a term as many in this community think it is. I 
> believe that many users wouldn’t know what it signifies.
> 
> 
>> 
>> Once you’re browsing the document, go to “About this Document” from the 
>> table of contents. After “Legal Notice” and “Feedback” you’ll find 
>> “History”, the top entry of which indicates the exact release for which the 
>> documentation applies.
> 
> The About this document appears only on the main TOC page. What about the 
> rest of the document? Users don’t always access our online help via the main 
> TOC.
> 
>> 
>> Of course it’s possible to add the version into the header. I suppose the 
>> simplest would be to change the chapter titles e.g. “Chapter 4. GnuCash 
>> Windows & Menus Overview” to “Chapter 4. GnuCash v3.2  Windows & Menus 
>> Overview”, just change the chapter title from 
>>  Windows  Menus Overview
>> to
>>   Windows  Menus Overview
>> Chapter titles (“Getting Started”) that don’t include the application tag 
>> would need to be reworded, e.g. “Getting Started with GnuCash 3.2”.
> 
> How hard would it 

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[Adrien Monteleone]

Thanks for the background info Geert,

I recall a discussion some time ago about the tools and methods used to 
generate the documentation, and I think based on that thread and the info 
you’ve just provided that the solution lies in a new method entirely. (frames 
aren’t really the best option as you noted)

I’ll try to dig up that old thread, but is there a list of ’needs’ of the 
developers to use when evaluating methods?

The only thing I can find recently is that the intended approach was to create 
an “O’Reilly” style book, (just a goal or hard and fast requirement?) and I 
recall there needed to be a means to generate PDF, .mobi, and .epub versions.

As for the current method, I see docbook has something called docbook-xslt 
which is a stylesheet approach to layout and other visuals. It seems geared 
more toward print than web, but I supposed it could be used for such. This 
strikes me though as trying to find a means to keep using the proverbial hammer 
rather than a more appropriate tool. Though, I do see Gnome is still using 
Docbook and their user help is well integrated into their website as individual 
web pages, (breadcrumbs and all) and not anything resembling a printed page.

Regards,
Adrien

> On Aug 21, 2018, at 2:46 AM, Geert Janssens  
> wrote:
> 
> Op dinsdag 21 augustus 2018 02:44:59 CEST schreef Adrien Monteleone:
>> David C,
>> 
>> So for clarification this is the first link you posted about:
>>> https://www.gnucash.org/docs/v3/C/gnucash-guide/txns-register-oview.html#t
>>> xns-regstyle1
>> Notice this is in the folder /docs/v3/C/gnucash-guide/
>> 
>> But the link on the Documentation page and the link you included (both in 
> that first post and in the last one) that said how you got there was this:
>>> https://www.gnucash.org/viewdoc.phtml?rev=3=C=help
>> 
>> So yes, that IS version 3 (listed here as ‘rev=3’) but that’s not the same
>> link as above. (though it might be the exact same content, I didn’t check)
>> 
>> I can’t find any way, other than typing it in directly, to get to the
>> /docs/v3/C/ directory wherein lies the /gnucash-guide/ and /gnucash-help/
>> folders and contents. All of the links on the documentation page seem to
>> point instead to the /viewdoc.phtml which never changes the URL as you
>> navigate the document. (my guess is the viewdoc.phtml template is serving
>> the pages physically located in /docs/v3/C/, we just can’t see the real
>> URL)
> 
> The viewdoc.phtml page is a first and imperfect attempt to integrate the 
> documentation in the website.
> 
> It ensures that while presenting the documentation the main website's 
> navigation menus and style are still visible. Before that page existed 
> clicking on a documentation link would suddenly remove all website 
> decorations 
> and just show you the documentation on a plain white page with no option to 
> navigate to other parts of the main website.
> 
> viewdoc.phtml is just a wrapper that opens the actual documentation in a 
> separate frame. If you ask your browser to open that frame in its own window 
> you'll see the direct links David posted here.
> 
> The use of a frame is old-fashioned and has indeed many limitations. It was 
> the only option at the time that could be implemented with reasonable effort.
> 
> Of course it would be much nicer to have bread crumbs and clear links for 
> each 
> page. And a documentation navigation menu integrated in the website's main 
> decorations.
> 
> However from how I understand this would mean to create a specialized docbook 
> style used exclusively to generate the documentation section of our website. 
> I 
> believe the way we currently generate the gnucash html documentation is not 
> fit for integration. Writing such a specialized docbook style is possible, 
> but 
> I never found time to dig in.
> 
> Regards,
> 
> Geert


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

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC] Column widths again)

[Adrien Monteleone]

> On Aug 21, 2018, at 7:12 AM, David T.  wrote:
> 
> David,
> 
> I haven’t advocated for renaming the documents. I changed a couple of 
> headings on the main wiki page.
> 
> There are two documents, 
> 
> 1) the Help Manual
> and
> 2) the Tutorial and Concepts Guide
> 
> as outlined at gnucash.org.
> 
> One might refer to them respectively as the “Help” and the “Guide”. There is 
> no "Help Guide.”
> 
> As for Adrien’s question regarding what goes where, there was a discussion a 
> few years back on precisely this issue—i.e., on what exactly is meant by 
> "Help Manual” and “Tutorial and Concepts Guide” and what, therefore should go 
> into each document. I can’t put my hands on that thread right now, but the 
> upshot was that the Help was seen by most as the place that identifies “this 
> button does this function” kinds of instruction, while the Guide is intended 
> to contain “if I am trying to accomplish goal X, here is how to do that.” 
> These categories are admittedly fuzzy around the edges. I admit that I am 
> more of a “how do I do X” kind of person, and so have worked most on 
> upgrading the Guide.

I think John addressed this very well in the other thread about Wiki main page 
editing. His description of the two documents should probably now be put on the 
website as well.

> 
> Finally, the website was redesigned  years ago, and the 
> current generic addressing scheme was implemented at that time. I commented 
> on it at the time, but we never came to any resolutions. I suspect some kind 
> of batter and breadcrumb solution (along with a flash frying in a nice deep 
> fryer) might help with navigation. When I am directing someone to a specific 
> page in the documentation, I right-click the link to the page in question, 
> and copy  the link. That provides the full URL.

Thanks for the tip. And that is probably how David C copied that direct link. 
The picture is much clearer now.

Regards,
Adrien


> 
> David
> 
>> On Aug 20, 2018, at 7:52 PM, David Carlson  
>> wrote:
>> 
>> I too am confused now.  First, I think David > > stated in the other documentation thread that the
>> document names need to be clarified, and that may be part of why I am
>> confused.  I think that the short names seem to be Guide and Tutorial,
>> which, if they were used consistently, would work for me.  I may be wrong
>> about the names.
>> 
>> Second, I think that there may be an alias issue, and I am not sure where I
>> am sometimes because of that. In my last foray into online documentation I
>> was specifically trying to get to the current stable (Release 3) version of
>> the documentation, and when I repeat my itinerary as I tried to describe in
>> previous posts, I do end up in pages identified as ../v3/..  So I am
>> puzzled that Adrien does not seem to get to the same place, or how some of
>> my previous attempts to document the trip do not seem to be leading to
>> pages identified as ../v3/..
>> 
>> Third, I think that document title and chapter numbers do not appear on
>> every page in each form of the documentation, and that has not helped me to
>> keep track of where I am.
>> 
>> Fourth, the label on the link in the tip just below figure 4.3 of the help
>> manual is named Tutorial and Concepts Guide and it does seem to point to
>> the Tutorial ../v3/..section 4.2, so it seems correct for the current
>> document structure.
>> 
>> I am not trying to rant, just document my confusion and agreement that
>> simplification would be helpful.
>> 
>> David C
>> 
>> On Mon, Aug 20, 2018 at 4:30 PM, Adrien Monteleone <
>> adrien.montele...@lusfiber.net> wrote:
>> 
>>> Hmm.. Not sure how I missed that recently. (I’ve read it before)
>>> 
>>> But then if it’s there, I wonder why so many questions still? Perhaps the
>>> organization or presentation isn’t very discoverable? User laziness?
>>> 
>>> Also, I still don’t think after several years that I’m clear on the
>>> difference between the Help Manual and the Tutorial & Concepts Guide. I get
>>> what their names imply and I understand the explanation on the website, but
>>> here is a case of info that I would expect to find in the other document.
>>> This is info about the GUI itself, not ‘how to use’ GnuCash to accomplish
>>> an accounting task. (which the name “Tutorial & Concepts Guide” implies and
>>> even the website itself defines as the document’s function)
>>> 
>>> Should this be relocated to the Help Manual?
>>> 
>>> Regards,
>>> Adrien
>>> 

Re: [GNC-dev] Wiki Home page

[Adrien Monteleone]

From a cursory look at other FOSS projects:

LibreOffice has an “Improve It” menu on their site, with an entry labeled “Docs 
Team”. They utilize a wiki and printable WYSIWYG produced using LO itself. 
(probably the lowest entry barriers of any project save for Mozilla)

GIMP has a “Participate” menu and then a link for “add Documentation” (but that 
took me to the docs, not how to contribute. I had to go to their generic 
developers page to find anything on contributing to the docs) It appears they 
currently use DocBook XML/git but are looking to move to something else using 
markdown.

Inkscape has “Contribute” “Learn” “Community” “Develop” menu entries on their 
site. Strangely, how to help with documentation seems a bit hidden, but 
apparently, that’s because it seems to be all via their website CMS. Details 
info might be hidden behind their documentation mailing list they direct 
everyone to, but I don’t see any page on what is involved in the doc process 
itself.

Thunderbird & Firefox have a “Get Involved” link and then a simple 
“Documentation” heading and a “Contributing to Documentation” subsection. They 
utilize a wiki apparently exclusively. (with official help forums for users 
instead of a mailing list which employs ’sticky’ articles people can write - 
something I think GnuCash could benefit greatly from, especially just for 
users.)

Gnome - has a “Get Involved” link, then a simple “Documentation” heading with 
“Contribute to the documentation team” link. They seem to use Mallard, an XML 
editor and Git.

Arch - yes, that Arch, uses a wiki. (integrated help is of course in the form 
of man pages as part of their regular build system)

So perhaps taking a cue from that, a simple “Contributing to Documentation”, 
“Help with Documentation” or a simple “Documentation” heading/link is just 
fine. It did seem that those projects that used more complicated tools than 
wiki/CMS hid their actual process behind several links or I had to go to the 
developer section to find anything. I’m not suggesting GnuCash should bury info 
however.

I see on the website, GnuCash has a simple “Writing Documentation” link and the 
page looks pretty direct and straightforward. The Wiki page is certainly more 
involved, but I don’t think the title “Improving” here is misleading. The only 
thing I see missing on either page is any hint that the wiki or the website are 
also documentation projects, or how to get involved with them, and at least the 
former has a lower entry barrier. (Has there been any discussion of moving to a 
CMS for the website?)

Just some thoughts...

Regards,
Adrien



> On Aug 18, 2018, at 1:42 AM, David T. via gnucash-devel 
>  wrote:
> 
> Frank,
> 
> You imply that the use of Eclipse somehow renders the documentation process 
> simple enough for a user to identify a typo and get it fixed. I flat out 
> disagree, and I think that using disingenuous language on the wiki home page 
> is not going to change the reality: implementing a change in the 
> documentation is a Process.
> 
> I still think the heading should be reverted to “Developing the 
> Documentation”, and I am copying gnucash-devel as you requested.
> 
> David
> 
> 
>> On Aug 17, 2018, at 11:23 AM, Frank H. Ellenberger 
>>  wrote:
>> 
>> Hi David,
>> 
>> Am 16.08.2018 um 20:52 schrieb David T.:
>>> Frank,
>>> 
>>> As you will see on gnucash-devel, I had reason to examine the wiki home 
>>> page today, and noticed some of the changes you have implemented there over 
>>> the last year or so. I wanted to discuss off list with you one of those 
>>> changes.
>>> 
>>> You changed “Developing the Documentation” to “Improving the Documentation” 
>>> with the note that “developing sounds so high-flown”. I think you’re wrong 
>>> here, and I’d like you to change that back to “Developing.” 
>>> 
>>> Here’s why I think that:
>>> 
>>> IF improving the documentation simply involved opening a Word file, 
>>> changing the text or formatting using a WYSIWIG editor, and saving the 
>>> result, THEN I’d agree on referring to it as “Improving the Documentation.”
>>> 
>>> HOWEVER, it simply isn’t that easy—as outlined on our own wiki page. That 
>>> page includes guidance on: the installation of several specialized software 
>>> packages, the creation of accounts at github and Bugzilla, the use of 
>>> version control software, the editing of DocBook XML text files, the XSLT 
>>> validation of your edits, etc. etc. etc.
>> 
>> Using a recent Eclipse CDT bundle should have everything, which is required:
>> a Git module,
>> a Bugzilla connector,
>> a WYSIWIG XML editor,
>> a module for autotools (configuer, make, ...).
>> You could ask Geert about his success with KDevelop.
>> 
>>> Simply put, the documentation update process *IS* complicated and 
>>> “high-flown”—and to imply otherwise is misleading.
>> 
>> The idea behind the change:
>> We should not already on the main page scare off potential contributors.
>> They should decide it while reading the 

Re: [GNC-dev] Main WIki Page edit

[Adrien Monteleone]

In combination with making the T glossary sentence a part the Official 
documentation paragraph, I think the second sentence should be moved down to 
the Developer Documentation paragraph.

Also, the following line needs a number correction:

"The Documentation page on the gnucash.org website also contains ~~this~~ 
_these_ documents in”

I’d do either myself, but I see the main page is above my pay grade. (I’m sure 
for very good reason)

Regards,
Adrien

> On Aug 18, 2018, at 8:53 AM, John Ralls  wrote:
> 
> 
> 
>> On Aug 17, 2018, at 11:45 PM, David T. via gnucash-devel 
>>  wrote:
>> 
>> 
>> 
>>> On Aug 17, 2018, at 11:29 AM, Frank H. Ellenberger 
>>>  wrote:
>>> 
>>> Am 16.08.2018 um 20:37 schrieb David T. via gnucash-devel:
 Hello,
 
 I was reviewing the Wiki today to try to figure out where a page on the 
 SQL formats might get attached, and I noticed a change to the Glossary 
 section that makes for awkward English.
 
 As currently entered, the section reads:
 
 Above GnuCash Tutorial and Concepts Guide includes a comprehensive 
 Glossary: 
 [https://www.gnucash.org/docs/v2.6/C/gnucash-guide/gnc-gloss.html 
 Released] or [https://code.gnucash.org/docs/C/gnucash-guide/gnc-gloss.html 
 Maintainer] version.
 
 However, it used to say:
 
 The GnuCash Tutorial and Concepts Guide includes a comprehensive Glossary: 
 [https://www.gnucash.org/docs/v2.6/C/gnucash-guide/gnc-gloss.html 
 Released] or [https://code.gnucash.org/docs/C/gnucash-guide/gnc-gloss.html 
 Maintainer] version.
 
 I would like to ask that someone with edit permissions on the wiki home 
 page to please change the word “Above” back to “The” to make the section 
 read more idiomatically.
 
 David T.
>>> 
>>> IMHO it is also bad style to have:
>>> The Tutorial and Concepts Guide - an in-depth guide to the concepts.
>>> :
>>> The GnuCash Tutorial and Concepts Guide includes a comprehensive
>>> Glossary: Released or Maintainer version.
>>> 
>> 
>> We differ in our opinion here. I stand by my recommendation.
> 
> And you’re both right, it needs a more thorough rewrite to flow better. Since 
> the glossary isn’t a stand-alone document it shouldn’t have its own level-two 
> header. An additional sentence in the T paragraph under Official 
> Documentation would be better. On the other hand the wiki needs more 
> prominence, there’s a whole lot more information there than just the FAQ and 
> technical glossary.
> 
> 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: [GNC-dev] Bugzilla Structure

[Adrien Monteleone]

The Search function worked very well with the bug number and any combination of 
the terms in the title. (or just a single term) But certainly, there could be a 
‘product’ that covers *all/miscellaneous/generic* documentation bugs that apply 
to multiple documents.

So I entered this: https://bugs.gnucash.org/show_bug.cgi?id=796825

Regards,
Adrien

> On Aug 27, 2018, at 9:28 AM, David T. via gnucash-devel 
>  wrote:
> 
> Hello,
> 
> I was just trying to track down the status of documentation bug 777893, and 
> was stymied for a bit. 
> 
> A bit of history: I raised the bug to induce the addition of information 
> about the SQL formats. Subsequently, I wrote a section for inclusion in the 
> Guide, which was submitted 10 days ago as Pull Request #109.
> 
> Today, I wanted to go add the PR # to the bug, and clicked my way to the 
> bugzilla section for the Guide, only to not find the bug in question. 
> Searching by bug number shows that the bug was entered under Help, rather 
> than Guide. This situation points out that breaking the bugs out to this 
> level of granularity can have negative effects: first, it forces a reporter 
> to decide on the appropriate document for a bug, rather than focus on the 
> problem in question; second a user looking for these bugs must discern the 
> specific document to which a given bug was assigned in order to locate said 
> bug; third, it causes difficulty if a given bug recommends changes to more 
> than one piece of documentation, as this bug does—which doc does the bug get 
> assigned to?
> 
> While it may have seemed an advance to be able to structure our bugs to cover 
> specific documents, I wonder at the choice at this point, and ask how 
> difficult it would be either to change the structure itself, or find a way to 
> allow users the option of seeing all Doc bugs in an aggregated screen?
> 
> Cheers,
> David
> ___
> 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] GnuCash 3.2 Released

[Adrien Monteleone]

I see right near the top there is still the “GnuCash 2.6 release tour”. Perhaps 
an update there to 3.0 would be in order.

Regards,
Adrien

> On Jul 10, 2018, at 8:45 PM, Wm  wrote:
> 
> On 29/06/2018 08:43, Geert Janssens wrote:
>> Op donderdag 28 juni 2018 22:11:49 CEST schreef Dennis West:
>>> I'm sure you like to get feedback from someone with absolutely no
>>> problems at all.
>>> 
>>> I was using 2.6.21 on my primary computer and testing 3.1/3.2 on my
>>> standby testbed (both on Win 10.1803).  I finally decided to take the
>>> plunge and upgraded my primary computer form 2.6.21 to 3.2.  The
>>> experience was flawless and now my testbed pc is eagerly awaiting vs 4.0.
> 
> But approximately a decade away for v4 so maybe get some new kit before 2030 
> for your testbed :)
> 
>> That's nice to hear :)
> 
> Aside: is there a reason why version changes aren't on (or easily found from) 
> the front page  of gnucash.org? they used to be there.
> 
> -- 
> Wm
> 
> ___
> 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] Wiki FAQ Page

[Adrien Monteleone]

Broken links can be handled by permanent redirects in the web server’s 
.htaccess file. I think Derek would be the one to add those in. If you compile 
the list for him to copy & paste, I’m sure that would help. The end result is 
someone can click the old link from the mailing list and the server will drop 
them in the new location.

On a content note, I suspect you could have three separate headings for 
“Managing GnuCash files”, “Configuring GnuCash” and “Customizing GnuCash”. I’m 
thinking the latter to be more geared towards things like CSS and where to put 
custom reports, while ‘Configuring’ is more related to tweaking the app 
preferences.

Regards,
Adrien 

> On Sep 4, 2018, at 9:43 AM, David T. via gnucash-devel 
>  wrote:
> 
> Hello,
> 
> I am digging in to the FAQ page with an eye to rationalizing the accumulated 
> mess. My hope is to make it easier for uers to find answers to their 
> questions. 
> 
> Currently, the structure of the page does not accurately reflect the content 
> of the questions. For example, the section “Installation Troubleshooting” 
> covers two broad and disparate question areas. 
> 
> In addition, numerous questions have been placed haphazardly in sections to 
> which they do not belong. For example, questions about theming do not belong 
> under Installation (for Mac or Windows), but IMHO under “GnuCash Files and 
> managing a GnuCash installation”, which itself would be better named 
> “Configuring and Managing”
> 
> On a practical level, as I rearrange the FAQ on some pretty substantial 
> levels, questions and headings on the page will be changed. 
> 
> First issue: I do not see a way to see whether the wiki has any instances of 
> links to a specific question. Clicking “What links here” only shows links to 
> the overall FAQ page.
> 
> Second issue: many links from the mailing lists will no longer work, which 
> may cause problems for users searching the ML archives and retrieving the 
> stale links. How should this be handled?
> 
> Now, on a meta-level, I think the primary headings here might be better 
> arranged as follows:
> 
> 1. General Questions
>  [move “Accounting Questions” to this section]
> 2. Installation
> 3. Using GnuCash [moved ahead of cunfiguring]
> 4. Configuring and Managing
>  [Move “Customizing" questions from current section 8 to this section]
> 5. Troubleshooting
> 6. Exporting and Importing Data
> 7. Business Features
>  [Move entire Developing GnuCash section of questions to the pages 
> established for Developers]
> 
> I welcome input and feedback.
> 
> David
> 
> 
> ___
> 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] Wiki FAQ Page

[Adrien Monteleone]

Yeah, those seem to be internal to the wiki, not an external broken link. But 
then, if the page itself isn’t changing, just the named anchor, it might not 
matter. The page still exists, so someone clicking an FAQ link from a mailing 
list message will still get dropped into the same page, but if the named anchor 
is not found, they’ll be focused to the top of the page rather than the 
intended place. Essentially then that named anchor will function as a basic 
page anchor which is just fine.

Regards,
Adrien

> On Sep 5, 2018, at 11:13 AM, Derek Atkins  wrote:
> 
> I feel like MediaWiki also has a way to fix that, too, but it may only
> work at a page level and not at an anchor level.
> 
> c.f. https://meta.wikimedia.org/wiki/Help:Redirect
> and
> https://meta.wikimedia.org/wiki/Help:Section#Section_linking_and_redirects
> 
> -derek
> 
> On Tue, September 4, 2018 12:42 pm, Adrien Monteleone wrote:
>> Broken links can be handled by permanent redirects in the web server’s
>> .htaccess file. I think Derek would be the one to add those in. If you
>> compile the list for him to copy & paste, I’m sure that would help. The
>> end result is someone can click the old link from the mailing list and the
>> server will drop them in the new location.
>> 
>> On a content note, I suspect you could have three separate headings for
>> “Managing GnuCash files”, “Configuring GnuCash” and “Customizing GnuCash”.
>> I’m thinking the latter to be more geared towards things like CSS and
>> where to put custom reports, while ‘Configuring’ is more related to
>> tweaking the app preferences.
>> 
>> Regards,
>> Adrien
>> 
>>> On Sep 4, 2018, at 9:43 AM, David T. via gnucash-devel
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> I am digging in to the FAQ page with an eye to rationalizing the
>>> accumulated mess. My hope is to make it easier for uers to find answers
>>> to their questions.
>>> 
>>> Currently, the structure of the page does not accurately reflect the
>>> content of the questions. For example, the section “Installation
>>> Troubleshooting” covers two broad and disparate question areas.
>>> 
>>> In addition, numerous questions have been placed haphazardly in sections
>>> to which they do not belong. For example, questions about theming do not
>>> belong under Installation (for Mac or Windows), but IMHO under “GnuCash
>>> Files and managing a GnuCash installation”, which itself would be better
>>> named “Configuring and Managing”
>>> 
>>> On a practical level, as I rearrange the FAQ on some pretty substantial
>>> levels, questions and headings on the page will be changed.
>>> 
>>> First issue: I do not see a way to see whether the wiki has any
>>> instances of links to a specific question. Clicking “What links here”
>>> only shows links to the overall FAQ page.
>>> 
>>> Second issue: many links from the mailing lists will no longer work,
>>> which may cause problems for users searching the ML archives and
>>> retrieving the stale links. How should this be handled?
>>> 
>>> Now, on a meta-level, I think the primary headings here might be better
>>> arranged as follows:
>>> 
>>> 1. General Questions
>>> [move “Accounting Questions” to this section]
>>> 2. Installation
>>> 3. Using GnuCash [moved ahead of cunfiguring]
>>> 4. Configuring and Managing
>>> [Move “Customizing" questions from current section 8 to this section]
>>> 5. Troubleshooting
>>> 6. Exporting and Importing Data
>>> 7. Business Features
>>> [Move entire Developing GnuCash section of questions to the pages
>>> established for Developers]
>>> 
>>> I welcome input and feedback.
>>> 
>>> David
>>> 
>>> 
>>> ___
>>> 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
>> 
> 
> 
> -- 
>   Derek Atkins 617-623-3745
>   de...@ihtfp.com www.ihtfp.com
>   Computer and Internet Security Consultant
> 
> 


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

Re: [GNC-dev] Long Term Documentation Directions

[Adrien Monteleone]

David,

Count me in. (with a vote for Markdown)

Consider the idea of making the bulk of the current Help to be appendices of 
the new Manual. Many of those pages are simply reference lists of the menu 
entries.

Also, consider arranging the Manual by function rather than form. If GnuCash 
evolves to more closely follow the Gnome HIG, the UI is going to be very 
different in how it presents each function and where it appears. Arranging the 
manual this way will mesh nicely with that path and relieve the need to 
completely re-write it yet again.

Regards,
Adrien

> On Sep 8, 2018, at 10:48 AM, John Ralls  wrote:
> 
> 
> 
>> On Sep 8, 2018, at 7:57 AM, David T. via gnucash-devel 
>>  wrote:
>> 
>> Hello,
>> 
>> As I have noted in another thread recently, I am finding the process of 
>> updating the various documentation pieces extremely challenging—due in large 
>> part to the fragmented nature of this documentation. Different contributors 
>> have placed information on similar topics in any of a number of official 
>> locations in the GnuCash documentation realm, making the update process a 
>> circular nightmare. 
>> 
>> This leads to variation in content, approach, and likelihood that a user is 
>> going to locate the full information on a given subject.
>> 
>> Rather than tackle each editorial task as if somehow this time it will be 
>> different, I would like to ask whether there would be support for a complete 
>> rewrite of the documentation. My idea would be to somehow merge all the 
>> content from the Guide and the Help into one huge file, and then establish a 
>> single Grand Unifying Manual that would provide users with a single source 
>> for help. Contextual help would be stripped back to only naming on screen 
>> functions, with references back to the GUM in all cases. The wiki would 
>> remain primarily for specific use cases and temporary issues. The FAQ would 
>> also point to the docs in most cases. Optionally, I would strip out the 
>> “Tutorial” aspect of the Tutorial and Concept Guide, as I think a solid 
>> Manual would obviate the need for this aspect (that, and the fact that most 
>> of the Tutorail sections are written in a “Hi, how are ya” folksie tone that 
>> I find inappropriate in formal documentation).
>> 
>> I do not make this suggestion lightly—I know the complexity and difficulty 
>> of such an endeavor. However, I increasingly find that the content of the 
>> Help and Guide are so inextricably enmeshed that any attempt to clean up one 
>> will have extreme impact on the other—and attempting to shepherd these 
>> changes through piecemeal is cumbersome at best. 
>> 
>> Currently, the Help occupies 230 PDF pages, while the Guide weighs in at 
>> 287. That’s over 500 pages of information—a good portion of which is 
>> duplicated across the docs. Any such rewrite would entail a HUGE effort, 
>> which is why I write this email: there is no way anyone would undertake this 
>> without knowing in advance whether the community would accept such a change 
>> at the outset.
> 
> I’ve no objection in principle.  Thorough preparation for such a rewrite 
> would also include a review of the mailing list archives and the wiki.
> 
> We should resolve the source-format question (Docbook/Asciidoc/Docx/Markdown) 
> before beginning actual writing.
> 
> It’s a pretty massive project, I think you’ll need to recruit a team.
> 
> 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: Invoicing on GnuCash

[Adrien Monteleone]

You should do a search on inventory software for your industry. There can be 
quirks of different products that a one-size-fits-all solution will require 
some gymnastics.

I’ve never used it myself, but one supplier I used to know was very happy with 
Fishbowl. That is just one of several hundred options.

Regards,
Adrien

> 
> Op woensdag 7 maart 2018 05:39:36 CET schreef André Steyn:
>> Thank you for the reply.
>> 
>> Could you perhaps suggest a package that handles descent inventory controls
>> and invoicing.
>> 
>> Regards
>> 
>> André Steyn

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

Re: [GNC-dev] gnc_add_swig_guile_command compile errors

[Adrien Monteleone]

Dave,

The info about directories being separate is higher up that wiki page in the 
Cmake section. I too missed it not long ago trying to build the 2.7 series.

Perhaps the page needs to be re-organized or maybe inside that Ubuntu section, 
it needs to be made clear that the higher general sections need to be read 
first.

Regards,
Adrien

> On Apr 6, 2018, at 7:38 PM, DaveC49  wrote:
> 
> Thanks Rob,
> 
> John passed on the message to me. I was following the Build#Ubuntu page on
> the wiki, so this may need modifying too. I will keep notes as I sort out
> and get used to building with Cmake. I guess the other cure would be to use
> ../../gnucash-3.0 to go up to the parent directory from a build-cmake inside
> to top level gnucash directory. With the extract from the tarball from the
> website, this is labelled gnucash-3.0. 
> 
> I haven't pulled it down with git in which case it may not have the major
> version number attached to the folder. 
> 
> I generally prefer to have the build directory under the top level directory
> as I sometimes have sources for a couple of versions and that keeps the
> relevant build with the source for that version.
> 
> Cheers
> 
> David
> 
> 
> 
> -
> 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

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

Re: [GNC-dev] Bug 795101 - Scroll Bar in Reconcile Window Floats in and covers the check boxes

[Adrien Monteleone]

Bob,

This isn’t so much a comment on the fix itself, but the problem.

I don’t see it on macOS 10.13.4, so it may be Windows specific. I haven’t built 
yet on Linux to try it there to comment on that platform. For me, the scroll 
bar is a tiny sliver that fits in nicely to the right of the check boxes and 
does not cover them.

I’m not sure if that makes a difference in the approach.

Regards,
Adrien

> On Apr 11, 2018, at 9:52 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> Would like some thoughts on possible fix...
> 
> There seems to be three options but I may of missed something, move the
> toggle reconcile column, make it wider or add a dummy spacer column.
> 
> The first may not be liked..
> The last seems a bit over kill.
> So making the column wider seems the best / easiest.
> 
> In reconcile-view.c you have the line below which sets the column title...
> 
>gnc_search_param_set_title ((GNCSearchParam *) param, _("Reconciled:R")
> + 11);
> 
> All I need to do is add a couple of spaces either side of the 'R' which I
> assume I can not do as it would affect the translation string
> 
>gnc_search_param_set_title ((GNCSearchParam *) param, _("Reconciled:
> R  ") + 11);
> 
> But can I add this after above line, it works on my setup, is this OK.
> 
>// to allow space for the vertical scrollbar showing, add a couple of
> spaces
>gnc_search_param_set_title ((GNCSearchParam *) param,
>  g_strconcat ("  ", ((GNCSearchParam *) param)->title, "  ",
> NULL));
> 
> Bob
> ___
> 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: Feedback about 2.7.8

[Adrien Monteleone]

Christop,

A general guide to CSS(in the context of web pages) is available here:

https://www.w3schools.com/css/

A more specific guide with respect to CSS usage in GTK3 is here:

https://developer.gnome.org/gtk3/stable/chap-css-overview.html


Regards,
Adrien

> On Mar 28, 2018, at 2:20 PM, Christoph R  
> wrote:
> 
> Hi Geert,
> 
>> Am 28.03.2018 um 17:24 schrieb Geert Janssens :
>> 
>> Op woensdag 28 maart 2018 15:46:26 CEST schreef Christoph R:
>> 
>>> It choked on one of my files, which worked fine with 2.6 and was probably
>>> created with 2.4 or even earlier.  There was an out-of range date in the
>>> price database which I corrected manually. But normal users would have been
>>> lost.
>> What was the date set to before you corrected it ? And how does it display 
>> in 
>> gnucash 2.6 if you look at that particular price in the Price editor ?
> 
> Date was 1301-09-13 00:05:08 +0053
> and it shows up absolutely correct as 13.9.1301 :-)
> 
>> 
>>> adding “EXTRA_ARGS=--nofile” to Library/Application\
>>> Support/Gnucash/gnucashrc does not have any effect any more.
>> 
>> I never heard of a gnucashrc file. Perhaps that is/was an OS X/Quarz 
>> specific 
>> extension ? The loading code on OS X has been aligned with Windows and Linux 
>> in this development cycle, so perhaps it got lost in that work.
> 
> Yes it was parsed by the MacOS launcher script, which apparently is gone now.
> 
>>> Changing account or value of a reconciled
>>> split gives me the correct warning as needed. Yeah! But I can change the
>>> description of a reconciled split without a warning.
>> 
>> Hmm, a split doesn't have a description, only a memo. Do you mean you get no 
>> warning when changing the memo ? Or do you mean you can change the 
>> transaction 
>> description of a transaction that has reconciled splits ?
> 
> I get no warning when changing the memo. I get one when changing the 
> transaction description.
> 
>> 
>>> Fonts and icons are different - due to gtk3 - and not
>>> necessarily to my liking. I had customised .gtkrc-2.0.gnucash a bit and of
>>> course this does not work any more. Unfortunately I did not figure out how
>>> to customise gtk3 on MacOS. Any help would be appreciated
>> 
>> I have updated the relevant FAQ entry:
>> https://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_change_the_register_colors.3F
> 
> Wow, this CSS stuff is cryptic. Can you enlighten me how to set font and font 
> size?
> 
> Cheers,
> Christoph 
> 
> ___
> 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: Feedback about 2.7.8

[Adrien Monteleone]

Geert,

I just noticed in the sample file linked in the FAQ that the following rules 
are repeated at the top and bottom of the file:


/* Change font color by mixing with grey */
.lighter-grey-mix {
color: mix (currentColor, grey, 0.8);
}
.darker-grey-mix {
color: mix (currentColor, grey, 0.2);
}

If someone didn’t see the bottom rules and only changed the top versions, they 
wouldn’t see any change in the interface.

Is there a class/id list for the GnuCash UI so we can know what’s available to 
style? Or are those listed in the sample file the only ones available? (I’m 
also assuming other properties can be set, for example font-size in addition to 
color, etc. or is this not possible?)

Regards,
Adrien

> On Mar 28, 2018, at 10:24 AM, Geert Janssens  
> wrote:
> 
> Op woensdag 28 maart 2018 15:46:26 CEST schreef Christoph R:
>> Hi,
>> 
>> since 2.7.8 is deemed a release candidate I am giving it a try on MacOS High
>> Sierra.
>> 
>> here is my feedback so far:
> 
> Thanks for your feedback.
> 
>> It choked on one of my files, which worked fine with 2.6 and was probably
>> created with 2.4 or even earlier.  There was an out-of range date in the
>> price database which I corrected manually. But normal users would have been
>> lost.
> What was the date set to before you corrected it ? And how does it display in 
> gnucash 2.6 if you look at that particular price in the Price editor ?
> 
>> adding “EXTRA_ARGS=--nofile” to Library/Application\
>> Support/Gnucash/gnucashrc does not have any effect any more.
> 
> I never heard of a gnucashrc file. Perhaps that is/was an OS X/Quarz specific 
> extension ? The loading code on OS X has been aligned with Windows and Linux 
> in this development cycle, so perhaps it got lost in that work.
> 
>> Normal
>> accounting with aqbanking and trading accounts seems to work fine. My
>> reports are fine.
> 
> Nice :)
> 
>> Finally I can change unreconciled splits in a transaction
>> with reconciled splits again.
> 
> Yay!
> 
>> Changing account or value of a reconciled
>> split gives me the correct warning as needed. Yeah! But I can change the
>> description of a reconciled split without a warning.
> 
> Hmm, a split doesn't have a description, only a memo. Do you mean you get no 
> warning when changing the memo ? Or do you mean you can change the 
> transaction 
> description of a transaction that has reconciled splits ?
> 
>> I need to file a bug
>> report on that.
> 
>> Fonts and icons are different - due to gtk3 - and not
>> necessarily to my liking. I had customised .gtkrc-2.0.gnucash a bit and of
>> course this does not work any more. Unfortunately I did not figure out how
>> to customise gtk3 on MacOS. Any help would be appreciated
> 
> I have updated the relevant FAQ entry:
> https://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_change_the_register_colors.3F
> 
>> 
>> Besides the nitpicks above it looks pretty good. Thanks for all the good
>> work!
> 
> Thanks! I'm happy the overall result is satisfactory as the gtk update was 
> unplanned and pretty late in the development cycle.
> 
> Geert
> 
> 
> ___
> 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: Feedback about 2.7.8

[Adrien Monteleone]

Thank you Geert,

That’s even better than just a list.

Regards,
Adrien

> On Mar 29, 2018, at 2:50 AM, Geert Janssens  
> wrote:
> 
> https://wiki.gnome.org/Projects/GTK%2B/Inspector

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

Re: Feedback about 2.7.8

[Adrien Monteleone]

> On Mar 31, 2018, at 6:51 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> 
> wrote:
> 
> Op donderdag 29 maart 2018 14:58:08 CEST schreef Adrien Monteleone:
>> Thanks for creating that page Alen,
>> 
>> I think this will be much easier for users to work with than the FAQ. I’d
>> recommend moving the FAQ material here.
>> 
> I'm fine with moving the FAQ material here, but I would prefer to keep a link 
> from the faq to this page so users can be redirected.

Yes, sorry. I guess in my editing of that reply, I accidentally chopped that 
part off. Certainly, the FAQ should link to this page.

> 
> I would also propose a less technical name for the wiki page. Most users 
> don't 
> know what gtk is so the wouldn't guess that page would hold information on 
> tweaking the gnucash gui style/theme.
> 
> So the page title should rather refer to such keywords: style, theme, tweak, 
> customize,... I'm not very creative in finding good titles right now, so feel 
> free to suggest some for public deliberation.
> 
> Geert

How does “Customize the GnuCash Theme” or “Customize the GnuCash Visual Style” 
sound?

I prefer the first one, and probably anyone even asking this question has some 
concept of system theming and so would be more likely to use that terminology.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Feedback about 2.7.8

[Adrien Monteleone]

> On Mar 29, 2018, at 3:00 AM, Alen Siljak  wrote:
> 
> 
> To answer a part of Adrien's question - see the gtk overview 
> (https://developer.gnome.org/gtk3/stable/chap-css-overview.html), the first 
> code entry, example 7. It sets the font to Comic Sans and paints it pink. 
> I've created the gtk-3.0.css file in C:\Users\siljak\AppData\Roaming\GnuCash, 
> added the example 7:
> 
> button, entry {
>  color: #ff00ea;
>  font: 12px "Comic Sans";
> }
> 
> and the entries in the account list header and footer became pink. The font 
> setting did not work but at least there are some signs of life! :)
> 
> Cheers

Thanks Alen,

I linked that page myself in response to the OP looking for CSS help. I think 
the GTK Inspector will be a big help, especially if it is interactive.

My initial suspicion (as with all things CSS and before further investigation 
into the button widget) is that another CSS rule is overriding your font 
choice—or maybe GTK doesn’t like Comic Sans :)

Note that the above link you provided on gnome.org mentions that each rule is 
applied to a node in the widget’s tree. It’s possible there is a child node 
something like [button > label] which has a font rule that is more specific 
than simply [button].


Regards,
Adrien

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

Re: Feedback about 2.7.8

[Adrien Monteleone]

Alen,

A follow-up on the button...

Check out the CSS section of: 
https://developer.gnome.org/gtk3/stable/GtkButton.html

It seems there are no child nodes of button.

But this reference does say it will get the class .image-button or .text-button.

My suspicion would be to try .text-button as the selector instead of just 
[button] and see what happens.

It would be nice if their reference included some examples or links to some 
such resource. The W3C has a much more complete reference for their specs, 
unfortunately, they aren’t in the context of designing a UI.

Regards,
Adrien

> On Mar 29, 2018, at 7:48 AM, Adrien Monteleone <adrien.montele...@gmail.com> 
> wrote:
> 
> 
>> On Mar 29, 2018, at 3:00 AM, Alen Siljak <alen.sil...@gmx.com> wrote:
>> 
>> 
>> To answer a part of Adrien's question - see the gtk overview 
>> (https://developer.gnome.org/gtk3/stable/chap-css-overview.html), the first 
>> code entry, example 7. It sets the font to Comic Sans and paints it pink. 
>> I've created the gtk-3.0.css file in 
>> C:\Users\siljak\AppData\Roaming\GnuCash, added the example 7:
>> 
>> button, entry {
>> color: #ff00ea;
>> font: 12px "Comic Sans";
>> }
>> 
>> and the entries in the account list header and footer became pink. The font 
>> setting did not work but at least there are some signs of life! :)
>> 
>> Cheers
> 
> Thanks Alen,
> 
> I linked that page myself in response to the OP looking for CSS help. I think 
> the GTK Inspector will be a big help, especially if it is interactive.
> 
> My initial suspicion (as with all things CSS and before further investigation 
> into the button widget) is that another CSS rule is overriding your font 
> choice—or maybe GTK doesn’t like Comic Sans :)
> 
> Note that the above link you provided on gnome.org mentions that each rule is 
> applied to a node in the widget’s tree. It’s possible there is a child node 
> something like [button > label] which has a font rule that is more specific 
> than simply [button].
> 
> 
> Regards,
> Adrien
> 

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

Re: Feedback about 2.7.8

[Adrien Monteleone]

Thanks for creating that page Alen,

I think this will be much easier for users to work with than the FAQ. I’d 
recommend moving the FAQ material here.

I started a talk:discussion on your new wiki page. If my suggestion is fine and 
you don’t have time/access to both linux and macOS, I’ll be happy to fill in 
the info for those.


Regards,
Adrien

> On Mar 29, 2018, at 3:00 AM, Alen Siljak  wrote:
> 
> A few questions/suggestions:
> 
> - captcha
> Captcha on wiki reports that the v1 is to be deprecated soon.
> 
> - gtk3 page. 
> I've created a Wiki entry for GTK3 with the main idea being sharing tips 
> about customization - https://wiki.gnucash.org/wiki/GTK3. This is also 
> related to the issue https://bugzilla.gnome.org/show_bug.cgi?id=791823. 
> Having a sample of a customizes CSS file would be a valid workaround. My main 
> goal is to get the adawaita dark theme on Windows machine.
> Let's add any tips, findings, including links to valid .css theme 
> configurations (which could be elsewhere, i.e. gist; there are also whole 
> sites dedicated to gtk3 themes so I'm gonna try to copy adawaita dark css 
> directly).
> 
> - list of ids
> David is correct, pointing to the important question raised by Adrien. 
> However, I'd think that the sample GnuCash css files would answer that, at 
> least partly. I'll write down my findings into the wiki page as I'm darkening 
> the UI.
> 
> - variables
> And, related to the above, I'm wondering why are there @ variables in the 
> GnuCash css files. Is this .scss or are they replaced elsewhere? I've seen 
> [this](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables) 
> even though I've never used it.
> 
> To answer a part of Adrien's question - see the gtk overview 
> (https://developer.gnome.org/gtk3/stable/chap-css-overview.html), the first 
> code entry, example 7. It sets the font to Comic Sans and paints it pink. 
> I've created the gtk-3.0.css file in C:\Users\siljak\AppData\Roaming\GnuCash, 
> added the example 7:
> 
> button, entry {
>  color: #ff00ea;
>  font: 12px "Comic Sans";
> }
> 
> and the entries in the account list header and footer became pink. The font 
> setting did not work but at least there are some signs of life! :)
> 
> Cheers
> 
>> Sent: Thursday, March 29, 2018 at 12:53 AM
>> From: "David Carlson" 
>> To: "Robert Fewell" <14ubo...@gmail.com>
>> Cc: "GNUCASH devel" 
>> Subject: Re: Feedback about 2.7.8
>> 
>> Neither of those sample .css file addresses Adreien's question
>> 
>> " Is there a class/id list for the GnuCash UI so we can know what’s
>> available to style? Or are those listed in the sample file the only ones
>> available? (I’m also assuming other properties can be set, for example
>> font-size in addition to color, etc. or is this not possible?)
>> "
> ___
> 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: trial balance - how to find mismatch question

[Adrien Monteleone]

Wm,

Consider the case of running a historical Balance Sheet for a date that falls 
on a market holiday that also falls on a weekend. The latest price prior to 
that holiday might be 2 days prior. The ’nearest price’ will be the day after 
the holiday. If Gnucash is pulling the day after price, it IS the ’nearest 
price’ to the target date of the report, but it is a ‘future price’ with 
respect to the report. Had you run the report on the actual day of the holiday, 
you’d get a different result. (the price from 2 days prior would be used)

It isn’t that people are magically downloading prices from the future, but that 
the case of running a historical report might pull in a price that is closer to 
the report date, but actually in the future with respect to the report date 
that is the problem.

If 2 days prior to the report, the market for silver closed at $16.50 and the 
day after the holiday, the market closed at $17.00 and GC used $17.00 for the 
commodity price because it was only 1 day from the report date as opposed to 2 
days, the report would overstate the assets by 3% as of the date of the report 
and be incorrect.

Holidays alone aren’t the problem. It happens with respect to when you actually 
‘get prices’. Perhaps the markets weren’t closed at all crossing a period 
boundary, and you routinely get prices on the first of the month. Running a 
Balance Sheet on any end of month day will always produce the wrong result. GC 
will use price on the day after the report, not the one before the report.

What is needed here is a ‘latest price’ (as opposed to ‘most recent’ which is 
relative to the today’s date, not the report date) or else change/add an option 
for ’nearest in time prior’.

In order to avoid this problem, one has to download on input prices for any 
specific day a report is run.

Regards,
Adrien

> On Mar 5, 2018, at 4:08 PM, Wm via gnucash-devel  
> wrote:
> 
> On 03/03/2018 18:52, D via gnucash-devel wrote:
> 
>> I think having nearest in time use future dates relative to the report date 
>> is not useful. Mind you, matching a broker statement for value (as opposed 
>> to holdings) is perhaps equally not useful.
>> I guess I could see a point to a nearest in time using later dates (for 
>> example, when the date history is sparse, and the only earlier date is much 
>> earlier). But perhaps your suggestion of a separate setting would solve the 
>> dilemma.
> 
> Where the heck do you get future prices from ?
> 
> Seriously.  This is valuable information.  I want to know how you know.
> 
> In any event, why aren't you telling gnc what it needs to know so it can 
> multiply some numbers together?
> 
> It is a *person* that says what a commodity was worth on a date not gnc after 
> all.
> 
> -- 
> Wm
> 
> never vote for a man that doesn't understand that imposing a tax on metal 
> mauy work in the inverse to what he expects. duh
> 
> 
> ___
> 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] Gtk and themes

[Adrien Monteleone]

> On Oct 19, 2018, at 9:38 AM, cicko  wrote:
> 
> 
> My point, on the other hand, would be - the users want customizations and
> that won't change anytime soon. And you can confirm that simply by
> considering the amount of questions on this list referring to fonts,
> spacing, colors, sizes, icons, etc. 
> Unfortunately.
> 

A non-scientific recollection based on recent threads is that most of this is 
coming from the Windows base. There are some UI bugs I see asked about on Mac, 
and a few window sizing issues on linux, but most of the desire for visual 
changes is from people on Windows who liked the old GTK2 look and don’t like 
the GTK3 styling with respect to colors and especially padding. Maybe linux 
users can figure out how to use the gtk-inspector and learn enough CSS to make 
things work for them and we don’t hear anything. Maybe MacOS users are so used 
to not being able to change much of anything, they just accept the new look. 
(and some like me, prefer it with a few custom CSS tweaks) I don’t know if you 
can extrapolate the number of users *asking* for styling assistance on the 
Windows platform to what total percentage of downloads for that platform 
actually want customization, but I’d say the *need* is rather tiny. Overall, 
I’d hazard a rough guess that less than 10 users have been involved in such 
threads from the asking perspective.

Personally, I don’t think GnuCash needs to worry about theming other than to 
try to follow best practices and not introduce many, or any, custom widgets 
that can break via different desktop themes. Support a light and dark variant 
app theme that looks decent across Windows, Mac, Gnome & Ubuntu as that will 
cover 99%+ of the user base, with the GTK3 and CSS wiki pages for the fraction 
of 1% left out. Ideally, if someone could figure out how to run gtk-inspector 
on Windows, that might be helpful for those folks. In the meantime, making the 
app work correctly is certainly more important, as is re-working the code base 
to eventually facilitate a move to an MVC pattern that might facilitate easier 
visual customization, or at least more native platform integration to remove 
the occasion for the requests.

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

Re: [GNC-dev] [GNC] GnuCash 3.3 Released

[Adrien Monteleone]

This may be related to this bug: https://bugs.gnucash.org/show_bug.cgi?id=796875

Regards,
Adrien

> On Oct 2, 2018, at 2:47 PM, Christian Kluge  wrote:
> 
> Hi,
> 
> Am 30.09.2018 um 22:42 schrieb John Ralls:
> 
>>  • Bug 796665 - Backspace Key Inoperable After Ctrl+V.
> 
> 
> This seems to be fixed, however I’ve encountered a new one.
> 
> Under certain circumstances I can’t select-all on autofilled
> transactions with Crtl+A, if I’ve clicked into a text input field,
> instead a random portion of the line gets selected right when I press
> Ctrl, the “a“ has no effect afterwards.
> 
> Is this already known or should I file a report?
> 
> Kind regards
> 
> Christian Kluge
> 
> ___
> gnucash-user mailing list
> gnucash-u...@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see 
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.


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

Re: [GNC-dev] Problems with Mailman?

[Adrien Monteleone]

Ah, I knew that. I’ll fiend temporary memory loss and lack of research effort 
to remind me. Sorry to take your time.

Thanks,
Adrien

> On Oct 1, 2018, at 2:38 PM, Derek Atkins  wrote:
> 
> More likely a DNS hiccup where it couldn't resolve your IP address back to
> a FQDN.  This error comes from postfix, not mailman.
> 
> -derek
> 
> On Mon, October 1, 2018 3:33 pm, Adrien Monteleone wrote:
>> I’ve had two messages today fail with 504 5.5.2 error: Helo command
>> rejected: need fully-qualified hostname
>> 
>> This happened once with a user message and another sent to both user and
>> devel.
>> 
>> Resending was successful however,
>> 
>> Regards,
>> Adrien
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> 
> 
> 
> -- 
>   Derek Atkins 617-623-3745
>   de...@ihtfp.com www.ihtfp.com
>   Computer and Internet Security Consultant
> 
> 


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

Re: [GNC-dev] GnuCash 3.3 Released

[Adrien Monteleone]

Chris,

Did your new Income/Balance multi-column report make it into this release or is 
it still in development?

Regards,
Adrien

> On Oct 1, 2018, at 9:23 AM, Christopher Lam  wrote:
> 
> Hi all
> 
> While everyone is busy shaking the program to weed out any new bugs, please 
> be aware that the invoice reports have been modified, with an aim for greater 
> maintainability (i.e. printable invoice, easy-invoice, fancy-invoice now 
> share the same code base and have been approximated as well as possible to 
> the original reports) and flexibility (invoice headers e.g. date, client 
> details, invoice details etc can now be reordered at will; insert company 
> logo; full CSS customisation). 
> 
> Please send any comments via bug reports.
> 
> 
> From: John Ralls
> Sent: Monday, 1 October 2018 4:48 AM
> To: Gnucash-User
> Cc: gnucash-devel; gnucash-annou...@gnucash.org
> Subject: [GNC-dev] GnuCash 3.3 Released
> 
> The GnuCash development team announces GnuCash 3.3, the fourth release of the 
> 3.x stable release series.
> 
> Changes
> 
> Between 3.2 and 3.3, the following bugfixes were accomplished:
> 
>   • Bug 771667 - Different warnings when changing reconciled splits vs. 
> splits linked to reconciled splits.
>   • Bug 784420 - "Save changes on closing" window waits 2^32 seconds when 
> "Time to wait for answer" is set 0.
>   • Bug 786708 - GnuCash won't load currency fractions larger than 
> 100. Also create larger fractions for the account dialog.
>   • Bug 787439 - Segmentation Fault in Transfer dialog after clearing 
> Date field and pressing escape.
>   • Bug 789594 - Unable to overwrite sqlite3 database file.
>   • Bug 792446 - Mixed languages in error dialog.
>   • Bug 794526 - Python bindings can't find loadable modules.
>   • Bug 794755 - Commodity Register displays fractional prices.
> Prices will now be displayed in decimal, rounded to two more places than the 
> currency's smallest unit.
> 
>   • Bug 794870 - If no book is opened, gnucash still asks if the user 
> wants to save changes when opening a file.
>   • Bug 795821 - GnuCash could not obtain the lock for 
> file://C:\Users\username\Documents\GnuCash\2.6.21\\.gnucash
>   • Bug 796054 - Unposting and reposting invoice doubles amounts.
>   • Bug 796137 - query.search_for outputs critical qof.object errors and 
> prevents queries being run.
>   • Bug 796248 - Editing Scheduled Transaction.
> In addition to not begining to edit already-loaded transactions, don't try to 
> load splits that are already loaded. It shouldn't be possible to load a 
> transaction without also loading its splits.
> 
>   • Bug 796474 - Segmentation fault while setting up online banking.
> Allow only a single instance of the assistant.
> 
>   • Bug 796509 - Saved reports don't respect *some* 'Edit report options'.
>   • Bug 796579 - Cannot go forward with empty duplicates screen.
>   • Bug 796665 - Backspace Key Inoperable After Ctrl+V.
>   • Bug 796669 - Dark Theme Text Colors Hard to Read.
> Only add the register-foreground class when using Gnucash built in colours. 
> When this setting not used, the foreground colour by default will be what 
> ever the theme has set and will be down to the user to over ride along with 
> the other register colours.
> 
>   • Bug 796724 - Can't overwrite gnucash DB on MariaDB.
>   • Bug 796725 - 4 of 6 Date Posted options fail to return matching 
> transactions.
>   • Bug 796734 - Auto-complete entry not highlighting to allow for 
> incremental entry.
>   • Bug 796737 - Patch to restore gncmod-python.c.
>   • Bug 796739 - Toolbar buttons have no labels.
>   • Bug 796751 - reconcile window usability - R column should be next to 
> Amount.
>   • Bug 796755 - buggy window handling at startup.
>   • Bug 796756 - OFX import fails to recognize associated income accounts.
>   • Bug 796759 - --add-price-quotes leaves a lock on the file.
>   • Bug 796762 - Scrollbar partially hides the delete button in the Saved 
> Report Configurations window.
> The vertical scrollbar obscures the delete button in the tree view so add a 
> dummy blank column to the end and set it to the width of the vertical 
> scrollbar.
> 
>   • Bug 796766 - Credit note creating 'imbalance' with wrong entries.
>   • Bug 796777 - CVE-2008-1391: Integer overflow in included strfmon 
> function.
>   • Bug 796788 - Strange behaviour in options of multicolumn report.
>   • Bug 796792 - SaveAs Overwrite dialogue in background and not visible.
>   • Bug 796812 - gnc_date_cell_get_date and gnc_date_cell_get_date_gdate 
> have different date validation behaviour.
>   • Bug 796813 - Date validation inconsistent.
>   • Bug 796814 - Changing a book's read-only threshold doesn't 
> immediately affect open registers.
>   • Bug 796816 - Notes field in Duplicate Invoice dialogue is 'read-only'.
>   • Bug 796819 - Bad icon 

Re: [GNC-dev] Error in payment processing since version 3

[Adrien Monteleone]

If you had an attachment it did not come through, but...

If you view the invoice and then choose to process payment with the toolbar 
button, does that work?

Regards,
Adrien

> On Oct 5, 2018, at 6:32 PM, Jeroen Dörr  wrote:
> 
> Hello,
> 
> I'm new here, so please instruct me how to proceed if I'm wrong.
> 
> I noticed following:
> 
> * In version 2.6.19 and earlier I was able to process payments against
>   created invoices.
> * Since version 3.1.2( first version I used) I can't process anymore
>   because now Gnu-Cash is searching on orders instead of customer and
>   doesn't find ANY match.
> * Also matches that were already successfully done that I try to edit
>   will fail now.
> * I installed latest release (3.3) last weekend but with same result.
> 
> See example below (Language is Dutch)
> 
> Customer name should show up, but instead the order connected to the customer 
> is searched.
> 
> Translation of error: You have no valid account. Create an account of type "" 
> before you proceed with the payment. Maybe you want to create an AP or AR 
> Invoice first?
> 
> * The invoices are available. In version 3 Gnu-Cash can't find them
>   anymore. When I switch back to my latest version 2.6.19, it works again.
> 
> Thanks in advance for your reply.
> 
> Jeroen Dörr
> 
> ___
> 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

[GNC-dev] Problems with Mailman?

[Adrien Monteleone]

I’ve had two messages today fail with 504 5.5.2 error: Helo command rejected: 
need fully-qualified hostname

This happened once with a user message and another sent to both user and devel.

Resending was successful however,

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

[GNC-dev] Erroneously filtered register

[Adrien Monteleone]

After loading up the first time on 3.3 (MacOS High Sierra) I noticed one of my 
registers had very few transactions in it. Slight panic started to take hold, 
but I quickly reminded myself I make backups, and then I noticed the ‘Filtered’ 
indication in the upper right corner. I checked the filter settings and sure 
enough, it was set to an end date as ‘Choose date’ and the result as 1/1/16 
which was the earliest date in this book. Clearing the filter to ‘Show all’ of 
course made the other transactions visible again as expected. Note, prior to 
this, the register was *not* filtered and all transactions were visible. (I’ve 
never used this feature) Also, this register was open at the time I closed 
Gnucash prior to updating the app and relaunching so it was one of those tabs 
automatically re-opened. I’m not sure if that made a difference, was part of 
the cause (another open register remains unfiltered however) or if this was 
just a one-time quirk.

Has anyone else noticed this?

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

Re: [GNC-dev] Documentation update problems

[Adrien Monteleone]

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 GnuCash versions 
would be the simplest and non-developer friendly approach.

Any other build would be from git, would be more geared to developers/testers, 
or those who wanted/needed bleeding edge nightlies. Those build instructions 
would more likely cover Windows and Mac in addition to Linux, and explain the 
GnuCash git repos. (and any build quirks from trying to use them)

I don’t think that latter sort of info should be on the same page(s) as those 
geared towards non-developers/testers. It will only serve to confuse.

Regards,
Adrien

> On Sep 19, 2018, at 4:16 PM, David Cousens  wrote:
> 
> 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 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.
> 
> David, 
> A lot of users rather than developers will build from the tarballs rather 
> than from the github repositories. While this
> page was I think originally targeted primarily at developers, with the 
> release of v3.2 quite a lot of users on Ubuntu
> based systems started building because the distribution repositories didn't 
> have, and still don't have in may cases, the
> latest Gnucash available. More people were also moving to Ubuntu 18.04 and 
> Linux Mint Tara based on Ubuntu 18.04 was
> also being released. The change to 3.2 also resulted in some updates to the 
> dependencies along with the move to cmake
> form./configure becoming compulsory. I had a few problems initially  with the 
> build, so I updated the
> BuildingUbuntu16.04 page as I sorted out issues and I updated it as other 
> issues came up on the Gnucash User forum along
> with a few other contributors.
> 
>> Focusing our efforts on *a* GnuCash Way of building the program would 
>> simplify the wiki immensely.
> 
> I think the prefrred way for users is from the tarballs not github. Too many 
> options with master maint, tags on releases
> etc., that unless you have some programming background it would put new users 
> off rather than encourage them.
> 
> 
> David Cousens
>> 
>>> 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.