First day of the week changes

[Bob-IT]

As promised this was what I was working on last November when I got distracted.

There are couple of bug fixes for saving the scheduled transaction page layout, i.e, the paned position and the number of months along with some tidy up.

The last three commits are the real changes.

• the first changes the dense calendar code to allow displaying the months to start on any day of the week.
• the second adds some GtkEntry widgets so that month, year and start day can be specified for testing.
• the last connects the dense call to gnc_get_first_day_of_week function which is OS specific.

That function is in gnc-gnome-utils which maybe in the wrong place but it had other Mac specific code and so was convenient. I am not sure the Mac code is correct but on Windows changing the start day under settings is reflected. The Mac and Windows functions do have error detection so that could default to gnc_start_of_week.

I have used a website that creates a calendar that allowed you to specify start day and from what I could see the calendars do match but would like other people to test it.

[jralls]

For the two bug fix commits please make the summary lines match the bug title. You can change the bug title if you want.

I haven't yet tested, generally looks pretty good. I'm not keen on more use of GDate but it looks like the alternative is to use ICU directly. That's too much work for this PR.

[Bob-IT]

For the two bug fix commits please make the summary lines match the bug title. You can change the bug title if you want.

I have missed this before, will do when I push again.

[Bob-IT]

I have made the changes to bug titles and removed my function in the last commit.
I have left the test widgets for now for testing.

[jralls]

Thanks. I hope to get time to test it later today.

[jralls]

@Bob-IT OK, it looks like it should when one changes the starting weekday.

I used an old test file with an SX that hasn't been allowed to run for a while. I was surprised that the calendar begins on the next month in which the selected SX is supposed to run rather than the current year. That makes me think that a start-month & year selector might be a useful addition. I don't think we want the start-of-week selector to be displayed most of the time.

The other thing that I noticed is that that it doesn't respond to changing the LANG value, either in etc/environment or with an environment variable in the shell, at least on my Mac. I had to change the region in System Preferences to get it to start the week on Monday instead of Sunday.

Of course as soon as someone notices this they'll wonder why the date selector calendar always starts on Sunday no matter the locale.

[Bob-IT]

I used an old test file with an SX that hasn't been allowed to run for a while. I was surprised that the calendar begins on the next month in which the selected SX is supposed to run rather than the current year.

There is code in gnc-dense-cal.c here that changes the default start month/year from now to the first date to be shown. What may be confusing and I think may of come up before is there is no year indicated. I have a schedule that last ran on 11/09/2018 with never as the next occurrence, if change that to 11/09/2019 the calendar starts from OCT.

I suppose that could be fixed by combining your suggestion with month and year combo's so on the left we get...
From "month name", year.

Then the next question would be how permanent are they, should they be saved while scheduled transactions page is open between sessions and reset to now when page is closed/opened?

The other thing that I noticed is that that it doesn't respond to changing the LANG value, either in etc/environment or with an environment variable in the shell, at least on my Mac. I had to change the region in System Preferences to get it to start the week on Monday instead of Sunday.

Did a normal GtkCalendar change, just wondering if the original code/macro line 510 using dgettext_noextract was needed, would need to change that to gtk30 as suggested in #1907. On my Linux VM I can start using LANG=en_US.utf8 gnucash and the dense cal starts on Sunday as opposed to my normal Monday

[jralls]

I suppose that could be fixed by combining your suggestion with month and year combo's so on the left we get...
From "month name", year.

Then the next question would be how permanent are they, should they be saved while scheduled transactions page is open between sessions and reset to now when page is closed/opened?

That works for me, and I wouldn't persist it, even when switching SXes in the list that might have different next dates.

Did a normal GtkCalendar change, just wondering if the original code/macro line 510 using dgettext_noextract was needed, would need to change that to gtk30 as suggested in #1907. On my Linux VM I can start using LANG=en_US.utf8 gnucash and the dense cal starts on Sunday as opposed to my normal Monday

#1907 nukes the whole function. I think that's the right thing to do. I don't see what that's got to do with anything though. The issue is that macOS uses ICU for its localization and ICU doesn't use ISO locale codes, so gnc_get_start_of_week is getting the locale info from the macOS configuration system. I imagine the same will be true of Windows; I haven't tested that. ISO locales in the environment is the way localization works in Linux so it's reasonable that ICU pays attention to that.

[gjanssens]

Did a normal GtkCalendar change, just wondering if the original code/macro line 510 using dgettext_noextract was needed, would need to change that to gtk30 as suggested in #1907. On my Linux VM I can start using LANG=en_US.utf8 gnucash and the dense cal starts on Sunday as opposed to my normal Monday

The issue is that macOS uses ICU for its localization and ICU doesn't use ISO locale codes, so gnc_get_start_of_week is getting the locale info from the macOS configuration system.

Is that the true reason ? If I look at the code that sets the locales - which has separate code paths on linux, windows and macos - I see the macOS path prioritizes the locale found in the macOS configuration system, while the linux path prioritizes what's set as environment variable. So if a valid locale is found in the macOS configuration system, the environment is never checked. Which would explain why you can't play with environment variables to test locale related stuff on macOS.

Our Windows locale code will first try the C library's setlocale() function and only if that doesn't work it will fall back to the Windows' native locale code. So I expect it to behave more like linux does in that you can override the preferred locale via the environment. (It may also be that due to this design choice the Windows native code is never called if setlocale() just does that for us in the background).

[jralls]

@gjanssens, It's supposed to work like Windows where it checks the environment first. I'll take a look.

[jralls]

@gjanssens,

Is that the true reason ?

Yes. If I add

--- a/libgnucash/engine/gnc-date.cpp
+++ b/libgnucash/engine/gnc-date.cpp
@@ -46,6 +46,7 @@

 #include <cinttypes>
 #include <unicode/calendar.h>
+#include <unicode/locid.h>

 #include "gnc-date.h"
 #include "gnc-date-p.h"
@@ -199,7 +200,8 @@ gnc_start_of_week (void)
     if (!cached_result)
     {
         UErrorCode err = U_ZERO_ERROR;
-        auto cal = icu::Calendar::createInstance (err);
+        icu::Locale icu_locale = icu::Locale::createFromName(setlocale(LC_TIME, nullptr));
+        auto cal = icu::Calendar::createInstance (icu_locale, err);
         if (!cal)
         {
             PERR("ICU error: %s\n", u_errorName (err));

to set the ICU locale from the POSIX locale then it behaves as expected when LANG=en_GB is set in the environment.

I see the macOS path prioritizes the locale found in the macOS configuration system

Half true. Attempting to set $LANG in the calling shell, perhaps like LANG=en_GB.UTF-8 LANGUAGE=$LANG /path/to/gnucash doesn't work, though setting those variables in etc/gnucash/environment does.

--- a/gnucash/gnucash-locale-macos.mm
+++ b/gnucash/gnucash-locale-macos.mm
@@ -197,10 +197,15 @@
     if (!setlocale(LC_ALL, [locale_str UTF8String]))
         locale_str =  mac_find_close_country(locale_str, country_str, lang_str);
 /* Cache the final locale string to be returned to the calling program */
-    gnc_locale = g_strdup ([locale_str UTF8String]);
-
-    if (g_getenv("LANG") == NULL)
+    if (!(gnc_locale = g_strdup(g_getenv("LANG"))))
+    {
+        gnc_locale = g_strdup ([locale_str UTF8String]);
         g_setenv("LANG", [locale_str UTF8String], TRUE);
+    }
+    else
+    {
+        locale_str = [NSString stringWithCString : gnc_locale encoding: NSUTF8StringEncoding];
+    }
     mac_set_currency_locale(locale, locale_str);

 /* Now call gnc_localeconv() to force creation of the app locale

Gets setting LANG and LANGUAGE in the shell working.
I haven't checked Windows but I suspect that we need to explicitly set the ICU locale there too because ICU sets its default locale from the system. Non-macOS unix has AFAIK only setlocale() and once a program has called it there's no straightforward portable way to get the locale that would have been set by setlocale(LC_FOO, "") at program startup.

[jralls]

@Bob-IT Can you wrap this up in the next week-10 days? I'd like to get it into GC5.7.

[Bob-IT]

@Bob-IT Can you wrap this up in the next week-10 days? I'd like to get it into GC5.7.

I used an old test file with an SX that hasn't been allowed to run for a while. I was surprised that the calendar begins on the next month in which the selected SX is supposed to run rather than the current year. That makes me think that a start-month & year selector might be a useful addition. I don't think we want the start-of-week selector to be displayed most of the time.

@jralls I did have a look at making the changes for this but did not like it, I think it gave the impression it could do more than in reality it could. I think it may be easier to remove them as originally intended and commit the rest of the changes. I will have another think about adding them and create a separate PR for it.

[jralls]

@Bob-IT That's reasonable, it's not related to calendar layout. Are all of the testing widgets confined to that last commit?

[Bob-IT]

@Bob-IT That's reasonable, it's not related to calendar layout. Are all of the testing widgets confined to that last commit?

@jralls Yes, I can drop the last commit and push this if you like.

[jralls]

@Bob-IT Go for it.