Re: [GNC-dev] Dev's features of choice?

[flywire]

Compatible code to add smarts to reports, say one click current/previous
fiscal year/half/quarter selection without a date in GnuCash. Using an
external Report App/ GnuCash Database split there is no intention or need
to write back to GnuCash database. Reporting configuration, say fiscal year
day/month or tax tables, can be held in the Report App database.

On Thu, Jun 3, 2021 at 1:11 PM John Ralls  wrote:

> > Not sure what you mean about compatibility, but the doctrine is that you
> can query all you want but shouldn't write the database outside of
> GnuCash's functions because all of the business logic is in GnuCash code,
> none in the database.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Dev's features of choice?

[John Ralls]

> On Jun 2, 2021, at 6:27 PM, flywire  wrote:
> 
> Thanks. I don't use MS-Office at home and it's in LO-Base so I'll keep it 
> there. 
> 
> I have a lot of experience with MS-Access at work and no real experience with 
> LO-Base. I suppose tables, queries, forms and reports would be compatible but 
> not coding.

Please remember to copy the list on all replies.

Not sure what you mean about compatibility, but the doctrine is that you can 
query all you want but shouldn't write the database outside of GnuCash's 
functions because all of the business logic is in GnuCash code, none in the 
database.

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

Re: [GNC-dev] Dev's features of choice?

[John Ralls]

> On Jun 2, 2021, at 4:29 PM, flywire  wrote:
> 
> On Sun Jul 26 13:36:07 EDT 2020, John Ralls wrote
> :
>> Big-picture:
>> - A report system that allows normal humans to generate custom reports
> and graphs...
> 
> What is some of the candidate sql qbe software? I'm interested in having a
> play around with reporting on sqlite.

We don't have any candidates yet. It's premature to start looking, there's too 
much prerequisite work to be done first.

For playing around: It's a bit of a lash-up but you can use Microsoft Access or 
Open/LibreOffice Base with SQLite3 via an ODBC driver. Both have QBE, though 
Microsofts is (as usual) a lot more polished. 

Regards,
John Ralls


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

[GNC-dev] Dev's features of choice?

[flywire]

On Sun Jul 26 13:36:07 EDT 2020, John Ralls wrote
:
> Big-picture:
>  - A report system that allows normal humans to generate custom reports
and graphs...

What is some of the candidate sql qbe software? I'm interested in having a
play around with reporting on sqlite.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Dev's features of choice?

[Alex Aycinena]

>
>
>
> -- Forwarded message --
> From: jean laroche 
> To: "Frank H. Ellenberger" 
> Cc: GnuCash Developer 
> Bcc:
> Date: Sun, 26 Jul 2020 14:49:47 -0700
> Subject: Re: [GNC-dev] Dev's features of choice?
>
>
> On 7/26/2020 1:54 PM, Frank H. Ellenberger wrote:
> > Hi Jean,
> >
> > Am 26.07.20 um 19:57 schrieb jean laroche:
> >> I'm curious about something:
> >> If you're a GC dev, contributing code to the project, what's the
> >> feature(s) you'd like to see added to GC?
> >> I'm only contributing a bit, but I'll offer my 3 top wishes:
> >> - Undo/(redo)
> >> - Multi-transaction (bulk) editing
> >> - Multi-account (bulk) editing
> > All three are violations of strict accounting rules. We often talk about
> > "In the times of ink and paper", not graphite (pencils). Some
> > governments require the immutabiity of once written records.
> I see a disconnect here. Some of us (John in particular) insist that GC
> is not a system for professionals, only for personal finance.
> Yet, I always hear about accounting rules, and the way it should be done
> by the book. If GC is really for the personal user, I don't understand
> how we can survive without undo/redo, and multi-select. *every* piece of
> software out there has these types of features, and they're invaluable.
> J.
>
>
There doesn't have to be a choice between these two points. Your three
enhancements could be done in a way that is consistent with Frank's
comments, but a solution for his comments about recording and having an
'audit trail' of all changes in a generic way would have to be designed and
implemented first.

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

