After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 793516 - Make on-canvas text settings behavior more intuitive
Make on-canvas text settings behavior more intuitive
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: User Interface
2.8.22
Other All
: Normal normal
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2018-02-16 17:02 UTC by Simon Müller
Modified: 2018-05-24 19:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Simon Müller 2018-02-16 17:02:04 UTC
Currently, the on-canvas text settings box is kind of counter-intuitive when no text is selected. 

Behavior when text is selected: Everything works as expected, all settings are applied to the selected text.

Behavior when no text is selected: The buttons for text styles (bold, italic, ...) can be pressed and the selected style is applied to all text that is typed from the current position. This does also work as I would expect it.

Now to the first thing that only works in parts: It is possible to select a new font but since the font input box does not lose focus after a valid font was selected, you have to manually focus the text layer again (otherwise you just keep typing into the font selection box). If you do this with the mouse, the font selection is reset to what it was before. Alternatively you can focus the text layer with multiple presses of the tab key, which preserves the font selection as you would expect.

For the font size, it is exactly the same as for the font selection: mouse click resets the setting, tab preserves it. 

For the two numeric selection fields below the font size settings, none of the two methods of bringing the text layer back to focus works. You lose your new settings either way.

This seems to overlap with bug 683011, it looks like the behavior for the text size selection was fixed there but the fix was not applied to the other numeric input fields.


I think that there are a few things that could help to make the on canvas settings a bit more intuitive to use:

1.: Make the enter key confirm the modified setting and refocus the text layer. It is kind of counter-intuitive to 'confirm' with the tab key.

2.: For the font selection box, automatically return focus to the text layer if you click on a font from the drop-down that appears once you start typing into the box.

3. Immediately refocus the text layer if one of the numeric settings was changed via the up or down button. Currently the use of the up or down button focuses the text area of the corresponding numeric input. This is unnecessary since I just changed the value via the button. If I wanted to change the value via keyboard, I would click into the text box. This is my personal preference so feel free to ignore that one :P

4. Don't always reset the font settings to the settings at the current cursor position when clicking into the text layer. If the new cursor position is the same as the old one, keep the new settings and use them for new text.
Comment 1 Simon Müller 2018-02-16 18:20:12 UTC
Just to clarify because there was some confusion on gimpforum.de: All of the above occurs, when I am typing, then stop typing to change a setting and then try to continue writing at the same cursor position I stopped. When I set the cursor somewhere else in the already written text, the settings for letter spacing etc. seem to work as expected.
Comment 2 Jehan 2018-02-27 21:06:30 UTC
I kind of agree with all of your propositions.
A few notes:

> 1.: Make the enter key confirm the modified setting and refocus the text layer. It is kind of counter-intuitive to 'confirm' with the tab key.

The Enter key could be used in any of the text input settings: not only font name but also font size, baseline and kerning (if you were to give focus to the entry, which should not happen when just clicking arrows, I agree with your point 3).

> For the two numeric selection fields below the font size settings, none of the two methods of bringing the text layer back to focus works. You lose your new settings either way.

I have different behaviors here:

- baseline indeed takes focus, but if I refocus to the canvas text with the mouse, it kept the baseline. No reset for me. So that looks good.
Also I notice that somehow baseline settings only works when text is selected somehow. If there is no selection, trying to change the baseline simply doesn't work. And this looks like a bug to me.

- Kerning is weird as it adds kerning after current cursor (when no text is selected), and if you start to write down text, it writes it before the kerning space (so custom kerning is not applied to this new text).
This is weird because that works very differently to other text features. I wonder if that is the expected logics for kerning in common text (for instance how is it working in libreoffice?), but that looks really weird and buggy to me.

In any case, patches are very welcome for the various issues you raised already. :-)
Comment 3 Jehan 2018-02-27 21:07:14 UTC
Setting to "All" since it is not Win32 specific, and could happen anytime in a 2.10.x.
Comment 4 Jehan 2018-02-27 21:11:14 UTC
(In reply to Jehan from comment #2)
> - Kerning is weird as it adds kerning after current cursor (when no text is
> selected), and if you start to write down text, it writes it before the
> kerning space (so custom kerning is not applied to this new text).
> This is weird because that works very differently to other text features. I
> wonder if that is the expected logics for kerning in common text (for
> instance how is it working in libreoffice?), but that looks really weird and
> buggy to me.

Just tested in LibreOffice myself. I think our interface related to kerning is bugged.
Comment 5 GNOME Infrastructure Team 2018-05-24 19:08:56 UTC
-- 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/gimp/issues/1306.