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 671701 - Please indicate docked dialog that has focus
Please indicate docked dialog that has focus
Status: RESOLVED OBSOLETE
Product: gdl
Classification: Other
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Anjuta maintainers
Anjuta maintainers
Depends on:
Blocks:
 
 
Reported: 2012-03-09 08:26 UTC by Alex Valavanis
Modified: 2021-06-19 08:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to indicate dock items that have focus (2.57 KB, patch)
2012-05-17 22:53 UTC, Alex Valavanis
reviewed Details | Review
Patch to indicate dock items that have focus (2.61 KB, patch)
2012-05-18 11:45 UTC, Alex Valavanis
rejected Details | Review

Description Alex Valavanis 2012-03-09 08:26:12 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?
Comment 1 Johannes Schmid 2012-03-09 16:14:28 UTC
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.
Comment 2 Alex Valavanis 2012-05-17 20:31:47 UTC
The parallel report in Inkscape is available here: https://bugs.launchpad.net/inkscape/+bug/950556
Comment 3 Alex Valavanis 2012-05-17 20:35:15 UTC
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.
Comment 4 Alex Valavanis 2012-05-17 22:53:54 UTC
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
Comment 5 Johannes Schmid 2012-05-18 08:44:33 UTC
Review of attachment 214284 [details] [review]:

Looks correct to me - thanks!
Comment 6 Sébastien Granjoux 2012-05-18 08:55:10 UTC
There is an issue here with this patch. I suppose it request additional redraw making an endless loop. The project pane is never displayed.
Comment 7 Alex Valavanis 2012-05-18 11:45:57 UTC
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.
Comment 8 Sébastien Granjoux 2012-05-18 14:27:58 UTC
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.
Comment 9 Johannes Schmid 2012-05-19 06:36:16 UTC
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.
Comment 10 Sébastien Granjoux 2012-05-19 14:16:53 UTC
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.
Comment 11 Alex Valavanis 2012-05-19 19:18:01 UTC
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.
Comment 12 André Klapper 2021-06-19 08:57:37 UTC
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.