[GNC-dev] Use trading accounts only for currency conversion

[cicko]

As I've written in https://bugs.gnucash.org/show_bug.cgi?id=797227:

I suspect that the purpose of the trading accounts was to account for the
loss/gain in currency conversion (only). Not sure if applying the trading
accounts for other commodities makes sense. These should be accounted for
through Capital Gains/Losses accounts.
I find that mixing other commodities trades in trading accounts almost
destroys their usefulness.
Limiting their implementation to Currency commodities only would make more
sense. What do others think?



--
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] Transactions vs Splits

[cicko]

David, that's a very elaborate explanation. I'm sure there will be enough
information once you are through with testing. So far our findings match.
One thing I'd like to note,


David Cousens wrote
> Date,Transaction ID,Number,Description,Notes,Commodity/Currency,Void
> Reason,Action,Memo,Full Account Name,Account Name,Amount With Sym,Amount
> Num.,Reconcile,Reconcile Date,Rate/Price
> 15/11/18,b60da83af9b84334aa2f5e129c23016f,,Transfer with currency
> exchange,,CURRENCY::AUDAssets:Current Assets:Savings Account,Savings
> Account,$100.00,100.00,n,,1.00
> ,Assets:Current Assets:Savings USD,Savings
> USD,-$110.00,-110.00,n,,10/11
> 
> The Price is what should control the currency conversion. 

I find the Price and Amount information redundant, if both are sent. For
example, if they don't match, which one is the relevant one?
If amounts are sent in all splits, it would be better to read the amounts
and calculate the price/rate on import.

I assume your export is from GnuCash so it is good to learn that it exports
the Price element, too. I'll adjust my export to do the same, just in case.

In conclusion, the current state of import would work fine for transactions
in single currency. 

Another issue I had with QIF import was that it was matching accounts by
name, which is not what I wanted. When exporting transactions that use
categories, then expenses in all currencies go to, for example, Dining. QIF
import would always match Dining to Expenses:Dining, which is in EUR, in my
case. So it would always create duplicate accounts after the holidays.
One thing for me to check is if the CSV importer is better in that regard
and will match (or at least remember manually set values) the categories to
the accounts in correct currency (i.e. Expenses:Dining:AUD etc.).



--
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] Transactions vs Splits

[cicko]

cicko wrote
> However, if the price is taken into account, then perhaps the Price field
> may have some role there?

Hm, the Price column definitely affects the destination amount but not in a
way I can understand. Using

111,2019-03-06,,,15,"HSBC savings",,0
111,2019-03-06,,9.8788,,"cash, EUR",,2

where the last column is Price, the result is

<http://gnucash.1415818.n4.nabble.com/file/t377766/MTQo9WS.png> 





--
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] Transactions vs Splits

[cicko]

cicko wrote
> If this works as expected, then multi-currency transfers should not be an
> issue at all. Each split would specify the amount so no need for GnuCash
> to
> fiddle with prices. 

This works great for single-currency transactions. Everything fits, as
specified in CSV records.

There are issues, as hinted by David, with multi-currency transfers. This
makes no sense to me at the moment.
During the import, one of my transfers was matched but the other not. This
may be due to the fact that I have matched the first one during an earlier
import attempt.

Here is the sample CSV content:

26,2015-09-12,"Biss Tours",,33.25,"cash, EUR",
26,2015-09-12,"Biss Tours",12,,"Vacation:Travel",
26,2015-09-12,"Biss Tours",21.25,,"Vacation",
33,2015-09-13,"Billa",,15.26,"cash, EUR",
33,2015-09-13,"Billa",15.26,,"Food:Groceries",
110,2019-03-06,,,10,"cash, EUR",
110,2019-03-06,,19.5925,,"cash, BAM",
111,2019-03-06,,,15,"HSBC savings",
111,2019-03-06,,9.8788,,"cash, EUR",

If the multi-currency transfers were imported as specified, that would be
perfect. What happens instead is this:
<http://gnucash.1415818.n4.nabble.com/file/t377766/VlTCdLQ.png> 

