Re: [GNC-dev] gnucash stable: Remove cruft.

[Geert Janssens]

Op woensdag 20 maart 2024 21:10:07 CET schreef john:
> Geert,
> 
> That ship sailed a really long time ago: You originally added it in
> https://github.com/Gnucash/gnucash/commit/a153412e5a8fca7519fadb62935bab797
> 860fbcd for what became GnuCash 3.0. Meaning that the migration happens when
> the user opens a 2.6 file with 3.0 or later. Nearly everybody has already
> done the migration, plus we advise users who haven't to step through the
> major releases. It seems pretty unlikely that anyone would ever see the
> dialog if we were to put it back and wire it up. Still, IIUC it's only a
> revert plus one line of code so if you really want to it won't take you
> long.
> 
> Regards,
> John Ralls

Hi John,

Indeed *that* particular migration has been a long time ago. As I tried to 
explain, my idea 
was to generalize this to be able to message the user about important stuff 
that might 
happen at early startup. Migrating metadata was the initial example of such a 
thing. At the 
time I was imagining one day also it could be used to inform the user 
saved-reports-xyz be 
converted from the current scheme format to something else (json, xml, ...) or 
any other 
internal conversions we'd do on the metadata.

However I don't really feel strongly about that nor about how I initially 
implemented it. I 
just mentioned it to check if there was common interest to have such a feature.

And your remark also makes we wonder should we really keep the migration code 
itself as 
we are now firmly in the 5.x series which means we have already kept this 
around for 3 
major release cycles ?

Regards,

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

Re: [GNC-dev] gnucash stable: Remove cruft.

[Geert Janssens]

Op zondag 17 maart 2024 09:05:12 CET schreef John Ralls:
> Updatedvia  https://github.com/Gnucash/gnucash/commit/9a39b3cd 
> (commit)
>   from  https://github.com/Gnucash/gnucash/commit/1a806b4e (commit)
> 
> 
> 
> commit 9a39b3cd6966f8d867efed934b6419bfd2ce5a2b
> Author: John Ralls 
> Date:   Sun Mar 17 09:00:32 2024 +0100
> 
> Remove cruft.
> 
> userdata_migration_message was moved to gnucash-core-app.spp by
> c58cfdb 4 years ago and this no-op fragment was left behind.
> 
> 
> 
> Summary of changes:
>  gnucash/gnucash.cpp | 13 -
>  1 file changed, 13 deletions(-)
> 
> ___
> gnucash-patches mailing list
> gnucash-patc...@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-patches

`userdata_migration_msg` never changing from `nullptr` was an oversight during 
the 
conversion.

The code was originally written to inform users when the meta data in 
{USERDATA_HOME} 
and/or {USERCONFIG_HOME} got migrated to a new location. My idea was to 
generalize 
this at some point to be a moment during boot-up to send important messages to 
the 
user.

With the split between gnucash and gnucash-cli, the way to do so depends on 
which 
binary is run. In gnucash one would want to display a dialog box - the part 
removed by this 
commit. In gnucash-cli a message should be printed on the command line. I 
clearly didn't 
work it out fully to actually do so - the dialog would never be displayed.

As these are often one-time messages (like a migration happens only once) I 
found it 
important that both code paths have a good way to show this to the user. Only 
writing to 
the logs would easily go unnoticed, particularly as logs are only kept for one 
gnucash run 
on linux and MacOS.

Regards,

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

Re: [GNC-dev] gnucash stable: Do a better job of including the -py3 option only for swig 4.1

[Geert Janssens]

Op vrijdag 23 februari 2024 01:37:40 CET schreef john:
> > On Feb 22, 2024, at 05:25, Geert Janssens 
> > wrote:> 
> > Op donderdag 22 februari 2024 13:41:43 CET schreef Derek Atkins:
> >> I'm going to throw some ideas out there, but... doesn't the "set"
> >> 
> >> overwrite the variable??  In the original you had:
> >>  set DSPF -python -Wall -Werror $(SWIG_ARGS)
> >>  if (swig_version < 4.1)
> >>  
> >> set DSPF $(SWIG_ARGS) -py3
> >> 
> >> Wouldn't this override DSPF if swig is < 4.1, getting rid of -python
> >> -Wall
> >> -Werror?  That would mean that on systems with swig < 4.1, it would not
> >> be
> >> running with -Wall -Werror, but with your new change it WOULD -- causing
> >> an error on warning where it didn't have one before.
> > 
> > This was my first attempt at making -py3 optional and definitely wrong as
> > I did indeed overwrite DSPF. But after that goof up I had already
> > committed a fix that only optionally sets -py3 as an additional parameter
> > to DSPF. In the new situation there's only one 'set' command to define
> > DSPF in which -py3 optionally comes in via a variable. And that commit
> > still bails out with an error while trying to determine the Python
> > site-package directory.
> > 
> > As far as I understand the moment configure fails on python it has not
> > even executed the code I have changed. My changes are related to
> > installing swig rules. The failure happens much earlier in the configure
> > phase namely while setting up python.
> > 
> > Note also the Ubuntu 22.04 ci tests run fine. Ubuntu 22.04 comes with swig
> > 4.0, hence also older than 4.1.
> 
> Geert,
> 
> I think that it fails on your push is coincidental.  Github updated the
> python version overnight: When [CI ran after my push
> yesterday](https://github.com/Gnucash/gnucash/actions/runs/7997611600/job/2
> 1842396667) python was version 3.12.1 and in [the failing
> test](https://github.com/Gnucash/gnucash/actions/runs/8002824454/job/218588
> 76155) it's 3.12.2.
> 
> I figured out a fix and pushed it.
> 
> Regards,
> John Ralls
 
Thanks!

Geert

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

Re: [GNC-dev] gnucash stable: Do a better job of including the -py3 option only for swig 4.1

[Geert Janssens]

Op donderdag 22 februari 2024 13:41:43 CET schreef Derek Atkins:
> I'm going to throw some ideas out there, but... doesn't the "set"
> overwrite the variable??  In the original you had:
> 
>   set DSPF -python -Wall -Werror $(SWIG_ARGS)
>   if (swig_version < 4.1)
>  set DSPF $(SWIG_ARGS) -py3
> 
> Wouldn't this override DSPF if swig is < 4.1, getting rid of -python -Wall
> -Werror?  That would mean that on systems with swig < 4.1, it would not be
> running with -Wall -Werror, but with your new change it WOULD -- causing
> an error on warning where it didn't have one before.
> 

This was my first attempt at making -py3 optional and definitely wrong as I did 
indeed 
overwrite DSPF. But after that goof up I had already committed a fix that only 
optionally 
sets -py3 as an additional parameter to DSPF. In the new situation there's only 
one 'set' 
command to define DSPF in which -py3 optionally comes in via a variable. And 
that commit 
still bails out with an error while trying to determine the Python site-package 
directory.

As far as I understand the moment configure fails on python it has not even 
executed the 
code I have changed. My changes are related to installing swig rules. The 
failure happens 
much earlier in the configure phase namely while setting up python.

Note also the Ubuntu 22.04 ci tests run fine. Ubuntu 22.04 comes with swig 4.0, 
hence also 
older than 4.1.

Regards,

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

Re: [GNC-dev] gnucash stable: Do a better job of including the -py3 option only for swig 4.1

[Geert Janssens]

My last commit causes a CI failure on MacOS. Unfortunately I can't find why 
that would be. 
As far as I can see I haven't changed anything that could cause the distutils 
module not to 
be found by python.


There are other errors later on in the configure output relating to a read-only 
file system.


I have retried but the error doesn't go away. Perhaps I should wait a bit 
longer before 
retrying ?


Geert


Op donderdag 22 februari 2024 11:14:04 CET schreef Geert Janssens:
> Updatedvia  https://github.com/Gnucash/gnucash/commit/b9eb550b (commit)
> from  https://github.com/Gnucash/gnucash/commit/cbf89a73 (commit)
> 
> 
> 
> commit b9eb550b9a9a2ff0a5e926debb1bee5a073a5319
> Author: Geert Janssens 
> Date:   Thu Feb 22 11:13:59 2024 +0100
> 
> Do a better job of including the -py3 option only for swig 4.1
> 
> The previous attempt broke builds with swig older than 4.1
> 
> diff --git a/common/cmake_modules/GncAddSwigCommand.cmake
> b/common/cmake_modules/GncAddSwigCommand.cmake index 23bbebcabf..
811f347608
> 100644
> --- a/common/cmake_modules/GncAddSwigCommand.cmake
> +++ b/common/cmake_modules/GncAddSwigCommand.cmake
> @@ -68,16 +68,14 @@ macro (gnc_add_swig_python_command _target _out_var
> _py_out_var _output _py_outp set(py_outfile
> ${SW_CURR_BUILD_SOURCE_DIR}/${_py_output})
>  set(${_py_out_var} ${py_outfile}) # This variable is set for
> convenience to use in the calling CMakeLists.txt
> 
> +if (${SWIG_VERSION} VERSION_LESS 4.1)
> +set (SWIG_EXTRA_OPT -py3)
> +endif()
>  set (DEFAULT_SWIG_PYTHON_FLAGS
> --python
> +-python ${SWIG_EXTRA_OPT}
>  -Wall -Werror
>  ${SWIG_ARGS}
>  )
> -if (${SWIG_VERSION} VERSION_LESS 4.1)
> -set (DEFAULT_SWIG_PYTHON_FLAGS
> -${SWIG_ARGS} -py3
> -)
> -endif()
>  set (DEFAULT_SWIG_PYTHON_C_INCLUDES
>   ${GLIB2_INCLUDE_DIRS}
>   ${CMAKE_SOURCE_DIR}/common
> 
> 
> 
> Summary of changes:
>  common/cmake_modules/GncAddSwigCommand.cmake | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> ___
> gnucash-changes mailing list
> gnucash-chan...@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-changes


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

Re: [GNC-dev] Possible fixes needed -- or maybe an anomaly with make and Ubuntu 23.10

[Geert Janssens]

Hi,

I presume you are referring to the warning messages regarding the -py3 switch :
Deprecated command line option: -py3. Ignored, this option is no longer 
supported.

They are not specific to Ubuntu 23.10. I see the same warnings when building 
gnucash on 
Fedora 39.

It's a change in the swig tool as of v4.1. This option is no longer needed 
starting with that 
version (but is on older versions). I have committed a fix to our source code.

Thanks for bringing this up and kind regards,

Geert

Op woensdag 21 februari 2024 22:35:13 CET schreef Stephen M. Butler:
>Don't know whether or not the following needs a developer's attention.
>I attempted to include as much context as needed.  Just did a git pull
>to update to 5.5-87 then did a successful build.  So it must not be too
>disastrous.  Perhaps just an anomaly with make on Ubuntu 23.10.
>-- The C compiler identification is GNU 13.2.0
>-- The CXX compiler identification is GNU 13.2.0
>[ 19%] Generating swig-unittest-support-python.c, unittest_support.py
>Deprecated command line option: -py3. Ignored, this option is no longer
>supported.
>[ 19%] Built target swig-unittest-support-python
>[ 30%] Linking CXX shared library
>../../../lib/libgnc-backend-xml-utils.so
>/usr/bin/ld:
>CMakeFiles/gnc-backend-xml-utils.dir/gnc-xml-backend.cpp.o: in function
>`GncXmlBackend::write_to_file(bool)':
>/home/steve/Projects/GnuCash/gnucash/libgnucash/backend/xml/gnc-xml-bac
>kend.cpp:390:(.text+0x1447):
>warning: the use of `mktemp' is dangerous, better use `mkstemp' or
>`mkdtemp'
>[ 30%] Built target gnc-backend-xml-utils
>[ 32%] Generating
>../../lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/app-utils/date
>-utilities.go
>: warning: non-literal format string
>wrote
>`/home/steve/Projects/GnuCash/Build-gnucash_5.5-87/lib/x86_64-linux-gnu
>/guile/3.0/site-ccache/gnucash/app-utils/date-utilities.go'
>[ 32%] Built target scm-app-utils-1
>[ 77%] Generating
>../../../lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/reports/sta
>ndard/advanced-portfolio.go
>: warning: non-literal format string
>wrote
>`/home/steve/Projects/GnuCash/Build-gnucash_5.5-87/lib/x86_64-linux-gnu
>/guile/3.0/site-ccache/gnucash/reports/standard/advanced-portfolio.go'
>[ 78%] Generating
>../../../lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/reports/sta
>ndard/category-barchart.go
>: warning: non-literal format string
>wrote
>`/home/steve/Projects/GnuCash/Build-gnucash_5.5-87/lib/x86_64-linux-gnu
>/guile/3.0/site-ccache/gnucash/reports/standard/category-barchart.go'
>[100%] Generating gnucash_core.c, gnucash_core_c.py
>Deprecated command line option: -py3. Ignored, this option is no longer
>supported.
>[100%] Built target swig-gnucash-core
>[100%] Generating swig-core-utils-python.c, sw_core_utils.py
>Deprecated command line option: -py3. Ignored, this option is no longer
>supported.
>[100%] Built target swig-core-utils-python
>[100%] Generating swig-app-utils-python.c, sw_app_utils.py
>Deprecated command line option: -py3. Ignored, this option is no longer
>supported.
>[100%] Built target swig-app-utils-python
> ___
> 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] WebKitGtk now defaults to Gtk4

[Geert Janssens]

Op zondag 19 november 2023 05:00:49 CET schreef john:
> 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

I agree it's probably a lot of work, we can get some inspiration from 
WxWidgets. It has a 
wxWebView class that uses a different backend on Windows (IE or Edge) and 
WebKit on 
MacOS and Linux.
https://docs.wxwidgets.org/3.2/classwx_web_view.html[1]


> * Send the HTML/JS/CSS to the default browser. This
> will lose the links to GnuCash objects like transactions

Keeping the links as you suggested in another reply in this thread is 
definitely tricky. I have 
been researching this for an unrelated project. Browsers are (rightfully) very 
reluctant to 
let a webpage interface with the local filesystem in any way. The only 
universal method is 
defining a custom handler for the user's default webbrowser. Similar to what we 
do with 
the integrated WebKit instance, though now it has to be installed for the users 
default 
browser, so somewhere on the user's system, outside of GnuCash' direct control. 
I have 
never looked at whether there's a system-wide location to store such handler 
that's read 
and interpreted by all common browsers. I doubt it though.

Next all links in reports we want to be handled by gnucash need to be set up 
such that this 
custom handler is called. This is usually done by using a unique protocol or 
extension to 
the links that are associated with the handler.

Next we need to figure out how the browser can pass this request to a running 
gnucash 
and how this running gnucash can act on it. I think we may have to complete the 
transition to GtkApplication in order to achieve that. We currently have no way 
to pass 
messages to a running gnucash. GtkApplication on the other hand has methods to 
respond to re-entrant requests (that is re-launching gnucash would instead 
delegate the 
parameters as a message to an already running gnucash -- overly simplified 
explanation).

I imagine there will be several additional complications.

These are some I'm thinking of immediately:
* What should we do if the report remains open in the browser, but gnucash is 
closed by 
the user, yet the user clicks on a link in the report. Should that start 
gnucash again ?
* What if the report is open for another gnucash book than the one that's 
currently open 
in gnucash and the user clicks a link ? I think at the minimum the links need 
to hold a 
reference to the book for which the report was generated. But that's only half 
of the 
solution. GnuCash still needs to act on a book mismatch in some way.
* Currently one could have two instances of gnucash running, with a different 
data set 
loaded and each having their own reports open. What if they both now will send 
their 
reports to the user's default browser ? How will the browser know what gnucash 
to 
forward the requests to when a user click on a report link ? Here also the 
migration to 
GtkApplication could help in solving this issue. Particularly if it's 
configured to be a 
singleton application. In this case there could only be a single gnucash 
running accepting 
messages from the browser. As with the earlier issues the links embedded in our 
reports 
would need to have an indication as to the gnucash book they relate to. This 
book 
information could be used by the single gnucash instance to act on the proper 
book.
* That leads to the next design challenge though: currently our backend code 
may not be 
capable of managing two GncSessions in one running gnucash instance. If we 
convert to 
GtkApplication in singleton mode, we would loose the option to have two gnucash 
books 
open at once. To fix that we'd have to rework the engine code to be fully 
capable of 
managing more that a single open Session.

So this avenue may be possible, but will definitely open a big can of worms if 
you ask me...

> * Configure a
> GtkTextView to understand HTML tags. This doesn't support charts, printing,
> or PDF export.

While probably less work, the result would be a huge step back IMO.

> * 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.
> 
I don't know of one either. The more common way is to go via an intermediate 
format, be 
it html or xml or whatever. Pandoc (https://pandoc.org/[2]) comes to mind here 
as it can 
handle plenty of input formats. However it doesn't do pdf generation directly, 
it relies on 
other pdf generators. Several are listed on the page I linked. They may be 
usable directly 
or not.

Regards,

Geert


[1] https://docs.wxwidgets.org/3.2/classwx_web_view.html
[2] https://pandoc.org/
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnucash stable: Bug 799121 - Parse error on CSV import on MacOS

[Geert Janssens]

Good find!

You may want to do the same in CsvImpPriceAssist::preview_refresh. It's 
following the 
exact same coding semantics as CsvImpTransAssist.

Regards,

Geert

Op vrijdag 17 november 2023 05:30:38 CET schreef John Ralls:
> Updatedvia  https://github.com/Gnucash/gnucash/commit/102304b3 
> (commit)
>   from  https://github.com/Gnucash/gnucash/commit/8d993e73 (commit)
> 
> 
> 
> commit 102304b38b153a5b87280da88d0679663eec2e1f
> Author: John Ralls 
> Date:   Thu Nov 16 18:15:17 2023 -0800
> 
> Bug 799121 - Parse error on CSV import on MacOS
> 
> Use csv_tximp_preview_sep_button_cb solely as a callback, its error
> handling doesn't make sense otherwise. All we want at the end of
> preview_refresh is to attempt a tokenize.
> 
> In addition to not going into an infinite loop with the message box
> this presents a more helpful message suggesting that the encoding is
> wrong.
> 
> diff --git a/gnucash/import-export/csv-imp/assistant-csv-trans-import.cpp
> b/gnucash/import-export/csv-imp/assistant-csv-trans-import.cpp index
> 55823b93b1..d1cb2480ea 100644
> --- a/gnucash/import-export/csv-imp/assistant-csv-trans-import.cpp
> +++ b/gnucash/import-export/csv-imp/assistant-csv-trans-import.cpp
> @@ -34,6 +34,7 @@
> 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include "gnc-path.h"
> @@ -1726,7 +1727,14 @@ CsvImpTransAssist::preview_refresh ()
>  gtk_entry_set_text (GTK_ENTRY(custom_entry), separators.c_str());
>  g_signal_handlers_unblock_by_func (custom_cbutton, (gpointer)
> csv_tximp_preview_sep_button_cb, this); g_signal_handlers_unblock_by_func
> (custom_entry, (gpointer) csv_tximp_preview_sep_button_cb, this); -   
> csv_tximp_preview_sep_button_cb (GTK_WIDGET (custom_cbutton), this); + 
>   try
> +{
> +tx_imp->tokenize (false);
> +}
> +catch(std::range_error& err)
> +{
> +PERR("CSV Tokenization Failed: %s", err.what());
> +}
>  }
> 
>  // Repopulate the parsed data table
> 
> 
> 
> Summary of changes:
>  gnucash/import-export/csv-imp/assistant-csv-trans-import.cpp | 10
> +- 1 file changed, 9 insertions(+), 1 deletion(-)
> 
> ___
> gnucash-changes mailing list
> gnucash-chan...@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-changes


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

Re: [GNC-dev] gnucash stable: Fix NULL dereference in gnc_plugin_page_report_focus_widget.

[Geert Janssens]

This seems to point at a regression in Gtk.

>From what I understand GTK_IS_WIDGET should return FALSE if widget is NULL.

It's defined here:
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkwidget.h?
ref_type=heads#L46

It's a macro that calls G_TYPE_CHECK_INSTANCE_TYPE, which is defined here:
https://gitlab.gnome.org/GNOME/glib/-/blob/main/gobject/gtype.h?
ref_type=heads#L541

The comment above this definition states G_TYPE_CHECK_INSTANCE_TYPE should 
return FALSE if instance is NULL.

So I'm rather surprised this use of GTK_IS_WIDGET crashes gnucash.

Regards,

Geert

Op donderdag 2 november 2023 04:15:31 CET schreef John Ralls:
> Updatedvia  https://github.com/Gnucash/gnucash/commit/5e06c8d8 
> (commit)
>   from  https://github.com/Gnucash/gnucash/commit/d617129d (commit)
> 
> 
> 
> commit 5e06c8d8a00935eff5908d71da46f148d6f01e43
> Author: John Ralls 
> Date:   Wed Nov 1 19:54:54 2023 -0700
> 
> Fix NULL dereference in gnc_plugin_page_report_focus_widget.
> 
> Reported by Michael Hendry in gnucash-user.
> 
> diff --git a/gnucash/gnome/gnc-plugin-page-report.cpp
> b/gnucash/gnome/gnc-plugin-page-report.cpp index 724008b4d8..a8a58ce7e0
> 100644
> --- a/gnucash/gnome/gnc-plugin-page-report.cpp
> +++ b/gnucash/gnome/gnc-plugin-page-report.cpp
> @@ -334,7 +334,7 @@ gnc_plugin_page_report_focus_widget (GncPluginPage
> *report_plugin_page) if (!priv->loaded) // so we only do the load once
>  gnc_plugin_page_report_load_uri (report_plugin_page);
> 
> -if (GTK_IS_WIDGET(widget))
> +if (widget && GTK_IS_WIDGET(widget))
>  {
>  if (!gtk_widget_is_focus (GTK_WIDGET(widget)))
>  gtk_widget_grab_focus (GTK_WIDGET(widget));
> 
> 
> 
> Summary of changes:
>  gnucash/gnome/gnc-plugin-page-report.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> ___
> gnucash-changes mailing list
> gnucash-chan...@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-changes




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

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

[Geert Janssens]

Op donderdag 14 september 2023 01:33:40 CEST schreef Frank H. Ellenberger:
> Hi Geert,
> 
> why is it using font-family:Bitstream Vera Sans?

Probably because that was the default font when I created the svg...

> Some non-latin glyphs
> are not supported by this fonts. Any suggestions for a font with full
> utf-8 support?
> 

Not really...

> When I open it with Inkscape 1.3 it wants to change the resolution.
> Should we?

I don't know ?

> 
> For html and the website
> [https://www.gnucash.org/images/features/basics_AccountRelationships.*.png]
> we convert it to a png file and use that. AFAIK today docbook and html
> can handle svg files. Should we drop the png file and use also there the
> svg directly?

I'd say yes, though you may have to specify a rendering size then.

Regards,

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

Re: [GNC-dev] recent CMake warnings and Ubuntu LTS support

[Geert Janssens]

Ok, I have lowered the bar for cmake to 3.14.5.

Regards,

Geert

Op dinsdag 22 augustus 2023 19:15:23 CEST schreef Derek Atkins:
> That would certainly solve the build issue on code (for now).
> 
> -derek
> 
> On Tue, August 22, 2023 1:08 pm, Geert Janssens wrote:
> > Heh, we usually look at Ubuntu LTS to find the oldest software versions to
> > support. Didn't
> > realize our own code server is even older.
> > 
> > We could also set the baseline to 3.14.5. It solves the issue for which I
> > chose to upgrade to
> > 3.16 equally well.
> > 
> > Regards,
> > 
> > Geert
> > 
> > Op dinsdag 22 augustus 2023 18:01:20 CEST schreef john:
> >> The docs are also built nightly as a GitHub action and published to
> >> http://gnucash.github.io/gnucash-docs/ so a possible workaround would be
> >> to
> >> copy or link that. There are at present no intermediate index.html so
> >> you
> >> have to get each one independently, e.g.
> >> http://gnucash.github.io/gnucash-docs/C/gnucash-guide/.
> >> 
> >> Regards,
> >> John Ralls
> >> 
> >> > On Aug 22, 2023, at 05:13, Derek Atkins  wrote:
> >> > 
> >> > Hi,
> >> > 
> >> > Only seeing this thread now.
> >> > This change broke the gnucash-docs build on code.
> >> > Code is (still) running Fedora-29, which only has cmake 3.14.5
> >> > Upgrading code is something that cannot happen quickly (for many
> >> 
> >> reasons),
> >> 
> >> > so if we still want docs builds we need to do downgrade the minimal
> >> > version.
> >> > 
> >> > Thanks,
> >> > 
> >> > -derek
> >> > 
> >> > On Fri, August 18, 2023 12:57 pm, Geert Janssens wrote:
> >> >> Op vrijdag 18 augustus 2023 18:24:34 CEST schreef john:
> >> >>> I have no problem with bumping up the minimum
> >> >> 
> >> >> CMake version as long as it's
> >> >> 
> >> >>> the same in gnucash and gnucash-docs. IIRC there are
> >> >> 
> >> >> already other issues
> >> >> 
> >> >>> blocking building 5.x on Ubuntu 18.04 so the support
> >> >> 
> >> >> isn't really there.
> >> >> 
> >> >> Done.
> >> >> ___
> >> >> gnucash-devel mailing list
> >> >> gnucash-devel@gnucash.org
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] recent CMake warnings and Ubuntu LTS support

[Geert Janssens]

Heh, we usually look at Ubuntu LTS to find the oldest software versions to 
support. Didn't 
realize our own code server is even older.

We could also set the baseline to 3.14.5. It solves the issue for which I chose 
to upgrade to 
3.16 equally well.

Regards,

Geert

Op dinsdag 22 augustus 2023 18:01:20 CEST schreef john:
> The docs are also built nightly as a GitHub action and published to
> http://gnucash.github.io/gnucash-docs/ so a possible workaround would be to
> copy or link that. There are at present no intermediate index.html so you
> have to get each one independently, e.g.
> http://gnucash.github.io/gnucash-docs/C/gnucash-guide/.
> 
> Regards,
> John Ralls
> 
> > On Aug 22, 2023, at 05:13, Derek Atkins  wrote:
> > 
> > Hi,
> > 
> > Only seeing this thread now.
> > This change broke the gnucash-docs build on code.
> > Code is (still) running Fedora-29, which only has cmake 3.14.5
> > Upgrading code is something that cannot happen quickly (for many reasons),
> > so if we still want docs builds we need to do downgrade the minimal
> > version.
> > 
> > Thanks,
> > 
> > -derek
> > 
> > On Fri, August 18, 2023 12:57 pm, Geert Janssens wrote:
> >> Op vrijdag 18 augustus 2023 18:24:34 CEST schreef john:
> >>> I have no problem with bumping up the minimum
> >> 
> >> CMake version as long as it's
> >> 
> >>> the same in gnucash and gnucash-docs. IIRC there are
> >> 
> >> already other issues
> >> 
> >>> blocking building 5.x on Ubuntu 18.04 so the support
> >> 
> >> isn't really there.
> >> 
> >> Done.
> >> ___
> >> 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] recent CMake warnings and Ubuntu LTS support

[Geert Janssens]

Op vrijdag 18 augustus 2023 18:24:34 CEST schreef john:
> I have no problem with bumping up the minimum 
CMake version as long as it's
> the same in gnucash and gnucash-docs. IIRC there are 
already other issues
> blocking building 5.x on Ubuntu 18.04 so the support 
isn't really there.
> 
Done.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] recent CMake warnings

