[gtk] weird border around views::Textfield

[Anton Vayvod]

Hi all,

I wonder if someone could help me to understand which property of views::Textfield (or underlying GtkEntry) should I set to avoid ugly white border around the widget when it's on some non-white background.

See the screenshot attached.

I tried to modify GtkEntry's background color or set GtkEntry::honors-transparent-bg-hint and GtkEntry::transparent-bg-hint to 1 in the corresponding gtkrc file, but the ugly corners are still there.

Thanks,

Anton.

[Evan Martin]

(I've never seen this transparent-bg-hint property before; it appears
to be a hack, potentially introduced by Mozilla, to make exactly the
use case you have work.)
Here's how Mozilla uses it in solving the equivalent problem (search
for transparent-bg-hint):
http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/gtk2drawing.c

It appears transparent-bg-hint needs to be set with
g_object_set_data(), not as a style property (which is what your gtkrc
change does).

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>

[Scott Violet]

Did you try gtk_entry_set_has_frame(false)?

-Scott

On Wed, Oct 27, 2010 at 11:06 AM, Anton Vayvod <ava...@chromium.org> wrote:

[Anton Vayvod]

From the same file it looks like the hint is only supported by Mozilla's own paint code - in moz_gtk_entry_paint().

They also install the property honors-transparent-bg-hint themselves in moz_gtk_init().

That means I'll have to do similar thing with gtk sources we use for Chrome OS, does it? Or should I try to reimplement textfield in views?

chromium-os-dev: I only found ebuild file for gtk that fetches the source and some patches that are probably being applied to it before compiling. There's nothing like gtk package I could work on using cros_workon, right?

[Anton Vayvod]

Well, this solves the problem in a sense: there's no round corners or focus border anymore so artifacts go away, but the fields don't look like we want them to look :) Perhaps, this could be a quick fix.

[Anton Vayvod]

From the same file it looks like the hint is only supported by Mozilla's own paint code - in moz_gtk_entry_paint().

They also install the property honors-transparent-bg-hint themselves in moz_gtk_init().

That means I'll have to do similar thing with gtk sources we use for Chrome OS, does it? Or should I try to reimplement textfield in views?

chromium-os-dev: I only found ebuild file for gtk that fetches the source and some patches that are probably being applied to it before compiling. There's nothing like gtk package I could work on using cros_workon, right?

On Wed, Oct 27, 2010 at 10:18 PM, Evan Martin <ev...@chromium.org> wrote:

[Evan Martin]

On Thu, Oct 28, 2010 at 4:54 AM, Anton Vayvod <ava...@google.com> wrote:
> From the same file it looks like the hint is only supported by Mozilla's own
> paint code - in moz_gtk_entry_paint().
> They also install the property honors-transparent-bg-hint themselves in
> moz_gtk_init().
> That means I'll have to do similar thing with gtk sources we use for Chrome
> OS, does it?

Sorry, I'm not too familiar with how Mozilla works. I am certain that
they don't need to patch GTK though, since they run on normal Linux
systems. I believe the moz_gtk_entry_paint() stuff is used for
drawing things that look GTK entry fields in web contents, which I
guess is not what you want to implement. Sorry for the bad lead.

> Or should I try to reimplement textfield in views?

I think that is a much larger task than you would anticipate. People
have talked about reusing WebKit's text fields. I think that's
probably a better long-term solution.

If I were asked me to fix this, I would probably look into just
changing the entry edge color to match the background color. I'm
certain it's possible to make a text field that doesn't have an ugly
white border as that's how it looks on ordinary Linux systems.

From reading
https://bugzilla.gnome.org/show_bug.cgi?id=534611
it appears the entry field has a square window, so there is no way to
make the edges transparent, and also that the base[NORMAL] or
bg[NORMAL] colors control the color used to fill in the corners.

[Scott Violet]

Also remember that on ChromeOS we are supplying the theme engine.
Specifically: http://git.chromium.org/gitweb/?p=theme.git;a=tree .
There are a couple of approaches you could take:

. Communicate to the theme engine these widgets should be rendered
differently (you could do this by setting a property the theme engine
looks for, or modifying the rc file).
. Do all the painting yourself.

-Scott

[Xiyuan Xia]

Similar effect could be seen on ChromeOs login screen as well. I am still investigating the problem. I suspect it's caused by code in NativeViewHost::Paint when there is a "installed clip". But have not got time to verify this and figure out why there is a clip. 

Cheers

Xiyuan

[Scott Violet]

This might require using compositing. I would talk with Oshima as he
has added the composited hooks in WidgetGtk.