The Cash EUR, €10 -> Cash BAM, KM19.59 transfer imports both splits (10 and
19.59) but adds additional records so that the end-result of the transfer
turns out to be 10:10.

The HSBC, $15 -> Cash Eur, €9.88, does something similar, adding "only"
€0.97 to the destination account.

I'm not sure why these happen and would appreciate some feedback before
reporting it as a bug. 

My suggestion, as written above, would be simply to leave the multi-currency
transfers as-is. There is really no way to tell if they match due to the
Price element. 
However, if the price is taken into account, then perhaps the Price field
may have some role there?



--
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] Transactions vs Splits

[cicko]

OK, now I see that I'll need to use the Multi-split option always, to cover
for the eventual real multi-split in the source. So, I'll be focusing on
that option.
The good news is, when multi-split is selected, the Transaction ID field
becomes available for mapping. That helps a lot as the matcher will know
which splits to group together into a transaction.


David Cousens wrote
>>I see that, with Multi-split checked, I can no longer select the Transfer 
>>Account destination field. This is a dead end for my current approach,
> using 
>>Transfer Account. 
> 
> With a multisplit multiline record there should be no need. GnuCash should
> interpret the following lines as transfer accounts

Oh, I think I'm getting the idea. In this case, the splits rows represent
exactly what will end up in GnuCash and need only one Account per split.
Yes, that makes sense. 


David Cousens wrote
> I suspect the mismatches you get are a problem with GnuCash not
> interpreting
> the multiline splits correctly. 

Nah, I believe this is because I was still using the
one-split-one-transaction approach in writing CSV.


David Cousens wrote
> The account selection in the first window is AFAIK intended to select an
> account for all transactions to be imported into. ...

This part I believe I now understand and agree with you, except



The notation transfer account is not one as an accountant that I really
like. It only makes sense when transferring funds between two  asset (or
liability accounts) but many software developers and users have adopted it
so it is now part of the language. My view of a transaction is that it
consist of two or more splits each of which has a target account which is
debited or credited by that split.


David Cousens wrote
> Where the multiline capability comes into its own is in dealing with
> transactions with 3 or more splits and it really only needs to be used in
> this case.

Now that I understand how Multi-split are supposed to work (I still need to
confirm it in practice), I find the multi-split a better option always, as
one can specify the Transaction Id and explicitly tell GnuCash which splits
go together.
So, as I mentioned at the top, I will probably use that as the default,
unless I run into some other issues.

If this works as expected, then multi-currency transfers should not be an
issue at all. Each split would specify the amount so no need for GnuCash to
fiddle with prices. 
I will test this as soon as I adapt my code to always produce multiple
splits instead of using Transfer Account.



--
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] Transactions vs Splits

[cicko]

This helps:

 




--
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] Transactions vs Splits

[cicko]

Thanks a lot, David. I have completely missed that checkbox. Will try it out.

Also, to comment on your reference to single- vs multi-split import. I saw
the Transfer Account field available and decided to use it from the start.
That way I don't need two splits for simple transactions, meaning this is
quite suitable more category-like approach, not double accounting. Single
CSV rows match what is available though QIF, for example. Hence I'm not even
trying the case that you describe, and I guess completely skipping the
matcher for two split rows in one transaction.

My test records look like this:
date, description/payee, deposit, withdrawal, account, category/transfer
account
2016-01-27,"Falafel",,4,"cash","Food:Dining out"

This fits more to my source schema. Note that I'm writing a library that
will allow me to pull records from MoneyManagerEx database, which is based
on categories.

I see that, with Multi-split checked, I can no longer select the Transfer
Account destination field. This is a dead end for my current approach, using
Transfer Account. 
At the last screen, I now get all mismatches as the destination account is
missing and I'm prompted to select one. This makes no sense as I could have
simply selected that at the first screen and save my matcher schema.
Should I raise this as a bug or am I misunderstanding how this is supposed
to work?

Thanks a lot for your assistance. Note that there's also no rush from my
side. For me, this is a hobby project that will, in the end, save me some
time in automating the transaction transfer from my phone app to GnuCash. So
don't feel pressured on that end, either.



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

[GNC-dev] Transactions vs Splits