[Geert Janssens]

Hi Frank,

I had a quick look at this.
I don't know what to do with your eclipse warning. That's not part of our CMake 
configuration. I suppose you are using something like -G Eclipse-CDT or 
something when 
you call cmake.

For the python warnings I have pushed a small change to use the newer find 
package 
module to detect python when our cmake is 3.12 or more recent.
As our baseline is still 3.10, I have kept some compatibility code for older 
cmake versions.
If however we choose to support Ubuntu 20.04 LTS as oldest distro, we could set 
cmake 3.16 
as baseline and then the compatibility code could also be dropped. Ubuntu 18.04 
LTS has 
reached end of standard support in May 2023, so IMO that's something we could 
consider.

Regards,

Geert

Op dinsdag 15 augustus 2023 13:38:36 CEST schreef Frank H. Ellenberger:
> Hi Geert,
> 
> I watched a bunch of new CMake warnings and assume parts of our build
> files and several wiki paages have to get updated:
> 
> ninja
> [0/1] Re-running CMake...
> CMake Deprecation Warning:
>Support for "Extra Generators" like
> 
>  Eclipse CDT4
> 
>is deprecated and will be removed from a future version of CMake.
> IDEs may
>use the cmake-file-api(7) to view CMake-generated project build trees.
> 
> 
> -- Eclipse version is set to 4.26 (). Adjust CMAKE_ECLIPSE_VERSION if
> this is wrong.
> -- Using guile-3.0.x
> -- Using guile SRFI-64
> -- Using guile textual-ports
> CMake Warning (dev) at CMakeLists.txt:500 (find_package):
>Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs
> modules
>are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
>the cmake_policy command to set the policy and suppress this warning.
> 
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> CMake Warning (dev) at CMakeLists.txt:505 (find_package):
>Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs
> modules
>are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
>the cmake_policy command to set the policy and suppress this warning.
> 
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> -- Checking for GTEST
> -- Checking for GMOCK
> -- Configuring done (14.6s)
> -- Generating done (2.1s)
> -- Build files have been written to:
> /home/frank/eclipse-workspace/gnucash-old/maint
> 
> cmake --version
> cmake version 3.27.1
> 
> Regards
> Frank


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

Re: [GNC-dev] GnuCash 5.1-2 for macOS

[Geert Janssens]

Op donderdag 11 mei 2023 02:44:50 CEST schreef john:
> Nope, never have. We don't in Windows or Flatpak either: It's whatever
> MinGW-W64 or the Gnome Runtime of the month hands us.
> 
> Regards,
> John Ralls
> 
True for Windows, though for flatpak that's subtly different. You explicitly 
choose a specific 
Gnome Runtime to build against in the flatpak manifest. That runtime is 
immutable so that 
build is 100% reproducible. Of course that doesn't mean much if the gnome folks 
force more 
recent runtimes on us every few months and drop older ones...

It doesn't matter really, it's just a curiosity I didn't realize. And we don't 
claim to guarantee 
reproducible builds anyway.

Regards,

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

Re: [GNC-dev] GnuCash 5.1-2 for macOS

[Geert Janssens]

Ok, my guess was close enough.

That implies we're not really tracking what version of gtk-osx is used to 
package gnucash 
releases ? That's a surprise to me.

Regards,

Geert

Op woensdag 10 mei 2023 16:19:39 CEST schreef john:
> Geert,
> 
> Nope, those changes are
> https://gitlab.gnome.org/GNOME/gtk-osx/-/commit/2e5e2a4712ee7f222f9342e6a8d
> 8a941e41dcd8d.  There is a change in gnucash-on-osx, but it's just bumping
> the release number in Info.plist...and I had forgotten to push it.
> 
> Regards,
> John Ralls
> 
> > On May 10, 2023, at 1:11 AM, Geert Janssens 
> > wrote:
> > 
> > Hi John,
> > 
> > Thanks for the updated dmg.
> > 
> > I saw mails passing by for your update to the htdocs repo. However I
> > didn't see similar mails for the gnucash-on-osx repo. I presume you had
> > to make at least a change in the gnucash.modules file over there as well
> > to add the patches or change the gtk package version number ?
> > 
> > Not too important for me personally, but if someone else is trying to
> > build on OSX/Quarz, they'd want these fixes as well...
> > 
> > Regards,
> > 
> > Geert
> > 
> > Op woensdag 10 mei 2023 04:26:31 CEST schreef John Ralls:
> >> There's a gtk3 regression in Gnucash-5.1-1. Nobody's reported hitting it
> >> yet, but it's there: I left a patch out when I updated gtk3 to 3.34.37
> >> just
> >> before the 5.1 release. I've re-packaged with a correctly-patched
> >> library.
> >> This also has a patch to fix
> >> https://bugs.gnucash.org/show_bug.cgi?id=798906 for those users with a
> >> dual-monitor setup where one monitor is Retina and the other isn't.
> >> 
> >> 65a67bdffbe2d50e5dbe69b7193acfde6d8964a0fbd631edfd0d064fbaea03d3
> >> Gnucash-Intel-5.1-2.dmg
> >> 
> >> https://downloads.sourceforge.net/gnucash/gnucash%20%28stable%29/5.1/Gnuc
> >> ash -Intel-5.1-2.dmg
> >> https://github.com/Gnucash/gnucash/releases/download/5.1/Gnucash-Intel-5.
> >> 1-> 2.dmg
> >> 
> >> Regards,
> >> John Ralls
> >> 
> >> ___
> >> gnucash-devel mailing list
> >> gnucash-devel@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > 
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel


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

Re: [GNC-dev] GnuCash 5.1-2 for macOS

[Geert Janssens]

Hi John,

Thanks for the updated dmg.

I saw mails passing by for your update to the htdocs repo. However I didn't see 
similar mails 
for the gnucash-on-osx repo. I presume you had to make at least a change in the 
gnucash.modules file over there as well to add the patches or change the gtk 
package 
version number ?

Not too important for me personally, but if someone else is trying to build on 
OSX/Quarz, 
they'd want these fixes as well...

Regards,

Geert


Op woensdag 10 mei 2023 04:26:31 CEST schreef John Ralls:
> There's a gtk3 regression in Gnucash-5.1-1. Nobody's reported hitting it
> yet, but it's there: I left a patch out when I updated gtk3 to 3.34.37 just
> before the 5.1 release. I've re-packaged with a correctly-patched library.
> This also has a patch to fix
> https://bugs.gnucash.org/show_bug.cgi?id=798906 for those users with a
> dual-monitor setup where one monitor is Retina and the other isn't.
> 
> 65a67bdffbe2d50e5dbe69b7193acfde6d8964a0fbd631edfd0d064fbaea03d3 
> Gnucash-Intel-5.1-2.dmg
> 
> https://downloads.sourceforge.net/gnucash/gnucash%20%28stable%29/5.1/Gnucash
> -Intel-5.1-2.dmg
> https://github.com/Gnucash/gnucash/releases/download/5.1/Gnucash-Intel-5.1-> 
> 2.dmg
> 
> Regards,
> John Ralls
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


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

Re: [GNC-dev] GnuCash 5.0 Released

[Geert Janssens]

Hi,

They should be the same size as it's the same binary that gets uploaded.

When I download both of them today, they actually are:
ls -s gnucash-5.0.setup*)
147504 'gnucash-5.0.setup(1).exe'
147504  gnucash-5.0.setup.exe


The first one is downloaded from sourceforge, the other from github.

Note that sourceforge reports the size as 151M while firefox reported it as
144Mb while downloading.

Regards,

Geert


Op dinsdag 28 maart 2023 18:22:04 CEST schreef p...@kroitor.ca:
> Is it normal that the SourceForge download of the Windows setup executable
> is 8.5MB larger (152.59MB) than the github version (144.04MB) of the same
> thing? I can't really think of a legitimate reason.
> 
> See last two links below.
> 
> Paul
> 
> -Original Message-
> From: gnucash-devel  On
> Behalf Of John Ralls Sent: Sunday, March 26, 2023 5:10 PM
> To: gnucash-annou...@lists.gnucash.org
> Cc: gnucash-devel ; Gnucash Users
>  Subject: [GNC-dev] GnuCash 5.0 Released
> 
> The GnuCash development team announces GnuCash 5.0.
> 
> New Features
> 
> [snip]
> 
> GnuCash is provided for both Microsoft Windows 8.1® and later and MacOS
> 10.13 (High Sierra)® and later in pre-built, all-in-one packages. An
> installer is provided for Microsoft Windows® while the MacOS® package is a
> disk image containing a drag-and-drop application bundle.
> 
> The SHA256 Hashes for the downloadable files are:
> 
> cfc13bab31aed8e4962805ef56530f9772889604910b5678cb5c79c283138824 
> gnucash-5.0.tar.bz2
> 66dd5e32829cb6d8dd9a7e017a894583c7579932d13c4fe024329d9c6cfe956d 
> gnucash-5.0.tar.gz
> e9d30e36163a7f047daf2523ac35bf2218d2e661bcfc7f279d57d4d396caa33d 
> gnucash-5.0.setup.exe
> c8ea60b2ccbeab5f6997a927939a0fad715fbbe494644e586c6c386bfec6857a 
> Gnucash-Intel-5.0-2.dmg
> 02a1d6d0d8c61aae47b1200af482967ed16322a41f31dd8cf3a6679e7159edb1 
> gnucash-docs-5.0.tar.gz
> 
> Microsoft Windows:
> https://github.com/Gnucash/gnucash/releases/download/5.0/gnucash-5.0.setup.e
> xe
> https://downloads.sourceforge.net/gnucash/gnucash%20%28unstable%29/5.0/gnuc
> ash-5.0.setup.exe
> 
> [snip]
> 
> ___
> 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] Help with Git repos and versioning

[Geert Janssens]

Op zondag 16 april 2023 09:19:44 CEST schreef Kevin Buckley:
> On Sun, 16 Apr 2023 at 14:50, David T.  wrote:
> 
> ...
> 
> On Sun, 16 Apr 2023 at 14:56, Geert Janssens 
> wrote:
> 
> ...
> 
> and clearly I missed ALL of the mailing list mentions of the renames,
> so cheers to you both for putting me right.
> 
> Having said that, I'd assumed, on the back of seeing the merge of maint
> into stable   that most of the development, or perhaps 'fixing", work was
> still being done on maint.
> 
> No matter: I'm back on track.
> 
> Whilst I have you though, I also noticed that README also says
> 
> ###
> Supported Platforms
> ---
> 
> GnuCash 3.x is known to work with the following operating systems:
> 
> 
> so maybe that could do with a bit of qualification as well, say
> 
> GnuCash versions 3.x and upwards are knowm to work ...
> 
> Cheers again,
> Kevin

Oops :)

That one should also be 5.x. The README file is meant to explain the gnucash 
version you 
are looking at, not a historical reference.

Fixed.

Regards,

Geert

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

Re: [GNC-dev] Help with Git repos and versioning

[Geert Janssens]

Hi Kevin,

The version number mentioned in the README file is an oversight. I have just 
fixed it. Thanks 
for mentioning this.

'maint' was the old name we used for the stable branch. Starting with 5.0 we 
decided it 
would be more clear to use 'stable' as name for that branch as 'maint' was a 
bit ambiguous 
and close to 'main' which is a name more commonly used for a development branch.

With the new stable branch it's normal you no longer find the maint branch.

John sent a message on the ANNOUNCE mailing list about this branch renaming:
https://lists.gnucash.org/pipermail/gnucash-announce/2023-March/000389.html[1]

Though while re-reading I see it's quite concise and doesn't explicitly mention 
maint (and 
master) will be dropped.

Regards,

Geert

Op zondag 16 april 2023 08:19:43 CEST schreef Kevin Buckley:
> I have a directory, from within which I do the occassional git pull
> againstt the GnuCash GitHub repo.
> 
> I just did one, and now see the following
> 
> $ git remote -v
> origin  https://github.com/Gnucash/gnucash.git (fetch)
> origin  https://github.com/Gnucash/gnucash.git (push)
> 
> $ git status -s -b
> ## stable...origin/stable
> 
> $ git describe --abbrev=1
> 5.0-71-gf4f48
> 
> All looks good, but then I started looking around.
> 
> The README I have starts with
> 
> 
>   GnuCash README file.
> 
> The current stable series is GnuCash 4.x.
> 
> 
> should I have one that says 5.x ?
> 
> 
> I also downloaded a 5.0 source tarball, and saw that the README is the
> same in there, but also saw in the Changelog
> 
> 2023-03-25 John Ralls
> 
> * Release GnuCash 5.0 (HEAD -> master, tag: 5.0)
> 
> 2023-03-25 John Ralls
> 
> * Merge branch 'maint'
> 
> 
> but, if I chechout the maint branch in my local directory, I see
> 
> $ git checkout maint
> $ git describe --abbrev=1
> 4.13-1-g52ded
> 
> amd I am aware that's there's been a 4.14, as well as the 5.0
> 
> FWIW, the latest commit I can see in my maint branch is
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Gnucash % Build on Linux MInt

[Geert Janssens]

The big difference is a git clone can generate de required file because the 
needed info is in the clone metadata. The zip file is automatically generated 
by github. We don't control this and unfortunately it doesn't contain the info 
the build needs. For that reason each release is accompanied with a release 
tarball, generated by the gnucash developers themselves and that does have  the 
missing file. You can find links to the tarball in the release announcements.  

Regards,

Geert

David Cousens  schreef op 28 maart 2023 14:23:24 
GMT+08:00:
>That worked for me too Stephen, thnaks. 
>
>The missing file is still not there in the git clone of the repository, so
>either the cmake is looking for and finding it  it elsewhere but the downloaded
>ZIP still isn't compiling.
>Cheers
>David
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Sent from my smartphone. Please excuse my brevity.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Test failure on current master branch

[Geert Janssens]

Got a chance to test this yesterday. Your change fixed it indeed.

Regards,

Geert

Op donderdag 2 maart 2023 21:36:00 CET schreef John Ralls:
> Found and fixed it. It turns out that string->number isn't locale-sensitive,
> std::to_string is. I replaced it with ostringstream and pushed.
> 
> Regards,
> John Ralls
> 
> > On Mar 2, 2023, at 9:16 AM, john  wrote:
> > 
> > Geert,
> > 
> > Aha! That would certainly explain why I  couldn't reproduce it. That
> > change is from
> > https://github.com/Gnucash/gnucash/commit/408b5ec2165fb43bef18b80ff44ba4d
> > 2f1b67f5f. Yes, no doubt string->number expects the number to be
> > represented in the current locale, so it wants "42,0" and getting "42.0"
> > returns #f
> > (https://www.gnu.org/software/guile/manual/html_node/Conversion.html).
> > I'll have to find another way to make that conversion.
> > 
> > Regards,
> > John Ralls
> > 
> >> On Mar 2, 2023, at 5:39 AM, Geert Janssens 
> >> wrote:
> >> 
> >> I still haven't figured out exactly where it goes wrong, but I did
> >> discover it's a locale related issue. For some reason this particular
> >> test has become locale sensitive.
> >> 
> >> If I run the test as follows:
> >> LC_ALL=C ctest -V -R test-gnc-option-scheme-output
> >> it passes. If however I do this:
> >> LC_ALL=fr_FR.utf8 ctest -V -R test-gnc-option-scheme-output
> >> it fails. I have also tried nl_BE.utf8 (my native locale), which fails as
> >> well. I suspect the call to (string->number (GncOption-serialize
> >> option)) on line 459 is failing. Perhaps GncOption-serialize spits out
> >> numbers in C locale while string->number uses local locale or vice versa
> >> ?
> >> 
> >> Regards,
> >> 
> >> Geert
> >> 
> >> Op woensdag 1 maart 2023 04:41:14 CET schreef John Ralls:
> >>> Geert,
> >>> 
> >>> I can't replicate that, tried on Debian 10, Debian Unstable, and Arch.
> >>> I'm
> >>> installing a Fedora 37 VM but I'm out of time for today and won't get to
> >>> the point of a test build of GnuCash.
> >>> 
> >>> Regards,
> >>> John Ralls
> >>> 
> >>>> On Feb 28, 2023, at 2:07 PM, Geert Janssens
> >>>> 
> >>>> wrote:
> >>>> 
> >>>> Hi,
> >>>> 
> >>>> With the current master branch I get the following test failure:
> >>>> 
> >>>> ctest --rerun-failed --output-on-failure
> >>>> Test project /home/janssege/Development/gnucash/master/build
> >>>> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Test failure on current master branch

[Geert Janssens]

I still haven't figured out exactly where it goes wrong, but I did discover 
it's a locale related 
issue. For some reason this particular test has become locale sensitive.

If I run the test as follows:
LC_ALL=C ctest -V -R test-gnc-option-scheme-output

it passes. If however I do this:
LC_ALL=fr_FR.utf8 ctest -V -R test-gnc-option-scheme-output

it fails. I have also tried nl_BE.utf8 (my native locale), which fails as well.
I suspect the call to (string->number (GncOption-serialize option)) on line 459 
is failing. 
Perhaps GncOption-serialize spits out numbers in C locale while string->number 
uses local 
locale or vice versa ?

Regards,

Geert

Op woensdag 1 maart 2023 04:41:14 CET schreef John Ralls:
> Geert,
> 
> I can't replicate that, tried on Debian 10, Debian Unstable, and Arch. I'm
> installing a Fedora 37 VM but I'm out of time for today and won't get to
> the point of a test build of GnuCash.
> 
> Regards,
> John Ralls
> 
> > On Feb 28, 2023, at 2:07 PM, Geert Janssens 
> > wrote:
> > 
> > Hi,
> > 
> > With the current master branch I get the following test failure:
> > 
> > ctest --rerun-failed --output-on-failure
> > Test project /home/janssege/Development/gnucash/master/build
> > 
> >   Start 120: test-gnc-option-scheme-output
> > 
> > 1/1 Test #120: test-gnc-option-scheme-output ***Failed0.22 sec
> > gnc:make-string-option is deprecated. Make and register the option in one
> > command with gnc-register-string-option.
> > gnc:register-option is deprecated. Use gnc-register-foo-option instead.
> > gnc:option-set-value and indeed all direct option access is deprecated.
> > Use gnc-set-option instead.
> > gnc:make-font-option is deprecated. Make and register the option in one
> > command with gnc-register-font-option.
> > gnc:make-currency-option is deprecated. Make and register the option in
> > one command with gnc-register-currency-option.
> > gnc:make-budget-option is deprecated. Make and register the option in one
> > command with gnc-register-color-option.
> > gnc:option-set-default-value and indeed all direct option access is
> > deprecated. Use gnc-set- option instead.
> > gnc:make-commodity-option is deprecated. Make and register the option in
> > one command with gnc-register-commodity-option.
> > gnc:make-simple-boolean-option is deprecated. Make and register the option
> > in one command with gnc-register-simple-boolean-option.
> > gnc:make-pixmap-option is deprecated. Make and register the option in one
> > command with gnc-register-pixmap-option.
> > gnc:make-account-list-option is deprecated. Make and register the option
> > in one command with gnc-register-account-list-option.
> > gnc:make-multichoice-option is deprecated. Make and register the option in
> > one command with gnc-register-multichoice-option.
> > gnc:make-list-option is deprecated. Make and register the option in one
> > command with gnc- register-list-option.
> > gnc:make-number-range-option is deprecated. Make and register the option
> > in one command with gnc-register-number-range-option.
> > 
> > FORMAT: error with call: (format #f "'~f<===" ===>#f )
> > 
> >   argument is not a number or a number string
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Test failure on current master branch

[Geert Janssens]

Hi,

With the current master branch I get the following test failure:

ctest --rerun-failed --output-on-failure 
Test project /home/janssege/Development/gnucash/master/build 
   Start 120: test-gnc-option-scheme-output 
1/1 Test #120: test-gnc-option-scheme-output ***Failed0.22 sec 
gnc:make-string-option is deprecated. Make and register the option in one 
command with 
gnc-register-string-option. 
gnc:register-option is deprecated. Use gnc-register-foo-option instead. 
gnc:option-set-value and indeed all direct option access is deprecated. Use 
gnc-set-option 
instead. 
gnc:make-font-option is deprecated. Make and register the option in one command 
with 
gnc-register-font-option. 
gnc:make-currency-option is deprecated. Make and register the option in one 
command with 
gnc-register-currency-option. 
gnc:make-budget-option is deprecated. Make and register the option in one 
command with 
gnc-register-color-option. 
gnc:option-set-default-value and indeed all direct option access is deprecated. 
Use gnc-set-
option instead. 
gnc:make-commodity-option is deprecated. Make and register the option in one 
command 
with gnc-register-commodity-option. 
gnc:make-simple-boolean-option is deprecated. Make and register the option in 
one 
command with gnc-register-simple-boolean-option. 
gnc:make-pixmap-option is deprecated. Make and register the option in one 
command with 
gnc-register-pixmap-option. 
gnc:make-account-list-option is deprecated. Make and register the option in one 
command 
with gnc-register-account-list-option. 
gnc:make-multichoice-option is deprecated. Make and register the option in one 
command 
with gnc-register-multichoice-option. 
gnc:make-list-option is deprecated. Make and register the option in one command 
with gnc-
register-list-option. 
gnc:make-number-range-option is deprecated. Make and register the option in one 
command with gnc-register-number-range-option. 

FORMAT: error with call: (format #f "'~f<===" ===>#f ) 
   argument is not a number or a number string 
Backtrace: 
In ice-9/boot-9.scm: 
 1752:10 14 (with-exception-handler _ _ #:unwind? _ # _) 
In unknown file: 
 13 (apply-smob/0 #) 
In ice-9/boot-9.scm: 
   724:2 12 (call-with-prompt _ _ #) 
In ice-9/eval.scm: 
   619:8 11 (_ #(#(#))) 
In ice-9/command-line.scm: 
  185:18 10 (_ #) 
In unknown file: 
  9 (eval (exit (run-test)) #) 
In ice-9/eval.scm: 
  191:35  8 (_ #f) 
In test-gnc-option-scheme-output.scm: 
46:2  7 (run-test) 
   143:6  6 (test-gnc-number-range-option-to-scheme) 
In ice-9/format.scm: 
 1546:18  5 (format #f "'~f" #f) 
  269:11  4 (format:format-work "'~f" (#f)) 
  1054:6  3 (format:out-fixed #f #f ()) 
In ice-9/boot-9.scm: 
 1752:10  2 (with-exception-handler _ _ #:unwind? _ # _) 
In ice-9/format.scm: 
  102:10  1 (_) 
In ice-9/boot-9.scm: 
 1685:16  0 (raise-exception _ #:continuable? _) 

ice-9/boot-9.scm:1685:16: In procedure raise-exception: 
error in format 
[pass] line:150, test: string unchanged 
[pass] line:154, test: string value 
[pass] line:150, test: text unchanged 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] donation problem

[Geert Janssens]

Op vrijdag 10 februari 2023 17:13:13 CET schreef Derek Atkins:
> The donation process should be as easy as a Paypal transfer.
> I'm not sure where you're seeing an "international bank transfer" or
> anything requiring a text callback?
> 
> -derek

The international bank transfer would be to the European Gnucash bank 
account I'm still managing...

Regards,

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

Re: [GNC-dev] Sample Report with Examples

[Geert Janssens]

Hi,

See answers in between.

Op zondag 15 januari 2023 23:38:07 CET schreef flywire:
> This exercise has left me with a few questions about
> https://github.com/flywire/gnucash/blob/Hello/gnucash/report/reports/example
> /options-example.scm
> 
>1. I'm not clear on the scheme terminology. What are the lines in the
>top-level definitions I labelled initialise values? I understand they are
> not constants and I'd normally call it initialising or assigning variables.

It's exactly that. These are variable assignments. Though "assignment" is 
probably not the exact term used in guile but close enough.

> 2. Why does the section referred to in the above point normally only
> contain option name and help but not default, section, or sort order?

I think the most common reason to do so it because the variables defined above 
would be used in multiple location throughout the code, while those that 
aren't will be used only once.

In the past it may also have been a habit to group translatable strings at the 
top of the file, but that's no longer standard practice.

Keep in mind that the report you're working on is a very artificial and 
extremely limited one. It may have copied and simplified sections coming from 
other reports and it may not all be logical still.

> 3. If option sections are defined, does a default section need to be set?

Setting a default section is optional. If not set, the default section will be 
the first section.

> 4. Can a default General section be added to?
> It seems not and the whole thig must be created.

I'm not sure I understand what you mean. But you can look in other reports 
that have a General section how that is done.

> 5. The formatting style is different to most standard reports.
> Does it need updating?

I think this report has been neglected for ages as it's only purpose was to be 
a lightweight illustration of how options work. It would probably be good to 
update the formatting style while you're at it. Be sure to do that in a 
separate commit though. Debugging gets ugly if formatting changes are mixed 
with actual code changes in the same commit.

>6. How can I make the version number bold:
>   
> https://github.com/flywire/gnucash/blob/3a949c269735709b47e02f181d80ad7e8c6
> 71982/gnucash/report/reports/example/options-example.scm#L340-L345

Have you tried html markup in the format string ?

> 7. What is the best way of understanding/searching the api? Things like html
> format and date interval below or tracing from date interval in other
> reports back to the specific date.

That's a weak point of our code. There's no guile oriented api documentation. 
So you'll have to resort to the C api documentation, which is also incomplete.

In general if you find functions of the format gnc-some-thing those are C-
functions really with the name gnc_some_thing (note the conversion of dashed 
into underscores). Functions names gnc:something are written in guile directly 
and will be found somewhere in the other parts of the guile code. The use-
modules directives at the top give hints to which other guile code is 
referenced.

>8. I'm still not clear on things like let, let*, and nested let.

Those are very much lisp/guile concepts. As Michael suggested you may want to 
get somewhat familiar with the concepts of such functional rather than 
procedural language. Another good place to start may be the guile user manual 
which you can find on the gnu.org website somewhere.

I have to admit it has taken me a very long time as well to get used to the 
functional programming style vs the for me more familiar procedural or object 
oriented programming styles. I'm still not fluent in it, but sufficient to 
work with the gnucash code base.

>9. There seems to be some sort of git corruption. How can I move this
>forward as a contribution?

Without more details, it's hard to tell what your problem really is.

>10. > [raised previously] I'm not sure if version or report-guid should
>be updated.

IMO, no.

Regards,

Geert



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

Re: [GNC-dev] New warnings on cmake master - Fedora 36

[Geert Janssens]

Op maandag 16 januari 2023 17:35:48 CET schreef John Ralls:
> Geert,
> 
> I added those last week because of link failures on Windows; the problem
> turned out to be that ASIO needs winsock, not that there were any
> additional boost libs. I've reverted the part of the commit that added the
> boost modules.
> 
> Regards,
> John Ralls

Perfect. Warnings are gone.


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

[GNC-dev] New warnings on cmake master - Fedora 36

[Geert Janssens]

Commit

https://github.com/Gnucash/gnucash/commit/
fed4daf4e7dea7c85a56ad08f1817319272f7567

Added a number of boost libraries in the cmake check. Since that commit a 
cmake run will spew these warnings:

CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:2217 (message): 
 No header defined for algorithm; skipping header check (note: header-only 
 libraries have no designated component) 
Call Stack (most recent call first): 
 CMakeLists.txt:549 (find_package) 


CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:2217 (message): 
 No header defined for asio; skipping header check (note: header-only 
 libraries have no designated component) 
Call Stack (most recent call first): 
 CMakeLists.txt:549 (find_package) 


CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:2217 (message): 
 No header defined for process; skipping header check (note: header-only 
 libraries have no designated component) 
Call Stack (most recent call first): 
 CMakeLists.txt:549 (find_package) 


CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:2217 (message): 
 No header defined for property_tree; skipping header check (note: 
 header-only libraries have no designated component) 
Call Stack (most recent call first): 
 CMakeLists.txt:549 (find_package)



As the warning suggests, header only libraries shouldn't be added to 
FindBoost. That's at least the case on Fedora. Did you have problems with 
finding these header-only libraries on other platforms ?

Regards,

Geert


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

Re: [GNC-dev] Sample Report with Examples

[Geert Janssens]

All good suggestions.

Let's see how many are reasonable for flywire to pick up and fix. (flywire, I 
have no idea 
of your skill level and willingness to work on this...)
I would already take partial fixes as a step in the good direction.

Regards,

Geert

Op zaterdag 14 januari 2023 16:58:09 CET schreef john:
> Geert,
> 
> Roger. The problem with that argument is that someone with that little
> programming experience isn't going to be able to write a custom report
> anyway. Even someone with enough programming experience to agree that
> default option values aren't significant to the structure of the code isn't
> going to be able to write a custom report unless at least some of that
> experience is in one of  the Lispish languages. The Lispish paradigms of
> car, cdr, lambda, map, and so on are utterly foreign to most procedural
> language programmers, but required for writing GnuCash reports.
> 
> Yes, the use of Hello, World is a bit flippant, and yes, hello-world.scm
> isn't a minimal Scheme program. It's also not a sample report because it
> doesn't demonstrate querying the GnuCash data performing analysis, or
> presenting results. So if someone feels motivated to make it less flippant
> and better described then I suggest:
> 
> * Change the filename to options-example.scm, and the menu-name to "Options
> Example". * Add a report title option. Most of the real reports have one.
> Set its default to "Example Title". * Fix the comment describing the value
> of `name from "This will be used, among other things for making its menu
> item in the main menu.". It doesn't do that, it sets the name on the
> options dialog's title bar and the default value for the General section's
> Report Name option. "menu-name", which is part of the report-registration
> block at the bottom, sets the menu name. The comment should also explain
> that changing the report name option will change the value of the report's
> window or tab title but not its options dialog title. * Change the name
> value to "Options Example Report".
> * Change the two Hello… section names to something like Tab A and Tab B to
> make clear that "Sections" in the option block map to tabs on the dialog
> box. * Change the string option default to "String Option Default".
> * Speaking of the General section, there should be a comment explaining that
> a skeleton General section gets added by gnc:report-template-new-options
> that provides the name (but not the title, reports must add that
> themselves) and stylesheet options.
> 
> Regards,
> John Ralls
> 
> > On Jan 14, 2023, at 2:02 AM, Geert Janssens 
> > wrote:
> > 
> > Ok, I tend to agree partially with flywire on this one.
> > 
> > John, you and I have years of programming experience and to us the default
> > value of an option is a minor detail.
> > 
> > However I can imagine someone with hardly any development experience at
> > all will have a much harder time to map the same string used multiple
> > times in the report code to the output visible on screen. And I
> > sympathize with those that try to create their own custom reports. So
> > yes, using different sample strings in code (even for default values)
> > makes it easier to relate output on the report with what's written in the
> > code - before - any option is changed.
> > 
> > To us this may look like bikeshedding, I think for someone trying to wrap
> > their head around the gnucash code this may actually help.
> > 
> > And while bikeshedding was mentioned, I'd rather use values like
> > "Sample string", "Sample Document Title" and "Sample Report" than the
> > half-baked "Hello String" and "Hello Example".
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Sample Report with Examples

[Geert Janssens]

Ok, I tend to agree partially with flywire on this one.

John, you and I have years of programming experience and to us the default 
value of an 
option is a minor detail.

However I can imagine someone with hardly any development experience at all 
will have a 
much harder time to map the same string used multiple times in the report code 
to the 
output visible on screen. And I sympathize with those that try to create their 
own custom 
reports. So yes, using different sample strings in code (even for default 
values) makes it 
easier to relate output on the report with what's written in the code - before 
- any option is 
changed.

To us this may look like bikeshedding, I think for someone trying to wrap their 
head around 
the gnucash code this may actually help.

And while bikeshedding was mentioned, I'd rather use values like 
"Sample string", "Sample Document Title" and "Sample Report" than the 
half-baked "Hello 
String" and "Hello Example".

As with these changes "Hello, World" is never used, the file name is probably 
better changed 
as well.

Regards,

Geert

Op zaterdag 14 januari 2023 05:47:29 CET schreef john:
> > On Jan 13, 2023, at 6:46 PM, flywire  wrote:
> > 
> > The point is not about the changes options make to reports, it's about how
> > the report source code changes the report and report options. Why
> > wouldn't unique string values help people unfamiliar with reports see the
> > relationship more clearly?
> While it's possible in Scheme to take that quoted option value and convert
> it to code I don't know of any report code in GnuCash that does so. That's
> a very good thing, we have enough Scheme-induced vulnerabilities without
> that.
> 
> With that in mind, no, the quoted-string default values do not in any way
> have anything to do with illustrating how the report source code changes
> the report and report options. Nor, for that matter, does hello-world.scm
> illustrate anything of the sort. hello-world.scm simply provides examples
> of the different types of options and very simply displays the values in
> the report. There's not a single line of code that changes the behavior of
> the report based on an option value--unlike many of the real options in
> most of the real reports.
> 
> Regards,
> John Ralls
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


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

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

[Geert Janssens]

Op zaterdag 14 januari 2023 00:23:21 CET schreef Fred Tydeman:
> On Fri, Jan 13, 2023 at 3:00 PM David H  wrote:
> > Yeah seems to be a typo which will cause the remote-add to fail if you
> > already have the flathub repository installed as follows:-
> > 
> > Wiki says - flatpak remote-add --user --if-not-exists *flathub*
> > https://flathub.org/beta-repo/flathub-beta.flatpakrepo
> > Should be - flatpak remote-add --user --if-not-exists *flathub-beta*
> > https://flathub.org/beta-repo/flathub-beta.flatpakrepo
> 
> Thanks.  That fix lets me get farther.
> I have done a fresh install of Fedora 37 with Gnome 43.2 on Intel 64-bit
> CPU.
> When I try to install the beta, I get an error saying that beta requires
> runtime org.gnome.Platform/x86_64/43
> Is there some way to force the beta to use the system wide Gnome?

No, you can't. Runtimes are a fundamental base concept of flatpaks (and snaps 
or 
appimages by the way) and you can't avoid them.

These runtimes ensure that there's a known common set of libraries available on 
the system 
for the flatpak application to depend on, regardless of the state of the base 
system. Aside 
from allowing the application to install on systems that don't have the proper 
base system, it 
also eliminates a whole host of compatibility issues early on in the 
development process. 
Issues that otherwise have to be solved by distribution maintainers when they 
package the 
applications for the regular packaging system of said distro.

Personally I think both systems (flatpaks vs distro packages) have their own 
distinct 
advantages and disadvantages. And I think both have their place. However in 
this particular 
scenario - distributing beta software for testing - I believe the isolation is 
actually a big 
advantage.

So if you want to install the (beta) gnucash flatpak on your system you will 
also have to 
accept to install the required gnome runtime for it.

If this is a hurdle for you, consider you can also only install it for as long 
as you want to beta 
test gnucash. You can easily remove this runtime together with the gnucash beta 
flatpak 
when you're done testing with the "flatpak uninstall" command.

Regards,

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

[GNC-dev] Test failure on master

[Geert Janssens]

Hi,

I ran our test suite a few moments ago and I get a test failure for the 
finance-quote related 
tests. Below is the relevant detail from the test logs:

[ RUN  ] GncQuotesTest.online_wiggle 
* 22:02:03  WARN  [GncFQQuoteSource::GncFQQuoteSource()] No 
Alpha 
Vantage API key set, currency quotes and other AlphaVantage based quotes 
won't work. 
* 22:02:04  WARN  [GncQuotesImpl::parse_one_quote()] Skipped 
NASDAQ:FKCM - Finance::Quote returned fetch failure. 
Reason Error retrieving quote for FKCM - no listing for this name found. Please 
check symbol 
and the two letter extension (if any) 
* 22:02:04  WARN  [GncQuotesImpl::parse_one_quote()] Skipped 
CURRENCY:EUR - Finance::Quote returned fetch failure. 
Reason unknown 
/home/janssege/Development/gnucash/master/src/libgnucash/app-utils/test/gtest-gnc-
quotes.cpp:164: Failure 
Expected equality of these values: 
 1u 
   Which is: 1 
 failures.size() 
   Which is: 2 
[  FAILED  ] GncQuotesTest.online_wiggle (1690 ms)

I'm not sure what was expected here and why that's different on my system. I 
have 
Finance::Quote 1.53 installed and it works when I run gnucash normally. I do 
have a valid 
Alpha Vantage API key set in the preferences. I'm not sure why this wasn't 
picked up.

Regards,

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

[GNC-dev] Warnings while building master

[Geert Janssens]

Today I rebuilt master from scratch and my eye was caught by the following 
warning:

[22/513] Generating swig-engine.cpp 
/home/janssege/Development/gnucash/master/src/libgnucash/engine/engine-helpers.h:31:
 
Warning 313: Unrecognized extern type "C++". 
/home/janssege/Development/gnucash/master/src/libgnucash/engine/gnc-date.h:83: 
Warning 313: Unrecognized extern type "C++". 
/home/janssege/Development/gnucash/master/src/libgnucash/engine/qofquery.h:90: 
Warning 302: Identifier 'QofQuery' redefined (ignored), 
/home/janssege/Development/gnucash/master/src/libgnucash/engine/gnc-option.hpp:55:
 
Warning 302: previous definition of 'QofQuery'. 
/home/janssege/Development/gnucash/master/src/libgnucash/engine/gnc-commodity.h:56:
 
Warning 313: Unrecognized extern type "C++". 
/home/janssege/Development/gnucash/master/src/libgnucash/engine/gncBusiness.h:40:
 
Warning 313: Unrecognized extern type "C++". 
/home/janssege/Development/gnucash/master/src/libgnucash/engine/gncEntry.h:37: 
Warning 313: Unrecognized extern type "C++".

Would this be a potential issue ? The warnings are generated by swig while 
parsing our 
headers. Normal compilation of objects that include these files works fine.

I don't see anything misbehaving in the built executable either so perhaps it's 
a non-issue.

Regards,

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

Re: [GNC-dev] GnuCash and Github

[Geert Janssens]

I agree self-hosting an alternative solution is more burden than it would bring 
benefit. So 
let's leave it as is for now.

Regards,

Geert


Op vrijdag 18 november 2022 19:12:46 CET schreef john:
> I don't think the silo effect is a big deal. The main impact is on
> transferring bugs and we gave that up when Gnome shut down its Bugzilla
> instance. Cross-project pull/merge requests make no sense, so I guess your
> complaint is that you can't use your Github account to submit a PR to e.g.
> Gtk because while there's a Gtk mirror on Github it doesn't take PRs, you
> have to get a Gnome LDAP account and make your MR (merge request, gitlab's
> name for pull request).
> 
> Based on what I see over at Gnome running a gitlab instance is a lot of
> work. Plus even with the Gnome Foundation's compute resources it frequently
> bogs down. I don't think we'd want to do that.
> 
> I'd never even heard of gitea or codeberg and I've encountered only one
> project on sourcehut. I wasn't terribly impressed.
> 
> We could switch the git mirror to Sourceforge, which would get us the
> code-browsing, though not as nice as GitHub's, and the merge requests. I
> don't know how the edit/discussion flow works there, but I bet it's not as
> nice as Github's either.
> 
> That leaves CI. Sourceforge doesn't provide it, so we'd have to set up our
> own instance of something; Jenkins used to be popular but I don't know if
> it's still considered the best. Regardless that's more time spent setting
> it up, securing, and maintaining it.
> 
> Regards,
> John Ralls
> 
> > On Nov 18, 2022, at 9:15 AM, Geert Janssens 
> > wrote:
> > 
> > That's a good analysis of the situation.
> > 
> > I agree this is largely a legal issue to be solved by organisations like
> > the SFC.
> > 
> > At a deeper level though I agree this could only have happened because OSS
> > has allowed github to become such a golden cage for our projects in the
> > first place. And this seems to happen over and over again.
> > 
> > It has become very hard to leave github because of the network effect. And
> > I agree we can't make others not have a clone of the gnucash repo on
> > github. That doesn't mean we can't make a statement by not hosting our
> > own forks/clones there ourselves if we care enough.
> > 
> > I don't know if *I* care enough. I am concerned about these developments, 
> > but at the same time I wouldn't want to add more infrastructure
> > maintenance to our already limited time.
> > 
> > SFC suggested a few alternatives, either hosted (sourcehut, codeberg) or
> > self-hosted (gitea, gitlab CE, sourcehut).
> > 
> > Codeberg is very similar to github, except for CI (which is currently in
> > closed beta). So it offers much of what our users/contributors are
> > already used to. I don't know about the others.
> > 
> > As a last semi-OT remark/rant, I think all the alternatives are missing a
> > key piece - federation.
> > 
> > You either have a centrally hosted platform(codeberg.org,...), or you have
> > completely isolated islands that happen to use the same software (think
> > gitlab.gnome.org, gitlab.kitware.com,...)
> > 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash and Github

[Geert Janssens]

That's a good analysis of the situation.

I agree this is largely a legal issue to be solved by organisations like the 
SFC.

At a deeper level though I agree this could only have happened because OSS has 
allowed 
github to become such a golden cage for our projects in the first place. And 
this seems to 
happen over and over again.

It has become very hard to leave github because of the network effect. And I 
agree we can't 
make others not have a clone of the gnucash repo on github. That doesn't mean 
we can't 
make a statement by not hosting our own forks/clones there ourselves if we care 
enough.

I don't know if *I* care enough. I am concerned about these developments,  but 
at the same 
time I wouldn't want to add more infrastructure maintenance to our already 
limited time.

SFC suggested a few alternatives, either hosted (sourcehut, codeberg) or 
self-hosted (gitea, 
gitlab CE, sourcehut).

Codeberg is very similar to github, except for CI (which is currently in closed 
beta). So it 
offers much of what our users/contributors are already used to.
I don't know about the others.

As a last semi-OT remark/rant, I think all the alternatives are missing a key 
piece - federation.

You either have a centrally hosted platform(codeberg.org,...), or you have 
completely 
isolated islands that happen to use the same software (think gitlab.gnome.org, 
gitlab.kitware.com,...)

The centrally hosted platforms will invariably lead to similar silo effects as 
github.com or 
gitlab.com if they become more successful. The islands on the other hand 
currently have no 
means of interaction or integration (like tracking an issue issue on another 
'island's' tracker, 
forking to another 'island', creating pull requests across 'islands',...). So 
in both cases the 
very distributed nature of git is not brought up to the level of the web 
interfaces.

The social media landscape is in the same boat in fact, though federation may 
very slowly be 
getting a foot in the door with the recent twitter debacle and a fair number of 
users now 
start to experiment with Mastodon.

Regards,

Geert

Op zondag 13 november 2022 20:50:53 CET schreef john:
> My number one use of GitHub, and IIRC the reason we mirrored it there in the
> first place, is to refer to and reference code when communicating on these
> lists, bug reports, and IRC. That's replaceable too by serving the repo
> ourselves or moving the mirror back to Sourceforge.
> 
> The fear is that Github's copilot will violate our author's copyrights by
> copying sufficiently substantial sections of code into a non-GPL project,
> stripping off the copyright and license in the process. I've seen claims
> that this has already happened.
> 
> In my completely non-legal opinion that makes every project that uses
> CoPilot GPL and the FSF should be suing all of them to publish their source
> code. But I think that's also true of any project whose developers read
> Stack Overflow or search on the web for solutions to their coding problems.
> The world has changed since the GPL was conceived and sharing source code
> meant sending me a blank DECTape and a paid mailer or downloading a tarball
> by anonymous FTP and code on the web--regardless of where--is findable by
> web-searching for a function name, and even if we don't provide web access
> someone else will. The GPL encourages that.
> 
> Plus the bird has flown. Sure, we could take down our Github repo. That
> won't affect the 673 forks, and some of those folks will get our code from
> somewhere and keep their repos up to date.
> 
> In fact it seems to me that the Software Freedom Conservancy is missing the
> point: The problem with Copilot isn't that it's encouraging
> proprietary-software developers to use open-source code in their projects.
> Although the GPL requires that using GPL code turns the project into a GPL
> one, most other FLOSS licenses don't. They require only that copyright
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Geert Janssens]

Op zondag 13 november 2022 20:08:15 CET schreef john:
> > On Nov 13, 2022, at 6:28 AM, Geert Janssens 
> > wrote:
> > 
> > How recent then can "more recent" be ? In my mind anything that's in the
> > most recent LTS, should be fine in all cases. For anything more recent
> > than that, we should consider how hard it would be to self-build the
> > dependency.
> For clarity, I think you mean Ubuntu's latest LTS, currently 22.04.

As far as I know there are only two primary LTS distros:
- RHEL
- Ubuntu LTS

All others are derived from either of these.

In the RHEL 7 series, gnucash got stuck on version 2.6.x - I think - due to 
dependency issues. 
We moved on, but started to ignore RHEL at that point. In addition it's not 
really RHEL that 
carries gnucash. It can only be installed via an add-on repository, EPEL.

In Ubuntu, gnucash is in the Ubuntu proper repos. Also contrary to RHEL, Ubuntu 
LTS has a 
clear release cadence of two years. For RHEL the time between major releases 
has been very 
variable (6 years between 7 and 8, 3 years between 8 and 9, with no commitment 
to a certain 
cadence). All reasons it makes it much harder to predict when our dependencies 
will be 
updated on RHEL.

On the other hand I found today that EPEL 8 ships gnucash 4.9 (https://
packages.fedoraproject.org/pkgs/gnucash/gnucash/epel-8.html[1]). Interestingly 
I didn't find 
gnucash for RHEL 9 in EPEL. I haven't followed the evolutions in that area so I 
don't know any 
details.

That's a lot of ambiguity around a distro to base minimum dependency decisions 
on.

So yes, I meant Ubuntu LTS 22.04 when I wrote that bit.

> 
> > The other approach, where we freeze minimum dependencies on the stable
> > branch, sounds like a nice compromise, but has the drawback that it makes
> > the stable code more complicated in order to accommodate support for
> > multiple versions of a dependency. So we trade the stability of an older
> > dependency for complexity in our own code. I don't know if that's really
> > a good trade-off for a small development team.
> I think that means that we'd bump a dependency's minimum version only in the
> case where there's an API change that would otherwise require that we have
> to #ifdef on the dependency version--or rather that bumping the minimum
> version lets us remove ifdefs introduced to keep building on both the
> current Ubuntu LTS and bleeding-edge distros like Arch Linux and Debian
> Unstable.
> 
Just for clarity, you're still talking about our stable series as well, right?
In practice this means we indeed may have to introduce #ifdefs if a bleeding 
edge distro 
makes API changes that affect our code and that we only can remove them the 
moment a 
new Ubuntu LTS release ships. I don't know the exact details of the LTS 
lifecycle. I know there 
are intermittent sub releases for the LTS as well (as opposed to the normal 
Ubuntu releases), 
but I have no idea which if any library version bumps are allowed in these sub 
releases.

> Then there's Gnome and macOS which have very nice versioning macros and
> deprecation policies that let you tune what the compiler will warn about.
> See e.g. https://docs.gtk.org/glib/const.VERSION_MIN_REQUIRED.html. There's
> a corresponding GLIB_VERSION_MAX_ALLOWED that somehow eluded gi-doc, see
> glib/versionmacros.h.in. There are corresponding macros for Gtk and Gdk.
> The idea is that MIN_REQUIRED will emit deprecation warnings for API
> deprecated in that version or earlier while MAX_ALLOWED will warn if you
> use API that was introduced after that version. Should we start using these
> to try to keep our code more current? (I think so.) If so how should we set
> them?
> 

I'm not sure I get how these can help us. Can you give an example of when and 
why to set 
either parameter ?

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

Re: [GNC-dev] Git branches

[Geert Janssens]

I'm fine with just doing the simple name change for our two primary branches as 
it's the 
option of least effort.

I'd rather have a different name than "main" though. It's a bit ambiguous and 
like "master" 
suggesting this branch is somehow more important than the other long-term 
branch 
"maint". I'd rather have names that help guide contributors to the right branch 
to work from. 
I don't think there's a silver bullet here though, but some names may give more 
of a hint 
than others. Some suggestions:

* "current" vs "future" as shorthands for "current-release-series" or 
"future-release-series" 
* "maintenance" ("maint") vs "development" ("devel")
* "stable" vs "development"

That said, I'm also very interested in the single branch model as alternative. 
Discussion on 
that is for another message.

Regards,

Geert

Op maandag 14 november 2022 20:59:26 CET schreef john:
> > On Nov 14, 2022, at 11:11 AM, Alex Aycinena 
> > wrote:
> > 
> > how about a simple change, like calling it 'main' rather than
> > 'master' and keeping the existing pattern for branches.
> 
> That would be OK as long as long as the two names aren't similar. main and
> stable would be OK; with main and maint one is far too likely to do
> something to the wrong branch.
> 
> Regards,
> John Ralls
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


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

Re: [GNC-dev] Git branches

[Geert Janssens]

Op maandag 14 november 2022 19:59:24 CET schreef john:
> I guess we could do that as long as we continue the no-backports policy, but
> it's something you argued against when we started using git-flow a few
> years ago.
> 

I don't have a clear memory of what I argued against way back then. It doesn't 
matter much. 
In reality we have continued to avoid backporting anyway, which is just fine 
for the small 
team that we are.

> 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/.

It's actually a branch and release pattern I had been considering but was 
hesitant to bring 
up as perhaps to radical. Since you now bring it up for consideration, let's 
evaluate it after all.

1. I like the idea of only a single release branch and all development 
happening on feature or 
bugfix branches that get merged into this release branch when ready. 

2. I also like the idea of dropping distinction between a stable and 
development series. It 
would bring improvements to users much faster in general - it will be released 
when ready, 
not queued for the next major release (which could be only in 2 years worst 
case).
It's a bit what fast moving projects such as webbrowsers currently do.

3. Year based release numbering is also very clear. And always gives a 
reasonable indication 
of how old a given version of gnucash is.


On the flip side
1. This does do away with semantic versioning completely. But that's the whole 
point of 
having only one release branch. Each release can be a mix of bugfixes and new 
features.
2. I imagine this only works well if newly added code (features or bugfixes 
alike) is well 
tested, implying having tests written for it. And that the existing code base 
is well tested as 
well. While slowly improving, the gnucash code is still not very well covered.

I also read through the dymitruk article you linked to. There are a few other 
elements that 
are not fully clear to me yet:

* he talks about an integration branch. Is that a branch that people continue 
to merge their 
new work in, and that just serves 
a. to discover and resolve merge conflicts early on and
b. to run an integration test suite on
Will this branch ever be cleaned or just merge upon merge be added to it ? I 
have no clear 
example of how such a branch is used really.

* there's a separate release branch. Which can be reset from time to time if 
bad features are 
to be skipped for the most recent release. Resetting a branch seems to conflict 
with 
distributed repositories in my mind. But perhaps this is not a problem if it's 
commonly 
known this a a resettable branch. And no devs except for the release manager 
should really 
check out this branch and then even only while preparing for releases ? It's a 
bit vague to 
me.

* handling merge conflicts and sharing the resolutions seem to be an important 
part of the 
solution. Otherwise these conflicts continue to trip up different devs. There 
was a suggestion 
as to how to do this, but nothing concrete. Something to figure out as well.



As for the API and schema changes, that would indeed require some 
reconsideration. 

I have a few first thoughts, but nothing well structured:

* For API the important change to keep in mind is deprecation. New API won't be 
an issue.  
Do we support function signature changes or should a new function be defined in 
that case ?
Current policy is that we deprecate in a stable series and remove in a future 
major release. 
As our current schedule is a two-year cycle for major releases, we could make 
the policy "a 
deprecated feature/function will be kept around for 2 years, after which it 
will be definitely 
removed". Other durations can be chosen as well, as long as it's clear. So 
consumers of the 
api could at most jump two years ahead from the version they currently use with 
a 
guarantee their own code continues to work. At that point they should do the 
work of 
updating their code to cope with deprecated api.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Git branches

[Geert Janssens]

This had been brewing in my mind as well, so thanks for bringing this up.

When I considered alternative branch names I initially thought of "stable" vs 
"development" 
or "devel" with an optional "unstable" at times of pre-releases. 

However when thinking this through some more I started wondering whether we 
really 
should limit ourselves to just two (or three) branch names.

We could also name our branches "4.x", "5.x" and so on to indicate the release 
series this 
branch is for. At some point we just stop using the older branches. We can 
choose to drop 
them or just leave them in the git history as it suits is best.

Both naming schemes have advantages and drawbacks. I like the direct 
relationship 
between branch name and releases that will be on it for the latter scheme. 
Although I admit 
this relationship doesn't hold for the pre-releases, unless we make that a 
separate branch for 
those like eg "4.9xx".

Regards,

Geert

Op zondag 13 november 2022 21:40:14 CET schreef john:
> Since Geert brought up our relationship with Github I thought it timely to
> start a discussion about a related trend: The name of the git repository's
> primary branches. There's an ongoing effort in the software development
> community for the last 25-30 years or so to remove the terms master and
> slave; originally when used together (as in processes) but more recently
> when used alone. This recently includes the name of the primary branch in a
> git repository. The Gitlab folks have a nice summary at
> https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/.
> 
> 'Master' was the standard when we started using git 10 years ago and so we
> adopted it and still use it. Aside from the cultural sensitivity issues
> (primarily in the United States because of our unfortunate history with
> forced importation and enslavement of Africans) it has proved to be a bit
> confusing to new contributors.
> 
> The new standard default is 'main'. I think that would be fine for htdocs
> where we have master and beta: Main would better express that that's the
> branch that you see when you visit https://www.gnucash.org
> . The gnucash-on-foo repositories for the build
> processes have only master branches so it doesn't really matter what the
> branch is called.
> 
> I don't think 'main' is the right name for gnucash or gnucash-docs because
> it does nothing about the confusion factor. Note that the default branch on
> those two is maint but we still use master for the next major release's
> branch. The most expressive titles would be current-major-release and
> next-major-release but they're a bit wordy; OTOH just current (or curr) and
> next leave a new contributor to ask current and next what? maint is concise
> and not terrible for a branch that gets only bug fixes and small features.
> Lots of generic names for the next-major-release branch (future, devel or
> development, major-change) come to mind but I'm not sure that any of them
> clearly express the intent of the branch.
> 
> Comments?
> 
> Regards,
> John Ralls
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


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

[GNC-dev] GnuCash and Github

[Geert Janssens]

Some may have heard the rumblings around github semi-recently. The software 
conservancy is calling free software projects to seek alternatives. They 
motivate this in much 
more detail over here:
https://sfconservancy.org/GiveUpGitHub/[1]

In short, they claim github is a proprietary tool that's leveraging the hosted 
free software for 
their commercial purposes. In itself that would be acceptable as long as it's 
done according 
to the licenses of these free software projects. There have been several 
situations where 
that's not the case, "copilot" being the latest and most worry-some.

Is this something we as a free software project should think about and possibly 
act on ?

Personally I don't like it at all that I chose to write code under a free 
software license to 
ensure my effort helps and benefits the free software ecosystem. Yet that a 
commercial 
company then decides to use my code to train an AI that's meant to help build 
proprietary 
software. The legal status of that is still very unclear and certainly not what 
I intended my 
code to be used for.

That is obviously only my personal opinion, but I wanted to express it as 
starting point for a 
wider discussion on this topic.

Is the golden cage that is github to developers really becoming detrimental to 
real free 
software principles ?

Should we do something about this ? Once hooked into the github ecosystem it's 
pretty hard 
to leave, as the sfc also acknowledges. They do offer initial suggestions for 
alternatives, but 
they are not at the same level as github currently.

Please share your views on this topic as well.

Regards,

Geert


[1] https://sfconservancy.org/GiveUpGitHub/
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Geert Janssens]

Op zaterdag 29 oktober 2022 18:53:57 CET schreef john:
> What really makes sense? How many users are building for themselves and on
> what?

Here are a few of my thoughts on this topic (I threw away several earlier 
attempts because 
they became way too long...)

With my developer hat on I prefer to have as little conditional code as 
possible in the sources 
as this complicates reasoning about the code and makes it harder to test. So 
ideally no parts 
of the code that require certain versions of a dependency and other parts of 
the code for 
other versions of that same dependency. So that's the "most extreme" policy in 
John's 
writing. I am aware this is not always possible, especially as we offer gnucash 
on multiple 
platforms.

The other approach, where we freeze minimum dependencies on the stable branch, 
sounds 
like a nice compromise, but has the drawback that it makes the stable code more 
complicated in order to accommodate support for multiple versions of a 
dependency. So we 
trade the stability of an older dependency for complexity in our own code. I 
don't know if 
that's really a good trade-off for a small development team.

>From the perspective of an end user (on linux), the group affected the most 
>are self-builders. 
A few have spoken up, but I have no idea of the size of this group in the wider 
community 
and whether or not they tend to run up-to-date distros.

The feedback we have received so far expresses a prudent willingness to 
self-build 
dependencies if needed.

On the whole my opinion is we can aim for more recent dependencies when it's 
useful, 
needed or desired.

How recent then can "more recent" be ? In my mind anything that's in the most 
recent LTS, 
should be fine in all cases. For anything more recent than that, we should 
consider how hard 
it would be to self-build the dependency.

Regards,

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

[GNC-dev] ANNOUNCE: Updated GnuCash with Finance::Quote 1.53 available on Flathub

[Geert Janssens]

We have updated the GnuCash package on flathub to 
include Finance::Quote 1.53.

The new flatpak is released as version 4.12-1.

Update the org.gnucash.GnuCash flatpak via your 
distribution's package manager or by runing 'flatpak --
update org.gnucash.GnuCash' on the command line.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Flatpak GnuCash and Finance::Quote

[Geert Janssens]

Op zondag 16 oktober 2022 18:11:04 CEST schreef Bruce Schuck:
> On Sun, 16 Oct 2022 12:38:05 +020 Geert Janssens wrote:
>  > Bruce S wrote:
> >> And my bonehead move was accidentally removing
> >> LWP::Protocol::https from the dependency list in dist.ini. So when
> >> running flatpak-cpan-generator.pl be sure to add it to command
> >> line so it's in the JSON file.
> > 
> > Did you already fix this ? When I tested today the list of
> > dependencies was identical, regardless of whether I added
> > LWP::Protocol::https to the dependency list or not.
> 
> I quietly pushed F::Q v1.5301 to CPAN for just this minor correction.
> Sorry if that caused any confusion.
> 
> - Bruce S.

 No problem. I'm glad it's fixed.

Regards,

Geert

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

Re: [GNC-dev] Flatpak GnuCash and Finance::Quote

[Geert Janssens]

Bruce,

This is a good tip!

At least the sources can be sorted deterministically in alphabetical order. The 
order of this list 
is not relevant for the build.

The order of the build rules is (all the calls to make-install). And 
unfortunately that  list is still 
shuffled each time flatpak-cpan-generator.pl is run. Each variation is a proper 
build order, but 
it does shuffle around.

I guess we can live with this for now. If the sources are already sorted 
consistently, we have 
an easier time tracking when dependencies change.

Regards,

Geert

Op donderdag 13 oktober 2022 03:05:51 CEST schreef Bruce Schuck:
> Geert,
> 
> One additional note. In the README for gnucash-on-flatpak, you or some
> one else notes about the flatpak-cpan-generator.pl script:
> 
> "Note I have found the script to be not very version control friendly:
> generated-sources.json will change a lot between runs. It will have the
> exact same sources and dependencies, but they are shuffled around.
> Experiments indicate this is already due to the way cpanminus handles
> dependency resolution. The order in which same-level dependencies are
> processed is not stable. A minor annoyance I can live with for now."
> 
> May I suggest using the 'jq' tool.
> 
> The command "cat generated-sources.json | jq -S 'sort_by(.dest)'" will
> sort both the keys in each section (you will notice that the raw file
> may contain one module's data listed as url, dest, type, sha256; then
> the next as dest, type, sha256, url) and order the modules
> alphabetically in the output (I have not yet figured an easy way to
> ignore case).
> 
> When building a test flatpak on Ubuntu 22.04 I had to change the
> build-command in modules/perl.json to "perl-libs/install.sh" from
> "install.sh".
> 
> - Bruce S.


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

Re: [GNC-dev] Flatpak GnuCash and Finance::Quote

[Geert Janssens]

Op dinsdag 11 oktober 2022 21:59:05 CEST schreef Bruce Schuck:
> On 10/11/22 12:46 PM, Geert Janssens wrote:
> > Well, what do you know! Looking at the history it was me apparently
> > that had added this information... completely forgotten.
> > 
> > Yes, I think that script is currently sufficient to do regular
> > updates. In fact I will try to update the flatpaks in the next couple
> > of days to ship with the newest F::Q. May take until the weekend
> > though as I'm quite busy this week.
> 
> And my bonehead move was accidentally removing LWP::Protocol::https from
> the dependency list in dist.ini. So when running
> flatpak-cpan-generator.pl be sure to add it to command line so it's in
> the JSON file.
> 

Hi Bruce,

Did you already fix this ? When I tested today the list of dependencies was 
identical, 
regardless of whether I added LWP::Protocol::https to the dependency list or 
not.

Regards,

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

Re: [GNC-dev] Flatpak GnuCash and Finance::Quote

[Geert Janssens]

Op dinsdag 11 oktober 2022 19:26:33 CEST schreef Bruce Schuck:
> On Mon, 10 Oct 2022 13:01:24 -0700, bsch...@asgard-systems.com wrote:
> > But, in the META.json or META.yml file created by Dist::Zilla when
> > 
> > The caviat is that list is still not complete because of how
> > installations via CPAN works, but will be enough for someone to
> > execute "cpan Finance::Quote" and install the latest/current
> > release.
> 
> Geert,
> 
> I was looking at https://github.com/Gnucash/gnucash-on-flatpak which
> points one to
> https://github.com/flatpak/flatpak-builder-tools/tree/master/cpan.
> 
Well, what do you know! Looking at the history it was me apparently that had 
added this 
information... completely forgotten.

Yes, I think that script is currently sufficient to do regular updates. In fact 
I will try to update 
the flatpaks in the next couple of days to ship with the newest F::Q. May take 
until the 
weekend though as I'm quite busy this week.

Regards,

Geert


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

Re: [GNC-dev] Flatpak GnuCash and Finance::Quote

[Geert Janssens]

Op donderdag 6 oktober 2022 14:00:05 CEST schreef Vincent Lucarelli:
> Hi,
> 
> F::Q uses Dist::Zilla to create the distribution and Dist::Zilla provides a
> mechanism to list all dependencies.
> 
> Is it possible in the build commands for a flatpack to bootstrap - install
> perl, install Dist::Zilla, use Dist::Zilla to install all F::Q perl
> dependencies, then install F::Q?


We can't directly integrate that in the flatpak build. I mean we can't write a 
script that's called 
when the flatpak manifest file is processed - flatpak expects reproducible 
builds, so we have 
to record which versions of each source that are used in the manifest file so 
others can rerun 
the build an get the exact same binary as result.


However, I think a helper script as part of the gnucash-on-flatpak repo that 
lists 
dependencies and/or proposes an updated manifest file when run would certainly 
be 
helpful. That way a dev can choose when to update the build dependencies 
instead of having 
each build start with a an updated set of dependencies. That manual deps update 
could for 
example be run when a new version of F::Q is released.


In practice, can you refer to an example invocation of Dist::Zilla (perhaps in 
the F::Q build 
system) we can take as a basis to write such a helper script ?


Regards,


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

Re: [GNC-dev] Flatpak GnuCash and Finance::Quote

[Geert Janssens]

Op dinsdag 4 oktober 2022 13:32:55 CEST schreef john:
> > On Oct 3, 2022, at 7:56 PM, Frank H. Ellenberger
> >  wrote:
> > 
> > Hi,
> > 
> > comments inline
> > 
> > Am 03.10.22 um 18:23 schrieb Bruce Schuck:
> >>> Date: Sun, 2 Oct 2022 21:09:31 -0700 From: john 
> >>> Correct. IIUC there are a lot of things not normally included in a
> >>> flatpak installation required to run cpan, so it's not really a
> >>> practical option. We build Finance::Quote and all of its dependencies
> >>> from source tarballs, see
> >>> https://github.com/Gnucash/gnucash-on-flatpak/blob/master/modules/financ
> >>> e-quote-sources.json. Unfortunately F::Q has a lot of dependencies and
> >>> the list isn't
> >>> stable, so keeping up with the latest often falls in the "too much
> >>> effort" category and doesn't get done.
> >>> If there's a better way, please share.

As it was me really who implemented Finance::Quote support in flatpak, I can 
share how I 
got the list of dependencies. I looked at the dependencies for the Fedora rpm 
for F::Q and 
just copied all dependencies from there.

It's true this remains largely manual work. However to update, I would again 
check the 
current version numbers of all dependencies as found in a recent Fedora repo 
and use 
those. If we do this from time to time (eg each time a Fedora is released - 
that is every 
half year), we can more or less keep up. At least someone else has figured out 
a working 
set of dependencies each time.

The other option is to just do the dependency updates each time a new F::Q is 
released or 
whenever F::Q requires newer dependencies than we currently have.
Regardless the option, we will have to go through this from time to time 
unfortunately.

Regards,

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

Re: [GNC-dev] Flatpak GnuCash and Finance::Quote

[Geert Janssens]

Op maandag 3 oktober 2022 00:38:23 CEST schreef Bruce Schuck:
> Hello all,
> 
> Noticing that the most recent Flatpak version of GnuCash (4.12+ (Flathub
> 4.12)) has v1.49 of Finance::Quote, I wanted to update to the recent
> release candidate I pushed to CPAN. I believe there are issues running
> gnc-fq-update or cpan within the flatpak container because some of the
> modules required by F::Q v1.52 and later require the gcc compiler to
> make and install. As far as I can see, gcc is not in the flatpak GnuCash
> distribution.
> 
> While copying the ./lib/Finance tree from GitHub or a downloaded tarball
> may seem to work, some of the lesser used methods for data retrieval may
> not work.
> 
> - Bruce S.


Flatpak follows a completely different distribution model than typical 
distributions do. It 
starts from the concept of an immutable base system. You are not supposed to 
manipulate 
this directly. So running gnc-fq-update is unfortunately not supposed to work 
within flatpak 
and the whole concept is designed to make that difficult to do.


The runtime that's normally used to run flatpak applications doesn't have any 
developer 
tools. You can switch to using sdk packages instead as Frank linked to, but it 
remains limited.


Having said that, there are several options to get newer versions of 
Finance::Quote in the 
hands of gnucash flatpak users. Though all involve rebuilding the gnucash 
flatpak in some 
way.


1. We have our own flatpak repository in which we publish nightly builds. The 
source for 
these nightly builds is the Gnucash/gnucash-on-flatpak repo on github. The 
build system is 
fairly automated (more on that later).


2. You can also use the same repo to set up your own build environment for 
gnucash 
flatpaks, if your main goal is to test for yourself or before you submit a PR 
to gnucash-on-
flatpak. I don't know how easy or hard this is perceived by outsiders (I 
created that repo and 
the scripts in there, so to me it's obviously not too hard).


3. The flatpaks as distributed on flathub are also under the gnucash project's 
control. We 
typically first test our changes in gnucash-on-flatpak and if proven ok, we 
copy the same 
patches to flathub. Flathub offers both a stable and a beta branch. On stable 
we should only 
push stable software, so release  candidates for Finance::Quote don't belong 
there. However 
we could experiment on the beta branch if that helps.


The idea is the same in all cases: flatpak builds follow a recipe as describe 
in a manifest file. 
Our manifest file is split up in smaller parts for readability but in general 
this contains a list 
of source packages, where to find them and how to build them. The sources for 
Finance::Quote are in
https://github.com/Gnucash/gnucash-on-flatpak/blob/master/modules/finance-quote-sources.json[1]
The way to update is to change version numbers of tar balls and the sha256 sums 
for these 
tarballs. Pushing these changes to the correct upstream repos will trigger new 
builds of the 
respective flatpaks.


Regards,


Geert


[1] 
https://github.com/Gnucash/gnucash-on-flatpak/blob/master/modules/finance-quote-sources.json
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Conditions to move revamped GnuCash Mobile App to GnuCash org

[Geert Janssens]

Hi Daniel,

Generally it would be great to have a gnucash presence on mobile devices.

As John I also welcome more presence and interaction in the gnucash mailing 
lists by people 
interested in maintaining GfA concerning use and development of that app. That 
would 
really kickstart the integration in the larger gnucash community as a whole in 
a more natural 
way. Your current request is a good initiative in that respect by the way.

My other concern is that currently gnucash and GfA don't share a single line of 
code. Other 
than the intention to be compatible they are two fully independent projects. 
That's 
unfortunate.

To be fair, at the time Ngewi did the GfA summer of code that was not feasible 
as much of 
that core functionality relied on code that is hard to port to Android, in 
particular parts were 
written in guile (a scripting language) and most of it depended (and still 
does) on glib2.

We are currently at a point that guile is mostly eliminated from the core 
functionality. I don't 
know how difficult it is these days to use glib2 on Android. However I see 
other glib2 based 
projects being ported (like vlc) so apparently it's doable.

It has always been my view that the core functionality should be shared between 
all gnucash 
implementations (desktop, mobile, ...). I believe that's important for solid 
long-term 
compatibility and interoperability across the board. It would also reduce 
maintenance of the 
app in the long-term as more bits of code are shared. This is also the reason I 
have kept 
pushing to eliminate all guile dependencies from the core functionality for 
years. The effort 
has paid off IMO.

So for GfA to really become *gnucash* for android, I would really like to see 
it work towards 
more code sharing with gnucash. Otherwise it remains a companion app and should 
clearly 
be marketed as such. The name currently used is misleading.

All that to say IMO it's important to clearly define the goal of the GfA 
project: either it aims to 
truly become gnucash on Android (reusing core functionality) or it decides to 
remain a 
companion app (properly named to reflect that).

Other than that I can only encourage renewed interest in GfA (or an iOS 
sibling)!

Regards,

Geert

Op donderdag 29 september 2022 02:09:53 CEST schreef Daniel Brown:
> Hello GnuCash devs,
> 
> does someone here have (had) a relation to the gnucash-android project?
> I couldn't find a way to contact the mainter "codinguser" and the project is
> abandoned: https://wiki.gnucash.org/wiki/GnuCash_and_Mobile_Devices
> 
> Recently there have been a couple of people (including me) who would like to
> contribute/maintain/fork/rewrite the project to keep it alive:
> https://github.com/codinguser/gnucash-android/issues/913
> 
> I have started a couple of steps to revive the project and will try to
> establish a new leading fork so that all the open contributions can find
> its way into the app. And as part of this revamp I would consider aligning
> the project to gnucash.org
> 
> What would be necessary, to move and continue the project under the gnucash
> org in the future?
> 
> I mean not only GitHub organization, but it would would be great to see the
> project as an official part of the community, with vendor "GnuCash" in the
> app store, mailing-list for support and so on.
> 
> 
> Best Regards
> Daniel
> ___
> 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] Simple Start to Contributing

[Geert Janssens]

Op zaterdag 16 juli 2022 14:44:06 CEST schreef Paul Kroitor:
> I have no trouble following the Guile/Scheme -- Lisp was one of the original
> 14 languages I studied in college -- and many reports date back 20 years or
> more anyway. The difficulties come more with the layers of approaches /
> authors you get in such mature systems. For example, the balance sheet and
> income statement use common support modules that enable certain standard
> optional behaviours, but the cash flow wasn't written to use said modules,
> so one has to duplicate the functionality but really should toss half the
> cash-flow and use the (better) common support modules.
> 

Hi Paul,

Welcome to gnucash indeed.

That's an interesting analysis of the cash flow report and at the same time 
that could be an 
opportunity for your next contribution (if you feel so inclined of course)  :)

Regards,

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

Re: [GNC-dev] gnucash/gnome-utils/gnc-plugin-page.h missing a documentation parameter

[Geert Janssens]

Thanks, 

I have pushed your suggested fix to maint.

Regards,

Geert

Op zondag 27 februari 2022 08:47:09 CET schreef Kevin Buckley:
> This stanza in gnucash/gnome-utils/gnc-plugin-page.h
> 
> /** Set the color of this page. This is the color string used
>  *  in the notebook tab.
>  *
>  *  @param page The page whose name should be retrieved.
>  *
>  *  @param The color for this page.  This string is owned by the page and
>  *  should not be freed by the caller.
>  */
> void gnc_plugin_page_set_page_color (GncPluginPage *page, const char
> *color);
> 
> appears to be missing the parameter name color
> 
> Line 408 should presumably be
> 
>  *  @param color The color for this page.  This string is owned by the page
> and
> 
> HTH
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




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

Re: [GNC-dev] documentation html location

[Geert Janssens]

Op donderdag 27 januari 2022 07:31:33 CET schreef Chris Good:
> Hi,
> 
> It's been quite a while since I built the documentation and much has
> changed.
> 
> https://wiki.gnucash.org/wiki/Documentation_Improvement#In_HTML_and_Other_Fo
> rmats
> says:
> 
> The built html files with be placed in an automatically created directory,
> which if using the example directories will be:
> $HOME/code/gnucash-docs/build//C/gnucash-
> ..
> To view the results in a web browser, in a file manager (or for Windows:
> Windows Explorer/File Explorer) double click on either:
> $HOME/code/gnucash-docs/build/help/C/gnucash-help/help.html
> # or
> $HOME/code/gnucash-docs/build/guide/C/gnucash-guide/index.html
> 
> But when I did it on my Ubuntu system,
> 
> help.html is
> 
> build/share/doc/C/gnucash-help/help.html
> 

Indeed. The build directory is now laid out as if it's an install directory. 
(We do the same for 
the gnucash application's build directory). This (mostly) eliminates the need 
to actually install 
to verify code or documentation changes.

> Should I update the wiki?
> 

Please do.

Regards,

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

Re: [GNC-dev] Preferences for Accounting Period start-date and end-date lost on 4.9 Install

[Geert Janssens]

Hi Chris,

I don't think we support building a 64bit version on Windows.

Can you run your commands in the 32bit mingw64 shell (MSys2 64bit/MSys2 MinGW 
32-bit) 
to at least avoid any additional bugs due to the different environment ?

Note the name is confusing. MingW64 is the name of the project (to 
differentiate from an 
older MingW32 project), but it provides both a 32bit and a 64bit environment 
for 
development. So far gnucash has only used the 32bit environment.

Regards,

Geert

Op vrijdag 14 januari 2022 08:01:09 CET schreef Chris Good:
> Hi Devs,
> 
> I'm trying to build gnucash-on-windows so I can find where the "subscribe"
> error above is coming from.
> I ran setup-mingw64.ps1 like:
> E:
> cd \Data\GnuCash\gcdev64
> .\setup-mingw64.ps1 -target_dir "e:\\Data\\GnuCash\\gcdev64" -download_dir
> "e:\\Data\\GnuCash\\gcdev64\\downloads" -x86_64
> 
> The setup seems to have worked with the exception of HtmlHelp but I don't
> need to build the documentation so I've ignored that.
> 
> The build is failing when I run in a MSYS2 64Bit / MSYS2 MinGW x64 window
> (not as admin):
> (As suggested by
> https://wiki.gnucash.org/wiki/Building_on_Windows#Running_a_build)
> 
> cd /e/Data/GnuCash/gcdev64/src/gnucash-on-windows.git
> TARGET=gnucash-maint jhbuild -f jhbuildrc build
> 
> Please see attached full log.
> 
> Note the output from the setup says:
> 
> Your build environment is now ready to use. Open an MSys2/mingw64 shell from
> the start menu, cd to /e/Data/GnuCash/gcdev64, and run
> jhbuild -f src/gnucash-on-windows.git/jhbuildrc build
> 
> Should I be doing that before the above "TARGET=... command or instead of?
> 
> Regards, Chris Good


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

Re: [GNC-dev] Problems compiling and running gnucash on linux mint (was: Trouble with gsettings in GC 4.9)

[Geert Janssens]

Hi Dirk,

The log messages seem to indicate you may have a version mismatch in guile 
between your 
build environment and your runtime environment.

I base that observation on this line
> ;;; note: source file
> /opt/gnucash/share/guile/site/2.2/gnucash/utilities.scm
> ;;;   newer than compiled
> /home/banking/.cache/guile/ccache/2.0-LE-8-2.0/opt/gnucash/share/guile/site/
> 2.2/gnucash/utilities.scm.go

The '2.0-LE-8-2.0' part suggests your runtime is using guile 2.0, while
this part 'opt/gnucash/share/guile/site/2.2/' suggests your build environment 
used guile 2.2 
to compile the guile source files in gnucash.

Or a slightly different way to say this - gnucash got linked to guile 2.0 while 
the guile sources 
were compiled with guile 2.2.

guile 2.0 can't read files compiled with guile 2.2, hence
1. the error message about bad header objects
2. gnucash' attempt to recompile these sources at run time

My first guess is you have not installed the proper -dev package for guile. You 
may need to 
install guile-2.2-dev (and possibly remove guile-2.0-dev).

Regards,

Geert

PS when sending messages to the mailing-list, please do not reply to existing 
messages if 
you want to start a new discussion. Your subject line refers to another 
discussion, which is 
confusing.

Op vrijdag 7 januari 2022 14:56:57 CET schreef bugzilla:
> Hi Derek,
> thanks for your prompt reply. I am not sure if version 3.8 had been
> uninstalled before the *BUILT* process. So I did the following:
> cd gnucash/build
> sudo make uninstall
> make clean
> rm ~/.cache/dconf/user
> mv /opt/gnucash/share/glib-2.0/schemas/gschemas.compiled
> /opt/gnucash/share/glib-2.0/schemas/gschemas.compiled.bkp
> (there were no other files inside the 'schemas' folder)
> 
> Now I also get error messages that point to /.cache/guile/
> 
> /opt/gnucash/bin/gnucash
> This is a development version. It may or may not work.
> Report bugs and other problems to gnucash-devel@gnucash.org
> You can also lookup and file bug reports at https://bugs.gnucash.org
> To find the last stable version, please refer to https://www.gnucash.org/
> ;;; WARNING: loading compiled file
> /opt/gnucash/lib/x86_64-linux-gnu/guile/2.2/site-ccache/gnucash/utilities.go
> failed:
> ;;; ERROR: In procedure make_objcode_from_file: bad header on object
> file: "\x7fELF\x02\x01\x01ÿ\x00\x00\x00\x00\x00\x00\x00\x00"
> ;;; note: source file
> /opt/gnucash/share/guile/site/2.2/gnucash/utilities.scm
> ;;;   newer than compiled
> /home/banking/.cache/guile/ccache/2.0-LE-8-2.0/opt/gnucash/share/guile/site/
> 2.2/gnucash/utilities.scm.go ;;; note: auto-compilation is enabled, set
> GUILE_AUTO_COMPILE=0
> ;;;   or pass the --no-auto-compile argument to disable.
> ;;; compiling /opt/gnucash/share/guile/site/2.2/gnucash/utilities.scm
> ;;; WARNING: loading compiled file
> /opt/gnucash/lib/x86_64-linux-gnu/guile/2.2/site-ccache/gnucash/core-utils.g
> o failed:
> ;;; ERROR: In procedure make_objcode_from_file: bad header on object
> file: "\x7fELF\x02\x01\x01ÿ\x00\x00\x00\x00\x00\x00\x00\x00"
> ;;; WARNING: loading compiled file
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Trouble with gsettings in GC 4.9

[Geert Janssens]

Glad you got it fixed!

Happy new year to you too!

Geert

Op vrijdag 31 december 2021 13:02:40 CET schreef Christian Wehling:
> Hi John, Geert,
> It works, thanks for your help!
> 
> What have I done?
> 1. emptied all old, not needed build directories and uninstalled the old
> flatpak version. 2. removed all org.gnucash.*.gschema.xml and
> gschemas.compiled from /usr/local/share/glib- 2.0/schemas/
> 3. deleted $HOME/.cache/dconf
> 4. install GnuCash 4.9 again
> 
> Regards and a happy new year,
> Christian
> 
> Am Freitag, dem 31.12.2021 um 11:54 +0100 schrieb Geert Janssens:
> > This is misleading.
> > 
> > Even the newer gnucash still installs schemas for org.gnucash.
> > next to org.gnucash.GnuCash.
> > In recent versions these are defined in
> > org.gnucash.GnuCash.deprecated.gschema.xml (1)
> > 
> > 
> > So it's absolutely normal both will still show up in dconf.
> > 
> > However if there are *two* sets of gschema.xml files that define the same
> > org.gnucash. schema, the glib schema compiler will bail out as
> > soon as it detects the first duplicate schema. As a result it won't reach
> > the schema files starting with org.gnucash.GnuCash and hence it won't
> > compile the newer schema.
> > 
> > I have now looked at your dconf.backup file. It shows both
> > org.gnucash. and org.gnucash.GnuCash. entries.
> > That's correct and should be so since gnucash 4.7. That's when I added
> > the new schema.
> > 
> > I also went back to your very first message. In there you write:
> > >  If I run:
> > >  glib-compile-schemas --strict /usr/local/share/glib-2.0/schemas/
> > >  /usr/local/share/glib-
> > >  2.0/schemas/org.gnucash.dialogs.business.gschema.xml:3:1  Fehler in
> > >  Zeile 3, Zeichen 1:  wurde
> > >  bereits angegeben.  --strict was specified; exiting.
> > 
> > This really points as /usr/local/share/glib-2.0/schemas as the cause. It
> > holds gschema.xml files from before gnucash 4.7 (the ones named
> > org.gnucash.
> > 
> > As we have been talking about this in all directions it's not clear to me
> > whether these are still there. If so, can you remove those and rerun
> > ninja install ?
> > 
> > Or instead of ninja install you can also do as John suggests in directly
> > rerun glib-compile- schemas. For that to work the
> > org.gnucash.GnuCash. schema files should be left in that
> > directory though.
> > 
> > Regards,
> > 
> > Geert
> > 
> > (1) We need to keep those
> > 1. to be able to migrate the user' settings (a one-time event)
> > 2. allow the user to downgrade without loosing preferences
> > The old schema is targeted for full removal only in gnucash 6.
> > 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Trouble with gsettings in GC 4.9

[Geert Janssens]

This is misleading.

Even the newer gnucash still installs schemas for org.gnucash. next 
to 
org.gnucash.GnuCash.
In recent versions these are defined in 
org.gnucash.GnuCash.deprecated.gschema.xml (1)


So it's absolutely normal both will still show up in dconf.

However if there are *two* sets of gschema.xml files that define the same 
org.gnucash. schema, the glib schema compiler will bail out as soon 
as it 
detects the first duplicate schema. As a result it won't reach the schema files 
starting with 
org.gnucash.GnuCash and hence it won't compile the newer schema.

I have now looked at your dconf.backup file. It shows both 
org.gnucash. and 
org.gnucash.GnuCash. entries. That's correct and should be so since 
gnucash 
4.7. That's when I added the new schema.

I also went back to your very first message. In there you write:
>  If I run:
>  glib-compile-schemas --strict /usr/local/share/glib-2.0/schemas/
>  /usr/local/share/glib-
>  2.0/schemas/org.gnucash.dialogs.business.gschema.xml:3:1  Fehler in
>  Zeile 3, Zeichen 1:  wurde
>  bereits angegeben.  --strict was specified; exiting.

This really points as /usr/local/share/glib-2.0/schemas as the cause. It holds 
gschema.xml 
files from before gnucash 4.7 (the ones named 
org.gnucash.

As we have been talking about this in all directions it's not clear to me 
whether these are still 
there. If so, can you remove those and rerun
ninja install ?

Or instead of ninja install you can also do as John suggests in directly rerun 
glib-compile-
schemas. For that to work the org.gnucash.GnuCash. schema files 
should be 
left in that directory though.

Regards,

Geert

(1) We need to keep those 
1. to be able to migrate the user' settings (a one-time event)
2. allow the user to downgrade without loosing preferences
The old schema is targeted for full removal only in gnucash 6.


Op donderdag 30 december 2021 22:22:11 CET schreef John Ralls:
> Yesterday you attached a dump from dconf that shows both org.gnucash.GnuCash
> and org.gnucash schema entries. If you're absolutely sure that you've
> gotten rid of all instances of org.gnucash.foo.schema.xml from everywhere
> outside of your gnucash-4.7 build directory and you've removed the
> gschemas.compiled files from those places then another possibility is that
> your version of dconf keeps a cache. See if $HOME/.caches/dconf exists and
> if it does, delete it.
> 
> In that same letter you said your build procedure is
> 
> > cd gnucash-4.9/build
> > cmake -G"Ninja" -D CMAKE_INSTALL_PREFIX=/usr/local -D WITH_PYTHON=ON
> > ../source sudo ninja install
> 
> Please modify that to
> cd gnucash-4.9/build
> rm -rf * && cmake -G"Ninja" -D CMAKE_INSTALL_PREFIX=/usr/local -D
> WITH_PYTHON=ON ../source ninja
> sudo ninja install
> 
> If that fails please paste the whole output either to an attachment or to
> some upload site like Github's GIST and tell us the URL to it.
> 
> Regards,
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Trouble with gsettings in GC 4.9

[Geert Janssens]

Christian,

Have you also searched for org.gnucash.*.gschema.xml ?
These files are important during the installation process. If these were 
present (the files that 
don't have GnuCash in camelcase in their name) the installation will not work 
properly.
But the actual problem file in that case will be called gschemas.compiled. 
That's the file used 
by gsettings (not dconf) to know which preference keys should exist.

I am slightly puzzled though because the migration of settings actually already 
happened in 
gnucash 4.7.

Regards,

Geert

Op donderdag 30 december 2021 16:42:44 CET schreef Christian Wehling:
> So, I first uninstalled everything and restarted the computer.
> Now "sudo find / -name libgnc*.so" only finds these directories:
>  /var/lib/flatpak/app/org.gnucash.GnuCash/ => not in use
>  ~/github/gnucash/build/lib/ => for development
>  ~/Programme/gnucash-4.7/build/lib/ => productiv
>  ~/Programme/gnucash-4.9/build/lib/
> In my opinion, this is not critical.
> 
> /usr/lib and /usr/local/lib do not contain libgnc*.so.
> 
> /etc/ld.so.conf.d contains this:
>  fakeroot-x86_64-linux-gnu.conf
>  i386-linux-gnu.conf
>  libc.conf => /usr/local/lib
>  x86_64-linux-gnu.conf
>  zz_i386-biarch-compat.conf
> and these directories do not contain libgnc*.so either.
> 
> The LD_LIBRARY_PATH does not contain any entries. Should I specify
> something here and, if so, what?
> 
> I fear something is broken with dconf, however I have no idea what and
> how to fix something in dconf.
> 
> I'm afraid I'll have to do a system update to get a newer GnuCash
> version working.
> 
> Regards,
> Christian
> 
> Am Mittwoch, dem 29.12.2021 um 12:53 -0800 schrieb John Ralls:
> > From yesterday's errors
> 
> * 16:29:33  INFO  [gnc_load_app_icons] Path 20:
> /opt/gnucash/share/gnucash/icons
> 
> Suggests that you might also have installed into /opt/gnucash at some
> point, so look there. You should also check /usr/lib just in case you
> installed the distro build at some point, and take a look at
> /etc/ld.so.conf and `echo $LD_PIBRARY_PATH` for other possible
> locations.
> 
> You can always do `find / -name libgnc*.so`, though that will take a
> while. If you have `locate` installed and you've generated the
> indexes `locate libgnc*.so` will be considerably faster, but since it
> has to index the hard disk it will take longer than find would if
> it's not installed and indexed already.
> 
> Regards,
> John Ralls
> 
> On Dec 29, 2021, at 12:18 PM, Christian Wehling <
> c.wehl...@posteo.de> wrote:
> 
> mhh,
> with these steps I always install a new version:
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Trouble with gsettings in GC 4.9

[Geert Janssens]

Op maandag 27 december 2021 17:57:17 CET schreef Christian Wehling:
> Hi,
> I have compiled version 4.9 (Ubuntu 20.04) from sourceforge.net and
> have trouble with the "glib-schemas".
> The installation seemed to run without errors, but when I start Gnucash
> I get these outputs:
> [...]
> * 16:48:51  INFO  [gnc_load_app_icons] Path 14:
> /usr/local/share/gnucash/icons
> * 16:48:51  INFO  [gnc_load_app_icons] Path 15:
> /usr/local/share/icons
> * 16:48:51 ERROR  g_settings_new_full: assertion
> 'schema != NULL' failed
> * 16:48:51  WARN 
> [gnc_gsettings_get_settings_ptr()] Ignoring attempt to access unknown
> gsettings schema org.gnucash.GnuCash.general
> * 16:48:51 ERROR  GVariant*
> gnc_gsettings_get_user_value(const gchar*, const gchar*): assertion
> 'G_IS_SETTINGS (settings_ptr)' failed
> [... and so on]
> 
> If I run:
> glib-compile-schemas --strict /usr/local/share/glib-2.0/schemas/
> /usr/local/share/glib-
> 2.0/schemas/org.gnucash.dialogs.business.gschema.xml:3:1  Fehler in
> Zeile 3, Zeichen 1:  wurde
> bereits angegeben.  --strict was specified; exiting.
> 
> 
> I had installed version 4.7 in the same way and it worked fine.

In 4.9 there should not longer be a file 
/usr/local/share/glib-2.0/schemas/org.gnucash.dialogs.business.gschema.xml

If it's there, that's the reason for the installation failure and subsequent 
run time error.

In fact there shouldn't be any gschema.xml file in there that starts with 
org.gnucash. where  is anything but GnuCash. So you 
should only 
find files that start with org.gnucash.GnuCash or not with org.gnucash at all 
(you can have 
gschema.xml files from other applications you build manually).

Please remove all the org.gnucash..gschema.xml files from that directory 
before 
installing 4.9.
Then check if that exact file reappears after running "sudo ninja install". If 
it does, something 
is wrong with your sources or build directory.

Regards,

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

Re: [GNC-dev] Spam bug

[Geert Janssens]

Hi Chris,

That's probably due to my own attempt to mark this bug as spam. In the process 
I made it 
only visible to users in the GnuCash Development Team, thinking that would 
prevent search 
bots from still finding it.

As I don't know which steps to actually take, I only did these:

- Change title to Spam,
- remove url
- mark resolved/invalid

What else should typically be done still ?

Regards,

Geert

Op woensdag 15 december 2021 14:57:01 CET schreef Chris Good:
> Hi,
> 
> Bug 798389 is spam but I cannot mark it as spam as when I try to open it I
> get:
> 
> You are not authorized to access bug #798389
> 
> I was able to mark as spam several other bugs this morning.
> I have marked the user as a spammer.
> 
> Regards,
> Chris Good
> ___
> 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] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Geert Janssens]

Hi John,

Op maandag 6 december 2021 20:26:39 CET schreef john:
> Geert,
> 
> This is hilarious. In that post Mr. Braam says that he maintains his
> Megapixels project on SourceHut. Follow the link. Right at the top it says
> "The development and maintainership of Megapixels has been moved to
> gitlab.com/postmarketos/megapixels
> "! That aside, the workflow
> promoted there depends on hosting at SourceHut; it's (not Free or even open
> source AFAICT) software is what provides the patch tracker.
> 
Hilarious indeed. Again I didn't follow through very deeply and missed plenty 
of these 
inconsistencies.



> 
> I'm a little puzzled by your complaint about git am saving you context
> switches. Have you tried `git pull --no-ff https://github.com/user/gnucash/
>  pr-branch`? You can copy and paste the
> line (minus the --no-ff) directly from the Github Conversation tab after
> clicking the "command line instructions" link (don't follow the
> instructions, most of the steps are unnecessary). If you prefer to do that
> in a local branch then be sure to change the merge commit message to say
> "into maint" so that you can ff-merge the local branch into maint.
> 
Even after years of using it, clearly I missed that hint. So yes that point is 
equally moot in 
my discourse.

> While searching for software to track mailing list patch submissions I found
> this: https://lwn.net/Articles/860607/ ,
> "Pulling GitHub into the kernel process". It's an interesting discussion of
> lots of alternatives that the kernel teams are considering.
> https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html
>  is
> another interesting post that mentions
> https://github.com/getpatchwork/patchwork
>  for tracking patch status from
> a mailing list. I found only one other, https://github.com/lu-zero/plaid
> , which says it's a patchwork derivative.

I'll read this discussion later. Thanks for the pointers.

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

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Geert Janssens]

Well, it wasn't just Kevin's patch submission by mail that triggered my 
reaction.

I recently also read this blog post
https://blog.brixit.nl/git-email-flow-versus-github-flow/[1]

Though as it didn't really apply to gnucash directly I only read it 
superficially back then. 
Rereading it more closely I gather the git mail process can be made more 
attractive by 
adding a web-based tool that displays mailing list messages in a way optimized 
for typical git 
mail conversations.
I'll also note the author apparently is allergic to merge commits which we are 
not so his 
heavy focus on that argument is a little weak.

I'm not really interested in promoting such an approach. It did trigger an 
academic curiosity 
towards it though as it seems to have it's own distinct advantages and 
drawbacks.

I'll elaborate on what I perceive just for the sake of provoking thoughts.

For example, the author refers to github's merge facility (which is in his 
opinion subpar as it 
generates merge commits). We can't actually use that as we have declared our 
repos on 
code to be the master repos. Yet as I'm usually working on the command line to 
steer git, 
using git am to apply mail patches would save me a number of context switches.
>From a user point of view that same command line efficiency is possible with 
>git mail. In 
addition not everyone wants to have an account on github for various reasons, 
but I 
presume those same people are willing to send mails directly to the project.

Specifically to your first objection (large complex patches needing much 
discussion). I didn't 
suggest to make it the only or even the primary channel to submit patches. We 
could still 
request a formal PR on github if the patch becomes too complex or rely on the 
suggested 
web-based tool to make that process easier for us.

Clearly there are also downsides. Firstly there is the maintenance of yet 
another website. 
Additionally much of the benefit of direct mail workflow is gone if you still 
have to visit a 
website to be able to follow the review conversation...

And with that I'll step down from my soapbox :)
I do not plan to pursue this further myself as I don't think there's enough net 
benefit for 
gnucash.

Regards,

Geert

Op zondag 5 december 2021 23:17:41 CET schreef John Ralls:
> Geert,
> 
> Reviewing and commenting a big patch with several commits touching several
> files and keeping track of what's been changed between versions via an
> email conversation isn't attractive to me, nor is trying to keep track of
> which change-sets have been applied, rejected, or are waiting for
> revisions.
> 
> Yeah, the linux kernel uses mailing lists and a huge posse of designated
> maintainers for handling patches. There doesn't seem to be any documented
> system for keeping track of the patches, just an exhortation to submitters
> to rebase and resubmit frequently during the limited "merge windows" at the
> beginning of each development cycle. It sure seems to me--and likely to
> most everyone else in the FLOSS community--that learning to use GitHub or
> GitLab as a prerequisite for patch submission is the less painful route.
> 
> Regards,
> John Ralls
> 
> > On Dec 5, 2021, at 1:07 PM, Geert Janssens 
> > wrote:
> > 
> > I actually wonder whether we should reconsider our strategy.
> > 
> > We're pretty used to the convenience of github pull requests. But patches
> > by mail are actually the main method offered by git itself. So forcing
> > potential contributors to go manipulate a website in order to get a patch
> > sent is is counterproductive to people accustomed to the git mail
> > process.
> > 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Geert Janssens]

I actually wonder whether we should reconsider our strategy.

We're pretty used to the convenience of github pull requests. But patches by 
mail are 
actually the main method offered by git itself. So forcing potential 
contributors to go 
manipulate a website in order to get a patch sent is is counterproductive to 
people 
accustomed to the git mail process.

I agree this mailing list may not be the proper destination for such mails but 
nothing stops 
us from also setting up a mailing list specifically to accept patches. It can't 
be gnucash-
patches as we already use that for other purposes. But we can come up with 
another one.

Note that also for us maintainers applying patches received by mail is not 
cumbersome at 
all. Git has commands built in for that. The cumbersome part may come from 
getting the 
mail out of your mail client into a directory structure where it can be read by 
git. If your mail 
client is maildir based, that very mail directory is already in the right 
format to start with. 
Otherwise it may require some save action on behalf of the maintainer. That's 
not more 
difficult than what we currently do with bugzilla patches (which I'd rather 
drop in favour of 
mail based patches as the latter has git integration and the former hasn't).

I'm interested what others think of this.

Regards,

Geert

Op zondag 5 december 2021 15:34:45 CET schreef Derek Atkins:
> Hi,
> 
> On Sun, December 5, 2021 8:55 am, D. via gnucash-devel wrote:
> > Kevin,
> > 
> > The preferred way to submit changes is through git PRs, not with patch
> > files attached to emails to the lists. You'll get better results using
> > that method.
> 
> I would add that there are two preferred methods:
> 
> 1) Github PR
> 2) Patch attached to a bugzilla report.
> 
> Patches sent in email are likely to get lost or forgotten.  Sending them
> via bugzilla and github are less prone to loss.
> 
> Also, for the record, the patch did NOT make it through the mailing list's
> "purge HTML" process and into my inbox -- so it is already lost!
> 
> > David T.
> 
> -derek


___
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

[Geert Janssens]

Op woensdag 24 november 2021 23:15:47 CET schreef flywire:
> Probably clearer to demonstrate same default functionality with different
> user interface:
> * Default is Off with On to Omit - double negative ??
> * Alternative default is On with Off to Omit - consistent and logical on a
> *Display* tab ??
> 
> [image: OmitVsDisplay.png]


I completely agree preferring positive language and particularly avoiding 
double negation 
logic is better design. This change can be implemented relatively easily as 
well.

The catch is that making this change would invert the meaning of the underlying 
option and 
hence without additional support code saved reports would suddenly behave the 
other way 
around. We don't have code that would help us convert report options based on 
semantic 
changes unfortunately. Someone would have to write it to provide a seamless 
transition 
from old to new semantics. And that then pulls in the complexity of backward 
compatibility.

Regards,

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

Re: [GNC-dev] gnucash maint: Multiple changes pushed

[Geert Janssens]

Oops, this push inadvertently added unfinished work on GSettings. I have 
reverted it for now.

Regards,

Geert

Op zaterdag 16 oktober 2021 10:49:14 CEST schreef Geert Janssens:
> Updatedvia  https://github.com/Gnucash/gnucash/commit/d4e4062c 
> (commit)
>via  https://github.com/Gnucash/gnucash/commit/24fa2899 (commit)
>via  https://github.com/Gnucash/gnucash/commit/26b2d7ca (commit)
>via  https://github.com/Gnucash/gnucash/commit/c6103a5c (commit)
>   from  https://github.com/Gnucash/gnucash/commit/16184daf (commit)
> 
> 
> 
> commit d4e4062c9310f50729c94b73e9f2bd80382fabfb
> Author: Geert Janssens 
> Date:   Sat Oct 16 10:48:55 2021 +0200
> 
> Remove redundant function declaration
> 
> gnc_load_scm_configuration is declared and defined in gnucash-core-app.
> 
> commit 24fa289952257cb8a2f2b9d59024be59d05888e3
> Author: Geert Janssens 
> Date:   Wed Oct 6 18:53:36 2021 +0200
> 
> GSettings - rework internal helper functions to use more C++
> 
> commit 26b2d7ca7878776a7c6777cd30e1b19185b72983
> Author: Geert Janssens 
> Date:   Wed Oct 6 17:11:00 2021 +0200
> 
> GSettings - make most of the api private
> 
> All preference calls should happen via the gnc_prefs_... apis.
> The gnc_gsettings_... apis are an internal implementation of this.
> 
> commit c6103a5c171f459b6ca070c61bcde939885ae613
> Author: Geert Janssens 
> Date:   Wed Oct 6 16:50:57 2021 +0200
> 
> Add structure to map migrated preferences to old ones
> 
> This can be used to keep both in sync in the period between
> initial migration and eventual obsolence.
> Note only non-obsoleted, migrated preferences are tracked.
> We don't want to resync preferences that have been
> obsoleted (reset). That would nullify the whole idea
> of making them obsolete for future removal.
> 
> This commit only adds the mapping, synching will follow in a future
> commit.
> 
> 
> 
> Summary of changes:
>  gnucash/gnucash-commands.hpp   |   4 -
>  libgnucash/app-utils/gnc-gsettings.cpp | 277 +++--
>  libgnucash/app-utils/gnc-gsettings.h   | 550
> - libgnucash/app-utils/gnc-prefs-utils.c | 
>  1 +
>  4 files changed, 189 insertions(+), 643 deletions(-)
> 
> ___
> gnucash-patches mailing list
> gnucash-patc...@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-patches




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

Re: [GNC-dev] warning: 'gtk_action_set_sensitive' is deprecated [-Wdeprecated-declarations] And gtk4

[Geert Janssens]

Op woensdag 6 oktober 2021 18:02:13 CEST schreef john:
> > On Oct 5, 2021, at 9:54 PM, Chris Good  wrote:
> > 
> > Hi John Ralls,
> > 
> > 
> > 
> > I'm following up on the your suggestion that it should not be possible to
> > start another import while another is already running.
> > 
> > 
> > 
> > When I added gtk_action_set_sensitive() the compiler says:
> > 
> > /home/cgood/gnucash-maint/src/gnucash/import-export/ofx/gnc-plugin-ofx.c:1
> > 21> 
> > :5: warning: 'gtk_action_set_sensitive' is
> > 
> > deprecated [-Wdeprecated-declarations]
> > 
> > 
> > 
> > but I see in maint, that function is used in many places but with
> > 
> > -Wno-deprecated-declarations
> > 
> > in the CMakeLists.txts to ignore this warning.
> > 
> > https://docs.gtk.org/gtk3/class.Action.html :
> > In GTK+ 3.10, GtkAction has been deprecated. Use GAction
> > 
> > instead, and associate actions with GtkActionable widgets.
> > 
> >  Use GMenuModel for creating menus with
> > 
> > gtk_menu_new_from_model().
> > 
> > 
> > 
> > There are NO mentions of GMenuModel in current maint or master.
> > 
> > 
> > 
> > Should I just continue with gtk_action_set_sensitive and add
> > -Wno-deprecated-declarations to CMakeLists.txt?
> > 
> > 
> > 
> > Is there a plan to migrate to GAction? Is that going to be a huge task?
> > 
> > 
> > 
> > I haven't seen any discussion about going to gtk4. Is that not a huge task
> > like gtk2 to gtk3?
> 
> Nobody's told me of undertaking the effort to rework the GUI for Gtk4, and I
> think Geert is somewhat opposed to it because we want to consider
> converting to another graphics framework at some point.

I'm not really opposed though I *am* indeed also interested in shopping for 
other frameworks. I think switching to Gtk4 may be less work that fully 
replacing with another framework and hence may be a more achievable goal.

GtkActions have been deprecated for a while and it may also be a useful effort 
to convert those to GActions. IIRC we looked at this quite a while ago and it 
turned out to be not that simple as it required changes from GtkMenus to 
GMenus and that hooks into GApplication which we also don't use. (All from 
memory so this may not be fully accurate)


> There's no need to
> rush, Gtk3 will continue in maintenance mode for several more years.
> Consider that The GIMP (which is the "G" in Gtk) is still working on their
> Gtk3 conversion.
> 
That I agree to as well. The only thing tempting me to Gtk4 is it's rumored to 
have a much more performant replacement for GtkTreeView which may allow us to 
do a better register (as in more Gtk conforming and standard widget based) 
than we have now. I haven't investigated this at all, it just something I 
gathered  from cursory reading news around Gtk4.

> IMO it would be far more useful to work on MVC separation in the GUI
> directories than on modernizing GtkActionGroup and GtkMenu usage.
> 
MVC separation is definitely also very much needed and might even be a 
prerequisite to do the GAction/GMenu/GApplicatation work.

Regards,

Geert


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

Re: [GNC-dev] GnuCash 4.7 Released

[Geert Janssens]

What I thought to be the problem yesterday turned out to only be an indirect 
indication of the problem. I now blame a subtle change in the build order to 
be the actual source of the issue.

I have applied a fix to maint, which seems to work well in all my tests (both 
building with ninja or make). It would be helpful if others can build our 
current maint branch report their results here as well.

Regards,

Geert

Op dinsdag 28 september 2021 05:04:55 CEST schreef john:
> David,
> 
> The problem is that schemes.compiled doesn't have the new
> org.gnucash.GnuCash paths. Or rather didn't, because running
> glib-compile-schemas again should have added that and you should now be
> able to run GnuCash. Can you check that?
> 
> Geert and I were working with another user on IRC this afternoon (well, my
> afternoon). That user used make and I just tested and found that make
> produced the result you get while ninja produced the result I get. But you
> say you're using ninja so so much for that hypothesis.
> 
> Regards,
> John Ralls
> 
> > On Sep 27, 2021, at 6:39 PM, davidcousen...@gmail.com wrote:
> > 
> > Hi John,
> > 
> > $strings /usr/local/share/glib-2.0/schemas/gschemas.compiled | grep
> > dialogs.import.hbci
> > (b)org.gnucash.dialogs.import.hbci
> > /org/gnucash/dialogs/import/hbci/
> > org.gnucash.dialogs.import.hbci.connection-dialog
> > org.gnucash.dialogs.import.hbci.connection-dialog
> > /org/gnucash/dialogs/import/hbci/connection-dialog/
> > 
> > 
> > $ sudo glib-compile-schemas --strict /usr/local/share/glib-2.0/schemas/
> > returns no erors
> > 
> > The build directory was cleaned with rm -rf before rebuilding and then a
> > rerun of the cmake, ninja and sudo ninja install.
> > 
> > Cheers
> > 
> > David
> > 
> > On Mon, 2021-09-27 at 18:05 -0700, John Ralls wrote:
> >> David,
> >> 
> >> Does
> >> 
> >>  strings /usr/local/share/glib-2.0/schemas/gschemas.compiled | grep
> >> 
> >> dialogs.import.hbci
> >> return
> >> 
> >>  (i)org.gnucash.dialogs.import.hbci
> >>  /org/gnucash/dialogs/import/hbci/
> >>  org.gnucash.GnuCash.dialogs.import.hbci.connection-dialog
> >>  org.gnucash.GnuCash.dialogs.import.hbci.connection-dialog
> >>  /org/gnucash/GnuCash/dialogs/import/hbci/connection-dialog/
> >>  org.gnucash.dialogs.import.hbci.connection-dialog
> >>  /org/gnucash/dialogs/import/hbci/connection-dialog/
> >>  org.gnucash.GnuCash.dialogs.import.hbci
> >>  /org/gnucash/GnuCash/dialogs/import/hbci/
> >>  org.gnucash.GnuCash.dialogs.import.hbci.connection-dialog
> >> 
> >> If you run
> >> 
> >>  glib-compile-schemas --strict /usr/local/share/glib-2.0/schemas/
> >> 
> >> do you get an error?
> >> 
> >> By "cleaned the build directory" do you mean "rm -rf *" or "ninja clean"?
> >> 
> >> Regards,
> >> John Ralls
> >> 
> >>> On Sep 27, 2021, at 2:25 PM, David Cousens 
> >>> wrote:
> >>> 
> >>> Hi Geert,
> >>> I hadn't tried to run gnucash from the build directory, only the
> >>> installed
> >>> directories under /usr/local.
> >>> Applied the patch, uninstalled the previous install, cleaned the build
> >>> directory and rebuilt 4.7. Again no problems with cmake or ninja or the
> >>> install itself but the same problem when running gnucash. I've attached
> >>> the
> >>> trace file and the patched gschema file.
> >>> $ gnucash --debug
> >>> Trace/breakpoint trap (core dumped)
> >>> 
> >>> On Mon, 27 Sept 2021 at 17:21, Geert Janssens
> >>> 
> >>> 
> >>> wrote:
> >>>> Hi David,
> >>>> 
> >>>> This is definitely a crasher bug that unfortunately managed to slip
> >>>> passed
> >>>> our
> >>>> testing. I am surprised the warning only happens when installing
> >>>> gnucash,
> >>>> not
> >>>> while building it. Likewise you can run GnuCash just fine from the
> >>>> build
> >>>> directory but not from the install path.
> >>>> 
> >>>> I'll push a fix but unfortunately this probably means we need to do a
> >>>> hotfix
> >>>> release (4.7.1). I'll let John decide.
> >>>> 
> >>>> I have attached a patch. Can you try to apply this to your tarball and
> 

Re: [GNC-dev] GnuCash 4.7 Released

[Geert Janssens]

Yeah, unfortunately this affects most of the aqbanking related settings.

If you can, apply the patch I added to a previous reply and rebuild.

Regards,

Geert

Op maandag 27 september 2021 10:08:29 CEST schreef Christian Wehling:
> Hi,
> I have a similar problem but with the "Flicker" dialogue.
> 
> The installation runs without errors, but the programme start aborts with
> the message [...] * 13:13:26  INFO 
> [gnc_load_app_icons] Path 21:
> /home/chris/github/gnucash/install/share/icons * 13:13:26 OTHER  > Settings schema 'org.gnucash.GnuCash.dialogs.flicker' is not
> installed Trace/Breakpoint ausgelöst (Speicherabzug geschrieben)
> 
> Grüße
> Christian
> 
> 
> Am Montag, dem 27.09.2021 um 11:27 +1000 schrieb
> 
> davidcousen...@gmail.com:
> > Hi John
> > 
> > Encountered a runtime problem with GC 4.7 on Linux MInt 20.2 built
> > from the
> > downloaded tarball. There were no obvious problems with the cmake and
> > ninja runs
> > and only the following warning running sudo ninja install ( to
> > /usr/local).
> > 
> > Compiling gschema files in /usr/local/share/glib-2.0/schemas
> > Warning: undefined reference to  > id='org.gnucash.GnuCash.dialogs.import.hbci.connection-dialog'/>
> > 
> > the program bombs out when I try to run it with the following in the
> > gnucash.trace file:
> > 
> > * 10:53:31 OTHER  Settings schema
> > 'org.gnucash.GnuCash.dialogs.import.ofx' is not installed
> > 
> > I reran GC with gnucash --debug and have attached the full trace file
> > 
> > All of the terminal outputis in the attached files in case I missed
> > the obvious.
> > 
> > David
> > 
> > On Sun, 2021-09-26 at 12:35 -0700, John Ralls wrote:
> > > The GnuCash development team announces GnuCash 4.7, the eighth
> > > release in the
> > > stable 4.x series
> > > Compatibility Notice
> > > 
> > > In order to allow flatpak users to share preferences with
> > > installations
> > > outside of the sandbox we need to change the preference path from
> > > /org/gnucash
> > > to /org/gnucash/GnuCash. This release of GnuCash does that and it
> > > will
> > > automatically migrate existing preferences. It does not, however,
> > > continue to
> > > write preferences to the old path and it runs the migration only
> > > once. If you
> > > go back and forth between GnuCash 4.7 and an older versions you'll
> > > have two
> > > sets of preferences, one for GnuCash 4.7 and later and another for
> > > GnuCash 4.6
> > > and earlier. This includes the file history list and last-opened
> > > file.
> > > 
> > > Between 4.6 and 4.7, the following bugfixes were accomplished:
> > > Bug 87847 - RFE: Create a 'checkbox' cell type
> > > Bug 766052 - Job report payments wrong when payment contains
> > > 
> > > splits
> > > 
> > > Bug 797596 - New-owner - improved representation of payments
> > > 
> > > with multiple
> > > non-APAR splits
> > > 
> > > Bug 798142 - Tax rate appears as a fraction
> > > Bug 798180 - Update to macOS Big Sur 11.3 breaks Finance Quote
> > > Bug 798205 - Some transactions dropped with no apparent cause
> > > 
> > > or warnings
> > > for credit card ofx import
> > > 
> > > Do not exclude from import a transaction that has an FITID
> > > 
> > > which matches
> > > an already existing split. This is because it (1) may be a
> > > coincidence and
> > > therefore the transaction needs to be added or (2) could be on a
> > > transfer from
> > > the account being imported to another bank account which has
> > > already been
> > > imported, and so needs to be matched, not added.
> > > 
> > > Bug 798208 - management fee transactions are ignored on OFX
> > > 
> > > import
> > > 
> > > Bug 798211 - Equity statement double calculates unrealized gain
> > > Bug 798219 - apply/OK truncates exchange rates from 4 to 2
> > > 
> > > decimal places;
> > > enter doesn't
> > > 
> > > Bug 798221 - Transfer funds between accounts with different
> > > 
> > > currencies
> > > crashes Gnucash on macOS
> > > 
> > > Bug 798224 - Scheduled transactions are created with date-
> > > 
> > > entered copied
> > > from the template transaction.
> > > 
> > > Bug 798229 - GncDate::c_formats is being created and destroyed
> > > 
> > > twice
> > > resulting in a double free crash on every exit.
> > > 
> > > Bug 798234 - Cut Transaction discards the reference to the
> > > 
> > > description/memo strings so that Paste Transaction will paste
> > > uninitialised
> > > data (or other strings)
> > > 
> > > Bug 798235 - Reconciliation Ending Balance not recalculated the
> > > 
> > > 2nd and
> > > subsequent times Statement Date is updated.
> > > 
> > > Bug 798237 - Logging during XML file loading degrades
> > > 
> > > performance
> > > significantly
> > > 
> > > Bug 798238 - "New security" dialog doesn't save the "Display
> > > 
> > > symbol"
> > > 
> > > Bug 798250 - Gnucash permanent hang on save while loading
> > > 
> > > report
> > > 
> > > Bug 798256 - Crash in recnFinishCB
> > > 

Re: [GNC-dev] GnuCash 4.7 Released

[Geert Janssens]

Hi David,

This is definitely a crasher bug that unfortunately managed to slip passed our 
testing. I am surprised the warning only happens when installing gnucash, not 
while building it. Likewise you can run GnuCash just fine from the build 
directory but not from the install path.

I'll push a fix but unfortunately this probably means we need to do a hotfix 
release (4.7.1). I'll let John decide.

I have attached a patch. Can you try to apply this to your tarball and see if 
t hat fixes the problem ? It does for me.

Regards,

Geert

Op maandag 27 september 2021 03:27:02 CEST schreef davidcousen...@gmail.com:
> Hi John
> 
> Encountered a runtime problem with GC 4.7 on Linux MInt 20.2 built from the
> downloaded tarball. There were no obvious problems with the cmake and ninja
> runs and only the following warning running sudo ninja install ( to
> /usr/local).
> 
> Compiling gschema files in /usr/local/share/glib-2.0/schemas
> Warning: undefined reference to  id='org.gnucash.GnuCash.dialogs.import.hbci.connection-dialog'/>
> 
> the program bombs out when I try to run it with the following in the
> gnucash.trace file:
> 
> * 10:53:31 OTHER  Settings schema
> 'org.gnucash.GnuCash.dialogs.import.ofx' is not installed
> 
> I reran GC with gnucash --debug and have attached the full trace file
> 
> All of the terminal outputis in the attached files in case I missed the
> obvious.
> 
> David
> 
> On Sun, 2021-09-26 at 12:35 -0700, John Ralls wrote:
> > The GnuCash development team announces GnuCash 4.7, the eighth release in
> > the stable 4.x series
> > Compatibility Notice
> > 
> > In order to allow flatpak users to share preferences with installations
> > outside of the sandbox we need to change the preference path from
> > /org/gnucash to /org/gnucash/GnuCash. This release of GnuCash does that
> > and it will automatically migrate existing preferences. It does not,
> > however, continue to write preferences to the old path and it runs the
> > migration only once. If you go back and forth between GnuCash 4.7 and an
> > older versions you'll have two sets of preferences, one for GnuCash 4.7
> > and later and another for GnuCash 4.6 and earlier. This includes the file
> > history list and last-opened file.> 
> > Between 4.6 and 4.7, the following bugfixes were accomplished:
> > Bug 87847 - RFE: Create a 'checkbox' cell type
> > Bug 766052 - Job report payments wrong when payment contains splits
> > Bug 797596 - New-owner - improved representation of payments with
> > multiple
> > 
> > non-APAR splits
> > 
> > Bug 798142 - Tax rate appears as a fraction
> > Bug 798180 - Update to macOS Big Sur 11.3 breaks Finance Quote
> > Bug 798205 - Some transactions dropped with no apparent cause or
> > warnings
> > 
> > for credit card ofx import
> > 
> > Do not exclude from import a transaction that has an FITID which
> > matches
> > 
> > an already existing split. This is because it (1) may be a coincidence and
> > therefore the transaction needs to be added or (2) could be on a transfer
> > from the account being imported to another bank account which has already
> > been imported, and so needs to be matched, not added.
> > 
> > Bug 798208 - management fee transactions are ignored on OFX import
> > Bug 798211 - Equity statement double calculates unrealized gain
> > Bug 798219 - apply/OK truncates exchange rates from 4 to 2 decimal
> > places;
> > 
> > enter doesn't
> > 
> > Bug 798221 - Transfer funds between accounts with different currencies
> > 
> > crashes Gnucash on macOS
> > 
> > Bug 798224 - Scheduled transactions are created with date-entered
> > copied
> > 
> > from the template transaction.
> > 
> > Bug 798229 - GncDate::c_formats is being created and destroyed twice
> > 
> > resulting in a double free crash on every exit.
> > 
> > Bug 798234 - Cut Transaction discards the reference to the
> > 
> > description/memo strings so that Paste Transaction will paste
> > uninitialised
> > data (or other strings)
> > 
> > Bug 798235 - Reconciliation Ending Balance not recalculated the 2nd
> > and
> > 
> > subsequent times Statement Date is updated.
> > 
> > Bug 798237 - Logging during XML file loading degrades performance
> > 
> > significantly
> > 
> > Bug 798238 - "New security" dialog doesn't save the "Display symbol"
> > Bug 798250 - Gnucash permanent hang on save while loading report
> > Bug 798256 - Crash in recnFinishCB
> > Bug 798298 - Re-imported transactions no longer ignored
> > Bug 798303 - account list is sorted wrong by amount
> > Bug 798312 - Opening the help for dialogues in the wrong language.
> > 
> > The following fixes and improvements were not associated with bug reports:
> > Lots of memory-leaks plugged
> > Change the preferences path to org.gnucash.GnuCash to comply with
> > flatpak
> > 
> > requirements and migrate existing preferences to the new paths. This won't
> > 

Re: [GNC-dev] KVP's

[Geert Janssens]

Upon re-reading in more detail I find it is exactly your idea to make it 
depend on the account-id. I am not sure how this interacts with the csv 
importer. So perhaps all of my reservations are moot.

Regards,

Geert

Op zaterdag 11 september 2021 10:44:18 CEST schreef Geert Janssens:
> Hi Chris,
> 
> I haven't followed the original issue discussion in detail so I can only add
> some generic considerations.
> 
> The generic import transaction matcher is used by both the OFX and the csv
> importer (and perhaps even by the aqbanking one as well). So your option
> would affect all of these.
> 
> Saving this value just like that would mean it will define behaviour of all
> two or three importers at once. Imagine a user imports in three different
> formats depending on the bank to import from, would it then be desirable to
> have this option set for all different banks ? Or would it be more desirable
> to have it apply only to specific bank accounts ? The latter could even be
> the case if a user imports ofx data from two different banks. Perhaps only
> for one bank you'd want this override and not for the other ?
> 
> In other words my concern is that making it a single book level option may
> be too generic and while it would reduce effort in the use case you have in
> mind it may increase effort in other scenarios.
> 
> Regards,
> 
> Geert
> 
> Op zaterdag 11 september 2021 10:22:07 CEST schreef Chris Good:
> > Hi,
> > 
> > 
> > 
> > I'm working on adding an "Append" checkbox to the bottom of the "Generic
> > import transaction matcher" so that when Update+Clear'ing
> > 
> > a matched transaction, the imported Trans->Desc and Trans->Notes can be
> > optionally appended to the matched transaction Desc/Notes
> > 
> > instead of overriding them.
> > 
> > 
> > 
> > I'd like to store the value of the checkbox (True or False) for the
> > imported account so that in the next import, it will default to the same
> > value.
> > 
> > 
> > 
> > I'm thinking this should be a KVP, either:
> > 
> > 1.  A New slot under the account or
> > 2.  Add a pipe symbol and the True or False value to the end of the
> > account "online_id" slot
> > 
> > 
> > 
> > I assume a new slot would be backwards compatible with older versions of
> > GnuCash as they would just be ignored.
> > 
> > 
> > 
> > Is a new slot the way to go? Any hints on how to do this please?
> > 
> > 
> > 
> > Regards,
> > 
> > Chris Good
> > 
> > 
> > 
> > ___
> > 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] KVP's

[Geert Janssens]

Hi Chris,

I haven't followed the original issue discussion in detail so I can only add 
some generic considerations.

The generic import transaction matcher is used by both the OFX and the csv 
importer (and perhaps even by the aqbanking one as well). So your option would 
affect all of these.

Saving this value just like that would mean it will define behaviour of all 
two or three importers at once. Imagine a user imports in three different 
formats depending on the bank to import from, would it then be desirable to 
have this option set for all different banks ? Or would it be more desirable 
to have it apply only to specific bank accounts ? The latter could even be the 
case if a user imports ofx data from two different banks. Perhaps only for one 
bank you'd want this override and not for the other ?

In other words my concern is that making it a single book level option may be 
too generic and while it would reduce effort in the use case you have in mind 
it may increase effort in other scenarios.

Regards,

Geert

Op zaterdag 11 september 2021 10:22:07 CEST schreef Chris Good:
> Hi,
> 
> 
> 
> I'm working on adding an "Append" checkbox to the bottom of the "Generic
> import transaction matcher" so that when Update+Clear'ing
> 
> a matched transaction, the imported Trans->Desc and Trans->Notes can be
> optionally appended to the matched transaction Desc/Notes
> 
> instead of overriding them.
> 
> 
> 
> I'd like to store the value of the checkbox (True or False) for the imported
> account so that in the next import, it will default to the same value.
> 
> 
> 
> I'm thinking this should be a KVP, either:
> 
> 1.A New slot under the account or
> 2.Add a pipe symbol and the True or False value to the end of the
> account "online_id" slot
> 
> 
> 
> I assume a new slot would be backwards compatible with older versions of
> GnuCash as they would just be ignored.
> 
> 
> 
> Is a new slot the way to go? Any hints on how to do this please?
> 
> 
> 
> Regards,
> 
> Chris Good
> 
> 
> 
> ___
> 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] How do I get the "sign" (or side) of the transaction from the account or transaction element in xml?

[Geert Janssens]

Op zondag 11 juli 2021 13:38:43 CEST schreef Arman Schwarz:
> Thanks Geert,
> 
> I'm aware of the need to think in terms of debit/credit signs, but my
> question was how I could know whether a positive value in the split element
> in the XML will increase or decrease the "balance" that the user sees in
> gnucash.
> 
> This depends on the side of the accounting equation the account is on, e.g.
> positive split values increase the balance of an asset account, but
> decrease the balance of an income account. Rather than manually maintaining
> a mapping of account types and whether the sign is positive or negative, I
> was hoping there'd be something in the XML or perhaps in those bindings you
> mentioned that would do this for me.
> 

I don't think this is stored in the xml file as the net representation in the 
gui is a combination of account type and the user preference. The former is 
hard-coded, the latter can be changed by the user. I don't know if we can 
access either information via the python bindings. I don't use them myself.

Regards,

Geert


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

Re: [GNC-dev] How do I get the "sign" (or side) of the transaction from the account or transaction element in xml?

[Geert Janssens]

Op zondag 11 juli 2021 10:36:40 CEST schreef Arman Schwarz:
> Hi Frank, I'm not sure how this helps. Are you suggesting that I should
> change the way the GUI renders the balances? I had hoped to instead just
> find a way to programmatically know the sign of the balance from looking at
> the XML. If that makes sense.
> 
Alas, that doesn't make sense in a few ways.

Firstly transactions don't have balances in gnucash, but I guess you mean 
splits. Those have positive or negative quantities and values. Positive values 
represent debits, negative ones are credits.

Secondly, if you want to manipulate data directly (which voids your waranty by 
the way ;-), you have to think in terms of those credit and debit signs,  
because that's how the data internally is signed. The way it's represented in 
the GUI is a matter of taste and influenced by the preferences Frank already 
pointed you at.

Our tutorial and concepts guide should give you some information on how the 
accounting equation works, which is the basis for the double accounting 
gnucash is implementing. Perhaps that gives you some more insight.

Regards,

Geert

PS
I quickly looked at your code and notice you have chosen to parse the xml data 
file directly outside of gnucash. While you are certainly free to do so, do 
know that gnucash development will ignore that completely and you may end  up 
with unexpected data format changes at random releases (hence the "voided 
warranty" claim earlier on).
We also provide python bindings. Perhaps those can do what you need as well ?


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

Re: [GNC-dev] gc 4.6 compile problem

[Geert Janssens]

Op donderdag 1 juli 2021 18:18:19 CEST schreef John Ralls:
> > On Jul 1, 2021, at 4:18 AM, Lothar Paltins via gnucash-devel
> >  wrote:> 
> > Am 01.07.21 um 05:15 schrieb John Ralls:
> >> You don't need to replace the old libraries, just remove them. Then Guile
> >> won't be able to find them and will fall back to looking where it's told
> >> to, in the build directory. Kinda like that (probably apocryphal)
> >> Churchill quote about Americans always doing the right thing after
> >> they'd exhausted all of the alternatives. Make/ninja uninstall is
> >> easiest but doesn't always work if there are filename changes and the
> >> builddir or sourcedir are reused. If it fails it's usually enough to
> >> remove libgnc* from the install library folder; sometimes you also need
> >> to remove the installed *.scm and *.go files from their respective
> >> directories in libdir/guile/version/ccache and sharedir/guile.> 
> > I'm not really familiar with the build process of gnucash and with guile
> > and I don't know, if it's possible. But I think, if a shared library is
> > generated during a build process, then this version should be used
> > afterwards unconditionally. Any other version anywhere in the file system
> > is most likely outdated. And my install directory is /opt/gnucash-4.6 and
> > it's empty during a "make". /usr/lib64 isn't my install directory, a
> > "make uninstall" will not remove anything there. A library in this
> > directory is almost certainly outdated. I want to install my compiled
> > version separated from the distribution version, so I can't simply remove
> > /usr/lib64/libgnucash-guile.so. I would have to restore it later.
> You're absolutely right, it should be. Unfortunately Guile doesn't agree and
> our efforts to convince it otherwise have been unsuccessful. It's not
> possible on Linux to build GnuCash on a machine that has GnuCash installed
> by the package manager without some gymnastics. I think the simplest work
> around is to set up a VM for building GnuCash, but maybe there's another
> way.

A (docker/podman) container is slightly more lightweight than a VM. But the 
idea is the same.

Regards,

Geert


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

Re: [GNC-dev] flatpak environment.local

[Geert Janssens]

Op maandag 26 april 2021 03:48:56 CEST schreef Chris Good:
> Hi Frank,
> 
> Your strace suggestion was successful thanks.
> I am using the flathub stable GnuCash flatpak.
> 
> 1. strace showed both environmentand & environment.local should be in
> /app/etc/gnucash to be read by GnuCash sandbox. Investigation shows that
> this comes from the host file system
> /var/lib/flatpak/app/org.gnucash.GnuCash/current/active/files/etc/gnucash.
> Sandbox /app/etc is HARD linked to host
> /var/lib/flatpak/app/org.gnucash.GnuCash/current/active/files/etc
> 
> This is the expected location for a flatpak that is for ALL users, but I
> thought  I installed it just for my user. It turns out that the
> installation instructions in
> https://wiki.gnucash.org/wiki/Flatpak#Installation are wrong, at least for
> Ubuntu 20.04 flatpak 1.65. Our wiki says:
>   # Install GnuCash ...
>   ## for all users
>   sudo flatpak install flathub org.gnucash.GnuCash
>   ## or only you
>   flatpak install flathub org.gnucash.GnuCash
> 
> but the Ubuntu man page says (my words):
>   ## for all users
>   flatpak install --system flathub org.gnucash.GnuCash
>   ## or only you:
>   flatpak install --user flathub org.gnucash.GnuCash
> And, although the man page doesn't say it, --system is the default and does
> NOT need sudo, so my flatpak installed in the system location
> (/var/lib/flatpak)
> rather than the user location (~/.local/share/flatpak).
> 
> Can some-one please let me know if the GnuCash wiki is outdated, or just
> wrong, or just wrong for Ubuntu so I can update it?
> 

I believe --system has always been the default. I *thought* it was a distro 
specific 
configuration to allow users (or perhaps users with admin rights only?) to 
install system wide 
flatpaks without sudo rights. As far as I know this is also the way it works on 
Fedora and has 
for as long as I remember. So Ubuntu is certainly not the only distro to do 
this. I don't know 
about other distros.

> 2. I just created an environment.local file in
> /var/lib/flatpak/app/org.gnucash.GnuCash/current/active/files/etc/gnucash
> from outside the sandbox, and after the sandbox is started, it is able to
> access /app/etc/gnucash/environment.local.
> I suspect that may go missing after a flatpak update - Is there a better
> way?
> 
Not based on environment.local. The environment.local method was created with a 
traditional 
package installation in mind. It also works on Windows, simply because the 
Windows installer 
overwrites an existing installation. It's not working with the MacOS dmg for 
the same reason it 
doesn't work for flatpaks. Each flatpak version is installed in a separate  
directory and the 
manually added files are not copied over. This could use some rearchitecting.

Having said that, you can define a custom environment for a flatpak application 
using
flatpak override (--user|--system) --env "LANG=en_GB LANGUAGE=en_GB" \
 org.gnucash.GnuCash

This will set these environment variables for the gnucash flatpak and this will 
persist across 
updates.

> 3. Even though the GC sandbox read environment.local setting LANG=en_GB and
> LANGUAGE={LANG}, and I checked en_GB is available in my flatpak GnuCash
> shell the trace file still shows: Effective locale set to en_AU.UTF-8
> Perhaps this message is misleading? I wonder how to check what is actually
> being used?
> 
I can't tell you that offhand (and currently am not in a position to dig in the 
code...) 

Regards,

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

Re: [GNC-dev] gnucash maint: Fix typo blocking Windows build.

[Geert Janssens]

Op donderdag 25 maart 2021 15:40:50 CET schreef John Ralls:
> Updatedvia  https://github.com/Gnucash/gnucash/commit/db4417b2 
> (commit)
>   from  https://github.com/Gnucash/gnucash/commit/7c323b22 (commit)
> 
> 
> 
> commit db4417b21282d7d3bb54eda05780d7eb62455b21
> Author: John Ralls 
> Date:   Thu Mar 25 07:40:42 2021 -0700
> 
> Fix typo blocking Windows build.
> 
> diff --git a/gnucash/CMakeLists.txt b/gnucash/CMakeLists.txt
> index 13a578f3f..078d2bda8 100644
> --- a/gnucash/CMakeLists.txt
> +++ b/gnucash/CMakeLists.txt
> @@ -74,7 +74,7 @@ set(gnucash_cli_SOURCES
>  )
> 
>  if (MINGW)
> -  list(APPEND gnucash_cli_SOURCES "gnucash-locale-locale.c")
> +  list(APPEND gnucash_cli_SOURCES "gnucash-locale-windows.c")
>  elseif (MAC_INTEGRATION)
>  list(APPEND gnucash_cli_SOURCES "gnucash-locale-macos.mm")
>  endif()
> 
Doh... Thanks for fixing my copy-paste error.

Geert


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

Re: [GNC-dev] Compilation fails on current maint and master, libgnucash/core-utils/gnc-vcs-info.h

[Geert Janssens]

Can you test again with the latest maint ? On my system it now builds. (I 
haven't merged the changes in master just yet)

Regards,

Geert

Op dinsdag 23 maart 2021 16:25:22 CET schreef Geert Janssens:
> Actually you can hold off on the bug report. I think I have it fixed. I will
> push the fixes after running a final test.
> 
> Geert
> 
> Op dinsdag 23 maart 2021 16:00:44 CET schreef Geert Janssens:
> > Ok, I can reproduce. The part that didn't immediately register with me is
> > that you are generating the build system for Unix Makefiles. Most other
> > devs are using "Ninja" and the ninja build system works fine.
> > 
> > There are some subtle differences between those build systems.
> > 
> > I suggest you file this as a bug. And while we look into getting this
> > fixed, I suggest you switch the the Ninja generator by  specifying
> > "-GNinja" to cmake.
> > 
> > The replace "make" with "ninja" (or "ninja-build" on some systems) in all
> > your calls.
> > 
> > Regards,
> > 
> > Geert
> > 
> > Op dinsdag 23 maart 2021 10:57:34 CET schreef c.holterm...@gmx.de:
> > > Hello all,
> > > 
> > > I tried compilation in some scenarios:
> > > 
> > > On a fresh git clone
> > > 
> > > A) Compiling 4.4 from scratch works.
> > > 
> > > B) Compiling maint from scratch does not compile.
> > > 
> > > C) Compiling 4.4 from scratch, checking out to maint head and
> > > recompiling current maint on top of the 4.4 build works.
> > > 
> > > regards,
> > > 
> > > Christoph
> > > 
> > > Am 2021-03-21 08:55, schrieb c.holterm...@gmx.de:
> > > > No, I work from a git clone. In addition I tried to do a fresh clone
> > > > from git. This doesn't compile as well. Same error. I'm working on
> > > > debian 10.8.
> > > > 
> > > > regards,
> > > > 
> > > > Christoph
> > > > 
> > > > Am 2021-03-20 17:35, schrieb Geert Janssens:
> > > >> Did you by any chance start from a github zipfile instead of a cloned
> > > >> git
> > > >> repository ?
> > > >> 
> > > >> Regards,
> > > >> 
> > > >> Geert
> > > >> 
> > > >> Op zaterdag 20 maart 2021 16:16:23 CET schreef GMX:
> > > >>> Hello,
> > > >>> 
> > > >>> just trying to compile after some months not on the project.
> > > >>> Compilation
> > > >>> 
> > > >>> from maint and master fails for me:
> > > >>> > >> cmake ../gnucash
> > > >>> > 
> > > >>> > ...
> > > >>> > [ 0%] Built target guile-json
> > > >>> > make[2]: *** No rule to make target
> > > >>> > 'libgnucash/core-utils/gnc-vcs-info.h', needed by
> > > >>> > 'share/gnucash/gnucash.1'. Stop.
> > > >>> > make[1]: *** [CMakeFiles/Makefile2:1496:
> > > >>> > doc/CMakeFiles/gnucash-manpage.dir/all]
> > > >>> > Error 2 make: *** [Makefile:163: all] Error 2
> > > >>> 
> > > >>> don't know what to make of that. If I just recompile and existing
> > > >>> and
> > > >>> updated builddir everything works fine (checked for maint).
> > > >>> 
> > > >>> regards,
> > > >>> 
> > > >>> Christoph
> > > >>> 
> > > >>> ___
> > > >>> gnucash-devel mailing list
> > > >>> gnucash-devel@gnucash.org
> > > >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > > > 
> > > > ___
> > > > gnucash-devel mailing list
> > > > gnucash-devel@gnucash.org
> > > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > 
> > ___
> > 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] Compilation fails on current maint and master, libgnucash/core-utils/gnc-vcs-info.h

[Geert Janssens]

Actually you can hold off on the bug report. I think I have it fixed. I will 
push the fixes after running a final test.

Geert

Op dinsdag 23 maart 2021 16:00:44 CET schreef Geert Janssens:
> Ok, I can reproduce. The part that didn't immediately register with me is
> that you are generating the build system for Unix Makefiles. Most other
> devs are using "Ninja" and the ninja build system works fine.
> 
> There are some subtle differences between those build systems.
> 
> I suggest you file this as a bug. And while we look into getting this fixed,
> I suggest you switch the the Ninja generator by  specifying "-GNinja" to
> cmake.
> 
> The replace "make" with "ninja" (or "ninja-build" on some systems) in all
> your calls.
> 
> Regards,
> 
> Geert
> 
> Op dinsdag 23 maart 2021 10:57:34 CET schreef c.holterm...@gmx.de:
> > Hello all,
> > 
> > I tried compilation in some scenarios:
> > 
> > On a fresh git clone
> > 
> > A) Compiling 4.4 from scratch works.
> > 
> > B) Compiling maint from scratch does not compile.
> > 
> > C) Compiling 4.4 from scratch, checking out to maint head and
> > recompiling current maint on top of the 4.4 build works.
> > 
> > regards,
> > 
> > Christoph
> > 
> > Am 2021-03-21 08:55, schrieb c.holterm...@gmx.de:
> > > No, I work from a git clone. In addition I tried to do a fresh clone
> > > from git. This doesn't compile as well. Same error. I'm working on
> > > debian 10.8.
> > > 
> > > regards,
> > > 
> > > Christoph
> > > 
> > > Am 2021-03-20 17:35, schrieb Geert Janssens:
> > >> Did you by any chance start from a github zipfile instead of a cloned
> > >> git
> > >> repository ?
> > >> 
> > >> Regards,
> > >> 
> > >> Geert
> > >> 
> > >> Op zaterdag 20 maart 2021 16:16:23 CET schreef GMX:
> > >>> Hello,
> > >>> 
> > >>> just trying to compile after some months not on the project.
> > >>> Compilation
> > >>> 
> > >>> from maint and master fails for me:
> > >>> > >> cmake ../gnucash
> > >>> > 
> > >>> > ...
> > >>> > [ 0%] Built target guile-json
> > >>> > make[2]: *** No rule to make target
> > >>> > 'libgnucash/core-utils/gnc-vcs-info.h', needed by
> > >>> > 'share/gnucash/gnucash.1'. Stop.
> > >>> > make[1]: *** [CMakeFiles/Makefile2:1496:
> > >>> > doc/CMakeFiles/gnucash-manpage.dir/all]
> > >>> > Error 2 make: *** [Makefile:163: all] Error 2
> > >>> 
> > >>> don't know what to make of that. If I just recompile and existing and
> > >>> updated builddir everything works fine (checked for maint).
> > >>> 
> > >>> regards,
> > >>> 
> > >>> Christoph
> > >>> 
> > >>> ___
> > >>> gnucash-devel mailing list
> > >>> gnucash-devel@gnucash.org
> > >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > > 
> > > ___
> > > gnucash-devel mailing list
> > > gnucash-devel@gnucash.org
> > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> ___
> 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] Compilation fails on current maint and master, libgnucash/core-utils/gnc-vcs-info.h

[Geert Janssens]

Ok, I can reproduce. The part that didn't immediately register with me is that 
you are generating the build system for Unix Makefiles. Most other devs are 
using "Ninja" and the ninja build system works fine.

There are some subtle differences between those build systems.

I suggest you file this as a bug. And while we look into getting this fixed, I 
suggest you switch the the Ninja generator by  specifying "-GNinja" to cmake.

The replace "make" with "ninja" (or "ninja-build" on some systems) in all your 
calls.

Regards,

Geert

Op dinsdag 23 maart 2021 10:57:34 CET schreef c.holterm...@gmx.de:
> Hello all,
> 
> I tried compilation in some scenarios:
> 
> On a fresh git clone
> 
> A) Compiling 4.4 from scratch works.
> 
> B) Compiling maint from scratch does not compile.
> 
> C) Compiling 4.4 from scratch, checking out to maint head and
> recompiling current maint on top of the 4.4 build works.
> 
> regards,
> 
> Christoph
> 
> Am 2021-03-21 08:55, schrieb c.holterm...@gmx.de:
> > No, I work from a git clone. In addition I tried to do a fresh clone
> > from git. This doesn't compile as well. Same error. I'm working on
> > debian 10.8.
> > 
> > regards,
> > 
> > Christoph
> > 
> > Am 2021-03-20 17:35, schrieb Geert Janssens:
> >> Did you by any chance start from a github zipfile instead of a cloned
> >> git
> >> repository ?
> >> 
> >> Regards,
> >> 
> >> Geert
> >> 
> >> Op zaterdag 20 maart 2021 16:16:23 CET schreef GMX:
> >>> Hello,
> >>> 
> >>> just trying to compile after some months not on the project.
> >>> Compilation
> >>> 
> >>> from maint and master fails for me:
> >>> > >> cmake ../gnucash
> >>> > 
> >>> > ...
> >>> > [ 0%] Built target guile-json
> >>> > make[2]: *** No rule to make target
> >>> > 'libgnucash/core-utils/gnc-vcs-info.h', needed by
> >>> > 'share/gnucash/gnucash.1'. Stop.
> >>> > make[1]: *** [CMakeFiles/Makefile2:1496:
> >>> > doc/CMakeFiles/gnucash-manpage.dir/all]
> >>> > Error 2 make: *** [Makefile:163: all] Error 2
> >>> 
> >>> don't know what to make of that. If I just recompile and existing and
> >>> updated builddir everything works fine (checked for maint).
> >>> 
> >>> regards,
> >>> 
> >>> Christoph
> >>> 
> >>> ___
> >>> gnucash-devel mailing list
> >>> gnucash-devel@gnucash.org
> >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > 
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel




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

Re: [GNC-dev] Compilation fails on libgnucash/core-utils/gnc-vcs-info.h

[Geert Janssens]

Did you by any chance start from a github zipfile instead of a cloned git 
repository ?

Regards,

Geert

Op zaterdag 20 maart 2021 16:16:23 CET schreef GMX:
> Hello,
> 
> just trying to compile after some months not on the project. Compilation
> 
> from maint and master fails for me:
> > >> cmake ../gnucash
> > 
> > ...
> > [ 0%] Built target guile-json
> > make[2]: *** No rule to make target
> > 'libgnucash/core-utils/gnc-vcs-info.h', needed by
> > 'share/gnucash/gnucash.1'. Stop.
> > make[1]: *** [CMakeFiles/Makefile2:1496:
> > doc/CMakeFiles/gnucash-manpage.dir/all]
> > Error 2 make: *** [Makefile:163: all] Error 2
> 
> don't know what to make of that. If I just recompile and existing and
> updated builddir everything works fine (checked for maint).
> 
> regards,
> 
> Christoph
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




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

Re: [GNC-dev] Early locale initialization

[Geert Janssens]

Op vrijdag 19 maart 2021 02:19:46 CET schreef John Ralls:
> > On Mar 18, 2021, at 6:08 AM, Geert Janssens 
> > wrote:> 
> > Op donderdag 18 maart 2021 13:56:35 CET schreef Derek Atkins:
> >> On Thu, March 18, 2021 7:58 am, Geert Janssens wrote:
> >> [snip]
> >> 
> >>> 3. While all three allow to tweak some environment parameters, only
> >>> linux
> >>> allows the user to do so via the environment file. For Windows and Macos
> >>> that
> >>> file is only read after locale is set. Whether that's a good thing
> >>> depends
> >>> on
> >>> the answer to question 2.
> >> 
> >> Are you saying that /etc/gnucash/environment (or the equivalent thereof)
> >> is not read/used on Windows or Mac?
> > 
> > No, it is used on all platforms. But it's only read after locale
> > initialization on mac/windows has been done. So for locale initialization
> > it only will affect linux. The other parameters in there (like
> > LD_LIBRARY_PATH tweaks and so on) will still affect all platforms.
> 
> No, it's read after the other initializations so that it will override them.
> As long as setlocale is called after loading the environment then the last
> computed locale is what GnuCash starts up with. I've tested that pretty
> extensively on both macOS and Win32, though not since last fall.
> 
Running this through a debugger I see setlocale gets called indeed afterwards 
but more by chance than by choice (the first time during gtk's 
initialization).

To zoom in on this: if I get you right the idea is effectively to allow users 
to set LC_ALL in the environment file and make it override whatever system 
locale was found (or fallen back to).

The code and comment in https://github.com/Gnucash/gnucash/blob/maint/gnucash/
gnucash-core-app.cpp#L424 certainly don't suggest that. For Macos and Windows 
it explicitly excludes the call to setlocale, with the suggestion it was 
already done. That's contrary to that intent.

I guess the part that complicates this area is that on both Windows and Macos 
there are two locales to take into account - the posix locale and the platform 
native one.

The windows branch of this code explicitly tries to set both to the same 
locale. If it finds LC_ALL, LC_MESSAGES or LANG it will use that for posix and 
then set the same for the Windows locale. In the absence of any of these it 
will start from the Windows locate and use that to also set the posix locale. 
To me that suggests the environment overrides should happen before calling 
this code. If you do it afterwards like we do now you may end up with out of 
sync Windows and Posix locales. I have no idea if that would have side-effects 
but I can imagine this could result in some obscure locale related corner case 
bugs.

If I read the mac branch of the code correctly, it always starts from the 
Macos locale and tries to derive a posix locale from it. A user can afterwards 
override that posix locale via settings in the environment file. The mac 
locale will never be updated to match any posix locale though. Again I don't 
know if that could be cause for issues.

Do you think a reverse mapping as in the Windows environment would be possible 
? I mean if users set LC_ALL (or related), can we use that to set the Macos 
locale for the gnucash process space ? I don't know enough of the platform to 
know whether Macos allows an application to change locales.

> The one thing that doesn't work is passing LANG/LANGUAGES in the Win32 CMD
> shell because that shell doesn't understand that. It should be possible on
> Powershell with something like $Env:LANG=nl_BE "c:\Program Files
> (x86)\gnucash\bin\gnucash.exe"; I've never actually tried that.
> 
Well, you can do the same in a Win32 CMD shell, but not on a single line.
set LANG=nl_BE
"c:\Program Files (x86)\gnucash\bin\gnucash.exe"
Will do it.

> On macOS the language fallback is used because Apple's localization can
> result in locales that libc thinks aren't legal, e.g. en_BE so we have to
> find something close or the user gets "C". That's done only when getting
> the locale from system preferences (aka "defaults").

I consider that a very nice refinement.

Regards,

Geert



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

Re: [GNC-dev] French Translation

[Geert Janssens]

Op donderdag 18 maart 2021 11:04:30 CET schreef coulon...@netc.fr:
> Hello,
> 
> 
> I'm using GnuCash for 4 years now and I would like to help this great
> project and contribute a bit.
> 
> I used be a C developper but for the time being I would prefer to improve
> french translation, especially the webpage.
> 
> 
> 
> Let me know if this is possible for you.

Hi Coulonval,

Absolutely! Translation contributions are equally welcome as code 
contributions, so please dive in  :)

Our website translations are managed on weblate:
https://hosted.weblate.org/projects/gnucash/website/

If you make an account there you can start translating right away. It is 
probably a good idea though to contact the previous maintainer with regards to 
reviewing your work: will he do this or will you be responsible for your own 
translations. Depending on that you also need to request review permissions.

Enjoy!

Geert


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

Re: [GNC-dev] Early locale initialization

[Geert Janssens]

Op donderdag 18 maart 2021 13:56:35 CET schreef Derek Atkins:
> On Thu, March 18, 2021 7:58 am, Geert Janssens wrote:
> [snip]
> 
> > 3. While all three allow to tweak some environment parameters, only linux
> > allows the user to do so via the environment file. For Windows and Macos
> > that
> > file is only read after locale is set. Whether that's a good thing depends
> > on
> > the answer to question 2.
> 
> Are you saying that /etc/gnucash/environment (or the equivalent thereof)
> is not read/used on Windows or Mac?
> 
No, it is used on all platforms. But it's only read after locale 
initialization on mac/windows has been done. So for locale initialization it 
only will affect linux. The other parameters in there (like LD_LIBRARY_PATH 
tweaks and so on) will still affect all platforms.

Geert


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

Re: [GNC-dev] Early locale initialization

[Geert Janssens]

Op donderdag 18 maart 2021 12:58:28 CET schreef Geert Janssens:
> On Windows the code will first look for environment variables "LC_ALL",
> "LC_MESSAGES" or "LANG" (in that order). If any of those exists it will try
> to convert that to a locale. If that fails it will fall back to the system
> default locale and if that fails it falls through to our main code which
> then defaults to "C".

This is not even true. The way it is currently implemented it won't reach the 
fallback-to-C code at all.

Geert


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

Re: [GNC-dev] Early locale initialization

[Geert Janssens]

In addition, the Macos code doesn't return the final locale string that was 
set. As a result the PINFO message to log the locale details to the trace file 
is partly bogus. Granted this was written with the Windows locale issues in 
mind, but again, it would be nice if this could be made consistent.

Regards,

Geert

Op donderdag 18 maart 2021 12:58:28 CET schreef Geert Janssens:
> In a moment of distraction I started looking at the locale initialization
> code in gnucash-core-app.cpp.
> 
> If I understand the actual code properly it's not exactly working as I had
> intended. So with this thread, I'd like to clear this out.
> 
> For reference I'm talking about the code that starts here:
> https://github.com/Gnucash/gnucash/blob/
> 1756f76079221f77904ccb9c9a504f9ebca2eb0e/gnucash/gnucash-core-app.cpp#L418
> 
> Locale initialization is strongly influenced by platform, so there are
> different code paths to set locale.
> 1. Macos will use set_mac_locale
> 2. Windows will use set_win32_thread_locale
> 3. Linux will fall through and use setlocale
> 
> So far so good.
> 
> Looking deeper, the linux method will search for an environment variables
> LC_ALL or LANG in that order and uses its value as locale. If that fails, it
> will fall back to the C locale. There is also code  in place to allow the
> user to override any of these variables by setting them in the gnucash
> environment file.
> 
> On Macos the code will first try to use the Macos proper locale setup code.
> If that fails it falls back to locale "en_US.utf-8". Then it sets the LANG
> variable to the same locale and proceeds with calling gnc_localeconv which
> will fill in the locale details that will be used throughout the code.
> 
> On Windows the code will first look for environment variables "LC_ALL",
> "LC_MESSAGES" or "LANG" (in that order). If any of those exists it will try
> to convert that to a locale. If that fails it will fall back to the system
> default locale and if that fails it falls through to our main code which
> then defaults to "C".
> 
> 
> Putting these next to each other there are a few differences:
> 1. the final fallback locale. On Macos that will be "en_US.utf-8", on the
> other platforms it will be "C". Should we use the same default on all or
> rather not ?
> 2. Priority of locale source. On linux and Windows adding variables in the
> environment will allow the user to override the default system locale. On
> Macos it will only allow to set LANG or LANGUAGE variables, not locale. Do
> we want to allow the user to override system locale via environment
> variables or do we only want a fallback mechanism ? Do we want to allow the
> user specify the locale to use for that fallback ?
> I'll note the Macos code has a neat fallback trick in that it tries to find
> a related locale in case the default doesn't work. Related in the sense
> that it may be another language in same country or if that fails the
> language without country. Downside is that in  case of multiple fallback
> options the one chosen may not be the one the user actually would have
> preferred.
> 3. While all three allow to tweak some environment parameters, only linux
> allows the user to do so via the environment file. For Windows and Macos
> that file is only read after locale is set. Whether that's a good thing
> depends on the answer to question 2.
> 
> Regards,
> 
> Geert
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




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

[GNC-dev] Early locale initialization

[Geert Janssens]

In a moment of distraction I started looking at the locale initialization code 
in gnucash-core-app.cpp.

If I understand the actual code properly it's not exactly working as I had 
intended. So with this thread, I'd like to clear this out.

For reference I'm talking about the code that starts here:
https://github.com/Gnucash/gnucash/blob/
1756f76079221f77904ccb9c9a504f9ebca2eb0e/gnucash/gnucash-core-app.cpp#L418

Locale initialization is strongly influenced by platform, so there are 
different code paths to set locale.
1. Macos will use set_mac_locale
2. Windows will use set_win32_thread_locale
3. Linux will fall through and use setlocale

So far so good.

Looking deeper, the linux method will search for an environment variables 
LC_ALL or LANG in that order and uses its value as locale. If that fails, it 
will fall back to the C locale. There is also code  in place to allow the user 
to override any of these variables by setting them in the gnucash environment 
file.

On Macos the code will first try to use the Macos proper locale setup code. If 
that fails it falls back to locale "en_US.utf-8". Then it sets the LANG 
variable to the same locale and proceeds with calling gnc_localeconv which 
will fill in the locale details that will be used throughout the code.

On Windows the code will first look for environment variables "LC_ALL", 
"LC_MESSAGES" or "LANG" (in that order). If any of those exists it will try to 
convert that to a locale. If that fails it will fall back to the system 
default locale and if that fails it falls through to our main code which then 
defaults to "C".


Putting these next to each other there are a few differences:
1. the final fallback locale. On Macos that will be "en_US.utf-8", on the 
other platforms it will be "C". Should we use the same default on all or 
rather not ?
2. Priority of locale source. On linux and Windows adding variables in the 
environment will allow the user to override the default system locale. On 
Macos it will only allow to set LANG or LANGUAGE variables, not locale. Do we 
want to allow the user to override system locale via environment variables or 
do we only want a fallback mechanism ? Do we want to allow the user specify 
the locale to use for that fallback ?
I'll note the Macos code has a neat fallback trick in that it tries to find a 
related locale in case the default doesn't work. Related in the sense that it 
may be another language in same country or if that fails the language without 
country. Downside is that in  case of multiple fallback options the one chosen 
may not be the one the user actually would have preferred.
3. While all three allow to tweak some environment parameters, only linux 
allows the user to do so via the environment file. For Windows and Macos that 
file is only read after locale is set. Whether that's a good thing depends on 
the answer to question 2.

Regards,

Geert


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

Re: [GNC-dev] String Freeze

[Geert Janssens]

Does string freeze also cover gnucash-docs ?

Geert

Op zondag 14 maart 2021 22:58:35 CET schreef John Ralls:
> Devs,
> 
> It's two weeks until our 4.5 release and that means it's time for a string
> freeze on maint. Please don't push any commits with changes to any
> translatable string, not even minor spelling or punctuation changes, to
> maint until after we release GnuCash 4.5.
> 
> Regards,
> John Ralls
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




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

Re: [GNC-dev] Toolbar Style

[Geert Janssens]

Hi,

The configuration option you reference to is a Gtk configuration option. The 
Gtk project has dropped this option with Gtk3. It now puts responsibility with 
the projects using Gtk3 to decide which toolbar style to use.

So when GnuCash switched to  Gtk3, the possibility to configure this as a user 
was lost. After a few trials with what should be the best hard-coded style, we 
ended up with the small icons+text as the best compromise.

Regards,

Geert

Op zaterdag 6 maart 2021 15:25:00 CET schreef Taull Boi:
> Hi,
> 
> I am using gnucash 4.4 on Windows. I find that the gnucash toolbar style
> does not change even though I have correctly configured the toolbar style
> settings in gtk-3.0/Settings.ini as follows:
> 
> [Settings]
> gtk-toolbar-style = GTK_TOOLBAR_TEXT
> 
> This problem appears to have been discussed below:
> 
> http://gnucash.1415818.n4.nabble.com/GNC-Toolbar-ignoring-gtk-toolbar-style-> 
> setting-in-Ubuntu-18-04-Bionic-tt4699591.html
> 
> I was looking at the gnucash source code and the toolbar style seems to be
> hardcoded in the following locations:
> 
> ./gnome/window-reconcile.c:1699:gtk_toolbar_set_style
> (GTK_TOOLBAR(widget),
> ./gnome-utils/gnc-embedded-window.c:302:gtk_toolbar_set_style
> (GTK_TOOLBAR(priv->toolbar),
> ./gnome-utils/gnc-main-window.c:3964:gtk_toolbar_set_style
> (GTK_TOOLBAR(priv->toolbar),
> 
> I was wondering why this is done.
> 
> Thanks for your time.
> ___
> 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] Help documentation

[Geert Janssens]

A complex topic is brought up here.

I agree with the issues you bring up. I don't know if or how we can solve them 
all.

In the gnucash project we currently only have experience with docbook for user 
oriented documentation and doxygen for our api documentation.

On the premise what we have so far is too complicated, I started looking at a 
few other projects to figure out how they manage their help. The hope is 
someone else has already solved this problem. I have only looked at a couple 
of projects so far.

It may be disappointing that many of the mature projects out there have a 
similar setup as we do (gimp, kontact, ...) Probably not surprising 
considering these projects are around for a long time and options were limited 
back in the days.

But there are a few alternative approaches:

* Libreoffice unsurprisingly handles user documentation in libreoffice 
documents [1]. It is however not clear whether that also comprises their help 
documentation.
They have set up a collaborative platform via nextcloud (which ships with a 
collaborative word processor, akin to Microsoft's 365 office or Google's 
Docs). I don't have an account there so I can't evaluate how that works 
exactly.
An addition they use weblate for string translations [2]. That's a selfhosted 
weblate instance, and it has a help project next to their ui project. Looking 
at the source files referenced there, the strings are extracted from xhp 
files. I don't know exactly what those are (yet).
So far I haven't discovered yet how much developer skills a documentation or 
help contributor needs (versioning system, build recipes,...)

* Firefox has another strategy [3]. Their help system is based on reStructured 
text files that sit next to the functionality. The documentation build system 
picks them up from there for further processing. Again it's not clear whether 
help is treated differently from guides and manuals.
Adding documentation does require tweaking build scripts (updating variables 
and running builds to verify the new docs).
Their devel documentation has a large section on localization, but it's 
focused on UI localization. So far I haven't found how they localize their 
help.

That's what I have found so far. Curiously it seems help is always treated as 
a second class citizen. While it's there, it's hard to find how it's managed.

This is meant as a starting point for further research. Others are invited and 
strongly encouraged to add more references or details.

Regards,

Geert


[1] https://wiki.documentfoundation.org/Documentation/DocumentationTeamInfo
[2] https://translations.documentfoundation.org/
[3] 
https://firefox-source-docs.mozilla.org/tools/moztreedocs/adding-documentation.html

Op dinsdag 16 februari 2021 18:21:03 CET schreef John Ralls:
> The way we manage program help has four serious problems:
> 
> 1. It's separate from the program--not even in the same git repository--so
> changes to the program are seldom reflected in the help. Very little of it
> has been touched in the last 10 years.
> 
> 2. It's largely monolithic which makes it resistant to translation, so while
> the program is translated into 58 languages, the help has only 3, only 1 of
> which, German, is up to date.
> 
> 3. It's formatted with Docbook, an XML dialect with no usable editing or
> translation tools, so authors and translators must learn to edit XML by
> hand and learn to work the document build system so that they can build to
> HTML and then review their work in their browser. Pretty damn tedious.
> 
> 4. A lot of GnuCash is completely undocumented.
> 
> Note that unlike the Tutorial and Context Guide sections of the help are
> reachable by context help buttons throughout the UI. ISTM that should make
> it more amenable to translation with gettext.
> 
> I think that if the help documentation was kept close to the UI code that it
> would be both easier for developers to keep it in sync with code changes
> and for code reviewers to insist that they do so. Integrating it with the
> build system that they already use routinely would remove a bit of the
> tedium, but even better would be finding a format for which a Free WYSIWYG
> editor is available or better still where contributors could edit directly
> on Github and create a PR using the fairly simple Github online UI, making
> editing accessible to non-developers (that would suggest that the format
> should be either Github-flavored markdown or restructured text, the formats
> for which Github supports WYSIWYG editing).
> 
> A somewhat geekier alternative--though still far more accessible than
> Docbook in a separate repo--is Doxygen markup. We already use that
> extensively for the API (though not extensively enough, there's a lot of
> undocumented API). Unfortunately Doxygen doesn't provide a way to extract
> msgids so we'd have to either build in a format that xgettext understands
> or extend Doxygen.
> 
> Regardless of the markup style we need to work out exactly where in the

Re: [GNC-dev] GncCombott Widget

[Geert Janssens]

Thanks. I'm fine with the dropping value listings in tooltips as well. The 
only reason I considered them was for the cases where per-value extra info 
would be needed. In my quick evaluation of a number of them that doesn't 
really seem necessary.  

Regards,

Geert

Op dinsdag 16 februari 2021 17:37:21 CET schreef John Ralls:
> I generally agree, but I think that there's no great benefit to listing the
> available options in most cases. The user can easily enough click the
> revealer to see them. I also don't think that we want dissertation-length
> tooltips. If that much verbiage is required then it should be in the help
> document,but that presents other issues that I'll address in a new thread.
> 
> We should relabel sort selectors from the overly geeky "primary key" and
> "secondary key" to something like "Sort first by:" and "Then sort by:".
> That's sufficiently descriptive that a tool tip isn't necessary.
> 
> Regards,
> John Ralls
> 
> > On Feb 16, 2021, at 7:11 AM, Geert Janssens 
> > wrote:
> > 
> > Hi Bob,
> > 
> > I did some experiments and I agree with you it would be hard to implement
> > this in Gtk3 because the tooltips should be added to the internal
> > GtkMenu. The GtkCombobox interface does not provide access to that
> > widget.
> > 
> > So there is a trade-off to make here between maintenance burden and added
> > value.
> > 
> > Personally I'm clearly in favor of restrict our specialized widgets to
> > only
> > where absolutely necessary.
> > 
> > In this case my suggestion would be to rethink our tooltip strategy in the
> > context of the GtkComboBoxes. Clearly Gtk didn't intend for each entry in
> > the menu to have a separate tooltip. I don't know their motivation (lack
> > of time, UX considerations,...)
> > 
> > What we can do with the GtkComboBox as is could be to use the single
> > tooltip it currently supports and be smarter on what we put in there.
> > 
> > For the remainder of this text, I'll focus on the comboboxes in report
> > options, but I think the reasoning remains the same for other locations.
> > 
> > Currently the comboboxes in report options will always show the tooltip
> > that relates to the selected combo menu item. For example for the
> > Stylesheet option, with "Default" being selected, the tooltip for the
> > combobox will be "Default stylesheet". Again, I'm talking about the
> > situation where the popup menu is hidden.
> > 
> > A few things to note:
> > * This tooltip doesn't really explain what the Stylesheet option is for.
> > It
> > explains what the selected value is. That's already inconsistent with
> > other
> > options - the tooltip on a text entry field will explain you what input is
> > expected from you. This information is not given for combobox tooltips.
> > That only gives a tip on what's currently selected.
> > 
> > * The tooltip "Default stylesheet" adds very little extra useful
> > information compared to the option name being "Stylesheet" and the option
> > value being "Default".
> > 
> > So there's little reason to add tooltips in this case to start with.
> > 
> > Next, given the limitations of a normal GtkComboBox, we could also build
> > tooltips for such combos as follows:
> > 
> > * Begin with an explanation of what the option is for (not what each value
> > represents)
> > * Then add a list of possible values, and for each value an explanation of
> > what it represents. I actually think if the explanation of the option is
> > well done, it's unlikely each value itself still needs an explanation,
> > just listing the possible options may be enough.
> > 
> > The advantage of this way of working is that a user gets a complete
> > overview by hovering the combobox even before clicking and navigating
> > through the popup menu. And there's an overarching overall tooltip to add
> > context to the possible choices. Something we currently are lacking.
> > 
> > This can still be done in code, though we need to add sensible explaining
> > tooltips for the options that are using a combobox widget. I don't think
> > we
> > currently have those.
> > 
> > Note you can still do smart things like highlight the selected value in
> > the
> > big tooltip using markup so more attention is drawn to the currently
> > selected value (and its possible explanation).
> > 
> > As an exercise I went through all the comboboxes in the transaction
> > report's options. From my estimate

Re: [GNC-dev] GncCombott Widget

[Geert Janssens]

Hi Bob,

I did some experiments and I agree with you it would be hard to implement this 
in Gtk3 because the tooltips should be added to the internal GtkMenu. The 
GtkCombobox interface does not provide access to that widget.

So there is a trade-off to make here between maintenance burden and added 
value.

Personally I'm clearly in favor of restrict our specialized widgets to only 
where absolutely necessary.

In this case my suggestion would be to rethink our tooltip strategy in the 
context of the GtkComboBoxes. Clearly Gtk didn't intend for each entry in the 
menu to have a separate tooltip. I don't know their motivation (lack of time, 
UX considerations,...)

What we can do with the GtkComboBox as is could be to use the single tooltip 
it currently supports and be smarter on what we put in there.

For the remainder of this text, I'll focus on the comboboxes in report 
options, but I think the reasoning remains the same for other locations.

Currently the comboboxes in report options will always show the tooltip that 
relates to the selected combo menu item. For example for the Stylesheet 
option, with "Default" being selected, the tooltip for the combobox will be 
"Default stylesheet". Again, I'm talking about the situation where the popup 
menu is hidden.

A few things to note:
* This tooltip doesn't really explain what the Stylesheet option is for. It 
explains what the selected value is. That's already inconsistent with other 
options - the tooltip on a text entry field will explain you what input is 
expected from you. This information is not given for combobox tooltips. That 
only gives a tip on what's currently selected.

* The tooltip "Default stylesheet" adds very little extra useful information 
compared to the option name being "Stylesheet" and the option value being 
"Default".

So there's little reason to add tooltips in this case to start with.

Next, given the limitations of a normal GtkComboBox, we could also build 
tooltips for such combos as follows:

* Begin with an explanation of what the option is for (not what each value 
represents)
* Then add a list of possible values, and for each value an explanation of 
what it represents. I actually think if the explanation of the option is well 
done, it's unlikely each value itself still needs an explanation, just listing 
the possible options may be enough.

The advantage of this way of working is that a user gets a complete overview 
by hovering the combobox even before clicking and navigating through the popup 
menu. And there's an overarching overall tooltip to add context to the 
possible choices. Something we currently are lacking.

This can still be done in code, though we need to add sensible explaining 
tooltips for the options that are using a combobox widget. I don't think we 
currently have those.

Note you can still do smart things like highlight the selected value in the 
big tooltip using markup so more attention is drawn to the currently selected 
value (and its possible explanation).

As an exercise I went through all the comboboxes in the transaction report's 
options. From my estimate with a decent description of what the option does, 
the actual option values are self-explanatory in 99% of the cases. Only in 
very few situations a per value tooltip can add some additional information. 
And even there it's usually only for one of two values in the whole value 
list.

For example, there's the "Primary Key" option. That in itself is a very 
technical and unfortunate option name, but that's what we have now. If a 
general tooltip was added to explain this sets the column to sort on first, 
there's no need for any of the tooltips on the possible values. It's pretty 
clear those are column names.

Another example: Void Transactions.
If a tooltip explains this option allows to filter transactions based on their 
voided status, that would already explain all the possible values. One could 
add a note/warning in that tooltip that if void transactions are selected, 
their values will be added to the totals as well. With that everything that's 
currently presented via the per-value tooltips is available in the general 
tooltip and more.

The same worked for me for each and every of the other options.

So while you are free to fix this as you see fit, I'm a strong proponent of 
revisiting our decision to continue to use per value tooltips.

Regards,

Geert

Op dinsdag 16 februari 2021 12:10:56 CET schreef Robert Fewell:
> Hi,
> 
> In bug 798109 it was highlighted that the widget I wrote back in 2012 does
> not respond to keyboard use well which I think would be relatively easy to
> fix and maybe a couple of tweaks.
> 
> Geert suggested that it could be dropped in favour of a traditional
> GtkComboBox.
> 
> The reason I wrote it was to match the GTK2 version at that time which
> allowed you to have tooltips on the popped up menu items as well as when
> the item was selected and the popup removed. This can not be done in the
> GTK3 

Re: [GNC-dev] Failed to build GnuCash on Windows

[Geert Janssens]

Op maandag 15 februari 2021 10:58:20 CET schreef Explorare:
> I followed the instructions on /gnucash-on-windows but failed with error
> "TypeError: can only join an iterable". And there is a warning before this:
>   "libtool: warning: '../lib/libosp.la' has not been installed in
> '/c/gcdev64/gnucash/maint/inst/lib'" [1]
> 
> So I make a copy of libosp.la to that path manually, and compiled again.
> The process stopped with a similar error " [2]
> 
> All commands are executed with admin privileges. And I've fetched the
> origin of gnucash-on-windows. Maybe it failed to copy the needed lib files?
> 
> [env]
> Windows 10 10H2 19042.804 (64bit)
> MSYS2 x86_64 20200903
> 
> [log files]
> [1] https://gist.github.com/Explorare/b9b123dd21f19b9351168053cb074aae
> [2] https://gist.github.com/Explorare/f86a60bc1e20644934a87f9fc619e7da
> 
> Thanks
> 
> ps. I'm trying to edit iso-4217-currencies.xml to add some
> cryptocurrencies and have no experience with jhbuild.

Also a note on your final goal.
Crypto currencies are no iso-4217 endorsed currencies. So you are free to try 
and add currencies like that for your own purpose, but this can't be included 
in the gnucash project in this form.

Additionally there are technical side effects to take into account, which may 
or may not be relevant for you. The first that comes to mind is that online 
quote retrieval will treat all currencies the same. I doubt however the online 
sources used to retrieve currency quotes will also  know about crypto 
currencies. Do AlphaVantage or Yahoo (via its json api) report crypto currency 
quotes ?

Other than that, happy hacking! If you can make gnucash work for you 
persoanlly as you want it, thumbs up.

Regards,

Geert


___
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

[Geert Janssens]

Hi Rob,

I have gathered from irc conversations the you have picked up on your interest 
of converting our documentation to reStructuredText. As I'm unfortunately not 
able to spend much time on irc while you are there, I will add some comments 
on this mailing list thread.

From the little information I have so far it looks like reStructuredText and 
the sphinx tool have everything it takes for a good conversion with plenty of 
benefits.

The only concern that remains for me is as mentioned earlier:
So far I don't see the ability for a master document in which certain sections 
only apply to some languages. To be fair our current documentation doesn't 
support that either as of today, but adding ITS to the current docbook mix 
would allow us to move in that direction.

Personally I find that an important feature to have for our future 
documentation system. Contrary to many other domains, accounting documentation 
is sensitive to regional differences. Each region may have subtle differences 
in how certain things are to be explained.
Luckily there is standardisation which means an estimated 90% of the 
documentation can be shared, but a small portion is region dependent. A 
typical example would be tax rules. Or some concepts only make sense in 
certain regions and don't apply at all in other regions.

Considering most of the documentation is common, a translation flow based on a 
master document with message catalogs makes sense to me. The huge benefit is 
that we can offer user-friendly systems to translators. I seem to remember the 
biggest hurdle for documentation writers and translators is git. Going for a 
gettext based translation system, at least translators would be able to do 
most of their job in tools familiar to them, like weblate or poedit or 
whatever.

But we should take care to also be able to handle that small part that's not. 
And that's where ITS in the docbook context would come in. It allows (among 
others) to mark certain sections as applying only to one specific "language".

That would allow an American document writer to explain the basics of American 
taxes, and a Dutch translator could replace that with a Dutch alternative in 
such a way that if the American section changes the Dutch translation is not 
affected.

And it would allow the American document to explain state taxes. Belgium and 
the Netherlands don't have states, so that section could be omitted in a Dutch 
translation.

I admit not having searched very hard, but I  didn't find something similar 
for reStructuredText or the sphinx build system.

Do you see ways to implement something like that ?

Regards,

Geert

Op zaterdag 25 april 2020 20:16:46 CET schreef Rob Gowin:
> > On Apr 25, 2020, at 2:24 AM, Geert Janssens 
> > wrote:
> > 
> > Hi Rob,
> > 
> > Thanks for running this experiment.
> > 
> > The stylesheet used by ReadTheDocs is much more modern than ours and
> > indeed looks much nicer for online consumption. Even the pdf is cleaner.
> > 
> > On the other hand I also have a few concerns/questions:
> > 1. How would a translation flow look like with asciidoc ?
> > 2. Can it support a single master document including sections that should
> > only appear for certain translations ? 3. ReadTheDocs is a hosted
> > service. That's a big change from our current philosophy to self-host as
> > much as possible. Are there self-hosting options ?
> > 
> > Regards,
> > 
> > Geert
> 
> Hi Geert,
> 
> First off, yes, the documentation can be self hosted. I’ve done that here:
> https://gnucash-docs-test.codesmythe.net/index.html
> <https://gnucash-docs-test.codesmythe.net/index.html>. It uses an older
> stylesheet, so looks a little different, and there’s no PDF there. I have
> generated a PDF similar to the ReadTheDocs one locally. Note that this
> experiment uses files in the reStructuredText format, not asciidoc. The
> reST files are generated from the DocBook files using pandoc.
> 
> For translation: The underlying tool used by ReadTheDocs is the Sphinx
> Python Doc Generation Project. Their I18N flow is described here:
> http://www.sphinx-doc.org/en/master/usage/advanced/intl.html
> <http://www.sphinx-doc.org/en/master/usage/advanced/intl.html>. I’m no
> expert in the area, but seems it does support a single master document. I
> don’t know about sections that should only appear for certain translations.
> 
> I’ll jump on IRC sometime this week to discuss translations in more detail.
> 
> Regards,
> 
> Rob




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

Re: [GNC-dev] Fwd: [GNC] Windows 10 File History More Than 4

[Geert Janssens]

I forgot to add that default values are not created in the registry. So if you 
want to change it you have to create that value yourself. On Windows it can be 
of type REG_DWORD.

Regards,

Geert

Op vrijdag 18 december 2020 19:19:57 CET schreef Geert Janssens:
> Hi Christian,
> 
> On the same registry page that lists the 10 saved file names there is also a
> key named "maxfiles" that defines how many entries to show. It defaults to
> 4, but you can set it to 10 if you want to list all the files gnucash can
> store in history.
> 
> Regards,
> 
> Geert
> 
> > -Original Message-
> > From: Frank H. Ellenberger  Sent:
> > December 17, 2020 10:37 PM
> > To: christ...@eliminator-rc.com
> > Subject: Re: [GNC] Windows 10 File History More Than 4
> > 
> > Hello,
> > 
> > https://wiki.gnucash.org/wiki/FAQ#Q:_How_can_I_change_the_number_of_recent
> > _f iles.3F
> > 
> > HTH
> > Frank
> > 
> > Am 17.12.20 um 21:10 schrieb christ...@eliminator-rc.com:
> > > Is it possible on Windows 10 to configure the File History to show
> > > more than the default 4 last opened files? We have many different
> > > databases across mysql and xml and having to retype the connection
> > > details every time we need a different database is proving very
> > > tedious. I can see in the registry it stores the last 10 connections but
> > > in Gnucash it only lists 4.
> > 
> > ___
> > 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] Fwd: [GNC] Windows 10 File History More Than 4

[Geert Janssens]

Hi Christian,

On the same registry page that lists the 10 saved file names there is also a 
key named "maxfiles" that defines how many entries to show. It defaults to 4, 
but you can set it to 10 if you want to list all the files gnucash can store 
in history.

Regards,

Geert

> -Original Message-
> From: Frank H. Ellenberger  Sent:
> December 17, 2020 10:37 PM
> To: christ...@eliminator-rc.com
> Subject: Re: [GNC] Windows 10 File History More Than 4
> 
> Hello,
> 
> https://wiki.gnucash.org/wiki/FAQ#Q:_How_can_I_change_the_number_of_recent_f
> iles.3F
> 
> HTH
> Frank
> 
> Am 17.12.20 um 21:10 schrieb christ...@eliminator-rc.com:
> > Is it possible on Windows 10 to configure the File History to show
> > more than the default 4 last opened files? We have many different
> > databases across mysql and xml and having to retype the connection
> > details every time we need a different database is proving very
> > tedious. I can see in the registry it stores the last 10 connections but
> > in Gnucash it only lists 4.
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




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

Re: [GNC-dev] New branch mistake

[Geert Janssens]

Bob,

The command to execute would be
git push origin :bug309943

(I have done so for you already)

This will push the "empty" branch to bug309943, effectively removing it.

The git devs use odd logic from time to time...

Regards,

Geert

Op zaterdag 28 november 2020 12:38:54 CET schreef Robert Fewell:
> Hi Guys,
> 
> I think I got my bug_branch and branch the wrong way round and created a
> new branch on code/github of bug309943.
> 
> Could someone remove / advise on command to do this on code.
> 
> Regards,
> Bob
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


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

Re: [GNC-dev] gnucash maint: Multiple changes pushed

[Geert Janssens]

Op vrijdag 13 november 2020 00:52:44 CET schreef John Ralls:
> Updatedvia  https://github.com/Gnucash/gnucash/commit/d751913c 
> (commit)
>via  https://github.com/Gnucash/gnucash/commit/4e91a33b (commit)
>   from  https://github.com/Gnucash/gnucash/commit/a519b913 (commit)
> 
> 
> 
> commit d751913cb9d422be91595f42f89674248ffe90aa
> Author: John Ralls 
> Date:   Mon Nov 9 14:26:15 2020 -0800
> 
> Fix typo in .gitattributes, text not test.
> 
> commit 4e91a33be358ac952ea31c2c62c816070c15b453
> Author: John Ralls 
> Date:   Mon Nov 9 13:50:51 2020 -0800
> 
> Use LTDL_LIBRARY_PATH instead of (DY)LD_LIBRARY_PATH
> 
> With GnuCash's main libraries now linked at startup instead of being
> dlopened at runtime except by Guile we can restrict the library path
> renaming to Gnu Libtool's environment variable.

Gnucash is no longer using gnc-module itself but the gnc-module interface is 
still present though. So in theory we still support user-built custom gnc-
modules. Would they still work after your change on MacOS ?

If not, we should either just drop gnc-module completely (which Derek opposed 
IIRC) or clearly document the extra  steps the user should take to make it 
work, which IIUC on MacOS means setting (DY)LD_LIBRARY_PATH such that the 
custom gnc-module is found.

Regards,

Geert


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

Re: [GNC-dev] gnucash maint: Bug 797750 - SIGSEV in swig-engine.c

[Geert Janssens]

You're welcome :)

Op zaterdag 10 oktober 2020 22:31:14 CEST schreef Frank H. Ellenberger:
> Hi Geert.
> 
> OK, so we are talking about
> https://lists.gnucash.org/pipermail/gnucash-patches/2020-October/033716.html
> .
> 
> That branch was never intended to go online. I was working on htdocs'
> beta branch and that was displayed in eclipse's git history. But
> obvisious I have then selected push from gnucash's remotes. Then
> something was working, but no result appeared in  the history.
> 
> Fixed now.
> 
> Thanks for heads up!
> Frank
> 
> Am 10.10.20 um 16:15 schrieb Geert Janssens:
> > Op zaterdag 10 oktober 2020 16:13:24 CEST schreef Geert Janssens:
> >> Op vrijdag 15 mei 2020 21:37:35 CEST schreef John Ralls:
> >>> Updatedvia  https://github.com/Gnucash/gnucash/commit/659f785c
> >>> (commit)
> >>> 
> >>>   from  https://github.com/Gnucash/gnucash/commit/4e9990dd (commit)
> >>> 
> >>> commit 659f785cb81396412e503b4d8f5fe22ceb3f39df
> >>> Author: John Ralls 
> >>> Date:   Fri May 15 12:37:24 2020 -0700
> >>> 
> >>> Bug 797750 - SIGSEV in swig-engine.c
> >> 
> >> Frank,
> >> 
> >> Did you push intentionally to the github repo ? As far as I know we don't
> >> usually push feature branches there :)
> >> 
> >> Regards,
> >> 
> >> Geert
> > 
> > And this reply was to the wrong commit :(
> > 
> > It was meant in reaction to the creation of the i18ninspector branch.
> > 
> > Regards,
> > 
> > Geert
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel


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

Re: [GNC-dev] gnucash maint: Bug 797750 - SIGSEV in swig-engine.c

[Geert Janssens]

Op zaterdag 10 oktober 2020 16:13:24 CEST schreef Geert Janssens:
> Op vrijdag 15 mei 2020 21:37:35 CEST schreef John Ralls:
> > Updated  via  https://github.com/Gnucash/gnucash/commit/659f785c 
> > (commit)
> > 
> > from  https://github.com/Gnucash/gnucash/commit/4e9990dd (commit)
> > 
> > commit 659f785cb81396412e503b4d8f5fe22ceb3f39df
> > Author: John Ralls 
> > Date:   Fri May 15 12:37:24 2020 -0700
> > 
> > Bug 797750 - SIGSEV in swig-engine.c
> 
> Frank,
> 
> Did you push intentionally to the github repo ? As far as I know we don't
> usually push feature branches there :)
> 
> Regards,
> 
> Geert

And this reply was to the wrong commit :(

It was meant in reaction to the creation of the i18ninspector branch.

Regards,

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

Re: [GNC-dev] gnucash maint: Bug 797750 - SIGSEV in swig-engine.c

[Geert Janssens]

Op vrijdag 15 mei 2020 21:37:35 CEST schreef John Ralls:
> Updatedvia  https://github.com/Gnucash/gnucash/commit/659f785c 
> (commit)
>   from  https://github.com/Gnucash/gnucash/commit/4e9990dd (commit)
> 
> 
> 
> commit 659f785cb81396412e503b4d8f5fe22ceb3f39df
> Author: John Ralls 
> Date:   Fri May 15 12:37:24 2020 -0700
> 
> Bug 797750 - SIGSEV in swig-engine.c
> 
> 
Frank,

Did you push intentionally to the github repo ? As far as I know we don't 
usually push feature 
branches there :)

Regards,

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