Close-to-tray support in new AllTray

[Michael B. Trausch]

Intercepting close-button does not work in trunk; this needs to be fixed. However, the available options to fix this are unclear, and I'm not sure how to proceed. Being that this bug blocks the 0.7.4dev release, I don't know if that release will be coming on-time or not. Any help with ideas is welcome. The goal is to find a way to do this that is portable between window managers and application software, and does _not_ interefere with the operation of things like drag-and-drop and so forth.

Optionally, you (the community) could decide that this is not a killer feature, and the release will go forward as otherwise planned. But I won't do that without some form of consensus.

[hasi (whynot-nurfuerspam)]

I am not a developer at all. However, can't you do the same thing the old versions did?

For me this is actually a quite important feature, especially since I am using the task panel in "auto-hide" mode, where clicking on the systray icon is not a convenient alternative.

BTW, thanks for working on this important application. I've been using the "old" alltray (v0.69) for quite a while now -- first with KDE 3.5, then with KDE 4.1 through 4.3. In all the KDE 4 versions (don't remember about KDE 3.5), catching the execution of the "close" button does not even work flawlessly with v0.69: in many cases, the applications close anyway (I am mainly using thunderbird and sunbird).

[Michael B. Trausch (mtrausch)]

On Mon, 17 Aug 2009, hasi wrote:

> I am not a developer at all. However, can't you do the same thing the
> old versions did?

I could, in theory, but that would be troublesome. It depends highly on
the underlying window manager being known, and using sometimes different
tricks based on the currently running window manager, so it is not really
ideal. My goal here is to have it be more robust, as well as
WM-independent, so that it will "just work" no matter if you are using
GNOME, KDE, e17, or fluxbox (or any other EWMH compliant WM, of which
there are many).

> For me this is actually a quite important feature, especially since I am
> using the task panel in "auto-hide" mode, where clicking on the systray
> icon is not a convenient alternative.
>
> BTW, thanks for working on this important application. I've been using
> the "old" alltray (v0.69) for quite a while now -- first with KDE 3.5,
> then with KDE 4.1 through 4.3. In all the KDE 4 versions (don't remember
> about KDE 3.5), catching the execution of the "close" button does not
> even work flawlessly with v0.69: in many cases, the applications close
> anyway (I am mainly using thunderbird and sunbird).

Does AllTray 0.70 (Jochen's last release) work any better for you?

> --
> Close button support in AllTray trunk
> https://bugs.launchpad.net/bugs/404564
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in AllTray: Confirmed
>
> Bug description:
> Intercepting close-button does not work in trunk; this needs to be fixed. However, the available options to fix this are unclear, and I'm not sure how to proceed. Being that this bug blocks the 0.7.4dev release, I don't know if that release will be coming on-time or not. Any help with ideas is welcome. The goal is to find a way to do this that is portable between window managers and application software, and does _not_ interefere with the operation of things like drag-and-drop and so forth.
>
> Optionally, you (the community) could decide that this is not a killer feature, and the release will go forward as otherwise planned. But I won't do that without some form of consensus.
>

[hasi (whynot-nurfuerspam)]

Michael:
I have now tested AllTray 0.70 for a while, and still it happens that sometimes applications just close for good after hitting the "close" button (when they should go to the tray, which they often do, but still often enough not).

[Michael B. Trausch (mtrausch)]

hasi: If you can find a way to reliably duplicate that issue, let me know. I may open another bug report, since this bug report is targeted at the new development that aims to supercede 0.70 and currently being worked on in the lp:alltray tree (which is a complete rewrite of AllTray).

[Forlong (forlong)]

Hi,

I just wanted to add that this was a fundamental feature of alltray for me.
Just to make sure we are talking about the same thing:
I want to be able to
1) "close" an application into the tray
2) exit it in the alltray context menu

Since those two features are missing from the latest version and the version in Karmic renders icons incorrectly (Bug #403135) I have to stop using Alltray for now.

Thanks for all your work, though.

[Michael B. Trausch (mtrausch)]

Hi Nick,

What do you mean exit from the system tray? You can exit AllTray in the system tray, but not the application; AllTray cannot know how to properly close an application and so that falls to the user.

As far as bug 403135 goes, I can try to formulate a patch (no assurances, that code is messy, old AllTray that is), but the problem is that I am not sure that Ubuntu would accept it even if I could find the right way to fix it there.

This bug is the highest priority for AllTray at the moment, and as *soon* as I can fix it, it will be fixed. The problem is that I simply do not yet know how to do it in a portable fashion, and old AllTray only worked in certain circumstances (that is, of course, undesirable).

[Forlong (forlong)]

Hi again,

I am on Intrepid right now and I have to say Alltray works perfect there.
No issues with dark panels and I am able to close Evolution to the tray as well as exit Evolution from the context menu.

Sorry, but I have to ask: why did things have to change from there at all?

[Szunti (szunti)]

Have you read this: http://john.nachtimwald.com/2009/11/01/x11-intercept-window-close-event/ ?

[Michael B. Trausch (mtrausch)]

Yes, however there are still issues to be worked out. I will not release any
implementation that isn't 100% workable, and missing out on drag and drop
support is not something I am willing to do; the correct solution for
AllTray is one that works for everyone in all cases. If there is a way to
be 100% sure that events, dnd, etc. are not lost, I am all for it.

--
Sent from my ADP1 Phone running Cyanogen

On Dec 5, 2009 5:41 PM, "Szunti" <email address hidden> wrote:

Have you read this: http://john.nachtimwald.com/2009/11/01/x11
-intercept-window-close-event/<http://john.nachtimwald.com/2009/11/01/x11-intercept-window-close-event/>?

--
Close button support in AllTray trunk
https://bugs.launchpad.net/bugs/404564
You received this bug notification because you are a direct subscriber
of the bug.

Status in AllTray: Confirmed

Bug description:
Intercepting close-button does not work in trunk; this needs to be fixed.
 However, the available options to fix this are unclear, and I'm not sure
how to proceed. Being that this bug blocks the 0.7.4dev release, I don't
know if that release will be coming on-time or not. Any help with ideas is
welcome. The goal is to find a way to do this that is portable between
window managers and application software, and does _not_ interefere with the
operation of things like drag-and-drop and so forth.

Optionally, you (the community) could decide that this is not a killer
feature, and the release will go forward as otherwise planned. But I won't
do that without some form of consensus.

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/alltray/+bug/404564/+subscribe

[Szunti (szunti)]

I don't know these stuff. I just googled a bit in a hope I find
something useful. About DND the XEmbed specification sais that it's easy
to implement:
(http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html#id2447278)

"Basically, the embedder has to operate as drag-and-drop proxy for the
client." I think it's the same for other events. (Not if what i think
means anything)

[Michael B. Trausch (mtrausch)]

Yes, but XEmbed isn't known by all client apps, and I have not managed to
get it and other misc. odd behaviors to work correctly when reparenting.
Believe me, I have not forgotten this issue and I have been (aside from the
past couple of weeks when I have been in Toledo) trying to get things to
work properly. This bug will be closed as soon as I possibly can, I am
sorry that it hasn't been done yet, but I have been working on it.

--
Sent from my ADP1 Phone running Cyanogen

On Dec 5, 2009 6:45 PM, "Szunti" <email address hidden> wrote:

I don't know these stuff. I just googled a bit in a hope I find
something useful. About DND the XEmbed specification sais that it's easy
to implement:
(
http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html#id2447278
)

"Basically, the embedder has to operate as drag-and-drop proxy for the
client." I think it's the same for other events. (Not if what i think
means anything)

--

Close button support in AllTray trunk
https://bugs.launchpad.net/bugs/404564You received this bug n...

[Ross (fudfuzz)]

Hi there,

If you need another test case that always shows the close button quitting the application:
alltray v. 0.7.4dev
using Gnome + compiz (metacity?)
Use Thunderbird-3.0 with the StartUp Master add on.

Now on first run alltray correctly recognises that the first winow that pops up is the masterpassword dialog and the tray icon remains after the password is entered.

However, EVERY time I click close, the tray icon disappears and alltray is no longer running.

I would like to help anyway I can so let me know if there are any outputs from verbose flags or logs that you need.

Thanks for all your hard work so far.

Ross.

[Michael B. Trausch (mtrausch)]

CLose-to-tray is now implemented in the 0.7.5dev release branch, from which a release will be made in the next several minutes. The tarball is ready, I just need to sign and upload it.