[h-e-w] gnuclient - Forget the drop target. Was: gnuserv maintenance

[David Vanderschel]

On Friday, October 29, "Jason Rumney" <address@hidden> wrote:
>>>There is no DOS window with gnuclientw.

>David Vanderschel wrote:
>>Yes there is;

>I don't know what version of gnuclientw you are
>using, but for all versions I have used (at least 2,
>maybe 3), gnuclientw does not open a DOS window. This
>is the case on Windows 98 for me too.

I agree that there is no DOS window associated with
gnuclientw.  I am embarrassed to admit that I erred.
I must have made a mistake in setting up my
experiments or I misinterpreted what I was seeing.

    My best guess about what happened:  I am used to
    the gnuclient -q behaviour in which there appears
    briefly on the task bar a button for a DOS window,
    which is then replaced by the button for the emacs
    frame.  What I now see with gnuclientw is a button
    for an emacs frame which is then replaced by a
    button for an emacs frame.  It is probably not
    really a different button but a replacement of the
    heading text from the emacs frame which text
    appears in the button on the task bar.  I think
    that when I made the observation with gnuclientw,
    I was also checking something else; and, since I
    'knew' what was going to happen anyway, without
    paying enough attention, I took the emacs->emacs
    transition I was seeing to be the DOS->emacs one I
    was expecting.  Lame.  :(

I really did not know that gnuclient and gnuclientw
were linked differently.  The funny thing is that I
speculated 4 years ago in my old gnuserv tips article
that they must have been linked differently because I
had observed the unexpected different behaviour with
the shortcut as drop target.  It turns out that I
reached a correct conclusion on the linking, but for a
wrong reason!  Would that someone had responded to my
confused pleas for enlightenment back then, and it
could have saved me from the blunder I have made
today.  Indeed, it might even have headed off some of
the other confusing issues which have arisen in this
context now.

I now see the point about 3 versions or +q for
gnuclientw - _if_ you are thinking that what
distinguishes the two is how they are linked.  Since
no one ever confirmed my "linked differently" theory,
I eventually came to believe that the _only_
difference was just the forcing of the q-flag.
Furthermore, I was pleased this week when I finally
figured out what actually did cause the difference in
behaviour for drag and drop; but, as it turns out, the
critical issue about whether arguments are passed or
not had nothing to do with the different linking.


After all this discussion about the implications of
the emacs shortcut, the irony is that I personally
hardly ever use the thing!  So it turns out that I
hardly ever invoke gnuclientw at all.  (I used
gnuclient -q everywhere _except_ in the shortcut I
don't use much.  I have a hot key to bring emacs into
focus.  I even have hot keys to visit various files
and directories in emacs.  Rather than drag and drop,
it seems easier to me to use my "Edit in emacs" option
on the context menu for a file object or my "dired"
option for a folder object.)  In other words, it would
not really bother _me_ if abilty to make the shortcut
work as a drop target were not a direct requirement.
Since it appears that, with respect to whether or not
arguments are passed, Windows 9x and NT behave one way
(no) while 2000 and XP behave another (yes), I am now
proposing that the anomaly about when arguments in a
shortcut target specification are passed or not be
ignored (though the difficulty should be documented).
It is appropriate to assume that any required
arguments may be passed in all situations.

Once we start introducing additional options, it
ceases to be practical to make a different version of
the executable for each possible combination of
options which might make sense in a drop target
scenario - just to deal with the 9x and NT systems
which fail to pass the parameters.  For those who
still want a drop target shortcut, there is still the
PIF approach where one has better control over the
passing of the arguments.  Four years ago I might have
complained that the overhead for the PIF solution was
too great.  (It took 3 seconds on my 350MHz AMD K-6.)
Nowadays, I think the extra overhead is a non-issue.
(I could be on shaky ground here if the PIF concept
itself does not carry over cleanly from, say, 98 to
XP.)

The fact remains that I am not really bothered by the
brief appearance on the task bar of a DOS box button
as a prelude to the appearance of the button for the
emacs frame.  (If you are reusing an existing frame
with gnuclient, the DOS box button just disappears
quickly rather than being replaced.)  OTOH, the
persistence of a DOS box when there really is a
process waiting on gnuclient actually makes sense to
me.  Are there folks who dislike it in that situation?
Or is it that they have accidentally been spawning
meaningless and persistent DOS windows because they
were incorrectly using gnuclient without the -q and
failing to release the resulting buffers?  I am
getting at the possibility that any current annoyance
with DOS box proliferation may be an effect of user
error.

Note that all of this is independent of the
_incorrect_ behaviour I sometimes observe when DOS
boxes which should no longer exist still do exist and
some of them may even be inappropriately not minimized
- all with gnuclient.

Regards,
  David V.