Re: [GNC-dev] GDPR and terrorism

[John Ralls]

> On May 22, 2018, at 11:42 AM, Frank H. Ellenberger 
>  wrote:
> 
> Am 22.05.2018 um 19:21 schrieb Geert Janssens:
>>> IRC includes IP addresses, which the GDPR explicitly mentions as personal
>>> information, in “joined” messages, and those get logged. ISTM those
>>> messages aren’t important as they’re not part of the conversation and we
>>> could easily stop logging them delete them from the existing logs.
>>> 
>> Yes, I think we should do that.
>> 
> It depends: most private used IPv4 are dynamic IPs - changing at least
> daily. They are useless without the dial in protocol of the provider.
> That is the reason, anti terror laws try to force them to store them.
> Then again courts declare the anti terror law unconstitutional.
> 
> I don't know the current practice of providers with IPv6.
> 
> Question: How will you behave, if you see, last night XXX announced an
> terror attack on our channel?

Even with dynamically-allocated IP addresses the ISP can identify which 
customer has an address -IPv4 and IPv6-given the address and the timestamp. IP 
addresses are specifically mentioned in article 30.

I would notify local law enforcement who will pass it up the chain to the 
appropriate level. Article 19 excludes criminal activity from being protected 
under the GDPR.

Regards,
John Ralls

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

Re: [GNC-dev] GDPR and terrorism

[Frank H. Ellenberger]

Am 22.05.2018 um 19:21 schrieb Geert Janssens:
>> IRC includes IP addresses, which the GDPR explicitly mentions as personal
>> information, in “joined” messages, and those get logged. ISTM those
>> messages aren’t important as they’re not part of the conversation and we
>> could easily stop logging them delete them from the existing logs.
>>
> Yes, I think we should do that.
> 
It depends: most private used IPv4 are dynamic IPs - changing at least
daily. They are useless without the dial in protocol of the provider.
That is the reason, anti terror laws try to force them to store them.
Then again courts declare the anti terror law unconstitutional.

I don't know the current practice of providers with IPv6.

Question: How will you behave, if you see, last night XXX announced an
terror attack on our channel?

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

Re: [GNC-dev] Register text selection

[Adrien Monteleone]

David,

I just repeated your steps verbatim and I don’t get the same result.

Note, I’m using 3.1-2 on High Sierra. (Your screenshot looks like 2.6x)

When I start typing ‘12345', the field in focus is the NUM field in the first 
blank transaction in the Checking register and it reflects my typing. (as does 
the status bar.)

Though I don’t understand why you are hitting TAB after cancelling the 
Reconcile Window.

If I don’t hit tab, the focus (and active editing as expected) is on the date 
field in that same transaction. TAB only advances me to the NUM field.

Also, before sending this I remembered I still had 2.6.21 installed. So I 
tested your steps there and sure enough, I get the same result as you.

So, this is fixed in 3.1-2. (or earlier)

Regards,
Adrien

> On May 22, 2018, at 9:40 AM, David T. via gnucash-devel 
>  wrote:
> 
> Dang. The list doesn't like how Mac Mail handles attachments!
> Let's see if this will work...
> 
> 
> 
>  From: David T. via gnucash-devel 
> To: Geert Janssens  
> Cc: gnucash-devel@gnucash.org
> Sent: Tuesday, May 22, 2018 7:21 PM
> Subject: Re: [GNC-dev] Register text selection
> 
> Geert,
> 
>> On May 22, 2018, at 1:22 PM, Geert Janssens  
>> wrote:
>> 
>> Op maandag 21 mei 2018 19:44:57 CEST schreef David T.:
 On May 21, 2018, at 6:14 PM, Geert Janssens >
 wrote:> 
 Op maandag 21 mei 2018 13:08:05 CEST schreef Robert Fewell:
> I have been looking at getting the middle mouse button to work for
> pasting
> selected text and whilst trying to do that started to wonder about the
> existing preselected text.
> 
> Currently...
> If you open a register, the blank transaction date text is preselected.
> If you start Gnucash with saved open registers, the last register in the
> list to load has the blank date text preselected, this may not be the
> current open register.
>>> 
>>> I would like to point out that I find *this* aspect of the register behavior
>>> highly confusing.
>>   
>> I had to re-read the description to get what you guys mean. I have *never* 
>> seen this precise behavior as described by Bob.
>>   
>> When I open gnucash the any keypresses I type before using my mouse will 
>> always go to the currently active tab. If that's a register tab it will 
>> alter the data field as that's the field selected by default.
>>   
>> The only variation I can think of would be if you have configured gnucash to 
>> open each tab in a separate window. I don't do that and haven't tested how 
>> it behaves in that case.
> 
> I am talking about multiple tabs open in one main window.
> 
> Here is the way I can demonstrate the problem.
> 
> Open GnuCash and close all tabs except the main Chart of Accounts.
> 
> Now, in sequence, open:
> 1) Your Checking account
> 2) Your Cash account
> 
> This will result in your GnuCash having the following tabs, in order: 
> Accounts, Checking, Cash.
> 
> Next, click on the Checking account tab.
> Click Reconcile, and OK in the Reconcile Information Window. Next, in the 
> Reconcile window, immediately click Cancel.
> 
> Now, the status bar at the bottom will show the date. Press Tab. Enter a 
> number (like 12345). The status bar will show the number you are entering, 
> ***but the register on screen will NOT show any change.*** This is because 
> the data is going into the Cash tab at the bottom. 
> 
> I am attaching a screen shot of my GnuCash at this particular juncture, which 
> shows: 
> 
> * the Checking account register (as indicated in the title bar at the top)
> * the status bar with my “12345” entry indicated
> * the register itself, which shows NO 12345.
> 
> If I access the Cash tab, the information is there. Interestingly, if one 
> clicks the Cancel button while still viewing the Checking register, there is 
> no effect on the (hidden) transaction that is being edited. You can only 
> cancel the transaction when it is in the current view.
> 
> David T.
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> 
>  PM.png>___
> 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] BZ: Status of (gnome)attachment-status field