Re: [GNC-dev] Dev's features of choice?

[Christopher Lam]

LUndo/redo could be implemented as a journalling type table, where each new
row describes the change in state. But then you're recreating sqlite, and
would require deep architectural changes. Probably not possible in this
lifetime.

On Mon, 27 Jul 2020, 12:33 pm jean laroche,  wrote:

> OK thanks for all the opinions. As usual with collaborative projects,
> it's a bit messy, we don't all have the very same optics, which I think
> is probably a good thing!
>
> I would agree with John that undo/redo is very challenging if it's
> applicable to all actions with "infinite" undo/redo. I've thought about
> it a bit, and there's nothing that seems easy to me that would give a
> fully functional undo/redo. Even if you saved the state of the database
> for every action (granularity to be defined!) restoring it, and going
> back exactly where you were would not be a simple matter...
>
> In any case, thanks for chiming in.
> Jean
>
>
> On 7/26/2020 8:52 PM, John Ralls wrote:
> > There's already a cancel button for the first part.
> >
> > There's no undelete, but it wouldn't be to hard to implement: Just make
> a second set of QofContainers to hold deleted objects until the end of the
> session and provide a dialog to list them and allow them to be returned to
> the primary container.
> >
> > The normal undo-redo stacks common in other programs would be a bit more
> complex but the technique is well known, it's just really tedious to
> implement. Where the problem gets quite a bit more interesting (read:
> complex and difficult with decisions about depth and granularity) is when
> the undo stack reaches back into already committed transactions. Do you
> save a copies of each object for every keystroke or treat an edited
> transaction like a deleted one? How do you handle an import of many
> transactions, some new and some matched-and-updated? That's just the
> beginning, GnuCash is complicated. It could easily turn into several years
> work for a skilled software engineer; definitely not a job for a hacker.
> >
> > Regards,
> > John Ralls
> >
> >
> >> On Jul 26, 2020, at 7:59 PM, Bruce Irving via gnucash-devel <
> gnucash-devel@gnucash.org> wrote:
> >>
> >> While I'm not a professional, there is a point about undo that I would
> like to see - sooner than later:  I start to edit a transaction but, before
> I commit it (press enter or move to another transaction). I realize that I
> didn't want to do that and would like to cancel my edit, restoring the
> transaction to what it was.
> >>
> >> And, I have accidentally deleted a transaction on more than one
> occasion.  It would be great if I could restore that transaction rather
> than completely re-enter it, hoping I remembered what was in it - I don't!
> >> Bruce
> >> Preach the Gospel wherever you go.
> >> If necessary, use words.
> >>
> >> Hi Jean,
> >>
> >> Am 26.07.20 um 19:57 schrieb jean laroche:
> >>> I'm curious about something:
> >>> If you're a GC dev, contributing code to the project, what's the
> >>> feature(s) you'd like to see added to GC?
> >>> I'm only contributing a bit, but I'll offer my 3 top wishes:
> >>> - Undo/(redo)
> >>> - Multi-transaction (bulk) editing
> >>> - Multi-account (bulk) editing
> >> All three are violations of strict accounting rules. We often talk about
> >> "In the times of ink and paper", not graphite (pencils). Some
> >> governments require the immutabiity of once written records.
> >>
> >> So I see at least a better auditing system as a requirement before your
> >> suggestions. The current logging would need a review. It should cover
> >> all changes, not only simple transactions. ISTR business actions and
> >> structural changes are not recorded.
> >>
> >>> I'm curious specifically about devs because they typically have a
> >>> different perspective on the project than users have.
> >>> Jean
> >> About the future I almost agree with Johns suggestions.
> >>
> >> Regards
> >> Frank
> >>
> >> ___
> >> gnucash-devel mailing list
> >> gnucash-devel@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Dev's features of choice?

