Thanks for a bug report. The 3.24.4 contains series of changes for bug #782210, which touched this. I wasn't able to make it right for the first time. It did some crazy things to me too, but down to the latest change from there the height of the panel seemed quite stable to me.

Could you try this, please:
a) open a terminal and run there:
   $ gsettings monitor org.gnome.evolution.mail
b) open another terminal and run there:
   $ evolution
c) watch the first terminal, particular the changes of the 'hpaned-size' key.

When trying here, I can change it to some value, then close evolution and when I open it again it's still in that size. Neither when I save the window maximized. I do not have hiDPI screen, which can make difference in certain cases.

Could you check when the hpaned-size is reset to the other value, whether it's on start or on close of evolution, please? You'll see it changing when dragging slider between the message list and the message preview.

It is set during resize and gets reset when evolution starts.

hpaned-size: 735
hpaned-size: 716
hpaned-size: 694
hpaned-size: 692
hpaned-size: 690
hpaned-size: 684
hpaned-size: 658
hpaned-size: 655
hpaned-size: 668
hpaned-size: 701
hpaned-size: 705
hpaned-size: 718
hpaned-size: 736
hpaned-size: 745
browser-close-on-reply-policy: 'always'
forward-style-name: 'attached'
show-headers: [('From', true), ('Reply-To', true), ('To', true), ('Cc', true), ('Bcc', true), ('Subject', true), ('Date', true), ('Newsgroups', true), ('Face', true), ('x-evolution-mailer', false)]
reply-style-name: 'quoted'
image-loading-policy: 'never'
search-gravatar-for-photo: false
junk-check-incoming: true
hpaned-size: 335

Also, it shrinks at every restart even if I don't re-enlarge it. 

for example:

hpaned-size: 1063
browser-close-on-reply-policy: 'always'
forward-style-name: 'attached'
show-headers: [('From', true), ('Reply-To', true), ('To', true), ('Cc', true), ('Bcc', true), ('Subject', true), ('Date', true), ('Newsgroups', true), ('Face', true), ('x-evolution-mailer', false)]
reply-style-name: 'quoted'
image-loading-policy: 'never'
search-gravatar-for-photo: false
junk-check-incoming: true
hpaned-size: 478
browser-close-on-reply-policy: 'always'
forward-style-name: 'attached'
show-headers: [('From', true), ('Reply-To', true), ('To', true), ('Cc', true), ('Bcc', true), ('Subject', true), ('Date', true), ('Newsgroups', true), ('Face', true), ('x-evolution-mailer', false)]
reply-style-name: 'quoted'
image-loading-policy: 'never'
search-gravatar-for-photo: false
junk-check-incoming: true
hpaned-size: 215
browser-close-on-reply-policy: 'always'
forward-style-name: 'attached'
show-headers: [('From', true), ('Reply-To', true), ('To', true), ('Cc', true), ('Bcc', true), ('Subject', true), ('Date', true), ('Newsgroups', true), ('Face', true), ('x-evolution-mailer', false)]
reply-style-name: 'quoted'
image-loading-policy: 'never'
search-gravatar-for-photo: false
junk-check-incoming: true
hpaned-size: 97
browser-close-on-reply-policy: 'always'
forward-style-name: 'attached'
show-headers: [('From', true), ('Reply-To', true), ('To', true), ('Cc', true), ('Bcc', true), ('Subject', true), ('Date', true), ('Newsgroups', true), ('Face', true), ('x-evolution-mailer', false)]
reply-style-name: 'quoted'
image-loading-policy: 'never'
search-gravatar-for-photo: false
junk-check-incoming: true
hpaned-size: 47

Thanks for the update. It's not what I see here.

Do you have the window maximized? If it is, what size does it have unmaximized?

It is maximised indeed and the problem does not occur if the app starts unmaximised.

I have no idea how to get the window size.

Do you use the same environment (Wayland and HiDPI)?

No Wayland used regularly here, neither HiDPI, but I also tested it under Wayland (though without HiDPI). There used to be a problem with maximized window, its unmaximized size could break the divisions of the window. The closer the unmaximized size gets to the maximized size the better.

Is it a similar issue, aka the umaximized window is significantly smaller than the maximized?

No, I've just tried enlarging the unmaximased window size and it doens't seem to have any positive effect.

I can confirm this bug. I'm using Fedora 26 (Evolution 3.24.4, Wayland, and HiDPI). Whenever I close Evolution the pane size is decreased.

I still do not know how to reproduce it. It doesn't reset the size here, maybe because I do not have any HiDPI monitor.

(In reply to Milan Crha from comment #9)
> I still do not know how to reproduce it. It doesn't reset the size here,
> maybe because I do not have any HiDPI monitor.

HiDPI does seem to be problem indeed. It doesn't happen on my non-HiDPI desktop computer. Maybe the easiest for you is to set-up a VM with HiDPI and scale the screen down?

If you can't reproduce the issue, is there any information that I could provide that would help?

I wish I have something to be done from outside, but I do not, unfortunately. I'll try to get to some real HiDPI monitor and debug it with it. By the way, what is the screen resolution for that monitor for you?

My monitor is a 13" 3200x1800 (approximately 277dpi)

Created attachment 359663 [details]
test-gtk.c

I'm sorry for such a long delay, but I finally managed to reproduce this. It's not that significant as for you, but I see the preview panel getting smaller each evolution start by several pixels. After some investigation I came up with this simple test application. I'd like to ask you to save it (as test-gtk.c), then install gtk3-devel package and then compile & run it as shown in the comment on the first line of this file. It will print similar lines as below, which I'd like to see. You might run it on different monitors, to get different results.

I suspect the problem is that the gdk_monitor_get_workarea() is unreliable. Evolution uses this value to set the expected window size when it's maximized, which works under X, but under Wayland the function simply returns whole screen resolution, which breaks things in Evolution.

For the two runs on my machine:

GNOME Shell on X.org:
maximize_window: monitor area:[0,27,1920,1053]
window_size_allocate_cb: w:1920 h:1053 toplevel withdrawn:1 label withdrawn:1
window_size_allocate_cb: w:1920 h:1053 toplevel withdrawn:1 label withdrawn:1
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
window_size_allocate_cb: w:1920 h:1016 toplevel withdrawn:0 label withdrawn:0
window_size_allocate_cb: w:1920 h:1016 toplevel withdrawn:0 label withdrawn:0

GNOME Shell on Wayland:
maximize_window: monitor area:[0,0,1920,1080]
window_size_allocate_cb: w:1972 h:1169 toplevel withdrawn:1 label withdrawn:1
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
window_size_allocate_cb: w:1972 h:1169 toplevel withdrawn:0 label withdrawn:0
window_size_allocate_cb: w:1920 h:1053 toplevel withdrawn:0 label withdrawn:0

Lines with "withdrawn:1" can be safely ignored, all the rest lines are important. As can be seen, the last two lines with GNOME Shell on X.org report the same width and height, but with GNOME Shell under Wayland the the last two lines report different size, the window is slightly larger here initially, then it's shrunk when it is (in the code) maximized.

I guess your HiDPI monitor has a) scale factor 2 (I used scale factor 1 here), b) larger difference in the size between the first two lines with "withdrawn:0". 

Could you paste here what it returns for you, please? I tried to change HiDPI scale factor in gnome-tweak-tool, which worked immediately under X.org, but not under Wayland.

Hi,

This is what I get:

maximize_window: monitor area:[0,0,3200,1800] scale-factor:2
window_size_allocate_cb: w:3246 h:1874 toplevel withdrawn:1 label withdrawn:1
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
window_size_allocate_cb: w:3246 h:1874 toplevel withdrawn:0 label withdrawn:0
window_size_allocate_cb: w:1600 h:872 toplevel withdrawn:0 label withdrawn:0
window_size_allocate_cb: w:1600 h:872 toplevel withdrawn:0 label withdrawn:0
window_size_allocate_cb: w:1600 h:872 toplevel withdrawn:0 label withdrawn:0

Thanks for a quick testing. From that I see that the monitor area doesn't count with the scale factor, at least not here. The main issue here is that the window is initially so large (w:3246 h:1874) and then it's immediately shrunk to the size to cover the screen (w:1600 h:872), which completely breaks the precomputed values. The best would be to know when user changes size of the panels and only then recalculate the portion, but I didn't find the way to recognize it yet. Also, storing the actual portion value instead of the size of the bottom panel would be much better as well.

But why doing anything at all with gdk_monitor_get_workarea ? It gives values that 1) are not scaled 2) don't take into account the header bar (and window decorations?)
Wouldn't it be better to call gtk_window_maximize rather than gtk_window_resize with the *wrong* values (again, not scaled, etc.) and then set the size of the widgets?

That all is done to properly restore window size after open and to deal with the way the gtk_window_maximize() works, together with being able to remember window size when it was not maximized. That's very complicated and relies on "proper" notifications order, which is the thing which broke under Wayland now.

I made some changes which helped me. The main difference now is that the saved value in GSettings is not the actual panel size, but the proportion. The panel will reset its size the first time evolution is run with this change, but then it sticks as expected.

I'd appreciate if you could give it some testing on your machine, but I do not know how hard it is to create a test build with that patch included in the Arch Linux world.

Created commit d5201031e9 in evo master (3.27.1+)
Created commit e8e10aa8c5 in evo gnome-3-26 (3.26.1+)

Tested on evolution 3.24.5, works great. Thanks!

I'm going to make 3.24.6 release and I decided to commit this there too:

Created commit d671faeb99 in evo gnome-3-24 (3.24.6+)

Hi,

I just updated to 3.26.1 and the todo bar got enabled by default and it was going crazy again until I disabled it.

I guess the same sort of change has to be made to make to-do-bar-width proportional?

F.

The folder tree on the left is not proportional, neither the To Do bar on the right. I'm not sure whether "everything should be proportional", though it seems to make sense and would eventually fix similar issues. I briefly looked into the code and the To Do pane is packed in the standard GtkPaned, not in Evolution's EPaned. It can be changed, of course, it's just that Evolution has not that much control on the GtkPaned as it has on the EPaned.

When you say that "the To Do bar got crazy", what does that mean precisely, please? Is the folder tree anyhow affected as well?

By the way, would you mind to open a new bug report for the To Do bar thing, please? I know it's related to this issue, but it's not exactly the same issue. We can still reference them between each other.

(In reply to François Guerraz from comment #22)
> I guess the same sort of change has to be made to make to-do-bar-width
> proportional?

Created commit d625e6adae in evo master (3.27.2+)
Created commit 8d56fd1091 in evo gnome-3-26 (3.26.2+)

That works for me! Thanks for working on it without me opening a new bug, I forgot about it.