After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 335241 - [KB-Fixed] Send/Receive Messages window too big
[KB-Fixed] Send/Receive Messages window too big
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: general
2.8.x (obsolete)
Other Linux
: High major
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
evolution[kill-bonobo]
: 267386 302917 349103 350266 438639 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-03-20 16:02 UTC by Pedro MG
Modified: 2013-09-10 14:04 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
scroll box added to the send receive pop up (2.01 KB, patch)
2006-06-22 07:59 UTC, ushveen kaur
committed Details | Review
screenshot. (23.90 KB, image/png)
2006-07-14 16:25 UTC, André Klapper
  Details
Proposed patch (1.92 KB, patch)
2006-07-31 11:05 UTC, Srinivasa Ragavan
none Details | Review
Updated patch (1.96 KB, patch)
2006-07-31 11:13 UTC, Srinivasa Ragavan
committed Details | Review
Proposed patch (3.59 KB, patch)
2007-05-15 18:01 UTC, Matthew Barnes
committed Details | Review
Screenshot (30.24 KB, image/png)
2007-05-15 18:49 UTC, Matthew Barnes
  Details

Description Pedro MG 2006-03-20 16:02:07 UTC
When having more than 12 email accounts, the send/receive messages window gets
too big. On a 1024x768 gets out of screen. Maybe a lower font solve this ?

Other information:
Comment 1 André Klapper 2006-03-21 22:51:40 UTC
probably a duplicate.
Comment 2 ushveen kaur 2006-06-22 07:59:16 UTC
Created attachment 67832 [details] [review]
scroll box added to the send receive pop up
Comment 3 Srinivasa Ragavan 2006-07-14 06:07:26 UTC
Fixed to head.
Comment 4 André Klapper 2006-07-14 12:14:49 UTC
*** Bug 302917 has been marked as a duplicate of this bug. ***
Comment 5 André Klapper 2006-07-14 16:24:38 UTC
reopening. this is definitely not the way to go, perhaps it works for you, but it does not work for me, see screenshot. :-)
Comment 6 André Klapper 2006-07-14 16:25:36 UTC
Created attachment 68936 [details]
screenshot.

don't force me to scroll/resize when there is no need to. thanks. :-)
Comment 7 Srinivasa Ragavan 2006-07-14 16:32:56 UTC
what do u think can be done in your opinion?
Comment 8 Srinivasa Ragavan 2006-07-14 16:35:51 UTC
Scroll bar is the way to go. May be the max size could be little bigger. When my a/c name is little bigger I get the hscroll. and over 3 I get the vscroll.
Comment 9 André Klapper 2006-07-14 17:25:05 UTC
err... well. it worked perfectly before, so it seems that before the patch was applied, this window was somehow able to find out which height and width length would be good to display everything properly.
so please display the scroll bars only when they are actually needed - no idea if evolution itself can find this out, though. :-/

i at least vote for removing the horizontal scrolling and get back to a human width preset as it has been before - what is horizontal scrolling for? if i have 4000 mail accounts, i have to scroll vertically, but not horizontally!

and if i really can get only three accounts displayed without resizing the window myself, i vote for reverting this patch entirely - to me, the harm seems to be bigger than the benefit. there are way more evolutionusers with <=10 accounts then >10 accounts. ;-)
Comment 10 Srinivasa Ragavan 2006-07-14 17:32:41 UTC
I agree to removal of hscroll and setting the size approx to 5a/c may be 500px. So that even if some one uses 800x600, it wont go out of screen.
Comment 11 André Klapper 2006-07-14 20:41:18 UTC
srinivasa: sounds reasonible. one could even make sure that the window is centered by fixing bug 325882, by the way. ;-)
Comment 12 André Klapper 2006-07-15 13:40:10 UTC
what was the code before? how did evolution find out to get the just-fits-horizontal size? i'm against having a hardcoded width here, if there wasn't one before.
Comment 13 Srinivasa Ragavan 2006-07-15 17:40:14 UTC
andre, prev no fixed size, it picks the max/add of sizes of all widgets. thatz y it grows. we need to fix to some size and say grow to scroll beyond this.
Comment 14 Pedro MG 2006-07-16 22:51:37 UTC
Srinivasa, my inicial post was because i have to monitor 12 email accounts, and on the 1024x768 laptop the window goes out of screen. Of course on the desktop pc, with 1600x1200 all goes ok. 
So, can the scroll appear if the window_height > screen_height - 50px ?
I putted 50px as an example of a defined margin.
Comment 15 André Klapper 2006-07-28 19:29:39 UTC
garr... this makes me sick. EVERYBODY has to scroll around currently, EVERYBODY.
srini, can we please fix this? thanks.
Comment 16 André Klapper 2006-07-28 19:29:53 UTC
*** Bug 349103 has been marked as a duplicate of this bug. ***
Comment 17 Srinivasa Ragavan 2006-07-31 11:05:42 UTC
Created attachment 69957 [details] [review]
Proposed patch
Comment 18 Srinivasa Ragavan 2006-07-31 11:09:55 UTC
It will grow automatically till 750x340 by TAKE_NEEDED method, beyond which it starts showing scroll bar.  Andre can you try this patch?
Comment 19 Srinivasa Ragavan 2006-07-31 11:13:39 UTC
Created attachment 69958 [details] [review]
Updated patch

Missed one condition. sorry dudes.
Comment 20 André Klapper 2006-08-01 15:12:57 UTC
aahh.... wonderful, perfect, adorable.
everything fine now with this patch, no more useless scrolling. let's get this in.
Comment 21 Srinivasa Ragavan 2006-08-02 05:39:14 UTC
Fixed to HEAD.
Comment 22 André Klapper 2006-08-07 14:18:09 UTC
*** Bug 350266 has been marked as a duplicate of this bug. ***
Comment 23 André Klapper 2006-09-03 15:10:14 UTC
*** Bug 354116 has been marked as a duplicate of this bug. ***
Comment 24 Matthew Barnes 2007-05-15 17:03:44 UTC
*** Bug 438639 has been marked as a duplicate of this bug. ***
Comment 25 Matthew Barnes 2007-05-15 17:15:29 UTC
Reopening, this is still a problem.

See: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240147
Comment 26 Srinivasa Ragavan 2007-05-15 17:25:45 UTC
I think ellipsize would be a good deal but beyond a threshold.
Comment 27 Matthew Barnes 2007-05-15 17:56:56 UTC
If I may open up this discussion again, I see three problems with the way the dialog is currently being constructed.

  1) The GtkLabel that shows the account name in bold followed by the URI is
     not being ellipsized.  It should be in PANGO_ELLIPSIZE_END mode [*].

  2) All of the widgets are being attached to the GtkTable with horizontal
     resizing behavior of GTK_EXPAND | GTK_FILL.  This is wrong.  The only
     column that should be expanding and filling is the label column.

  3) The policy of the GtkScrolledWindow should be to never, ever, EVER
     show a horizontal scrollbar.  Ever.

[*] By the way, what exactly is the difference between a GtkLabel in ellipsize
    mode and an EClippedLabel?  Do we really still need this widget?
Comment 28 Matthew Barnes 2007-05-15 18:01:33 UTC
Created attachment 88235 [details] [review]
Proposed patch

This patch seems to work well for me.  It reverts the dialog_map() function and implements my suggestions above.  What do others think?

As a sidenote, maybe we should write custom widget for displaying each account in this dialog.  The logic in build_dialog() is just really messy and needs to be broken up better.
Comment 29 Matthew Barnes 2007-05-15 18:49:23 UTC
Created attachment 88238 [details]
Screenshot

Here's what this patch gives me when I add a bunch of accounts with ridiculously long names.  If I stretch the dialog horizontally, only the labels expand.
Comment 30 Matthew Barnes 2007-05-15 19:34:13 UTC
(In reply to comment #9)
> and if i really can get only three accounts displayed without resizing the
> window myself, i vote for reverting this patch entirely - to me, the harm seems
> to be bigger than the benefit. there are way more evolutionusers with <=10
> accounts then >10 accounts. ;-)

One thing we could do to address the vertical scrollbar objection is store the dialog's GtkVBox dimensions in GConf.  The current hard-coded dimensions (600x200) seem like a reasonable default, but it the user makes it the dialog bigger it should stay bigger.
Comment 31 Gilles Dartiguelongue 2007-05-16 12:01:58 UTC
wow, this looks great :) 
trying that tonight.

(In reply to comment #30)
 I agree that if the user makes the windows bigger, evo should remember. What about the position though ?
Comment 32 Matthew Barnes 2007-05-16 13:50:47 UTC
> (In reply to comment #30)
>  I agree that if the user makes the windows bigger, evo should remember. What
> about the position though ?

I think the dialog should always appear centered over the main window (GTK_WIN_POS_CENTER_ON_PARENT), so I don't see a need to store the position.
Comment 33 Srinivasa Ragavan 2007-05-19 20:50:22 UTC
Matthew you patch and the other suggestion looks fine. Please go-ahead :) 
Comment 34 Matthew Barnes 2007-05-25 15:02:50 UTC
Committed the patch in comment #28 to trunk (revision 33576).

I plan to do some follow-up work related to this.  See my footnotes in comment #27 and comment #28 (and _maybe_ comment #32 if there's sufficient interest).
Comment 35 Matthew Barnes 2007-06-25 22:53:17 UTC
*** Bug 438639 has been marked as a duplicate of this bug. ***
Comment 36 Matthew Barnes 2007-06-25 22:57:27 UTC
Bug #335241 (a dupe of this) was reopened due to an Ubuntu bug:

Ubuntu https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/120790 is
similar and still happening using evolution 2.11.3, reopening

The gist of the downstream bug is as follows:

    Suggestion:
     Please,
    1. let Evolution remember the enlarged windows as a default setting
      and/or
    2. let Evolution show more than 4 account settings at the pop up window
       as a default ( like Feisty)

Part 1 is consistent with comment #30.
Part 2 is unnecessary, in my opinion.

Srini, what do you think?
Comment 37 Srinivasa Ragavan 2007-06-26 03:04:53 UTC
I voted for the first one. If you do the first one, the second can be achieved. If the user resizes to a bigger size, he can see all. Lets not do the second part. I will go with you Matthew.
Comment 38 Matthew Barnes 2008-03-11 00:26:57 UTC
Bumping version to a stable release.
Comment 39 Matthew Barnes 2009-08-25 15:49:35 UTC
I think this is more or less fixed in the kill-bonobo branch.  EClippedLabel is long dead, the window already remembers its size, and with Bonobo out of the way we can finally center the thing properly over the main window.
Comment 40 Matthew Barnes 2009-08-30 05:53:00 UTC
The "kill-bonobo" branch has been merged into "master" and will debut as Evolution 2.29.1.  We believe the branch has addressed the reported issue.  If you find the issue still exists in version 2.29 or later please feel free to re-open this bug.

Closing as FIXED.
Comment 41 André Klapper 2012-06-21 09:13:54 UTC
*** Bug 267386 has been marked as a duplicate of this bug. ***