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?
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 **************************
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.
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.
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.
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.
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?
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.
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 916 |
Nodes: | 10 (1 / 9) |
Uptime: | 50:44:58 |
Calls: | 12,172 |
Calls today: | 2 |
Files: | 186,522 |
Messages: | 2,234,730 |