[cicko]

What is meant by "multiline" in this case?

I've tried importing a CSV file with multiple records and it seems to be
going fine.
However, I'd like to keep the split structure in place but am not sure if
that is possible. Currently I create rows for each split in a transaction
and so it makes sense that they are imported as separate transaction in
GnuCash.

Is there a way to keep splits within one transaction during the CSV import?



--
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] CSV Import Format

[cicko]

Thanks, David.

I can confirm that a multi-currency transfer uses the same amount on both
sides. I did not check the Trading Accounts but assume that works just fine.

Reading your document gave me a few ideas, however. I might try sending both
Deposit and Withdrawal columns together. Or calculating the exchange rate
and sending it as the price in transfer splits.
My (future) test case is here:
https://gitlab.com/alensiljak/pymoneymanagerexdal/issues/4



--
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] CSV Import Format

[cicko]

A brief update from my side, as well. I've spent a few hours adding code to
my export library and CSV generator. 
At first, I've exported the tranfers and that seemed to have gone well.
However, as in my test file I had at least four different currencies, I
switched back to simple transactions. Importing withdrawal transactions with
one split each works as expected.

I'm using the following format for export:
f"{date},{description},{deposit},{withdrawal},{account},{transfer_account}"

Next on my to-do list are multi-split transactions, and multi-currency
transfers. I see that David is making more progress, which is great.
I've also added some basic info to
https://wiki.gnucash.org/wiki/CSV_Import/Export.



--
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] CSV Import Format

[cicko]

Thanks a lot for this useful info, David. I'll keep in mind the possible
issues with transfers, multiple accounts, and currencies during this
exercise. Once I am happy with the code, I'll probably add my findings to
the wiki. In the meantime I'll be on the lookout for the results you get
with the import testing.
Cheers



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

Re: [GNC-dev] CSV Import Format

[cicko]

Oh, I wrote too soon. 
Only now, that I have some .csv output, do I see the new screen for mapping
the CSV fields. Wow, this should be enough to create any type of custom
mapping so the CSV field order doesn't really matter as long as all the
useful values are there. 
Cheers for that rewrite!



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

[GNC-dev] CSV Import Format

[cicko]

Hi, everyone,

Could you recommend a place that contains the current description of the
optimal CSV format for smooth import into GnuCash? Or perhaps just a few
tips?

So far I've been importing .qif files from the Android app and I was
wondering if importing .csv files would be easier with the rewritten import
code.
I'm writing some scripts/libraries in Python to pull the data from the
sqlite database and write to .csv file(s), ready for import to GnuCash. 

That way I should be able to move the transactions from the phone, which
synchronizes the database to the cloud, to the GnuCash book. 



--
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] AppImage

[cicko]

Thanks a lot, Geert! This is just for my own amusement at the moment, and
potentially for filing bugs if I run into any issues on my system. I hope to
have time to try it out sometime this week.



--
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] AppImage

[cicko]

Great! Could you point me to where I can find these, please? I'm happy to try
them out.



--
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] AppImage

[cicko]

Someone actually created an AppImage repo for GnuCash at
https://github.com/ecmu/gnucash.AppImage

It seems pretty fresh. The release available there is 3.4. The title says
"Continuous Build", and it builds to the latest (.tar.gz) released sources.
It looks a bit funny, probably minor GTK issues. It crashed once on opening
the sqlite database so beware. But, in any case, it's there! :)




--
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] Gtk and themes

[cicko]

Adrien Monteleone-2 wrote
> In the meantime, making the app work correctly is certainly more
> important, as is re-working the code base to eventually facilitate a move
> to an MVC pattern that might facilitate easier visual customization, or at
> least more native platform integration to remove the occasion for the
> requests.

Well, I wholeheartedly agree on that one. Even just getting the data store
to be a clean relational database would help immensely in providing a solid
base for alternative UIs (like web, mobile, etc.).
For example, I'd be happy to experiment with NativeScript and create a basic
app that could post, or at least read, the transactions from the book on
both mobile platforms, or something along those lines, but I'm still
reluctant to generate any transactions from outside GnuCash.



