Re: [GNC-dev] AppImage

[Alen Siljak]

That's great news!
I've collected the links I found so far to this issue: 
https://bugs.gnucash.org/show_bug.cgi?id=796019
It is now closed since the AppImage is there and there are ongoing efforts in 
getting an official Flatpak image.

> Sent: Friday, January 11, 2019 at 6:34 PM
> From: "Derek Atkins" 
> To: cicko 
> Cc: gnucash-devel@gnucash.org
> Subject: Re: [GNC-dev] AppImage
>
> For the record, we are working on getting a Flatpak build done locally.
> It's on my to-do to set up a "nightly" build.
> -derek
> 
> cicko  writes:
> 
> > Someone actually created an AppImage repo for GnuCash at
> > https://github.com/ecmu/gnucash.AppImage
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] pricedb policy

[Alen Siljak]

He he, just to make things a bit more complicated and realistic:

> Sent: Sunday, May 13, 2018 at 6:42 PM
> From: "John Ralls" 
> To: "Adrien Monteleone" 
> Cc: gnucash-devel@gnucash.org
> Subject: Re: [GNC-dev] pricedb policy
>
> Just get local currency at a bank 

If you're on a weekend trip this won't work most of the time. Especially on 
Sunday in a Catholic country.

>or from a bank’s (preferably indoor) ATM

This means that, once you see something you'd like to buy, you first need to 
find an ATM that won't charge exorbitant prices for currency exchange and cash 
withdrawal. Also, you should use a card provider that doesn't do that.
Even though I had a nice travel card a few times, cash still seems to be the 
king. And exchanged outside the destination country and outside the tourist 
season, if possible. :)

> Make a “cash in wallet” account in the local currency. That will get you 
> better rates and only a few exchange transactions.

I wish all the remaining countries in Europe would start using Euro. That would 
make things so much easier. :D
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] pricedb policy

[Alen Siljak]

I'll add a simple case that maybe does not happen often in real accounting but 
happens to me all the time.

When traveling and exchanging cash at various small shops, the exchange rate 
varies wildly. This, however, should not have the precedence compared to the 
official central bank's rate. Also, what happens when the currency is exchanged 
a few times per day?

These are the negative side-effects of your proposal. It is, however a very 
valid question if the reports are using only one rate.

In that case, I would prefer to be in control of the rate used. 

Another important item is that the Australian Tax Office, for example, 
publishes the official exchange rates for the tax year and I would really need 
to be able to use that rate for all my tax reports, irrespective of what the 
other entered prices may be.

> Sent: Sunday, May 13, 2018 at 12:34 PM
> From: "Christopher Lam" 
> To: gnucash-devel@gnucash.org
> Subject: [GNC-dev] pricedb policy
> 
> My concerns relate to (1) above. I believe these transactional prices are
> always more accurate than online quotes, because they describe the exact
> prices achieved.
> 
> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
> same day, the second entered price will overwrite the first. (<- according
> to my last test)
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3.0 wine versus Windoze 10

[Alen Siljak]

Jeffrey, perhaps a stupid question - why don't you install a native linux 
version of GnuCash instead of running a Windows version under Wine?
I use the same xml/sql book with linux and windows versions interchangably and 
there are no issues (that I can see, at least!). 
Also, just for comparison, Windows version loads my book in ~30 seconds while 
linux version loads the same book in 5. You may even benefit from an increased 
performance.

Versions 3.0 and 2.6.19 are not compatible. Version 2.6.21 should be, though. 
However, can't confirm that 100% as I've moved to 3.0 and it worked ok for me 
so far.


