Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[Frank H. Ellenberger]

Hi Chris,

Am 18.07.2018 um 15:13 schrieb Christopher Lam:
> The state of balsheet-pnl.scm, is as follows:
> 
> I think it is stable and featureful enough to be a replacement, but
> there are no tests yet to validate a transition. This may happen over
> the next few months.
> 
> It incorporates all balance-sheet.scm and income-statement.scm
> functionality with the following known differences:
> 
>  * no option to show double-column ie Asset=left, Expense/Equity=right
>    (because I prefer leaving space for multiple data columns )

That is a problem for users in continental Europe, probably also other
non english speaking countries. We use the traditional T account
representation, while english speaking countries prefer the scaled (from
ital. for step stairs) form.

The T account representation easens also simple liqudity checks (current
assets > current lianilities, medium term assets > medium term
liabilities ...). Similar comparing groups of income & expense is desired.

IMHO the ability to compare groups is as much, if not more important
than compares over time.

Regards
Frank


pEpkey.asc
Description: application/pgp-keys
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] New balsheet (and P report), API considerations, and (slow?) KVP in Account.cpp

[Christopher Lam]

The state of balsheet-pnl.scm, is as follows:

I think it is stable and featureful enough to be a replacement, but 
there are no tests yet to validate a transition. This may happen over 
the next few months.


It incorporates all balance-sheet.scm and income-statement.scm 
functionality with the following known differences:


 * no option to show double-column ie Asset=left, Expense/Equity=right
   (because I prefer leaving space for multiple data columns )
 * no option to hide/show individual sections/their labels (eg
   Display/show asset section)
 * no display/show accounting-style rules (no space at all)
 * flatten list at depth limit (I don't understand its strategy at all
   and prefer to disable it)
 * balance-sheet.scm with Display/Parent-account-balances=none will
   disable amounts for accounts-with-children, which I think is
   nonsensical -- if an account has children, unless its amount is $0,
   it must be displayed, either recursive or multilevel.
 * choosing a common-report-currency when there are missing prices will
   now leave the amount in its original currency, instead of converting
   to $0.00
 * new balsheet will not compute unrealized gains -- from my
   understanding this doesn't belong in the balance sheet
 * I haven't coded the price source to average-cost or
   weighted-average, both of which will set a single exchange rate
   through all multicolumns -- are these options important???

Future plans:

 * I think the account-amount calculating functions are good enough to
   be reused to replace net-charts, category-barchart etc.
 * Hopefully the unintelligible old code can then be dumped for good.

C


On 03/07/18 15:41, Geert Janssens wrote:

Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:

Hi Stephen, Dave 

Thank you -

Dave - the changes are merely cosmetic therefore easy.

It sounds there are still 2 desired presentational types - (1) Dave's
approach = *recursive-bal* - 'parent' accounts generally collect their
children account amounts; if they also have their own amount, the latter is
rendered on the next line, indented as a child account. (2) Stephen's
approach = *multilevel-bal* - parent accounts' amounts are hidden unless
they exist.


I'm not sure I understand the difference here. Isn't this expressing the same
thing twice in different ways ? Perhaps I'm missing a subtlety in the English
language...

Or is the difference whether the totals are shown above or below the children
?

Geert




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

Re: [GNC-dev] Compiling Gnucash on MacOS - not for the faint of heart...

[Geert Janssens]

In addition I think the xcode project in git is out of date. When I moved the 
source directories around I saw a lot of source file references in the xcode 
project, but I didn't update those. So they still point at the old locations. 

Geert