--
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] Gtk and themes

[cicko]

Geert Janssens-4 wrote
>> Well, I'm fairly confident that it is exactly the opposite. Just looking
>> at
>> trends in mobile apps tells me that clearly the users want to customize
>> the
>> apps to their preferences, mostly visual, rather than to have "more,
>> better
>> app" (whatever that means).
> 
> Interestingly I'm not aware of visual styling customizations in any of the 
> mobile apps I use. They all seem to use the system's theme(s). I don't
> find 
> options anywhere related to, hmm, I'd like a different font for this menu
> item 
> or hide the label for that button, and oh, can the spacing between these
> two 
> fields be reduced a bit ?

Right. But choosing a different theme is a kind of visual customization, no?
Not to mention the icon packs, custom emojis, and what not. That, of course,
depends on the apps you use but I'm talking about a huge deal where I read
"visually pleasing" and "easy customization" in the description and move on.


Geert Janssens-4 wrote
> The point I wanted to make by posting this article is really this:

I think I get your point and actually agree with it, along with the point
the guy was making in that article. But I'm a developer and I've noticed
that my view is quite different to that of an average user.

My point, on the other hand, would be - the users want customizations and
that won't change anytime soon. And you can confirm that simply by
considering the amount of questions on this list referring to fonts,
spacing, colors, sizes, icons, etc. 
Unfortunately.



--
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] Gtk and themes

[cicko]

Thanks a lot for the link, Geert. 
Unfortunately, I think the root of the problem is this: "If given a choice
between customization and more, better apps, I’m confident the majority of
people would prefer the latter."

Well, I'm fairly confident that it is exactly the opposite. Just looking at
trends in mobile apps tells me that clearly the users want to customize the
apps to their preferences, mostly visual, rather than to have "more, better
app" (whatever that means). Also, the users clearly do not want more apps
that do more-or-less the same thing. Well, that just promises that the
debate on the topic will continue be going on, at least for a while. :)



--
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] webkitgtk

[cicko]

Also update from my side:

https://gitlab.com/alensiljak/python-gui/tree/master/webview-server

Here I have two scripts pywebview and pywebview-qt. I can confirm that,
using the webkit2 branch of pywebview, both versions run on my system. So,
webkit2 seems to be used successfully.
So, Christoph, you may try using pywebview as a wrapper, if needed. That
way, at least, there would be less changes to make in the client code, I
hope.



--
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] webkitgtk

[cicko]

John Ralls-2 wrote
> No, pywebview will never support WebKit2Gtk because WebKit2Gtk is Gtk3
> only and pywebview, like pygtk, is Gtk2-only. You need to rewrite your
> whole application for Gtk3 using pygobject.

You may well be right but do check out this branch:
https://github.com/r0x0r/pywebview/tree/webkit2

Yesterday my time limit for investigation expired before getting to it so I
might continue with this on the weekend. Qt5 version, however, works fine so
I might as well not spend additional time on it. The browser window opens
from Python code, which is good enough for me. 
On Windows, the example with running Flask in a separate thread and
connecting to it from the client works fine. If the same happens on Linux
and Android, then I might as well proceed in that direction.

Thanks for the comments.




--
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] webkitgtk

[cicko]

Ah, that's from the period before I was born, then. :)

Thanks for the pointers! I found out some of that in the course of the
night. These packages are installed but the trick is that pywebview does not
(yet) support WebKit2. In the meantime, I'll be using the Qt5 version.
The more I learn about the options available, the more I wish GnuCash was
moving to Python, not C++. :)
It seems that Qt5 UI can be packaged for Android. And pywebview might also
work as a client (with Flask server).

Cheers



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

[GNC-dev] webkitgtk

[cicko]

