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
>>

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.

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
>>

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
>>

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?

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
>>

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?

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
>>

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]"
}