GNOME Bugzilla – Bug 494171
Send/receive dialog cut off
Last modified: 2008-10-22 18:26:49 UTC
This problem could be solved by the proposal in bug 360614, but I don't know how likely that is to ever get implemented... So for the time being: If you have more than 3 accounts that fetch/send mail, the send/receive dialog will get a scrollweel and only show the first three. The window could expand to the required size... I suppose more than 6 or 7 accounts is not very common, so it could be limited at some point (same height as width?) but until then, it shoudl expand to fit all the accounts in.
Created attachment 98663 [details] Shot
i think matthew will implement saving the window size after a manual resize to gconf for evolution 2.22
Not really what I was thinking about but that would help, too.
I can confirm the bug. Every time I click send and receive the window will be the same size, not showing all of my accounts. I have to manually resize it, but the new size won't be saved for the next time I Send and Receive email.
i wonder if matthew has a patch handy that stores the send/receive dialog window size to some gconf key?
This can easily be done with OpenedHand's GConfBridge. I've already proposed embedding the GConfBridge sources -- all two files -- into Evolution until GNOME comes up with a better configuration system. It's not worth writing out the whole save-widget-dimensions-using-delayed-writes pattern again by hand. I'll put together a patch.
Created attachment 103402 [details] [review] Proposed patch With GConfBridge, this is stupid simple.
Matt, we have discussed this before. I wouldn't be interested to take it unless we get a tangible benefit out of it. Not too late surely. I think we do it the same way in every other place, we can do it here also. (get/set the window sizes to GConf). We can look at GConfBridge later. Hope you understand my point.
Bumping version to a stable release.
this is starting to annoy me. can we find a short-term solution (e.g. the one proposed in comment #8) for 2.23.x, please? i don't want to patch it every time by adding a gtk_widget_set_size_request(send_recv_dialog, 600, 600) to the code...
Someone else can take this bug if GConfBridge is still not permitted. The patch in comment #7 works, is simple, and the same approach can be applied throughout Evolution where we want persistent window sizes and/or positions. I'm not interested in hand-writing the same signal handlers and timeout logic over and over.
Created attachment 109672 [details] [review] save send receive dialog size to gconf
here's a patch that implements dialog resize signal and restores dialog size from gconf. For schema modification I took over schema that Matthew proposed.
Created attachment 109694 [details] [review] Final patch Srini agreed to let me use GConfBridge in Evolution. The GConfBridge is already in trunk, so here's the final patch I'm committing for this bug. Committed to trunk (revision 35400).
Does it mean we can get rid of all "remember window position" bugs with the same approach as here? Maybe only with one exception, I do not want to bump scheme files with such crap, it doesn't worth it, really. Maybe if it will be saved under reasonable gconf key, then it would be fine. I think we can keep the size request, and let the GConfBridge does its job just after that, so it will be better than relay on the default keys. (It scared me a bit, when I saw only dots instead of account names there, because the scheme file failed to install.)
Would be nice. I've already filed bug #529565 to take care of the places where we already save window sizes and pane positions. Keeping default window sizes in the GConf schema will work fine for users running a proper release. I think the behavior you saw was because the schema was never loaded into your GConf daemon after you installed from SVN, so the default window sizes never got loaded.
Oh, "proper release", what's that? :) You know, you can compile from official stable tarballs, but it will not work for you too, somehow.
*** Bug 541994 has been marked as a duplicate of this bug. ***
*** Bug 557467 has been marked as a duplicate of this bug. ***