I was trying something out with pywebview library in Python, ran into some
issues and found that python-webkitgtk
(https://software.opensuse.org/package/python-webkitgtk) package has been
removed from openSuse.

But that's just the beginning. The webkitgtk package itself is being
removed, as can be seen in
https://bugzilla.opensuse.org/show_bug.cgi?id=1055659.
I guess/hope you are aware of the fact that gnucash is one of the few
dependencies listed at the bottom of that issue.

My real question, though, is what will webkitgtk be replaced with? It's a
web view component and I'm looking for an alternative for my pywebview app.
Well, one real alternative for me is to use Qt, which is also supported by
pywebview on Linux. I'm also wondering what is the solution for gnucash in
general.




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

[GNC-dev] Windows installation size, nightly

[cicko]

FYI, a couple of days ago the installation size for Windows nightlies jumped
from 95 to 157 MB. A significant increase for what I hoped were the new
features. ;)
Just a quick question on whether this was intentional and/or if the size can
be brought back down again.

https://imgur.com/Uga1ckd

Cheers



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

Re: [GNC-dev] Python: About Wrapping SWIG Objects (GncNumeric)

[cicko]

Christoph Holtermann wrote
> I'm willing to now and then do something for the python bindings. I 
> don't feel like an expert. But surely I'd like to talk and think things
> through 
> about them. Maybe someone is interested. I saw that there were some people 
> asking questions about the bindings on this list. Maybe they don't commit
> but 
> still work with the bindings. So my question remains and maybe someone has
> an 
> idea.

Christoph,

I, for example, am quite interested in accessing GnuCash via Python. So, on
first sight, Python bindings seem an interesting option.
In practice, though, I did not find much motivation to spend time on it,
unfortunately. The main reason for that is that I need my (Python) code to
run on Windows, Linux, and Android. And to run equally well.
Since the bindings are available only on Linux, that's a very limiting
factor. So I've limited my work to only reading the GnuCash data. Additional
functionality is dispersed across various small projects that keep extra
information in their own databases (i.e. Asset Allocation). This works well
on Android and I can get my Portfolio Value report or Security Analysis by
running a Python script on my phone (sounds weird, I know).
To run on all platforms I'm using Sebastien's Piecash library.
Additional step would be to add some sort of (native) GUI on all the
platforms. I've already looked into that a bit, but nothing tickles my fancy
yet.

Having the ability to write data to GnuCash would be fantastic. However, I
don't think it's going to happen on multiple platforms any time soon.
Naturally, it is possible to write to GnuCash database but that is not
exactly the same as using GnuCash's business logic.

One thing I would like to improve on next is the process of getting the
transactions from the mobile app (MoneyManagerEx for Android) into GnuCash.
Python bindings would be perfect for that, to avoid lengthy process of .qif
import. I could adapt the Android app to provide GnuCash-specific export
file, for example. But if this would work only on Linux, it would be a very
small return on the investment of time and effort. 



--
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] GnuCash Bugzilla URLs -- /bugzilla or not?

[cicko]

Excuse me for jumping the thread but I'd just like to mention that there is a
similar situation with wiki:

https://wiki.gnucash.org/wiki/Backup

There is a redundant "wiki" sub-domain / application path combination.




--
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] AppImage

[cicko]

John Ralls-2 wrote
> None of the core devs have had time to look into application bundles for
> Linux. Since the Windows and Mac bundles also have pretty much all of the
> dependency libraries and associated data in them I imagine that a Flatpack
> or similar would run to about the same size, 120-180MB. 

Great. I've opened a request / discussion thread at
https://bugzilla.gnome.org/show_bug.cgi?id=796019.

I think this might be a convenient option as quite a few users have
mentioned that they can't find a current version of GnuCash in their
distribution repositories and need to build it themselves. While I have
nothing against building software, I find it unnecessary for an ordinary
user to download development tools and libraries. Especially now that a few
technologies exist to allow convenient binary packages. In any case, the
topic is open. Let's see if we can get something rolling automatically.



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

[GNC-dev] AppImage

[cicko]

I just learned a bit more about application packages (AppImage, Snap,
Flatpak) on Linux after downloading KeePassXC image and find them quite
convenient. 
Nabble does not find anything if I search for AppImage so I'd like to see
you opinion about using one of these for distributing Linux version of
GnuCash. I've only used AppImage so far and it works fine. Apparently it
would work on any distribution because all the libraries are packaged with
the executable.
If this was applied to GnuCash, would the distribution size be much larger?
Has anyone tried?
Even though I'm on Tumbleweed, a rolling OpenSuse distribution with the
apparently latest software, GnuCash 3.1 is still not available as a
compatible rpm. Somehow, the distribution of software for Windows still has
the upper hand in terms of being easy and simple. At least for the end
users.
Having an AppImage of the latest GnuCash would, I guess, enable all Linux
users to have the latest binary version without needing to build it
themselves and/or depending on multitude of development tools and libraries.