[jean laroche]

OK thanks for all the opinions. As usual with collaborative projects, 
it's a bit messy, we don't all have the very same optics, which I think 
is probably a good thing!


I would agree with John that undo/redo is very challenging if it's 
applicable to all actions with "infinite" undo/redo. I've thought about 
it a bit, and there's nothing that seems easy to me that would give a 
fully functional undo/redo. Even if you saved the state of the database 
for every action (granularity to be defined!) restoring it, and going 
back exactly where you were would not be a simple matter...


In any case, thanks for chiming in.
Jean


On 7/26/2020 8:52 PM, John Ralls wrote:

There's already a cancel button for the first part.

There's no undelete, but it wouldn't be to hard to implement: Just make a 
second set of QofContainers to hold deleted objects until the end of the 
session and provide a dialog to list them and allow them to be returned to the 
primary container.

The normal undo-redo stacks common in other programs would be a bit more 
complex but the technique is well known, it's just really tedious to implement. 
Where the problem gets quite a bit more interesting (read: complex and 
difficult with decisions about depth and granularity) is when the undo stack 
reaches back into already committed transactions. Do you save a copies of each 
object for every keystroke or treat an edited transaction like a deleted one? 
How do you handle an import of many transactions, some new and some 
matched-and-updated? That's just the beginning, GnuCash is complicated. It 
could easily turn into several years work for a skilled software engineer; 
definitely not a job for a hacker.

Regards,
John Ralls



On Jul 26, 2020, at 7:59 PM, Bruce Irving via gnucash-devel 
 wrote:

While I'm not a professional, there is a point about undo that I would like to 
see - sooner than later:  I start to edit a transaction but, before I commit it 
(press enter or move to another transaction). I realize that I didn't want to 
do that and would like to cancel my edit, restoring the transaction to what it 
was.

And, I have accidentally deleted a transaction on more than one occasion.  It 
would be great if I could restore that transaction rather than completely 
re-enter it, hoping I remembered what was in it - I don't!
Bruce
Preach the Gospel wherever you go.
If necessary, use words.

Hi Jean,

Am 26.07.20 um 19:57 schrieb jean laroche:

I'm curious about something:
If you're a GC dev, contributing code to the project, what's the
feature(s) you'd like to see added to GC?
I'm only contributing a bit, but I'll offer my 3 top wishes:
- Undo/(redo)
- Multi-transaction (bulk) editing
- Multi-account (bulk) editing

All three are violations of strict accounting rules. We often talk about
"In the times of ink and paper", not graphite (pencils). Some
governments require the immutabiity of once written records.

So I see at least a better auditing system as a requirement before your
suggestions. The current logging would need a review. It should cover
all changes, not only simple transactions. ISTR business actions and
structural changes are not recorded.


I'm curious specifically about devs because they typically have a
different perspective on the project than users have.
Jean

About the future I almost agree with Johns suggestions.

Regards
Frank

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

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


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

Re: [GNC-dev] Dev's features of choice?

[John Ralls]

There's already a cancel button for the first part.

There's no undelete, but it wouldn't be to hard to implement: Just make a 
second set of QofContainers to hold deleted objects until the end of the 
session and provide a dialog to list them and allow them to be returned to the 
primary container. 

The normal undo-redo stacks common in other programs would be a bit more 
complex but the technique is well known, it's just really tedious to implement. 
Where the problem gets quite a bit more interesting (read: complex and 
difficult with decisions about depth and granularity) is when the undo stack 
reaches back into already committed transactions. Do you save a copies of each 
object for every keystroke or treat an edited transaction like a deleted one? 
How do you handle an import of many transactions, some new and some 
matched-and-updated? That's just the beginning, GnuCash is complicated. It 
could easily turn into several years work for a skilled software engineer; 
definitely not a job for a hacker.

Regards,
John Ralls


