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

[Geert Janssens]

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

[GNC-dev] Register text selection

[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 ?

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.

Regards,
Bob
___
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 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 hold 
off other changes related to text entry until that's done to avoid doing 
double work.

Geert


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

Re: [GNC-dev] Register text selection

[David Carlson]

As a concerned user, not a developer, I would vote to drop all
preselection.  I think it is confusing to users who do not necessarily
consider the differences between the various navigation methods as being
significant.

Further, in the cases where the curser is not visible in the register
window, the only way to find it is to use a trick such as pressing tab to
bring it back into the visible window, assuming it is in a transaction that
has not been hidden by the View > Filter by option, which complicates this
issue, and when the curser is in the blank transaction at the end, if the
register is in single line view it may not be visible.

That is my 2¢ *.*

David C

On Mon, May 21, 2018 at 6:08 AM, Robert Fewell <14ubo...@gmail.com> wrote:

> 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 ?
>
> 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.
>
> Regards,
> Bob
> ___
> 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

[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 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 think I will close my PR and start again if required after you have made
your changes.

Bob

On 21 May 2018 at 14:14, 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.
> >
> > 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
> hold
> off other changes related to text entry until that's done to avoid doing
> double work.
>
> Geert
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] BZ: What to do about circular deps ?

[Derek Atkins]

"Derek Atkins"  writes:

[snip]
> 106749 is marked a dupe_of 350675
> 350675 is marked a dupe of 570011
> 570011 blocks 570012
> 580012 is marked a dupe of 350675
>
> So 570011 is still open, so theoretically it should be "okay" and be in
> there "last".  Maybe I need to swap the blocks vs depends_on?  I'm not
> sure why I picked one vs. the other.

For the record, swapping the blocks/depends_on fields did the trick for
this issue.  I had been deleting the depends_on and keeping the blocked
list.  Now I delete the blocked list and keep the depends_on list.
Internally BZ modifies both sides, but I needed to ensure I can't get
into a loop like the above.  Once swapped, no more loops appeared.

Also for the record, it's VERY annoying that the json API output changes
field names, such that you cannot directly push it into the create APIs.
You need to change a bunch of field names (and in some cases then change
them back!!).   Very annoying to get right.

-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

[David T. via gnucash-devel]

> 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

[GNC-dev] BZ: Currently Ignored Fields

[Derek Atkins]

Hi,

I've been working with John today iterating over the BZ Migration.

At this point I think we've got the Status, Resolution, and Work Flow
worked out.  I've removed field values that do not apply to us, and I've
added the Gnome field values that we actually use.

I think what's left, at this point, is dealing with some additional data
that I currently toss out during the migration/import.   At least one of
these is a Gnome-BZ extension, but we should decide what, if anything, we
want to do about these:

Products:
  I set the "version" to "3.0" -- I'm not sure exactly what that means or
what effect that has.

Product Components:
  I'm deleting the sort_key and flag_types fields I downloaded from GnomeBZ

In Bugs I'm deleting:
  cf_gnome_version
  cf_gnome_target
  is_open
  flags

In Bug Comments I'm deleting:
  attachment_id
  count
  author (not sure the difference between this and the creator/"who")
  time (not sure the difference between this and bug_when/creation_time)

In Bug History:
  I'm not sure if "groups" == "bug_group"
  Because the two cf_gnome_* fields don't exist, I have to change those
 in bug history.
  attachments.gnome_attachment_status does not exist, so I have to change
 that, too, in the history.

In Bug Attachments, I'm deleting:
  attacher
  flags
  summary
  last_change_time
  size

I suspect there is a lot of data hidden in the various "flags" elements
that I'm just deleting during the import.  I know for sure that the
gnome_attachment_status data is not getting imported, but I don't know
where it can be found exactly.  There are 507 bugs that use this field.

I also don't know if I'm properly handling comments on attachments.  C.f.
Bug #630652 for an example.

-derek

PS: These field names are a combination of JSON fields obtained from the
JSON API, and the Perl/DB fields.

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

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

Re: [GNC-dev] BZ: Currently Ignored Fields

[John Ralls]

> On May 21, 2018, at 1:12 PM, Derek Atkins  wrote:
> 
> Hi,
> 
> I've been working with John today iterating over the BZ Migration.
> 
> At this point I think we've got the Status, Resolution, and Work Flow
> worked out.  I've removed field values that do not apply to us, and I've
> added the Gnome field values that we actually use.
> 
> I think what's left, at this point, is dealing with some additional data
> that I currently toss out during the migration/import.   At least one of
> these is a Gnome-BZ extension, but we should decide what, if anything, we
> want to do about these:
> 
> Products:
>  I set the "version" to "3.0" -- I'm not sure exactly what that means or
> what effect that has.
> 
> Product Components:
>  I'm deleting the sort_key and flag_types fields I downloaded from GnomeBZ
> 
> In Bugs I'm deleting:
>  cf_gnome_version
>  cf_gnome_target
>  is_open
>  flags
> 
> In Bug Comments I'm deleting:
>  attachment_id
>  count
>  author (not sure the difference between this and the creator/"who")
>  time (not sure the difference between this and bug_when/creation_time)
> 
> In Bug History:
>  I'm not sure if "groups" == "bug_group"
>  Because the two cf_gnome_* fields don't exist, I have to change those
> in bug history.
>  attachments.gnome_attachment_status does not exist, so I have to change
> that, too, in the history.
> 
> In Bug Attachments, I'm deleting:
>  attacher
>  flags
>  summary
>  last_change_time
>  size
> 
> I suspect there is a lot of data hidden in the various "flags" elements
> that I'm just deleting during the import.  I know for sure that the
> gnome_attachment_status data is not getting imported, but I don't know
> where it can be found exactly.  There are 507 bugs that use this field.
> 
> I also don't know if I'm properly handling comments on attachments.  C.f.
> Bug #630652 for an example.
> 
> -derek
> 
> PS: These field names are a combination of JSON fields obtained from the
> JSON API, and the Perl/DB fields.

Searching bugzilla.gnome.org turns up exactly one bug [1] with a flag set and 
it's not one of ours. I don't think we need to worry about there being any data 
hidden in any of the flags fields.

I found this for gnome_attachment_status: 
https://git.gnome.org/browse/bugzilla-gnome-org-customizations/log/?qt=grep&q=gnomeattachmentstatus
 are at least some of the relevant customizations Gnome made to Bugzilla 4.4. 
While it's a nice feature I'd rather that we don't customize BZ's code if we 
can avoid it, and I'd actually prefer that we push anyone making a non-trivial 
patch to doing it as a Github PR instead, so maybe not really worth too much 
effort. We have well over 900 bugs with patches against them, but only 39 
*open* ones. Only about half have status other than "none" so we clearly 
haven't been to assiduous in marking the status anyway.

In Bugs, groups is the user groups (e.g. GnuCash Developers) who can view the 
bug. Exactly one [2] was limited and it appears to have not imported. I've 
unprotected it in bz.gnome.

In Comments, "author" and "time" are redundant to "creator" and "creation_time" 
respectively for backward (*from* 4.4) compatibility. Count seems to regenerate 
itself. Unlike for bugs you're not keeping attachment numbers so you're right 
to remove them from comments.

In Attachements, attacher is redundant to creator and summary to description. 
Without gnome_attachment_status the last_change_time is probably not that 
important and it can anyway be retrieved from history, and size is probably 
computed anyway. 

Looks like we're close and can start thinking about configuring BZ unless you 
want to do something with gnome_attachment_status.

Regards,
John Ralls


[1] https://bugzilla.gnome.org/show_bug.cgi?id=626399
[2] https://bugzilla.gnome.org/show_bug.cgi?id=619984
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Chris Good]

[GNC-dev] Register text selection


Geert Janssens
 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
hold 
off other changes related to text entry until that's done to avoid doing 
double work.
 
Geert

 

I agree with Geert, the way it is, works well with how I work, and is usual
UI.

 

The fact that the current field is highlighted when you go back to the
register makes it easier to find where you are.

 

This email reminded me of another issue I wish to discuss.

The scroll bars on all the windows seem to have changed in 3.0+.

If you now click above (or below) the current position bar in the scrollbar,
it takes you to the place in the 

window which is proportional to where in the scroll bar you click, rather
than up (or down) 1 screen full.

 

This is not typical MS Windows UI and surprises me because it is not what I
expect. Suddenly I am far from 

where I was instead of just being 1 page away, and it can be laborious to
get back to where I want to be.

 

I know I can use PgUp/PgDn instead and once I get used to it, the new method
does offer extra

functionality, but I'm not sure if there is a real need to be able to go say
approx. 1/3 of the way through all 

the entries in the window.

 

Also, usually in Windows, the height of the scroll bar indicates how much
the current screen is, as a 

proportion of all entries.

 

What do other think?

 

Maybe this is an option I can set in css?

 

Regards, Chris Good

 

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

Re: [GNC-dev] Register text selection

[David Carlson]

A long time ago I filed a bug report <
https://bugzilla.gnome.org/show_bug.cgi?id=686051> 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 <
gnucash-devel@gnucash.org> 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 + V#3 Windows scroll bars.

[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&In-Reply-To=%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
> hold
> off other changes related to text entry until that's done to avoid doing
> double work.
>
> Geert
>
>
>
> I agree with Geert, the way it is, works well with how I work, and is usual
> UI.
>
>
>
> The fact that the current field is highlighted when you go back to the
> register makes it easier to find where you are.
>
>
>
> This email reminded me of another issue I wish to discuss.
>
> The scroll bars on all the windows seem to have changed in 3.0+.
>
> If you now click above (or below) the current position bar in the
> scrollbar,
> it takes you to the place in the
>
> window which is proportional to where in the scroll bar you click, rather
> than up (or down) 1 screen full.
>
>
>
> This is not typical MS Windows UI and surprises me because it is not what I
> expect. Suddenly I am far from
>
> where I was instead of just being 1 page away, and it can be laborious to
> get back to where I want to be.
>
>
>
> I know I can use PgUp/PgDn instead and once I get used to it, the new
> method
> does offer extra
>
> functionality, but I'm not sure if there is a real need to be able to go
> say
> approx. 1/3 of the way through all
>
> the entries in the window.
>
>
>
> Also, usually in Windows, the height of the scroll bar indicates how much
> the current screen is, as a
>
> proportion of all entries.
>
>
>
> What do other think?
>
>
>
> Maybe this is an option I can set in css?
>
>
>
> Regards, Chris Good
>
>
>
> ___
> 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

[D via gnucash-devel]

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.

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