GNOME Bugzilla – Bug 501222
Evolution: The width of the windows...
Last modified: 2012-02-15 13:47:43 UTC
The width of the windows is not changeable. It is fixed to a bit more than my screen width of 1024 pixels. Also, the left, vertical window-seperator is not changeable. Distribution: Ubuntu 7.10 (gutsy) Gnome Release: 2.20.1 2007-10-19 (Ubuntu) BugBuddy Version: 2.18.1
Alt + MiddleMouse Drag solved the problem. It seems to be a known bug of the german version of evolution.
Can you confirm that Andre?
if the reporter refers to the account wizard at the first start of evolution (i'm not sure), this has been filed already, and i've seen it myself.
The problem is not the size of a wizard but the size of the main evolution window. Furthermore, the separator between the left, vertical frame and the two right, horizontal frames (in email-view) is not moveable. Resizing of both the frame and the separator does work directly after starting evolution for the first time after booting Ubuntu. The moment I click on any entry in the left frame, both window and frame resize themselves and are not changeable until I reboot. I am using the german version of Ubuntu and Evolution, if that helps.
haven't heard of that stuff before. i wonder whether this is a downstream problem.
Could you make a screenshot of your problem? I can't even imagine, what the problem might be. What happens if you try to click the border of the window?
OK, I found out a bit more: The problem seems to be that the right frames (list of emails and display of current emails) can not be made smaller than a certain width. The left frame can not be made smaller than the width of the first row of text: "Eingang xxx ungelesen, xxx insgesamt" (In german Eingang=inbox, ungelesen=unread, insgesamt=total) with xxx being the number of unread and total emails. If made as small as possible, "inbox" will be replaced by "...", but "ungelesen", "insgesamt" and the numbers will stay at the same length. If the number of unread and total emails gets large, this frame gets wide. Combined with the fixed width of the other two frames, it then exceeds my poor 1024 pixels of screen resolution. Obviously, this problem ony occurs in the german version (because of the length of the words "ungelesen" and "insgesamt") and only if there are many (over a hundred) unread mails. I would think that the problem could be fixed if the width of the right two frames was changeable to a slightly smaller width than it is now.
(In reply to comment #1) > Alt + MiddleMouse Drag solved the problem. > > It seems to be a known bug of the german version of evolution. > This was wrong. It didn't solve the problem. I just had no unread mail at that moment, so the window was resizable.
Created attachment 103944 [details] Screenshot showing one possible occurence of the stated problem Here is a screenshot of the issue. The string in the headline of the left side-pane is exceeding a certain width, which causes even a maximized window getting resized exceeding the physical resolution of the screen. Especially in Calendar view this is annoying, because, at least in German locale, the left side-pane is getting resized every time you select another day (e.g. from "Montag" to "Donnerstag", because "Donnerstag" has more characters to be displayed.) English version is afaik using abbrevations there, so this should not occur.
I can confirm the problem with Polish locale. Window is 1039 pixels wide on a 1024 pixels wide screen. It is a problem for some users since one cannot use the vertical scrollbar in message list window.
Created attachment 123677 [details] Screen overhang.
Comment on attachment 123677 [details] Screen overhang. I can confirm this problem on 2.24.1. Attached is a screenshot. The overhang doesn't happen when evolution is first started, but as soon as another function is selected (calendar, mail, etc) the view is messed up until the program is restarted.
Not displaying the sidebar seems to fix the problem, so it seems to be related to the inability to adjust the sidebar width.
Summarizing the many bug reports on this topic under bug 462786. Adding a comment to bug 462786 describing the situation in GNOME 3.2 would be welcome. *** This bug has been marked as a duplicate of bug 462786 ***