> Sent: Wednesday, April 18, 2018 at 9:40 AM
> From: "jeffrey black" 
> To: "Gnucash userlist" , gnucash-devel 
> 
> Subject: [GNC-dev] GnuCash 3.0 wine versus Windoze 10
>
> Before I do something incredibly stupid, like I did in hard crashing my 
> Windoze server because of a virus (IRS search miss-key, go figure), and 
> the boot partitions seem to be non-repairable even though all data and 
> programs are still on disk.  (And yes, I know stupid of me to not have a 
> current backup).  I still have legacy apps with data stored internally 
> that are not extractable without Windoze and without a reliable backup 
> per partition, per drive, I am not going to touch those drives until I 
> can find a way to recover everything.
> 
> Can GnuCash 3.0 be run under Wine on Ubuntu Xenial?  3.0 has features 
> that I need.  It wants to install on only my Windoze dives which I will 
> not do until I have all of the data extracted. I have been unable to 
> build 3.0 from source code.  (yes I know Mint is a better choice but; 
> until I recover all of the data from Windoze I am not changing, Ubuntu 
> is up and running, Hallelujah, on it's own dedicated drive).
> 
> Second Question:  My laptop still has Windoze 10 home, so can I install 
> GnuCash 3.0 on it and use it with Windoze GnuCash Version 2.6.19 data 
> files on the server files which are still accessible via Ubuntu file 
> share with Windoze 10?  Are the data files compatible?  I have 20+ years 
> of data that I definitely can not afford to loose (think divorce).
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Captcha; was: GTK3 CSS Active Row

[Alen Siljak]

Frank, thanks a lot. Yes, the new captcha works great!

> Sent: Thursday, April 12, 2018 at 4:47 PM
> From: "Frank H. Ellenberger" 
> To: cicko 
> Cc: gnucash-devel@gnucash.org, "Derek Atkins" 
> Subject: [GNC-dev] Captcha; was:  GTK3 CSS Active Row
>
> The Captcha should now be fiexed. can you test it?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Feedback about 2.7.8

[Alen Siljak]

Thanks for the info, Adrien.

So far I managed to paint most of the application dark by using the * selector 
only. It is a bit draconian but things are dark, alright.
Hopefully we can figure out additional selectors for borders and other elements.
The example css for register is a good start for that part, too. 

I haven't yet spent much time on this but hopefully more of us can chip in and 
add any related info to the GTK3 page. 
Please do add any links and tips you find. I'll use the info on the page once I 
get to spend some more time hacking around the styles.

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

Re: Feedback about 2.7.8

[Alen Siljak]

The recommended link for upgrade info:

g.co/recaptcha/upgrade


> > > - captcha
> > > Captcha on wiki reports that the v1 is to be deprecated soon.
> > 
> > Where do you get this ? I don't see this when logging in to our wiki or 
> > editing pages. Perhaps because I'm a developer ?
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Feedback about 2.7.8

[Alen Siljak]

> Sent: Thursday, March 29, 2018 at 10:16 AM
> From: "Geert Janssens" <geert.gnuc...@kobaltwit.be>
> To: gnucash-devel@gnucash.org
> Cc: "Alen Siljak" <alen.sil...@gmx.com>
> Subject: Re: Feedback about 2.7.8
>
> Op donderdag 29 maart 2018 10:00:25 CEST schreef Alen Siljak:
> > A few questions/suggestions:
> > 
> > - captcha
> > Captcha on wiki reports that the v1 is to be deprecated soon.
> 
> Where do you get this ? I don't see this when logging in to our wiki or 
> editing pages. Perhaps because I'm a developer ?

I think the captcha only appears when adding new external links. 
It is being deprecated on 31st of March!

Thanks for the other suggestions. I'll add them to the wiki page. 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Feedback about 2.7.8

[Alen Siljak]

Soon as in the day after tomorrow! 
(just read the warning message again)

> Sent: Thursday, March 29, 2018 at 10:00 AM
> From: "Alen Siljak" <alen.sil...@gmx.com>
> To: "David Carlson" <david.carlson@gmail.com>
> Cc: "GNUCASH devel" <gnucash-devel@gnucash.org>
> Subject: Re: Feedback about 2.7.8
>
> A few questions/suggestions:
> 
> - captcha
> Captcha on wiki reports that the v1 is to be deprecated soon.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Feedback about 2.7.8

[Alen Siljak]

A few questions/suggestions:

- captcha
Captcha on wiki reports that the v1 is to be deprecated soon.

- gtk3 page. 
I've created a Wiki entry for GTK3 with the main idea being sharing tips about 
customization - https://wiki.gnucash.org/wiki/GTK3. This is also related to the 
issue https://bugzilla.gnome.org/show_bug.cgi?id=791823. Having a sample of a 
customizes CSS file would be a valid workaround. My main goal is to get the 
adawaita dark theme on Windows machine.
Let's add any tips, findings, including links to valid .css theme 
configurations (which could be elsewhere, i.e. gist; there are also whole sites 
dedicated to gtk3 themes so I'm gonna try to copy adawaita dark css directly).

- list of ids
David is correct, pointing to the important question raised by Adrien. However, 
I'd think that the sample GnuCash css files would answer that, at least partly. 
I'll write down my findings into the wiki page as I'm darkening the UI.

- variables
And, related to the above, I'm wondering why are there @ variables in the 
GnuCash css files. Is this .scss or are they replaced elsewhere? I've seen 
[this](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables) 
even though I've never used it.

To answer a part of Adrien's question - see the gtk overview 
(https://developer.gnome.org/gtk3/stable/chap-css-overview.html), the first 
code entry, example 7. It sets the font to Comic Sans and paints it pink. 
I've created the gtk-3.0.css file in C:\Users\siljak\AppData\Roaming\GnuCash, 
added the example 7:

button, entry {
  color: #ff00ea;
  font: 12px "Comic Sans";
}

and the entries in the account list header and footer became pink. The font 
setting did not work but at least there are some signs of life! :)

Cheers

> Sent: Thursday, March 29, 2018 at 12:53 AM
> From: "David Carlson" 
> To: "Robert Fewell" <14ubo...@gmail.com>
> Cc: "GNUCASH devel" 
> Subject: Re: Feedback about 2.7.8
>
> Neither of those sample .css file addresses Adreien's question
> 
> " Is there a class/id list for the GnuCash UI so we can know what’s
> available to style? Or are those listed in the sample file the only ones
> available? (I’m also assuming other properties can be set, for example
> font-size in addition to color, etc. or is this not possible?)
> "
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Feedback about 2.7.8

[Alen Siljak]

> Sent: Wednesday, March 28, 2018 at 3:46 PM
> From: "Christoph R" 
> To: gnucash-devel 
> Subject: Feedback about 2.7.8
> But I can change the description of a reconciled split without a warning. I 
> need to file a bug report on that.

Chris, I'm just wondering - why would a change of description require 
re-reconciliation? 
Somehow, I'd expect that the date and amount are the relevant fields. The 
description is something for me (the user) to add notes about the transaction 
and is basically irrelevant for anyone else, therefore not requiring 
re-reconciliation with another account statement (i.e. bank or credit card 
statement). Just wondering what your case is.

Cheers,

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

Re: [PATCH] Switch to python 3

[Alen Siljak]

Thanks for the consideration, John. I'm happy to push for adoption of Python 3 
and use that exclusively (as I'm fresh in the Python world). 
Sebastien might still be supporting v2 in some projects so let's see what he 
has to add.

> Sent: Friday, March 16, 2018 at 3:26 PM
> From: "John Ralls" <jra...@ceridwen.us>
> To: "Julian Wollrath" <jwollr...@web.de>
> Cc: gnucash-devel@gnucash.org
> Subject: Re: [PATCH] Switch to python 3
>
> For further discussion here, though, particularly for Sébastien de Menten and 
> Alen Siljak: Is it OK to convert to Python-3 only or should the bindings 
> support both Python-2.7 and Python-3
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Alen Siljak]

> Sent: Tuesday, February 13, 2018 at 8:13 AM
> From: "Wm via gnucash-devel" 
> To: gnucash-de...@lists.gnucash.org
> Subject: Re: price.date, transaction.post_date and neutral time
>
> That is interesting.  There has been quite a lot of enthusiasm for 
> mobile / gnc interaction.  Have you written about this before and I 
> missed it ?  If MMEX for Android is working well with gnc I think you 
> should make a wiki entry and ignore my view on MMEX as an accounting app.

Done. https://wiki.gnucash.org/wiki/GnuCash_and_Mobile_Devices

> Aside: I am completely confused how MMEX for Android could be used for 
> Asset Allocation, MMEX doesn't understand Assets and Liabilities and 
> Equity!  Looking at the forums, the dev's of MMEX haven't realised that 
> prices aren't available from Y! any more, etc.  Crazy.  If the MMEX for 
> Android app is moving beyond MMEX itself and may be working better with 
> gnc then please let us know,

It's very simple really. MMEX schema supports Asset and Investment accounts. 
For me, AA is really very simple: 

- we set the allocation. I.e. 10% stocks, 90% bonds.
- we enter the investments we own, i.e. Stocks Fund, Bonds Fund, Direct Bond, 
favorite company ABC stock, etc. 
- we link the investments (by symbol) to the allocation classes above.
  Stocks Fund => stocks
  Bonds Fund => bonds
  Direct Bond => bonds
  ABC => stocks
- we get the latest prices

All that computer software needs to do (and, deep into 21st century this is the 
least I'd expect my personal finance app to do) is to calculate the current 
value of the holdings, therefore asset classes, and say:
"you have 50K in investments, out of which 30% is in stocks and 70% in bonds, 
while your allocation is 10%/90%".

> Asset Allocation is indeed simple, the problem is that no two people 
> agree on how to do it :)
> 
> Further, most AA models are USA biased, I don't think gnc needs any more 
> USA bias and any model that includes a stock allocation along the lines 
> of "domestic / foreign" is rubbish if you live outside of the USA so 
> let's not go there! [1]

OK. This is an interesting distinction. Are we talking about AA as a concept or 
a concrete AA implementation (values)? This is kinda class/instance 
relationship. I'm strictly interested in providing a tool that allows working 
with AA as a concept, and leave the actual implementation to the user. They can 
work out their allocations in any way they prefer but the tool should be 
accessible and use the portfolio data from a GC book.
Just like a text editor, it does not tell you how to write but lets you write 
some text, save it, view/edit it later, and share it with someone else.

> for a sanity check, I am certain the good people that maintain the code 
> that allows us to get prices do *not* try to maintain a complete db of 
> prices themselves.  there is, quite simply, too much information.

Nobody mentioned a complete db of prices but separating Price information from 
the rest of the book. Prices are expendable and, as you say, can be retrieved 
independently. As they are independent of a book, they can be shared across 
multiple books and/or applications. Which is where I'm coming from. And price 
information is pretty much the same for any application. It has basic 
properties of Date(/Time), Symbol, and Value.

> you haven't been looking, there are hundreds of AA implementations, 
> maybe you mean you haven't found many that agree with your 
> preconceptions ? AA is often about preconceptions.

Good advice. I see a few implementations, thanks to Python being so accessible. 
However, it seems that most of them are dealing with calculating an optimal 
allocation rather than letting the user manage it, the way ledger-cli (or MMEX 
4 Android) does.

> Heh, you just outed yourself as a bad trader :)  A "good" trader doesn't 
> care about capital gains :)

