[GNC-dev] Translations for 3.7; was: German online banking users would need a 3.7 release before mid-September...

[Frank H. Ellenberger]

Dear Translators,

If you want to update your translation and are having trouble to merge a
fresh gnucash.pot in your po file, let me know and I will do it for you.

That is easy possible, if your language is marked as external on
https://translationproject.org/domain/gnucash.html

Regards
Frank

Am 11.08.19 um 20:43 schrieb Christian Stimming:
> Am Samstag, 10. August 2019, 20:32:00 CEST schrieb John Ralls:
>>> the German online banking users have received notice from their banks that
>>> due to EU regulations, from mid-September onwards (Sept 14th) the banking
>>> client software has to use a registered product key, otherwise the bank
>>> server connection will be refused.
>>>
>>> (In German: https://www.hbci-zka.de/register/prod_register.htm )
>>>
>>> For gnucash, I have registered and received such a product key, and in the
>>> communication to me there haven't been any restrictions that would pose
>>> problems for open source software. Hence, as long as gnucash will stick to
>>> this procedure and send the product key, the users (and we) should be
>>> fine.
>>
>> Apparently the bank servers were supposed to have switched over last week,
>> see https://www.hbci-zka.de/register/register_faq.htm. The 14 September
>> deadline seems to have something to do with using FinTS bank interfaces via
>> third party services, see https://subsembly.com/apidoc/fints/index.html
>> under "PSD2 Client Registration". I suppose some users may have configured
>> GnuCash to do that and now will have to reconfigure to talk to their banks
>> instead. There's nothing we can do about that.
>
> The information on the zka.de  website about the dates is (no pun intended)
> outdated and the information is also unchanged for many months there. The date
> of Sept. 14th is what various users received as notification from their banks
> quite recently, that's where this date is from.
>
>> Regardless, we can do a snap release as soon as we can get the registration
>> number issue sorted and I can make time to do the release.
>
> The windows nightly has built last night. On gnucash-de I asked windows-users
> to start testing it. Let's see whether this is indeed sufficiently
> implemented. Once some positive feedback has arrived, a 3.7 release sometime
> in August would indeed be great - as it fits best for you.
>
>> I am a bit concerned about the registration number being published. What's
>> to prevent a bad actor from taking it and using it in a different,
>> malicious, application? What might be the consequences? Would DK revoke
>> GnuCash's registration? I think it more likely that the folks at DK didn't
>> even consider the possibility that there might be an open source financial
>> application than that it doesn't matter to them.
>
> I totally understand these concerns, and it holds for any open source project
> here, not only ours. Such as: KMyMoney, Hibiscus, aqbanking, but there are
> surely more. As it turns out, we've discussed those very same points on
> gnucash-de several months ago (in German) because the various people there
> came up with the same questions. Some people have asked at the ZKA for a
> statement regarding their view on open source software. Eventually we got a
> reply which is in our favor: This registration number has no legal obligations
> behind it. It is merely a tool for guiding the user support into better suited
> answers.  There's no security level introduced by this here, and it is known
> to the ZKA that open source software will have this number observable in the
> public source code. Yes, this in turn questions the whole point of this
> fuzz... on the other hand, if the bank server will otherwise refuse the whole
> online connection in the first place, we also have to do something about it.
>
> Regards,
>
> Christian
>
>
> ___
> 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] Import Main Matcher

[Frank H. Ellenberger]

Dear Davids,


Am Do., 15. Aug. 2019 um 03:07 Uhr schrieb David Cousens
:
>
> David,
>
> I also agree that the guide is the most logical place to place most of the
> detail for the Importing operations.
> However the same information is currently largely duplicated in the
> transaction operations section of the help manual including some recent
> updates re the importer and matcher. This may have resulted from the
> rearrangement you had in progress. I have recently updated some information
> in the Help manual section not realizing the same section was also in the
> guide.
>
> I would propose that we delete the section on importing in the help manual
> transaction operations and simply replace it with a cross reference to the
> Ch3 section on importing data in the guide and consolidate the current
> information into the guide there.  If everyone is happy with that I can
> start that process.
>
> David Cousens

IMHO the question is:

What would you expect to see, if you press on [Help] in any dialog?

That parts obvisious belong in Help, the rest can go to Guide.
So your tabel about the import matcher states was long missing in Help.

OTOH
Sections about "How to migrate between Q* and GC",
"Tips to import bank statements",
"How to split a years book" for whatever purpose...
could fill the data exchange chapter of the Guide.

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

Re: [GNC-dev] Import Main Matcher

[David Cousens]

David,

I also agree that the guide is the most logical place to place most of the
detail for the Importing operations.
However the same information is currently largely duplicated in the
transaction operations section of the help manual including some recent
updates re the importer and matcher. This may have resulted from the
rearrangement you had in progress. I have recently updated some information
in the Help manual section not realizing the same section was also in the
guide.

I would propose that we delete the section on importing in the help manual
transaction operations and simply replace it with a cross reference to the
Ch3 section on importing data in the guide and consolidate the current
information into the guide there.  If everyone is happy with that I can
start that process.

David Cousens



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Rework GoogleTest integration

[Christian Gruber]

Am 14.08.19 um 05:09 schrieb John Ralls:



On Aug 13, 2019, at 2:54 PM, Christian Gruber  
wrote:

Am 13.08.19 um 02:45 schrieb John Ralls:

