Date: prev next · Thread: first prev next last
March 2016 Archives by date, by thread · List index


https://bugs.documentfoundation.org/show_bug.cgi?id=57174

--- Comment #10 from Eric Harman <harman.eric@gmail.com> ---
(In reply to Katarina Behrens from comment #4)
This bug has been fixed as a part of GSoC 2015 application process. While I
would accept the code as non-trivial easy hack, thus a valid GSoC
application (the candidate fixed the bug and demonstrated understanding of
LibO code), I do question the validity of this bug. Here is why:

1. Sure, selecting (highlighting) the value  of a text|spin box makes it
easier for the user to delete the value or input their own value. But some
users might want to use the mouse and change the spin box value by clicking
on spin buttons. Highlighting the value might become confusing for them. One
man's bug is the other man's feature

2. What to do if there are more input fields in the dialog? Select the first
one? Or some other one? What if it's not the one the user wants to change?
(selecting multiple input fields is iirc not possible)

3. Finally, if we decide to select (hightlight) the values of input field(s)
on opening the dialog, we should do it consistently in every LibO dialog and
sidebar. 

UX team: any thoughts?

I would like to comment on these points. 

1. I see your point on this, but disagree. It's true that a user might be
somewhat confused by seeing a text|spin box highlighted, but simply clicking on
the up/down controls would quickly confirm the behavior. For someone who is
ready to type the new value with the keyboard they would forever be stuck
deleting or highlighting the value before they could do this. 

2. Perhaps my original title is unclear. My ticket was more about the value in
the control that has focus not being selected, not a matter of which control
has focus. My point is that whichever one has focus it should be selected so
that I can easily change the value without extra keystrokes to select/delete
initial value. 

3. Agree. I have seen some a mix of behaviors in LibO dialogs and I believe
unless there is some specific functional reason for a particular dialog they
should be consistent within the app. 

I did a quick check this morning and found any of a number of Windows examples
where the value in the control with focus is highlighted:

Notepad: Edit, Goto 
Notepad: Format, Font 
Notepad++ 6.9: Search, Find… [if it auto-fills the nearest string] 
Firefox 45.0: File, Save Page As… (suggested filename) 
Firefox 45.0: Edit, Find (highlights previous search term) 
Libre Office Writer 4.1.2.3: File, Save As… (standard dialog) 
Libre Office Writer 4.1.2.3: File, Save A Copy… (standard dialog) 
Libre Office Writer 4.1.2.3: File, Print… (Number of copies) 
Libre Office Writer 4.1.2.3: Edit, Find & Replace… 
Windows: standard Save dialog for apps that suggest a filename (Paint,
Notepad…)

-- 
You are receiving this mail because:
You are the assignee for the bug.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.