bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#46493: [feature/pgtk] Low contrast region face
Date: Sat, 13 Feb 2021 23:12:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]