starting emacs with alltray freezes buffer window

Bug #198528 reported by Benjamin Ferrari
Affects Status Importance Assigned to Milestone
Fix Released
alltray (Ubuntu)

Bug Description

Binary package hint: alltray


using gnome desktop.

ben@kafka: alltray -v

Alltray version 0.69

ben@kafka: emacs-snapshot-gtk -version
GNU Emacs
Copyright (C) 2007 Free Software Foundation, Inc.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
ben@kafka: alltray emacs-snapshot-gtk --no-init-file

(Please note that I can reproduce this with emacs "--no-init-file" option, so it does not seem to depend on any customized configuration or plugins I might use.)

What happens is that emacs starts, but the editor pane is all plain grey and no text is visible. Other than that, everything seems to work (I can execute commands). I can even use the menu bar, but every menu list that overlaps with the text pane is "burned" into the gray area and does not go away after I close the menu.

In the tray icon, I get what I think is a default icon. If I minimize Emacs, it is minimized into the task bar, not into the tray. When I then click on the emacs entry in the taskbar, the same broken emacs shows up. But if I click now in the tray Icon, the text pane becomes visible and I can fully use Emacs, with the exception that the close button does not work and that Emacs is still minimized to the taskbar and not to the tray icon.

If I start emacs without alltray, then start alltray seperately and click on the Emacs Window, everything works fine: Emacs is minimized into a tray icon with the emacs logo and shows text.

Revision history for this message
Michael B. Trausch (mtrausch) wrote :

Confirmed on Hardy, with Compiz enabled; there is still errant behavior as well when using Metacity, but Emacs is functional save for the fact that it refuses to minimize. This is also emacs-snapshot-gtk; I am not sure if regular emacs would experience the problem or not.

At first, it looks like when Emacs starts Alltray detects two windows, and the "real" Emacs window isn't the one being captured. If that's the case, then this isn't a bug in Alltray, per sé; it just means that to dock Emacs, one would have to always use Alltray in click mode, starting Emacs first, and Alltray second, and then grabbing the window. There are a few other applications that will do something like pop up a useless window first, and since Alltray latches onto the first window created by the application, that causes some side effects.

If this is correct (I or someone else will have to take a look at the Emacs sources to see if this is in fact the case), then this would be a bug only in that Alltray probably should have a different policy in the way that it attempts to intercept the events for applications.

Changed in alltray:
status: New → Confirmed
Changed in alltray:
status: New → Confirmed
Revision history for this message
Michael B. Trausch (mtrausch) wrote :

A fix for this is in 0.7.2dev (however that is not a release that is suitable for day-to-day use), which will become 0.8.0. It also handles multiple Emacs windows that belong to the same process cleanly. Will mark this as "Fix Released" when 0.8.0 is released.

Changed in alltray:
importance: Undecided → Medium
milestone: none → 0.8.0
status: Confirmed → Fix Committed
Changed in alltray:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers