Created attachment 960 [details]
drop the gtk_window_iconify call that is the culprit
Quoting a thread from 2010-12-06 20:38:
| Claws Mail starts minimized (or hidden?) with Gnome Shell.
| It's the only app that does it. Should I contact the devs of CM?
Apparently this has not been reported to you. Or perhaps it is a bug in GNOME Shell? It also affects Fedora 15 development with GNOME Shell and Claws Mail 3.7.8cvs68: https://bugzilla.redhat.com/693846
Attached patch just drops the gtk_window_iconify() call that is the culprit, and that fixes the issue. I haven't done any deep digging to examine what is going on.
(If I remember correctly) This is done so that the TrayIcon plugin's 'Hide at start-up' option works in a more agreeable manner.
On slow systems this may mean that there is a very (very) short amount of time before the claws-mail main window is shown, (< 1 second).
I don't really see what problem this causes, and it is not a bug. This is surely better than a splash screen.
Try using the TrayIcon's 'Hide at start-up' with your patch and then decide which behaviour is less desirable.
I'll add that if Gnome Shell honors the gtk_window_iconify() request, but not the gtk_window_deiconify() request that comes after, it's a Gnome Shell problem unless I deeply misunderstood the role of window managers.
Indeed, thanks for the insight. That's what I meant with "not done any deep digging". ;)
The deiconify() call is done here actually (just to confirm that), but doesn't raise the window. I've poked the "Mutter" (2.91.93) maintainers at Fedora.
> Try using the TrayIcon's 'Hide at start-up' with your patch and then
> decide which behaviour is less desirable.
Certainly the one with the patch, because this is GNOME Shell - so much is different. Currently, there is no startup notification or anything like that when starting Claws Mail with a simple click on its app icon. Only those users, who visit the "Windows" view (e.g. with Alt+TAB) would find/see the active albeit minimized Claws Mail window and would need to raise it explicitly. That would be very confusing.
The tray icon plugin is not loaded by default. If loaded and configured for "Hide at startup", the patched Claws Mail appears briefly before it minimizes again. Acceptable as a work-around IMO.
Anyway, I'm not asking you to apply the patch. I just want to learn what's broken where and what will need to be changed.
Thanks ! Keep us informed about what the Shell guys think about that. (I love that we deiconify our main window once everything's ready, it has the advantage of looking nicer, and this is especially visible on slow machines or slow ssh -X, and I'd hate to have to remove it).
As an alternative to dropping the iconify call, the following also works in mainwindow.c main_window_popup():
Thanks, I've tried it with xfwm4 and it works fine. Maybe it can be commited if it also works with Metacity and KDE's WM ?
But, let's wait for Gnome Shell's people response first.
Changes related to this bug have been committed.
Please check latest CVS and update the bug accordingly.
You can also get the patch from:
2011-04-10 [colin] 3.7.9cvs3
2011-04-10 [colin] 3.7.9cvs2
Use gtkut_window_popup() to work around a bug in Gnome Shell.
This is the patch from bug #2396, it should be innocuous even
if that's useless to do deiconify + present window...
The patch causes damage. It just seems to work. In GNOME Shell, several of Claws Mail's dialogs don't receive focus due to this patch.
makes the main window appear without affecting the dialogs.
Hmm, not really... :/
Created attachment 990 [details]
debug patch 1
I've been trying to find out how close together I can move the iconify() and deiconify() calls to prevent the main window from disappearing. Something in Claws Mail between the two calls triggers this bug's symptoms. The "debug patch 1" is the most minimal change to Claws Mail I've arrived at. With it, Claws Mail starts with a visible main window.
[ The further down I move the deiconify() call, the more I need to patch Claws Mail in various files. For example, if I move it down two lines further, I need to patch summaryview.c summary_init() and take out the gtk_widget_modify_font() and summary_clear_list() calls, and also patch textview.c and take out the gdk_cursor_new(GDK_WATCH) call. ]
Is everything okay with the GtkCMCTree implementation?
Created attachment 991 [details]
debug patch 2
If the deiconify() is not inserted directly after folderview_init() as in debug patch 1, but two lines further down after summary_init() and messageview_init(), a few more things need to be taken out to prevent the main window from starting minimized.
It seems some of the things taken out corrupt GTK structures.
according to comment 8.
(Reverted 3.7.9cvs2 at 3.7.9cvs27)
I have the same bug in archlinux.
Is it solve or gonna be solve soon ?
Notice beginning of comment 13 of this bug report. If you need a work-around (under consideration of everything that has been commented on before in related tickets), here's a brute-force one:
thanks for the response.
But if there is a patch to fix this issue, why the status of this bug is RESOLVED INVALID ? This problem will be fix or not in the next release of claws-mail ?
If you had actually read comment 3, you would know that it is a bug in GNOME Shell's window manager. The work-around (!) I have pointed you at is not a fix, just a work-around that removes a feature from Claws Mail. A feature that may be important to some users (e.g. those who use the tray icon and want Claws Mail to start minimized).
Do you know whether a fix has reached Gnome Shell ?
Upstream ticket hasn't changed yet:
To test, I would need to rebuild Claws Mail without the work-around sometime this weekend for Fedora 16. Will report the results.
Submitted a quick scratch-build ( http://koji.fedoraproject.org/koji/taskinfo?taskID=3468002 ) and it still starts minimized with:
$ rpm -q gnome-shell mutter gtk3 claws-mail
Thanks Michael !
I've put back something in CVS, gtk_window_present() after the deiconification and a fix for alertpanels too. It seems to work OK...
> It seems to work OK...
Can you reproduce weirdness like you had in comment #8 ? For me it seemed to go rather OK, with occasional strangenesses.
No focus issues noticed. The original ticket for that https://bugzilla.redhat.com/711257
*** Bug 2457 has been marked as a duplicate of this bug. ***