1. Forum
  2. Usenet
  3. COMP.LANG.TCL

  • Tk text widget cursor jumps to next line when clicking on the right (??

    From xol odho@21:1/5 to All on Mon Oct 3 16:09:28 2022
    Hello all ... learning some Tk here ...

    After playing around with Tk's lovely text megawidget, I've been
    annoyed by the "line jumping" behavior when you click on the empty
    area to the right of the text. Am I the only one that expects the
    cursor to stay on the last char of the line, instead of jumping to the
    first char of the next one? All editors I've used stay on the line
    when you click on the empty area on the right.

    For instance, try this in wish:

    pack [text .t] -expand yes -fill both
    .t insert end "hello\nthis is another line"

    Make sure there is plenty of empty area to the right of the first
    line. Now put the mouse pointer on the first line a little bit to the
    right of the "hello", and start clicking and moving the cursor to the
    right (click, move, click, etc). After the mouse pointer crosses the
    middle of the empty area, on click the insertion cursor jumps to the
    first char of the next line (before "this") instead of staying at the
    end of the line (i.e. to the right of the "o"). I didn't expect this
    behavior.

    I don't know whether this is the intended behavior, but anyway I found
    a little temporary fix for it, as follows.

    In Tk 8.6.12, look for the `tk::TextClosestGap` procedure in
    `text.tcl`, here it is (with minor reformatting):

    proc ::tk::TextClosestGap {w x y} {
    set pos [$w index @$x,$y]
    set bbox [$w bbox $pos]
    if {$bbox eq ""} {
    return $pos
    }
    if {($x - [lindex $bbox 0]) < ([lindex $bbox 2]/2)} {
    return $pos
    }
    $w index "$pos + 1 char"
    }

    That routine is directly invoked by tk::TextButton1 (on click) to set
    the insertion cursor. It seems the second `if` is trying to determine
    whether the click position ($x,$y) is horizontally on the left half of
    the bounding box for the char at position $pos (which is under the
    mouse pointer ($x,$y) according to `index`), and if so, $pos remains
    where it was, otherwise it jumps to the next char. But when the char
    at $pos is the last one on the line (newline), the bounding box
    returned by `bbox` has the full width of the empty area, so if you
    click in the right half of that area the insertion cursor will jump to
    the next char, which is on the following line (unless you are on the
    last line).

    For now I'm fixing it with this in place of the first `if`:

    if {$bbox eq "" || [$w compare $pos == "$pos lineend"]} {
    return $pos
    }

    So if the mouse click is on the empty area to the right, $pos is the
    index of the last char of that text line, and it will stay there. I'm
    not sure this is the right way to do it but it is working so far...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Francois Vogel@21:1/5 to All on Tue Oct 4 07:55:27 2022
    Le 04/10/2022 à 01:09, xol odho a écrit :
    After playing around with Tk's lovely text megawidget, I've been
    annoyed by the "line jumping" behavior when you click on the empty
    area to the right of the text.

    See:

    https://core.tcl-lang.org/tk/tktview?name=b461c70399

    This was a lengthy discussion and I never actually made my mind on
    changing the behavior or not, and if so, in what version of Tk (and what version of the text widget - legacy or revised).

    Opinions, final arguments and decisive remarks welcome.

    Regards,
    Francois

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luc@21:1/5 to Francois Vogel on Tue Oct 4 17:55:04 2022
    That's not a big deal, but I think the current behavior is wrong.
    There is no reason why a widget should take decisions for the user.
    If I click one line, whatever it is, the insertion point must be
    in that line, period. No surprises. Do you want the next line?
    Click the next line then.

    FWIW.

    --
    Luc

    **************************
    On Tue, 4 Oct 2022 07:55:27 +0200, Francois Vogel wrote:

    Le 04/10/2022 à 01:09, xol odho a écrit :
    After playing around with Tk's lovely text megawidget, I've been
    annoyed by the "line jumping" behavior when you click on the empty
    area to the right of the text.

    See:

    https://core.tcl-lang.org/tk/tktview?name=b461c70399

    This was a lengthy discussion and I never actually made my mind on
    changing the behavior or not, and if so, in what version of Tk (and
    what version of the text widget - legacy or revised).

    Opinions, final arguments and decisive remarks welcome.

    Regards,
    Francois


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From xol odho@21:1/5 to All on Tue Oct 4 16:32:58 2022
    Ok, I just read that Tk ticket page, I really had no idea this had
    been reported already. I feel the current behavior is quite
    unintuitive, it's one of the first quirks I noticed with the Tk text
    widget (which apart from some annoyances like this one, is quite
    impressive).

    Can't this be fixed in the Tk 8.6 series? Do any apps/users depend on
    this behavior? It seems to me like an unexpected secondary effect of
    the implementation, not an intended feature and so shouldn't be
    depended upon. But I'm a newcomer to Tk, so I really don't know.

    There are other things in Tk that cause me more concern though, like
    the "<KeyRelease>" semantics clearly broken on X11 (I reported a
    ticket already), or the Tk button getting stuck after spacebar pressed
    for a few seconds (I didn't file a ticket that one but I inquired
    about that on this list a few weeks ago).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)