[John Ralls]

> On May 22, 2018, at 4:37 AM, Derek Atkins  wrote:
> 
> Hi,
> 
> Based on the back-and-forth with John and I yesterday, I think there is
> only one open question:  What do we want to do (if anything), about the
> gnome bugzilla extension (Gnome)AttachmentStatus?
> 
> We have three options:
> 
> 1) Nothing -- just drop and ignore the data
> 1a) Almost Nothing -- drop the actual status data but translate the
>history to something else (which might be a bit confusing)
> 2) Create a custom flag for the bug -- this probably is not right
> 3) Up-port the extension to our BZ
> 
> I should note that as far as I can tell, I ONLY see this data in the
> history; it does not look like this status has been delivered in the data.
> 
> Personally I'm for either 1 or 1a.  For 1a we just need to decide what
> to translate it to in the history.  Right now I put in "submitter", but
> we could choose "status".  Although it might just be cleaner to remove
> that history.
> 
> What say you?

Option 2 should be create a flag on the attachment. If we want to keep the 
status information this would be the easy way to do it.

See https://bugzilla.readthedocs.io/en/5.0/administering/flags.html
and https://bugzilla.readthedocs.io/en/5.0/using/editing.html#flags

I've already said that I prefer option 1 and why.

Regards,
John Ralls

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

Re: [GNC-dev] GDPR and gnucash as a project

[Geert Janssens]

Op dinsdag 22 mei 2018 16:35:24 CEST schreef John Ralls:
> > On May 22, 2018, at 6:02 AM, Geert Janssens 
> > wrote:
> > 
> > Yesterday John raised some concerns about GDPR compliance of the gnucash
> > project itself.
> > 
> > This is a different question from the one Mike Evans asked in April this
> > year about GDPR compliance by people *using* gnucash.
> > 
> > This requires some thought as the GDPR has many aspects.
> > 
> > The essence of the GDPR (global data protection regulation) is to regulate
> > the processing of EU citizen's personal data.
> > 
> > The first question this raises is which personal data does the gnucash
> > project process ? So far I have come up with:
> > - e-mail addresses on the gnucash mailing lists
> > - user accounts in bugzilla
> > - user accounts in our wiki
> > - user accounts on Uservoice
> > The above are pretty clear. There are others that are less clear to me
> > whether they constitute personal data or not:
> > - the actual messages people send to mailing lists and which are stored in
> > a public archive
> > - the actual comments on bugs
> > - the actual page edits in wiki
> > And also what about things like our irc channel ? Does that fall under
> > processing personal data ? We don't really run the irc channel, we only
> > use
> > it. But on the other hand we do publish irc logs. Does GDPR apply to those
> > ? I can't tell really.
> > And the same question could be asked about our code itself in a way. Does
> > a
> > code contribution represent personal data ? Each commit logs an e-mail
> > address of a committer which can't easily be removed.
> > 
> > Once we have established what constitutes personal data we need to
> > formulate a "privacy policy" in which we explain how we process this data
> > and whether third parties are involved (think github, uservoice,
> > travis-ci, our social media presence,...).
> > 
> > An open source project is a bit in an odd situation because we do almost
> > everything in public so there's very little being kept private. We publish
> > archives of our mailing list conversations, irc logs, commits and so on.
> > We
> > have to inform our users of this in a clear manner. The good thing is we
> > only do keep the absolute minimum amount of information to function: a
> > username (which can be an e-mail address) and a password is usually
> > sufficient. Unless the message content also falls under personal data.
> > 
> > We also require explicit consent to use the personal data. We're
> > reasonably
> > good in this respect as for all services we offer we require the user to
> > opt- in. We will never use for example mail addresses gathered from
> > bugzilla user accounts to automatically enroll the same people in a
> > mailing list. We probably should more clearly indicate what people
> > subscribe to in each case while they are registering. So when registering
> > for a mailing list, it should be pretty clear that anything the person
> > contributes will end up on a public web page. The same goes for all other
> > services we offer and make use of.
> > 
> > Next a person should be allowed to make corrections to the personal data
> > we
> > were provided with and "the right to be forgotten". For user accounts in
> > the various services we offer this is not really a problem. Most of these
> > do allow the user to change passwords, user names or e-mail addresses.
> > However if the message content is also part of private data it becomes
> > much harder. In that case the question becomes whether a user can request
> > a mail message to be removed from our mailing list archive. I have no
> > answer to this.
> > 
> > Next there is the requirement to protect children. I don't know for sure
> > if
> > this applies to us. If it does our registration processes should ask a
> > minimum age and require consent of a parent or equivalent in order to
> > continue with the registration. This is mostly mentioned in the context
> > of social networks. But as we publish all communication in public it may
> > apply to us as well.
> > 
> > And finally in case of data breaches we should inform the affected people
> > of this. Again one I don't know exactly how to deal with.
> > 
> > This mail is meant as a kick-off to start thinking about this. Any
> > feedback is very welcome.
> 
> Some more considerations:
> 
> Uservoice data lives on Uservoice’s servers, not ours, and so GDPR
> compliance there is their problem.

Probably correct. As we don't use the personal data we collect from say 
bugzilla accounts to populate uservoice accounts, we are not passing 
information to a third party here. We do use the service but not likely to be 
responsible for the personal data they collect.
> 
> We have copied from Gnome’s BZ a bunch of names and email addresses for
> reporters, commenters, and developers on GnuCash bugs without those
> people’s permission. The GDPR permits collecting information without
> permission for “business 

Re: [GNC-dev] GDPR and gnucash as a project

[Geert Janssens]

Op dinsdag 22 mei 2018 16:36:47 CEST schreef David T.:
> Geert,
> 
> I am not fluent with the issues of the GDPR, but I have had a lifetime of
> considering intellectual property issues (as a librarian). Personal
> contributions of ideas, thoughts, or intellectual content are IMHO NOT
> personal data, even when signed by an individual’s name*.