On Aug 12, 2019, at 3:12 PM, Christian Gruber  
wrote:

Following my previous thread "[GNC-dev] Contribute to GnuCash development" I 
opened a new topic thread about reworking GoogleTest integration.


At first some investigation results on bug 797344 
.

In function gnc_gtest_configure() in file common/cmake_modules/GncAddTest.cmake 
the two CMake variables GTEST_INCLUDE_DIR and GMOCK_INCLUDE_DIR are set as 
follows:

find_path(GTEST_INCLUDE_DIR gtest/gtest.h HINTS ${GTEST_ROOT}/include 
${GMOCK_ROOT}/gtest/include /usr/include)
find_path(GMOCK_INCLUDE_DIR gmock/gmock.h HINTS ${GMOCK_ROOT}/include 
/usr/include)

This means, as long as GTEST_ROOT and GMOCK_ROOT are defined and refer to a 
valid GoogleTest repository, header files gtest.h and gmock.h are found there 
and the two variables GTEST_INCLUDE_DIR and GMOCK_INCLUDE_DIR will refer to the 
include directories within this GoogleTest repository.

In contrast to that the four CMake variables GTEST_MAIN_LIB, GTEST_SHARED_LIB, 
GMOCK_MAIN_LIB and GMOCK_SHARED_LIB are set in the same function 
gnc_gtest_configure() as follows:

find_library(GTEST_MAIN_LIB gtest_main)
find_library(GTEST_SHARED_LIB gtest)
find_library(GMOCK_MAIN_LIB gmock_main)
find_library(GMOCK_SHARED_LIB gmock)

This means, libraries are always searched in the default CMake search paths. 
Therefore any preinstalled GoogleTest libraries will be found this way.

This explains the behaviour described in my bug report.


Now let's come to my ideas regarding rework of GoogleTest integration. After 
further studying CMake files I have two general questions at first.

1. Why are library targets "gtest" and "gmock" defined in GnuCash build system 
instead of importing them from GoogleTest build results?

In file common/test-core/CMakeLists.txt these two targets are defined via 
add_library(). The same is done within GoogleTest build system in files 
googletest/CMakeLists.txt and googlemock/CMakeLists.txt. So part of the CMake 
build system from GoogleTest repository is copied into GnuCash build system.

My idea is to build and install GoogleTest completely independent from GnuCash 
using its own build system and then importing targets via find_package() into 
GnuCash build system. GoogleTest build system provides CMake configuration 
files after installation ready for importing targets into other projects.

CMake function find_package() is able to find package GTest via CMake configuration 
files, i.e. prebuilt from source code repository, as well as preinstalled libraries 
from distro using internal CMake module FindGTest 
. Beginning from CMake 
version 3.5 module FindGTest provides imported targets GTest::GTest and GTest::Main.

This would avoid mixing of libraries and header files from different locations.

Additionally the user doesn't have to define extra environment variables 
GTEST_ROOT and GMOCK_ROOT anymore. Instead the user can configure CMake search 
path using CMake variable CMAKE_PREFIX_PATH, if desired.

And the user can choose, which GoogleTest installation should be used by 
influencing the CMake search path. So the requirement, that one can decide 
whether to use preinstalled GoogleTest libraries from distro or GoogleTest 
installation prebuilt from sources would be fulfilled.


2. Why is library target "gtest" not used directly instead of variables 
GTEST_LIB, GTEST_INCLUDE_DIR?

Several test applications are defined via function gnc_add_test() by passing a 
list of sources, include directories and libraries to that function. This 
function gnc_add_test() is defined in file 
common/cmake_modules/GncAddTest.cmake and passes the list of libraries 
(TEST_LIBS_VAR_NAME) after resolving the variable names to CMake function 
target_link_libraries().

My idea is to add library target "gtest" directly to that list of libraries 
instead of variable GTEST_LIB, which is possible since CMake function 
target_link_libraries() can handle libraries as well as CMake targets. The advantage is, 
that you don't have to handle include directories separately on your own. When passing 
CMake targets to function target_link_libraries() CMake does all the stuff for you. 
Include directories defined for that target are added automatically, i.e. 
target_include_directories() doesn't have to be invoked to add GTEST_INCLUDE_DIR.

A further advantage is, that all test application targets depend on library target "gtest". And if library 
target "gtest" is not an imported target, it would be rebuilt automatically if necessary, when building test 
applications. Currently after any change to GoogleTest sources, e.g. checking out another version, you have to rebuilt 
GoogleTest libraries at first via "make gtest" for instance before you can rebuilt test applications

Re: [GNC-dev] Import Main Matcher

[David Cousens]

Frank,

I might also have to look at the recent additions to the Help manual and see
if they are not better in the guide rather than the help manual.  David T
pointed me to the right place in the guide in another post. Agreed on the
wiki. In addition to the information which might be useful to users, I have
mapped out some  the code linkages between the backend and the gui
(currently in flow charts in YeD) which may be more useful to those new to
the code. As John suggested I wil try and incorporate some of that in
Doxygen comments in the code.


David



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Import Main Matcher

[David Cousens]

Hi John,

Point taken on the documenting the how in the code and what it does in the
docs. I have a slight familiarity with Doxygen but no great expertise but
there is one way to change that. I'll ty and keep any Help and Tutorial
description as general as I can while trying to provide something that will
be useful to a user. David T has suggested Ch3 of the Tutorial and Concepts
Guide as a possible home. 

David



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel