bug#46493: [feature/pgtk] Low contrast region face

bug#46493: [feature/pgtk] Low contrast region face

[Basil L. Contovounesios]

[-- Attachment #1: Type: text/plain, Size: 117 bytes --]

X-Debbugs-Cc: Yuuki Harano <masm+emacs@masm11.me>
Severity: wishlist

On master:

0. emacs -Q
1. M-2 M-b
2. M-2 M-@


[-- Attachment #2: 2021-02-13-165334_709x171_scrot.png --]
[-- Type: image/png, Size: 364549 bytes --]

[-- Attachment #3: Type: text/plain, Size: 35 bytes --]


Repeat the same on feature/pgtk:


[-- Attachment #4: 2021-02-13-165400_721x169_scrot.png --]
[-- Type: image/png, Size: 366377 bytes --]

[-- Attachment #5: Type: text/plain, Size: 2079 bytes --]


I understand that each toolkit has its look & feel, and that colour
perception is subjective, but the default contrast on pgtk strikes me as
a bit too low for text editing.

Is there a way for Emacs to control the default (and would we want to do
that), or is this something that users must adjust on their side using
GTK or Emacs themes or the like?

Thanks,

-- 
Basil

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2021-02-13 built on tia
Repository revision: d1be48fdedabb451d5c6cf315fd5f09a632e771f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Debian GNU/Linux bullseye/sid

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
 --prefix=/home/blc/.local --enable-checking=structs
 --with-x-toolkit=lucid --with-file-notification=yes --with-x'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11
XAW3D XDBE XIM XPM LUCID ZLIB

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-02-13 built on tia
Repository revision: 175ebb010477ff0e174fe5145154397f43dee2d2
Repository branch: feature/pgtk
Windowing system distributor 'System Description: Debian GNU/Linux bullseye/sid

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
 --prefix=/home/blc/.local --program-suffix=-pgtk
 --enable-checking=structs --with-file-notification=yes --with-pgtk
 --with-xwidgets'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM
XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_IE.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

bug#46493: [feature/pgtk] Low contrast region face

[Dmitry Gutov]

On 13.02.2021 18:55, Basil L. Contovounesios wrote:
> X-Debbugs-Cc: Yuuki Harano <masm+emacs@masm11.me>
> Severity: wishlist
> 
> On master:
> 
> 0. emacs -Q
> 1. M-2 M-b
> 2. M-2 M-@

That's not a GTK3 build, though, right?

> Repeat the same on feature/pgtk:
> 
> 
> 
> I understand that each toolkit has its look & feel, and that colour
> perception is subjective, but the default contrast on pgtk strikes me as
> a bit too low for text editing.

Seems like it uses the same background color as the GTK3 build (the 
current one)? And that is probably the color of the window background.

My current GTK theme has a bit darker windows, so the background color 
looks like fine here, FWIW.

But the screenshot exhibits another (definite) bug: when Emacs is just 
started, the cursor shape is hollow. Switch away from its window and 
then back: the cursor is now filled.

bug#46493: [feature/pgtk] Low contrast region face

[Basil L. Contovounesios]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 13.02.2021 18:55, Basil L. Contovounesios wrote:
>> X-Debbugs-Cc: Yuuki Harano <masm+emacs@masm11.me>
>> Severity: wishlist
>> On master:
>> 0. emacs -Q
>> 1. M-2 M-b
>> 2. M-2 M-@
>
> That's not a GTK3 build, though, right?

configure.ac suggests otherwise:

  pgtk )
    term_header=pgtkterm.h
    with_gtk3=yes
    USE_X_TOOLKIT=none
  ;;

As does the GTK3 seen in the system-configuration-features part of my
signature in the OP.

>> Repeat the same on feature/pgtk:
>> I understand that each toolkit has its look & feel, and that colour
>> perception is subjective, but the default contrast on pgtk strikes me as
>> a bit too low for text editing.
>
> Seems like it uses the same background color as the GTK3 build (the current
> one)? And that is probably the color of the window background.
>
> My current GTK theme has a bit darker windows, so the background color looks
> like fine here, FWIW.

I don't use a desktop environment, and I'm not really familiar with GTK,
but here's my $XDG_CONFIG_HOME/gtk-3.0/settings.ini:

  [Settings]
  gtk-font-name                     = DejaVu Sans 10
  gtk-icon-theme-name               = Adwaita
  gtk-recent-files-enabled          = false
  gtk-recent-files-limit            = 0
  gtk-recent-files-max-age          = 0
  gtk-theme-name                    = Adwaita

> But the screenshot exhibits another (definite) bug: when Emacs is just started,
> the cursor shape is hollow. Switch away from its window and then back: the
> cursor is now filled.

I can't reproduce that here.  My cursor is always filled so long as the
frame is focused.  The hollow cursor in my screenshot seems to be the
result of invoking scrot via gmrun, during which Emacs seems to lose
focus.  I don't know why that doesn't happen with Lucid; I assumed it
was just toolkit-specific behaviour.  [BTW, disabling blink-cursor-mode
does not change anything.]

Is this rather some kind of mishandling of focus events on Emacs' side?

Thanks,

-- 
Basil

bug#46493: [feature/pgtk] Low contrast region face

[Dmitry Gutov]

On 13.02.2021 22:53, Basil L. Contovounesios wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 13.02.2021 18:55, Basil L. Contovounesios wrote:
>>> X-Debbugs-Cc: Yuuki Harano <masm+emacs@masm11.me>
>>> Severity: wishlist
>>> On master:
>>> 0. emacs -Q
>>> 1. M-2 M-b
>>> 2. M-2 M-@
>>
>> That's not a GTK3 build, though, right?
> 
> configure.ac suggests otherwise:
> 
>    pgtk )
>      term_header=pgtkterm.h
>      with_gtk3=yes
>      USE_X_TOOLKIT=none
>    ;;
> 
> As does the GTK3 seen in the system-configuration-features part of my
> signature in the OP.

No, I'm talking about your "reference" screenshot.

You are not comparing pgtk to the GTK3 build, which I think should be 
the reference when discussing it.

>>> Repeat the same on feature/pgtk:
>>> I understand that each toolkit has its look & feel, and that colour
>>> perception is subjective, but the default contrast on pgtk strikes me as
>>> a bit too low for text editing.
>>
>> Seems like it uses the same background color as the GTK3 build (the current
>> one)? And that is probably the color of the window background.
>>
>> My current GTK theme has a bit darker windows, so the background color looks
>> like fine here, FWIW.
> 
> I don't use a desktop environment, and I'm not really familiar with GTK,
> but here's my $XDG_CONFIG_HOME/gtk-3.0/settings.ini:
> 
>    [Settings]
>    gtk-font-name                     = DejaVu Sans 10
>    gtk-icon-theme-name               = Adwaita
>    gtk-recent-files-enabled          = false
>    gtk-recent-files-limit            = 0
>    gtk-recent-files-max-age          = 0
>    gtk-theme-name                    = Adwaita

It's some color within the Adwaita theme, then.

>> But the screenshot exhibits another (definite) bug: when Emacs is just started,
>> the cursor shape is hollow. Switch away from its window and then back: the
>> cursor is now filled.
> 
> I can't reproduce that here.  My cursor is always filled so long as the
> frame is focused.  The hollow cursor in my screenshot seems to be the
> result of invoking scrot via gmrun, during which Emacs seems to lose
> focus.  I don't know why that doesn't happen with Lucid; I assumed it
> was just toolkit-specific behaviour.  [BTW, disabling blink-cursor-mode
> does not change anything.]
> 
> Is this rather some kind of mishandling of focus events on Emacs' side?

Hm, all right. Maybe I'll report it later.

I can easily reproduce it with the current feature/pgtk by just calling 
'src/emacs -Q'. The cursor is hollow until I switch windows or drag the 
current one.

Not so in the GTK3 build.

bug#46493: [feature/pgtk] Low contrast region face

[Basil L. Contovounesios]

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 13.02.2021 22:53, Basil L. Contovounesios wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>> That's not a GTK3 build, though, right?
>> configure.ac suggests otherwise:
>>    pgtk )
>>      term_header=pgtkterm.h
>>      with_gtk3=yes
>>      USE_X_TOOLKIT=none
>>    ;;
>> As does the GTK3 seen in the system-configuration-features part of my
>> signature in the OP.
>
> No, I'm talking about your "reference" screenshot.

Ah, yes that would be Lucid.

> You are not comparing pgtk to the GTK3 build, which I think should be the
> reference when discussing it.

That's fair, but my intention wasn't so much a comparison with GTK3 as a
question for how [P]GTK3 should work in Emacs.  Let me know if I should
take this elsewhere.

>>>> Repeat the same on feature/pgtk:
>>>> I understand that each toolkit has its look & feel, and that colour
>>>> perception is subjective, but the default contrast on pgtk strikes me as
>>>> a bit too low for text editing.
>>>
>>> Seems like it uses the same background color as the GTK3 build (the current
>>> one)? And that is probably the color of the window background.
>>>
>>> My current GTK theme has a bit darker windows, so the background color looks
>>> like fine here, FWIW.
>> I don't use a desktop environment, and I'm not really familiar with GTK,
>> but here's my $XDG_CONFIG_HOME/gtk-3.0/settings.ini:
>>    [Settings]
>>    gtk-font-name                     = DejaVu Sans 10
>>    gtk-icon-theme-name               = Adwaita
>>    gtk-recent-files-enabled          = false
>>    gtk-recent-files-limit            = 0
>>    gtk-recent-files-max-age          = 0
>>    gtk-theme-name                    = Adwaita
>
> It's some color within the Adwaita theme, then.

Okay, but what alternatives are there?  I have the following directories
under /usr/share/themes: Adwaita, Adwaita-dark, Default, Emacs,
HighContrast, Raleigh.

Replacing Adwaita with Default, Emacs, or Raleigh in settings.ini makes
no difference.

With Adwaita-dark, I see the following:


[-- Attachment #2: 2021-02-14-124035_722x180_scrot.png --]
[-- Type: image/png, Size: 390762 bytes --]

[-- Attachment #3: Type: text/plain, Size: 75 bytes --]


And with HighContrast seeing is not believing that the region is active:


[-- Attachment #4: 2021-02-14-124234_717x176_scrot.png --]
[-- Type: image/png, Size: 379442 bytes --]

[-- Attachment #5: Type: text/plain, Size: 92 bytes --]


Is this entirely a misconfiguration on my end, or can Emacs do better?

Thanks,

-- 
Basil

bug#46493: [feature/pgtk] Low contrast region face

[Yuuki Harano]

On Sat, 13 Feb 2021 16:55:47 +0000,
	"Basil L. Contovounesios" <contovob@tcd.ie> wrote:
> I understand that each toolkit has its look & feel, and that colour
> perception is subjective, but the default contrast on pgtk strikes me as
> a bit too low for text editing.

lisp/faces.el:

(defface region
  '((((class color) (min-colors 88) (background dark))
     :background "blue3" :extend t)
    (((class color) (min-colors 88) (background light) (type gtk))
     :distant-foreground "gtk_selection_fg_color"
     :background "gtk_selection_bg_color" :extend t)

The color name "gtk_selection_bg_color" is handled by src/gtkutil.c:
xg_check_special_colors(), which gets colors from gtk theme.

This issue is not pgtk-specific.

If we want another color for bg on pgtk, we can change this face definition as follows:

(defface region
  '((((class color) (min-colors 88) (background dark))
     :background "blue3" :extend t)
    (((class color) (min-colors 88) (background light) (type pgtk))    ; add this line
     :background "lightgoldenrod2" :extend t)                          ; add this line
    (((class color) (min-colors 88) (background light) (type gtk))
     :distant-foreground "gtk_selection_fg_color"
     :background "gtk_selection_bg_color" :extend t)

-- 
Yuuki Harano

bug#46493: [feature/pgtk] Low contrast region face

[Basil L. Contovounesios]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

Yuuki Harano <masm+emacs@masm11.me> writes:

> On Sat, 13 Feb 2021 16:55:47 +0000,
> 	"Basil L. Contovounesios" <contovob@tcd.ie> wrote:
>> I understand that each toolkit has its look & feel, and that colour
>> perception is subjective, but the default contrast on pgtk strikes me as
>> a bit too low for text editing.
>
> lisp/faces.el:
>
> (defface region
>   '((((class color) (min-colors 88) (background dark))
>      :background "blue3" :extend t)
>     (((class color) (min-colors 88) (background light) (type gtk))
>      :distant-foreground "gtk_selection_fg_color"
>      :background "gtk_selection_bg_color" :extend t)
>
> The color name "gtk_selection_bg_color" is handled by src/gtkutil.c:
> xg_check_special_colors(), which gets colors from gtk theme.

Thanks.

> This issue is not pgtk-specific.

Indeed, but I thought it was worthwhile asking since pgtk seems primed
to be the future of GTK3 in Emacs mainline.  Let me know if I should
take this discussion elsewhere.

> If we want another color for bg on pgtk, we can change this face definition as follows:
>
> (defface region
>   '((((class color) (min-colors 88) (background dark))
>      :background "blue3" :extend t)
>     (((class color) (min-colors 88) (background light) (type pgtk))    ; add this line
>      :background "lightgoldenrod2" :extend t)                          ; add this line
>     (((class color) (min-colors 88) (background light) (type gtk))
>      :distant-foreground "gtk_selection_fg_color"
>      :background "gtk_selection_bg_color" :extend t)

Sounds fine to me, but I'm wondering if this shouldn't be fixed lower
down.  Out of curiosity, I installed another GTK editor, Gedit:

0. gedit
1. foo bar RET baz


[-- Attachment #2: 2021-02-14-125741_612x152_scrot.png --]
[-- Type: image/png, Size: 279755 bytes --]

[-- Attachment #3: Type: text/plain, Size: 116 bytes --]


Note how the current line is highlighted with the same background colour
as the active region in pgtk.

2. S-<up>


[-- Attachment #4: 2021-02-14-125845_612x152_scrot.png --]
[-- Type: image/png, Size: 279755 bytes --]

[-- Attachment #5: Type: text/plain, Size: 146 bytes --]


Note how Gedit's "region" takes on a different, much clearer colour.
Could/should Emacs query GTK3 colours differently here?

Thanks,

-- 
Basil

bug#46493: [feature/pgtk] Low contrast region face

[Yuuki Harano]

On Sun, 14 Feb 2021 13:00:59 +0000,
	"Basil L. Contovounesios" <contovob@tcd.ie> wrote:
> Note how Gedit's "region" takes on a different, much clearer colour.
> Could/should Emacs query GTK3 colours differently here?

Gedit doesn't know anything about coloring.

There is a widget class to edit a text in Gtk, and gedit only use it.
The widget class uses Gtk theming functions.
That is why gedit coloring is consistent with themes.

I looked for another way to get theme color, but nothing found.

-- 
Yuuki Harano

bug#46493: [feature/pgtk] Low contrast region face

[Basil L. Contovounesios]

Yuuki Harano <masm+emacs@masm11.me> writes:

> On Sun, 14 Feb 2021 13:00:59 +0000,
> 	"Basil L. Contovounesios" <contovob@tcd.ie> wrote:
>> Note how Gedit's "region" takes on a different, much clearer colour.
>> Could/should Emacs query GTK3 colours differently here?
>
> Gedit doesn't know anything about coloring.
>
> There is a widget class to edit a text in Gtk, and gedit only use it.
> The widget class uses Gtk theming functions.
> That is why gedit coloring is consistent with themes.
>
> I looked for another way to get theme color, but nothing found.

Thanks for looking.  Feel free to close this issue as wontfix if this is
something that can't really be helped.

-- 
Basil

bug#46493: [feature/pgtk] Low contrast region face

[Lars Ingebrigtsen]

Yuuki Harano <masm+emacs@masm11.me> writes:

> This issue is not pgtk-specific.
>
> If we want another color for bg on pgtk, we can change this face definition as follows:

The proposed patch was:

diff --git a/lisp/faces.el b/lisp/faces.el
index d92569e7cd..de1ca095aa 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2502,7 +2502,9 @@ highlight
 (defface region
   '((((class color) (min-colors 88) (background dark))
      :background "blue3" :extend t)
-    (((class color) (min-colors 88) (background light) (type gtk))
+     (((class color) (min-colors 88) (background light) (type pgtk))
+     :background "lightgoldenrod2" :extend t)
+     (((class color) (min-colors 88) (background light) (type gtk))
      :distant-foreground "gtk_selection_fg_color"
      :background "gtk_selection_bg_color" :extend t)
     (((class color) (min-colors 88) (background light) (type ns))

But...  The gtk_selection_fg_color colour is different under gtk, but not
pgtk -- that's the problem.

Poking at this, it seems the colours we get out of GTK are:

gtk_selection_bg_color 0.964706 0.960784 0.956863

Which is a very, very light colour, which is apparently calculated
correctly in this branch here:

#ifndef HAVE_PGTK
  sprintf (buf, "rgb:%04x/%04x/%04x", r, g, b);
  success_p = x_parse_color (f, buf, color) != 0;
#else
  sprintf (buf, "#%04x%04x%04x", r, g, b);
  success_p = pgtk_parse_color (f, buf, color) != 0;
#endif

But with the non-pgtk branch we get a very dark colour.  And when taking
this into account:

      /* FIXME: Retrieving the background color is deprecated in
	 GTK+ 3.16.  New versions of GTK+ don't use the concept of a
	 single background color any more, so we shouldn't query for
	 it.  */
      gtk_style_context_get (gsty, state,
			     GTK_STYLE_PROPERTY_BACKGROUND_COLOR, &c,
			     NULL);

I think we should just remove all of this code and use the same colours
in (p)GTK Emacsen as in non.

Any other opinions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46493: [feature/pgtk] Low contrast region face

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think we should just remove all of this code and use the same colours
> in (p)GTK Emacsen as in non.

No.  The code in both branches currently works fine for me, and the GTK
deprecation warning is mostly exaggerated: since GTK 3 is no longer
seeing feature development, it will probably work till the end of time.

Basil, do you have any GTK stylesheet enabled that isn't Adwatia?

bug#46493: [feature/pgtk] Low contrast region face

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> I think we should just remove all of this code and use the same colours
>> in (p)GTK Emacsen as in non.
>
> No.  The code in both branches currently works fine for me, and the GTK
> deprecation warning is mostly exaggerated: since GTK 3 is no longer
> seeing feature development, it will probably work till the end of time.

Like I said, the colour we get out is the same in GTK and PGTK:

gtk_selection_bg_color 0.964706 0.960784 0.956863

(That's the RGB floating point value.)  This is turned into a dark grey
face on non-PGTK systems and a very, very light grey on PGTK.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46493: [feature/pgtk] Low contrast region face

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Like I said, the colour we get out is the same in GTK and PGTK:
>
> gtk_selection_bg_color 0.964706 0.960784 0.956863
>
> (That's the RGB floating point value.)  This is turned into a dark grey
> face on non-PGTK systems and a very, very light grey on PGTK.

Both builds display the same colors for me, so I don't know why that
might be happening.

bug#46493: [feature/pgtk] Low contrast region face

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Both builds display the same colors for me, so I don't know why that
> might be happening.

Odder and odder.  What colour is that for you?  Light or dark grey?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46493: [feature/pgtk] Low contrast region face

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Odder and odder.  What colour is that for you?  Light or dark grey?

Both display a very light gray, which is the same color used to
highlight the line containing the caret in programs such as gedit.

There should be a way to obtain the actual color used to highlight
selected text from GTK, but I've really lost touch with the higher-level
aspects of modern GTK programming, and cannot find anything.

bug#46493: [feature/pgtk] Low contrast region face

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> Odder and odder.  What colour is that for you?  Light or dark grey?
>
> Both display a very light gray, which is the same color used to
> highlight the line containing the caret in programs such as gedit.

Ah, I see what's going on now...  I was testing this on a remote
machine, which gives pretty irrelevant results in this case.

Testing this on my laptop, I get the same colour in pgtk and not -- a
very dark grey.  And that's because I use a dark theme in Gnome Shell,
presumably?

However, we ignore the theme for everything else, so "emacs -Q" gives me
an Emacs with a white background -- and a very dark region face.

It's nonsensical to heed Gtk's settings for the region face when we
don't heed it for the default background colour, so again I'm back to
the same point: We should probably just remove that code and use the
normal Emacs-determined face colours on (p)gtk, too.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46493: [feature/pgtk] Low contrast region face

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Testing this on my laptop, I get the same colour in pgtk and not -- a
> very dark grey.  And that's because I use a dark theme in Gnome Shell,
> presumably?

I guess so, yes.  Though the GNOME Shell theme is separate from the GTK
stylesheet itself, as GNOME Shell uses a different toolkit.

> However, we ignore the theme for everything else, so "emacs -Q" gives me
> an Emacs with a white background -- and a very dark region face.

That shouldn't be problematic, right? Because we have the distant
foreground set to the GTK region foreground color, so there will always
be sufficient contrast.

> It's nonsensical to heed Gtk's settings for the region face when we
> don't heed it for the default background colour, so again I'm back to
> the same point: We should probably just remove that code and use the
> normal Emacs-determined face colours on (p)gtk, too.

I don't think so: it seems unduly harsh, since we also do the same on
other platforms such as Mac OS.

Users using a non-default GTK stylesheet should know of the
consequences, and can simply customize the region face to use a
different background color.

bug#46493: [feature/pgtk] Low contrast region face

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> However, we ignore the theme for everything else, so "emacs -Q" gives me
>> an Emacs with a white background -- and a very dark region face.
>
> That shouldn't be problematic, right? Because we have the distant
> foreground set to the GTK region foreground color, so there will always
> be sufficient contrast.

It's nonsensical of Emacs to use the Gtk theme for just one colour here.
It should either use the Gtk theme for the background/foreground
colours, too, or not use it at all.

> Users using a non-default GTK stylesheet should know of the
> consequences, and can simply customize the region face to use a
> different background color.

Emacs composes the colours we use here, and we choose colours that have
the mixture we want.  Our current approach leads to two bugs: With a
dark theme, we get a nonsensically dramatic region face, and with a
light theme, we get a region face that has too low contrast.  That's an
Emacs bug, and not something the user should have to deal with.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46493: [feature/pgtk] Low contrast region face

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It's nonsensical of Emacs to use the Gtk theme for just one colour here.
> It should either use the Gtk theme for the background/foreground
> colours, too, or not use it at all.

It does for the foreground color too, if the contrast is too low.
Otherwise, why would we have a `distant-foreground' specification for
the region face on GTK?

> Emacs composes the colours we use here, and we choose colours that have
> the mixture we want.

We choose the colors specified by the user in his system-wide
preferences by default.

> Our current approach leads to two bugs: With a dark theme, we get a
> nonsensically dramatic region face, and with a light theme, we get a
> region face that has too low contrast.  That's an Emacs bug, and not
> something the user should have to deal with.

I disagree that the contrast is either too low or "dramatic".  And
anyway, I don't think we should be changing long-standing defaults for
personal preferences in this area.

bug#46493: [feature/pgtk] Low contrast region face

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> Emacs composes the colours we use here, and we choose colours that have
>> the mixture we want.
>
> We choose the colors specified by the user in his system-wide
> preferences by default.

But we don't.  The user has specified a dark theme, but we use the
default Emacs foreground/background colours.

> I disagree that the contrast is either too low or "dramatic".  And
> anyway, I don't think we should be changing long-standing defaults for
> personal preferences in this area.

We don't follow the personal preferences here, and this bug report is
exactly about the contrast being too low, so obviously people do think
that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46493: [feature/pgtk] Low contrast region face

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But we don't.  The user has specified a dark theme, but we use the
> default Emacs foreground/background colours.

Okay, I should have been more clear: we use the system colors for the
region face.  I had some code around that made Emacs respect the GTK
style more (in my first attempt at porting Emacs to GTK 4), but it broke
between GTK 4.2 and GTK 4.4, so I don't think we want to go down that
rabbit hole.

> We don't follow the personal preferences here, and this bug report is
> exactly about the contrast being too low, so obviously people do think
> that.

With all due respect, the reporter is just one person.  There are many
more users of the GTK builds (including me), and over the years they
have not had problems with this.

bug#46493: [feature/pgtk] Low contrast region face

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> I disagree that the contrast is either too low or "dramatic".  And
>> anyway, I don't think we should be changing long-standing defaults for
>> personal preferences in this area.
>
> We don't follow the personal preferences here, and this bug report is
> exactly about the contrast being too low, so obviously people do think
> that.

I've now removed the usage of the Gtk selection face for the 'region'
face under (p)gtk for the reasons mentioned in Emacs 29.

bug#46493: [feature/pgtk] Low contrast region face

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now removed the usage of the Gtk selection face for the 'region'
> face under (p)gtk for the reasons mentioned in Emacs 29.

I thought we agreed to not remove that feature? And in any case, the
special color should be kept, or users will not be able to revert to the
previous behavior?  (I've already undone the changes to gtkutil.c.)

bug#46493: [feature/pgtk] Low contrast region face

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> I thought we agreed to not remove that feature?

Nope.

bug#46493: [feature/pgtk] Low contrast region face

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Nope.

In that case, the code on macOS must be deleted too, since there is no
more free operating system where the system region face is used.

(I might add that this is also a serious regression on GTK+ 2.x, where
the default selection color is a deep blue, which has no contrast issues
whatsoever.)

bug#46493: [feature/pgtk] Low contrast region face

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> In that case, the code on macOS must be deleted too, since there is no
> more free operating system where the system region face is used.

Good point.

bug#46493: [feature/pgtk] Low contrast region face

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu [2022-06-18 09:58 +0800] wrote:

> Basil, do you have any GTK stylesheet enabled that isn't Adwatia?

The only GTK3-related settings I'm aware of on my system are listed in
https://bugs.gnu.org/46493#11.  Is there anything else you'd like me to
check?

Recall that I use X, specifically Xmonad (sans desktop environment), and
not Wayland, FWIW.

Thanks,

-- 
Basil