Re: [GNC-dev] Translators: Re: To colon or not to colon

2019-11-04 Thread Robert Fewell
Frank,
Yes the trailing space is a mistake so was going to get rid of that any
way, possibly it was added for alignment.

So, the only other question as part of this is whether the labels should be
left aligned or right and again there is a mix of the two in various
dialogs.
The page you linked to says they should be right aligned so there is the
minimum space between the label and control but I quite like it being left.

As part of the changes to use grids, I will probably need to set this so I
just want it to be consistent and only change it once.

Any thoughts, left or right aligned ?

Regards,
Bob

On Sun, 3 Nov 2019 at 23:08, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Hi Bob,
>
> Am Do., 31. Okt. 2019 um 12:11 Uhr schrieb Robert Fewell <
> 14ubo...@gmail.com>:
> >
> > Hi,
> > I have PR563 which I want to progress and it has a couple of commits that
> > either add a missing colon or remove a trailing space from a label with a
> > colon next to a entry widget. These will require translation changes so I
> > was wondering if there is a consensus of whether these sort of labels
> > should or should not have a trailing colon.
>
> IMHO a trailing space should be seen as an input error and be fixed
> immediately.
>
> In the times of command line interfaces, the colon was common to show,
> the program is waiting for input.
> This was also inherited in the first simple GUI's.
> But as of today, there are other properties like text style to
> distinguish input field labels from content, see i.e.
> https://developer.gnome.org/hig/stable/visual-layout.html.en. So we
> should remove them.
>
> But because we usually add mnemonics, they will still in most cases
> still be different from the base words. OTOH if we are consistent, we
> should still reduce the number of translatable strings.
>
> If nobody *protests now*, we should remove them immediately.
>
> > Looking at other places, the job dialogue doesn't, the invoice page
> > doesn't, the transfer dialogue does, the schedule dialogue also does and
> > also the print dialogue mostly.
> >
> > I would imagine if this was consistently done it may reduce the number of
> > translations a bit.
> >
> > Regards,
> > Bob
>
> Regards
> Frank
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Translators: Re: To colon or not to colon

2019-11-04 Thread Frank H. Ellenberger
Hi Bob,

Am 04.11.19 um 12:01 schrieb Robert Fewell:
:
> So, the only other question as part of this is whether the labels should be
> left aligned or right and again there is a mix of the two in various
> dialogs.
> The page you linked to says they should be right aligned so there is the
> minimum space between the label and control but I quite like it being left.
>
> As part of the changes to use grids, I will probably need to set this so I
> just want it to be consistent and only change it once.
>
> Any thoughts, left or right aligned ?

The benefit of the right alignment: It is easily comprehensible which
label belongs to which control element. This would be harder, if you
have one long and many short labels and align them left.

Their exception is the existence of options, which depend on a
previous option, i.e. in Edit->Preferences>Scheduled Transactions
"Notify before transactions are created" is only vailable, if
"Auto-create new transactions" is enabled. I am wondering, if there is
a smarter solution.

Another question: How will the elements behave for RTL writing?

> Regards,
> Bob
:
>> https://developer.gnome.org/hig/stable/visual-layout.html.en

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


Re: [GNC-dev] Translators: Re: To colon or not to colon

2019-11-04 Thread Robert Fewell
Frank,
So it looks like get rid of trailing colon/space and right align text for
normal dialogues.

For RTL, GTK already swaps the label and control along with the alignment
which I have observed on the 'View Invoice page'.

The preference dialogue may need to be treated differently, not sure yet
and there is also no indents for RTL, will need to be looked at separately
along with some other RTL stuff I have been thinking about.

For removing the trailing colon, 35 out of 66 glade files and maybe some
source files would need to be changed which is probably too many changes
for maint in one hit all be it in a few commits.
Then on top of that, changing from GTK boxes to grids and the alignment
changes, I am just not sure what to do on maint and what to do on master?

Regards,
Bob

On Mon, 4 Nov 2019 at 16:05, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Hi Bob,
>
> Am 04.11.19 um 12:01 schrieb Robert Fewell:
> :
> > So, the only other question as part of this is whether the labels should
> be
> > left aligned or right and again there is a mix of the two in various
> > dialogs.
> > The page you linked to says they should be right aligned so there is the
> > minimum space between the label and control but I quite like it being
> left.
> >
> > As part of the changes to use grids, I will probably need to set this so
> I
> > just want it to be consistent and only change it once.
> >
> > Any thoughts, left or right aligned ?
>
> The benefit of the right alignment: It is easily comprehensible which
> label belongs to which control element. This would be harder, if you
> have one long and many short labels and align them left.
>
> Their exception is the existence of options, which depend on a
> previous option, i.e. in Edit->Preferences>Scheduled Transactions
> "Notify before transactions are created" is only vailable, if
> "Auto-create new transactions" is enabled. I am wondering, if there is
> a smarter solution.
>
> Another question: How will the elements behave for RTL writing?
>
> > Regards,
> > Bob
> :
> >> https://developer.gnome.org/hig/stable/visual-layout.html.en
>
> Regards
> Frank
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


[GNC-dev] Bug 797463 - CSV Import of transactions into a new file hangs

2019-11-04 Thread Christian Gruber
I have some questions related to Bug 797463 
, which I have analyzed.


The author wrote, that "Gnu Cash hangs", when importing (only two) 
transactions into a Gnu Cash file with standard accounts list SKR04.


My analysis showed, that actually Gnu Cash does not hang, but needs 
really long time for import (several minutes). The problem is, that the 
author has bayesian matching enabled in his preferences, but the Gnu 
Cash file is not prepared for bayesian matching (feature 
GNC_FEATURE_GUID_FLAT_BAYESIAN is not set in the Gnu Cash file). 
Moreover the Gnu Cash file contains a lot of accounts (approx. 1000).


Most time is spent in function check_import_map_data(), which is called 
from gnc_account_imap_find_account_bayes() (Account.cpp). In this 
function imap_convert_bayes_to_flat() is called, which AFAICS prepares 
all accounts for bayesian matching.


I'm not familiar with that conversion step and therefore have several 
questions:


Why does the conversion need so much CPU time?

If the conversion needs so much CPU time, why is it done only 
temporarily? The conversion is done for each of the two transactions again.


Why is the conversion even not persistent after the import is done? The 
feature GNC_FEATURE_GUID_FLAT_BAYESIAN is not set in the Gnu Cash file, 
even not after the import is finished.


Regards,
Christian

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