> On Jul 26, 2020, at 7:59 PM, Bruce Irving via gnucash-devel 
>  wrote:
> 
> While I'm not a professional, there is a point about undo that I would like 
> to see - sooner than later:  I start to edit a transaction but, before I 
> commit it (press enter or move to another transaction). I realize that I 
> didn't want to do that and would like to cancel my edit, restoring the 
> transaction to what it was.  
> 
> And, I have accidentally deleted a transaction on more than one occasion.  It 
> would be great if I could restore that transaction rather than completely 
> re-enter it, hoping I remembered what was in it - I don't!
> Bruce
> Preach the Gospel wherever you go.
> If necessary, use words.
> 
> Hi Jean,
> 
> Am 26.07.20 um 19:57 schrieb jean laroche:
>> I'm curious about something:
>> If you're a GC dev, contributing code to the project, what's the
>> feature(s) you'd like to see added to GC?
>> I'm only contributing a bit, but I'll offer my 3 top wishes:
>> - Undo/(redo)
>> - Multi-transaction (bulk) editing
>> - Multi-account (bulk) editing
> 
> All three are violations of strict accounting rules. We often talk about
> "In the times of ink and paper", not graphite (pencils). Some
> governments require the immutabiity of once written records.
> 
> So I see at least a better auditing system as a requirement before your
> suggestions. The current logging would need a review. It should cover
> all changes, not only simple transactions. ISTR business actions and
> structural changes are not recorded.
> 
>> I'm curious specifically about devs because they typically have a
>> different perspective on the project than users have.
>> Jean
> 
> About the future I almost agree with Johns suggestions.
> 
> Regards
> Frank
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

Re: [GNC-dev] Dev's features of choice?

[John Ralls]

Because while GnuCash lacks the controls and some modules (c.f. the recent 
request for cost accounting; we also get frequent questions about whether we 
support payroll, inventory control, and POS for retail) required by many 
businesses, it is double-entry and designed for users who want a formal 
accounting app. If you're more interested in a Quicken work-alike try KMyMoney.

That said I don't agree with Frank that transactions should be immutable, 
though we have a preference that can get you pretty close to that if you want. 
The real difficulty with bulk edit is GnuCash's edit-commit structure that as 
you recently discovered in imports makes bulk modification rather slow. 
Changing it without breaking a lot of other things would be difficult. There 
are also accounting controls issues: Remember that you punted on enforcing 
same-commodity on bulk moves of transactions in sub-accounts when deleting the 
parent account because of the spiraling complexity.

Undo/Redo is maybe another matter. The simplest form would keep a stack of 
changes to the Gtk controls while some element--a transaction in the register, 
a business object, or a dialog box--is between being open and committed. 
Implementing that would be mostly tedious. Being able to undo already committed 
changes would require a good deal more care and perhaps some changes to the 
edit-commit behavior in the backend.

Regards,
John Ralls


> On Jul 26, 2020, at 4:50 PM, jean laroche  wrote:
> 
> But why???
> 
> 
> On 7/26/2020 3:38 PM, D. wrote:
>> Jean,
>> 
>> I think you raise a valid point. There does seem to be a tendency in the 
>> community to assume that a certain amount of inconvenience is to be 
>> expected. The reasons vary, but the underlying tendency remains.
>> 
>> David T.
>> 
>> 
>>  Original Message 
>> From: jean laroche 
>> Sent: Sun Jul 26 17:49:47 EDT 2020
>> To: "Frank H. Ellenberger" 
>> Cc: GnuCash Developer 
>> Subject: Re: [GNC-dev] Dev's features of choice?
>> 
>> 
>> 
>> On 7/26/2020 1:54 PM, Frank H. Ellenberger wrote:
>>> Hi Jean,
>>> 
>>> Am 26.07.20 um 19:57 schrieb jean laroche:
>>>> I'm curious about something:
>>>> If you're a GC dev, contributing code to the project, what's the
>>>> feature(s) you'd like to see added to GC?
>>>> I'm only contributing a bit, but I'll offer my 3 top wishes:
>>>> - Undo/(redo)
>>>> - Multi-transaction (bulk) editing
>>>> - Multi-account (bulk) editing
>>> All three are violations of strict accounting rules. We often talk about
>>> "In the times of ink and paper", not graphite (pencils). Some
>>> governments require the immutabiity of once written records.
>> I see a disconnect here. Some of us (John in particular) insist that GC
>> is not a system for professionals, only for personal finance.
>> Yet, I always hear about accounting rules, and the way it should be done
>> by the book. If GC is really for the personal user, I don't understand
>> how we can survive without undo/redo, and multi-select. *every* piece of
>> software out there has these types of features, and they're invaluable.
>> J.
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

Re: [GNC-dev] Dev's features of choice?

[Bruce Irving via gnucash-devel]

While I'm not a professional, there is a point about undo that I would like to 
see - sooner than later:  I start to edit a transaction but, before I commit it 
(press enter or move to another transaction). I realize that I didn't want to 
do that and would like to cancel my edit, restoring the transaction to what it 
was.  

And, I have accidentally deleted a transaction on more than one occasion.  It 
would be great if I could restore that transaction rather than completely 
re-enter it, hoping I remembered what was in it - I don't!
 Bruce
 Preach the Gospel wherever you go.
 If necessary, use words.

Hi Jean,

Am 26.07.20 um 19:57 schrieb jean laroche:
> I'm curious about something:
> If you're a GC dev, contributing code to the project, what's the
> feature(s) you'd like to see added to GC?
> I'm only contributing a bit, but I'll offer my 3 top wishes:
> - Undo/(redo)
> - Multi-transaction (bulk) editing
> - Multi-account (bulk) editing

All three are violations of strict accounting rules. We often talk about
"In the times of ink and paper", not graphite (pencils). Some
governments require the immutabiity of once written records.

So I see at least a better auditing system as a requirement before your
suggestions. The current logging would need a review. It should cover
all changes, not only simple transactions. ISTR business actions and
structural changes are not recorded.

> I'm curious specifically about devs because they typically have a
> different perspective on the project than users have.
> Jean

About the future I almost agree with Johns suggestions.

Regards
Frank

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

Re: [GNC-dev] Dev's features of choice?

[Christopher Lam]

Jean as usual the best answer is to push the code forward in ways that you
are best capable and willing to do. If they require deep architectural
changes that are impossible to maintain, or simply badly written code, then
they will be rejected. But if you feel they will be well received then
go for it. I still think your proposals are positive contributions.

On Mon, 27 Jul 2020, 1:58 am jean laroche,  wrote:

> I'm curious about something:
> If you're a GC dev, contributing code to the project, what's the
> feature(s) you'd like to see added to GC?
> I'm only contributing a bit, but I'll offer my 3 top wishes:
> - Undo/(redo)
> - Multi-transaction (bulk) editing
> - Multi-account (bulk) editing
>
> I'm curious specifically about devs because they typically have a
> different perspective on the project than users have.
> Jean
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Dev's features of choice?

[David Cousens]

Jean,

As always the answer comes down to the available resources to carry out the 
work needed vs the complexity of carrying it
out. John has pointed out a number of barriers to being able to make GnuCash 
even more flexible  than it is currentlyand
facilitate addition of plugin capability for more specialized functionality, 
many of which are a consequence of the
history of its development. 

Much of the user base would I think prioritise the basic accounting 
functionality which is highly adaptable (the use in
many countries by a wide variety of amatuer and professional accountants and 
business attests to that) over nice but not
necessarily critical features. We will of course happily accept those if they 
become available but this is always
contingent on the availability of developers with the necessary expertise and 
sufficient understanding of the current
code base and its historical complexities as well as having the accounting 
background necessary. 

Some of the occasional contributors like myself were/are primarily users with a 
little coding experience (but not
professional developers) so our ability to contribute is limited by that as 
well as our available time. We rely on the
core development team for the hard work (which we all appreciate greatly) and 
overall development roadmap while we
mainly contribute around the edges.

I detect a healthy dollop of the "if it ain't broke, don't fix it" brigade in 
the mix as well but mostly they will
happily use new features if they meet their needs and then end up not knowing 
how they ever did without them. Such is
life!

David Cousens

On Sun, 2020-07-26 at 16:50 -0700, jean laroche wrote:
> But why???
> 
> 
> On 7/26/2020 3:38 PM, D. wrote:
> > Jean,
> > 
> > I think you raise a valid point. There does seem to be a tendency in the 
> > community to assume that a certain amount
> > of inconvenience is to be expected. The reasons vary, but the underlying 
> > tendency remains.
> > 
> > David T.
> > 
> > 
> >  Original Message 
> > From: jean laroche 
> > Sent: Sun Jul 26 17:49:47 EDT 2020
> > To: "Frank H. Ellenberger" 
> > Cc: GnuCash Developer 
> > Subject: Re: [GNC-dev] Dev's features of choice?
> > 
> > 
> > 
> > On 7/26/2020 1:54 PM, Frank H. Ellenberger wrote:
> > > Hi Jean,
> > > 
> > > Am 26.07.20 um 19:57 schrieb jean laroche:
> > > > I'm curious about something:
> > > > If you're a GC dev, contributing code to the project, what's the
> > > > feature(s) you'd like to see added to GC?
> > > > I'm only contributing a bit, but I'll offer my 3 top wishes:
> > > > - Undo/(redo)
> > > > - Multi-transaction (bulk) editing
> > > > - Multi-account (bulk) editing
> > > All three are violations of strict accounting rules. We often talk about
> > > "In the times of ink and paper", not graphite (pencils). Some
> > > governments require the immutabiity of once written records.
> > I see a disconnect here. Some of us (John in particular) insist that GC
> > is not a system for professionals, only for personal finance.
> > Yet, I always hear about accounting rules, and the way it should be done
> > by the book. If GC is really for the personal user, I don't understand
> > how we can survive without undo/redo, and multi-select. *every* piece of
> > software out there has these types of features, and they're invaluable.
> > J.
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
-- 
Dr David R Cousens
B.Sc, M.Prof. Acc., Ph.D., G.C.Ed

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

Re: [GNC-dev] Dev's features of choice?

[jean laroche]

But why???


On 7/26/2020 3:38 PM, D. wrote:

Jean,

I think you raise a valid point. There does seem to be a tendency in the 
community to assume that a certain amount of inconvenience is to be expected. 
The reasons vary, but the underlying tendency remains.

David T.


 Original Message 
From: jean laroche 
Sent: Sun Jul 26 17:49:47 EDT 2020
To: "Frank H. Ellenberger" 
Cc: GnuCash Developer 
Subject: Re: [GNC-dev] Dev's features of choice?



On 7/26/2020 1:54 PM, Frank H. Ellenberger wrote:

Hi Jean,

Am 26.07.20 um 19:57 schrieb jean laroche:

I'm curious about something:
If you're a GC dev, contributing code to the project, what's the
feature(s) you'd like to see added to GC?
I'm only contributing a bit, but I'll offer my 3 top wishes:
- Undo/(redo)
- Multi-transaction (bulk) editing
- Multi-account (bulk) editing

All three are violations of strict accounting rules. We often talk about
"In the times of ink and paper", not graphite (pencils). Some
governments require the immutabiity of once written records.

I see a disconnect here. Some of us (John in particular) insist that GC
is not a system for professionals, only for personal finance.
Yet, I always hear about accounting rules, and the way it should be done
by the book. If GC is really for the personal user, I don't understand
how we can survive without undo/redo, and multi-select. *every* piece of
software out there has these types of features, and they're invaluable.
J.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel



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

Re: [GNC-dev] Dev's features of choice?

[D. via gnucash-devel]

Jean,

I think you raise a valid point. There does seem to be a tendency in the 
community to assume that a certain amount of inconvenience is to be expected. 
The reasons vary, but the underlying tendency remains.

David T. 


 Original Message 
From: jean laroche 
Sent: Sun Jul 26 17:49:47 EDT 2020
To: "Frank H. Ellenberger" 
Cc: GnuCash Developer 
Subject: Re: [GNC-dev] Dev's features of choice?



On 7/26/2020 1:54 PM, Frank H. Ellenberger wrote:
> Hi Jean,
>
> Am 26.07.20 um 19:57 schrieb jean laroche:
>> I'm curious about something:
>> If you're a GC dev, contributing code to the project, what's the
>> feature(s) you'd like to see added to GC?
>> I'm only contributing a bit, but I'll offer my 3 top wishes:
>> - Undo/(redo)
>> - Multi-transaction (bulk) editing
>> - Multi-account (bulk) editing
> All three are violations of strict accounting rules. We often talk about
> "In the times of ink and paper", not graphite (pencils). Some
> governments require the immutabiity of once written records.
I see a disconnect here. Some of us (John in particular) insist that GC 
is not a system for professionals, only for personal finance.
Yet, I always hear about accounting rules, and the way it should be done 
by the book. If GC is really for the personal user, I don't understand 
how we can survive without undo/redo, and multi-select. *every* piece of 
software out there has these types of features, and they're invaluable.
J.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

Re: [GNC-dev] Dev's features of choice?

[jean laroche]

On 7/26/2020 1:54 PM, Frank H. Ellenberger wrote:

Hi Jean,

Am 26.07.20 um 19:57 schrieb jean laroche:

I'm curious about something:
If you're a GC dev, contributing code to the project, what's the
feature(s) you'd like to see added to GC?
I'm only contributing a bit, but I'll offer my 3 top wishes:
- Undo/(redo)
- Multi-transaction (bulk) editing
- Multi-account (bulk) editing

All three are violations of strict accounting rules. We often talk about
"In the times of ink and paper", not graphite (pencils). Some
governments require the immutabiity of once written records.
I see a disconnect here. Some of us (John in particular) insist that GC 
is not a system for professionals, only for personal finance.
Yet, I always hear about accounting rules, and the way it should be done 
by the book. If GC is really for the personal user, I don't understand 
how we can survive without undo/redo, and multi-select. *every* piece of 
software out there has these types of features, and they're invaluable.

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

Re: [GNC-dev] Dev's features of choice?

[Frank H. Ellenberger]

Hi Jean,

Am 26.07.20 um 19:57 schrieb jean laroche:
> I'm curious about something:
> If you're a GC dev, contributing code to the project, what's the
> feature(s) you'd like to see added to GC?
> I'm only contributing a bit, but I'll offer my 3 top wishes:
> - Undo/(redo)
> - Multi-transaction (bulk) editing
> - Multi-account (bulk) editing

All three are violations of strict accounting rules. We often talk about
"In the times of ink and paper", not graphite (pencils). Some
governments require the immutabiity of once written records.

So I see at least a better auditing system as a requirement before your
suggestions. The current logging would need a review. It should cover
all changes, not only simple transactions. ISTR business actions and
structural changes are not recorded.

> I'm curious specifically about devs because they typically have a
> different perspective on the project than users have.
> Jean

About the future I almost agree with Johns suggestions.

Regards
Frank


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

Re: [GNC-dev] Dev's features of choice?

[jean laroche]

Thanks that's helpful!
J


On 7/26/2020 11:35 AM, John Ralls wrote:



On Jul 26, 2020, at 10:57 AM, jean laroche  wrote:

I'm curious about something:
If you're a GC dev, contributing code to the project, what's the feature(s) 
you'd like to see added to GC?
I'm only contributing a bit, but I'll offer my 3 top wishes:
- Undo/(redo)
- Multi-transaction (bulk) editing
- Multi-account (bulk) editing

I'm curious specifically about devs because they typically have a different 
perspective on the project than users have.


Big-picture:
- A report system that allows normal humans to generate custom reports and 
graphs.
- Simultaneous multi-user access.
- Real plugins
- Mobile (at least for tablets) support

To get there, plus some maintainability improvements:

- In-memory SQLDB for the XML backend, enabling replacement of QofQuery with 
SQL queries and use of SQL record locking in the engine that would in turn make 
multiple simultaneous sessions possible when using a SQL server backend.
- A QBE frontend for those SQL queries so that normal humans can query their 
data.
- Cleaning the model and controller code out of gnucash/gnome and 
gnucash/gnome-utils to make UI improvements easier and migration to a different 
GUI framework feasible.
- Removing Guile from everything except the report module.
- Consolidating signaling, events, and hooks into a single system.
- Removing all of the direct model manipulation from reports and replace it 
with SQL queries.
- Replace the report module with something that normal humans can use to 
generate reports and graphs suitable for their needs.
- Make GncModule a proper plugin architecture that allows modules compiled 
separately from the main GnuCash source tree. Immediate uses would separate 
AQBanking and the Python console into separate projects, but no doubt others 
would pop up once the capability is available.
- Find a way to display reports so that we don't have to include WebKit in the 
macOS and Windows bundles.

Regards,
John Ralls



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

Re: [GNC-dev] Dev's features of choice?

[John Ralls]

> On Jul 26, 2020, at 10:57 AM, jean laroche  wrote:
> 
> I'm curious about something:
> If you're a GC dev, contributing code to the project, what's the feature(s) 
> you'd like to see added to GC?
> I'm only contributing a bit, but I'll offer my 3 top wishes:
> - Undo/(redo)
> - Multi-transaction (bulk) editing
> - Multi-account (bulk) editing
> 
> I'm curious specifically about devs because they typically have a different 
> perspective on the project than users have.


Big-picture:
- A report system that allows normal humans to generate custom reports and 
graphs.
- Simultaneous multi-user access.
- Real plugins
- Mobile (at least for tablets) support

To get there, plus some maintainability improvements:

- In-memory SQLDB for the XML backend, enabling replacement of QofQuery with 
SQL queries and use of SQL record locking in the engine that would in turn make 
multiple simultaneous sessions possible when using a SQL server backend.
- A QBE frontend for those SQL queries so that normal humans can query their 
data.
- Cleaning the model and controller code out of gnucash/gnome and 
gnucash/gnome-utils to make UI improvements easier and migration to a different 
GUI framework feasible.
- Removing Guile from everything except the report module.
- Consolidating signaling, events, and hooks into a single system.
- Removing all of the direct model manipulation from reports and replace it 
with SQL queries.
- Replace the report module with something that normal humans can use to 
generate reports and graphs suitable for their needs.
- Make GncModule a proper plugin architecture that allows modules compiled 
separately from the main GnuCash source tree. Immediate uses would separate 
AQBanking and the Python console into separate projects, but no doubt others 
would pop up once the capability is available.
- Find a way to display reports so that we don't have to include WebKit in the 
macOS and Windows bundles.

Regards,
John Ralls

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

[GNC-dev] Dev's features of choice?

[jean laroche]

I'm curious about something:
If you're a GC dev, contributing code to the project, what's the 
feature(s) you'd like to see added to GC?

I'm only contributing a bit, but I'll offer my 3 top wishes:
- Undo/(redo)
- Multi-transaction (bulk) editing
- Multi-account (bulk) editing

I'm curious specifically about devs because they typically have a 
different perspective on the project than users have.

Jean

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