balsa issueshttps://gitlab.gnome.org/GNOME/balsa/-/issues2023-09-08T19:09:30Zhttps://gitlab.gnome.org/GNOME/balsa/-/issues/92Request: possibility of sorting by "flagged" or showing only "flagged" emails?2023-09-08T19:09:30ZFrank McLaughlinRequest: possibility of sorting by "flagged" or showing only "flagged" emails?It is already possible in Balsa to go to the "next flagged message" (although apparently not the previous flagged message as far as I can tell). The mailbox window allows sorting by number, from, subject, date, and size, but it does not...It is already possible in Balsa to go to the "next flagged message" (although apparently not the previous flagged message as far as I can tell). The mailbox window allows sorting by number, from, subject, date, and size, but it does not allow sorting by status or whether a message is "flagged." I don't see any way one can conveniently view all flagged messages together in some way. It would be nice to be able to sort by whether a message is "flagged," or possibly to have another option in the search drop-down for "flagged" (i.e., show only flagged messages).https://gitlab.gnome.org/GNOME/balsa/-/issues/91CardDAV address book support2023-10-14T15:45:07ZAlbrecht DreßCardDAV address book supportI just pushed the new branch [carddav-ab](https://gitlab.gnome.org/GNOME/balsa/-/tree/carddav-ab) which implements limited support for remote CardDAV address books in Balsa. Please see the file [README-CardDAV.md](https://gitlab.gnome.o...I just pushed the new branch [carddav-ab](https://gitlab.gnome.org/GNOME/balsa/-/tree/carddav-ab) which implements limited support for remote CardDAV address books in Balsa. Please see the file [README-CardDAV.md](https://gitlab.gnome.org/GNOME/balsa/-/blob/carddav-ab/README-CardDAV.md) for details about the implementation and its limitations – as CardDAV address books usually contain a plethora of information in its `VCARD` elements, modifying them using Balsa's the rather limited address book editor would probably break them. Thus, it is *only* possible to read the address book and add items, but modifying or deleting elements is not supported (use e.g. your mobile phone for that…).
I divided the implementation into a WebDAV and a CardDAV layer. Rationale: Iff we decide to include it in Balsa, we might also want to have CalDAV support in the future (to add iCalendar requests to a remote calendar), and splitting these logical layers would simplify the implementation.
It would be great if someone could have a look at it, before I create a merge request. As always, any comment would be highly appreciated!
Thanks, Albrecht.https://gitlab.gnome.org/GNOME/balsa/-/issues/90Multiple IMAP Mailboxes2023-07-20T20:36:02ZLioh MoellerMultiple IMAP MailboxesI have set up multiple IMAP Mailboxes and even gone through all the folders and defined the relevant identity. Now I have tried to mark e.g. SENT in Mailbox 1 as type Inbox and then mark SENT in Mailbox 2 as type Sentbox as well. It look...I have set up multiple IMAP Mailboxes and even gone through all the folders and defined the relevant identity. Now I have tried to mark e.g. SENT in Mailbox 1 as type Inbox and then mark SENT in Mailbox 2 as type Sentbox as well. It looks like it is only possible to mark one folder as Sentbox because as soon as I mark the one in Mailbox 2, the one in Mailbox 1 is unset.
That means that e.g. sent mails are stored in the wrong Mailbox if I send a new mail from the other account.https://gitlab.gnome.org/GNOME/balsa/-/issues/88Email source view broken2023-05-16T17:04:55ZAlbrecht DreßEmail source view brokenNewly, the source view dialogue is broken, just a very small scrollable area, which is basically unusable – it _used_ to work just fine in the past, though:
![Bildschirmfoto_2023-04-19_18-45-59](/uploads/7d88b8cdbe2b4a8fa8530dda11fd95c9...Newly, the source view dialogue is broken, just a very small scrollable area, which is basically unusable – it _used_ to work just fine in the past, though:
![Bildschirmfoto_2023-04-19_18-45-59](/uploads/7d88b8cdbe2b4a8fa8530dda11fd95c9/Bildschirmfoto_2023-04-19_18-45-59.png)
Not sure, but this _might_ be linked to the recent (huge) merge !71 – which again raises the question if it is a good approach to replace working `gtk_*` methods by our own wrappers, just to be able to switch to a newer Gtk version in the _very_ distant future… :thinking:https://gitlab.gnome.org/GNOME/balsa/-/issues/87meson: gtk-update-icon-cache doesn't work if balsa isn't installed yet2023-09-23T19:15:48ZJeremy Bichameson: gtk-update-icon-cache doesn't work if balsa isn't installed yet- balsa 2.6.4
- meson 1.0.0
- Debian Unstable
I tried building balsa with meson on a system where balsa isn't installed:
```
--- stderr ---
gtk-update-icon-cache: Failed to open file /usr/share/balsa/.icon-theme.cache : No such file or...- balsa 2.6.4
- meson 1.0.0
- Debian Unstable
I tried building balsa with meson on a system where balsa isn't installed:
```
--- stderr ---
gtk-update-icon-cache: Failed to open file /usr/share/balsa/.icon-theme.cache : No such file or directory
FAILED: install script '/usr/bin/gtk-update-icon-cache --ignore-theme-index /usr/share/balsa' exit code 1, stopped
```
Several GNOME apps run gtk-update-icon-cache as part of a special meson_post_install.py script. Actually, a lot of them now use a [built-in feature](https://mesonbuild.com/Gnome-module.html#gnomepost_install) to run gtk-update-icon-cache but I think that only works for the standard icon directory.https://gitlab.gnome.org/GNOME/balsa/-/issues/86Add support for the soup3 build of WebKitGTK2023-07-15T10:52:32ZAlberto GarciaAdd support for the soup3 build of WebKitGTKWebKitGTK switched to soup3 a while ago while keeping the older soup2 build for compatibility.
For apps that don't use libsoup directly (and therefore don't need to port the code to the new soup API) the only change that's needed is usi...WebKitGTK switched to soup3 a while ago while keeping the older soup2 build for compatibility.
For apps that don't use libsoup directly (and therefore don't need to port the code to the new soup API) the only change that's needed is using webkit2gtk-4.1 instead of webkit2gtk-4.0.https://gitlab.gnome.org/GNOME/balsa/-/issues/85Build fails with html-widget=no2022-10-05T08:45:25ZSchievel1Build fails with html-widget=noWhen I set the option -Dhtml-widget=no the build fails. Here is the log of the failing build: https://pastebin.com/KqfC7ERu
Here is the log of a working build with -Dhtml-widget=webkit2: https://pastebin.com/Ze4pMEahWhen I set the option -Dhtml-widget=no the build fails. Here is the log of the failing build: https://pastebin.com/KqfC7ERu
Here is the log of a working build with -Dhtml-widget=webkit2: https://pastebin.com/Ze4pMEahhttps://gitlab.gnome.org/GNOME/balsa/-/issues/84IMAP mailbox: bold-face “unread messages” indicator may be misleading2022-09-21T23:23:04ZAlbrecht DreßIMAP mailbox: bold-face “unread messages” indicator may be misleadingIf an IMAP mailbox is used by more than one MUA in parallel, the bold-face mailbox name in the mailbox tree *may* wrongly indicate that unread messages are present.
To reproduce:
1. Open the IMAP mailbox in Balsa and in a second MUA.
2....If an IMAP mailbox is used by more than one MUA in parallel, the bold-face mailbox name in the mailbox tree *may* wrongly indicate that unread messages are present.
To reproduce:
1. Open the IMAP mailbox in Balsa and in a second MUA.
2. Wait until a new message arrives. Balsa lists the message and prints the mailbox name in **bold** to indicate that it contains unread messages.
3. In the second MUA, erase the new message.
4. After a short while, Balsa removes the message from the list, but the mailbox name is still printed in bold, which is a little confusing.
Note: the same effect happens if in step 3. a different MUA downloads the messages from the mailbox using POP3.https://gitlab.gnome.org/GNOME/balsa/-/issues/83Improve popup notifications, such as which server has oversize message.2022-10-10T02:14:51ZJack OstroffImprove popup notifications, such as which server has oversize message.I just had Balsa fail to download (POP3) a message because it was over the configured max size. At first, I didn't even realize it, but eventually noticed the quick popup that there was a message too large to download. Before I changed...I just had Balsa fail to download (POP3) a message because it was over the configured max size. At first, I didn't even realize it, but eventually noticed the quick popup that there was a message too large to download. Before I changed the limit, I wanted to check (IMAP) that the message was legit, but I had to start hunting through all my mail sources, since the popup didn't say which server the message was from. That popup should mention the server, and possibly even the message subject.https://gitlab.gnome.org/GNOME/balsa/-/issues/82g_date_time_new_from_unix_local fails for TAI timezone2022-12-15T18:01:21ZArne Wörnerg_date_time_new_from_unix_local fails for TAI timezoneHi!
When I use [this timezone file](http://www0.wgboome.org/zoneinfo-TAI.tar.xz), and
when I send an email _@1658946095 (`date -d@1658946095` = "Wed Jul 27 18:21:45 TAI 2022")_,
_balsa_ says,
that the timestamp is _2022-07-27T18:22:12TA...Hi!
When I use [this timezone file](http://www0.wgboome.org/zoneinfo-TAI.tar.xz), and
when I send an email _@1658946095 (`date -d@1658946095` = "Wed Jul 27 18:21:45 TAI 2022")_,
_balsa_ says,
that the timestamp is _2022-07-27T18:22:12TAI (format: %FT%T%Z)_.
It seems like _g_date_time_new_from_unix__local does not behave like _date(1)_.
Workaround: I append a patch.
But I guess you won't like it, because: It does not use _gchar_ functions.
And the workaround might not solve the whole problem, because: There seem to be lots of places where balsa assumes, that timezone_offset%60 is zero.
Btw: Exim had the same problem...
Can you somehow fix it?
I do not know why _g_date_time_new_from_unix_local_ hates me so much...
I just wanted to avoid those annoying leap seconds (once I thought that the crystal in my self-tinkered USB sensor phalanx is broken, when i woke up in the morning...)...
Thx.
Bye
Arne
[patch](/uploads/95ce3617275bdfaad9544a9096049893/patch)https://gitlab.gnome.org/GNOME/balsa/-/issues/81Documentation issues (dead links, strings differing from GUI)2023-03-19T22:05:50ZAnders JonssonDocumentation issues (dead links, strings differing from GUI)This is a list of some documentation issues so they don't get forgotten. This is a followup on more straightforward stuff that is fixed in !61.
* GnomeCard is mentioned in several strings for editing address books, but I don't think tha...This is a list of some documentation issues so they don't get forgotten. This is a followup on more straightforward stuff that is fixed in !61.
* GnomeCard is mentioned in several strings for editing address books, but I don't think that program is around anymore.
* [C/index.page](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/doc/C/authors.page) has the dead link http://www.cs.queensu.ca/FAQs/email/ , I found no working alternative for that one. Also that university seems to have [abandoned having own e-mail servers](https://help.cs.queensu.ca/faq-qsc-cs-mail-shutting-down/), so that link would probably best be replaced by some other FAQ elsewhere.
* The string "If you can't figure out how to do something but <app>Balsa</app> lets you do it, that's a bug." looks a bit strange. I suppose the meaning is something along the lines of "If you can't figure out how to do something that <app>Balsa</app> is capable of doing, that's a bug."
* [C/preferences-display-options.page](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/doc/C/preferences-display-options.page): `<gui>Alternative Layout</gui>` is not in the GUI as such. It is a drop-down containing "Default Layout", "Wide Message Layout", "Wide Screen Layout", so these could be described with name in the string after.
* [C/preferences-display-options.page](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/doc/C/preferences-display-options.page): `<gui>Automatic View</gui>` is not in the GUI, looks like this could be `Automatically view message when mailbox opened`
* [C/preferences-display-options.page](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/doc/C/preferences-display-options.page): `<gui>Fallback codeset</gui>` is not in the GUI. It looks like this is `National (8-bit) characters in broken messages without codeset header` in the GUI.
* [C/preferences-mail-options.page](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/doc/C/preferences-mail-options.page): `<gui>Don't include HTML parts as text when replying or forwarding mail</gui>` is just `<gui>Include HTML parts as text when replying or forwarding</gui>` in the GUI. Since the next string is "Tell Balsa to be sensible", that string should possibly be changed as well since the string has opposite meaning without the Don't.
* [C/preferences-mail-options.page](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/doc/C/preferences-mail-options.page): `<gui>Wrap Incoming Text</gui>` and `<gui>Wrap Incoming Messages</gui>` mentioned, but is not found in the GUI.
* [C/preferences-mail-options.page](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/doc/C/preferences-mail-options.page): `<gui>Reflow messages of type text/plain;format=flowed</gui>` was removed in https://gitlab.gnome.org/GNOME/balsa/-/commit/aeb91c88572efdfb998422e9bc45998ac075eab5 , so possibly a bit of the section about flowed format need to be rewritten.
* [C/win-composer.page](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/doc/C/win-composer.page) has two internal links to `<link xref="preferences-outgoing">`, but there is no such page.
* [C/win-composer.page](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/doc/C/win-composer.page) has two internal links to `<link xref="preferences-spelling">`, but preferences-spelling.page is not being built.
* [C/win-main.page](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/doc/C/win-main.page) mentions `<gui>Flat index</gui>`, `<gui>Simple threading</gui>`, `<gui>JWZ threading</gui>` that seem to be just Flat/Simple/JWZ now.
* [C/win-main.page](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/doc/C/win-main.page) has the link `<link xref="win-main#subwin-messagemenu">` that does nothing. Looks like `subwin-messagemenu` needs to be a `section` for the link to work?
~~* [C/authors.page](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/doc/C/authors.page) suggests using the GNOME Documentation Handbook to "add your comments online". It is unclear to me how this can be done at https://developer-old.gnome.org/gdp-handbook/stable/gettingstarted.html.en since it is a static page. That page is also quite old even with the dead link fixed, so possibly some newer text is available?~~https://gitlab.gnome.org/GNOME/balsa/-/issues/80Add translator comments2022-10-10T02:14:50ZTim SabschAdd translator commentsHi, I'm a member of the German translation team. We recently came across a few strings that could use some context information. Looking into the source code helps, but it would be great if translators would get the info directly from the...Hi, I'm a member of the German translation team. We recently came across a few strings that could use some context information. Looking into the source code helps, but it would be great if translators would get the info directly from the po file (using a translator comment such as already discussed in https://gitlab.gnome.org/GNOME/balsa/-/issues/60)
- What do the `%s` mean?: [`"Cannot read HTML preferences for “%s”: %s"`](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/libbalsa/html-pref-db.c#L316)
- What do the `%s` mean?: [`"Cannot save HTML preferences for “%s”: %s"`](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/libbalsa/html-pref-db.c#L369)
- What will happen here? FileChooser opens so the user can specify a folder?: [`"Save selected to folder and browse…"`](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/src/balsa-message.c#L976)
- Exception as in "error state" or "exceptions to a rule"" ["Manage exceptions…"](https://gitlab.gnome.org/GNOME/balsa/-/blob/master/src/pref-manager.c#L2556)
Thanks!https://gitlab.gnome.org/GNOME/balsa/-/issues/79handling of MDN, iCalendar replies; Sender: header2022-10-10T02:14:51ZAlbrecht Dreßhandling of MDN, iCalendar replies; Sender: headerLooking into the implementation of WKD support (issue #71), I stumbled across a few odd usages of the [RFC 5322 “Originator” fields](https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.2) in general and the `Sender:` header in part...Looking into the implementation of WKD support (issue #71), I stumbled across a few odd usages of the [RFC 5322 “Originator” fields](https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.2) in general and the `Sender:` header in particular.
1. MDN's
In `src/balsa-message.c`, function `handle_mdn_request()`, we check if a MDN request looks suspicious by checking if the `Disposition-Notification-To:` address equals `Reply-To:`, `From:` or `Sender:`. However, [RFC 8098 sect. 2.1](https://datatracker.ietf.org/doc/html/rfc8098#section-2.1) states that a MDN request is suspicious (i.e. the user's consent *should* be obtained) “*if the address in the Disposition-Notification-To header field differs from the address in the Return-Path header field*”.
2. iCalendar replies
In `src/balsa-mime-widget-vcalendar.c`, the reply to a `VEVENT` request is sent to (in this order) the `Reply-To:`, `From:` or `Sender:` address. [RFC 5545](https://datatracker.ietf.org/doc/html/rfc5545#section-2.1) defines that “*"REPLY" refers to the method a recipient of a request uses to update their status with the "Organizer" of the calendar component*”, though.
Both use cases query the function `libbalsa_message_get_sender()` to obtain the `Sender:` of the message as fallback iff neither `Reply-To:` nor `From:` is valid (the latter should *always* be present, but *may* be more than one address). This function is a getter for `_LibBalsaMessage::sender` which is modified by `libbalsa_message_set_sender()`. However, this function is called *only* from `libbalsa_mailbox_imap_load_envelope()` (`libbalsa/mailbox_imap.c`) which fills in the value obtained from the `ImapEnvelope`. The latter is populated by `imap_envelope_from_stringi()` (`libbalsa/imap/imap-handle.c`) which interprets the data of an IMAP `ENVELOPE` response. However, this does *not* contain the data of the RFC 5322 message headers, as defined in [RFC 3501, sect. 2.3.5](https://datatracker.ietf.org/doc/html/rfc3501#section-2.3.5) and [RFC 3501, sect. 7.4.2](https://datatracker.ietf.org/doc/html/rfc3501#section-7.4.2): “*If the Sender or Reply-To lines are absent in the [RFC-2822] header, or are present but empty, the server sets the corresponding member of the envelope to be the same value as the from member*”.
In short, using `_LibBalsaMessage::sender` is completely useless for non-IMAP mailboxes (i.e. always `NULL`) and misleading at best for IMAP.
However, IMHO it would be helpful to add the value of the `Sender:` header (extracted by gmime) to `_LibBalsaMessageHeaders` so it could be displayed like `From:` etc. with a localised/translated label, and I will probably need it for WKD.https://gitlab.gnome.org/GNOME/balsa/-/issues/78Edit with GNOME-Editor2022-05-17T15:02:09ZPeter BloomfieldEdit with GNOME-EditorIn the compose window, the `Edit` menu has a final option `Edit with GNOME-Editor`, which opens a text editor window (`Gedit` for me) for editing the message text. It is currently launched using old-school `fork()` and `exec()`, and `g_t...In the compose window, the `Edit` menu has a final option `Edit with GNOME-Editor`, which opens a text editor window (`Gedit` for me) for editing the message text. It is currently launched using old-school `fork()` and `exec()`, and `g_timeout_add(200, …)` to wait for completion.
Letting `glib` do the work with `g_spawn_async()` and `g_child_watch_add()` is simpler. See [this new branch](https://gitlab.gnome.org/GNOME/balsa/-/tree/78-edit-with-gnome).https://gitlab.gnome.org/GNOME/balsa/-/issues/77Request: Possibility of a tray icon?2022-10-10T02:14:51ZFrank McLaughlinRequest: Possibility of a tray icon?It is possible to have a tray icon, especially one that can change depending on whether there's new unread mail? If not, would it at least be possible to have the window title change when there is new unread mail, so that kdocker can pi...It is possible to have a tray icon, especially one that can change depending on whether there's new unread mail? If not, would it at least be possible to have the window title change when there is new unread mail, so that kdocker can pick up on it? Thank you!https://gitlab.gnome.org/GNOME/balsa/-/issues/76Switch development branch from "master" to "main"2022-11-17T23:56:14ZPeter BloomfieldSwitch development branch from "master" to "main"To be more inclusive, many projects are moving their development branches from `master` to `main`. `Balsa` should join the movement.To be more inclusive, many projects are moving their development branches from `master` to `main`. `Balsa` should join the movement.Peter BloomfieldPeter Bloomfieldhttps://gitlab.gnome.org/GNOME/balsa/-/issues/75Printing of HTML messages is confusing/broken2022-05-15T16:46:35ZAlbrecht DreßPrinting of HTML messages is confusing/brokenIn a [recent message to the mailing list](https://mail.gnome.org/archives/balsa-list/2022-March/msg00014.html) a user noted that printing of HTML messages is confusing: he selected the HTML part of the message, which included an external...In a [recent message to the mailing list](https://mail.gnome.org/archives/balsa-list/2022-March/msg00014.html) a user noted that printing of HTML messages is confusing: he selected the HTML part of the message, which included an external image (which he loaded)downloaded), but the printout misses the image.
Reason: the printout is controlled by the settings on the 3rd tab of the printing dialogue instead of using the actually displayed (html vs. plain text, external content being downloaded) data from which printing is initiated. The natural approach would be to just print the message as it is _currently displayed_ and remove the extra settings for printing.
Looking deeper into this issue, the problem is more complex:
1. Any external HTML content which has been downloaded is stored in the Webkit cache on disk, but Webkit does not offer any method to check the cache contents.
Simple solution: add a flag to `LibBalsaMessageBody` indicating whether external contents has been downloaded (either explicitly, or due to a setting in the HTML preferences database) or not. Using this flag can also fix another weird behaviour: user selects the HTML part of a message, confirms downloading external content, opens the same message _again_ in a separate window, and the button for downloading external content re-appears.
The drawback of this approach: when the message is de-selected, the flag status is lost, i.e. after selecting the massage again, downloading external contents needs to be re-confirmed (which is loaded from the cache unless it has been cleared in the meantime, though). As alternative, the HTML preferences database could be used, but the implementation may be difficult (association with message and body, cleanup when messages are moved or erased, etc.).
2. Remember which part of a `multipart/alternative` is activated.
Again, the simple solution is an additional `LibBalsaMessageBody` flag, plus a reference to the parent part of each body, as whenever a different text part is selected we must remember the selection with the `multipart/alternative` parent.
3. Testing a _very_ first implementation of 1. and 2. above, it turned out that printing of messages containing a `multipart/related` (typically a `text/html` plus embedded images) in completely broken.Albrecht DreßAlbrecht Dreßhttps://gitlab.gnome.org/GNOME/balsa/-/issues/74Line break does not consider quotes in preview2022-05-15T14:16:08ZDanManLine break does not consider quotes in previewWhen viewing a received plain text mail with quoted lines in it that are longer than the line-wrap limit, a line break will be inserted/forced.
Problem is that the resulting new line isn't marked up as a quote. Example:
`> This is a lo...When viewing a received plain text mail with quoted lines in it that are longer than the line-wrap limit, a line break will be inserted/forced.
Problem is that the resulting new line isn't marked up as a quote. Example:
`> This is a long line of text that's also a quote.`
That's how it's written in the mail. Let's say the line-break is forced after the word "text". That'll result in the preview looking as if it was written as:
```
> This is a long line of text
that's also a quote.
```
The 2nd half of the line will not be part of the quote anymore. That makes it all really hard to read, also because the highlighting is affected.https://gitlab.gnome.org/GNOME/balsa/-/issues/73[Encryption] Balsa doesn't use the selected key2022-04-07T14:29:38ZChristoph Klassen[Encryption] Balsa doesn't use the selected keyWhen I don't own the public key for an email address and select one from the list, Balsa doesn't use the selected one but a different one.
Steps to reproduce:
1. Open compose window
2. Enter an email address whose key you don't own yet ...When I don't own the public key for an email address and select one from the list, Balsa doesn't use the selected one but a different one.
Steps to reproduce:
1. Open compose window
2. Enter an email address whose key you don't own yet in the To-field
3. Make sure that the option "Encrypt message" is activated
4. Click on "Send"
5. Select a key from the list in the window "Select key" ![select_key](/uploads/03ee41d1eac3f81f51c51ec31a8556aa/select_key.png)
Result: Balsa shows a different key in the next window. ![result](/uploads/3e7c858bbd42212bc3a7a2e24e8a5a71/result.png)
Expected result: Balsa should show the selected key in the next window.
Balsa 2.6.3https://gitlab.gnome.org/GNOME/balsa/-/issues/72Using "Next unread message" not quite as expected2022-05-12T23:43:33ZPeter BloomfieldUsing "Next unread message" not quite as expectedIn a recent [mailing list thread](https://mail.gnome.org/archives/balsa-list/2022-March/msg00013.html), Andreas reported a problem with `Balsa`'s message window: selecting the next unread message changes the message in the preview pane, ...In a recent [mailing list thread](https://mail.gnome.org/archives/balsa-list/2022-March/msg00013.html), Andreas reported a problem with `Balsa`'s message window: selecting the next unread message changes the message in the preview pane, but not in the message window. Other changes to the displayed message may have a similar issue.
The cause seems to be a change in the way `GtkTreeSelection`'s "changed" signal is emitted. When a different message is selected using `gtk_tree_view_set_cursor()`, the signal used to be emitted synchronously, so the caller could assume that the signal handler had been called before `gtk_tree_view_set_cursor()` returned. That seems to be no longer the case.