I don't really. But I have to report on it to the tax authorities every year. ;)

On a side note, I'm pretty amazed how few people are interested in AA 
considering that they are the masters of their own fortune in countries with 
private pension funds. In countries like Australia, each person is responsible 
for choosing their superannuation fund, including the asset allocation.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Alen Siljak]

> Sent: Monday, February 12, 2018 at 7:34 PM
> From: "Wm via gnucash-devel" <gnucash-devel@gnucash.org>
> To: gnucash-de...@lists.gnucash.org
> Subject: Re: price.date, transaction.post_date and neutral time
>
> On 12/02/2018 14:27, Alen Siljak wrote:
> > I am currently separating the Asset Allocation logic into its own
> > Python package, for direct use (cli) and potential library reuse
> > between GnuCash Portfolio and an Android app (perhaps an add-on for
> > MoneyManagerEx or who knows where it leads).
> 
> MoneyManagerEx is single entry and will never get approval in the double 
> entry community.  I like they way they do reports, but their 
> understanding of accounting is broken.

True but, as a maintainer of MMEX for Android app, I have already implemented 
Asset Allocation module there. The mobile app served me well for years by 
providing transactions in .qif files, which GnuCash also handles well. So, it 
remains my mobile app of choice for the moment, in combination with GnuCash.

What I would like to do, is extract the AA logic from the app, implement in 
some platform-neutral way (python?) and use on desktop and mobile. Since it is 
not complex, there is no reason for GnuCash not to implement the same concept. 
After all, it simply takes user-set allocation and compares to the quantity of 
the various commodities owned, calculating their current value by using their 
current price. Hence the need to have Allocation and Price elements.

> We spoke about this before.  gnc is a bad platform for trading, end of 
> discussion.

I was not in any way referring to trading but to reusing the price database 
file/schema. But it seems that it would be too much trouble for such a small 
component so nevermind.

> > I'm wondering what the opinion here in the project would be about such
> > an idea in terms of reuse and/or tools for populating and reading the
> > database.
> 
> My advice is don't go there.

I still need to read the latest available prices from somewhere. I could use 
GnuCash book, of course, but I hate to pollute it with a bunch of prices that 
don't have real use inside GnuCash anyway. Actually, I'd prefer not to download 
any prices into my GC book apart from the ones that are generated automatically 
on conversion. And even those I'd prefer to clean up from time to time.
I believe I'll do all the price-sensitive calculations outside GC by reading 
from a separate database (or another source).

> > I will definitely be creating a separate project for this, just hoping
> > someone else is interested.
> 
> There is lots of scope in other projects, I don't like people forcing 
> one to be another

Hm, that gives me a few ideas already. One thing I keep forgetting is to check 
if perhaps someone has a similar project already. Or I could simply try 
fetching and caching the latest prices for all symbols on startup. And to 
support offline calculations, I'd still need to save data to a db. Something to 
be worked-out.

Anyway, it would be nice to see Asset Allocation module in GnuCash. The current 
implementation is just two tables. But I'm not sure if it would satisfy 
everybody right now. 
The only other AA implementation I found is in ledger but I have not tested it 
properly because my exported book doesn't balance in ledger due to mismatch in 
handling capital gains transactions between GC and ledger. :(

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

Re: price.date, transaction.post_date and neutral time

[Alen Siljak]

   This is interesting information.
   I am currently separating the Asset Allocation logic into its own
   Python package, for direct use (cli) and potential library reuse
   between GnuCash Portfolio and an Android app (perhaps an add-on for
   MoneyManagerEx or who knows where it leads).
   In any case, it seems that Prices seems a likely candidate for
   separation, as well, as that can definitely be reused by multiple
   projects, contains simple data, and can get huge hence it seems better
   to have it separate to the main database.

   Now, this raises an interesting question of whether GnuCash would
   benefit from the same concept and perhaps reuse the price db. This
   might even be invisible to an average user but someone more advanced
   could take advantage. The internal GnuCash logic could remain
   more-or-less the same, in getting the latest price for the day only.
   I think a single table might be enough for this purpose, pretty much
   what's in GnuCash now. I have not yet looked into details for this.

   I'm wondering what the opinion here in the project would be about such
   an idea in terms of reuse and/or tools for populating and reading the
   database.
   I will definitely be creating a separate project for this, just hoping
   someone else is interested.

   Sent: Monday, February 12, 2018 at 3:17 PM
   From: "Wm via gnucash-devel" 
   To: gnucash-de...@lists.gnucash.org
   Subject: Re: price.date, transaction.post_date and neutral time
   IIRC the discussion at the time was about whether gnc should or could
   be
   used for trading. the result was "no" and it was decided that the price
   db should only have one entry per day (some people wanted multiple
   entries per day in an attempt to use gnc for trading, that was never
   going to work as gnc is a crap model for all the other stuff short term
   traders need, like quick graphs, moving averages, etc).
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Future allocated money, aka Envelope Budgeting

[Alen Siljak]

   He he

   Thanks a lot for the tips. I'm in touch with Sebastien in order to
   polish the ledger export script. It is available either directly
   (pc-export has been renamed to export.py) or through piecash cli
   ("piecash ledger" is the command if I remember well).
   Hopefully over the weekend I'll have some more time to play around with
   the whole process:

   gnucash -> sqlite db -> piecash export -> ledger data -> ledger or
   beancount -> fava or custom web interface

   I did not notice if asset allocation is available through Fava. Either
   way, I need to investigate that into more detail and see if I can get
   something similar to the view I already created in Gnucash Portfolio.
   I'm hoping it would be easier to contribute to an existing project than
   write and maintain the whole thing from scratch.

   There is also another Python export script at
   https://github.com/MatzeB/pygnucash. I hope to combine the wisdom from
   both of these.

   Is anyone aware of how close Beancount is to Ledger in terms of
   functionality?

   Also, apologies if this is spamming the devel list. Let me know if
   discussing related projects is/not ok for this list.

   Cheers

   Sent: Wednesday, February 07, 2018 at 7:00 AM
   From: Wm 
   To: gnucash-de...@lists.gnucash.org
   Subject: Re: Future allocated money, aka Envelope Budgeting
   P.S. I've just noticed MisterY already knows about piecash, silly me :)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Capital Gains FAQ entry

[Alen Siljak]

   Thanks, David. I'm refraining from deleting any text unless it is
   glaringly obvious that it is wrong.
   What I'm trying to do is to link various related pieces of information
   together. As you say, sometimes it can be contradictory because one
   side is quite outdated. I believe that, with having links, this would
   become easier to navigate and eventually correct.
   Sometimes I run into a page describing some concept and I can not find
   it afterwards.
   Multiple entry points to documentation are also extremely confusing to
   me - faq, wiki, user docs, doxygen, txt files, descriptions in the
   repo, etc. So, I guess, the ability to clean up is equally important as
   adding new text. :)

   The Lots Concept guide page, which I linked to the Concept of Lots wiki
   page, contains the most complete explanation of the lots concept and
   the *implementation*, which is currently in GnuCash. From that point it
   is very valuable although it may be outdated. And I never saw any link
   to that page elsewhere.
   It is a bit difficult (for me, at least) to distinguish between user
   and developer documentation. Because, as a user, I had terrible
   problems working with Lots - transactions would appear duplicate out of
   the blue, transactions would be split automatically, etc. None of
   what's happening was obvious until I read the mentioned description.
   So, once a few details were known, I had no issues with the Lots any
   longer. Not able to reproduce the issues I was experiencing before and
   report as bugs because now I don't remember the way I tried to do it
   instinctively.

   In addition, it would be handy to have useful links on the home page.
   For example, Uservoice is missing and I think this is quite handy for
   end users to have input into the desired features. While it does not
   guarantee the implementation, at least it shows where the demand is.

   Hope what I wrote here makes sense. These are mostly observations from
   my short recent experience and not a direct reference to what you wrote
   earlier.
   Thank you for making the changes you just did. This just proves that
   adding the links between related topics helps to clean up the things a
   bit. For example, someone who only reads the FAQ would have a different
   understanding of capital gains process than someone who happened to
   search for Lots and read a different page. Now, at least, they should
   be a bit more aligned.

   Cheers

   Sent: Sunday, January 21, 2018 at 6:35 PM
   From: "David T." 
   To: cicko 
   Cc: gnucash-devel@gnucash.org
   Subject: Capital Gains FAQ entry
   Cicko,
   I see that you have gotten involved in working on the wiki; fabulous!
   I recently received a notice that you had edited the FAQ on handling
   capital gains, by adding a reference to the wiki page “Concept of
   Lots”.
   Naturally, having received the announcement of the page change, I took
   a look at both the FAQ section and the Concept of Lots page, and found
   a number of problems.
   First, the FAQ itself is quite dated, mentioning the status of gains as
   of version 1.8. Since the Tutorial & Concept Guide represents the most
   complete and up-to-date version of the documentation, I have added
   these references and removed the original paragraph.
   Next, it goes into quite a bit of detail on how to enter gains—topics
   that are now covered in quite some detail in the Tutorial & Concepts
   Guide. SInce "9.7. Selling Shares” is so thorough, the examples given
   in the FAQ are both incomplete and redundant. Consequently, I am
   removing the example in the FAQ, and pointing to the Tutorial a second
   time, since it has so many detailed examples.
   Finally, I wonder whether it is wise to link to the “Concept of Lots”
   page, as it appears to be a description of how the implementer of the
   Lots feature went about it. Some of this information does appear to be
   unique, however, so I didn’t touch your reference to it. Long term, I
   think the information on this page should be separated so that the
   technical, development, information was placed on a technical page, and
   the user-focused information placed in the documentation set.
   Anyhow, I just wanted to let you know why I went into this section and
   changed it just after you had.
   David
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Boost/Python