> Those would fall
> under intellectual property/copyright rules rather than personal data.

> It is my understanding also that use of GPL addresses the question of IP
> rights in code and documentation; if a user contributes to the GC project
> in these areas, they do so with this release understood.

I had given this some more thought as well. And I agree that our code and 
documentation licenses handle this.
Because of these licenses I see a code/documentation contribution as happening 
under a contract. So the GDPR doesn't apply there as far as I'm concerned.
Or put differently in my own simplified words: our code is regulated by 
copyright law. In order to be able to assert copyright (even in copyleft form) 
the author of the protected work must be known. So if someone contributes a 
patch that person must be identified together with the patch or copyright 
can't work. So "the right to be forgotten" doesn't apply due to the legal 
framework in which the personal data (user's name/email) is used.

> It is also my
> understanding that unless someone explicitly states otherwise, their
> posting of information in a public place (such as a website, wiki, mailing
> list, etc.) would constitute permission to release that information
> generally.

Sounds reasonable to me. Though we may be required to mention this more 
explicitly in various places.

> 
> David T.
> 
> * - I would be extremely surprised to find that a user’s name, in and of
> itself, would constitute protected personal information.

That does sound reasonable to me as well.

Geert


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

Re: [GNC-dev] Example migrated bug: [Bug 784378] Duplicate languages in https://l10n.gnome.org/languages/

[John Ralls]

> On May 22, 2018, at 8:47 AM, Frank H. Ellenberger 
>  wrote:
> 
> Hi,
> 
> I just got this message, closing a bug of an migrated gnome project.
> 
> ~Frank
> 
>  Weitergeleitete Nachricht 
> Betreff: [Bug 784378] Duplicate languages in
> https://l10n.gnome.org/languages/
> Datum: Tue, 22 May 2018 12:21:33 +
> Von: damned-lies (GNOME Bugzilla) 
> An: frank.h.ellenber...@gmail.com
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=784378
> 
> GNOME Infrastructure Team  changed:
> 
>   What|Removed |Added
> 
> Status|NEW |RESOLVED
> Resolution|--- |OBSOLETE
> 
> --- Comment #3 from GNOME Infrastructure Team  ---
> -- GitLab Migration Automatic Message --
> 
> This bug has been migrated to GNOME's GitLab instance and has been
> closed from
> further activity.
> 
> You can subscribe and participate further through the new bug through
> this link
> to our GitLab instance:
> https://gitlab.gnome.org/GNOME/damned-lies/issues/69.
> 

Yes, Carlos Sorianos reported on gnome-desktop-devel this morning that they’ve 
begun the “mass migration” of all projects in git.gnome.org 
 to gitlab.gnome.org . All 
associated bugs in bz.gnome will be closed; they’ll be migrated to gitlab if 
the project requested it.

Carlos also confirmed yesterday that BZ will go read-only for all other 
projects (like GnuCash) on 1 July. This is nice, we were expecting 1 June. 
Since we’re pretty close we’ll be able to pick a cutover day ourselves and 
disable new bugs on bz.gnome from our project page well before the deadline.

Regards,
John Ralls

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

[GNC-dev] Example migrated bug: [Bug 784378] Duplicate languages in https://l10n.gnome.org/languages/

[Frank H. Ellenberger]

Hi,

I just got this message, closing a bug of an migrated gnome project.

~Frank

 Weitergeleitete Nachricht 
Betreff: [Bug 784378] Duplicate languages in
https://l10n.gnome.org/languages/
Datum: Tue, 22 May 2018 12:21:33 +
Von: damned-lies (GNOME Bugzilla) 
An: frank.h.ellenber...@gmail.com

https://bugzilla.gnome.org/show_bug.cgi?id=784378

GNOME Infrastructure Team  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #3 from GNOME Infrastructure Team  ---
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been
closed from
further activity.

You can subscribe and participate further through the new bug through
this link
to our GitLab instance:
https://gitlab.gnome.org/GNOME/damned-lies/issues/69.

-- 
You are receiving this mail because:
You reported the bug.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GDPR and gnucash as a project

[David T. via gnucash-devel]

Geert,

I am not fluent with the issues of the GDPR, but I have had a lifetime of 
considering intellectual property issues (as a librarian). Personal 
contributions of ideas, thoughts, or intellectual content are IMHO NOT personal 
data, even when signed by an individual’s name*. Those would fall under 
intellectual property/copyright rules rather than personal data. It is my 
understanding also that use of GPL addresses the question of IP rights in code 
and documentation; if a user contributes to the GC project in these areas, they 
do so with this release understood. It is also my understanding that unless 
someone explicitly states otherwise, their posting of information in a public 
place (such as a website, wiki, mailing list, etc.) would constitute permission 
to release that information generally.

David T.

* - I would be extremely surprised to find that a user’s name, in and of 
itself, would constitute protected personal information. 

> On May 22, 2018, at 6:02 PM, Geert Janssens  
> wrote:
> 
> Yesterday John raised some concerns about GDPR compliance of the gnucash 
> project itself.
> 
> This is a different question from the one Mike Evans asked in April this year 
> about GDPR compliance by people *using* gnucash.
> 
> This requires some thought as the GDPR has many aspects.
> 
> The essence of the GDPR (global data protection regulation) is to regulate 
> the 
> processing of EU citizen's personal data.
> 
> The first question this raises is which personal data does the gnucash 
> project 
> process ? So far I have come up with:
> - e-mail addresses on the gnucash mailing lists
> - user accounts in bugzilla
> - user accounts in our wiki
> - user accounts on Uservoice
> The above are pretty clear. There are others that are less clear to me 
> whether 
> they constitute personal data or not:
> - the actual messages people send to mailing lists and which are stored in a 
> public archive
> - the actual comments on bugs
> - the actual page edits in wiki
> And also what about things like our irc channel ? Does that fall under 
> processing personal data ? We don't really run the irc channel, we only use 
> it. But on the other hand we do publish irc logs. Does GDPR apply to those ? 
> I 
> can't tell really.
> And the same question could be asked about our code itself in a way. Does a 
> code contribution represent personal data ? Each commit logs an e-mail 
> address 
> of a committer which can't easily be removed.
> 
> Once we have established what constitutes personal data we need to formulate 
> a 
> "privacy policy" in which we explain how we process this data and whether 
> third parties are involved (think github, uservoice, travis-ci, our social 
> media presence,...).
> 
> An open source project is a bit in an odd situation because we do almost 
> everything in public so there's very little being kept private. We publish 
> archives of our mailing list conversations, irc logs, commits and so on. We 
> have to inform our users of this in a clear manner. The good thing is we only 
> do keep the absolute minimum amount of information to function: a username 
> (which can be an e-mail address) and a password is usually sufficient. Unless 
> the message content also falls under personal data.
> 
> We also require explicit consent to use the personal data. We're reasonably 
> good in this respect as for all services we offer we require the user to opt-
> in. We will never use for example mail addresses gathered from bugzilla user 
> accounts to automatically enroll the same people in a mailing list. We 
> probably should more clearly indicate what people subscribe to in each case 
> while they are registering. So when registering for a mailing list, it should 
> be pretty clear that anything the person contributes will end up on a public 
> web page. The same goes for all other services we offer and make use of.
> 
> Next a person should be allowed to make corrections to the personal data we 
> were provided with and "the right to be forgotten". For user accounts in the 
> various services we offer this is not really a problem. Most of these do 
> allow 
> the user to change passwords, user names or e-mail addresses. However if the 
> message content is also part of private data it becomes much harder. In that 
> case the question becomes whether a user can request a mail message to be 
> removed from our mailing list archive. I have no answer to this.
> 
> Next there is the requirement to protect children. I don't know for sure if 
> this applies to us. If it does our registration processes should ask a 
> minimum 
> age and require consent of a parent or equivalent in order to continue with 
> the registration. This is mostly mentioned in the context of social networks. 
> But as we publish all communication in public it may apply to us as well.
> 
> And finally in case of data breaches we should inform the affected people of 
> this. Again one I don't know 

Re: [GNC-dev] [GNC] feature request, select all on reconcille

[Dennis Powless]

I do not have gnucash/glade either.

I've noticed there are several files that deal with the reconcile
window and I was directed to this one in particular.
window-reconcile.c

I will direct my work on this file.  I've got some reading to do, in
order to get up to speed.  Particularly with gtk

D


On Mon, May 21, 2018 at 5:27 AM, Geert Janssens
 wrote:
> Op zondag 20 mei 2018 16:13:56 CEST schreef John Ralls:
>> > On May 19, 2018, at 5:46 PM, Dennis Powless  wrote:
>> >
>> > Ok, yes it would seem glade is much, much easier.  However, I was not able
>> > to open window-reconcile.c in glade, am I missing something?  I thought
>> > that was a gtk output? I'll look over some of the gnucash pages,
>> > https://wiki.gnucash.org/wiki/Development_Process
>> >  for background to get
>> > up to speed.  Forgive me if I'm asking obvious questions, but i'll come
>> > along with some coaching (or directing to documentation).
>> >
>> > Are there any other specific prerequisites I need to learn?
>> >
>> > I'll have to sign up for GIT and learn about that too.
>>
>> The files that Glade works on are in gnucash/glade, gnucash/ui, and
>> gnucash/gtkbuilder.
>
> As far as I know glade (the tool) will only be able to work with files in
> gnucash/gtkbuilder.
>
> gnucash/glade does not exist in my git clone. I wonder if it exists on your
> system and if so I wonder why.
>
> gnucash/ui does contain menu definitions also written in xml but my glade tool
> won't open them.
>
> Geert
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Request to mailing list gnucash-devel rejected

[Dennis Powless]

Nice catch, I used the wrong email address on the outgoing message...
I've updated it.

Thanks,

Dennis

On Tue, May 22, 2018 at 9:08 AM, Adrien Monteleone
 wrote:
> This happens to me when I don’t catch my e-mail client selecting the wrong 
> e-mail account as the sender. (I manage several)
>
> Regards,
> Adrien
>
>> On May 22, 2018, at 8:01 AM, Dennis Powless  wrote:
>>
>> I'm registered to the list, at least on my end.  I'll direct to the git
>> mailing list.
>>
>> Let me know if this is different on your end?
>>
>> Dennis
>>
>>
>>
>> On Tue, May 22, 2018 at 2:00 AM,  wrote:
>>
>>> Your request to the gnucash-devel mailing list
>>>
>>>Posting of your message titled "Git"
>>>
>>> has been rejected by the list moderator.  The moderator gave the
>>> following reason for rejecting your request:
>>>
>>> "Non-members are not allowed to post messages to this list. I suggest
>>> you ask this on a "Git list"."
>>>
>>> Any questions or comments should be directed to the list administrator
>>> at:
>>>
>>>gnucash-devel-ow...@gnucash.org
>>>
>> ___
>> 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] Register text selection

[David T. via gnucash-devel]

Geert,

> On May 22, 2018, at 1:22 PM, Geert Janssens  
> wrote:
> 
> Op maandag 21 mei 2018 19:44:57 CEST schreef David T.:
> > > On May 21, 2018, at 6:14 PM, Geert Janssens  > > >
> > > wrote:> 
> > > Op maandag 21 mei 2018 13:08:05 CEST schreef Robert Fewell:
> > >> I have been looking at getting the middle mouse button to work for
> > >> pasting
> > >> selected text and whilst trying to do that started to wonder about the
> > >> existing preselected text.
> > >> 
> > >> Currently...
> > >> If you open a register, the blank transaction date text is preselected.
> > >> If you start Gnucash with saved open registers, the last register in the
> > >> list to load has the blank date text preselected, this may not be the
> > >> current open register.
> > 
> > I would like to point out that I find *this* aspect of the register behavior
> > highly confusing.
>  
> I had to re-read the description to get what you guys mean. I have *never* 
> seen this precise behavior as described by Bob.
>  
> When I open gnucash the any keypresses I type before using my mouse will 
> always go to the currently active tab. If that's a register tab it will alter 
> the data field as that's the field selected by default.
>  
> The only variation I can think of would be if you have configured gnucash to 
> open each tab in a separate window. I don't do that and haven't tested how it 
> behaves in that case.

I am talking about multiple tabs open in one main window.

Here is the way I can demonstrate the problem.

Open GnuCash and close all tabs except the main Chart of Accounts.

Now, in sequence, open:
1) Your Checking account
2) Your Cash account

This will result in your GnuCash having the following tabs, in order: Accounts, 
Checking, Cash.

Next, click on the Checking account tab.
Click Reconcile, and OK in the Reconcile Information Window. Next, in the 
Reconcile window, immediately click Cancel.

Now, the status bar at the bottom will show the date. Press Tab. Enter a number 
(like 12345). The status bar will show the number you are entering, ***but the 
register on screen will NOT show any change.*** This is because the data is 
going into the Cash tab at the bottom. 

I am attaching a screen shot of my GnuCash at this particular juncture, which 
shows: 

* the Checking account register (as indicated in the title bar at the top)
* the status bar with my “12345” entry indicated
* the register itself, which shows NO 12345.

If I access the Cash tab, the information is there. Interestingly, if one 
clicks the Cancel button while still viewing the Checking register, there is no 
effect on the (hidden) transaction that is being edited. You can only cancel 
the transaction when it is in the current view.

David T.

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

Re: [GNC-dev] GDPR and gnucash as a project

[Adrien Monteleone]

Psuedonymization can be used in most if not all cases of removal requests to 
maintain data but render it ’not personal’.

There are also exceptions for data deemed necessary for and that is still being 
used for its original intended purpose which should drastically reduce even 
those cases.

Regards,
Adrien


> On May 22, 2018, at 8:02 AM, Geert Janssens  
> wrote:
> 
> Yesterday John raised some concerns about GDPR compliance of the gnucash 
> project itself.
> 
> This is a different question from the one Mike Evans asked in April this year 
> about GDPR compliance by people *using* gnucash.
> 
> This requires some thought as the GDPR has many aspects.
> 
> The essence of the GDPR (global data protection regulation) is to regulate 
> the 
> processing of EU citizen's personal data.
> 
> The first question this raises is which personal data does the gnucash 
> project 
> process ? So far I have come up with:
> - e-mail addresses on the gnucash mailing lists
> - user accounts in bugzilla
> - user accounts in our wiki
> - user accounts on Uservoice
> The above are pretty clear. There are others that are less clear to me 
> whether 
> they constitute personal data or not:
> - the actual messages people send to mailing lists and which are stored in a 
> public archive
> - the actual comments on bugs
> - the actual page edits in wiki
> And also what about things like our irc channel ? Does that fall under 
> processing personal data ? We don't really run the irc channel, we only use 
> it. But on the other hand we do publish irc logs. Does GDPR apply to those ? 
> I 
> can't tell really.
> And the same question could be asked about our code itself in a way. Does a 
> code contribution represent personal data ? Each commit logs an e-mail 
> address 
> of a committer which can't easily be removed.
> 
> Once we have established what constitutes personal data we need to formulate 
> a 
> "privacy policy" in which we explain how we process this data and whether 
> third parties are involved (think github, uservoice, travis-ci, our social 
> media presence,...).
> 
> An open source project is a bit in an odd situation because we do almost 
> everything in public so there's very little being kept private. We publish 
> archives of our mailing list conversations, irc logs, commits and so on. We 
> have to inform our users of this in a clear manner. The good thing is we only 
> do keep the absolute minimum amount of information to function: a username 
> (which can be an e-mail address) and a password is usually sufficient. Unless 
> the message content also falls under personal data.
> 
> We also require explicit consent to use the personal data. We're reasonably 
> good in this respect as for all services we offer we require the user to opt-
> in. We will never use for example mail addresses gathered from bugzilla user 
> accounts to automatically enroll the same people in a mailing list. We 
> probably should more clearly indicate what people subscribe to in each case 
> while they are registering. So when registering for a mailing list, it should 
> be pretty clear that anything the person contributes will end up on a public 
> web page. The same goes for all other services we offer and make use of.
> 
> Next a person should be allowed to make corrections to the personal data we 
> were provided with and "the right to be forgotten". For user accounts in the 
> various services we offer this is not really a problem. Most of these do 
> allow 
> the user to change passwords, user names or e-mail addresses. However if the 
> message content is also part of private data it becomes much harder. In that 
> case the question becomes whether a user can request a mail message to be 
> removed from our mailing list archive. I have no answer to this.
> 
> Next there is the requirement to protect children. I don't know for sure if 
> this applies to us. If it does our registration processes should ask a 
> minimum 
> age and require consent of a parent or equivalent in order to continue with 
> the registration. This is mostly mentioned in the context of social networks. 
> But as we publish all communication in public it may apply to us as well.
> 
> And finally in case of data breaches we should inform the affected people of 
> this. Again one I don't know exactly how to deal with.
> 
> This mail is meant as a kick-off to start thinking about this. Any feedback 
> is 
> very welcome.
> 
> Regards,
> 
> Geert
> 
> 
> ___
> 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] Request to mailing list gnucash-devel rejected

[Adrien Monteleone]

This happens to me when I don’t catch my e-mail client selecting the wrong 
e-mail account as the sender. (I manage several)

Regards,
Adrien

> On May 22, 2018, at 8:01 AM, Dennis Powless  wrote:
> 
> I'm registered to the list, at least on my end.  I'll direct to the git
> mailing list.
> 
> Let me know if this is different on your end?
> 
> Dennis
> 
> 
> 
> On Tue, May 22, 2018 at 2:00 AM,  wrote:
> 
>> Your request to the gnucash-devel mailing list
>> 
>>Posting of your message titled "Git"
>> 
>> has been rejected by the list moderator.  The moderator gave the
>> following reason for rejecting your request:
>> 
>> "Non-members are not allowed to post messages to this list. I suggest
>> you ask this on a "Git list"."
>> 
>> Any questions or comments should be directed to the list administrator
>> at:
>> 
>>gnucash-devel-ow...@gnucash.org
>> 
> ___
> 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

[GNC-dev] GDPR and gnucash as a project

[Geert Janssens]

Yesterday John raised some concerns about GDPR compliance of the gnucash 
project itself.

This is a different question from the one Mike Evans asked in April this year 
about GDPR compliance by people *using* gnucash.

This requires some thought as the GDPR has many aspects.

The essence of the GDPR (global data protection regulation) is to regulate the 
processing of EU citizen's personal data.

The first question this raises is which personal data does the gnucash project 
process ? So far I have come up with:
- e-mail addresses on the gnucash mailing lists
- user accounts in bugzilla
- user accounts in our wiki
- user accounts on Uservoice
The above are pretty clear. There are others that are less clear to me whether 
they constitute personal data or not:
- the actual messages people send to mailing lists and which are stored in a 
public archive
- the actual comments on bugs
- the actual page edits in wiki
And also what about things like our irc channel ? Does that fall under 
processing personal data ? We don't really run the irc channel, we only use 
it. But on the other hand we do publish irc logs. Does GDPR apply to those ? I 
can't tell really.
And the same question could be asked about our code itself in a way. Does a 
code contribution represent personal data ? Each commit logs an e-mail address 
of a committer which can't easily be removed.

Once we have established what constitutes personal data we need to formulate a 
"privacy policy" in which we explain how we process this data and whether 
third parties are involved (think github, uservoice, travis-ci, our social 
media presence,...).

An open source project is a bit in an odd situation because we do almost 
everything in public so there's very little being kept private. We publish 
archives of our mailing list conversations, irc logs, commits and so on. We 
have to inform our users of this in a clear manner. The good thing is we only 
do keep the absolute minimum amount of information to function: a username 
(which can be an e-mail address) and a password is usually sufficient. Unless 
the message content also falls under personal data.

We also require explicit consent to use the personal data. We're reasonably 
good in this respect as for all services we offer we require the user to opt-
in. We will never use for example mail addresses gathered from bugzilla user 
accounts to automatically enroll the same people in a mailing list. We 
probably should more clearly indicate what people subscribe to in each case 
while they are registering. So when registering for a mailing list, it should 
be pretty clear that anything the person contributes will end up on a public 
web page. The same goes for all other services we offer and make use of.

Next a person should be allowed to make corrections to the personal data we 
were provided with and "the right to be forgotten". For user accounts in the 
various services we offer this is not really a problem. Most of these do allow 
the user to change passwords, user names or e-mail addresses. However if the 
message content is also part of private data it becomes much harder. In that 
case the question becomes whether a user can request a mail message to be 
removed from our mailing list archive. I have no answer to this.

Next there is the requirement to protect children. I don't know for sure if 
this applies to us. If it does our registration processes should ask a minimum 
age and require consent of a parent or equivalent in order to continue with 
the registration. This is mostly mentioned in the context of social networks. 
But as we publish all communication in public it may apply to us as well.

And finally in case of data breaches we should inform the affected people of 
this. Again one I don't know exactly how to deal with.

This mail is meant as a kick-off to start thinking about this. Any feedback is 
very welcome.

Regards,

Geert


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

Re: [GNC-dev] Request to mailing list gnucash-devel rejected

[Dennis Powless]

I'm registered to the list, at least on my end.  I'll direct to the git
mailing list.

Let me know if this is different on your end?

Dennis



On Tue, May 22, 2018 at 2:00 AM,  wrote:

> Your request to the gnucash-devel mailing list
>
> Posting of your message titled "Git"
>
> has been rejected by the list moderator.  The moderator gave the
> following reason for rejecting your request:
>
> "Non-members are not allowed to post messages to this list. I suggest
> you ask this on a "Git list"."
>
> Any questions or comments should be directed to the list administrator
> at:
>
> gnucash-devel-ow...@gnucash.org
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] BZ: Status of (gnome)attachment-status field

[Derek Atkins]

Hi,

Based on the back-and-forth with John and I yesterday, I think there is
only one open question:  What do we want to do (if anything), about the
gnome bugzilla extension (Gnome)AttachmentStatus?

We have three options:

1) Nothing -- just drop and ignore the data
1a) Almost Nothing -- drop the actual status data but translate the
history to something else (which might be a bit confusing)
2) Create a custom flag for the bug -- this probably is not right
3) Up-port the extension to our BZ

I should note that as far as I can tell, I ONLY see this data in the
history; it does not look like this status has been delivered in the data.

Personally I'm for either 1 or 1a.  For 1a we just need to decide what
to translate it to in the history.  Right now I put in "submitter", but
we could choose "status".  Although it might just be cleaner to remove
that history.

What say you?

-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: [GNC-dev] Register text selection

[Geert Janssens]

Op maandag 21 mei 2018 17:33:25 CEST schreef Robert Fewell:
> Sorry I did not explain the third option very well, have a transaction
> between say "Checking Account" and "Cash in Wallet" with both registers
> open.
> Position the cursor on a transaction somewhere in the "Checking Account",
> go back to the "Cash in Wallet" and edit a transaction between the two and
> commit it.
> If you go back to the "Checking Account" you will find the text highlighted
> where the cursor was.
> 
I don't know if I see the same as you do:
I have opened my checking account and a credit card account side by side.
I click in the description field of the same transaction in both windows. So 
the text cursor (the vertical "caret") is visible in both.
I now choose either window to make a change to the description field (one 
character or complete text makes no difference). After committing the change 
the description in the other window updates as well and the text caret ends up 
at the end of the new description.

So far this looks like expected behavior to me.

On the other hand while digging deeper into something I've hit some kind of a 
race condition: starting from the setup above
- I change the description field text in one window, but don't commit yet
- Then I change the description field text in the other window (to something 
different from the first window) and commit.
=> The description field in the first window remains as I set it in the first 
step while the field in the second window gets updated.
- then I commit the change in the first window
=> The description field in both windows now updates to the value I set in the 
first window.

This has been duly reported by David Carlson in the past:
https://bugzilla.gnome.org/show_bug.cgi?id=686052

While in itself this is correct behavior it can be very confusing if one of 
the changes happened accidentally. I don't know how hard it would be to catch 
such a situation and warn the user about it. I thought it worth pointing out 
though.

> I had a look at the "Edit Account Dialog" and the "Edit Customer Dialog",
> both do not preselect the first entry when opened and the cursor is at the
> beginning of that entry. When you tab to the next entry it is preselected
> but with the cursor hidden. If you type a letter, the cursor becomes
> visible as usual or if you left arrow it shows at the start or right arrow
> it shows at the end of the text.
> 
I see what you mean. And apparently I didn't fully grasp your original 
question. My replies were based on navigation in general, not what the initial 
state should be when opening a register.

I still believe we should have the selected field highlighted completely when 
first opening. The reasoning behind this is the register is our main data 
entry element so it should be optimized for efficient data entry.

Compare this for example with libreoffice calc. When you open a sheet you can 
start typing immediately. There is an active cell and whatever was in there 
will be replaced. The experience doesn't match 100% with the gnucash register 
because calc uses a dedicated field on top of the page for cell entry in 
addition to direct cell editing and they don't highlight the active cell when 
tabbing into it. I think that's less clear though and I see many new users of 
a spreadsheet getting confused on that. But the point I'm trying to make is 
that in both cases typing your first key will replace the full contents of the 
selected cell. This model is different when using mouse navigation.

While we're on this subject anyway I came across a request not so long ago to 
also save our register cursor when closing gnucash in addition to the tabs and 
windows that are open. I can't find it immediately but I think that's also a 
valid improvement.

> I think I will close my PR and start again if required after you have made
> your changes.

Ok.

Geert


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

Re: [GNC-dev] Register text selection

[Geert Janssens]

Op dinsdag 22 mei 2018 04:02:16 CEST schreef D:
> Rather than change the message (which is still a good idea), I think we
> should in this case fix the messenger--in other words, stop highlighting
> off screen data elements and stop allowing users to change things they
> cannot see.
> 
> David T.
> 
I agree on this part. The text entry focus should always be in the top most 
visible window. And if it's scrolled out of sight the first keystroke should 
scroll the edit field into view. I think this should be filed as a separate 
bug though.

But as explained in my previous mail this is only half of the story. A user 
can create pending edits regardless. And for me this is the essence of 
https://bugzilla.gnome.org/show_bug.cgi?id=686051
I have thought a bit about this and I think preventing pending edits in non-
active tabs or windows is pretty difficult (and may have unwanted side-
effects) so improving the message and guiding the user to the pending edit is 
probably more realistic.

Geert

> On May 22, 2018, at 5:39 AM, David Carlson 
> wrote:
> 
> A long time ago I filed a bug report
>  about needing to have
> an easy way to navigate to those edited but not committed transactions that
> trigger the warnings when closing the file or clicking on Save.  I vote to
> escalate that bug.
> 
> 
> David C
> 
> On Mon, May 21, 2018 at 12:44 PM, David T. via gnucash-devel  wrote:
> > On May 21, 2018, at 6:14 PM, Geert Janssens 
> > wrote:> 
> > Op maandag 21 mei 2018 13:08:05 CEST schreef Robert Fewell:
> >> I have been looking at getting the middle mouse button to work for
> >> pasting
> >> selected text and whilst trying to do that started to wonder about the
> >> existing preselected text.
> >> 
> >> Currently...
> >> If you open a register, the blank transaction date text is preselected.
> >> If you start Gnucash with saved open registers, the last register in the
> >> list to load has the blank date text preselected, this may not be the
> >> current open register.
> 
> I would like to point out that I find *this* aspect of the register behavior
> highly confusing. The “Select a field in a register that is not the current
> one” problem crops up at other times. I am not certain, but I think it
> happens when a modal dialog is closed. It is extremely frustrating to be
> working in a register that is not the bottom-most and then discover that
> your typing is going into a register that is NOT the one you are currently
> working in! Moreover, you may not even be aware that you are changing a
> transaction that is out of sight—and if you choose to leave GnuCash at this
> juncture, you will get a mysterious dialog asking if you want to save your
> changes (huh? what changes? I guess I better!). And THEN, you have no idea
> the next time what happened in that OTHER register.
> 
> I am grateful that someone else has seen this behavior and commented on it.
> I’d like to see it changed.
> 
> David T.
> 
> 
> 
> 
> ___
> 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] Register text selection

[Geert Janssens]

Op maandag 21 mei 2018 19:44:57 CEST schreef David T.:
> > On May 21, 2018, at 6:14 PM, Geert Janssens 
> > wrote:> 
> > Op maandag 21 mei 2018 13:08:05 CEST schreef Robert Fewell:
> >> I have been looking at getting the middle mouse button to work for
> >> pasting
> >> selected text and whilst trying to do that started to wonder about the
> >> existing preselected text.
> >> 
> >> Currently...
> >> If you open a register, the blank transaction date text is preselected.
> >> If you start Gnucash with saved open registers, the last register in the
> >> list to load has the blank date text preselected, this may not be the
> >> current open register.
> 
> I would like to point out that I find *this* aspect of the register behavior
> highly confusing.

I had to re-read the description to get what you guys mean. I have *never* seen 
this precise 
behavior as described by Bob.

When I open gnucash the any keypresses I type before using my mouse will always 
go to the 
currently active tab. If that's a register tab it will alter the data field as 
that's the field selected 
by default.

The only variation I can think of would be if you have configured gnucash to 
open each tab in a 
separate window. I don't do that and haven't tested how it behaves in that case.

> The “Select a field in a register that is not the current
> one” problem crops up at other times. I am not certain, but I think it
> happens when a modal dialog is closed. It is extremely frustrating to be
> working in a register that is not the bottom-most and then discover that
> your typing is going into a register that is NOT the one you are currently
> working in!

That also sounds like you are opening registers in multiple windows ?

> Moreover, you may not even be aware that you are changing a
> transaction that is out of sight—and if you choose to leave GnuCash at this
> juncture, you will get a mysterious dialog asking if you want to save your
> changes (huh? what changes? I guess I better!). And THEN, you have no idea
> the next time what happened in that OTHER register.

I have seen this "mysterious dialog" pop up at times so I agree there's room 
for improvement.

I know closing a modal dialog is not the only way to get it. It can be 
triggered by an action as 
simple as starting a change in one register and forgetting to complete it 
before moving to 
another making other changes.

For example I frequently hit this when I am clearing (not reconciling) splits. 
That's done by 
clicking in the "n" in the reconcile state column of a register. The click 
changes the "n" to "c" but 
the state change is only complete when I *leave* the transaction. Something I 
frequently forget 
to do for the last transaction I'm changing.

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

Re: [GNC-dev] Register text selection + V#3 Windows scroll bars.

[Geert Janssens]

This is another behavioral change we got "for free" from Gtk3.

Luckily this one is configurable [1] by adding
gtk-primary-button-warps-slider = false
to the [Settings] section of gtk3's settings.ini file

The location of this file is platform dependent.

On systems following the Freedesktop specification (being linux, gnucash on 
macports, most 
bsd's,...) settings.ini should be created (if not exists yet)
in
$HOME/.config/gtk-3.0
$HOME is a special shell variable and refers to your home directory.
For example
/home/someuser/.config/gtk-3.0/settings.ini

On Windows this file should reside in
%localappdata%\gtk-3.0
%localappdata% is a special Windows variable and refers to a location to store 
local user 
specific configuration files.
For example
c:\Users\someuser\AppData\Local\gtk-3.0

For our OS X/Quartz the settings.ini file will be searched for in
$HOME/Library/Application Support/Gnucash/config/gtk-3.0
Like on linux $HOME refers to your home direcory.
For example
/home/someuser/Library/Application Support/Gnucash/config/gtk-3.0/settings.ini

Geert

[1] According to this AskUbuntu forum topic:
https://askubuntu.com/questions/295988/how-to-fix-gtk3-scrollbar-behavior

Op dinsdag 22 mei 2018 02:47:01 CEST schreef David Carlson:
> I have seen that proportional scrollbar jumping behavior in some other
> Linux applications, and I too dislike it.  In very long lists like our
> registers become after a while, it is not easy to scroll several screens up
> or down frequently.  I think that it is a GTK thing.  If there is a
> work-around, I would like to know about it.
> 
> David C
> 
> On Mon, May 21, 2018 at 7:36 PM, Chris Good  wrote:
> > [GNC-dev] Register text selection
> > 
> > 
> > Geert Janssens
> >  > 20Re%3A%20%5BGNC-dev%5D%20Re
> > gister%20text%20selection=%3C1925551.
> > T7MvD3KevP%40legolas.kobalt
> > wit.lan%3E> geert.gnucash at kobaltwit.be
> > Mon May 21 09:14:29 EDT 2018
> > 
> >   _
> > 
> > Op maandag 21 mei 2018 13:08:05 CEST schreef Robert Fewell:
> > > I have been looking at getting the middle mouse button to work for
> > 
> > pasting
> > 
> > > selected text and whilst trying to do that started to wonder about the
> > > existing preselected text.
> > > 
> > > Currently...
> > > If you open a register, the blank transaction date text is preselected.
> > > If you start Gnucash with saved open registers, the last register in the
> > > list to load has the blank date text preselected, this may not be the
> > > current open register.
> > > 
> > > If you navigate by keyboard, the next field text is preselected and the
> > > cursor set to the end of text.
> > > If you navigate by mouse, the text is not selected and the cursor is the
> > > mouse position.
> > > If you update a transaction in one register and have the other
> > > corresponding register open, the text where the cursor is will get
> > > selected. (I think this is an easy fix).
> > > 
> > > I am just wondering if we should be doing this preselected text at all ?
> > 
> > As far as I can tell the first two (text navigation hightlights the full
> > text,
> > mouse navigation sets the text cursor) are at least common behavior, if
> > not
> > default. Find any dialog with more than one text field and try what
> > happens
> > if
> > you tab from one field to the next or click in random fields. I would find
> > it
> > disturbing if the register would behave differently.
> > 
> > I don't understand exactly what you mean with the third behavior.
> > 
> > > Some might say it is a good indication of where the focus is, only with
> > > keyboard navigation, but one could simply add something like this to
> > > your
> > > css file which would also work for mouse navigation...
> > > 
> > > cursor entry {
> > > 
> > >   background-color: pink;
> > > 
> > > }
> > > 
> > > So just asking the question.
> > 
> > It's not just a matter of visual indication. It's also about ergonomics.
> > Text
> > and mouse navigation have different dynamics and this is reflected in the
> > way
> > text is selected or not when entering a text field.
> > 
> > For your information I plan to work in this area of the code soon to fix
> > input
> > methods. I intend to drop all code related to text manipulation from the
> > sheet
> > and make the gtk entry responsible for it instead. Perhaps it's best you
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel