GNOME Bugzilla – Bug 728859
Popover placement issues
Last modified: 2017-02-25 22:42:00 UTC
I'm testing master, which is using GtkPopover rather than bijiben's homebrew widget. Currently I can see a few issues with the placement of the popover when text is selected: * If I select a word by double clicking on it (or a paragraph by triple clicking), the point of the popover obscures part of the selection. There needs to be a small amount of clearance between the text selection area and the point of the popover, as in: https://github.com/gnome-design-team/gnome-mockups/raw/master/selections/selections-touch-timer.png * If I click once to place the caret and then press shift+home or shift+end to select a section of text, the popover points to the upper-left corner of the note. * The popover is placed according to where I clicked last (or where I released the mouse button when dragging to make a selection). Instead, it should be placed in relation to the size and shape of the text selection area (it should be horizontally centred in relation to this area).
i just added a little offset about point 1. But the remaining part will be the real work : perform some magic to guess position of selection area.
I've just tested master, and the situation is much improved. The vertical position of the popovers is now usually correct. Remaining issues I can see: * Horizontal positioning - the point of the popover is positioned where you released the mouse button, rather than being horizontally centered in relation to the text selection area. * If you select a length of text with the keyboard, the popover appears at the top of the window, pointing towards the top-left corner. I'm not sure we should show the popover at all when selecting text using the keyboard.
(In reply to comment #2) > * Horizontal positioning - the point of the popover is positioned where you > released the mouse button, rather than being horizontally centered in relation > to the text selection area. I will need to wait for WebKit2 code to advance because this change has a very strong influence on this. > I'm not sure we should show the popover at all when selecting text using the keyboard. Yes this one should be easily doable right now, I will check.
I spoke too soon. Other issues I've observed: * When selecting multiple lines with the pointer, both the horizontal and vertical placement of the popover is based on where the mouse button was released. Often, this means that the popover obscures the selected text. * When moving a text selection by dragging - after you relaese the mouse button, the popover appears in the top-left of the window. * Vertical placement of the popover is inconsistent when selecting small runs of text on the same line with pointer and mouse button.
I'm still seeing a bunch of these issues with master (built today). Any plan to resolve them before 3.14?
ack, i don't have terrific plans right now Thus, I just pushed two workaround commit 1d5ce7f46b67e17ffe2c93ccdd6f7e4eb6f2c12a Author: Pierre-Yves Luyten <py@luyten.fr> Date: Wed Aug 20 00:34:31 2014 +0200 Hide cursor while selection Actually this feels slightly better. Any mouse usage will recover the cursor. commit 366aceeeb5280c82fabad6ed28b8aacc09ab32f4 Author: Pierre-Yves Luyten <py@luyten.fr> Date: Wed Aug 20 00:45:32 2014 +0200 EditorToolbar: do not align on key press This is not the real fix, which would be to *compute* where to align toolbar. Does not work with a heavy keyboard usage, but whenever keyboard just serves to extend a selection or to select text near point, this partially hides the bug.
This bug is still present in 3.14, and is quite noticeable if you drag to select a text area, or select an area of text with the keyboard (eg. use Shift+Home or Shift+End). Carlos has advised that the root of the bug is in the use of WebKit. To accurately implement the design, either WebKitGtk needs to grow the necessary support, or WebKit needs to be replaced with GtkTextView. The alternative is to drop the floating popovers and use a different design for formatting. Setting this as a 3.16 target bug, since it is quite obvious.
(In reply to comment #7) ... > The alternative is to drop the floating popovers and use a different design for > formatting. Here are a couple of suggestions for alternative UIs. One of these could be used temporarily, until this issue is resolved: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/notes/notes-formatting-controls-wireframe.png
It looks like no-one has worked on this and this seems to not happen for 3.16. Proposing removal of the "GNOME Target" here.
removing target
(In reply to Allan Day from comment #8) > Here are a couple of suggestions for alternative UIs. One of these could be > used temporarily, until this issue is resolved: > > https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/ > notes/notes-formatting-controls-wireframe.png Indeed action bar idea could solve the issue for now, this would be a nice fix
Created attachment 326565 [details] popover overlapping the text in the 1st line
(In reply to Asif Ali Rizvan from comment #12) > Created attachment 326565 [details] > popover overlapping the text in the 1st line I can confirm this again in GNOME 3.20. When a user gets a problem like this on the 1st line of their note, it does not provide a good (polished) first impression or encouragement to continue using the program.
Created attachment 334304 [details] Popover obscuring text in 1st line: above variant
Created attachment 334305 [details] Popover obscuring text in 1st line: below variant
Added a patch that follows the GtkActionBar approach from GNOME Design Team. No Numbered List and Clear Formatting buttons have been added at the moment, but those can be added later along with their functionality. This approach uses GtkButton, to format/unformat the selected text. A better solution would be to use toggle buttons, but at the moment there is no way to know if the text has any kind of format applied to activate/deactivate format buttons accordingly. This should be solved before adding Clear Formatting button.
Created attachment 346456 [details] [review] bjb-editor-toolbar moved from GtkPopover to GtkActionBar
Created attachment 346657 [details] [review] bjb-editor-toolbar moved UI definition to a template file A follow up of the last patch, that moves UI definition to a template file. After removing the UI code, I have also updated the code by using GTK facilities for class definitions (G_DECLARE_FINAL_TYPE, G_DEFINE_TYPE_WITH_PRIVATE).
Review of attachment 346456 [details] [review]: commit 81a8fe5245119663f15edb32aebaf9ebe3be5306 Author: Iñigo Martínez <inigomartinez@gmail.com> Date: Sat Feb 25 23:28:35 2017 +0100
Review of attachment 346657 [details] [review]: commit 8811ff5003a1129550b2f522a80cd302e91b05e8 Author: Iñigo Martínez <inigomartinez@gmail.com> Date: Sat Feb 25 23:34:25 2017 +0100
Thanks to Iñigo Martínez , this bug is now fixed, GtkActionBar is used.