[Alen Siljak]

   In my quest to call GnuCash functions from Python (or C#), I ran across
   Boost.Python
   (http://www.boost.org/doc/libs/1_66_0/libs/python/doc/html/index.html).

   What are the chances that this would work with GnuCash .dlls on
   Windows? Has anyone had any experience and willing to share?

   To me it currently looks like an interesting field to explore.
   A mini project to use this on would be an enhancement of the scheduled
   transactions management, for which I've submitted a few feature
   requests.
   Access to basic functions for listing and creation of records would be
   enough to build additional functions for displaying the transactions in
   range, changing states, etc.
   I'm currently focusing on using a Web interface through Flask.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Beyond 2.8 - some design thoughts

[Alen Siljak]

   I'd like to add that, to me, the difference between stable and unstable
   version is obvious enough if I see v2.8.0-alpha1, 2.8.0-alpha2,
   2.8.0-beta1, 2.8.0-rc1, and then 2.8.0. I see no need for separate
   version numbers.

   However, I don't feel strongly about the version numbers as long as
   they make sense. The above is just something I'd instinctively
   recognise if I did not know absolutely anything else about the project
   at hand.

   The same goes for major/minor version. For example, in the projects I
   contribute to (at work or privately), I tend to continuously update any
   dependencies that have minor version updates, assuming they contain
   only minor improvements. Bug fixes (the third number) are almost
   mandatory updates as they often correct issues that we identify
   ourselves.
   Major version change requires more time and effort in checking what has
   changed and hence doesn't get updated readily. That usually involves a
   migration path and coordinated effort.
   All this information is fairly obvious from just those three numbers.

   Happy New Year!

   Sent: Wednesday, December 27, 2017 at 6:15 PM
   From: "Geert Janssens" <geert.gnuc...@kobaltwit.be>
   To: gnucash-devel@gnucash.org
   Cc: "Alen Siljak" <alen.sil...@gmx.com>
   Subject: Re: Beyond 2.8 - some design thoughts
   I do agree up to some point. I consider the scheme I propose to be
   mostly a
   simplified form of the semantic versioning. We will use one level less,
   because we don't distinguish between bugfixes and compatible features.
   I can
   understand why this is suggested for libraries. The reality is we
   haven't been
   doing this for years. Also with every major release (2.6.0, 2.8.0,...)
   we have
   been introducing backwards incompatible changes. According to the
   semantic
   versioning this means we should have updated the first number rather
   than the
   second one. So applying the rules of semantic versioning on gnucash in
   the
   past would have been misleading.
   Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Beyond 2.8 - some design thoughts

[Alen Siljak]

   To me, as an outsider and an occassional tester, Semantic Versioning
   would make much more sense than any other custom versioning system.
   Simply because it is getting common across various software packages
   and libraries. It might work for the GUI application as well, when
   referring to the workflows instead of APIs.
   In that regard, I would always go for the "don't make me think"
   approach and stay away from numbering schemes that require a user
   manual to figure out.

   There's an answer on Stack Exchange that explains this into more
   detail:
   https://softwareengineering.stackexchange.com/questions/255190/how-does
   -semantic-versioning-apply-to-programs-without-api

   >
   > Option A: let's number development snapshots starting from x.90. That
   gives us
   > 10 development snapshots. If that's not enough we can either choose
   to start a
   > bit earlier, like x.80 or from x.98 jump to x.980 to give us 20 more.
   > Option B: as a variation all development snapshots do use a 3 number
   version:
   > x.99.z with 99 clearly indicating "right before the next major
   release" and z
   > incrementing with each snapshot.
   >
   I’m indifferent to the versioning system as long as it’s consistent,
   but the distro packagers aren’t. Some of them recite the “Semantic
   Versioning” [1] mantra even though it really applies only to libraries.
   Back when we released 2.6 we were unsure about whether the coming
   version would be 2.8 or 3.0. One of the criteria proposed was that we
   should call it 3.0 if we upgraded to Gtk+3. Well, we have, so maybe the
   coming release should be 3.0.0 instead of 2.8.0. That would certainly
   be consistent with the Gnome guidelines [2] that include a major change
   in the GUI as a reason for bumping the major version.
   Should some of the component libraries (especially libgnucash) have
   separate versioning that follows the semantic versioning rules?
   Regards,
   John Ralls
   [1] [1]https://semver.org/ <[2]https://semver.org/>[2]
   [3]https://developer.gnome.org/programming-guidelines/stable/versioning
   .html.en
   <[4]https://developer.gnome.org/programming-guidelines/stable/versionin
   g.html.en>

References

   1. https://semver.org/
   2. https://semver.org/
   3. 
https://developer.gnome.org/programming-guidelines/stable/versioning.html.en
   4. 
https://developer.gnome.org/programming-guidelines/stable/versioning.html.en
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Re: Re: change in date format in 2.7

[Alen Siljak]

   To get back to Sebastien's question: this does seem like a breaking
   change at this stage. Going back to 2.6.19 with the database where a
   few transactions have been entered in 2.7.2 shows the dates as
   1970-01-01.

   >Alen,
   >
   >Oh yeah, SQLite3. That doesn’t have a date type so the backend stores
   a formatted string. We use >ISO formatted date output for a lot of
   other things and I didn’t see a good reason to write a >special output
   function just for the SQLite3 backend when I rewrote the SQL backend in
   C++.
   >
   >We consider the data file formats and SQL schemas to be private
   implementation details.  If we make >a change that breaks Piecash, too
   bad. I told Sébastien that repeatedly and at length three years >ago
   when he embarked on the project.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Re: change in date format in 2.7

[Alen Siljak]

   I'm more than happy to do that but Python bindings don't even seem to
   be available for Windows at this stage. Which is a deal breaker for me,
   for example.
   --
   Sent from my Android phone with GMX Mail.

   On 21/12/17, 03:14 John Ralls <jra...@ceridwen.us> wrote:

 Alen,

   Oh yeah, SQLite3. That doesn’t have a date type so the backend stores a
   formatted string. We use ISO formatted date output for a lot of other
   things and I didn’t see a good reason to write a special output
   function just for the SQLite3 backend when I rewrote the SQL backend in
   C++.

   We consider the data file formats and SQL schemas to be private
   implementation details.  If we make a change that breaks Piecash, too
   bad. I told Sébastien that repeatedly and at length three years ago
   when he embarked on the project.

   The desired state at this time is that you work on improving the
   GnuCash python bindings and use those.

   Regards,

   John Ralls

   \On Dec 20, 2017, at 12:37 PM, Alen Siljak <[1]alen.sil...@gmx.com>
   wrote:

 John,
 With 2.7.2, the datetime field in sqlite3 database has increased to
   19
 chars, as Sebastien reported. The new format is -mm-dd HH:MM:ss
 instead of mmddHHMMss.
 It appears that the application can read both formats in a book and
 that part is not a problem.
 However, we are trying to set up the piecash library to utilize
   either
 one or both formats (if possible with SQLAlchemy data layer to use
   both
 patterns for conversion to Python datetime type).
 Now that you say this was not intentional, I'd like to know what is
   the
 desired state at this time. I have updated almost all my date columns
 to the new format so that I could continue using gnucash_portfolio
   set
 of functions and reports, which use the piecash data model underneath
 and still read my book file after upgrade to 2.7.2.
 Any clarifications are welcome! :)
 Cheers,
 Alen

 On Dec 20, 2017, at 4:38 AM, Sébastien de Menten  wro

   te:

 Hello,
 In books created in gnucash 2.7, the size of the field for date has
 been
 increased from 14 to 19 characters to move from a custom format to
 an ISO
 format if I understand properly.
 This is a backward incompatible change, correct ?
 ie GC 2.7 will read previous books and "migrate" them to the new
 format but
 then the books will not be readable by GC < 2.7.

 Uh, what file format do you mean? The only intentional change was to
 MySQL wher

   e we replaced TIMESTAMP >with DATETIME, but that appeared during
   testing to be t
   ransparent.

 But otherwise, no, it’s not necessarily incompatible as long as the
 date parser

   can understand the input >it will work either way. Did you test and
   find that s
   ome 2.6.x was unable to read a 2.7.2 file or database?

 Regards,
 John Ralls

   ___
   gnucash-devel mailing list
   [3]gnucash-devel@gnucash.org
   [4]https://lists.gnucash.org/mailman/listinfo/gnucash-devel

References

   1. mailto:alen.sil...@gmx.com
   2. http://gmail.com/
   3. mailto:gnucash-devel@gnucash.org
   4. 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: Re: change in date format in 2.7

[Alen Siljak]

   John,

   With 2.7.2, the datetime field in sqlite3 database has increased to 19
   chars, as Sebastien reported. The new format is -mm-dd HH:MM:ss
   instead of mmddHHMMss.
   It appears that the application can read both formats in a book and
   that part is not a problem.

   However, we are trying to set up the piecash library to utilize either
   one or both formats (if possible with SQLAlchemy data layer to use both
   patterns for conversion to Python datetime type).
   Now that you say this was not intentional, I'd like to know what is the
   desired state at this time. I have updated almost all my date columns
   to the new format so that I could continue using gnucash_portfolio set
   of functions and reports, which use the piecash data model underneath
   and still read my book file after upgrade to 2.7.2.

   Any clarifications are welcome! :)

   Cheers,
   Alen
>> On Dec 20, 2017, at 4:38 AM, Sébastien de Menten  wro
te:
>>
>> Hello,
>>
>> In books created in gnucash 2.7, the size of the field for date has been
>> increased from 14 to 19 characters to move from a custom format to an ISO
>> format if I understand properly.
>>
>> This is a backward incompatible change, correct ?
>> ie GC 2.7 will read previous books and "migrate" them to the new format but
>> then the books will not be readable by GC < 2.7.
>
>Uh, what file format do you mean? The only intentional change was to MySQL wher
e we replaced TIMESTAMP >with DATETIME, but that appeared during testing to be t
ransparent.
>
>But otherwise, no, it’s not necessarily incompatible as long as the date parser
 can understand the input >it will work either way. Did you test and find that s
ome 2.6.x was unable to read a 2.7.2 file or database?
>
>Regards,
>John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel