• Roomy fonts won't fit in text widget

    From Luc@luc@sep.invalid to comp.lang.tcl on Fri Mar 1 17:17:07 2024
    From Newsgroup: comp.lang.tcl

    I have a series of small text widgets inside a large text widget.

    Each small text widget has exactly two lines.

    text $::t1.smallbox_$x -width 200 -height 2

    The problem is, the first line in those boxes is a certain font,
    likely a very boring one, and the second line can be any font at all
    including some pretty wild ones whose actual size is unpredictable in
    spite of nominal font size.

    So the first line fits fine but the second one very often doesn't.
    In my vain philosophy, I expected the text widget to "stretch" to make
    both lines fit because heck, I specified two lines of height, didn't I?
    The widget should give me as tall a line as necessary for the text to
    fit in. But that is not happening.

    Setting the small widgets height to 3 fixes it for some fonts, but
    not all. Setting it to 4 fixes some others, but one is still left.
    How much do I need then? How much will I need if I install some other
    "roomy" font? It's uncertain.

    What is the correct way of handling this?
    --
    Luc


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rich@rich@example.invalid to comp.lang.tcl on Fri Mar 1 22:46:39 2024
    From Newsgroup: comp.lang.tcl

    Luc <luc@sep.invalid> wrote:
    In my vain philosophy, I expected the text widget to "stretch" to
    make both lines fit because heck, I specified two lines of height,
    didn't I?

    Whether a widget "stretches" later, after it has been laid out on
    screen, is also dependent upon the options given to the geometry
    manager that is managing that widget on the screen.

    So your lack of 'resizing' might just be that the geometry manager is allocating enough for two lines, and then not allowing the widget to
    grow later when it needs more.

    A very minimal example showing how you are placing/packing/gridding it
    would prove helpful.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Luc@luc@sep.invalid to comp.lang.tcl on Fri Mar 1 19:51:31 2024
    From Newsgroup: comp.lang.tcl

    On Fri, 1 Mar 2024 22:46:39 -0000 (UTC), Rich wrote:

    Luc <luc@sep.invalid> wrote:
    In my vain philosophy, I expected the text widget to "stretch" to
    make both lines fit because heck, I specified two lines of height,
    didn't I?

    Whether a widget "stretches" later, after it has been laid out on
    screen, is also dependent upon the options given to the geometry
    manager that is managing that widget on the screen.

    So your lack of 'resizing' might just be that the geometry manager is >allocating enough for two lines, and then not allowing the widget to
    grow later when it needs more.

    A very minimal example showing how you are placing/packing/gridding it
    would prove helpful.

    **************************

    I'm using pack, which is not necessary with 'create' but I added it
    anyway, and it doesn't make any difference.


    pack $::t1.smallbox_$x -fill both -expand 1
    $::t1 window create end -window $::t1.smallbox_$x -stretch 1
    --
    Luc


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Luc@luc@sep.invalid to comp.lang.tcl on Fri Mar 1 20:43:09 2024
    From Newsgroup: comp.lang.tcl

    On Fri, 1 Mar 2024 19:51:31 -0300, Luc wrote:

    I'm using pack, which is not necessary with 'create' but I added it
    anyway, and it doesn't make any difference.


    pack $::t1.smallbox_$x -fill both -expand 1
    $::t1 window create end -window $::t1.smallbox_$x -stretch 1 **************************

    I've also tried inserting the content first and doing pack/create
    later. No worky.
    --
    Luc


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rich@rich@example.invalid to comp.lang.tcl on Sat Mar 2 05:42:48 2024
    From Newsgroup: comp.lang.tcl

    Luc <luc@sep.invalid> wrote:
    On Fri, 1 Mar 2024 19:51:31 -0300, Luc wrote:

    I'm using pack, which is not necessary with 'create' but I added it >>anyway, and it doesn't make any difference.


    pack $::t1.smallbox_$x -fill both -expand 1
    $::t1 window create end -window $::t1.smallbox_$x -stretch 1
    **************************

    I've also tried inserting the content first and doing pack/create
    later. No worky.

    I missed that you indeed said "text widget inside text widget" in your original post. In which case what I said about geometry managers does
    not apply.

    The "height" of a text widget is computed from the "line height" of the "-font" for the text widget, times the numerical value given for
    "-height". This is documented in the manpage:

    Command-Line Name:-height
    Database Name: height
    Database Class: Height

    Specifies the desired height for the window, in units of
    characters in the font given by the -font option. Must be at
    least one.

    Note the "units of characters in the font given by the -font option".

    So your solution here is to set the "-font" option for the embedded
    text widget to whichever of the two fonts is "taller" than the other
    font. Then you will get two lines of the taller font worth of room.
    Which will allow enough room for one line of a shorter font plus one
    line of the taller font. And, if the font assiged to "-font" is
    resized (or changed) the widget will change its size automatically.


    Now, next question. If you are inserting two text lines, why are you
    using an embedded text widget to do so, instead of simply inserting
    those two lines in the outer text widget, and tagging each with a
    different tag if you want them to be a different font than the outer
    widget's default?

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Luc@luc@sep.invalid to comp.lang.tcl on Sat Mar 2 03:21:37 2024
    From Newsgroup: comp.lang.tcl

    On Sat, 2 Mar 2024 05:42:48 -0000 (UTC), Rich wrote:

    I missed that you indeed said "text widget inside text widget" in your >original post. In which case what I said about geometry managers does
    not apply.

    The "height" of a text widget is computed from the "line height" of the >"-font" for the text widget, times the numerical value given for
    "-height". This is documented in the manpage:

    Command-Line Name:-height
    Database Name: height
    Database Class: Height

    Specifies the desired height for the window, in units of
    characters in the font given by the -font option. Must be at
    least one.

    Note the "units of characters in the font given by the -font option".


    I have determined without any doubt that it's the font size of the
    larger text widget which contains the small text widgets that defines
    the height of the small widgets' lines.

    But...


    So your solution here is to set the "-font" option for the embedded
    text widget to whichever of the two fonts is "taller" than the other
    font.

    Your solution is better. Just set -font to the largest font. Duh!
    I was doing something stupid, no -font definition at all and tags
    to define the font of each line.

    I followed your suggestion and yes, it works better.

    But there is a bizarre odd case here and there that doesn't quite
    look right and is hard to understand. I will have a hard time debugging
    that. I thought this was going to be a ridiculously easy project but
    it has turned out to be a little challenging after all.

    There is also an unwanted side effect: the width of the text boxes
    now varies and I really didn't want that. :-(



    Now, next question. If you are inserting two text lines, why are you
    using an embedded text widget to do so, instead of simply inserting
    those two lines in the outer text widget, and tagging each with a
    different tag if you want them to be a different font than the outer >widget's default?

    Control. I want to be very, very sure of what is selected. The idea
    is that the user will be able to select and remove unwanted boxes at
    leisure. I began with one big widget and keeping track of line numbers,
    but that was very unreliable. Unusable really. So now I'm going with individual "boxes" of text.
    --
    Luc


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rich@rich@example.invalid to comp.lang.tcl on Sat Mar 2 06:44:29 2024
    From Newsgroup: comp.lang.tcl

    Luc <luc@sep.invalid> wrote:
    On Sat, 2 Mar 2024 05:42:48 -0000 (UTC), Rich wrote:

    I missed that you indeed said "text widget inside text widget" in your >>original post. In which case what I said about geometry managers does
    not apply.

    The "height" of a text widget is computed from the "line height" of the >>"-font" for the text widget, times the numerical value given for >>"-height". This is documented in the manpage:

    Command-Line Name:-height
    Database Name: height
    Database Class: Height

    Specifies the desired height for the window, in units of
    characters in the font given by the -font option. Must be at
    least one.

    Note the "units of characters in the font given by the -font option".


    I have determined without any doubt that it's the font size of the
    larger text widget which contains the small text widgets that defines
    the height of the small widgets' lines.

    Nope, it is the font set as the "-font" for the small widgets.

    Now, if that happens to be the same font used by the container, it will
    seem as if the container's font is impacting the small ones as well.

    So your solution here is to set the "-font" option for the embedded
    text widget to whichever of the two fonts is "taller" than the other
    font.

    Your solution is better. Just set -font to the largest font. Duh!
    I was doing something stupid, no -font definition at all and tags
    to define the font of each line.

    There's *always* a font, even if you don't explicitly give one:

    $ rlwrap wish
    % text .t
    .t
    % .t cget -font
    TkFixedFont
    %

    I followed your suggestion and yes, it works better.

    There is also an unwanted side effect: the width of the text boxes
    now varies and I really didn't want that. :-(

    Font "-size" impacts both height *and* width of the font, which impacts
    the pixel width of the widget when it computes the font character width
    times the "-width" option value.

    Now, next question. If you are inserting two text lines, why are you >>using an embedded text widget to do so, instead of simply inserting
    those two lines in the outer text widget, and tagging each with a >>different tag if you want them to be a different font than the outer >>widget's default?

    Control. I want to be very, very sure of what is selected.

    The text widget already tells you, with perfect accuracy, what text is selected. And you not only get lines, but character position within
    line accuracy (of the start and end) for the text widget selection
    data.

    The idea is that the user will be able to select and remove unwanted
    boxes at leisure. I began with one big widget and keeping track of
    line numbers, but that was very unreliable.

    If you were trying to track it yourself, yes, that can be a pain. But
    why did the widget's built in tracking not work for you?

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Luc@luc@sep.invalid to comp.lang.tcl on Sat Mar 2 04:19:38 2024
    From Newsgroup: comp.lang.tcl

    On Sat, 2 Mar 2024 06:44:29 -0000 (UTC), Rich wrote:

    The text widget already tells you, with perfect accuracy, what text is >selected. And you not only get lines, but character position within
    line accuracy (of the start and end) for the text widget selection
    data.

    If you were trying to track it yourself, yes, that can be a pain. But
    why did the widget's built in tracking not work for you?


    Yes, of course. I didn't provide you with enough details so you don't
    really understand what is going on. My fault. Sorry.

    It's a series of pairs. I want to keep track of what pair is selected.
    And I can't afford to make the text widget editable. The user could
    delete one, two, God knows how many lines, and I would no longer know
    what is what and what is where.

    So I have to "disable" the text widget. The user thus cannot select
    any text in the most obvious way. And I can no longer keep track of
    cursor position because there is no cursor in a disabled text widget.
    I have to provide a very controlled method for selecting a pair.

    I am no longer using text widgets. Now the big text widget contains
    a series of labels. The whole thing looks and behaves a lot better
    now. I thought it would be cool to let the user edit the boxes at
    leisure, but I've decided that idea is not very viable. It may be
    possible, but too much work and not really necessary.

    This is going to be a pretty neat application.

    Useful too! Let's not forget that. :-)
    --
    Luc


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rich@rich@example.invalid to comp.lang.tcl on Sat Mar 2 16:28:53 2024
    From Newsgroup: comp.lang.tcl

    Luc <luc@sep.invalid> wrote:
    On Sat, 2 Mar 2024 06:44:29 -0000 (UTC), Rich wrote:

    The text widget already tells you, with perfect accuracy, what text is >>selected. And you not only get lines, but character position within
    line accuracy (of the start and end) for the text widget selection
    data.

    If you were trying to track it yourself, yes, that can be a pain. But
    why did the widget's built in tracking not work for you?

    Yes, of course. I didn't provide you with enough details so you don't
    really understand what is going on. My fault. Sorry.

    Yep, that's *very* true.

    It's a series of pairs. I want to keep track of what pair is selected.
    And I can't afford to make the text widget editable. The user could
    delete one, two, God knows how many lines, and I would no longer know
    what is what and what is where.

    So I have to "disable" the text widget. The user thus cannot select
    any text in the most obvious way. And I can no longer keep track of
    cursor position because there is no cursor in a disabled text widget.
    I have to provide a very controlled method for selecting a pair.

    So, create a 'read only' text widget instead. That way the user can't
    make changes to the text, but all the normal text widget features still
    work. See code example at end.

    I am no longer using text widgets. Now the big text widget contains
    a series of labels. The whole thing looks and behaves a lot better
    now. I thought it would be cool to let the user edit the boxes at
    leisure, but I've decided that idea is not very viable. It may be
    possible, but too much work and not really necessary.

    Using tags to mark pairs, you could even extend the example below to
    allow editing within a single pair by checking that the position being
    edited is within the range of a tag attched to a given pair that is
    meant to be editable at the moment.

    Quick code example of a read only text widget:

    #!/usr/bin/wish

    text .text

    .text insert end "Lorem ipsum dolor sit amet, consectetur\n"
    .text insert end "adipiscing elit, sed do eiusmod tempor\n"
    .text insert end "incididunt ut labore et dolore magna\n"
    .text insert end "aliqua. Ut enim ad minim veniam,\n"
    .text insert end "quis nostrud exercitation ullamco laboris\n"
    .text insert end "nisi ut aliquip ex ea commodo consequat.\n"
    .text insert end "Duis aute irure dolor in reprehenderit\n"
    .text insert end "in voluptate velit esse cillum dolore\n"
    .text insert end "eu fugiat nulla pariatur. Excepteur\n"
    .text insert end "sint occaecat cupidatat non proident,\n"
    .text insert end "sunt in culpa qui officia deserunt mollit\n"
    .text insert end "anim id est laborum."

    pack .text

    # now, rename the text widget to a new name

    rename .text .real-text-widget

    # and create a proc to 'watch' for 'change content' commands and
    # reject any attempts to change the contents

    proc .text {subcommand args} {
    switch -exact -- $subcommand {
    delete -
    insert -
    replace {
    # modification command - reject it
    puts stderr "Refusing to edit text widget contents"
    }
    default {
    # chain everything else to the real text widget
    .real-text-widget $subcommand {*}$args
    }
    }
    }

    # also bind to <<Selection>> to show changes in the selection

    bind .text <<Selection>> [list show-selection .text]

    proc show-selection {w} {
    puts stderr ".text selection is: [.text tag ranges sel]"
    }
    --- Synchronet 3.20a-Linux NewsLink 1.114