GNOME Bugzilla – Bug 502010
GtkComboBox has-frame property has no effect
Last modified: 2017-11-07 11:24:19 UTC
The has-frame property of GtkComboBox seems to have no visual effect, though I'm not sure what I should expect to see. I've tried it in code and in Glade (I don't need it myself, but a gtkmm user asked about it). On irc, Richard Hult mentioned that it maybe only has an effect on Windows. If so, I guess that should be documented.
I have now discovered some more: 1. The change is visible in some themes even on Linux (but not in ClearLooks). 2. I only see any change in GtkComboBoxText, not GtkComboBox. But I guess this is just part of the story.
The visibility of the change should not depend on the theme. has-frame is responsible for whether or not there is a frame around the entry or not.
For GTK+ 2: ClearLooks is gone, and Raleigh seems OK here on a quick test. (In reply to Matthias Clasen from comment #2) > The visibility of the change should not depend on the theme. In GTK+ 3/4, it does now, the presence/absence of the frame is set by removing/adding the .flat style class on the internal Entry. > has-frame is responsible for whether or not there is a frame > around the entry or not. which explains (In reply to Murray Cumming from comment #1) > 2. I only see any change in GtkComboBoxText, not GtkComboBox. though you should and presumably do see the same thing if taking a ComboBox and then manually adding an Entry to it. Anyway, in both cases, ComboBox just passes :has-frame through to the Entry, so if there is still an issue here, it should be reopened on GtkEntry instead. Note also that I pushed some fixes for the .flat state being wrongly overridden by various pseudoclasses (:backdrop, :disabled, etc.) to Adwaita and HighContrast just the other day, which would interact with tests of this. That is: if your window is backdropped and you're toggling :has-entry, you'll get misleading results unless you're running GTK+ 3/4 from Git.
(In reply to Daniel Boles from comment #3) > For GTK+ 2: ClearLooks is gone, and Raleigh seems OK here on a quick test. Nope, this does still occur in GTK+ 2. However, I doubt it will change there at this point, so I'll leave it closed unless someone disagrees.