Re: New odd behavior - selected message not within dislay and others.

--===============2629266743953790120==
Content-Type: multipart/signed; micalg=PGP-SHA1;
	protocol="application/pgp-signature"; boundary="=-mGlZ4RkJSIXyXsaL8R4/"

--=-mGlZ4RkJSIXyXsaL8R4/
Content-Type: text/plain; charset=UTF-8; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi All,

On 07/20/2020 03:27:36 PM Mon, Albrecht Dre=C3=9F wrote:
> Hi Jack!
>=20
> Am 19.07.20 00:20 schrieb(en) Jack via balsa-list:
>> Normally, when I've read all new messages in the current mailbox, and cl=
ick "Next Unread" Balsa switches to the mailbox with the next unread messag=
e, selects that message and displays it, and scrolls the message list to sh=
ow the new message line.  The first part does always happen - display the n=
ext mailbox with an unread message.  However, sometimes, the message select=
ed is an old one (or perhaps the one with the highest message number, which=
 is essentially random for maildir mailboxes.  That has happened infrequent=
ly, but for a long time.  It now seems more frequent.  What is new, however=
, is that the selected message is NOT scrolled to the center of the display=
, and may be very far away.
>=20
> No Heisenbug!  I also observed the latter effect (wrong scrolling), in pa=
rticular with a somewhat crowded Maildir mailbox (Postgresql mailing list),=
 with threading enabled and a high depth of the threads (more than 10 level=
s, sometimes).  In this case, typically the sorting in the mailbox is also =
broken (although Peter *mostly* fixed this effect, it still =E2=80=93but ra=
rely!=E2=80=93 occurs).  I don't use the =E2=80=9CNext Unread=E2=80=9D func=
tion, so I can't tell if it occurs here too.

I've pushed a couple of changes to GitLab that should resolve some of the i=
ssues. There was indeed at least one race: the front end displaying a mailb=
ox before the back end got to sort it. That's bad when a message has been a=
dded to a mailbox, because it's always prepended and then sorted into place=
.

>> The final, least common bit, is that I do NOT see any scrollbar on the m=
essage list.  It is always there if I switch to another mailbox and then ba=
ck.  It someimes seems to appear, if i don't pay any attention and just sta=
rt reading the new messages, and look up later to see it's back.

Is the vanishing scrollbar part of GNOME's overlay scrollbars? You can disa=
ble globally them with:

gsettings set org.gnome.desktop.interface overlay-scrolling false

They can also be disabled programmaticly for a particular scrolled window: =
<URL:https://developer.gnome.org/gtk3/stable/GtkScrolledWindow.html#gtk-scr=
olled-window-set-overlay-scrolling>, but having a mixture of overlay and pe=
rmanent scrollbars might look weird!

> Huh!  Never saw that.

It's intended for touch-screen devices, where I suppose it makes sense, but=
 it's actually used whenever there's no mouse, such as my laptop with its t=
ouch-pad =F0=9F=A4=A8=EF=B8=8F

Best,

Peter
--=-mGlZ4RkJSIXyXsaL8R4/
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQS030wPRfNNA5alz3MfX9S1uSp09QUCX0AxbAAKCRAfX9S1uSp0
9ZK/AJ4ti93x9ZeY/zQ2cJes6mkjsg8DfgCfb0Z3qcQ92X7L8e5N2oR7GxI7xjc=
=0yYl
-----END PGP SIGNATURE-----

--=-mGlZ4RkJSIXyXsaL8R4/--

--===============2629266743953790120==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list

--===============2629266743953790120==--