[Bug 23651] Preferred handler doesn't get the channel if too new; no way to handle *only* the request

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=23651


Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Preferred handler doesn't   |Preferred handler doesn't
                   |get the channel if it's too |get the channel if too new;
                   |new                         |no way to handle *only* the
                   |                            |request




--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-09-15 03:55:01 PST ---
(In reply to comment #0)
> In some cases this handler doesn't actually get the channel. From the looks of
> it this happend because MC starts dispatching the channel before it has
> finished introspecting the recently popped up handler, which means that it's
> unaware of the specific filter and ignores the preferred handler.

I'd go further than this, and say that as long as the preferred handler exists,
it should be the first handler tried even if its filters are known not to
match, as you suggested as one alternative:

>   * Always give it to the preferred handler, even if its filter is unknown (or 
>     even if it doesnt match?)

because that makes it easier to write one-shot handlers (like nautilus-sendto)
that handle the channel that they themselves requested, but never want to be
given channels requested by other processes.

(Admittedly, this doesn't matter for n-s, because FileTransfer channels can't
usefully be requested on another process's behalf - but it could matter for
Tubes, Text etc.)


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.