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 789732 - Cannot hide GtkEntry frame
Cannot hide GtkEntry frame
Status: RESOLVED NOTGNOME
Product: gtk+
Classification: Platform
Component: Themes
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-10-31 19:26 UTC by Adrien Tétar
Modified: 2017-11-02 19:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
working test case (1014 bytes, text/plain)
2017-11-01 20:37 UTC, Daniel Boles
Details

Description Adrien Tétar 2017-10-31 19:26:14 UTC
Hi all,

I have trouble removing the frame of a GtkEntry widget on Ubuntu 17.10/GTK+ 3.22.24. (64bits)

Code:

GtkEntry* widget = gtk_entry_new();

gtk_entry_set_has_frame(widget, FALSE);

This has no effect on my machine. I also tried:

g_object_set (widget, "has-frame", FALSE, NULL);

And also I tried to use the new CSS machinery:

GtkCssProvider* provider = gtk_css_provider_new();
gtk_css_provider_load_from_data(
    provider, "GtkEntry { border-style: none }", -1, NULL);
gtk_style_context_add_provider(
    gtk_widget_get_style_context(widget),
    GTK_STYLE_PROVIDER(provider),
    GTK_STYLE_PROVIDER_PRIORITY_USER);

Neither seem to work.

This is calling from wxWidgets (cpp library) and maintainer told me styling changes to widgets aren't working on recent GTK+3 versions: https://groups.google.com/forum/#!topic/wx-users/Wg8M-jC_8lk


Thanks.
Comment 1 Daniel Boles 2017-10-31 19:33:19 UTC
Since 3.20, GTK+ uses different CSS node names. These are documented for each widget, e.g. entry.

https://developer.gnome.org/gtk3/stable/GtkEntry.html#GtkEntry.description

    entry { border: none; }

works just fine to do this in CSS.

I'd hope wxWidgets were aware of this; it was loudly discussed at the time. :P


:has-frame adds or removes the .flat style class, which is working, but the standard theme Adwaita indeed does not seem to be doing what I would expect from this: it seems to shrink the padding around the edges but not remove the border.
Comment 2 Daniel Boles 2017-10-31 19:39:00 UTC
...nevermind, I needed to trigger a redraw. :has-frame also seems to work AOK on Adwaita.

If it doesn't for you, that sounds like a bug in whatever theme you're using to me.
Comment 3 Daniel Boles 2017-10-31 19:41:00 UTC
(In reply to Daniel Boles from comment #2)
> ...nevermind, I needed to trigger a redraw. :has-frame also seems to work
> AOK on Adwaita.

Ah, it doesn't work when the window is backdropped. That'll be a CSS precedence fail.
Comment 4 Adrien Tétar 2017-10-31 20:36:46 UTC
Thanks Daniel. So you're saying:
Comment 5 Adrien Tétar 2017-10-31 20:41:13 UTC
(Hit submit too soon) alright thanks, I changed the bug category to "Themes". I'm using the built-in Ubuntu theme but I think this behavior is inherited from the base Adwaita theme, which afaict should remove the border to be consistent with the docs.
Comment 6 Daniel Boles 2017-10-31 20:45:41 UTC
We'll need a screenshot and replication steps of what you're saying is wrong, because the problems I'm working on in Bug 789733 only affect edge cases of Adwaita, while foreground Entries with :has-frame = FALSE work as documented - yet you indicate :has-frame simply does not work at all.

So I don't think this is an inherent problem in Adwaita itself, but you need to provide more precise info on how we can test this for a conclusion to be made.
Comment 7 Daniel Boles 2017-11-01 20:37:37 UTC
Created attachment 362784 [details]
working test case

In support of what I last said, here's a working example, which is already fine on 3.22.2[45] using upstream Adwaita (modulo what I fixed in that other bug).
Comment 8 Adrien Tétar 2017-11-02 18:07:04 UTC
On my Ubuntu machine the frame is still displayed, so I'm going to guess it's a problem with Ubuntu's theme and not the upstream GNOME one. Thanks.

Closing this.
Comment 9 Daniel Boles 2017-11-02 19:05:36 UTC
Just to clarify, you'll still see a blue frame around such an entry when it has keyboard focus, but setting :has-frame to FALSE (i.e. adding the .flat CSS class) should - and, in my tests, does - suppress the background colour and the frame in non-focussed cases.

I didn't analyse in much depth whether that's completely intended; you still want *some* kind of indication that a flat entry has focus, though it ends up looking a bit clumsy since the margin between the border and the text layout gets lost. I didn't want to go beyond the scope of fixing the obviously wrong things, though; I'll leave the rest for the actual designers. :D

Anyway, thanks for prompting me to take a closer look and finding other issues that I could fix!