John Ralls  schreef op 17 juli 2018 17:07:30 CEST:
>
>
>> On Jul 16, 2018, at 10:21 PM, Mike Alexander  wrote:
>> 
>>> On Jul 1, 2018, at 11:23 PM, John Ralls  wrote:
>>> 
>>> Last question first, bash and emacs. ISTR Mike Alexander uses vim
>and emacs.
>> 
>> Sorry for the delay, I’m a bit behind on EMail
>> 
>> My GnuCash environment is probably unique, or at least was until
>recently.  I’ve been too busy to update things for the current release
>so for the last few weeks I’ve been using the prebuilt binaries.  I
>hope to get back to my previous setup soon, however.  This means
>running the X-Window version on MacOS instead of the native Quartz
>version.  GTK3 is better than GTK2, but even with it I find the support
>for Quartz deficient in many ways.  For example there is almost no
>support for any accessibility features such as Voice Over.  Since I’m
>partly blind I depend on this and find apps that don’t suport it
>difficult to use.
>> 
>> I use a combination of MacPorts, BBEdit, and XCode to work on
>GnuCash.  I use MacPorts to install the dependencies.  This works fine
>if you’re using the X-Window version since that’s what MacPorts does
>for a living.  I’m not sure MacPorts has a quartz build for everything
>GnuCash needs for a dependency but it probably would be possible to add
>any that are missing.  It’s hard to have MacPorts build both X-Window
>and Quartz versions of things on the same machine so you really need to
>pick one or the other.
>> 
>> I use BBEdit to look at and edit the source and to do the builds.  I
>used to use XEmacs (never vi)  a lot back when I worked on Unix and
>Windows systems, but since XEmacs is essentially dead now and BBEdit is
>a very good replacement I use it.  I do the builds in a BBEdit
>worksheet.  If any of you have been around Macs long enough to remember
>MPW, a BBEdit worksheet is much like an MPW worksheet.  It’s an
>editable text window with a shell attached so you can execute shell
>commands and have the output appear in the window.   This is somewhat
>of an acquired taste, but I like it for some things.
>> 
>> I also have an XCode project (which is in git) but it is not used for
>building (the build script is /usr/bin/true).  It is useful for
>debugging since XCode provides a quite reasonable GUI for lldb.  I’ve
>got most of the source files in the project (although it’s probably not
>up to date right now) so XCode can find them.  I point the binary at
>the copy I build in BBEdit.  Then I can use XCode to debug GnuCash. 
>This works surprisingly well.
>> 
>> When I just  want to run GnuCash I invoked it from the terminal using
>a bash script I’ve put in ~/bin/gnucash.
>> 
>> This is admittedly an odd setup, but it works for me.
>
>Mike,
>
>I think that the only GnuCash dependencies that care about the
>windowing backend (i.e. quartz vs. X11) are cairo, pango, gtk, and
>webkitgtk, all of which I’m pretty sure MacPorts supports building with
>quartz. That doesn’t do anything for your a11y needs, of course. That
>requires someone to integrate atk with the Mac a11y apis.
>
>Since we’ve moved to cmake it’s possible to have cmake create an
>xcodeproject for you. Have you tried that? It might be easier than
>hand-maintaining your own.
>
>Regards,
>John Ralls
>
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

Re: [GNC-dev] GnuCash Portable is no longer portable as of 3.x

[Wm via gnucash-devel]

On 12/07/2018 01:14, John Ralls wrote:


I wrote a lengthy reply and then pressed the wrong key


Nothing you said suggests anything other than that Portable Apps is just 
another distro. The purposes of the distribution and the version tracking are 
immaterial.


They make a big shake of asking permission, usually.  Maybe you didn't 
give your permission.



You’re correct that %APPDATA%\Roaming isn’t for sneaker net. It’s for the 
user’s presence on different machines in a workgroup or Windows Domain.


There is a lot more to it than that, I am surprised you are so unaware.

Apparently what is illogical to you is perfectly reasonable to just about everyone else on the planet. 


Nope, unless you are JohnR <-- I'd prefer not to fight BTW

The settings that go into %APPDATA% are that user’s customizations and 
history.


Yes, notice "that users's" not "that orgs"

NOTICE: you are putting an invoice,
a formal document that in some cases has to have some exact words in it, 
the boilerplate on it in the same place as "oh, I had a thought, maybe 
I'll save it, maybe I won't, maybe I'll change it?  yeah, I'll change 
it, won't matter, they'll use the real version"


Every other OS also has standard locations for configurations and preferences and we try to keep GnuCash compliant with the standards on each OS. 


I KNOW THAT

The fact is that gnc has broken the standards about where personal and 
general .rc stuff goes :(


you seem to have made everything very personal

if that is the gnc model


MAKE IT VERY OBVIOUS, PLEASE


Since those standards have been around for a very long time indeed 
(almost 50 years in the case of Unix and its derivatives) it seems 
extremely unlikely to me that Portable Apps don’t have their own 
convention...


this is no longer about them

but as I said, since they have never to my knowledge communicated with 
us I have no idea what it might be and there’s no way that we can 
accommodate them. Of course if they’re modifying any part of 
GnuCash--including the build system--then they’re obliged to provide 
their users (not us) with the source code for their modifications.


The bottom line here is that this isn’t the GnuCash project’s problem and we 
have no way to coerce the Portable Apps folks to fix it for you.


I agree, this is now about where someone thought they should place stuff 
in accordance with .rc standards they didn't fully conceive for all.



Oh, and the wiki article you want is 
https://wiki.gnucash.org/wiki/Configuration_Locations 
.


I read that more than once.

--
Wm
No Trump joke today, America and Trump *is* the joke.

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