Re: [GNC-dev] WebKitGtk now defaults to Gtk4

[Adrien Monteleone]

Thanks John,

If the internal links are indeed possible, I'd think HTML to the browser 
would be the way to go. As David noted, if someone wants a PDF, they can 
save it from there.


But all is not lost with respect to a direct PDF export. That might be 
possible by first generating the HTML, but instead of sending it to the 
Browser for viewing, run it through one of the following first, then to 
disk:


1. https://ekoopmans.github.io/html2pdf.js/
2. https://github.com/spipu/html2pdf/

(the first seems a bit more robust and less limited than the second)

Regards,
Adrien

On 11/20/23 9:35 PM, john wrote:

Sending the HTML to the browser is easy. Writing the reports in PDF directly requires 
a complete rewrite of the report output code that's hardwired to generate HTML using 
basic scheme text output, plus replacing the javascript-based charts solution with 
some other library that generates PostScript vector graphics (https://graphviz.org 
 comes to mind). That's a pretty big rewrite, probably a 
solid year of work for an experienced developer with lots of available time and 
assuming that there's a suitable library to abstract generating the PDF boilerplate.

The reason using the web browser to display the html loses the 
transaction/account links is because they're implemented using a callback 
function that we can register with WebKitWebViewGtk. That goes away when the 
browser isn't part of GnuCash. It's not impossible, of course: It should be 
possible to embed a bit of javascript that calls back to GnuCash on a (new) 
socket listener that would do the linked action.


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

Re: [GNC-dev] WebKitGtk now defaults to Gtk4

[Adrien Monteleone]

Thank you for the explanation John. I seem to recall a bit of that from 
an older discussion.


While it seems there is no ideal all-in-one solution, might two of your 
last three suggestions be doable or is each one a serious pile of work 
on its own?


That is:

*Send the HTML/JS/CSS to the default browser
*Write reports directly to PDF

The drill-down links I think get lost either way, and maybe that is 
unacceptable, but View, Print, PDF export, and get charts. (The writing 
to PDF would just be for export)


And I'm not quite following the loss of drill-down links on the first 
option. Certainly, I can open a local HTML file in my browser and it can 
contain links to local resources. Is there a way to expose a URI to a 
GnuCash transaction or other resource that might work? Or is the fact 
that it has to leave 'GTK land' for 'native land' in the browser and 
back in such a case the problem? Or is it that targeting anything within 
the data file is the tricky/impossible part? (I admit, while I've used 
local HTML to access local files, I've never tried to access only a 
portion of a file or even a marker in a file)


Apologies if my lack of understanding the guts of it all is noise.

Regards,
Adrien

On 11/19/23 11:20 PM, john wrote:

The reason for selecting WebKitGtk is the Gtk: It had WebKitWebView and was 
supported in most distros and Mingw.

The Mozilla team seem to have stopped maintaining their embedding facility 
around 2015 and it is apparently badly bit-rotted.

Blink is Chromium's rendering engine so that's the same as Sherlock's suggested 
CEF, i.e. Chromium Embedded Framework. It supports Gtk only on Linux; on macOS 
and Windows it build to the native toolkits, so we'd have to hack the build to 
provide Gtk3 on macOS and Windows. There's no mention of support for MinGW, so 
that might not be possible. The level of effort needed both to get and keep the 
ports working might make it impractical even if it is possible, but the only 
way to find that out is to try.

Note that while most repos have a Chromium package, only Arch and Nix have CEF 
packages. Adding it as a GnuCash dependency is likely to get most distros to 
drop us, so nearly everybody on Linux/BSD would be forced to use flatpak.


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

Re: [GNC-dev] WebKitGtk now defaults to Gtk4

[Adrien Monteleone]

Gecko? Blink?

I'm sure there was a reason for selecting WebKit originally. Does that 
still hold true?


Regards,
Adrien

On 11/18/23 10:00 PM, john wrote:

I spent some time this afternoon poking at webkit replacement. The options I 
found are:
* Keep using WebKitGtk
* Figure out how to wrap a native (meaning Apple AppKit or Microsoft) WebView 
in a GtkWidget
* Send the HTML/JS/CSS to the default browser. This will lose the links to 
GnuCash objects like transactions
* Configure a GtkTextView to understand HTML tags. This doesn't support charts, 
printing, or PDF export.
* Write reports directly to PDF. There are libraries out there but I didn't 
find any FLOSS ones that mention CSS styling or drawing charts in their feature 
sets.

Any other ideas?


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

Re: [GNC-dev] Scripting Gnucash actions without UI

[Adrien Monteleone]

I've seen several questions on the user list with respect to that very 
use case as an SX variable.


Regards,
Adrien

On 10/12/23 9:26 PM, Christopher Lam wrote:

Other ideas are possible: determine the balance of an account at a
particular date


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

Re: [GNC-dev] Questions about */guide/figures/basics_AccountRelationships.svg

[Adrien Monteleone]

I'm not certain if these use acceptable licenses for GnuCash, or if they 
indeed cover the necessary blocks, but it seems "GNU Unifont" (GPL) and 
"Noto" (OFL) might fit the bill.


It seems Gnu Unifont has the greatest # of blocks supported.

Even then, I see what look like some Chinese only fonts with an insane # 
of glyphs by comparison.


see:
https://en.wikipedia.org/wiki/Unicode_font?useskin=vector#List_of_Unicode_fonts

This may shed more light, though not with a handy chart like the other 
page, limited to OpenSource fonts:

https://en.wikipedia.org/wiki/Open-source_Unicode_typefaces?useskin=vector

Regards,
Adrien

On 9/13/23 6:33 PM, Frank H. Ellenberger wrote:
why is it using font-family:Bitstream Vera Sans? Some non-latin glyphs 
are not supported by this fonts. Any suggestions for a font with full 
utf-8 support?


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

Re: [GNC-dev] Git branches

[Adrien Monteleone]

'next' is a good one. It is unambiguous, and unlikely to get auto-corrected.

Regards,
Adrien

On 3/24/23 10:02 AM, Chris Graves wrote:

Or perhaps, cur(rent) and next.


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

Re: [GNC-dev] GnuCash 4.13 Released

[Adrien Monteleone]

A big Thanks! to the dev team, and congrats on the release.

Of the many pieces of OSS I use, I'm the most impressed with the speed 
and professional attitude of the devs addressing any and all issues, not 
to mention their seemingly infinite patience with new users (and a few 
of us old hats) when we don't understand or misunderstand how the app works.


Regards,
Adrien

On 12/18/22 5:07 PM, John Ralls wrote:

The GnuCash development team announces GnuCash 4.13, the fourteenth release in 
the stable 4.x series


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

Re: [GNC-dev] Git branches

[Adrien Monteleone]

My 2¢:

From a user perspective, I very much like the idea of a year.quarter 
numbering scheme. One need never have to research the age of the release 
they are using. (even those of us who know the cycle)


If non-compatible changes are kept on say, the ".1" or a year-based 
boundary, that would make the upgrade path easy enough to follow.


Regards,
Adrien

On 11/14/22 12:59 PM, john wrote:

But what about the opposite approach, having only one permanent branch and no 
major releases? Instead of 5.0 next spring we'll release 2023.1 and the spring 
after that 2024.1, with .2 in June, .3 in September, and .4 in December every 
year? Major changes, like c++options, get merged when ready; we might do a beta 
release (e.g. 2023.2beta) a month before a release with a major change to get 
better user testing. We'd have to work out policies for API and schema changes 
because it would blow up the file upgrade path for users who've skipped some 
releases. There's a very dense exposition on this pattern at 
http://dymitruk.com/blog/2012/02/05/branch-per-feature/.


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

Re: [GNC-dev] Dependencies policy for major releases

[Adrien Monteleone]

Mint 21 is based on Ubuntu 22.04, so it seems there shouldn't be any 
serious concerns right off.


Regards,
Adrien

On 10/29/22 7:08 PM, John Ralls wrote:

I don't know how to support that: https://repology.org doesn't report linux 
mint 21 at all and 20 shows only 137 packages, with no entries for aqbanking, 
anything starting with lib including libgtk+-3.0, libofx, or libxml, nor 
sqlite3. Searching for those names at http://packages.linuxmint.com also 
produced nothing. However, https://en.wikipedia.org/wiki/Linux_Mint says that 
Mint follows Ubuntu LTS releases with a slight delay. As long as that's true 
and you keep up to date with new releases you should have no problems.

Regards,
John Ralls


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

Re: [GNC-dev] alpha-testing budgets in 5.x

[Adrien Monteleone]

Thanks, that will save some time.

Regards,
Adrien

On 1/4/22 11:54 AM, john wrote:

Linux users can also get a flatpak nightly from 
https://code.gnucash.org/builds/flatpak/master 
.

Regards,
John Ralls


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

Re: [GNC-dev] alpha-testing budgets in 5.x

[Adrien Monteleone]

On 1/4/22 10:40 AM, Christopher Lam wrote:

Experienced Users,

The upcoming 5.x series (master branch) currently has a one-time fix for
budgets to ensure they're internally stored as unreversed numbers.
Currently (up to 4.x) budgeting $1000 income into $600 expense and $400
liability repayment are stored as +1000, +600, +400. They should be stored
internally as -1000, +600, +400 amounts, as per usual accounting equation.


I would nit-pick the assertion of 'usual accounting equation'. I've only 
seen one form of it, in any reference, and short of any further 
'factoring' it looks like this:


Assets = Liabilities + (Income - Expenses) + Equity

ALL of those terms are positive and a single operand is negative.


But somewhere along the way, someone decided to implement this instead:

Assets + (-Liabilities) + (-Income) + Expenses + (-Equity) = 0

Where the credit accounts are moved to the left and preference signed.

There would be no need for this conundrum with the budget or other parts 
of the UI, if the real equation were to be implemented.


But I digress, because I know that won't be changed.


The internal numbers assume the reversal pref is "Credit Accounts". This
means the budgets are currently functioning well *only* if reversal
preference is set to credit-accounts

A obligatory one-time fix is suggested and applied on the master branch,
applying some heuristics and negating the numbers, and will render the
datafile unreadable on GnuCash prior to 3.7. It is *not* an option to make
the one-time fix optional, because this will mean maintaining two code
paths in perpetuity. However I'm not sure if it is debugged enough.

I'd like to ask experienced users to test from the master branch, either as
win32 nightlies https://code.gnucash.org/builds/win32/master/ (4-jan-2022
onwards) or building on linux, and report back of the new budget is *less*
buggy than in 4.x maint series. Please do NOT test master on your
production datafile.

If there are unsolvable bugs, then I'll suggest that the one-time fix
change must be undone, and someone else may decide to try again.


What's the time frame?

I'm about to finish my 2022 budget, I can compare 4.9 to 5.x

Regards,
Adrien

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

Re: [GNC-dev] Omit zero balance figures Vs Show zero balances

[Adrien Monteleone]

I could be mistaken as to your question, but you can include accounts 
with zero balances, but not show the actual zeros.


This allows you to not show zeros for 'header' accounts in your tree. 
(even if they aren't set as technical placeholders)


Omit Zero Balance Figures + Include Accounts with Zero Total Balances 
allows for this.


I think most of my reports are setup this way.

I agree, some re-wording of the preferences might help here, but not 
certain what that should be.


Regards,
Adrien

On 11/22/21 7:29 PM, flywire wrote:

Display options are selected to display something except for Omit zero
balance figures. Why is it any different to Include accounts with zero
total balances ie select to display?



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

Re: [GNC-dev] gnucash-devel Digest, Vol 216, Issue 18

[Adrien Monteleone]

One slipped by I see.

Regards,
Adrien

On 3/30/21 8:32 PM, Scott Morgan wrote:

snip...


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

Re: [GNC-dev] DTD for gnucash

[Adrien Monteleone]

Regards,
Adrien

On 3/10/21 7:26 AM, Mark Lautman wrote:

Two items:

a) The subdomain wiki.gnucash.org isn't responding. Is it live?
As per the MAINT announcement, it was probably down for a spell due to a 
temporarily severed cable.


b) Regarding the gnucash data file:

  i) It is a gzipped XML file. Is a DTD available for that file?


I don't know, but you can also un-zip it simply enough. (I've never had 
much trouble deciphering it) Maybe the Wiki has something for you now 
that it is back up.


Regards,
Adrien

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

Re: [GNC-dev] Toolbar Style

[Adrien Monteleone]

You probably can't do so, but you might be able to specify with a CSS 
file, the individual changes that would accomplish the same result. This 
of course means figuring out the differences between the two toolbar 
styles and what nodes/classes/ids/etc. to target. Again, you might not 
get 100% of the way there, but you might get close.


Regards,
Adrien

On 3/10/21 11:59 AM, Taull Boi wrote:

I can use GTKInspector to change properties of the toolbar.

GtkToolbar -- DefaultToolbar

Properties:
toolbar-style: GTK_TOOLBAR_TEXT

For example, setting the toolbar-style property above changes the toolbar.
However, I don't see how this can be accomplished via GTK's CSS.



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

Re: [GNC-dev] Toolbar Style

[Adrien Monteleone]

Have you investigated trying to make changes via CSS? (you'll need to 
employ the GTKInspector to find the right nodes/classes/etc.)


Regards,
Adrien

On 3/8/21 10:41 AM, Taull Boi wrote:

Bob,

Thanks for the clarification. If I understand correctly, as a result of
this change in gtk3, currently gnucash does not support
changing/configuring the toolbar icon size and style in gnucash. If so,
would there be interest in supporting such functionality?

Also, I understand that GtkSettings:gtk-toolbar-style has been deprecated,
but what does it mean for it to be ignored?


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

Re: [GNC-dev] Book advertised on help manual online

[Adrien Monteleone]

I'll add: perhaps leave the link up as it is still a somewhat useful 
resource, and if the publisher/author contact falls through, or they are 
not interested in an updated edition, a message can be added to the 
website 'seeking' a talented technical author to write a new book?


Someone on the list mentioned doing video tutorials some time ago.

Perhaps if there were an official YouTube (or other) channel as part of 
the Documentation, volunteers could craft and submit tutorials. I do 
understand that is an entirely different project, and of course, is not 
without moderation and maintenance work. The videos could also be hosted 
on gnucash.org instead. (not sure of the current infrastructure and if 
the present site code is friendly to such an addition)


Regards,
Adrien

On 1/12/21 11:03 AM, Adrien Monteleone wrote:
I don't have a copy of the book, but most usually have a way to contact 
the author, and if not directly, then contacting the publisher would be 
the way to go.


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

Re: [GNC-dev] Book advertised on help manual online

[Adrien Monteleone]

I don't have a copy of the book, but most usually have a way to contact 
the author, and if not directly, then contacting the publisher would be 
the way to go.


Regards,
Adrien

On 1/12/21 1:31 AM, David Cousens wrote:

Liz,

The book is available from booksellers like Booktopia online as well as direct
from the publishers.

Does anyone know Ashok Ramachandran or know how to contact him? For example he
might be interested inproducing an updated edition for GnuCash 4.x for example?

A new version could be written from scratch but it would probably make more
sense to update the original. An Ashok Ramachandran (Australian citizen) was
recently appointed CEO of Schindler India. I don't know if he is the same person
however.


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

Re: [GNC-dev] Nice Job All!

[Adrien Monteleone]

Is this what you are looking for?

https://wiki.gnucash.org/wiki/images/8/86/Gnucash_erd.png

And there is also this: https://wiki.gnucash.org/wiki/SQL

Regards,
Adrien

On 1/7/21 6:30 PM, Scott Morgan wrote:

Ok, thanks for the clarification.   If SQL is the main model format where
is the best place to look for docs on the SQL schema ?   I don't even seem
to be able to get see the XML correctly, I will log this as a bug (perhaps
the older 3.11 version [on an old mac 10.10.5])  ie;

cat 2020-01-07.gnucash.xml.gnucash


4???p?~???'??M??f??

I'm digging in the bug list, but is this known to anyone?


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

Re: [GNC-dev] [GNC] Tabs Behaviors in GNC4.1

[Adrien Monteleone]

On 9/21/20 11:15 AM, John Ralls wrote:

Adrien,

You might prefer gnucash-patches. gnucash-changes includes the code diff while 
gnucash-patches has just the commit message. Both link to the commit on GitHub 
so if you feel a need to look at a patch it's only a click away.


Thanks, I'll check that out as well, though the diffs don't bother me. I 
have only used the tool sparingly so far and want to learn how to read 
the results more fluently. I could be wrong, but I'm going to hazard the 
guess that following the diffs will prompt me to start learning the code 
base and get in the habit of pulling up those sections to examine them. 
I find it is one thing to try to read existing code, but quite another 
to see how developers make changes to it.




Like gnucash-announce those are send-only lists. They don't accept posts from 
subscribers. If you want to comment on a commit you'll need a GitHub account.


Certainly, I thought that might be why Gmane wasn't carrying them, but 
then they carry -announce which is also send-only. I'm already on GitHub 
but other than one-off issues I've reported or followed here or there 
for other various projects I'm not a daily user. That needs to change.



Those lists reflect only commits to the repositories. You'll have to monitor 
https://github.com/Gnucash/gnucash/pulls to keep up with work in progress. 
Github publishes an RSS feed on the page.


There's the ticket, I think I'll switch to that method, thanks again!

Regards,
Adrien

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

Re: [GNC-dev] [GNC] Tabs Behaviors in GNC4.1

[Adrien Monteleone]

Thanks Christopher, I didn't know that list existed.

Note to anyone using Gmane, it is not offered there, so regular mail 
client only. (at least for now)


Regards,
Adrien

On 9/18/20 6:05 AM, Christopher Lam wrote:

A small note about code progress (and occasional regressions). Development
takes place mainly via github and IRC; I'd wager most subscribers to devel
*will* have enough understanding to understand the ongoing discussions and
changes. Even if they have little coding skills, the commit messages will
almost always contain adequate detail regarding changes. Commit messages
are generated and distributed live to any subscriber at
https://lists.gnucash.org/mailman/listinfo/gnucash-changes


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

Re: [GNC-dev] "Mortgage Repayment Druid"

[Adrien Monteleone]

I've seen several threads over the years that a user wanted to make an 
SX based on the current account balance. I'm glad to see the code 
exists, and hope to see it finally included.


I'll make my way through that PR discussion and chime in once I have a 
grasp of the nuances, but for now, I'd say this will also be very useful 
for envelope budgeting. This was my first hangup trying to implement it.


I've also seen a use case of someone calculating their charitable 
donations based on the balance of some accounts at a certain point in 
time, so grabbing that automatically would be nice.


This might turn out to be 'build it and they will come' sort of code. 
People may find uses for it that aren't anticipated yet.


Regards,
Adrien

On 9/16/20 12:08 PM, Jean Laroche wrote:
Note that there is a pull request that adds the ability to use the 
current balance of an account in a scheduled transaction.

https://github.com/Gnucash/gnucash/pull/682

This allows setting up a scheduled transaction for your mortgage payment 
that's smart enough to compute the interest owned based on the current 
balance of the mortgage account. So for example, if you make an extra 
payment, the scheduled transactions created by the current "Mortgage & 
Loan Repayment Assistant" will all be off. But if you setup your 
schedule transaction to use the current balance to compute the interest 
owned, the correct interest will be calculated no matter your 
prepayments etc.


That pull request has been sitting on the list since April, as the 
powers that be don't seem to think it's a priority or even a good idea 
to merge it into maint or master. Check it out, and voice your interest 
if you think that would be useful to you.


Jean


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

Re: [GNC-dev] Saving searches

[Adrien Monteleone]

The feature has been requested a few times on the user list that I recall.

Usually the need is solved with a different approach.

For example if the desired result is purely informational, a saved report is an 
option.

A recent thread concerned finding a particular subset of transactions, but the 
user didn’t know which account they were in, so they were running the search 
repeatedly by trial and error. Running the report from the Accounts tab (a 
global Find) did the trick.

I’ve seen a few cases of searches being done to refactor accounts and I 
personally can see saving the search to be useful when you have lots of 
transactions to change. I’ve done some work like this in batches and it would 
have been nice to just pull up the saved search when coming back to said work 
after said time. But it isn’t terrible for me to just redo the search from 
scratch. (not sure the re-assignment could be automated though in my case)

Not sure if any of that sheds light on your case. If you have to repeatedly 
refactor transactions from Imbalance to the same other account (thus needing to 
save the search) I’d instead ponder why those transactions that would be found 
by this search keep ending up in Imbalance in the first place. This is usually 
an error situation, either during manual entry (easily solvable individually) 
or from an import. (so the import process should either be improved, or the 
user missed an important step to avoid the Imbalance)

Regards,
Adrien

> On Jul 7, 2020 w28d189, at 12:38 AM, c.holterm...@gmx.de wrote:
> 
> Hello,
> 
> on some occasions I have wondered if it makes sense to save searches.
> Just now I am thinking of filtering certain transactions to
> automatically assign the imbalanced split to an account using the python
> bindings. That would be easier if I could use a saved search for that.
> Have there been thoughts about saving searches?
> 
> regards,
> 
> Christoph Holtermann

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

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

[Adrien Monteleone]

Note: a typo in line 5

*glyphs* not ‘glyths’

Regards,
Adrien


> On Jun 25, 2020 w26d177, at 3:21 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> I think for now we should disable it for MacOS until a solution presents 
> itself, maybe I will get a Macbook so I can test this.
> John, is this right...
> void
> gnc_assoc_cell_set_use_glyphs (AssocCell *cell)
> {
> #ifdef MAC_INTEGRATION
> cell->use_glyths = FALSE;
> #else 
> gboolean use_glyphs = TRUE;
> gchar *test_text;
> GtkWidget *label;
> PangoLayout *test_layout;
> gint count;
> 
> g_return_if_fail (cell != NULL);
> 
> label = gtk_label_new (NULL);
> test_text = g_strconcat (GLYPH_LINK, ",", GLYPH_PAPERCLIP, NULL);
> test_layout = gtk_widget_create_pango_layout (GTK_WIDGET (label), 
> test_text);
> 
> pango_layout_set_text (test_layout, test_text, strlen (test_text));
> 
> count = pango_layout_get_unknown_glyphs_count (test_layout);
> 
> if (count != 0)
> use_glyphs = FALSE;
> 
> g_object_unref (test_layout);
> g_free (test_text);
> 
> cell->use_glyphs = use_glyphs;
> #endif
> }
> 


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

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

[Adrien Monteleone]

Bob,

I tried, that is in one of my replies below.

It takes up space, but it doesn’t appear visually. (so like a space character 
the width of the glyph) I even tried using the GTKInspector and setting the 
entire UI to use Apple Color Emoji as a font and they still appeared as spaces.

Regards,
Adrien

> On Jun 25, 2020 w26d177, at 3:23 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> Adrian, maybe for a start one could just try and see if you can paste those 
> unicodes or some other into the notes/memo fields, that is how I started and 
> when it worked I thought about using them.
> 
> Regards,
> Bob
> 


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

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

[Adrien Monteleone]

I’d be happy to play with the CSS, but I don’t see a way to target that cell. 
All I get are the sheet and the entry cell.

Regards,
Adrien

> On Jun 24, 2020 w26d176, at 8:05 PM, John Ralls  wrote:
> 
> Font handling in Gtk on MacOS is weird: Pango only calculates the layout for 
> computing box sizes. The actual glyph selection and layout is handled by 
> Cairo, and I don't think it knows how to use CoreText's font substitution. 
> WebKitGtk complicates matters by requiring the FreeType2 Pango backend as 
> well and that does its own font substitution. Regardless, pango is finding 
> the emojis so the test passes. Cairo isn't putting a missing glyph glyph 
> there like I'd expect. I haven't yet figured out why not.
> 
> I can think of two avenues to try: Simply forcing have_glyphs to false on 
> MacOS would display the regular letters. Not as pretty but it's sure to work. 
> A bit more difficult and in need of testing would be to use CSS to set the 
> font family for the Association cell to Apple Color Emojis on MacOS.
> 
> Regards,
> John Ralls


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

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

[Adrien Monteleone]

Sorry, I forgot to report back that after looking over the entire unicode 
table, I can’t find anything suitable as replacement glyphs. (at least not 
without a specialized typeface, which GnuCash would have to package)

So on Mac at least, we lose the ability to see there is an attachment or 
location association.

Regards,
Adrien

> On Jun 24, 2020 w26d176, at 12:03 PM, Adrien Monteleone 
>  wrote:
> 
> I tried pasting them into a Notes field, they take up space, but do not 
> display.
> 
> I fired up the GTKInspector to see if I could find a clue —no dice. CSS has 
> no effect, and it is near impossible to target anything besides the register 
> sheet as a whole, or the entry field. (and one can’t edit the attachment cell 
> to focus it) I even tried changing the font to Apple Color Emoji and it still 
> didn’t display.
> 
> So this might be a GTK-Mac emoji issue. (I can’t paste any emojis in, same 
> result) Or if others on Mac can use and see emoji, then something is wrong 
> with my setup.
> 
> But this failure to display also means the fall-back can’t be seen. GnuCash 
> thinks it doesn’t need to fall-back, and puts the glyph there, but it shows 
> up as simply a space and is invisible.
> 
> Regards,
> Adrien
> 
> 
>> On Jun 24, 2020 w26d176, at 10:57 AM, Robert Fewell <14ubo...@gmail.com> 
>> wrote:
>> 
>> I tested this on a couple of Linux boxes and also on Windows and had no 
>> trouble so maybe it is a Mac issue. Unfortunately I do not presently have 
>> one so I do not know, maybe John might have an idea, the only ideas I have 
>> is to set different code points for a paperclip and links for Mac's, disable 
>> it for Macs or maybe change the test.
>> 
>> Adrien do you have likely candidates for those?
>> 
>> On Wed, 24 Jun 2020 at 16:28, Adrien Monteleone 
>>  wrote:
>> Those glyphs only show up for me in Character Viewer as ‘Apple Color Emoji’. 
>> (thus not part of any regular typeface) Not sure how to get that included in 
>> GnuCash if it isn’t there by default. Certainly, I don’t want to change my 
>> default font to all emojis.
>> 
>> But that doesn’t explain the lack of fall back ‘f’ and ‘w’.
>> 
>> I had a custom CSS file for colors and font sizes, so I pulled that and 
>> still the fall backs are not there.
>> 
>> Regards,
>> Adrien
>> 
>>> On Jun 24, 2020 w26d176, at 7:38 AM, Robert Fewell <14ubo...@gmail.com> 
>>> wrote:
>>> 
>>> Adrien,
>>> That is a bot surprising, there is a test for the glyphs in the font and if 
>>> not present should default to 'f' and 'w', code points are..
>>> #define GLYPH_PAPERCLIP "\360\237\223\216" // Codepoint U+1F4CE
>>> #define GLYPH_LINK  "\360\237\224\227" // Codepoint U+1F517
>>> 
>>> 
>>> Regards,
>>> Bob
> 


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

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

[Adrien Monteleone]

I tried pasting them into a Notes field, they take up space, but do not display.

I fired up the GTKInspector to see if I could find a clue —no dice. CSS has no 
effect, and it is near impossible to target anything besides the register sheet 
as a whole, or the entry field. (and one can’t edit the attachment cell to 
focus it) I even tried changing the font to Apple Color Emoji and it still 
didn’t display.

So this might be a GTK-Mac emoji issue. (I can’t paste any emojis in, same 
result) Or if others on Mac can use and see emoji, then something is wrong with 
my setup.

But this failure to display also means the fall-back can’t be seen. GnuCash 
thinks it doesn’t need to fall-back, and puts the glyph there, but it shows up 
as simply a space and is invisible.

Regards,
Adrien


> On Jun 24, 2020 w26d176, at 10:57 AM, Robert Fewell <14ubo...@gmail.com> 
> wrote:
> 
> I tested this on a couple of Linux boxes and also on Windows and had no 
> trouble so maybe it is a Mac issue. Unfortunately I do not presently have one 
> so I do not know, maybe John might have an idea, the only ideas I have is to 
> set different code points for a paperclip and links for Mac's, disable it for 
> Macs or maybe change the test.
> 
> Adrien do you have likely candidates for those?
> 
> On Wed, 24 Jun 2020 at 16:28, Adrien Monteleone 
>  wrote:
> Those glyphs only show up for me in Character Viewer as ‘Apple Color Emoji’. 
> (thus not part of any regular typeface) Not sure how to get that included in 
> GnuCash if it isn’t there by default. Certainly, I don’t want to change my 
> default font to all emojis.
> 
> But that doesn’t explain the lack of fall back ‘f’ and ‘w’.
> 
> I had a custom CSS file for colors and font sizes, so I pulled that and still 
> the fall backs are not there.
> 
> Regards,
> Adrien
> 
> > On Jun 24, 2020 w26d176, at 7:38 AM, Robert Fewell <14ubo...@gmail.com> 
> > wrote:
> > 
> > Adrien,
> > That is a bot surprising, there is a test for the glyphs in the font and if 
> > not present should default to 'f' and 'w', code points are..
> > #define GLYPH_PAPERCLIP "\360\237\223\216" // Codepoint U+1F4CE
> > #define GLYPH_LINK  "\360\237\224\227" // Codepoint U+1F517
> > 
> > 
> > Regards,
> > Bob


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

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

[Adrien Monteleone]

I found it to be trivial to expand the columns again from 0px. Though if you’ve 
collapsed multiple adjacent columns, you have to un-collapse them in reverse 
order.

I guess since the layout is shared, it makes sense there could be other issues 
if 0px were allowed.

Regards,
Adrien

> On Jun 24, 2020 w26d176, at 10:43 AM, Robert Fewell <14ubo...@gmail.com> 
> wrote:
> 
> The kludge is not practical as there are some hidden columns at 0px as the 
> layout is shared between invoices and bills and one would not know on save 
> which columns should really be at 0px or changed to 1px.
> 
> I think the only real option is to not allow dragging columns to zero, not 
> really sure why it is at least this would also allow you to drag the column 
> width back should it be required.
> 
> Bob


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

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

[Adrien Monteleone]

Those glyphs only show up for me in Character Viewer as ‘Apple Color Emoji’. 
(thus not part of any regular typeface) Not sure how to get that included in 
GnuCash if it isn’t there by default. Certainly, I don’t want to change my 
default font to all emojis.

But that doesn’t explain the lack of fall back ‘f’ and ‘w’.

I had a custom CSS file for colors and font sizes, so I pulled that and still 
the fall backs are not there.

Regards,
Adrien

> On Jun 24, 2020 w26d176, at 7:38 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> Adrien,
> That is a bot surprising, there is a test for the glyphs in the font and if 
> not present should default to 'f' and 'w', code points are..
> #define GLYPH_PAPERCLIP "\360\237\223\216" // Codepoint U+1F4CE
> #define GLYPH_LINK  "\360\237\224\227" // Codepoint U+1F517
> 
> 
> Regards,
> Bob


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

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

[Adrien Monteleone]

I guess that is what I managed to do. I'm interpreting ‘0px’ to mean the 
dividers merge/overlap so you only see a single-width divider. That it seems 
doesn’t get saved, but it is easier to accomplish dexterity-wise without having 
to carefully hit a fine-tuned target. (I’m using a touch pad, not sure if this 
is easier or harder with a mouse)

Regards,
Adrien

> On Jun 24, 2020 w26d176, at 9:56 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> It may be possible to save the column widths as 1px when the columns are 
> dragged on screen to zero px.
> 
> Regards,
> Bob
> 


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

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

[Adrien Monteleone]

Bob,

Thanks, that was the ticket.

I very carefully set them to 1px (column dividers still visible as a now 
thicker line) which is rather tricky.

The layout was retained.

Apparently, the columns that were getting reset on me had been reduced to zero.

So I guess this is working as intended (or allowed by code restraints) but I 
can’t say it is intuitive and I suspect something in the wiki and documentation 
(if not already there, my apologies if it is) would be in order.

Regards,
Adrien

> On Jun 24, 2020 w26d176, at 9:46 AM, Adrien Monteleone 
>  wrote:
> 
> Funny enough, they were 1 or 2px.
> 
> In my re-test after using the reset option, I made sure to be careful to 
> bring them to zero. Those widths weren’t retained at all.
> 
> I’ll try again to carefully set them all to very small and see what happens.
> 
> Regards,
> 
> 
>> On Jun 24, 2020 w26d176, at 9:44 AM, Robert Fewell <14ubo...@gmail.com> 
>> wrote:
>> 
>> I think that is the problem, reduce those columns but make sure the columns 
>> are at least one pixel. I do not think they can be zero.
>> 
>> Bob
>> 


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

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

[Adrien Monteleone]

Funny enough, they were 1 or 2px.

In my re-test after using the reset option, I made sure to be careful to bring 
them to zero. Those widths weren’t retained at all.

I’ll try again to carefully set them all to very small and see what happens.

Regards,


> On Jun 24, 2020 w26d176, at 9:44 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> I think that is the problem, reduce those columns but make sure the columns 
> are at least one pixel. I do not think they can be zero.
> 
> Bob
> 
> On Wed, 24 Jun 2020 at 15:41, Adrien Monteleone 
>  wrote:
> Thanks I’ll check for that glyph.
> 
> Concerning the layout, I used that option then opened other bills from a 
> Vendor Report, as well as the same bill.
> 
> I just changed them again and used the menu entry again, and this time did a 
> Find.
> 
> Now (check my reply to Geert) only ’Taxable?’ and ‘Billable?’ come back to 
> default sizes. (and stay that way regardless of how I pull up that or other 
> bills)
> 
> Regards,
> Adrien
> 
> > On Jun 24, 2020 w26d176, at 7:38 AM, Robert Fewell <14ubo...@gmail.com> 
> > wrote:
> > 
> > Adrien,
> > That is a bot surprising, there is a test for the glyphs in the font and if 
> > not present should default to 'f' and 'w', code points are..
> > #define GLYPH_PAPERCLIP "\360\237\223\216" // Codepoint U+1F4CE
> > #define GLYPH_LINK  "\360\237\224\227" // Codepoint U+1F517
> > 
> > Regarding the second point, 
> > Once you set the columns for the vendor bill, I presume you then used the 
> > menu option "Windows->Use as Default for Vendor Documents" which should 
> > save the layout.
> > Closed the Bill, did a find for a bill and hopefully the layout is the same.
> > 
> > Note the 'Windows' option will probably move to 'View' for 4.0
> > 
> > Regards,
> > Bob
> > 
> > 
> > On Wed, 24 Jun 2020 at 08:43, Adrien Monteleone 
> >  wrote:
> > Is there a trick to this?
> > 
> > I just set a layout on a Vendor bill, then clicked the menu entry.
> > 
> > I closed the bill and opened a different one from the same vendor. The 
> > layout was not the one I saved.
> > 
> > I then re-opened the original bill and it too did not return with the saved 
> > layout.
> > 
> > 3.906 on MacOS 10.15.5
> > 
> > Regards,
> > Adrien
> > 
> > p.s. - better to keep the announcement thread title or change it per issue? 
> > (not sure of the protocol on this for testing releases)
> > 
> > > Add option to save Layout for Business items
> > > Add two menu items under windows, one to save an existing layout for 
> > > Invoices, Bills and Vouchers to their respective default layouts so the 
> > > user set column widths will be used. The second menu item will reset the 
> > > column widths to defaults and remove the default layout. Open Business 
> > > items will also save their column widths to the page section so these can 
> > > temporarily have different widths.


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

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

[Adrien Monteleone]

I just decided to test using the ‘Reset’ option then re-opened some bills to 
test that it was indeed reset, then I reset my layout and made it default again.

Now, every subsequent bill I open is back to default column widths and my 
layout isn’t saved at all.

Regards,
Adrien

> On Jun 24, 2020 w26d176, at 7:36 AM, Geert Janssens 
>  wrote:
> 
> That should do it...
>  
> I just tested on my Fedora 31 box and after following your steps the new bill 
> opens with the new layout (I do run current master rather than 3.906 but I 
> don't think any changes were made in that area between these two).
>  
> What changes did you make exactly to the layout ?
>  
> Regards,
>  
> Geert
>  
> Op woensdag 24 juni 2020 09:42:46 CEST schreef Adrien Monteleone:
> > Is there a trick to this?
> > 
> > I just set a layout on a Vendor bill, then clicked the menu entry.
> > 
> > I closed the bill and opened a different one from the same vendor. The
> > layout was not the one I saved.
> > 
> > I then re-opened the original bill and it too did not return with the saved
> > layout.
> > 
> > 3.906 on MacOS 10.15.5
> > 
> > Regards,
> > Adrien
> > 
> > p.s. - better to keep the announcement thread title or change it per issue?
> > (not sure of the protocol on this for testing releases)
> > > Add option to save Layout for Business items
> > > Add two menu items under windows, one to save an existing layout for
> > > Invoices, Bills and Vouchers to their respective default layouts so the
> > > user set column widths will be used. The second menu item will reset the
> > > column widths to defaults and remove the default layout. Open Business
> > > items will also save their column widths to the page section so these can
> > > temporarily have different widths.


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

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

[Adrien Monteleone]

Thanks I’ll check for that glyph.

Concerning the layout, I used that option then opened other bills from a Vendor 
Report, as well as the same bill.

I just changed them again and used the menu entry again, and this time did a 
Find.

Now (check my reply to Geert) only ’Taxable?’ and ‘Billable?’ come back to 
default sizes. (and stay that way regardless of how I pull up that or other 
bills)

Regards,
Adrien

> On Jun 24, 2020 w26d176, at 7:38 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> Adrien,
> That is a bot surprising, there is a test for the glyphs in the font and if 
> not present should default to 'f' and 'w', code points are..
> #define GLYPH_PAPERCLIP "\360\237\223\216" // Codepoint U+1F4CE
> #define GLYPH_LINK  "\360\237\224\227" // Codepoint U+1F517
> 
> Regarding the second point, 
> Once you set the columns for the vendor bill, I presume you then used the 
> menu option "Windows->Use as Default for Vendor Documents" which should save 
> the layout.
> Closed the Bill, did a find for a bill and hopefully the layout is the same.
> 
> Note the 'Windows' option will probably move to 'View' for 4.0
> 
> Regards,
> Bob
> 
> 
> On Wed, 24 Jun 2020 at 08:43, Adrien Monteleone 
>  wrote:
> Is there a trick to this?
> 
> I just set a layout on a Vendor bill, then clicked the menu entry.
> 
> I closed the bill and opened a different one from the same vendor. The layout 
> was not the one I saved.
> 
> I then re-opened the original bill and it too did not return with the saved 
> layout.
> 
> 3.906 on MacOS 10.15.5
> 
> Regards,
> Adrien
> 
> p.s. - better to keep the announcement thread title or change it per issue? 
> (not sure of the protocol on this for testing releases)
> 
> > Add option to save Layout for Business items
> > Add two menu items under windows, one to save an existing layout for 
> > Invoices, Bills and Vouchers to their respective default layouts so the 
> > user set column widths will be used. The second menu item will reset the 
> > column widths to defaults and remove the default layout. Open Business 
> > items will also save their column widths to the page section so these can 
> > temporarily have different widths.


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

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

[Adrien Monteleone]

I reduced ‘Invoiced?’, ‘Billable?' and all three tax columns to zero then 
expanded ‘Expense Account’ and snapped ‘Description’ to balance.

After re-opening, the three tax columns and ‘Billable?’ come back as default 
sizes and Description shrinks accordingly.

Is there a way to choose visible columns like on a printable invoice rather 
than shrinking them to 1px/zero manually?

Regards,
Adrien

 
> On Jun 24, 2020 w26d176, at 7:36 AM, Geert Janssens 
>  wrote:
> 
> That should do it...
>  
> I just tested on my Fedora 31 box and after following your steps the new bill 
> opens with the new layout (I do run current master rather than 3.906 but I 
> don't think any changes were made in that area between these two).
>  
> What changes did you make exactly to the layout ?
>  
> Regards,
>  
> Geert
>  
> Op woensdag 24 juni 2020 09:42:46 CEST schreef Adrien Monteleone:
> > Is there a trick to this?
> > 
> > I just set a layout on a Vendor bill, then clicked the menu entry.
> > 
> > I closed the bill and opened a different one from the same vendor. The
> > layout was not the one I saved.
> > 
> > I then re-opened the original bill and it too did not return with the saved
> > layout.
> > 
> > 3.906 on MacOS 10.15.5
> > 
> > Regards,
> > Adrien
> > 
> > p.s. - better to keep the announcement thread title or change it per issue?
> > (not sure of the protocol on this for testing releases)
> > > Add option to save Layout for Business items
> > > Add two menu items under windows, one to save an existing layout for
> > > Invoices, Bills and Vouchers to their respective default layouts so the
> > > user set column widths will be used. The second menu item will reset the
> > > column widths to defaults and remove the default layout. Open Business
> > > items will also save their column widths to the page section so these can
> > > temporarily have different widths.


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

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

[Adrien Monteleone]

Is there a trick to this?

I just set a layout on a Vendor bill, then clicked the menu entry.

I closed the bill and opened a different one from the same vendor. The layout 
was not the one I saved.

I then re-opened the original bill and it too did not return with the saved 
layout.

3.906 on MacOS 10.15.5

Regards,
Adrien

p.s. - better to keep the announcement thread title or change it per issue? 
(not sure of the protocol on this for testing releases)

> Add option to save Layout for Business items
> Add two menu items under windows, one to save an existing layout for 
> Invoices, Bills and Vouchers to their respective default layouts so the user 
> set column widths will be used. The second menu item will reset the column 
> widths to defaults and remove the default layout. Open Business items will 
> also save their column widths to the page section so these can temporarily 
> have different widths.


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

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

[Adrien Monteleone]

Is there some documentation on the unicode point for this symbol?

I loaded 3.906, and the ‘f’ indicator went away and was replaced by nothing. 
(so I’m guess even the default font doesn’t have the symbol, which isn’t 
optimal.)

Regards,
Adrien

> 
> • A symbol is now displayed on transactions in the register when they have an 
> attachment and the selected font supports the symbol.


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

Re: [GNC-dev] gnucash 3.906-1 fails to launch on clicked icon

[Adrien Monteleone]

For future reference, you can do:

`cat $TMPDIR/gnucash.trace`

on 10.13 (High Sierra) and later, otherwise:

`find /var/folders -name gnucash.trace`

to get the path.

All of this per the wiki: https://wiki.gnucash.org/wiki/Tracefile

Regards,
Adrien





> On Jun 22, 2020 w26d174, at 2:22 PM, Jeff Earickson  
> wrote:
> 
> John,
> 
> "open Gnucash.app" via command-line gives the same error code 1 in
> system.log, nothing else happens.
> 
> I had to hunt for a gnucash.trace file by walking the root directory with
> find.  Finally found something in
> /System/Volumes/data/private/var/folders/(other stuff)/gnucash.trace.  I
> zeroed out the tile via "cat /dev/null > gnucash.trace" then started
> clicking and trying to open the app via command-line.  Not a single byte
> went to this file.  Just the errcode 1 to system.log.
> 
> Then I tried via the commond-line, running the executable:
> 
> cd /Applications/Gnucash/Gnucash.app/Contents/MacOS
> ./Gnucash --debug --extra --logto /tmp/gnucash.trace
> 
> The application opened up, wanted me to create a new account, I clicked
> thru the "next" buttons to do so, and then it crashed.  I realize this may
> be a different problem than the "fail to open" issue, but the latter
> problem refuses to cough up a tracefile anyplace.  See attached.
> 
> Thanks,
> Jeff Earickson


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

Re: [GNC-dev] Is there a way to do right-click on mac os???

[Adrien Monteleone]

I can do a real ‘right click’ with a mouse, and I can achieve the same with a 
two finger tap on my track pad.

But the keyboard version does not work. I suspect that is a GTK thing.

The best I can get with CTRL+click is the GTK input menu. (after the initial 
move to GTK3, that was all that was available, but this was fixed to restore 
the GC context menu)

Regards,
Adrien

> On May 18, 2020 w21d139, at 11:30 PM, jeanl  wrote:
> 
> Guys,
> I'm trying GC on macos, and I can't find a way to do a right click. Normally
> you do right click by Ctrl+click in mac os. But this does not work in GC.
> Is that an oversight? Is is just my setup? I'm on Catalina with the latest
> build.
> Jean.

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

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Adrien Monteleone]

> On Apr 28, 2020 w18d119, at 9:27 AM, Geert Janssens 
>  wrote:
> 
> What I take from all this is that as long as you display data in two columns 
> (a debit and a credit) you can follow the logic as you suggest.

Most likely, that’s what I thought at first too, but I suppose a notation like 
“Dr./Cr.” or “D/C” could be used instead, though it might be more visual 
clutter than two columns. Two columns might also be much easier to spot if 
balances are correct or contra for an account. (such as, "is the balance in the 
proper column?”)

Two columns might also be easier on translators than abbreviations/notations.

>  
> However numbers are not just meant for displaying, one needs to do 
> calculations on them as well. And at that point signs will matter. Whether a 
> certain number increase or decrease your balance is a matter of sign.

Not necessarily. 

If the equation is treated in code as:

Assets = Liabilities + Equity

then those values are all positive. You don’t test for zero, you test for 
equality between left and right. (I don’t know if that is more computationally 
expensive or not. I’m not as up to par as I should be on modern processor 
instructions and what is available.) My conception is the value of each side 
would be stored, you then do a <,>,=,!= test. (whichever seems saner in code 
and is faster)

The idea is also that each account would keep debit and credit balances. (just 
like in the ’T’ accounts) The overall account balance is the absolute value of 
the difference. (still no negative numbers, but a subtraction with two 
positives, and the result being positive)

Whether the balance is represented as Debit or Credit is done by an additional 
check for which term was greater before the difference was taken.

This would happen probably everywhere. (individual transactions, integrity 
checks, reports, budgets)

Again, I don’t know if such logic is more expensive computationally. But it 
does model traditional accounting better and removes the need for signs 
presentationally, and computationally.

The only place I might think signs would be appropriate in this case would be 
in reports that show variances. (an increase or decrease in absolute value, 
without regard to debit or credit) For example, if a Balance Sheet comparison 
report (doesn’t exist yet) showed liabilities increased, both numbers would be 
positive, as would the variance. If liabilities decreased, both would be 
positive with a negative variance. The same would hold for a multi-period 
income statement with a variance column (doesn’t exist yet) or the current 
budget report, or transaction comparison report. (still not-official I think)

Just a few thoughts...

Regards,
Adrien
> So regardless of how you interpret the equations at some point it all boils 
> down to dry maths. The exact internal representation is less important as 
> long as it's consistent.
>  
> How to display this internal representation to the user is mostly a matter of 
> taste. And clearly various opinions on that exist based on user's background 
> and experience.
>  
> > I’m sure there was a reasonable basis for the decision decades ago to employ
> > the equation in this form, I question whether the reasoning still holds and
> > posit that it might have produced more work and effort than it has saved,
> > or will. (not just for developers, but for the many users as well) I don’t
> > know if this reasoning ever made it into any sort of documentation or code
> > comments. (I admit, I haven’t looked –yet)
> > 
> > I understand that saying such a change would be ‘major’ is a gross
> > understatement.
> > 
> :)
>  
> > I’ll keep testing the beta build(s) and reporting anything that appears
> > inconsistent with sign treatment, or incorrect with the basic math results.
> 
> Great, thanks for that!
>  
> Geert


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

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Adrien Monteleone]

Geert,

I concur.

As long as the internals treat the equation as set to equal zero, then signage 
is necessary and it should be consistent. I appreciate the efforts being made 
to achieve this.

My (pie in the sky) request for consideration is the idea that such a treatment 
of the equation is inconsistent with accounting texts and practice (as best I 
can tell) and should one day be changed so that GnuCash more closely follows 
how accountancy treats the equation. This would eliminate issues with signage 
as there wouldn’t be any. All ‘normal’ values (unless contra-balanced) would be 
positive. (and even then, signage would still be a display consideration that 
is based on a choice to not present the balance as either a debit or credit, 
but with a sign)

The equation is:

Assets = Liabilities + Equity

It is *not*:

Assets - Liabilities - Equity = 0

I’m sure there was a reasonable basis for the decision decades ago to employ 
the equation in this form, I question whether the reasoning still holds and 
posit that it might have produced more work and effort than it has saved, or 
will. (not just for developers, but for the many users as well) I don’t know if 
this reasoning ever made it into any sort of documentation or code comments. (I 
admit, I haven’t looked –yet)

I understand that saying such a change would be ‘major’ is a gross 
understatement.

I’ll keep testing the beta build(s) and reporting anything that appears 
inconsistent with sign treatment, or incorrect with the basic math results.

Regards,
Adrien

> On Apr 28, 2020 w18d119, at 8:18 AM, Geert Janssens 
>  wrote:
> 
> My simplistic view on this: if there is going to be confusion anyway, let's 
> at least make it consistent.
>  
> We have the sign reversal strategies in there to alter gnucash number 
> presentation behavior. To me it would make sense this affects normal 
> transactions the same way as it would reports as it would budgetting.
>  
> That's currently not the case, which means users have to keep two mental 
> models in their head: one for transactions (is liability interpreted such or 
> so, and so on) and another for budgets. I personally think that's a big 
> hurdle.
>  
> Keep in mind that these reversal strategies (should) only be relevant for the 
> display of information. Internally numbers should always be stored according 
> to the signs in the accounting equation. Again budget values didn't follow 
> this rules. So besides being inconsistent to users it is also inconsistent 
> and confusing to developers.
>  
> That's what prompted the work to bring this all in line.
>  
> No doubt this may change the interpretation of certain numbers. We can't 
> avoid this completely. What we had was inconsistent and created 
> interpretations based on the inconsistent behavior. Change that and the 
> interpretation has to change with it.
>  
> Regards,
>  
> Geert

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

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Adrien Monteleone]

I do some testing this evening.

Regards,
Adrien

> On Apr 27, 2020 w18d118, at 3:51 PM, Christopher Lam 
>  wrote:
> 
> Labelling issues aside, is there anyone who would be willing to beta test?
> 


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

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Adrien Monteleone]

Thanks Phil, so I’m not completely insane then.

I too try to remember to factor in signs because GnuCash works that way. I was 
just throwing in my 2¢ for taking a step back for perspective that maybe can be 
considered in a future release. (5.0 maybe?)

As for danger in generating confusion, the app already throws people at least 
in the middle of the pool of accounting. Being consistent with accounting text 
resources might reduce confusion. (in my humble opinion) If texts don’t refer 
to credit accounts as ’normally negative’, or don’t address or present ’sign’ 
at all, then people learning on their own would come to GnuCash and see a 
similar approach.

I presently have my reversed balance accounts setting to ‘Credit accounts’ 
because that way, negative values tell me I have a contra-account balance. 
Short of seeing the balance as Dr. or Cr., that’s the best I can get at the 
moment.

Christopher,

I’ll add a big ’Thank You’ for tackling this. I understand you have program 
constraints to work in and can’t re-build the house for the kitchen sink. Even 
if it isn't the optimum, if it is at least consistent and works properly, that 
is better than not.

Regards,
Adrien

> On Apr 27, 2020 w18d118, at 1:43 PM, Phil Longstaff 
>  wrote:
> 
> I agree with what you say about positive and negative with respect to
> budgeting assets and liabilities. However, if I have a transaction which
> pays down a loan, and then add that loan to the budget report, the actual
> value is displayed as negative. That is why I budget paying down a loan
> with a negative value.
> 
> I understand what you are saying about budget outlays always being
> positive. That also makes sense. However, it doesn't match what gnucash
> currently does.
> 
> Yes, it would be more straightforward to budget either a CR or a DB, and
> then "amount left to budget" would be sum(DB) - sum(CR). However, that
> would make it more confusing for non-accountants.


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

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Adrien Monteleone]

I noticed that odd as well. I also noticed it to be odd to choose ‘Inflow’ for 
anything but income.

However, I’m not sure the preface ‘Inflow from’ or ‘Outflow to’ should even be 
there. It produces too much confusion with signs.

Now I have to be concerned with interpreting the sign to be the opposite of the 
prefacing term chosen.

I might be an outlier, but when I budget outlays, I budget positive amounts. It 
doesn’t matter if I’m paying a debt or buying something or saving some. 
(liability vs. expense, or asset)

It makes no sense to me to say I’m ‘budgeting negative $100’ on a liability 
unless I was pulling money from a liability to make it available to budget. 
(thus taking out a loan, similar to pulling money out of savings for expenses 
or debt payments) I suppose I could use ‘Income/Expense’ instead of ‘Credit 
Accounts’ as my sign reversal strategy but then that messes with my use of 
signs for general accounting.

I see budgeting as a different context and I don’t think it should follow the 
same strict adherence to sign preferences. (maybe that is why it didn’t honor 
the setting in the first place)

The entire issue with signs has to do with someone who made the decision to 
re-write the accounting equation with all terms on one side and zero on the 
other. The real equation given in every text book I’ve seen is not presented 
that way. This is partly why a reversal setting exists. Traditional accounting 
doesn’t present credit accounts as negative amounts. Debits and Credits are 
specifically and strictly not taught as being ‘positive’ or ’negative’. I know 
that’s a bigger fish to fry and more fundamental to the core code, but it seems 
to be a stumbling block when the context of the amounts changes.

I could get over it and manage because I’ve been with GnuCash long enough. But 
a fresh new user might well run into an obstacle here. (and some already do 
with the general sign issue in the rest of the app)

Regards,
Adrien

> On Apr 27, 2020 w18d118, at 9:13 AM, Frank H. Ellenberger 
>  wrote:
> 
> Hi,
> 
> Am 27.04.20 um 06:08 schrieb Christopher Lam:
>> [image: budget-view.png]
> 
> as translator I have a problem with "Inflow to" in this context. I had
> only expected "Inflow from" and "Outflow to".
> 
> Frank

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

Re: [GNC-dev] About Experimental Reports

[Adrien Monteleone]

What happens to saved configs of old reports?

Does GC choke when you try to run one?

Is an error message generated?

If the reports are renamed (and maybe relocated) will this auto-map so the 
configs still work? Or will that just blow them up entirely anyway?

I’ll presume the configs won’t work on new reports since some options either 
won’t exist or have been changed.

I rarely run a default report except for testing or to see what a new user sees 
when they need help or someone thinks they found a bug. For my own use I have 
customized configs. (not so many I can’t re-create them, but it will be some 
effort to figure out how to re-create those reports with the new versions) I’m 
sure some users out there have extensive saved configs.

Regards,
Adrien

> On Apr 24, 2020 w17d115, at 10:08 PM, Christopher Lam 
>  wrote:
> 
> Dear Users
> 
> We hope the revamped reports have been useful and welcome to the community.
> 
> With 4.0 round the corner, it is time to consider replacing the old reports
> with the experimental ones.
> 
> Balance Sheet and Income Statement (Multicolumn) reports are now well
> tested, and can replace the previous ones; however not all options will or
> can survive the merge. This means most options will remain unchanged
> - accounts selection
> - target report currency (optional in new report)
> - some display options
> 
> and obsolete options ignored/renamed e.g.:
> - asset/liability/equity individual labels/totals
> - accounting style rules
> - too many subtotal options
> 
> Also the various business reports Customer/Employee/Vendor reports and
> Aging reports are now upgraded, and can supplant the old reports
> immediately. The newer reports do NOT need to specify an AP/AR account, and
> can show related business transactions.
> 
> The question is how to handle old reports: hide (behind a seldom-used
> --extras argument), rename, or remove altogether. Any preference?
> ___
> 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] Porting the Tutorial & Concepts Guide to ReadTheDocs.org

[Adrien Monteleone]

Thanks for the info and clarification.

Regards,
Adrien

> On Apr 25, 2020 w17d116, at 2:27 AM, Geert Janssens 
>  wrote:
> 
> Op zaterdag 25 april 2020 09:17:58 CEST schreef Geert Janssens:
>> Op zaterdag 25 april 2020 01:09:56 CEST schreef Adrien Monteleone:
>>> I’ve used some documentation from that source for several projects (as a
>>> user, not a documenter) and I have to say it is much more pleasant to read
>>> and navigate than the current GnuCash setup.
>>> 
>>> There was some discussion some time ago (I think there is a bug filed) for
>>> making documentation more accessible for editing. The current procedures
>>> are a bit of a hurdle, at least enough to result in few people tackling
>>> needed changes.
>>> 
>>> Thanks for this effort. Do I see correctly that I could jump in for
>>> editing
>>> via GitHub? I haven’t played with RST yet.
>> 
>> While ReadTheDocs does support it, it doesn't match with our current
>> tooling. The GitHub version of our documentation is just a clone of the
>> real source location: code.gnucash.org. So any changes on github will be
>> overwritten when a change is pushed to code.gnucash.org.
>> 
> Let me correct myself.
> 
> IIRC this edit feature works by generating a clone of the gnucash-docs repo 
> and after editing it 
> will guide you in making a pull request. That actually would work. The devs 
> would just not use 
> github's merge functionality.
> 
> Regards,
> 
> Geert

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

Re: [GNC-dev] Passwords are Confidential

[Adrien Monteleone]

You can turn off the reminder in your mailman settings.

As this is part of the mailman code, perhaps a bug report to them would be in 
order concerning the storage issue.

Regards,
Adrien

> On Apr 24, 2020 w17d115, at 11:29 PM, flywire  wrote:
> 
> My password is confidential so please don't email it to me in plain text.
> Don't even store it, instead encrypt what I entered and store that so you
> can verify an encrypted version of the password I enter in the future.

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

Re: [GNC-dev] Porting the Tutorial & Concepts Guide to ReadTheDocs.org

[Adrien Monteleone]

I’ve used some documentation from that source for several projects (as a user, 
not a documenter) and I have to say it is much more pleasant to read and 
navigate than the current GnuCash setup.

There was some discussion some time ago (I think there is a bug filed) for 
making documentation more accessible for editing. The current procedures are a 
bit of a hurdle, at least enough to result in few people tackling needed 
changes.

Thanks for this effort. Do I see correctly that I could jump in for editing via 
GitHub? I haven’t played with RST yet.

Regards,
Adrien

> On Apr 24, 2020 w17d115, at 5:13 PM, Rob Gowin  wrote:
> 
> Got the itch to play around with GnuCash’s documentation tooling, file 
> format, etc. I’m an AsciiDoc fan, but like the docs I read on ReadTheDocs.org 
> , which uses reStructuredText. 
> 
> So, got out ‘pandoc’ to convert the T Guide (English only) from DocBook  to 
> RST, did a little scripting and here is the result:
> 
> https://gnucash-docs-rst.readthedocs.io/en/latest/index.html 
> 
> 
> I’d say it’s appearance is a bit improved over the existing online docs.. :-)
> 
> I haven’t examined every chapter in detail, but I think this is pretty good 
> for a first attempt at the conversion, which is 99% automated. The only thing 
> done by hand is the intro page, which is ch_oview.rst with some markup for 
> the table of contents. Speaking of which, the TOC for the Appendices isn’t 
> done correctly, but should be straightforward to fix. I’m not 100% sure all 
> the table formatting is correct.
> 
> One nice thing about using ReadTheDocs is that the book looks good on mobile. 
> Give it a try.
> 
> Also, ReadTheDocs automatically generates PDF and EPUB versions. Click on the 
> down arrow at the bottom near “v: latest” to pop up a menu to download these 
> formats. They look pretty decent.
> 
> Comments welcome.
> 
> Rob

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

Re: [GNC-dev] About 3.9 and reconciliation balances

[Adrien Monteleone]

+1 on your idea of the statement as a separate object.

If a closing date is later realized to be erroneous, it only needs to be 
corrected in one place, not every transaction involved. And I hazard the guess 
that the UI that allows a user to edit a statement object data would be simpler 
and more straightforward than walking through every transaction looking for 
suspected bad dates and then making changes.


Regards,
Adrien

> On Apr 15, 2020 w16d106, at 6:14 AM, Geert Janssens 
>  wrote:
> 
> I agree this is useful extra information and also what Christopher Lam has 
> been playing with.
> 
> From an implementation point of view I'd structure this slightly differently:
> 1. instead of adding an account property with a list of reconciliation 
> history, I would introduce a 
> new object, like a "statement" This object would have the fields you mention 
> before (date of 
> reconciliation, statement start date, statement starting balance, statement 
> end date) and some 
> more:
> *statement id* - most bank statements has a unique number which may be 
> helpful to track
> *statement ending balance* - particularly useful to verify manual transaction 
> entries. If you 
> explicitly enter a start and ending balance in addition to the transactions 
> themselves, amount 
> typos will be caught by the numbers no longer adding up.
> *account" - the account this statement refers to.
> 
> Lastly each split should get an additional field "statement id" referring to 
> the statement which 
> includes it. The split "reconciliation date" field would no longer be 
> necessary. That info is 
> encapsulated in the associated statement.
> 
> This mapping would be much closer to the real world order of things:
> * during reconciliation a split is matched to a line on a statement
> * each split can be linked to only one statement
> * in case of reconciliation trouble in the past, the extra statement details 
> make it easier to dig 
> up the related external source (there's a statement id in addition to a 
> reconciliation date).
> * it is more clear which splits were reconciled together - they are tied to 
> the same statement, 
> where in the past there was only a reconciliation date, which may have been 
> wrong for various 
> reasons.
> 
> Regards,
> 
> Geert

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

Re: [GNC-dev] About 3.9 and reconciliation balances

[Adrien Monteleone]

I concur.

It is not unusual for a transaction to be made in one period and clear in the 
next, even in modern times. This is highly probable with issuing a paper check. 
Lower date bounds are going to be a problem.

While I don’t think there is much case (though one user reported so) for a 
future date (beyond ’today’) there is a case for including a transaction dated 
past the statement date.

If you need to enter a balancing or correcting transaction some users may 
prefer the date of that transaction be the day it was made, not ‘as of the 
closing date’. Sticklers for using correcting transactions (as opposed to 
editing transactions) are likely to prefer such dating. This date can very 
likely be more than ’closing +1’.

Regards,
Adrien

> On Apr 17, 2020 w16d108, at 9:27 AM, Dale Phurrough via gnucash-devel 
>  wrote:
> 
> As an attempt for clarity, I don't globally agree with what David wrote
> "The dates in a statement will all fall between the end date of the last
> statement +1 (the start date of the current statement) and the end date of
> the current statement as the statement dates are inclusive."
> 
> I believe in the global (as in all scenarios all possibilities) that the
> dates for transactions in a statement would be on or before the end date of
> the current statement. However, such transactions could also be before the
> end date of the last statement. I have countless examples of this where I
> caused/made a payment before the end of month and that payment wasn't
> booked by a bank until the next month. In this scenario, the date that one
> wants in GnuCash might be the causation date or the booking date.
> 
> I believe it is the user's choice of which date to save into GnuCash:
> either the date the transaction was caused (e.g. data entry into GnuCash)
> or the date the bank finally booked it. So the date should not be lower
> bounded by the end date of the last statement. Instead, only upper bounded
> by the end date of the current statement.
> 
> Follow my thinking?
> 
> --Dale


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

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Adrien Monteleone]

I just posted my first result and impression to the bug report, though I’m sure 
you saw that already. (this is more for the benefit of list readers not 
following the bug)

The signs aren’t making sense, and the amounts aren’t adding up correctly.

Regards,
Adrien

> On Apr 10, 2020 w15d101, at 5:59 AM, Christopher Lam 
>  wrote:
> 
> Next addendum: your existing budget data will behave well when reverse
> balances=credit accounts, but the *featured* data will be stable with *any*
> reverse balances global preference option.
> 
> On Fri, 10 Apr 2020, 11:28 am Christopher Lam, 
> wrote:
> 
>> 
>> 
>> On Fri, 10 Apr 2020, 10:20 am Christopher Lam, 
>> wrote:
>> 
>>> Deadline is 11 April at noon GMT, so, about 34 hours from now.
>>> 
>>> For both: *existing* datafile and especially *4.x-featured *datafile (in
>>> bug report).
>>> 
>>> Please test:
>>> - creation of budget amounts
>>> - use estimate to prefill cells
>>> - all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately
>>> 
>> 
>> Addendum this is not simply an arithmetic test; it *must also
>> confirm that the totals and signs are sensible for the purpose of
>> budgeting. Hence the difficulty of a one person coder to make it work. For
>> example, we can budget a liability account regularly until we have enough
>> deposit for a huge loan, or we can budget a liability account regularly for
>> the loan repayments. IIUC both approaches are "valid" but the signs will be
>> opposite. Other counter examples likely exist.
>> 
>> - budget.scm report (optionally other budget reports but these are lower
>>> priority) and especially difference column.
>>> 
>>> On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone <
>>> adrien.montele...@lusfiber.net> wrote:
>>> 
>>>> Thank You! This makes it so much easier to test. I’ll give the flatpak a
>>>> spin and see what I find. I still haven’t set up a build environment for
>>>> Mac yet. (and watching a recent thread on the subject makes it look
>>>> daunting compared to Linux)
>>>> 
>>>> This is a busy weekend for me though. What kind of time frame do you
>>>> have and is there something in particular you’re looking to find. (other
>>>> than just loosely that the totals appear to work)
>>>> 
>>>> Regards,
>>>> Adrien
>>>> 
>>>>> On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam <
>>>> christopher@gmail.com> wrote:
>>>>> 
>>>>> 2020-04-07 nightly available at
>>>> https://code.gnucash.org/builds/win32/maint/
>>>>> flatpaks available at https://code.gnucash.org/builds/flatpak/maint/
>>>> - use
>>>>> between 2020-04-04 and 2020-04-10
>>>>> 
>>>>> On Fri, 10 Apr 2020 at 01:38, Christopher Lam <
>>>> christopher@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> This topic is about budgets.
>>>>>> 
>>>>>> We now know that budgets are currently inherently flawed: they
>>>> *assume*
>>>>>> that sign-reversal = credit-accounts, and do not work well at all
>>>> with any
>>>>>> other sign-reversal option. In addition, there was a feature request
>>>> (bug
>>>>>> 781345) that introduced budget equity into the equation, and I still
>>>> do not
>>>>>> know whether a budget equity amount is a correct approach.
>>>>>> 
>>>>>> In 4.x series there is a planned *fix* which will scan budget amounts,
>>>>>> use heuristics to determine the most likely sign-reversal approach
>>>> used
>>>>>> during budget creation, internally unreverse the amounts, and upgrade
>>>> the
>>>>>> datafile so that it cannot be damaged by 3.7 or earlier.
>>>>>> 
>>>>>> Therefore 3.8 was the first release which could handle both old and
>>>> fixed
>>>>>> budget amounts. Unfortunately, the interpretation of budget signs
>>>> was/is
>>>>>> very difficult, which explained the switch to
>>>>>> asset/liability/equity/income/expense totals, which are impervious to
>>>>>> budget signs. Unfortunately users missed the "Remaining to Budget"
>>>> facility.
>>>>>> 
>>>>>> Therefore 3.9 was, du

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Adrien Monteleone]

Okay, I’ll see what I can do. First, is to figure out how to get that flatpak 
installed from that link.

I’ve never messed with Flatpaks, but I’m guessing I need to add a repo and then 
I should be able to install. Researching now...

Regards,
Adrien

> On Apr 9, 2020 w15d100, at 9:20 PM, Christopher Lam 
>  wrote:
> 
> Deadline is 11 April at noon GMT, so, about 34 hours from now.
> 
> For both: existing datafile and especially 4.x-featured datafile (in bug 
> report).
> 
> Please test:
> - creation of budget amounts
> - use estimate to prefill cells
> - all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately
> - budget.scm report (optionally other budget reports but these are lower 
> priority) and especially difference column.
> 
> On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone 
>  wrote:
> Thank You! This makes it so much easier to test. I’ll give the flatpak a spin 
> and see what I find. I still haven’t set up a build environment for Mac yet. 
> (and watching a recent thread on the subject makes it look daunting compared 
> to Linux)
> 
> This is a busy weekend for me though. What kind of time frame do you have and 
> is there something in particular you’re looking to find. (other than just 
> loosely that the totals appear to work)
> 
> Regards,
> Adrien
> 
> > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam 
> >  wrote:
> > 
> > 2020-04-07 nightly available at https://code.gnucash.org/builds/win32/maint/
> > flatpaks available at https://code.gnucash.org/builds/flatpak/maint/ - use
> > between 2020-04-04 and 2020-04-10
> > 
> > On Fri, 10 Apr 2020 at 01:38, Christopher Lam 
> > wrote:
> > 
> >> This topic is about budgets.
> >> 
> >> We now know that budgets are currently inherently flawed: they *assume*
> >> that sign-reversal = credit-accounts, and do not work well at all with any
> >> other sign-reversal option. In addition, there was a feature request (bug
> >> 781345) that introduced budget equity into the equation, and I still do not
> >> know whether a budget equity amount is a correct approach.
> >> 
> >> In 4.x series there is a planned *fix* which will scan budget amounts,
> >> use heuristics to determine the most likely sign-reversal approach used
> >> during budget creation, internally unreverse the amounts, and upgrade the
> >> datafile so that it cannot be damaged by 3.7 or earlier.
> >> 
> >> Therefore 3.8 was the first release which could handle both old and fixed
> >> budget amounts. Unfortunately, the interpretation of budget signs was/is
> >> very difficult, which explained the switch to
> >> asset/liability/equity/income/expense totals, which are impervious to
> >> budget signs. Unfortunately users missed the "Remaining to Budget" 
> >> facility.
> >> 
> >> Therefore 3.9 was, during development, tested with
> >> https://github.com/Gnucash/gnucash/pull/630 and was deemed "good enough"
> >> to fix to restore the remaining to budget total. Unfortunately the
> >> liability budget amount issue was tested incorrectly.
> >> 
> >> For a week, the git-maint contained a candidate fix, discussed in
> >> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is
> >> insufficient beta testing on the budgets for now. So, 3.10 will retain 3.9
> >> behaviour unless the fix is fully tested.
> >> 
> >> Conclusion: this is a call for beta testers, using the 2020-04-07 nightly
> >> (the only one with the fix), to test both their datafiles and the
> >> *4.x-featured* datafile attached in the bug report. Please *especially*
> >> test the liability and equity totals, both with existing datafile and
> >> featured datafile.
> >> 
> >> Flame away. I will try to be available throughout the day for testing.
> >> Win32 users have only 1 build to test, Linux users may also build from
> >> 882fd22ca rather than git-maint which has returned to 3.9 behaviour. I'm
> >> not sure how MacOS users can 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


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

Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10

[Adrien Monteleone]

Thank You! This makes it so much easier to test. I’ll give the flatpak a spin 
and see what I find. I still haven’t set up a build environment for Mac yet. 
(and watching a recent thread on the subject makes it look daunting compared to 
Linux)

This is a busy weekend for me though. What kind of time frame do you have and 
is there something in particular you’re looking to find. (other than just 
loosely that the totals appear to work)

Regards,
Adrien

> On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam 
>  wrote:
> 
> 2020-04-07 nightly available at https://code.gnucash.org/builds/win32/maint/
> flatpaks available at https://code.gnucash.org/builds/flatpak/maint/ - use
> between 2020-04-04 and 2020-04-10
> 
> On Fri, 10 Apr 2020 at 01:38, Christopher Lam 
> wrote:
> 
>> This topic is about budgets.
>> 
>> We now know that budgets are currently inherently flawed: they *assume*
>> that sign-reversal = credit-accounts, and do not work well at all with any
>> other sign-reversal option. In addition, there was a feature request (bug
>> 781345) that introduced budget equity into the equation, and I still do not
>> know whether a budget equity amount is a correct approach.
>> 
>> In 4.x series there is a planned *fix* which will scan budget amounts,
>> use heuristics to determine the most likely sign-reversal approach used
>> during budget creation, internally unreverse the amounts, and upgrade the
>> datafile so that it cannot be damaged by 3.7 or earlier.
>> 
>> Therefore 3.8 was the first release which could handle both old and fixed
>> budget amounts. Unfortunately, the interpretation of budget signs was/is
>> very difficult, which explained the switch to
>> asset/liability/equity/income/expense totals, which are impervious to
>> budget signs. Unfortunately users missed the "Remaining to Budget" facility.
>> 
>> Therefore 3.9 was, during development, tested with
>> https://github.com/Gnucash/gnucash/pull/630 and was deemed "good enough"
>> to fix to restore the remaining to budget total. Unfortunately the
>> liability budget amount issue was tested incorrectly.
>> 
>> For a week, the git-maint contained a candidate fix, discussed in
>> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is
>> insufficient beta testing on the budgets for now. So, 3.10 will retain 3.9
>> behaviour unless the fix is fully tested.
>> 
>> Conclusion: this is a call for beta testers, using the 2020-04-07 nightly
>> (the only one with the fix), to test both their datafiles and the
>> *4.x-featured* datafile attached in the bug report. Please *especially*
>> test the liability and equity totals, both with existing datafile and
>> featured datafile.
>> 
>> Flame away. I will try to be available throughout the day for testing.
>> Win32 users have only 1 build to test, Linux users may also build from
>> 882fd22ca rather than git-maint which has returned to 3.9 behaviour. I'm
>> not sure how MacOS users can 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] About 3.9 and reconciliation balances

[Adrien Monteleone]

I don’t see #1 as ‘forever’ but ‘until a better option can be crafted’.

#2 gives flexibility. To reduce confusion, should it be selected by default? 
(only those who intentionally need to reconcile future dates are the users 
who’ll have to grok it) 

How viable is:

3b. Add this to the Check & Repair process already in the Actions Menu. Does 
the book feature need to be set without further input? (is that the part that 
prevents the book from being read from <3.10?)

Regards,
Adrien

> On Apr 9, 2020 w15d100, at 2:25 AM, Christopher Lam 
>  wrote:
> 
> Regarding reverting:
> 
> It is too difficult to create a UI to modify reconciled dates. Options to
> fix this are:
> 
> 1. roll back this change and tolerate the invalid data. This means any
> progress on that matter is hindered forever.
> 
> 2. allow this change depending on a user-selectable book property "Use
> strict reconcile date balances".
> Pros: This means the book can be read/written by any recent version. See
> "Use split action for num" as a similar example.
> Cons: The toggled property can be a confusing option for new users.
> 
> 3. allow this change depending on a non-user-selectable book feature "Use
> strict reconcile date balances".
> Pros: This feature can be set by a menu item. It triggers one-time
> verification of all reconciled dates, instructing users to
> correct/re-reconcile previous reconciled-dates, and sets the book feature
> if all dates seem correct.
> Cons: This means the book can only be read by 3.10 onwards.
> 


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

Re: [GNC-dev] [GNC] [MAINT] Unplaned network outage yesterday, April 2, 2020

[Adrien Monteleone]

Unless you were the one who cut the line, no need to apologize. Thanks for 
keeping things running!

Regards,
Adrien

> On Apr 3, 2020 w14d94, at 11:09 AM, Derek Atkins  wrote:
> 
> HI,
> 
> There was a fiber break in my neighborhood yesterday which took out my
> network (and others) for multiple hours.  It was eventually repaired and
> everything came back.  Not much I could do about it.  I called AT within
> 10 minutes to work on getting it repaired, but there was a truck at the
> site quickly and unrelated to my technician call.
> 
> Once they repaired the line everything came back and mail started flowing
> again.
> 
> Sorry for any inconvenience.
> 
> -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] [GNC] some of my reconciliations in 3.9 are completely bonkers

[Adrien Monteleone]

How difficult would it be to craft a report that exposes these *possibly* 
errant dates? I’m thinking something that compares closing date to transaction 
dates in that reconciliation. If they don’t match, they get flagged to end up 
on a report. It is certainly possible to have out of period transactions, but 
this would be a starting point. Of course, I don’t know if the data file even 
contains this info. Is the closing date and/or reconcile date stored with a 
transaction’s reconciled flag?

Or maybe this should be a check in the code on first run to alert the user to 
possibly errant reconciliations with an opportunity to correct them.

The report might be better though because the amount of transactions and 
reconciliations might be large and the user might need to tackle them over a 
longer time frame than a single session after upgrading.

Regards,
Adrien

> On Apr 2, 2020 w14d93, at 12:10 AM, Christopher Lam 
>  wrote:
> 
> Thank you for helping troubleshoot this issue.
> 
> The dilemma is whether to keep this change which exposes invalid
> reconciliation statement dates, or revert to previous behaviour. The only
> UI available to fix these dates is to unreconcile the old splits and
> rereconcile old statements (or use latest statement).
> 


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

Re: [GNC-dev] Question about account list and typeahead

[Adrien Monteleone]

Search button?

The issue I’m speaking of is when you are on the Accounts tab and just start 
typing. A small entry field will pop up, usually in the lower right corner 
(location varies) and it finds (as you type) whatever text you just typed in 
that tab. It isn’t a feature of GnuCash to search for accounts. It is a feature 
of GTK as a general content search.

That is where my delete and/or backspace key do not work for me. (using Apple 
standard keyboard or a full keyboard) Yes, this field comes up blank initially, 
but if you misspelled something, you can’t use delete/backspace to fix it. You 
have to highlight the entire text first.

Regards,
Adrien

> On Mar 16, 2020 w12d76, at 4:33 PM, chris graves  
> wrote:
> 
> Just another point of reference, the delete key in this situation works fine 
> on my system (Catalina).
> 
> But I'm not quite sure that I am understanding your issue.  In the search 
> entry field, I can enter text and delete at will.
> 
> When I hit the Search button, the search entry field is blanked, so no reason 
> to hit backspace.
> 
> Chris
> 
>> On Mar 15, 2020, at 2:34 PM, Adrien Monteleone 
>>  wrote:
>> 
>> I am on Catalina as well.
>> 
>> Regards,
>> Adrien
>> 
>>> On Mar 15, 2020 w12d75, at 4:30 PM, David H  wrote:
>>> 
>>> Doesn't work on my Mac either - Catalina maybe ???
>>> 
>>> Cheers David.
>>> 
>>> On Mon, 16 Mar 2020 at 07:18, jeanl  wrote:
>>> 
>>>> Adrien Monteleone-2 wrote
>>>>> It has a usability bug. If you want to search for something else, such as
>>>>> if you misspelled your term, you have to highlight the text to delete it
>>>>> and then type something different. The backspace key (delete on MacOS)
>>>>> doesn’t work. This might just be a Mac thing though.
>>>> 
>>>> Mmm, it seems to work on my mac. On my windows machine, I see the problem
>>>> you describe.
>>>> 


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

Re: [GNC-dev] Question about account list and typeahead

[Adrien Monteleone]

I am on Catalina as well.

Regards,
Adrien

> On Mar 15, 2020 w12d75, at 4:30 PM, David H  wrote:
> 
> Doesn't work on my Mac either - Catalina maybe ???
> 
> Cheers David.
> 
> On Mon, 16 Mar 2020 at 07:18, jeanl  wrote:
> 
>> Adrien Monteleone-2 wrote
>>> It has a usability bug. If you want to search for something else, such as
>>> if you misspelled your term, you have to highlight the text to delete it
>>> and then type something different. The backspace key (delete on MacOS)
>>> doesn’t work. This might just be a Mac thing though.
>> 
>> Mmm, it seems to work on my mac. On my windows machine, I see the problem
>> you describe.
>> 


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

Re: [GNC-dev] Question about account list and typeahead

[Adrien Monteleone]

I don’t think that is a feature of GnuCash. I think it belongs to GTK. It seems 
to work similar to Find-in-page of browser windows.

It will only search what is visible in the tab, so a collapsed part of the tree 
won’t be found.

A keyboard shortcut to expand/collapse all would be nice to go along with this 
for sure.

It has a usability bug. If you want to search for something else, such as if 
you misspelled your term, you have to highlight the text to delete it and then 
type something different. The backspace key (delete on MacOS) doesn’t work. 
This might just be a Mac thing though.

> On Mar 14, 2020 w11d74, at 2:34 PM, jeanl  wrote:
> 
> Guys,
> 
> When we're in the account list view (the main gnucash page), you can start
> typing and this will open the account list to the first matching account. 
> This is very convenient to quickly access an account in a large, deep
> hierarchy.
> However if the account tree isn't expanded, its leaf accounts are not
> matched, so unless the tree is fully expanded, the type ahead account match
> isn't terribly useful.
> 
> Question: Is this on purpose? I would imagine that would not be hard to fix,
> so there must be a reason why it hasn't been...
> 
> NOTE: This has nothing to do with the PR I submitted about matching account
> in the transaction editing dialog)
> Jean

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

Re: [GNC-dev] Ideas for account type-ahead modification

[Adrien Monteleone]

Can account number entry be part of the solution? (or is that a separate ball 
of wax?) I know I’ve seen that asked for as well. (and would use it myself if 
it existed) The current work around is to include the account number in the 
account name (though it has its own field) and even then it requires too many 
key presses to use properly.

Regards,
Adrien

> On Mar 10, 2020 w11d70, at 10:20 AM, Jean Laroche  wrote:
> 
> Thanks for pointing me to this bug report! I don't know how I missed it. I 
> looks like a patch was created a long time ago, commented upon, but then 
> nothing was done about it, which is really too bad.
> 
>> It might be useful for small private acoount herarchies.
>> But on major business templats with over 1000 accounts it would be
>> annoying in several aspects:
>> 1. slow down on building the  list,
>> 2. exposing irrelevant parts, example:
>> Assets:Tax paid:{x %|y %|z %}
>> Liabilities:Tax collected:{x %|y %|z %}
>> Expense:Purchases at:{x %|y %|z %}
>> Income:Sells at:{x %|y %|z %}
>> which currently is straight forward.
> 
> About the slow down, I'm not too sure. Searching through 1000 or 2000 strings 
> is pretty much instantaneous on current machines, but building the drop down 
> list may be far slower.
> 
>> I would divide the business users in 2 groups:
>> learned accountants would enter the account code and are not affected,
>> but oters with some economic knowledge would prefer to enter e.g.
>> "I:S:x". Will that still be possible?
> 
> I concur. A change like that could not be enforced to users who don't 
> want/need it. There should be a preference that selects the type of 
> completion the user wants, for sure.
> I'll take a look at the attached patch and see if it can be improved...
> But the fact that there was the beginning of a solution, and that this was 
> abandoned is a bit discouraging: the reviewers asked for improvements, but in 
> the end instead of a better solution, we got no solution at all. That's 
> definitely not ideal.
> Jean

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

Re: [GNC-dev] [GNC] Fwd: Failed - import of QIF files from Quicken

[Adrien Monteleone]

I seem to recall a development goal being to eliminate Scheme code except for 
reports.

This might be a good candidate for just re-writing this in C/C++ with proper 
tests and verbose error output and/or logging.

If someone with the skillset is interested of course.

Regards,
Adrien

> On Feb 18, 2020 w8d49, at 6:35 PM, James Peterson  wrote:
> 
> Well, with no hint of what the problem is, even smaller
> test sets won't necessarily find anything, so it could be 
> a lot of work for no benefit.  For example, I could export
> each account separately (although there are about 80 of them
> so that's a lot of work), and each account could load 
> okay separately, because maybe the problem is an interaction 
> between two different accounts. So then I have to do 80*79
> possible pairs of accounts, and so on.
> 
> My poking around in the 
> source code to try to find the problem suggests that the
> problem is in the Scheme part that seems to be working with
> all the accounts at the same time:
> 
> ;; Build a local account tree to hold converted transactions.
> 
> ;; Sort the account list on the depth of the account path.
> 
> ;; Make all the accounts.
> 
> ;; Run through the markable transactions marking any
>  ;; duplicates.  marked transactions/splits won't get imported.
> 
>   ;; Convert into a GnuCash transaction.
>   ;; rebalance and commit everything
> 
> So this looks like multiple runs thru the data, and even printing
> the line number won't narrow it down -- you have to know what
> step of the process we are doing, and where we are in the data
> at that point.
> 
> As things stand, we don't even know what the immediate problem
> is -- a divide by zero?  Looking for an account that should exist,
> but doesn't?, an account type that it doesn't know about? 
> 
> The code is not written to allow it to even explain what it is
> doing. If we are going to use this code base, someone who actually
> understands, and is comfortable with the code will need to add
> a "verbose input processing" level or something that will create
> a log file explaining what it is going to try to do, then do it,
> then explain what it got and how it interprets that. I've done 
> that with code before, but only C code, where, if need be, there is
> the equivalent of a printf to a log file between every major step,
> or each iteration of a loop, explaining what it thinks it is doing
> and with what input and with what result.  I just don't know how to
> add that to scheme.
> 
> jim

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

Re: [GNC-dev] [GNC] Failed - import of QIF files from Quicken

[Adrien Monteleone]

Tom, info about sources and building can be found on the GnuCash website and 
wiki. Check the Development section.

Regards,
Adrien

> On Tue, 18 Feb 2020 at 15:51, Tom Hatzigeorgiou  wrote:
> 
>> To do this someone will need to help me.
>> I don't know how projects like this work.
>> I have no idea where the program source exists and the tools I will need
>> to manipulate it.
>> 
>> I was thinking that a very simple way to debug the code is, for someone to
>> place a display on a version of the new importer where every record that it
>> processes gets displayed (in a log file) before it gets imported.
>> This way by running the importer I will see at what record(s) it failed.
>> I would run it multiple times until I find and eliminate ALL the records
>> of my file that it fails on.
>> When all bad records get eliminated and my file gets loaded correctly by
>> the current importer, I don't think I would have a problem sending you all
>> those bad records for you to analyze and see where the new importer has
>> gone bad.
>> 
>> DO you think something like the above can be done?

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

Re: [GNC-dev] (no subject)

[Adrien Monteleone]

I forgot to mention that an absolutely positioned element behaves differently 
with respect to height rules. But absolute positioning should usually be 
avoided as much or more than setting height in the first place. Let the 
rendering engine do the work rather than treating the layout like a manually 
designed desktop publishing exercise.

Regards,
Adrien

> On Nov 19, 2019 w47d323, at 12:48 PM, Adrien Monteleone 
>  wrote:
> 
> 
> 
>> On Nov 19, 2019 w47d323, at 12:59 AM, Christopher Lam 
>>  wrote:
>> 
>> Dear All
>> 
>> Maint branch includes recent changes to report whereby  is
>> inserted at the top. This is to improve standards compliance.
>> 
>> The minor side effect right now is that it enforces standards-mode instead
>> of quirks-mode in webkit (both unices and Windows) charts are squashed to
>> 300px because of
>> https://stackoverflow.com/questions/32214152/why-does-my-div-height-100-work-only-when-doctype-is-removed/32215263#32215263
>> and I'm not 100% sure of the most appropriate fix yet. Inserting html,body
>> {height:95%} does the trick by expanding parent elements to 95% of
>> viewport. Setting height to 100% would be fine except it causes scrollbars
>> to appear unnecessarily. This fix works both in Unix (libwebkit2) and
>> Windows (libwebkit1).
>> 
>> If anyone has better ideas how to fix this please let me know. If this
>> change is unwanted we can revert to previous quirks-mode reports.
> 
> The solution and explanation is given both in that link as well as the 
> further explanatory link contained therein: 
> https://stackoverflow.com/a/31728799/3597276
> 
> The problem is the use of percentage which is relative to its parent element. 
> But if the parent (all the way up the document tree to the root element, 
> `html`) does not have a set height, then the value defaults to `auto` because 
> there is nothing to calculate the percentage on.
> 
> The solution is to not use percentage.
> 
> If you need a relative rule, (as opposed to explicit units like `px` or `pt`) 
> use Viewport Height, `vh`, thus set {height: 100vh}
> 
> That may not be what you want, however. You might just need a smaller 
> percentage of the viewport, but any such value has a reference for 
> calculation. (the viewport height is known by the browser and doesn’t rely on 
> the document tree cascade. It can be changed by the user, however)
> 
> The reason that percentage ‘works’ in quirks-mode is because quirks-mode 
> converts the percentage rule to a viewport height rule.
> 
> So I’d advocate for sticking with standards-mode and using the proper style 
> declaration.
> 
> Note too, it is rare to need to set height. While there are some exceptions, 
> needing to set height means something else was maybe done wrong somewhere. It 
> is probably better to find and fix that error instead and let the rendering 
> engine determine the height based on content.
> 
> 
>> Additionally there's a recent change to re-enable negative numbers=red in
>> reports; a side effect of this was border colour also becomes red. This is
>> fixed by applying CSS rule "th,td {border-color:grey}" which could cause
>> cause issues with users with different colour themes. Any further
>> suggestions welcome.
> 
> Borders should not be affected by a rule for coloring negative numbers at 
> all. That tells me the proper specificity is not being used in the CSS rule.
> 
> Fix the specificity targeting negative numbers instead and you won’t need to 
> mess with border color at all.
> 
> Regards,
> Adrien


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

Re: [GNC-dev] (no subject)

[Adrien Monteleone]

> On Nov 19, 2019 w47d323, at 12:59 AM, Christopher Lam 
>  wrote:
> 
> Dear All
> 
> Maint branch includes recent changes to report whereby  is
> inserted at the top. This is to improve standards compliance.
> 
> The minor side effect right now is that it enforces standards-mode instead
> of quirks-mode in webkit (both unices and Windows) charts are squashed to
> 300px because of
> https://stackoverflow.com/questions/32214152/why-does-my-div-height-100-work-only-when-doctype-is-removed/32215263#32215263
> and I'm not 100% sure of the most appropriate fix yet. Inserting html,body
> {height:95%} does the trick by expanding parent elements to 95% of
> viewport. Setting height to 100% would be fine except it causes scrollbars
> to appear unnecessarily. This fix works both in Unix (libwebkit2) and
> Windows (libwebkit1).
> 
> If anyone has better ideas how to fix this please let me know. If this
> change is unwanted we can revert to previous quirks-mode reports.

The solution and explanation is given both in that link as well as the further 
explanatory link contained therein: https://stackoverflow.com/a/31728799/3597276

The problem is the use of percentage which is relative to its parent element. 
But if the parent (all the way up the document tree to the root element, 
`html`) does not have a set height, then the value defaults to `auto` because 
there is nothing to calculate the percentage on.

The solution is to not use percentage.

If you need a relative rule, (as opposed to explicit units like `px` or `pt`) 
use Viewport Height, `vh`, thus set {height: 100vh}

That may not be what you want, however. You might just need a smaller 
percentage of the viewport, but any such value has a reference for calculation. 
(the viewport height is known by the browser and doesn’t rely on the document 
tree cascade. It can be changed by the user, however)

The reason that percentage ‘works’ in quirks-mode is because quirks-mode 
converts the percentage rule to a viewport height rule.

So I’d advocate for sticking with standards-mode and using the proper style 
declaration.

Note too, it is rare to need to set height. While there are some exceptions, 
needing to set height means something else was maybe done wrong somewhere. It 
is probably better to find and fix that error instead and let the rendering 
engine determine the height based on content.


> Additionally there's a recent change to re-enable negative numbers=red in
> reports; a side effect of this was border colour also becomes red. This is
> fixed by applying CSS rule "th,td {border-color:grey}" which could cause
> cause issues with users with different colour themes. Any further
> suggestions welcome.

Borders should not be affected by a rule for coloring negative numbers at all. 
That tells me the proper specificity is not being used in the CSS rule.

Fix the specificity targeting negative numbers instead and you won’t need to 
mess with border color at all.

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

Re: [GNC-dev] [GNC] Customer Report versus Receivables Aging

[Adrien Monteleone]

I have a client that has frequent pre-payments and their entry in the Aging 
report shows a negative balance. (I owe them because they have pre-paid)

I’m also using 3.7.

Are you entering pre-payments using the “process payment” function?

If you are simply taking the payment entered as a manual transaction, and later 
using the ‘apply as payment’ function, then the Aging report won’t see it till 
you do that. The business features and associated reports aren’t cognizant of 
manual entries.

Regards,
Adrien

> On Nov 6, 2019 w45d310, at 11:00 PM, John Morris  wrote:
> 
> Hi All,
> 
>  Having recently upgraded from GnuCash 2.6.something to 3.7, we are
> having trouble with the some of the customer features. Specifically,
> two reports help us see the amounts we are owed and what we owe our
> clients. Those reports are Reports -> Business -> Receiveable Aging
> and Reports -> Business -> Customer Report. The first report gives us
> a handy list of all the clients who have a balance (positive or
> negative). The second report gives us details (invoices and payments)
> about a particular customer and can be accessed from the first report.
> 
>  The problem we are having is that in version 2.6, Receivable Aging
> included all invoices and all payments in its assessment of each
> client's balance. Thus, if a client has overpaid by $100 but that
> payment has not been applied to any invoices, it would show that the
> client had a $100 negative balance. In version 3.7, no payments that
> have not been applied to any invoices are included in the calculations
> for this report. Thus, if a client completely pays all past invoices
> and then sends another check for $100 to be applied to future work,
> that client does not show up in the Receivable Aging report because it
> thinks the client has a zero balance. As soon as I use even one penny
> from that payment to pay an invoice, the entire $100 shows up in the
> report.
> 
>  In contrast, the Customer Report shows all invoices and all payments
> for a particular client, so we know if we owe the client or the client
> owes us. Unfortunately, with over 1,700 customers, this is not a
> practical way to track our receivables.
> 
>  Is there any way around this problem? We don't have many, but we do
> have a few clients who regularly prepay their projects, so it is very
> important for us to know who they are and where we stand with them. If
> there is no way around this new functionality, how else do other
> people keep track of prepaying clients?
> 
> Thanks,
> John

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

Re: [GNC-dev] owner-report, receivables-aging etc

[Adrien Monteleone]

Christopher,

I have some AR cleanup in-progress and your revised owner-report would come in 
handy matching up payments to invoices. I’ll be happy to report back any 
testing issues I encounter while using it.

I can’t seem to find your link in the list threads, can you provide a current 
link? (I have your github bookmarked but can’t seem to find where this 
particular report is buried)

Can I simply place it in my reports folder and load it or do I need to build 
maint first? Thanks.

Regards,
Adrien

> On Jul 19, 2019 w29d200, at 3:56 AM, Christopher Lam 
>  wrote:
> 
> Wish to canvas opinion on what is considered best practice for the
> following real-data simulations, for rebuilding owner-report and
> aging-report. This illustrates current buggy behaviour.
> 
> * I have a $100 customer invoice, posted- and due-dates 6 weeks ago.
> * I have a $50 credit-note to same customer, posted and due-dates are 2
> weeks ago.
> 
> Intuitively the customer owes $50. But I haven't formally yet linked the
> credit-note to the invoice though. The $100 invoice is still unpaid
> 
> Attachments show:
> * the Customer Report counts the $100 and $50 separately into separate
> owing date ranges.
> * the Receivables Aging report shows the CN $50 was automatically used to
> fund the $100 invoice, via FIFO (paying oldest invoice first).
> 
> Which behaviour should we standardise on?
> 
> 
> [image: image.png]
> 
> [image: image.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] gnucash maint: [new-aging] new receivable/payable aging reports

[Adrien Monteleone]

The Customers/Vendors Overview does show that info, but one cannot export it, 
save it, or even select the text to copy/paste. A fix there I would think would 
be the better option, because as far as I can tell, it does show all 
customers/vendors. But until it is fixed, I agree, it shouldn’t be removed from 
the aging/owner reports.

> On Oct 28, 2019 w44d301, at 10:30 AM, Derek Atkins  wrote:
> 
> Hi,
> 
> Christopher Lam  writes:
> 
>> 3. owner address display is disabled. I am not sure of the utility anymore;
>> we can add again if there is demand.
> 
> I pointed this out in IRC, but just for email posterity --- this feature
> was the only place where one could get a list of all customers (or
> vendors) with their addresses.  Sure, it would only provide the list of
> those customers that have had invoices, but unless there is another
> report that can provide that feature, it should not be removed from here.
> 
> Note that I don't object to creating another "Customer List" report that
> just provides that information.  It's just that this functionality
> should not be lost without it being replaced.
> 
> Thanks,
> 
> -derek

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

Re: [GNC-dev] Mouse usage in Gnucash

[Adrien Monteleone]

I would expect that the language of ‘primary’ and ’secondary’ click is the most 
versatile across platforms and preferences. It allows for OS discrepancies, 
accounts for touch vs. click mice, and allows for handidness considerations. Of 
course, people using accessibility interfaces might not literally ‘click or 
tap’ but the concept of selection is the same. If there is an ‘all-inclusive’ 
term, so be it, but I’m not personally aware of one. (and getting too general 
might even detract from the specific communication intended)

So far, my experience with touch devices has been that 
’tap/click’=primary/left-click and ’two-finger-tap/click’=secondary/right-click 
but that could be a MacOS thing. However, I don’t experience anything different 
using the same hardware in VMs with Linux or Windows so maybe it gets 
translated properly by the VM software. I’ve yet to use the same touch hardware 
with either of those OS options natively.

Now, how do you intend to describe interacting with GnuCash via a VR/AR 
interface where you point out in the space around you? (just kidding of 
course...)

Regards,
Adrien


> On Oct 11, 2019 w41d284, at 6:35 PM, David Cousens  
> wrote:
> 
> Thanks John,
> 
> I agree totally. I am trying to settle on something which might be
> intelligible or at least easily translatable to users on other OSs and
> devices. Frank raised the issue with me while reviewing changes to the help
> manual importing section. I tried what he suggested out but my view on the
> end result is that it ends up being unintelligible to everybody and I may
> yet revert it. 
> 
> I am not too concerned about fairly experienced users (they will figure it
> out) but the novice who comes in without too much experience of other OSs
> and computers is the real target - the one who gets hung up if the
> description is not exactly the way the box in front of him operates. They
> are becoming rarer beasts these days once they have grandkids to educate
> them properly.
> 
> I personally am happy with the left click/tap and right click/tap notation
> and then let users translate that as required for their specific
> equipment/OS as necessary. My son is a leftie and he has never really had a
> problem translating automatically from the RH world unless the devices were
> physically right handed. 
> 
> The touchpads on my laptop and tablet with a touchscreen all respond to
> tap/s on either side of the touchpad or on the screen as expected so the
> click/tap may be the way to go. I don't use tablets too much so I'm not too
> au fait with the finer points of gestures in any case. I just blunder my way
> through.
> 
> David

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

Re: [GNC-dev] Yahoo blocking GnuCash Email

[Adrien Monteleone]

That’s a bummer.

It could also be users who can’t read the unsubscribe instructions or don’t 
follow them and then report the list as spam because they still get messages 
after they ‘asked us’ to unsubscribe them.

I turned off the password reminder feature long ago, as I thought it was a bad 
idea to send passwords via e-mail. It probably should be off by default. I 
don’t get such messages for any other site - ever. I don’t understand why 
mailman even offers it. One can always just reset their password if they forget 
it or don’t manage their passwords.

The only other option I can think of to get this info to them would be to parse 
the mailman db for the yahoo addresses and send to them personally. I would 
include that they should preferably re-subscribe with a different mail provider 
as no one knows when Yahoo will unblock the list again.

Regards,
Adrien


> On Sep 20, 2019 w38d263, at 12:37 PM, Derek Atkins  wrote:
> 
> Hi,
> 
> Starting around September 10, Yahoo appears to have started blocking
> SMTP (email) originating at code.gnucash.org.  This means that yahoo
> users have been prevented from receiving any mail (including list mail
> and bug mail), and worse, they've been blocked from sending mail *to*
> the list as well (due to sender-verify blocking them because yahoo is
> blocking us).
> 
> Unfortunately, this appears to be a "due to user complaints" blockage,
> and Yahoo is pretty tight-lipped about why it actually is blocking.
> This could be due to people flagging gnucash email as spam (which might
> include the monthly password reminders), or it could be as stupid as
> people receiving the email but never reading it.  But like I said, Yahoo
> won't tell me the source of the blockage.
> 
> I am hoping this will clear up on it's own.  If not, I might need to
> literally unsubscribe every yahoo user and then request each person to
> re-subscribe themselves to the list (once email clears up).
> 
> I realize that no Yahoo users will actually *see* this email, but I'm
> hoping they will eventually be able to google for gnucash email yahoo
> problem or something like that and this email will pop up in a couple
> days in the archives.  Alternately, email will clean up and the queue
> will get flushed.
> 
> If anyone has other ideas, please let me know.
> 
> -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] GnuCash 4 Minimum Versions (was: Building on Windows)

[Adrien Monteleone]

Your explanation was what I had in mind when using the term ‘reasonable’. I 
also have a MacBook stuck at 10.6, but I certainly wouldn’t expect the dev team 
to keep supporting a 10+ year old OS. (2.6.x can run on it anyway) Thanks for 
the info.


Regards,
Adrien

> On Aug 27, 2019 w35d239, at 4:02 PM, John Ralls  wrote:
> 
> For what value of "reasonable"? Someone who's still running Mac OS X 10.5 
> thinks it unconscionable that the latest GnuCash doesn't run on it. A user 
> posted on the user list last week that he's upgrading to a "new" Mac running 
> 10.11 from one running 10.10. On the one hand Apple pushes really hard to 
> keep users on the latest MacOS version but on the other every release comes 
> with a list of Macs that won't run it.
> 
> Picking how old an OS to support is in part a balance between what we think 
> most users will be using during the support lifetime of a stable series, what 
> features (both language and libraries) we want to use and what OS versions 
> we're willing to test on. Linux and BSD impose the greatest restrictions 
> because of dependencies, so we pick an "oldest" Linux to set up in Travis CI 
> and make sure that we can always build against it. On MacOS it's driven by 
> what will compile the C++ standard I want to use (C++14 for GnuCash 4 -> 
> 10.10 or newer) and what's required to build the current Gtk stack (also 
> C++14 thanks to a recent change in Harfbuzz; Gtk requires CUPS >= 1.7 as of 
> about 2 months ago, that's 10.9 or newer). I keep a collection of VMs with 
> old versions of MacOS for this purpose.
> 
> Windows is a different story: AFAIK MinGW-w64 still works on XP so GnuCash 
> probably runs on XP. But to make sure of that we'd have to have a Windows XP 
> instance running and exposed to the internet. That's a security risk for the 
> whole LAN that it's running on. In a couple of months Win7 will be in the 
> same bucket and I don't think Geert should be exposed to that risk for the 
> minimal benefit of ensuring that GnuCash builds on a 10 year old operating 
> system, nor should any of us have to track down a Win8.1 installer since it's 
> already 6 years old and Win10 is older than the oldest Linux we're going to 
> test on for the GnuCash 4 series.
> 
> Microsoft says that they support Win10 builds for 18 months but they also 
> make sure that either you have the latest Win10 or you're not connected to 
> the internet. There are probably users out there with 3-year-old Win10 builds 
> but I don't know how to determine whether or not GnuCash will work on their 
> system and if I did how to tell them in a way that a normal user would 
> understand.
> 
> Regards,
> John Ralls

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

Re: [GNC-dev] Building on Windows

[Adrien Monteleone]

> On Aug 27, 2019 w35d239, at 11:01 AM, John Ralls  wrote:
> 
> 
> VSCode can't build anything, it's just an editor. But it can call[1] out to 
> the build system to do whatever build for whatever platform you like. Visual 
> Studio is the full-featured IDE and there's a free (as in beer, Microsoft 
> hasn't gotten *that* far down the open source road!) version [2]. There's 
> even a Mac version[3] that's probably better than Xcode, though admittedly 
> that's not saying much.

And probably why it is seemingly used primarily for web based development so 
far.

> 
> I don't know much about WSL, I was wondering out loud.

WSL was not-so-allegedly created so devs can stick with the MS desktop and 
develop for Linux on it. (primarily) It runs (as of v2) a real Linux kernel in 
a Win10 managed ‘utility’ VM with very little overhead or performance hit. The 
code executed is ‘Linux’ code. Some potential uses are to run Linux apps ‘on’ 
Windows desktops with a native feel and performance. (supposedly WSL2 will 
achieve that)

It stems some bleeding of devs away from the MS platform, but also makes it 
easier for MS devs to work on the Linux kernel which they have started 
contributing to. (probably for WSL, a bit circular) Note, that sentence is pure 
conjecture from the interwebs.

There is some evidence for this with the new VSCode Remote which is an 
extension where you run VSCode on windows, but ‘remote into’ WSL: 
https://code.visualstudio.com/docs/remote/wsl (making it easy to stick with 
Windows, but still develop for Linux)

Regards,
Adrien

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

Re: [GNC-dev] Building on Windows

[Adrien Monteleone]

Interesting.

Also very interesting, is this graph form the survey showing how the 
technologies relate to each other, and from that one *might* surmise the use 
cases:

https://insights.stackoverflow.com/survey/2018#correlated-technologies

If I’m reading that correctly, it looks like VSCode is the preferred IDE for 
JS/TS developers for web applications. Devs working more directly on Windows 
Desktop seem to prefer the full VS, but that might also be affected by the 
demographics - younger developers are preferring VSCode and they are 
gravitating towards web platforms rather than desktop.

> On Aug 27, 2019 w35d239, at 7:37 AM, Dale Phurrough  wrote:
> 
> I noticed earlier the use of "VS" and was watching it for context. Now I see 
> more clearly what was intended.
> You want to actually use the Visual Studio UI and the Visual Studio compiler. 
> And consider VS Code a lesser option "at a stretch".
> 
> I've tons of experience with Visual Studio. It is good for legacy Visual 
> Studio projects, large in-house teams, and rigid development cycles. None of 
> those three align well with GnuCash.
> Contrast that to VS Code. Personally, I use it for everything now. And I use 
> it across platforms, across projects, and always with open-source projects.
> 
> This "windows developer" that you are seeking...are you sure they want Visual 
> Studio? Or is VS Code a better fit? I ask because the approach one takes will 
> be different between the two; and likely not worth the effort to support both.
> Each of the two will have their own possibilities of: editor, packager, and 
> compiler/linker. Luckily, there is some overlap.
> Here is recently statistics and reports on dev tool use VS Code and Visual 
> Studio. VS Code is ahead and the younger devs (via hires) prefer it.
> https://visualstudiomagazine.com/blogs/data-driver/2018/12/2018-vs-code.aspx 

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

Re: [GNC-dev] Building on Windows

[Adrien Monteleone]

> On Aug 26, 2019 w35d238, at 11:28 PM, Sumit Bhardwaj  
> wrote:
> 
> WSL would provide a Linux binary, not a Windows binary. Is that what you are 
> thinking of building? I am also not sure how to get GUI running for WSL. (WSL 
> is really good tool.)

That’s what I was thinking too, but maybe John knows something we don’t. If the 
goal of being able to build via VSCode is reached, then you can use one machine 
and do both builds, one for Linux, the other for Windows. I’ve not heard that 
the Linux version of VSCode can build a Windows binary. (would be great if it 
could)

As for the GUI, some people have done it, though MS doesn’t support it. (even 
running GnuCash!) But I haven’t tried it myself. I’m just getting ready to play 
with Win10 for a client (I don’t use Win systems regularly anymore) so I might 
give it a go in a month or so.

Regards,
Adrien


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

Re: [GNC-dev] Budget accumulate amounts

[Adrien Monteleone]

How about: ‘report amounts as YTD’

If ‘Year’ isn’t necessarily a consistent concept, then something like you 
suggested, ‘report/use accumulated amounts’ would work.

I can play with it soon. (as well as test the First Day of Week fix) Now I 
guess I just need to set up a build workflow for Mac. (I’ve built on Ubuntu 
several times, but never tried on Mac yet)

Regards,
Adrien

> On Aug 20, 2019 w34d232, at 9:46 PM, Christopher Lam 
>  wrote:
> 
> Dear All
> 
> The current maint for upcoming 3.7 includes an upgrade to the basic budget
> report; it incorporates calculations to accumulate budgeted and actual
> amounts from the beginning of the budget period. The aim is to incorporate
> Phil Longstaff's budget-ytd strategy into the main budget report. I have
> labelled the option "General"/"Use envelope budgeting".
> 
> I am fairly certain that my calculations are correct but would like some
> confirmation. Moreover I am not happy with the option name. What should it
> be?
> e.g. "Accumulate amounts across periods", "Use accumulated amounts".
> 
> Suggestions welcome!

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

Re: [GNC-dev] [GNC] Miscalculation in cashflow reports

[Adrien Monteleone]

> On Jul 30, 2019, at 10:57 AM, Adrien Monteleone 
>  wrote:
> 
> The basic form is something like this:
> 
> --
> Cash & Cash Equivalents, beginning of period:
> 
> Cash Flow from Operations:
> Cash Flow from Financing:
> Cash Flow from Investing:
> 
> Net Increase in Cash & Cash Equivalents:
> 
> Cash & Cash Equivalents, end of period:
> --

For simplicity, the Beginning & End of Period lines might have to be left off 
and just report the Net Increase (Decrease) line.

This is because the Beginning of Period figure comes from the End Of Prior 
Period Balance Sheet. Since that will vary, and may not have even been run, 
there is no way to know what that would be. The only way around that would be 
to run the Balance Sheet code for a period *from the start of the book* to the 
day before the opening day of the CashFlow report, take that Cash figure, then 
run the rest of the code for the Cash Flow report, then add the Net change to 
that Cash amount to get the End of Period amount. (which is supposed to match 
the End of Period Balance Sheet cash amount as well)

!!

I’m copying -devel on this to move the discussion there.

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

Re: [GNC-dev] Adding module to make GnuCash more valuable

[Adrien Monteleone]

But what you are speaking of here appears to me to be more of a document 
management or inventory management feature, not an accounting feature.

I’d be inclined to agree with John, that is out of scope for GnuCash.

I understand the industry might have a need for such features, particularly 
open source options, but I’m not sure GnuCash is the place for them. Certainly, 
you can track inventory ownership in your GnuCash books, but the details of how 
you arrive at those transactions are likely best handled by some other tool.

Regards,
Adrien

> On Jul 24, 2019, at 3:08 PM, Rosi Dimova via gnucash-devel 
>  wrote:
> 
> Hi Frank,
> 
>> On 24 Jul 2019, at 17:47, Frank H. Ellenberger 
>>  wrote:
>> 
>> Hi Rosi,
>> 
>>> Am 24.07.19 um 09:12 schrieb Rosi Dimova via gnucash-devel:
>>> :
>>> I never understood this decision to make translators part of dev-team.
>> 
>> you are our ambassador to all Bulgarian speaking people. :-)
>> Translators find many issues in the GUI: Missing context, bad plural
>> forms, bad concatenation for right-to-left writing,  ...
> 
> I like that - an ambassador. Works for me. :-) 
> You have a point, I never considered these things. But can recall being stuck 
> at 33% of translation for months, because I didn’t understand one single 
> word. If it wasn’t for Mila, who explained me our legislation lacks the 
> concept of orphan account, Bulgarian translation wouldn’t become real for 
> many years. At least, not from me.
> 
>> I like your idea. But considering our small resources, I believe it
>> would better fit as a module into ERP software:
>> https://en.wikipedia.org/wiki/List_of_ERP_software_packages
>> 
> 
> Thank you!  :) I’m not good at explanations, but will give it another try and 
> will stop disturbing your discussions. :) 
> You and John are thinking big, but not small or not big enough. And you are 
> underestimating yourselves. Or may be I wasn’t clear enough. Here it is why:
> 
> Technically, issuing ocean bill of lading is nothing much different that 
> printing out a document on a letterhead. Forwarders and shipping lines use 
> various tools. Small companies use spreadsheets or pdf templates to print it 
> on paper. Big companies use SAP or other solutions. SAP-based solutions use 
> browser+pdf again in the common case. I used to work on AS400 for almost 2 
> years. Can you imagine that? It’s older than me! 
> 
> So, I’m talking about nothing more than two additional templates - one for 
> originals and another for electronic (express or telex) release. But it is 
> tricky, especially the latter. For originals: the margins of the templates 
> should be adjustable to fit on their own forms. Also additional fields as per 
> local legislation might be required (like SCAC code).
> The good practice says originals should be printed out from fewer computers. 
> Also two or max. three persons in charge shall sign them. A specimen of any 
> written signature is kept to prove the validity of the B/L. But it is problem 
> of the issuing party, not of the software. Most small companies do not follow 
> this rule strictly.
> 
> For express release: same rules shall be kept by using electronic means. 
> Basically it should include additionally three programmable fields:
> - consecutive number of the document itself, not the B/L number 
> - identity of the signing party (digital signature or some kind of security 
> token)
> - valid time stamp, supported by Electronic data interchange (EDI) for 
> vessel’s sailing date. 
> Date of departure is as important as the identity. Especially for L/C.
> 
> The two templates are needed, because in some countries originals are the 
> only valid B/L. Others require the B/L’s to mention the ocean rate (freighted 
> B/L).
> 
> This is the idea and I think GNC can actually do that or supports the 
> features to implement it. Please let me know if I’m right. :)
> 
> Kind regards,
> Rosi
> 
> 
> 
> 
> 
> 
> ___
> 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] owner-report, receivables-aging etc

[Adrien Monteleone]

> On Jul 23, 2019, at 10:11 AM, Derek Atkins  wrote:
> 
> 
> 
>> In any case I'd think both owner-report and aging must be consistent.
> 
> MAYBE..  But not necessarily.  The aging report is more for the
> business, whereas the customer report is designed to actually be sent to
> the customer.  So they might not need to be 100% consistent.  And
> indeed, I would suggest the customer report should be sure to contain
> ALL transactions, whereas aging can ignore certain types.

I would certainly agree here. If credits are simply ‘left off’ this report, the 
very first question a customer will have will be about their credit notes. This 
report is the closest equivalent to a Statement of Account. It should contain 
everything.

I can see it could get messy with the aging table, so that should likely be 
just positive balances outstanding. Or, include the credit notes here as well, 
but age them just like an invoice, don’t ‘apply’ them to an invoice.

A third possible option —does it make sense to show a separate aging table for 
credit notes if any?

Regards,
Adrien


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

Re: [GNC-dev] [GNC] How to apply Over Payments or Pre-Payments to a Different Invoice

[Adrien Monteleone]

Nice!

Does this work for invoices not assigned a ‘job’? (I might have to tackle my 
own bug report on that one as my first, it is a source of confusion)

I think the second report example is cleaner, by the way.

And while I don’t use multi-currency AR/AP, I can certainly see the ability to 
pull them all on one report will earn you many thanks.

Thanks for the link. I’ll try it out.

Regards,
Adrien

> On Jul 10, 2019, at 9:34 AM, Christopher Lam  
> wrote:
> 
> On Wed, 10 Jul 2019 at 14:30, Adrien Monteleone 
>  wrote:
> (snip)
> 
> Unfortunately, the Customer Report doesn’t match up invoices to payments, it 
> is just a straight time-line of debits and credits. (you can sort of match 
> them up if you utilize the notes and memos fields, but there are a few bugs 
> on this issue at present to make this entirely useful)
> 
> If a customer regularly floats lots of invoices, or balances owed along with 
> credits held, there is no easy way to see which credits haven’t been used 
> other than trying to process a payment and they’ll show up there.
> 
> 
> (Ahem) doesn't have to be this way... 
> https://github.com/Gnucash/gnucash/pull/535


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

Re: [GNC-dev] [GNC] best accounting practice for refund

[Adrien Monteleone]

Chris, you have me confused a bit. You probably want Derek Atkins (active on 
this list) who, from what I gather, wrote the larger portion, if not all, of 
the business features.

I don’t shy away from editing requests, particularly because I understand the 
devs have their hands full already, but in this case, for base material, I 
defer.

Regards,
Adrien

> On Jun 28, 2019, at 5:48 PM, Christopher Lam  
> wrote:
> 
> Adrien you're the current expert in business processes supported by GnuCash. 
> How would you feel about documenting the known feature and describe database 
> changes somewhere in wiki? It would be useful as a reference. You may need 
> some SQL spy. e.g.
> 
> # Creating a customer
> - add new row to Customers table, must have currency, name and address
> 
> # Creating invoice
> - add new row to Invoice table, must have customer, currency
> - add new row to Lots table, ???
> 
> # Creating a credit note
> - ???
> 
> etc
> 
> On Fri., 28 Jun. 2019, 14:31 Adrien Monteleone, 
>  wrote:
> Nope.
> 
> 1. Create the credit note and assign the line items either back to the same 
> original income account(s) used, or to a new one along the lines of “Returns 
> & Allowances” or “Refunds” or something similar if you want to keep track of 
> this separately. (this is considered a ‘contra account’ because its normal 
> balance is opposite of what is expected)
> 
> 1a. Post the credit note. (should default to be assigned to AR)
> 
> 2. Then ‘pay’ it with the liability account you created.
> 
> This will affect your books at each step like so:
> 
> 1a. Income is debited either directly or via the contra account
> 1a. AR is credited for the amount of the credit note
> 2. AR is debited for the amount of the credit note
> 2. The Liabilities:Credit Payments account is credited (your now tracking a 
> pre-payment liability owed to the client)
> 
> The only step that should be different in this process than what you were 
> doing before is step 2. Instead of paying with the checking account and 
> printing a check, you’re transferring the customer’s AR balance to a 
> liability account.
> 
> Step 1 - the credit note itself, should be the same as before.
> 
> There will then be a new step 3 - which is where you ‘pay’ a future invoice 
> with all or part of the balance in the new liability account.
> 
> -
> 
> *NOTE*
> 
> If you don’t need to keep track of the pre-payment as a liability (not 
> necessary unless a CPA advised it) then just skip creating that special 
> account and don’t use it.
> 
> Simply leave the credit note (still created as always) outstanding till it is 
> needed to offset a future invoice. You don’t even have to send it to the 
> client if they don’t need it.
> 
> When you need to offset a future invoice, process a payment, choose BOTH the 
> credit note and the invoice being offset. Enter any additional payment being 
> made and assign that to the appropriate asset account. Complete the payment.
> 
> Mind you, this is probably the best route to take. It will allow you to still 
> see the overpayment/pre-payment in their account report, and you can send 
> them a statement that reflects this. The option with the liability account 
> makes this very difficult.
> 
> Sorry if I created any confusion. With the original limited info, I was just 
> offering all the options I could think of. Which route you take is up to you 
> as it best meets your needs and requirements.
> 
> Regards,
> Adrien
> 
> 
> 
> > On Jun 28, 2019, at 12:39 AM, Eric Rathhaus (general) 
> >  wrote:
> > 
> > Something didn’t;t work.  I created a credit note for the client and 
> > created a new account “Credit Prepayments) under Liabilities.  When 
> > creating the note, instead of selecting an income account, I selected the 
> > new liabilities account and then posted the note.  I then tried to process 
> > a payment for an outstanding invoice using the credit note but nothing 
> > happened.  Where did I go wrong?
> > 
> >> On Jun 26, 2019, at 9:09 PM, Eric Rathhaus (general) 
> >>  wrote:
> >> 
> >> Thanks!
> >> 
> >>> On Jun 26, 2019, at 7:41 PM, Adrien Monteleone 
> >>>  wrote:
> >>> 
> >>> In that case, certainly, you need to use credit notes.
> >>> 
> >>> I don’t see any reason why this ‘wouldn’t work from an accounting 
> >>> standpoint’ but if you find a problem, instead of cutting a check to the 
> >>> customer as payment for the credit note, combine this with option #2 I 
> >>> listed, and this time, use that Liabilities:Customer Deposits account to 
>

Re: [GNC-dev] About the "$HOME/.local" installation prefix

[Adrien Monteleone]

Good question.

I’ve never used that location, and have not otherwise seen any recommendation 
to use it for a single/local-user installation.

I’ve seen people recommend to recreate the official tree under ~/ (~/usr, 
~/usr/local, ~/usr/bin) which doesn’t make much sense to me, or something else 
like:

~/apps, ~/applications

I would think a recommendation of:

$HOME/apps/gnucash, $HOME/applications/gnucash

would be fine as it would be easier to remove. (one could maybe keep a 
`$HOME/apps/gnucash/build` directory around for that eventual removal)

Regards,
Adrien

> On May 2, 2019, at 6:01 AM, Geert Janssens  wrote:
> 
> Our current wiki on building gnucash for Ubuntu 16.04 (https://
> wiki.gnucash.org/wiki/BuildUbuntu16.04) suggests $HOME/.local as a valid 
> installation prefix.
> 
> While checking for another thread I have found this to be problematic.
> 
> In particular when using this installation prefix, a number of files and 
> directories will be added in $HOME/.local/share/. That directory however is 
> also to primary directory where a running applications store their runtime 
> data. So the same directory is being used as installation directory and data 
> directory.
> 
> That makes it pretty difficult to quickly remove the local gnucash 
> installation in one go as the installation directory may also hold runtime 
> data (and from more than one application!).
> 
> So personally I would recommend against using $HOME/.local as installation 
> prefix. I am however curious where this suggestion originally came from.
> 
> Regards,
> 
> Geert

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

Re: [GNC-dev] [GNC] Recording dividend payoffs

[Adrien Monteleone]

My bad,

I saw the thread starting in the user list, I never saw it in devel. So when I 
replied, I set it to user. I’ll update my filters to file into devel ahead of 
user and be more careful next time when setting my reply address(es).

Regards,
Adrien

> On Apr 16, 2019, at 11:37 AM, John Ralls  wrote:
> 
> Adrien,
> 
> You copied the wrong list, this thread was in gnucash-devel.
> 
> Regards,
> John Ralls
> 
>> On Apr 16, 2019, at 7:47 AM, Adrien Monteleone 
>>  wrote:
>> 
>> If you create an Equity:Retained Earnings account and debit it, while 
>> crediting Dividends Payable (the formal method) does this not show up on the 
>> Balance Sheet?
>> 
>> I understand that you would have two ‘Retained Earnings’ lines, one being 
>> the actual account and the other being the calculated amount by GnuCash. The 
>> sum of the two should be the true amount. This means you can’t submit the 
>> report as-is, but you could certainly export to a spreadsheet for the small 
>> modification first.
>> 
>> Of course, it would be nice if the report factored in an actual 
>> Equity:Retained Earnings account to its calculation.
>> 
>> There is an alternate practice of using a contra-equity account that is 
>> later closed to Retained Earnings called “Dividends Declared” or simply 
>> “Dividends”. I don’t see much advantage to it since you still have a 
>> liability you can track either way.
>> 
>> Regards,
>> Adrien
>> 
>>> On Apr 16, 2019, at 9:04 AM, Justin Mathew via gnucash-user 
>>>  wrote:
>>> 
>>> Christopher,
>>> 
>>>> The "Retained Earnings" part of the Balance Sheet has nothing to do with 
>>>> dividends.
>>>> 
>>>> IIUC on the balance sheet date X, the retained earnings simply means the 
>>>> total income up to date X, minus total expenses up to date X.
>>> 
>>> Don't get me wrong, the 'retained earnings' anywhere in accounting (not 
>>> just in the balance sheet) should have everything to do with dividends. 
>>> It's the accounting definition that 'Retained earnings' is the business' 
>>> net income - cash/stock dividends.
>>> 
>>> The definition of 'total income minus total expenses' works only for sole 
>>> proprietorships where the business isn't a legal entity in it's own right. 
>>> A registered business, however small it is will have at least one 
>>> shareholder. Most small businesses will have more than one from what I have 
>>> seen.
>>> 
>>>> From your description of 'owning a company with shares' / 'selling shares 
>>>> of company' / 'issuing dividends' I honestly have no idea how the books 
>>>> should look like, nor which chart of accounts should apply, nor whether 
>>>> the GnuCash reports are appropriate to produce useful reports.
>>> 
>>> Oh yes, GnuCash should be able fit in all business, because they all follow 
>>> the same accounting principles. All we need to do is to calculate 'Retained 
>>> Earnings' as per the standard accounting formula - it should account for 
>>> dividends paid.
>>> 
>>> Understanding which transactions are dividends to account for is a problem.
>>> 
>>> Dividends are a decrease in equity and can't be recorded in an 'Expense' 
>>> type account (although that's the current workaround and technically 
>>> wrong). Therefore what I suggest is to create a dividend account type under 
>>> equity (equity currently has only 1 type of account) which can be used to 
>>> record dividend declarations. The value of this account can then be 
>>> adjusted from total income. This will give us the real 'Retained Earnings'.
>>> 
>>> Note that: The corresponding journal entry for recording in dividend 
>>> declaration account is 'dividend payable' (which is a liability account 
>>> created by user). To record a dividend paid, a second record is created in 
>>> 'dividend payable' against the journal 'current account' or 'cash account'.
>>> 
>>> -
>>> Regards,
>>> Justin Mathew
> 


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

Re: [GNC-dev] GnuCash 3 on Linux

[Adrien Monteleone]

Derek,

I don’t disagree with your assessments of what certainly *can* (and maybe even, 
more often than not) be specific to a book rather than a user. I was thinking 
more along the lines of what someone *might* most likely want to carry over 
across multiple books. For example, I keep books for a few entities. Everything 
is in USD. (except for my personal book which has a smattering of left over 
currency from travels and some bullion I track as currency) I have no need for 
other currencies, and likely never will. At the least, I’d want to start books 
for a new entity, should one arise, with that same default currency in my 
reports. (simple enough since the default book currency is also the default 
report currency)

But I might also like to never show zero balance amounts or the corresponding 
accounts, and I might like to always roll up the sub account totals into the 
parent (since I set all parents as placeholders) and *not* show any duplicative 
’total’ lines.

These were the types of settings I was thinking of that someone might want to 
carry over across all books and maybe even all reports. (where applicable) The 
same might very well applied to financial periods.

Separating preferences for reports is, I suspect, more useful to a multi-user 
environment, which GnuCash does not support, but can be useful for a single 
user who keeps books for multiple entities that are all in the same 
jurisdiction and might well even use the same CPA. (and certainly have to file 
the same tax forms) They might even all follow a July-June fiscal year, for 
example.

It might be that this is too small of a use case, and the user’s setup work so 
light that the development burden is simply not worth the effort. (and I’m by 
no means advocating for more work for the team already, I’m just chiming in 
with my own user story to consider.)

I started a project to map out report preferences as part of a revamp of the 
tab content and I didn’t finish it. Perhaps completing that project will offer 
more insight. (and very likely allow me to discover that the present situation 
is optimal)

Regards,
Adrien

> On Mar 7, 2019, at 10:14 AM, Derek Atkins  wrote:
> 
> hi,
> 
> Adrien Monteleone  writes:
> 
>> I’ll hazard a quick guess that everything not in the accounts tab is
>> non-book specific.
> 
> I'm not sure I completely agree with this statement.
> 
>> At the very least, the display and general tabs are not.
> 
> Maybe..
> 
>> How you want figures to be displayed, which sets of figures, which periods...
> 
> Different companies might have different periods; therefore, the period
> is tied to the book, not the person.
> 
>> Content settings may be tied to the book, but formatting settings are
>> likely to be the most likely to be used cross-book. I can certainly
>> see someone wanting all of their reports looking the same.
> 
> I mostly agree with this statement, but I think it depends greatly on
> the definitions of "content settings" and "formatting settings".  Sure,
> window sizes, tabs v windows, color schemes -- those are clearly
> formatting setting and should be per-user.  But "default currency",
> "periods", and certain parts of report configurations (e.g. accounts to
> include) are definitely content settings and belong with the book data.
> 
>> Regards,
>> Adrien
> 
> -derek

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

Re: [GNC-dev] GnuCash 3 on Linux

[Adrien Monteleone]

I’ll hazard a quick guess that everything not in the accounts tab is non-book 
specific.

At the very least, the display and general tabs are not.

How you want figures to be displayed, which sets of figures, which periods...

Content settings may be tied to the book, but formatting settings are likely to 
be the most likely to be used cross-book. I can certainly see someone wanting 
all of their reports looking the same.


Regards,
Adrien

> On Mar 6, 2019, at 9:18 AM, Derek Atkins  wrote:
> 
> Hi,
> 
> Coming at this late...
> 
> Geert Janssens  writes:
> 
>> For starters the user preference is an all or nothing thing, either all 
>> reports are in a book or in a common location. That's not very fine-grained. 
>> Perhaps you consider some reports common and some reports book-specific. 
>> This 
>> could be solved by making it a per report option of course.
> 
> I can picture very few cases where a configured report is not tied to
> the book.  If it contains references to *ANY* accounts, then it is, by
> definition, book-specific and should live with the data.  This is, IMHO,
> most reports.
> 
>> And yet another issue: reports are only suitable for multiple books if these 
>> books have the exact same base as required per report. An example to clarify 
> 
> EXACTLY!
> 
> The only time all saved-reports are useful across books is if the books
> are derived from the same base.  I.e., you copy, or save-as.
> 
> If the reports are stored in the book data itself then you get this for
> free.
> 
> [snip]
>> So my conclusion is that report configurations are essentially book specific 
>> and should be treated as such to avoid unexpected accounting mistakes.
> 
> Agreed.
> 
>> On the other hand I understand it takes time to carefully configure
>> reports to your preference and there's a wish to reuse this effort
>> across books.
> 
> Perhaps we need an "export report configuration" that can extract the
> non-book-specific settings?
> 
> -derek
> 


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

Re: [GNC-dev] GnuCash 3 on Linux

[Adrien Monteleone]

One might want the same configuration in many respects and the same options on 
various reports to be ’saved’ (since there is no other way to accomplish this 
task) as user configured defaults to be useful across various books.

Some people have separate files for many entities and they shouldn’t have to 
re-create all of that work for each one. You might always want to roll up child 
totals to the parent or not show zero balance accounts for example, regardless 
of the entity you are running reports for. Your accountant might always want to 
see reports following a certain format, different from the GnuCash defaults, 
regardless of the entity.

But I also see the case where multiple users might access the same data file 
and you’d want them all to have the same configuration for the book options and 
a standard set of reports to be able to run.

Certainly, there is room for improvement for a multi-user environment. (which 
GnuCash does not officially support at present from my understanding)

Perhaps the user environment itself should be an option which would determine 
where the various configurations are stored. (or more likely, how they are 
stored, as they should probably all be located *with* the data file, though not 
necessarily a part of it.)

Another option, specific to reports would be the ability to create a ‘custom 
default’ set of options. This would allow the creation of new books without 
having to 'remake the wheel’. (I understand ‘custom default’ may sound absurd 
to some, but think of this more like a ’template’.)

Regards,
Adrien

> On Feb 23, 2019, at 8:53 PM, David T. via gnucash-devel 
>  wrote:
> 
> Storing configuration data separately from the financial data and on a user 
> (as opposed to a book) basis is questionable.
> 
> Storing saved reports separately from the financial data and on a user basis 
> makes no sense at all. A saved report for one file will be meaningless in 
> another. This issue has come up many times on the lists. 
> 
> The fact that we even need a wiki page dedicated to file and configuration 
> locations-- let alone one as long and convoluted as the one we have (and 
> which needs additional diagramming)-- only underscores this problem. 
> 
> I want to be clear that I am truly grateful that Chris has decided to work on 
> reports, and I have great respect for his ability to work with Scheme. I've 
> yet to succeed in either editing an existing report or getting a third party 
> report installed on my Mac. 13 years of futility on that front!
> 
> David T. 
> 

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

Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me

[Adrien Monteleone]

Please tell me the intent is to *add* the book currency value, not replace the 
actual currency value.

I would hope that the actual currency transaction data would still be 
available. If you have to reconcile against statements or receipts (or suffer 
an audit) with foreign amounts sans their ‘book currency’ equivalents, such 
original data would be critical.

If so, this is how I originally conceived GC was operating till I learned 
otherwise.

Regards,
Adrien

> On Feb 10, 2019, at 1:46 PM, Alex Aycinena  wrote:
> 
> 
> The 'book currency' feature is intended to deal with this by, if the 'book
> currency' feature is selected, forcing every non-book-currency split to be
> denominated in book-currency (i.e., like the trick, above, but without
> having to use a third account register) and enforcing lot tracking for each
> of these transactions (to get rid of all the off-line calculations), thus
> providing a basis for tracking cost and eliminating the need for an
> external price reference (unless you want to see an estimate of current
> value).
> 


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

Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me

[Adrien Monteleone]

I’m in agreement on that note. I understand why someone who doesn’t close books 
would like a report that shows a current position. But the Trial Balance report 
is really only useful for the close books crowd. It should only reflect actual 
transactions in the various registers. In the case of assets then, it shouldn’t 
be estimating based on any user choice of average, nearest date or such, it 
should be taking actual purchase price just like you would if you did it on 
paper.

Regards,
Adrien

> On Feb 10, 2019, at 2:47 AM, D via gnucash-devel  
> wrote:
> 
> Ok. I'll preface my comments with the note that every time I try to 
> understand how the trial balance report works, someone on the list points out 
> how misguided my understanding is
> 
> That being said, I don't understand how a trial balance of completed 
> transactional history could change value based on a change in price history 
> settings. The euros I bought last week might be worth more this week, but I'd 
> expect the report to be based on what was real, versus the imaginary value 
> those euros have gained or lost since then.
> 
> David T.
> 
> On February 10, 2019, at 2:40 AM, David Carlson  
> wrote:
> 
> Following up on my last email, in version 2.6.17 the Trial Balance report 
> does default to nearest in time as the default valuation procedure.   I don't 
> know what happens in 3.4.
> 
> 
> David Carlson
> 

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

Re: [GNC-dev] Register window - Reconciliation Flag

[Adrien Monteleone]

Same behavior on MacOS.

Regards,
Adrien

> On Jan 31, 2019, at 4:19 AM, Geert Janssens  
> wrote:
> 
> 
> The *R* is there in single line mode. In transaction journal mode it will 
> only 
> be there if the currently selected line is a split. It will be gone if the 
> currently selected line is the transaction line.
> 
> At least that's what I see on Fedora 29 with the most recent maint build...
> 
> Regards,
> 
> Geert

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

Re: [GNC-dev] [GNC] New Budget Bar Chart Not Displaying

[Adrien Monteleone]

Okay, disregard other message that just crossed this one.

Regards,
Adrien

> On Jan 24, 2019, at 5:43 AM, Christopher Lam  
> wrote:
> 
> Best build entire branch because of new chartjs dependencies
> 
> On 24/1/19 7:35 pm, Adrien Monteleone wrote:
>> I haven’t built from git yet. (no time like the present) Do I build the 
>> entire branch or can I just dl and build the report?
>> 
>> Regards,
>> Adrien
>> 
>>> On Jan 24, 2019, at 5:09 AM, Christopher Lam  
>>> wrote:
>>> 
>>> Perhaps you can beta-test the budget-barchart, with the report start/end 
>>> dates options removed.
>>> 
>>> This also includes chartJS preview ;-)
>>> 
>>> https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart
>>> 
>>> On 24/1/19 1:42 am, Adrien Monteleone wrote:
>>>> Good question — I think the budget reports are fine, it seems to be the 
>>>> chart that is the odd one out.
>>>> 
>>>> As it is currently, for all of the budget reports, you choose the budget 
>>>> you want to report on and the range is determined accordingly. You can’t 
>>>> set it independently. I have no problem with this. I can’t see why someone 
>>>> would want to select a budget to report or chart, but want GC to use 
>>>> transactions from out of the budget period. (well, for comparing 
>>>> performance, sure, but it doesn’t work that way anyway, the Transaction 
>>>> Report is better suited there - see below)
>>>> 
>>>> But for the chart, you can choose, as in my example, last year’s budget 
>>>> (or anything other than current year) but the default date window is for 
>>>> this year, which would render no data. Since you can select the budget and 
>>>> date range separately, you can easily end up with either no results, 
>>>> incomplete results, or possibly non-sensical results.
>>>> 
>>>> For consistency, the chart should probably pull the date range from the 
>>>> budget choice like the reports do and not offer the options to set the 
>>>> range independently.
>>>> 
>>>> -
>>>> 
>>>> Now, if the reports and charts allowed you to independently select a 
>>>> budget and date-range for comparison of budget vs. actual (of the chosen 
>>>> period) that would be much more versatile. As it presently stands, you 
>>>> have to copy or re-do your budget each year/quarter. But if you could 
>>>> report a static budget against variable periods, you could have budgets 
>>>> based on something other than dates. (such as different scenarios, 
>>>> regardless of the period)
>>>> 
>>>> Making the change that direction would not remove the ability to produce 
>>>> and analyze budget performance on a period basis though. If that route is 
>>>> chosen, I’d suggest some sort of default report/chart page to explain what 
>>>> options need to be chosen to get a desired result. (similar to how some 
>>>> other reports tell you that you need to select some accounts or certain 
>>>> options, rather than just dumping you to a blank page. Note, this would be 
>>>> a good improvement for any report/chart that requires setting options to 
>>>> get a usable result or non-blank page.)
>>>> 
>>>> I’m not sure how difficult it would be to have the reports and chart look 
>>>> for budgeted amounts statically but actual performance based on a 
>>>> separately specified range. This might also necessitate some change to the 
>>>> budget options where you would assign values for a generic period without 
>>>> regard to a specific year.
>>>> 
>>>> While that all might be nice, the easiest thing to fix right now, I think 
>>>> would be to pattern the General tab of the budget chart similar to the 
>>>> various budget reports.
>>>> 
>>>> Regards,
>>>> Adrien
>>>> 
>>>>> On Jan 23, 2019, at 10:14 AM, Christopher Lam  
>>>>> wrote:
>>>>> 
>>>>> Directed towards Adrien- how should the budgeting reporting options look 
>>>>> like?
>>>>> 
>>>>> Budget has start-date and num(periods)
>>>>> 
>>>>> Budget-report-date has its own start-date and end-date -- they should be 
>>>>> removed?
>>>>>

Re: [GNC-dev] [GNC] New Budget Bar Chart Not Displaying

[Adrien Monteleone]

I see looking deeper there is a budget-barchart.scm.

Can I just grab that and add it as a custom report? or do I still need to build 
something (or everything) from your branch?

Sorry for the noob git questions.

Regards,
Adrien

> On Jan 24, 2019, at 5:35 AM, Adrien Monteleone 
>  wrote:
> 
> I haven’t built from git yet. (no time like the present) Do I build the 
> entire branch or can I just dl and build the report?
> 
> Regards,
> Adrien
> 
>> On Jan 24, 2019, at 5:09 AM, Christopher Lam  
>> wrote:
>> 
>> Perhaps you can beta-test the budget-barchart, with the report start/end 
>> dates options removed.
>> 
>> This also includes chartJS preview ;-)
>> 
>> https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart
>> 
>> On 24/1/19 1:42 am, Adrien Monteleone wrote:
>>> Good question — I think the budget reports are fine, it seems to be the 
>>> chart that is the odd one out.
>>> 
>>> As it is currently, for all of the budget reports, you choose the budget 
>>> you want to report on and the range is determined accordingly. You can’t 
>>> set it independently. I have no problem with this. I can’t see why someone 
>>> would want to select a budget to report or chart, but want GC to use 
>>> transactions from out of the budget period. (well, for comparing 
>>> performance, sure, but it doesn’t work that way anyway, the Transaction 
>>> Report is better suited there - see below)
>>> 
>>> But for the chart, you can choose, as in my example, last year’s budget (or 
>>> anything other than current year) but the default date window is for this 
>>> year, which would render no data. Since you can select the budget and date 
>>> range separately, you can easily end up with either no results, incomplete 
>>> results, or possibly non-sensical results.
>>> 
>>> For consistency, the chart should probably pull the date range from the 
>>> budget choice like the reports do and not offer the options to set the 
>>> range independently.
>>> 
>>> -
>>> 
>>> Now, if the reports and charts allowed you to independently select a budget 
>>> and date-range for comparison of budget vs. actual (of the chosen period) 
>>> that would be much more versatile. As it presently stands, you have to copy 
>>> or re-do your budget each year/quarter. But if you could report a static 
>>> budget against variable periods, you could have budgets based on something 
>>> other than dates. (such as different scenarios, regardless of the period)
>>> 
>>> Making the change that direction would not remove the ability to produce 
>>> and analyze budget performance on a period basis though. If that route is 
>>> chosen, I’d suggest some sort of default report/chart page to explain what 
>>> options need to be chosen to get a desired result. (similar to how some 
>>> other reports tell you that you need to select some accounts or certain 
>>> options, rather than just dumping you to a blank page. Note, this would be 
>>> a good improvement for any report/chart that requires setting options to 
>>> get a usable result or non-blank page.)
>>> 
>>> I’m not sure how difficult it would be to have the reports and chart look 
>>> for budgeted amounts statically but actual performance based on a 
>>> separately specified range. This might also necessitate some change to the 
>>> budget options where you would assign values for a generic period without 
>>> regard to a specific year.
>>> 
>>> While that all might be nice, the easiest thing to fix right now, I think 
>>> would be to pattern the General tab of the budget chart similar to the 
>>> various budget reports.
>>> 
>>> Regards,
>>> Adrien
>>> 
>>>> On Jan 23, 2019, at 10:14 AM, Christopher Lam  
>>>> wrote:
>>>> 
>>>> Directed towards Adrien- how should the budgeting reporting options look 
>>>> like?
>>>> 
>>>> Budget has start-date and num(periods)
>>>> 
>>>> Budget-report-date has its own start-date and end-date -- they should be 
>>>> removed?
>>>> 
>>>> I don't use the budgeting tools myself.
>>>> 
>>>> (ytd-budget.scm from years back seems to be a good report)
>>>> 
>>>> On 23/1/19 11:37 pm, Adrien Monteleone wrote:
>>>>> This means the date range for the report (default is start & end of 
>>>>> curr

Re: [GNC-dev] [GNC] New Budget Bar Chart Not Displaying

[Adrien Monteleone]

I haven’t built from git yet. (no time like the present) Do I build the entire 
branch or can I just dl and build the report?

Regards,
Adrien

> On Jan 24, 2019, at 5:09 AM, Christopher Lam  
> wrote:
> 
> Perhaps you can beta-test the budget-barchart, with the report start/end 
> dates options removed.
> 
> This also includes chartJS preview ;-)
> 
> https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart
> 
> On 24/1/19 1:42 am, Adrien Monteleone wrote:
>> Good question — I think the budget reports are fine, it seems to be the 
>> chart that is the odd one out.
>> 
>> As it is currently, for all of the budget reports, you choose the budget you 
>> want to report on and the range is determined accordingly. You can’t set it 
>> independently. I have no problem with this. I can’t see why someone would 
>> want to select a budget to report or chart, but want GC to use transactions 
>> from out of the budget period. (well, for comparing performance, sure, but 
>> it doesn’t work that way anyway, the Transaction Report is better suited 
>> there - see below)
>> 
>> But for the chart, you can choose, as in my example, last year’s budget (or 
>> anything other than current year) but the default date window is for this 
>> year, which would render no data. Since you can select the budget and date 
>> range separately, you can easily end up with either no results, incomplete 
>> results, or possibly non-sensical results.
>> 
>> For consistency, the chart should probably pull the date range from the 
>> budget choice like the reports do and not offer the options to set the range 
>> independently.
>> 
>> -
>> 
>> Now, if the reports and charts allowed you to independently select a budget 
>> and date-range for comparison of budget vs. actual (of the chosen period) 
>> that would be much more versatile. As it presently stands, you have to copy 
>> or re-do your budget each year/quarter. But if you could report a static 
>> budget against variable periods, you could have budgets based on something 
>> other than dates. (such as different scenarios, regardless of the period)
>> 
>> Making the change that direction would not remove the ability to produce and 
>> analyze budget performance on a period basis though. If that route is 
>> chosen, I’d suggest some sort of default report/chart page to explain what 
>> options need to be chosen to get a desired result. (similar to how some 
>> other reports tell you that you need to select some accounts or certain 
>> options, rather than just dumping you to a blank page. Note, this would be a 
>> good improvement for any report/chart that requires setting options to get a 
>> usable result or non-blank page.)
>> 
>> I’m not sure how difficult it would be to have the reports and chart look 
>> for budgeted amounts statically but actual performance based on a separately 
>> specified range. This might also necessitate some change to the budget 
>> options where you would assign values for a generic period without regard to 
>> a specific year.
>> 
>> While that all might be nice, the easiest thing to fix right now, I think 
>> would be to pattern the General tab of the budget chart similar to the 
>> various budget reports.
>> 
>> Regards,
>> Adrien
>> 
>>> On Jan 23, 2019, at 10:14 AM, Christopher Lam  
>>> wrote:
>>> 
>>> Directed towards Adrien- how should the budgeting reporting options look 
>>> like?
>>> 
>>> Budget has start-date and num(periods)
>>> 
>>> Budget-report-date has its own start-date and end-date -- they should be 
>>> removed?
>>> 
>>> I don't use the budgeting tools myself.
>>> 
>>> (ytd-budget.scm from years back seems to be a good report)
>>> 
>>> On 23/1/19 11:37 pm, Adrien Monteleone wrote:
>>>> This means the date range for the report (default is start & end of 
>>>> current accounting period) does not match the budget.
>>>> 
>>>> For example, I opened a chart for the 2018 budget and got a blank page.
>>>> 
>>>> When I changed the date range to start & end of previous year, I got 
>>>> charts for my selected accounts with budget and actual bars.
>>>> 
>>>> Regards,
>>>> Adrien
>>>> 
>> 
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


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

Re: [GNC-dev] [GNC] New Budget Bar Chart Not Displaying

[Adrien Monteleone]

Good question — I think the budget reports are fine, it seems to be the chart 
that is the odd one out.

As it is currently, for all of the budget reports, you choose the budget you 
want to report on and the range is determined accordingly. You can’t set it 
independently. I have no problem with this. I can’t see why someone would want 
to select a budget to report or chart, but want GC to use transactions from out 
of the budget period. (well, for comparing performance, sure, but it doesn’t 
work that way anyway, the Transaction Report is better suited there - see below)

But for the chart, you can choose, as in my example, last year’s budget (or 
anything other than current year) but the default date window is for this year, 
which would render no data. Since you can select the budget and date range 
separately, you can easily end up with either no results, incomplete results, 
or possibly non-sensical results.

For consistency, the chart should probably pull the date range from the budget 
choice like the reports do and not offer the options to set the range 
independently.

-

Now, if the reports and charts allowed you to independently select a budget and 
date-range for comparison of budget vs. actual (of the chosen period) that 
would be much more versatile. As it presently stands, you have to copy or re-do 
your budget each year/quarter. But if you could report a static budget against 
variable periods, you could have budgets based on something other than dates. 
(such as different scenarios, regardless of the period)

Making the change that direction would not remove the ability to produce and 
analyze budget performance on a period basis though. If that route is chosen, 
I’d suggest some sort of default report/chart page to explain what options need 
to be chosen to get a desired result. (similar to how some other reports tell 
you that you need to select some accounts or certain options, rather than just 
dumping you to a blank page. Note, this would be a good improvement for any 
report/chart that requires setting options to get a usable result or non-blank 
page.)

I’m not sure how difficult it would be to have the reports and chart look for 
budgeted amounts statically but actual performance based on a separately 
specified range. This might also necessitate some change to the budget options 
where you would assign values for a generic period without regard to a specific 
year.

While that all might be nice, the easiest thing to fix right now, I think would 
be to pattern the General tab of the budget chart similar to the various budget 
reports.

Regards,
Adrien

> On Jan 23, 2019, at 10:14 AM, Christopher Lam  
> wrote:
> 
> Directed towards Adrien- how should the budgeting reporting options look like?
> 
> Budget has start-date and num(periods)
> 
> Budget-report-date has its own start-date and end-date -- they should be 
> removed?
> 
> I don't use the budgeting tools myself.
> 
> (ytd-budget.scm from years back seems to be a good report)
> 
> On 23/1/19 11:37 pm, Adrien Monteleone wrote:
>> This means the date range for the report (default is start & end of current 
>> accounting period) does not match the budget.
>> 
>> For example, I opened a chart for the 2018 budget and got a blank page.
>> 
>> When I changed the date range to start & end of previous year, I got charts 
>> for my selected accounts with budget and actual bars.
>> 
>> Regards,
>> Adrien
>> 
> 


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

Re: [GNC-dev] AppImage

[Adrien Monteleone]

Good to know, thanks!

Regards,
Adrien

> On Jan 16, 2019, at 8:08 AM, Derek Atkins  wrote:
> 
> For the record, nightly maint and master builds are happening now.
> We are still working to get tag builds done.
> However, we probably wont be able to "announce" their general
> availability for another ~6 months due to network constraints.
> 
> -derek
> 
> "Alen Siljak"  writes:
> 
>> That's great news!
>> I've collected the links I found so far to this issue:
>> https://bugs.gnucash.org/show_bug.cgi?id=796019
>> It is now closed since the AppImage is there and there are ongoing
>> efforts in getting an official Flatpak image.
>> 
>>> Sent: Friday, January 11, 2019 at 6:34 PM
>>> From: "Derek Atkins" 
>>> To: cicko 
>>> Cc: gnucash-devel@gnucash.org
>>> Subject: Re: [GNC-dev] AppImage
>>> 
>>> For the record, we are working on getting a Flatpak build done locally.
>>> It's on my to-do to set up a "nightly" build.
>>> -derek
>>> 
>>> cicko  writes:
>>> 
 Someone actually created an AppImage repo for GnuCash at
 https://github.com/ecmu/gnucash.AppImage
>> 
>> 
> 
> -- 
>   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] [GNC] Reconciliation Report -- Can't find transactions

[Adrien Monteleone]

Christopher,

There is another current thread on gnucash-user looking for something similar: 
https://lists.gnucash.org/pipermail/gnucash-user/2019-January/081941.html

Can you share your report files there or does the new version also require 
changes to other parts of gnucash to make it work?

Regards,
Adrien

> On Jan 13, 2019, at 9:39 AM, Christopher Lam  
> wrote:
> 
> Hi
> 
> If you can pull from my git again I think you'll find the reconcile report 
> now matches the formal tool very well.
> 
> 1. disable date filter - i.e. grab *all* transactions
> 2. filter to unreconciled or cleared only
> 3. calculate start/end balances
> 
> Comments welcome.
> 
> On 13/1/19 10:58 am, Liz wrote:
>> On Sat, 12 Jan 2019 18:49:05 +0800
>> Christopher Lam  wrote:
>> 
>>> Please experiment further (1) expand dates eg from 01/01/1980 to
>>> 01/01/2099 (2) let me know the characteristics of the 77 missing
>>> amounts
>>> - are they unreconciled/cleared/reconciled?
>>> 
>>> I guess you can build from source, would you care to try
>>> https://github.com/christopherlam/gnucash/tree/maint-scheme-progress-and-reconcile-header
>>> which will add a reconcile-report header?
>> 
>> This is the result from the the git build, working from a copy of my
>> file
>> I suppressed the description column
>> No transactions from 31/8/18 to 31/12/18
>> 77 or so in the file.
>> 
>> Liz
>> 
>> ___
>> 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] Reports -- Cleanup

[Adrien Monteleone]

Stephen, while I agree in principle that the reports need cleanup, as a user, I 
don’t want to see functionality removed, just moved. Consider the following:

For example on your #1,

Why do I need to see the credit split for every transaction when running the 
report for an expense account? Maybe I want to know where the money came from, 
but more likely, I want to know who I paid it to and when and how much. Maybe 
I’d like some 'how much' totals for the 'who to' and when ‘questions'. To have 
to see the other side of every transaction even for a few dozen is unnecessary 
clutter, imagine a report with hundreds of transactions. One purpose of a 
report is to condense/consolidate information. This would turn the Transaction 
Report into just a fancy Register Report. I might as well look at the expense 
register itself then run a report.

On the #2,

So I shouldn’t be able to see what else might have happened in that 
transaction, but I always have to see both the credit and debit sides of it? 
How is that consistent? or possible? If I can’t see the other splits, I can’t 
see the balancing part of the transaction like you want in #1, or, maybe I see 
a debit to an expense and the credit to checking, but maybe there were other 
offsetting debits for other expense accounts in that transaction. Now I’m 
looking at an expense debit that is less than the credit line and things don’t 
balance at the least, and worst, now I have clutter that gives me no useful 
information and can’t see the info I might want to see. (such as, is there a 
pattern that two expenses go together?)

I do agree however that the Transaction report is really more of a ‘master 
report’ of sorts. The multi-column is another. There might be others.

Those should probably be either in their own sub-menu, or the only ones in the 
main Reports menu. Then the various useful reports one routinely needs that are 
based off of those masters can be in the topic specific sub-menus.

I don’t see the myriad of options as ‘gold plating’ I see them as making the 
report more useful. (though obtuse as well)

Perhaps if some more routine and useful reports were created from this and 
added to the relevant sub-menus, less people would need the ‘master report’ 
though it can still be there for those who know how to wield its power.

Just my 2¢.

Regards,
Adrien

> On Jan 7, 2019, at 4:50 PM, Stephen M. Butler  wrote:
> 
> I think one of the developers here mentioned that there is a lot of
> duplication in the reports arena.  I concur.  At first it was very
> confusing as to which was the "correct" one.  Finally figured out none
> where -- according to the in house SME (pronounced "smee" and standing
> for Subject Matter Expert) and needed to roll my own.  Of which, I only
> have the Balance Sheet sorta working like she wants it.
> 
> Following some email exchange via the bug reporting system regarding the
> Transaction report module, I agree that it has too many options already
> and requires a near programmer to figure out which options need to be
> set what way to get something close to desirable.
> 
> Please note that I'm not a smee in this arena and, with my project
> manager hat on, my wife barely qualifies.  There are others on this
> mailing list better qualified who will have differing opinions. 
> 
> However, here are my thoughts:
> 
> 1.  A transaction report (however it is organized) should always show
> the split amount.  I propose that the Amount (None, Single, Double)
> option be removed and the report always produces the Amount in two
> columns Debit to the left and Credit to the right. 
> 
> 2.  The Multi-line versus Single-line option may add confusion.  If one
> wants to group the splits in a transaction together, then the report
> should be organized that way.  When one picks the multi-line option, the
> report becomes hard to read and understand especially as the other
> splits are not included in the totals.  I suggest that Single-line be
> the reporting style and the multi-line (meaning -- as best I can
> determine -- multi-splits) removed.
> 
> These are just two of many simplifications that could be made to help
> guide the end-user into the reports they need rather than letting them
> create a report that is useless to them and anybody else.
> 
> Along those lines, I see this code needing to generate the following
> types of reports:
> 
> A.  Transaction Journal -- this one lists the transactions within the
> date range in date order and keeps all the splits together on the
> report.  A printed version of the General Ledger screen (in multi-split
> mode).
> 
> B.  Reconciliation Report -- rather than have the user pick the
> accounts, a first pass should show the Dates within Accounts for which
> there were reconciliations done (with the date range selected).  Let the
> user select one or more of these to be reported, but each selection
> becomes its own report or page.  Usually show the transactions
> reconciled on that date (by 

Re: [GNC-dev] Launchpad

[Adrien Monteleone]

I haven’t. I did try to download the 1.58-dev files from the Xenial repo, but 
that’s when I hit a wall of additional dependencies and decided further effort 
wasn’t worth the trouble.

I don’t need it for my own use. I was just testing it because I had time.

I daily use GnuCash on High Sierra.

I suspect though that I’d still get the error as it was looking for a 1.58 
version it couldn’t find despite that I had 1.65 installed. (and then upgraded 
to 1.67, still to no effect)

When I tried to start unraveling everything back to a prior state (I should 
have just taken a snapshot of the VM) I learned that libboost is also used by 
LibreOffice so most systems will probably have it, just not the version spec’d 
for the Disco .deb.

Note, I also have not tried Stephen’s .deb file. I was only testing the one 
from the Disco repos he linked today. I’m not sure if that would have made a 
difference.

Regards,
Adrien
> On Jan 3, 2019, at 6:40 PM, David Cousens  wrote:
> 
> Adrien,
> 
> Have you loaded and compiled with the libboost-dat-time-dev headers
> installed. I have libboost-date-time-dev,  libboost-date-time1.65-dev and
> libboost-date-time1.65.1 loaded on Linux Mint 19 (Ubuntu Bionic 18.04) and
> it builds and compiles without any problem.. dpkg -l | grep
> libboost-date-time will list the installed libraries
> 
> I think I used sudo apt install libboost-all-dev to install the headers
> although apt-cache lists libboost-dev as the default header files and it
> also only lists libboost-date-time1.65-dev and libboost-date-time1.65.1. I
> think libboost-date-time-dev is a hangover or a dependency for another
> program I build
> 
> David Cousens
> 
> 
> 
> -
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 


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

Re: [GNC-dev] Launchpad

[Adrien Monteleone]

I found this:

https://lists.gnucash.org/pipermail/gnucash-user/2019-January/081695.html

noting that the following needed to be installed:

libboost-filesystem1.65.1
libboost-date-time1.65.1
libboost-locale1.65.1
libboost-regex1.65.1

But my error was for 1.58, not 1.65 missing

I installed them anyway, with no effect on the error. (as expected)

After some investigation, it seems 1.58 was in Xenial. (this was the original 
OS installed in this VM and it has undergone two in-place upgrades to Bionic 
and now Cosmic) It seems the upgrade didn’t play nice and now my software is 
still looking for old versions of libraries. (or the Xenial version of GnuCash 
didn’t uninstall properly)

I downloaded the libboost-date-time1.58 deb but that gave me another 
dependency, which I downloaded and upon trying to install that, was hit with 
about 6 more dependencies.

I’m giving up.

Perhaps a fresh Cosmic install will play much nicer.

At this point, it would be much simpler just to build from source.

Sorry I couldn’t give you a definitive “It works!”

Regards,
Adrien

> On Jan 3, 2019, at 4:24 PM, Adrien Monteleone 
>  wrote:
> 
> I have a Cosmic VM handy so I tested the Disco .deb via “dpkg -i” and here 
> was the result:
> 
> 
> dpkg: dependency problems prevent configuration of gnucash:
> gnucash depends on gnucash-common (= 1:3.4-1); however:
>  Package gnucash-common is not installed.
> gnucash depends on libboost-regex1.67.0 (>= 1.67.0-10); however:
>  Package libboost-regex1.67.0 is not installed.
> gnucash depends on libicu63 (>= 63.1-1~); however:
>  Package libicu63 is not installed.
> gnucash depends on libpython3.7 (>= 3.7.0); however:
>  Package libpython3.7 is not installed.
> gnucash depends on libfinance-quote-perl; however:
>  Package libfinance-quote-perl is not installed.
> gnucash depends on libhtml-tableextract-perl; however:
>  Package libhtml-tableextract-perl is not installed.
> 
> dpkg: error processing package gnucash (--install):
> dependency problems - leaving unconfigured
> 
> I did an ‘apt search’ on the missing dependencies with the following results:
> 
> gnucash-common, libicu63 (“International Components for Unicode”) and the 
> required version of libboost-regex1.67.0 are not in Cosmic, you’ll need to 
> download them from Disco.
> 
> gnucash-common: https://packages.ubuntu.com/disco/gnucash-common
> 
> libicu63: https://packages.ubuntu.com/disco/libicu63
> 
> libboost-regex1.67.0: https://packages.ubuntu.com/disco/libboost-regex1.67.0
> 
> Download those files, but do not install them yet.
> 
> First, install these:
> 
> sudo apt libfinance-quote-perl libhtml-tableextract-perl libpython3.7 
> libpython3.7-minimal libpython3.7-stdlib
> 
> (those last two are dependencies of libpython3.7 and are in Cosmic)
> 
> 
> *adjust the following package names for your architecture:
> 
> 
> Then install libboost-regex1.67.0:
> 
> sudo dpkg -i libboost-regex1.67.0_1.67.0-11_amd64.deb
> 
> 
> 
> Then install libicu63:
> 
> sudo dpkg -i libicu63_63.1-5_amd64.deb
> 
> 
> 
> Then instal gnucash-common:
> 
> sudo dpkg -i gnucash-common_3.4-1_all.deb
> 
> 
> 
> Then finally, install gnucash:
> 
> sudo dpkg -i gnucash_3.4-1_amd64.deb
> 
> --
> 
> Note that I went in reverse as I was trying to find and then install the 
> dependencies, so at some point, I got the advice from apt to try ‘apt 
> --fix-broken install’ which pulled in libfinance-quote-perl 
> libhtml-tableextract-perl libpython3.7 libpython3.7-minimal 
> libpython3.7-stdlib as the rest was already installed but not completely 
> configured.
> 
> Now, GC still doesn’t run and I’m getting an error:
> 
> gnucash: error while loading shared libraries: libboost_date_time.so.1.58.0: 
> cannot open shared object file: No such file or directory
> 
> I recall someone encountered that in the *.deb thread, so I’ll go look there 
> to see if there was a resolution. This file doesn’t appear to be in any 
> ubuntu repos.
> 
> Regards,
> Adrien
> 
> 
> 
>> On Jan 3, 2019, at 3:46 PM, Stephen M. Butler  wrote:
>> 
>> Thanks.  I checked the trusty and others and they had older versions. 
>> So, maybe not so good news.
>> 
>> But, if I can get his debian folder
>> 
>> On 1/3/19 1:34 PM, Colin Law wrote:
>>> On Thu, 3 Jan 2019 at 21:28, Stephen M. Butler  wrote:
>>>> mirrors.kernel.org/ubuntu
>>>> <http://mirrors.kernel.org/ubuntu/pool/universe/g/gnucash/gnucash_3.4-1_amd64.deb>
>>>> 
>>>> Colin, do you have a machine on which this can be tested?
>>> Yes, on Ubuntu 18.10.  Note that I think this is intended for disco

Re: [GNC-dev] Launchpad

[Adrien Monteleone]

Single board computers such as the various Pi boards will benefit from armhf if 
not arm64, not sure any machines out there in userland would need the ppc64el 
port. (a little-endian build for Power based chips)

arm64 is the ‘default’ but most of the Pi boards, including the RaspberryPi3 
use armhf, which stands for ‘hard float’. Raspian was a hack to work around the 
lack of floating point support of the early RaspberryPi boards, but now it can 
run straight debian using the armhf port.

I can’t seem to find anything definitive concerning differences between arm64 
and armhf and what machines might use arm64 in the wild.

Also, some newer Chromebooks are shipping with ARM chips instead of Intel.

Regards,
Adrien

> On Dec 31, 2018, at 2:16 PM, Stephen M. Butler  wrote:
> 
> On 12/31/18 11:52 AM, Adrien Monteleone wrote:
>> Stephen,
>> 
>> I could be mistaken, but doesn’t Launchpad have automated build facilities 
>> to target different releases? That might ease providing packages for the LTS 
>> versions and the current regular version even if you aren’t running them 
>> yourself. That won’t help derivative distros but as people discover which 
>> one works best, that info can be passed on for those users.
>> 
>> Regards,
>> Adrien
> 
> 
> If I am reading their documentation correctly, you can pick several
> environments to which they will build deb files. 
> 
> I believe these architectures were supported:
> 
> X86, AMD64, arm64, armhf, ppc64el
> 
> 
> In addition, you could pick several release environments including:
> 
> Ubuntu:  Cosmic, Bionic, Xenial, Trusty
> 
> Debian: Stretch, Jessie, Wheezy, SID
> 
> 
> It sounded like all that had to happen is to push a tarball up with the
> ./Debian folder already populated and their system would build to all
> those environments automatically.
> 
> --Steve
> 
> PS  I'm not sure what arm64, armhf, and ppc64el would do for GnC!
> 
>> 
>>> On Dec 31, 2018, at 11:55 AM, Stephen M. Butler  wrote:
>>> 
>>> On 12/31/18 9:47 AM, Colin Law wrote:
>>>> I don't think the guys/gals that maintain the official Debian and
>>>> Ubuntu packages are on this list, though I may be wrong.
>>>> 
>>>> Colin
>>> 
>>> 
>>> Perhaps the question then becomes:  Is the team willing to support an
>>> unofficial PPA for the latest version of GnC?
>>> 
>>> If so, I'll do more research.  If not, I'll stop.
>>> 
>>>> On Mon, 31 Dec 2018 at 17:44, Stephen M. Butler  wrote:
>>>>> Dev Team,
>>>>> 
>>>>> So far, three folks have either used or inquired about using the debian
>>>>> package for 3.4.  Marketing theory (no, I'm a software engineer by
>>>>> avocation) says that there are several more that would take advantage if
>>>>> it were more "supported".
>>>>> 
>>>>> Here are my thoughts:
>>>>> 
>>>>> 1. Both Ubuntu (Launchpad) and Debian request certain files in a
>>>>>   ~/debian folder.  Most of these appear to be copies of files the
>>>>>   application already has.  Perhaps a softlink could be put in the
>>>>>   debian folder that points to the original so that changes in the
>>>>>   original automatically show up in the folder.  Does this work via git?
>>>>> 2. I'm willing to coordinate the effort to build that folder (I presume
>>>>>   on the Master branch) but will need volunteers from more technical
>>>>>   folks from time-to-time to handle some of the techy stuff.  I know
>>>>>   the devs are busy squashing bugs so this would have to take a back
>>>>>   seat to that.
>>>>> 3. Building this folder might even be beneficial to the official
>>>>>   packagers for the various distros.
>>>>> 4. One team for whom I did light testing, published a daily build (no
>>>>>   longer daily as the software matured) for the adventurous.
>>>>> 
>>>>> 
>>>>> https://launchpad.net/~subsurface/+archive/ubuntu/subsurface-daily
>>>>> 
>>>>> I would be willing to push the files up to Launchpad if the team sees
>>>>> value in perusing this.  However, I don't want to step on anybodies toes
>>>>> if this would get in the way of the official release process for the
>>>>> various distros.  And, if this got to the point of highly automated,
>>>>> perhaps the dev team would prefer to do the push themselves.
>>>>> 
>>>>> --Steve
> ___
> 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] Launchpad

[Adrien Monteleone]

Stephen,

I could be mistaken, but doesn’t Launchpad have automated build facilities to 
target different releases? That might ease providing packages for the LTS 
versions and the current regular version even if you aren’t running them 
yourself. That won’t help derivative distros but as people discover which one 
works best, that info can be passed on for those users.

Regards,
Adrien

> On Dec 31, 2018, at 11:55 AM, Stephen M. Butler  wrote:
> 
> On 12/31/18 9:47 AM, Colin Law wrote:
>> I don't think the guys/gals that maintain the official Debian and
>> Ubuntu packages are on this list, though I may be wrong.
>> 
>> Colin
> 
> 
> 
> Perhaps the question then becomes:  Is the team willing to support an
> unofficial PPA for the latest version of GnC?
> 
> If so, I'll do more research.  If not, I'll stop.
> 
>> On Mon, 31 Dec 2018 at 17:44, Stephen M. Butler  wrote:
>>> Dev Team,
>>> 
>>> So far, three folks have either used or inquired about using the debian
>>> package for 3.4.  Marketing theory (no, I'm a software engineer by
>>> avocation) says that there are several more that would take advantage if
>>> it were more "supported".
>>> 
>>> Here are my thoughts:
>>> 
>>> 1. Both Ubuntu (Launchpad) and Debian request certain files in a
>>>~/debian folder.  Most of these appear to be copies of files the
>>>application already has.  Perhaps a softlink could be put in the
>>>debian folder that points to the original so that changes in the
>>>original automatically show up in the folder.  Does this work via git?
>>> 2. I'm willing to coordinate the effort to build that folder (I presume
>>>on the Master branch) but will need volunteers from more technical
>>>folks from time-to-time to handle some of the techy stuff.  I know
>>>the devs are busy squashing bugs so this would have to take a back
>>>seat to that.
>>> 3. Building this folder might even be beneficial to the official
>>>packagers for the various distros.
>>> 4. One team for whom I did light testing, published a daily build (no
>>>longer daily as the software matured) for the adventurous.
>>> 
>>> 
>>> https://launchpad.net/~subsurface/+archive/ubuntu/subsurface-daily
>>> 
>>> I would be willing to push the files up to Launchpad if the team sees
>>> value in perusing this.  However, I don't want to step on anybodies toes
>>> if this would get in the way of the official release process for the
>>> various distros.  And, if this got to the point of highly automated,
>>> perhaps the dev team would prefer to do the push themselves.
>>> 
>>> --Steve
>>> 
>>> --
>>> Stephen M Butler, PMP, PSM
>>> stephen.m.butle...@gmail.com
>>> kg...@arrl.net
>>> 253-350-0166
>>> ---
>>> GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
>>> 
>>> ___
>>> gnucash-devel mailing list
>>> gnucash-devel@gnucash.org
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> 
> -- 
> Stephen M Butler, PMP, PSM
> stephen.m.butle...@gmail.com
> kg...@arrl.net
> 253-350-0166
> ---
> GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
> 
> ___
> 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] [GNC] GnuCash 3.4 Released

[Adrien Monteleone]

Awesome! Thanks to the devs for their hard work.

FYI, the GitHub download links for the installers should point to 
/downloads/3.4 instead of /downloads/3.3 or you’ll get a 404.

Regards,
Adrien

> On Dec 30, 2018, at 2:15 PM, David Carlson  
> wrote:
> 
> Wow, that looks like a lot of progress has been made!  Thanks to the
> developers for their hard work!
> 
> David C
> 
> On Sun, Dec 30, 2018 at 2:03 PM John Ralls  wrote:
> 
>> The GnuCash development team announces GnuCash 3.4, the fifth release of
>> the 3.x stable release series.
>> 
>> Changes
>> 
>> Between 3.3 and 3.4, the following bugfixes were accomplished:
>> 
>>• Bug 498072 - GnuCash show taxes on invoice when individual taxes
>> is not checked
>>• Bug 760825 - On duplicating a bill, the entry dates should be
>> set to the bill date, not to the current date - followup:
>> Use neutral time on entry post dates instead of canonical time
>>• Bug 767772 - Associated file with transaction is lost when
>> moving entry between accounts
>>• Bug 775580 - Inaccurate information provided for "Common
>> Accounts" when using "New Account Hierarchy Setup"
>>• Bug 779565 - Treeview header combos do not work at first load
>>• Bug 788332 - Last Reconcile Date column sorts by day of month
>> not date
>>• Bug 789674 - Close Book tool regression
>>• Bug 793156 - Incorrect date sort order in Generic import matcher
>> window
>>• Bug 795080 - Some dates reset to 01/01/1970
>>• Bug 795237 - Update of "wohnungsw" template
>>• Bug 795425 - Version 2018 of german account template SKR49
>>• Bug 796772 - Receivable Ageing Report invalid URL for Totals
>> column
>>• Bug 796806 - Crash after OFX import if line item dragged
>>• Bug 796842 - Add new employee window may not fit on screen
>>• Bug 796849 - Load another QIF file causes "that file already
>> loaded" dialog
>>• Bug 796875 - Unable to use arrow keys to advance past pre-filled
>> text in register
>>• Bug 796878 - test-qofsession fails on x86_32.
>>• Bug 796883 - Register text oddities
>> HOME and END need to be treated like right and left arrow keys.
>>• Bug 796886 - OFX Import does not show source account in the
>> transaction matching window
>>• Bug 796887 - Remove account slot key color if there is no valid
>> color
>>• Bug 796893 - invoice.GetDatePosted() and other date related
>> functions returns strange values for uninitalised dates.
>>• Bug 796896 - Button to complete an export not intuitively placed
>> or discoverable
>>• Bug 796903 - Crash when searching invoice by Invoice Owner
>>• Bug 796914 - Customer Summary is giving error
>>• Bug 796915 - Update Account colour background
>>• Bug 796940 - Invalid transaction date-posted KVP causes
>> date-posted to not be saved.
>>• Bug 796944 - Tab navigation From Company Address field in New
>> Book Options
>>• Bug 796945 - Search Search Criteria window does not scroll when
>> added criteria exceed a certain amount
>>• Bug 796948 - Scheduled Transactions Entered Since Last Run Are
>> not Visible
>>• Bug 796949 - Incorrect conversion of 0,01 USD to EUR
>>• Bug 796960 - Incorrect amount sort order in Generic import
>> matcher window
>>• Bug 796961 - Can't overwrite existing MYSQL database, V3.3.
>>• Bug 796967 - gnclock table not removed when using PostgreSQL.
>>• Bug 796978 - Deleting a split of same account as register
>> cancels the transaction without warning
>>• Bug 796981 - Gnucash crashes with critical error when selecting
>> another file
>>• Bug 796982 - Import Bills & Invoices: change in un_escape()
>> routine causes description and notes fields to be mangled.
>>• Bug 796988 - Untranslated string in CSV transaction importer
>>• Bug 796989 - some date/time does not honor user locale
>>• Bug 796994 - Unable to generate Tax Report because of pricedb
>> error
>> The following fixes and improvements were not associated with bug reports:
>> 
>>• Set up filepath utils to determine the GNC_CONFIG_HOME in the
>> same way as GNC_DATA_HOME.
>> Until now GNC_CONFIG_HOME was more or less hard-coded. Now it can be set
>> via environment variable GNC_CONFIG_HOME. In addition it will automatically
>> be created to avoid potential user confusion.
>>• Redesign gnc-uri-utils
>>• gnc_uri_get_components will now return NULL as protocol
>> if the input is a normal file system path instead of a uri (it used to
>> return 'file')
>>• gnc_uri_get_protocol will now return NULL if the input
>> is a normal file system path instead of a uri (it used to return 'file')
>>• gnc_uri_is_file_protocol now returns FALSE if protocol
>> is NULL (it used to return TRUE)
>>• gnc_uri_is_file_uri now returns FALSE