GNOME Bugzilla – Bug 671701
Please indicate docked dialog that has focus
Last modified: 2021-06-19 08:57:37 UTC
Now that we have implemented focus grabbing, it would be good to highlight the handle of the dock that has focus so that it can easily be identified. Any suggestions for how we should do this?
You would need to paint a focus on/around the grip here: http://git.gnome.org/browse/gdl/tree/gdl/gdl-dock-item-grip.c#n125 gtk_render_focus (http://developer.gnome.org/gtk3/3.0/GtkStyleContext.html#gtk-render-focus) paints the focus according to used theme. If that doesn't look good you might consider drawing the focus line around the whole dialog instead, not sure if it is looking any better though.
The parallel report in Inkscape is available here: https://bugs.launchpad.net/inkscape/+bug/950556
I had a quick attempt at adding gtk_render_focus to the draw function. It semi-worked, but was a bit glitchy. In particular, the highlight wasn't always clearing properly when focus switched somewhere else.
Created attachment 214284 [details] [review] Patch to indicate dock items that have focus OK, I finally got this working, but I'm not sure if I've fixed it correctly. The focus indicator in the grip is handled whenever the item is redrawn. I couldn't figure out a sensible way of doing this without overriding the draw function in gdl_dock_item.c
Review of attachment 214284 [details] [review]: Looks correct to me - thanks!
There is an issue here with this patch. I suppose it request additional redraw making an endless loop. The project pane is never displayed.
Created attachment 214304 [details] [review] Patch to indicate dock items that have focus Oops... I messed up the return value from the draw function. Perhaps that will have adversely affected the propagation of the draw signal? Corrected patch attached.
Review of attachment 214304 [details] [review]: I think you shouldn't call gtk_widget_queue_draw in the draw handler. This function should be called only when there is a focus change to force redrawing the widget. Then, there is an issue when the iconify and close button are hidden, the focus border is erased.
Review of attachment 214304 [details] [review]: I am not entirely sure but it might make sense to hook up some "focus-changed" signal and force a redraw there. ::: gdl/gdl-dock-item.c @@ +1085,3 @@ + + if (GTK_IS_WIDGET (item->priv->grip)) + gtk_widget_queue_draw (GTK_WIDGET (item->priv->grip)); Yep, indeed you may not call queue_draw() as Seb said, I think it is even in the docs. But you shouldn't have to as you draw already. But you probably have to invalidate the focus area when the focus changes so it is actually redrawn on next draw.
I have tried to understand why a part of the focus frame is erased sometimes and I have found that it's a bug in gdl_dock_item_grip_realize, we should have gtk_widget_get_allocation (widget, &allocation); instead of gtk_widget_get_allocation (grip->priv->label, & allocation). But I don't really know how you want to handle the focus in Inkscape. In your patch you draw the focus when the grip or the dock child widget has the focus. In Anjuta, when the dock child widget has the focus it is often already shown in the child widget itself so it's not really useful. Then what is the use of having the focus on the grip? I think it would be better to make this focus optional and to take into account a few properties ("interior-focus", "focus-line-width", "focus-padding", border_width) when drawing the focus box like it is done for a GtkButton.
Well, actually the original Inkscape behaviour didn't paint a focus indicator on the grip... Instead, the background colour of the grip became darker to indicate which dock item has focus, even when nothing inside the dock item is currently selected.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of gdl, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gdl/-/issues/ Thank you for your understanding and your help.