It has been pointed out to me that my description
of the problem that this patch actually fixes was
lacking.
The problem was with the text widget and the entry
widget. They did not place the insertion cursor
correctly after a click and drag operation over
some text. When you click and drag in a text
widget, the insertion cursor should be dragged
along with the mouse. When you release the
mouse, the insertion cursor should be where
the mouse was released. Other toolkits seem
to do this consistently, the behavior of Tk in
these situations defied explanation.
The "click and drag" test cases test cases added
by the patch demonstrate the broken behavior and
the corrected behavior after the patch has been
applied.
The other test cases just test out various kinds
of event generation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you clarify exactly how to reproduce the problem? Some work as done on this for 8.4, which is why the patch confused me. In 8.4a2, a simple click-and-drag in a text widget will cause the insertion cursor to follow the mouse correctly on Windows, and it is always at the end on Unix. The Windows behavior is consistent with other Windows apps. I assume the Unix behavior is Motif-like. In any case, it certainly seems intentionally different.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In real Motif, the insertion cursor follows the mouse when selecting by character or word (though in the latter case it is also always constrained to be at one end of the selection or the other, so where it is depends on how the word was selected, obviously.)
(I've just checked with a real Motif application.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jeff, please take a look at the event-click-drag-1.1
test supplied with the patch. It details what the
insert position should be after the mouse down
and mouse up events. You can also just run the
test to see what it does. The behavior after the patch
matches the behavior I was seeing in wordpad
on Windows and in xemacs and netscape on Linux.
I think netscape is a "real motif" application.
At any rate, the behavior on Unix was just plain
stupid. If you dragged to the right and then back
to the left over the spot where you clicked down,
the insertion cursor would not be moved. I could
find no other unix applications that matched this
behavior.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, that looks incorrect. Everything is just fine on Windows. Note that reading the end of the patch, into the uncommented test suites is not the recommended way of making people understand what the patch corrects.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jeff, could you elaborate on your "that looks incorrect"
comment? Are you saying the old behavior is incorrect
or that the patched behavior is wrong? I would like
to get this patch applied but I am not clear on what
the "next step" is. Would adding more comments to
the test case help?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
None
It has been pointed out to me that my description
of the problem that this patch actually fixes was
lacking.
The problem was with the text widget and the entry
widget. They did not place the insertion cursor
correctly after a click and drag operation over
some text. When you click and drag in a text
widget, the insertion cursor should be dragged
along with the mouse. When you release the
mouse, the insertion cursor should be where
the mouse was released. Other toolkits seem
to do this consistently, the behavior of Tk in
these situations defied explanation.
The "click and drag" test cases test cases added
by the patch demonstrate the broken behavior and
the corrected behavior after the patch has been
applied.
The other test cases just test out various kinds
of event generation.
Can you clarify exactly how to reproduce the problem? Some work as done on this for 8.4, which is why the patch confused me. In 8.4a2, a simple click-and-drag in a text widget will cause the insertion cursor to follow the mouse correctly on Windows, and it is always at the end on Unix. The Windows behavior is consistent with other Windows apps. I assume the Unix behavior is Motif-like. In any case, it certainly seems intentionally different.
In real Motif, the insertion cursor follows the mouse when selecting by character or word (though in the latter case it is also always constrained to be at one end of the selection or the other, so where it is depends on how the word was selected, obviously.)
(I've just checked with a real Motif application.)
Jeff, please take a look at the event-click-drag-1.1
test supplied with the patch. It details what the
insert position should be after the mouse down
and mouse up events. You can also just run the
test to see what it does. The behavior after the patch
matches the behavior I was seeing in wordpad
on Windows and in xemacs and netscape on Linux.
I think netscape is a "real motif" application.
At any rate, the behavior on Unix was just plain
stupid. If you dragged to the right and then back
to the left over the spot where you clicked down,
the insertion cursor would not be moved. I could
find no other unix applications that matched this
behavior.
OK, that looks incorrect. Everything is just fine on Windows. Note that reading the end of the patch, into the uncommented test suites is not the recommended way of making people understand what the patch corrects.
Logged In: YES
user_id=90858
Jeff, could you elaborate on your "that looks incorrect"
comment? Are you saying the old behavior is incorrect
or that the patched behavior is wrong? I would like
to get this patch applied but I am not clear on what
the "next step" is. Would adding more comments to
the test case help?
Logged In: YES
user_id=72656
I meant the old behavior is incorrect. Go ahead with your
patch.
Logged In: YES
user_id=72656
I meant the old behavior is incorrect. Go ahead with your
patch.
Logged In: YES
user_id=90858
Added on Thu Mar 29, 2001.