Is there anything preventing building and packaging the latest (either
stable or nightly) version of GnuCash in this way? Have you thought about it
before? Have you tried it already? What were the findings?

Cheers



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

Re: [GNC-dev] GTK3 CSS Active Row

[cicko]

As it often happens, the solution was quick to find only after the question
was posted.
This works well:

*.register-cursor {
color: blanchedalmond;
}

Here is a gist that adjusts this for a dark theme (still can't add new urls
to the wiki):
https://gist.github.com/MisterY/15ea50fee571865ca9efd8c5437a1713



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

[GNC-dev] GTK3 CSS Active Row

[cicko]

A quick question in relation to GTK3 customization
(https://wiki.gnucash.org/wiki/GTK3). 

I've applied an existing dark theme and that covers general GTK elements.
One issue I have now is that the selected/active register row keeps the dark
text but gets the dark background from the theme.

Does anyone know which selector would apply to the active row in the
register (only!)?

Selectors like "*.register-foreground" work but they affect all the text in
the register (all the rows and headers).

cursor entry {
color: orange;
}
also works but affects only the cell where the cursor is. I've tried just
"entry" but that did not do anything.

Thanks!



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

MMEX Android Currency Filter

[cicko]

FYI,

In case somebody is using MoneyManagerEx for Android. I'm just adding the
currency filter in the search parameters, which would allow exporting .qif
files per currency.
This should be in Beta release tonight and would make transfers from a
mobile device into GnuCash easier as currently the import handles only one
currency per file. (Haven't tried yet the new import in 2.7).

Cheers



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

Bugzilla Migration

[cicko]

I guess that by now you've all seen the notification of the issue tracker
migration to GitLab?

https://mail.gnome.org/archives/desktop-devel-list/2018-March/msg00023.html

Probably I have missed any discussion about that in the past so I'm just
assuming GnuCash issues will get migrated to GitLab in one of the next
batches.



--
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: 2.7.6?

[cicko]

Ah, no worries. Got it from Sound Forge. :P



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

2.7.6?

[cicko]

John, 

I was going to try 2.7.6 at my home PC but I no longer see it on GitHub
releases. Has it been taken off?

Cheers,

Alen



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

Transaction Associations

[cicko]

Hi!

Just ran the still-hot 2.7.5 and noticed an interesting option - Transaction
Associations. While there may have been discussions in the past, could
anybody shed some light into the concept?

I assume this opens up a range of options. One of them could lead to
replacement of the current implementation of lots, matching buy vs sell side
for commodities. Another option might be to link broker charges to a buy
transaction in case they were recorded separately. 

I wonder what the foreseen usage scenarios are, will there be an immediate
implementation for some specific purpose, and would just like to see some
thoughts on the topic. 
Cheers!



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

Re: Future allocated money, aka Envelope Budgeting

[cicko]

cicko wrote
> A quick question, though - what do you guys use to have an up-to-date
> records in ledger? How do you use (or export) GnuCash book into text files
> appropriate for ledger?

Looks good so far. At
https://www.ledger-cli.org/3.0/doc/ledger3.html#Major-Changes-from-version-2_002e6,
a feature "GnuCash file import" is listed. I guess this implies the XML
file?
Hopefully, with a bit more searching, it turns out that there is also an
sqlite adapter. :)

It is also great that there is the Python interface
(https://www.ledger-cli.org/3.0/doc/ledger3.html#Extending-with-Python).
Hopefully my work on portfolio project will turn to be more of a process of
discovery of what ledger does. :) And then adapting it and presenting in a
way I'd like to have.



--
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: Future allocated money, aka Envelope Budgeting

[cicko]

GnuCash - Dev mailing list wrote
> for e.g. I am, at the moment, in the process of doing my multiple view 
> portfolio analysis starting from
> 
> https://www.ledger-cli.org/3.0/doc/ledger3.html#Asset-Allocation
> 
> which is more or less what envelope budgeting is plus a bit.
> 
> see
> 
> https://www.ledger-cli.org/3.0/doc/ledger3.html#Working-with-multiple-funds-and-accounts

Thanks a lot for these links! I was not aware that ledger had asset
allocation.
This might save some effort in writing gnucash portfolio extensions
(https://github.com/MisterY/gnucash-portfolio). Perhaps I could even
interface to ledger-cli or another ledger client from Python.

A quick question, though - what do you guys use to have an up-to-date
records in ledger? How do you use (or export) GnuCash book into text files
appropriate for ledger?

Now I'm thinking how good it would be to have a translation layer that
provides the data from a GnuCash sqlite database to ledger.



--
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: On development/release processes and version numbers

[cicko]

Looks like a start of an interesting discussion.
I'll chip in just a few drops at this time and won't repeat myself in terms
of personal preferences for the version numbers because there are other
concerns to take into consideration there, as well.

The release management need not necessarily be tied to the development and
code branching strategy. Here is an interesting model that I've tried to
emulate in practice but never got as far as having the full spectre of
branches in a repo (mostly because I never had git in professional projects
and Open Source ones are fairly small for the full model :'( ). It is
interesting, nonetheless, to read into it and utilize the ease of switching
and merging branches git provides.
http://nvie.com/posts/a-successful-git-branching-model/
In brief, you could still have two main branches: unstable and stable. There
are numerous other branches in practice. The feature branches merge to
unstable, while hotfixes merge to stable branch. In this model, master is
the stable branch, the mirror image of the GnuCash branch stability, but the
practical difference is just in branch names. The code flow is likely still
the same. What I find quite practical with git is that there can be lots of
active branches that span from the main two - unstable and stable - and are
used for new feature development or bug fixes.
An opposite, perpendicular approach would be a branch per version number.
This model is more oriented towards end-users and, in my opinion, makes more
sense for large providers with a large and profitable user base. This seems
very demanding on the development team as well as the release management
process.

As far as product management goes, with release version numbers, there will
be lots of factors, I guess. As you mentioned, supporting certain versions
in order to follow other vendors' policies might be one. But, politics
aside, what I find practical for the release schedule GnuCash follows at the
moment, is to have the version numbers still provide the information with
semantic versioning but not necessarily providing much overhead in terms of
maintaining the code branches. What I mean is, the numbers increase like on
a measuring device. The third number (bugfix) releases happen only until the
next minor version comes out. Then this becomes the latest version and
bugfixes are release only for this version. I.e.
- you do some work -> release 1.0.0
- features are being developed in feature branches
- bug found. Release goes out, not waiting for the features to be complete.
-> 1.0.1
- one feature complete -> 1.1.0
- another bug fixed -> 1.1.1
- big feature complete -> 2.0.0
- another bug fixed -> 2.0.1
and so on.
There are several aspects here. Once a minor release is out, the maintenance
is only done on that latest release, not on any of the previous ones. Users
are expected to upgrade because there are no breaking changes involved.
Releasing a major version might be a different story but in the simple case
everything goes just like with minor version. Whether and for how long the
previous versions are supported in practice depends on several factors:
- the amount of development overhead and effort in maintaining the previous
releases,
- the amount of time/effort that goes into testing the future releases
(meaning how stable they are in their x.0.0 version).
Maintaining several active versions requires decent amount of testing of
*all* of them and I am not a big fan of that scenario. That grows the
efforts exponentially while providing a questionable result. You'll have to
weigh on whether the results are worth the effort.

The versions also do not need to be scheduled, although that's a nice touch
when I look from the end-user's perspective. You could simply release
whenever there are some updates. This gets both the features and bug fixes
into production faster. Which is not necessarily always a good thing. 

These are just some observations that may or may not apply to GnuCash. But I
always enjoy the discussion about these matters. :)



--
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: Capital Gains FAQ entry

[cicko]

Hi, David,

Thanks a lot for the insights on GnuCash documentation in general!
The Guide was, for a long time, my main reference to GnuCash. That is, until
I started scratching the surface and look for more details on how to some
"dirty" work after switching to GnuCash, or after running into some
unexplainable issues that I considered bugs. Especially after I started
writing some tools and views I was used to but are missing in GnuCash at the
moment.
Thanks to Google, we can now access pretty much any piece of text ever
published about GnuCash and that certainly does not help one get around. :)
Additionally, if you look at the paragraph on the main wiki page under
"Getting involved in the GnuCash project", it clearly states that the Wiki
is to become The one and replace everything else. Statements like that
create certain expectations on the side of the reader, just like the text
about Lots. I, as a reader, create an image of GnuCash in the order of the
information I receive, not necessarily in the order it was written. 

>From the technical perspective, I'd prefer wiki just for the simplicity of
access and editing. This would require someone to police and edit the
contributions, of course, as well as arrange them by the application version
number they apply to. Not an easy task, I know. However, I hope that the
agility provided by wiki would work for a hobby project.

In any case, the main point is -yes - I thought that the Uservoice link
would be helpful on the main www.gnucash.org page, if it officially accepted
way of providing suggestions and voting on them. 

Alen



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

Wrong link in docs

[cicko]

In the documentation, page  Lots in Account
  , the link
in the following sentence:

"See Tutorial and Concepts Guide, Automatic Calculation of Capital Gain or
Loss Using Lots for more details. "

points to a non-existing page. Is this something that should go to bugs or
is a notification here enough?
Cheers 



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

Re: Captcha error on wiki

[cicko]

I can confirm that editing URLs works now.

@John, BTW, I'm not sure that the content of the linked txt file always
matches the message of the sentence in which it is referenced. At the top of
the page, I added the new link to the architecture article which explains
the concept and the reasoning behind the current implementation of the Lots.
It has more narrative than the first text file, which is more the API-style
documentation. 



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

Wiki down?

[cicko]

Hi,

The wiki site seems to be down and there is no related announcement. Is it a
planned downtime?

Alen



--
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: Boost/Python

[cicko]

Success!
At least a limited one. I've assembled a small demo - retrieving the GnuCash
version from core-utilities.

https://github.com/MisterY/gnucash-portfolio.net

Some more prototyping needed, mostly in mapping the unmanaged types to
managed.

I'll try this approach first, before setting up a whole dev environment on
Linux, building the custom version of GnuCash, etc. I'd rather focus on the
higher-level functionality for the moment, relying on production GnuCash
libraries. 
My goal is to have a few working tools, like upcoming transactions reminder.

Last weekend I've set up a Raspberry Pi server. Now I'm thinking this could
be my reminder provider, having a synchronized copy of GnuCash db, or
something like that. A mobile app could read/cache the reminders. 

Even better, I could try to publish the reminders as an .ics and have them
as an additional calendar on the phone.



--
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: Boost/Python

[cicko]

Thanks a lot, John! 
I'll read more into this. I'd hope for some sort of wrapper on top of the
already compiled binaries. Was hoping that these Python interfaces would do
something like that. Which makes me wonder why the bindings currently don't
work on Windows. I don't know much about the inner workings of this part at
all.

The ability to read c/c++ dlls directly from c# makes it another interesting
multi-platform option. It's supposed to work well on Linux by now. I might
explore that route into more details over the weekend. 
I tried it before but the thought of rewriting the data access layer threw
me off a bit and Python seemed like an easier approach for a hobby project,
considering there is PyCash, which provides the complete GnuCash data model. 
Now that direct access to GnuCash libraries looks possible, I might tap
directly into the real engine and, for example, get the list of scheduled
transactions with next due dates, instead of writing a parallel logic for
this elsewhere.

Hopefully this turns out to provide enough access to create some sort of
prototype (.net is my main professional development platform, btw). Then it
would be a fairly simple thing of exposing it over HTTP endpoint, which is
what some have been asking for on the lists. I'd also prefer a HTTP UI as it
also opens the door to mobile apps as well.



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