Re: Beyond 2.8 - some design thoughts

[Frank H. Ellenberger]

Am 03.01.2018 um 17:41 schrieb Derek Atkins:
> I see no reason that we can't jump from 2.7.x to 3.0[.0] when we release.
> And since we DID upgrade to GTK3, I think we should do that.

+1

> As for whether to drop the third entry is less important to me, but I
> still think it makes sense to have 3.0.0, 3.0.1, etc., for bugfixes and
> leave 3.1/3.2 for more major changes.

+1

Maintainers might have a policy to update bugfixes in their current
release, mayor changes in the next release and for fundamental changes
both versions.

The 3 levels also should give admins and users a clue how much time is
needed for
 dependency changes and
 understanding new concepts.

> I'm fine with dropping the even/odd and just jumping t0 3.0.80 (or 90)
> for testing pre-releases.

The rule is simple: Do not install the odd version on productive systems!

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

Re: Issue when importing QIF file with splits

[Derek Atkins]

Hi,

Edward Bridges  writes:

> Hello,
>
> I am trying to import a QIF file with splits, but the splits are being
> created in an unexpected way.
>
> Here is an example of the QIF file that I'm trying to import (these
> are being generated to create splits, so I have control over their
> format).
>
> ```
> !Account
> NAssets:Current Assets:Checking Account
> TBank
> ^
> !Type:Bank
> C
> D12/15/2008
> NN/A
> PSample Income (Imported)
> T100.00
> LIncome
> SAssets:Budgeted Cash
> $-50.00
> SBudget:Food
> $50.00
> ^
> ```
>
> This is what I'm hoping to get as a result of the import (screenshot
> is available at the link):
> https://imagebin.ca/v/3ml1P92nUJxa
>
> However when the above QIF file is imported, I'm getting the following:
> https://imagebin.ca/v/3ml2apQ0okqR
>
> The problem I'm seeing is that the $100 is not being debited from the
> Checking Account and credited to Income.
>
> I expected that additional split to be created because the record is
> in the context of the checking account (given the `N` field on line 2)
> and the transaction is categorized as "Income" (via the `L` field on
> line 11).

When doing splits, the "L" portion is ignored, which is why you're not
seeing anything to Income.  You need:

SIncome
$100.00

> Please help me to understand what I'm doing wrong to make this import
> as I expect.

I think if you remove the LIncome and add those two lines then it should
do what you want.  Try it out and let me know?

> Thanks!
> Ed

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Beyond 2.8 - namespaces

[Derek Atkins]

Aaron Laws  writes:

[snip]
>  It would, of course, require a casual user (single desktop
> user with one data file) to have to have a server and client process
> running. In general, I think it would be a needless source of complexity
> since the earlier approach I mentioned (single-processes communicating with
> the database directly) works just fine.

In the single-user/desktop case, the application can spawn the server
sub-process if it's not already running, and the server sub-process can
exit when it has no connections.

[snip]
> That said, as Mr. Ralls mentioned, separation of business logic and GUI
> logic is a high-priority development goal, but happens to be a colossal
> task in Gnucash.

Agreed.  A true MVC with complete disconnection of business logic means
a less-usage UI.  You want the UI to be able to inform the user as soon
as possible that there is an "error" in their input.  On the other hand,
you want that error-checking to be done in a way that *ANY* UI can
leverage it (e.g. is my split transaction balanced?).  There-in lies the
difficulty and challenges, because different UIs are going to want to do
that checking in different ways.

For example, on a webui you would want to have that checking done in
Javascript, whereas the Gtk frontend would want a C/C++ function call.
If everything is REST (or REST-like) then you MAY be able to perform
intermediary "validate" calls somewhere along the way to provide more
real-time feedback.  You may not want to wait until the end to perform
the validation.

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Beyond 2.8 - some design thoughts

[Derek Atkins]

John Ralls  writes:

>> 2. Versioning.
>> 
>> We currently use a version scheme gigantic.major.minor[-build]. Like 2.6.19 
>> (and an optional -2 if we had to release more than once to get it right). 
>> For 
>> the 3 levels we really only use two. The 2 in front has been updated when 
>> gnucash migrated from gtk to gtk2.  We will migrate to gtk3 for gnucash 2.8 
>> yet we don't changed to 3.0 as a result. The migration to gtk2 has
>> been a long
>> time ago and the software world has evolved since then. Release cycles in 
>> general have shortened. Incremental changes are usually preferred over big 
>> bang changes. So I think our numbering scheme is in for a modernization.
>> 
>> Here's my proposal:
>> After the 2.8 lifecycle let's drop one number and stick with major.minor[-
>> build] instead. 
>> Major releases would increment the first number. Bugfix releases the second.
>> 
>> So after 2.8 the next major release would be 3.0, bugfix releases for that 
>> major release would become 3.1, 3.2, 3.4...
>> 
>> I would drop the idea of odd numbers being development snapshots and even 
>> numbers being stable ones. Instead I see several options, I haven't decided 
>> which one is most elegant/kludgy:
>> 
>> 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.
>> 
>> This makes development snapshots slightly more verbose in their numbering 
>> but 
>> gives us cleanly incrementing stable releases. The latter are more visible 
>> to 
>> most users, so I personally care more about those.
>> 
>> The development snapshots between 2.8 and 3.0 fall a bit in between. We 
>> could 
>> choose to handle them old style or new style as we see fit. Old style would 
>> mean we'd still work with a 2.9.x series. New style would mean we'd
>> start with
>> 2.8.90/2.8.99.1 as we see fit.
>> 
>> Thoughts ?
>
> 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?

I see no reason that we can't jump from 2.7.x to 3.0[.0] when we release.
And since we DID upgrade to GTK3, I think we should do that.

As for whether to drop the third entry is less important to me, but I
still think it makes sense to have 3.0.0, 3.0.1, etc., for bugfixes and
leave 3.1/3.2 for more major changes.

I'm fine with dropping the even/odd and just jumping t0 3.0.80 (or 90)
for testing pre-releases.

> Regards,
> John Ralls

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GnuCash wiki error on reCAPTCHA

[Derek Atkins]

Hi,

I'm back from my holiday so can now work to debug this.
I don't see anything specific in the logs, so I think we'll have to work
on this in more "real time".
Let me know when you're available to work on this?

(I should note that I *DID* receive email from google about having to
upgrade our reCAPTCHA interface, which I have not (yet) done -- unclear
if this is related)

-derek

Tommy Trussell  writes:

> I'm trying to update the Ubuntu page at wiki.gnucash.org that I have
> updated in the past. It's been months since I've been logged in, so I just
> logged in anew.
>
> I made the change to the page, which includes a new URL, so I get the
> reCAPTCHA.
>
> When I enter the CAPTCHA text I get a blank page containing the error
>
> "Could not open socket"
>
> I have tried Firefox and Chromium, both with the same result.
>
> Various web searches imply the error is due to a network issue between the
> wiki server and the captcha server, but the problem has persisted for more
> than a half hour.
>
> Is the problem affecting other folks, too, or am I missing something?
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel