GNOME Bugzilla – Bug 155071
wrong colors in location bar history
Last modified: 2018-02-10 03:28:27 UTC
The colors of the location bar history/completion list don't match the currently selected theme. See following screenshot.
Created attachment 32471 [details] screenshot
This is the stock gtkentrycompletion gtk+ widget, re-assigning to gtk+.
Works fine for me here in testentrycompletion. Can you reproduce this with testentrycompletion, Christian ?
Ricardo: can you be more specific about what exactly you think is wrong? As I understand it, it is that the completion actions should be themed like menu items? If that's the case, then yes, I can reproduce this in testentrycompletion, using the high-contrast inverse theme: On mouse-over, the completion actions are white on blue, while menuitems are blank on white.
What I originally thought was wrong was apparently the result of inconsistencies or errors in several themes. However there is still a problem related to themes and its that all completion entries are themed with unfocused colors (because the text entry is retaining the focus) which make it look like they aren't correctly themed when they probably are. Another question, are completion action supposed to be themed with the same color of menu items or with the same appearance (style properties, theme engine style,etc)? If the second case is correct (menu item apperance) then there are certainly a few more things wrong.
And yes, I tried testentrycompletion and it appears to be themed correctly except for the "completion action not looking like menu items" case and the "unfocused colors" situation.
Created attachment 51275 [details] [review] focus completion popup window This patch adds focus to the entry completion window, it does the same thing as treeview with interactive search entry. But there is a problem with treeview cursor, there is no way to unset it. This patch does this just directly freeing tree_view->priv->cursor row reference. It would be good to have something like gtk_tree_view_unset_cursor().
The patch is no good, see "there is a problem" in last comment.
We probably cannot use the same logic as the tree view search dialog uses here. The tree view search dialog is popped up and made modal (so it will receive all events) and then the focus is set again on the tree view so the selection is drawn okay. So while the tree view has focus, the entry will receive all the events. Here we want kind of the same, however we cannot really make the entry modal here -- things are just the opposite, the tree view is in the popup now and not the entry. Transferring focus to the tree view might work, since events are already being passed from the entry completion popup window to the entry. Instead of getting the code right that has to move the focus back and forth between widgets, it might be easier to change the tree view such that it will always draw the selection as if the tree view is focussed when it is in hover-selection mode? Matthias, what do you think of this approach?
Comment on attachment 51275 [details] [review] focus completion popup window Setting patch status as per comment 8, plus patch uses API removed in gtk3 (GTK_WIDGET_SET_FLAGS)
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.