-Scott

[Evan Stade]

I think you could manually control the shape of the window, like we do
with the find bar.

[Xiyuan Xia]

Scott is right that if you want real rounded-rect TextField you need to figure out how to do composited widget. I did some simple test and found out the ugly white thing is the GtkEntry's background, not from our views code as I originally suspected. 

What is your background color? If it is a simple solid color (no gradient etc), then you could just use that as the underlying GtkEntry's background color. Note you need to change base[NORMAL] rather than bg[NORMAL] though.

Xiyuan

[James Su]

Have you tried to remove the widget's background by using gdk_window_set_back_pixmap()?

[Anton Vayvod]

I tried that and it needs GdkWindow, not GdkWidget, so widget->window can be passed there. Didn't help.

[Anton Vayvod]

I'm addressing exactly the problem with textfields on login screen, so my background is gradient. I'd be glad to change textfield background to something darker at least to make the artifact less noticeable.

[oshima]

On Fri, Oct 29, 2010 at 5:31 AM, Anton Vayvod <ava...@chromium.org> wrote:

I'm addressing exactly the problem with textfields on login screen, so my background is gradient. I'd be glad to change textfield background to something darker at least to make the artifact less noticeable.

I'll look into this today and see if I can make the textfield background transparent.

- oshima 

[oshima]

I discuss this with xiyuan and the best, short-term solution seems to be disable gtk's border on this textfield and

we draw the border instead. There may be better way, but since this will be replaced with domui in near future,

we believe this is good enough for beta.

Anton, is there a bug filed? I'll file if not.

- oshima

[Anton Vayvod]

It's number 8 in the list of http://code.google.com/p/chromium-os/issues/detail?id=8101

[Anton Vayvod]

Well, actually not, it's only mentioned by Kan there for a couple of times and there's a reference to me trying to fix this.

[Anton Vayvod]

On Sun, Oct 31, 2010 at 3:46 PM, Anton Vayvod <ava...@chromium.org> wrote:

Well, actually not, it's only mentioned by Kan there for a couple of times and there's a reference to me trying to fix this.

On Sun, Oct 31, 2010 at 3:35 PM, Anton Vayvod <ava...@chromium.org> wrote:

It's number 8 in the list of http://code.google.com/p/chromium-os/issues/detail?id=8101

On Sat, Oct 30, 2010 at 6:17 AM, oshima <osh...@chromium.org> wrote:

I discuss this with xiyuan and the best, short-term solution seems to be disable gtk's border on this textfield and

we draw the border instead. There may be better way, but since this will be replaced with domui in near future,

we believe this is good enough for beta.

I guess this can be done in gtk_view_entry expose event handler, right? I see that even if I don't call gtk_entry expose handler there at all, the whole area is still filled with the same white color.

Changing gtk_view_entry could break some other textfields on Linux though, which I'd like to avoid.

[Nikita Kostylev]

It was a part of http://crosbug.com/8101 but feel free to open another one

On Sat, Oct 30, 2010 at 6:17 AM, oshima <osh...@chromium.org> wrote:

--
Nikita

[Anton Vayvod]

Sent http://codereview.chromium.org/4127009/show for a review.

[oshima]

On Sun, Oct 31, 2010 at 10:32 AM, Anton Vayvod <ava...@chromium.org> wrote:

On Sun, Oct 31, 2010 at 3:46 PM, Anton Vayvod <ava...@chromium.org> wrote:

Well, actually not, it's only mentioned by Kan there for a couple of times and there's a reference to me trying to fix this.

On Sun, Oct 31, 2010 at 3:35 PM, Anton Vayvod <ava...@chromium.org> wrote:

It's number 8 in the list of http://code.google.com/p/chromium-os/issues/detail?id=8101

On Sat, Oct 30, 2010 at 6:17 AM, oshima <osh...@chromium.org> wrote:

I discuss this with xiyuan and the best, short-term solution seems to be disable gtk's border on this textfield and

we draw the border instead. There may be better way, but since this will be replaced with domui in near future,

we believe this is good enough for beta.

I guess this can be done in gtk_view_entry expose event handler, right? I see that even if I don't call gtk_entry expose handler there at all, the whole area is still filled with the same white color.

Changing gtk_view_entry could break some other textfields on Linux though, which I'd like to avoid.

The good thing about doing this way is that you can use the background already drawn by parent, and don't have to

paint each textfield using the parent's color, which is tricky when the background is gradient. That's been said, there

may be other issue and since you've already started, i'll leave it to you.

- oshima