Mouse polling

[Curry]

David Vaughan wrote:

> What you MUST have is a solution to your interface requirement. Let us
> then find out if that solution entails  particular programming
> features, rather than working the other way around. If it does, your
> argument to retain those features has more force, and Scott will have
> a clearer idea on an adequate implementation.

Kind of like, why should I retain my hammer, because hey, I can pound nails
with the handle of my screwdriver too if I try hard enough? Only if I fail
in that should I request that the hammer be preserved? :-)

It seems like many people are thinking with the workaround approach--how can
I get around the lack of this feature. That's fine for real missing
features, and is a common thing to do in xTalk or any other very high level
development system, but this mouse() function is a feature that has been
around forever and a day, and works very well for these types of behaviors.
It is much easier to implement in the situations where it's most often used.
It also is more readable in many situations. (There are good situations for
using the event handlers too, of course.)

If I understand it, the problem with support these polling functions is that
the behavior is complex to support as it is, and most people still haven't
made clear if it would be acceptable for the behavior to be changed a bit.
So I wonder, instead of everyone working together to figure out how to pound
nails best with other tools lying around, why not just give the hammer
manufacturer your opinion on the details of how the hammer should be
designed, so that the dilemma could perhaps be solved?

For myself, I'm OK with straight direct polling at the time of the call. The
way I use the features, I don't worry about losing a quick click up and
down, or vice versa, before the call. (This is also much less a
consideration now than with HyperCard, because computers are so much
faster.) 

The great thing about direct polling is that it would be perfect for loops
and handlers that check more than once during the script. It would also
alleviate the need for some workarounds like using wait..with messages
statements which are necessary in some cases now to get the correct value.
In addition, a third benefit is that you couldn't get stuck in a loop.

I see why HyperCard had the complex buffered behavior, especially with
slower computers back then, and why there is a bit of Catch-22 involved. But
I think the direct polling would work fine for almost every case nowadays,
and I think that Catch-22 is mostly history. For example, let's take one of
the most common usages: say you want to do something after a control is
pressed and continue until the mouse is released.

With "repeat until the mouse is up", the action would continue until the
mouse was released, and even if the repeated action could take a visible
amount of time, it would still stop if the mouse was up at poll time. So if
the user had clicked up and down again quickly while the action was going
on, the action would still stop.

If the user had let up quickly and then held the mouse down again, it would
usually still be the correct behavior. The user would see and understand
what was going on even if the second click was outside the control or
intended area, and realize that he should let go.

Now, that's the worst case scenario, and could be avoided either by extra
polling during such lengthy actions, or by ensuring shorter actions. I think
it's unlikely on the typical speedy computer of today (or even five or so
years ago) that this will be a big consideration. At least I can speak for
myself: I would have no problems with it.

When designing for older computers, or the other cases where direct polling
could cause problems (I suspect these cases would be pretty rare), any
number of methods to overcome the problem could be used, such as additional
polling.

It's hard to come up with the best examples right off hand, but hopefully
you see what I'm getting at. Do you see how direct polling, or some sort of
simplification of the current behavior, would be very effective for most
situations? And how tweaking for the other occasional situation would still
be much easier than having a bunch of different handlers that have to share
variables and keep each other informed of what they're trying to do, and
goodness-knows-what? I admit, some tasks are indeed best done with the
separate event handlers, but the objective observer will have to admit that
many, many tasks are much more straightforward using the polling functions.

And that's why we have hammers to pound nails, although with practice you
might be able to drive nails with another tool or with a rock or even your
bare hands or your forehead. If I picked up on Scott's messages correctly (I
don't want to put words in his mouth but) it seemed like he was willing to
consider reworking the functions and keeping them in a more logical and
simplified form if people could indicate whether changing the behavior would
be acceptable for them, and if so, how should it behave.

Dropping these functions would be silly when all we have to do is just agree
on an acceptable behavior. I'm not working on alternatives for them in my
own projects. I just don't want to script without these functions, period. I
can't say I would stop using Revolution without them, because I have a lot
tied up in Revolution and I like almost everything about it. Having found
the perfect cross-platform scripting environment, I want to keep using it.

But short of that, I can say that I would wholeheartedly hate scripting
without those polling functions. I would resent having to use other methods
in situations where the polling function would have been the most
straightforward solution. I would hate the whole business. This shouldn't be
a situation that we have to face, because those functions shouldn't be
deprecated.

Scott and team, please hang onto these functions and alter the behavior so
that it is easier for you to support while meeting the needs of those who do
express their needs. Consider the people who do depend on the functions and
care about them enough to tell you the behavior they want to see, and if
some other people wouldn't mind losing the functions altogether, then a
small behavior change shouldn't hurt them in a function they don't depend on
heavily and wouldn't mind moving away from.

As far as I know, all popular general-use languages like the BASICs and
LOGOs have these types of polling functions. They part of scripting and part
of other languages too. Why on earth should MetaCard and Revolution do
without them? They make sense for the situations where they are most often
used, they are more readable and much more convenient for many tasks, they
really help people who like to use them and they certainly don't hurt anyone
that choose not to.

As for the considerations of being advanced-OS-friendly, which is a slightly
different angle on the issue, I see the point, but it's a matter of what you
are making and for whom. It's not relevant for me at this time, but
continued existence and support of these polling functions certainly is.

So, I can see where the problems came from with supporting the complexities
of the old behaviors and still running into complaints on them, but I can't
see any reason why a modified, simpler implementation couldn't solve all
those problems as long as people indicate what would be acceptable for them.
And I can't see dumping these functions because of the conflict--any
implementation would be better than none! I think direct polling, or direct
polling with a few tweaks, would solve the problem for everyone.

Thanks,

Curry Kenworthy