Will you please look at this screenshot:

https://0x0.st/HZVM.png

I am using ttk::notebook for the tabs. Apparently, my limit before
the tab names are truncated is 16 tabs.

Instead of bothering with scrolling or anything like that, I have
decided to just create a new row of tabs under that one. So I will
have 32 tabs. I for one think that having all tabs visible all the
time without the need for scrolling may be a better experience than
the one I'm used to having.

I am stil thinking about what to do if the user wants to have more
than 32 tabs. I already have some ideas.

Anyway, my screen has room for 16 tabs, but what about other people?
I only found 16 by trial and error, not with any kind of calculation.
For other people's screen, the application will have to do some math.

But how? Is it possible to determine how many tabs anyone's window
can have before the tab names get truncated?

Note: the tab names *will* vary.

--
Luc
>>

Luc <luc@sep.invalid> wrote:
>
> But how? Is it possible to determine how many tabs anyone's window
> can have before the tab names get truncated?

Maybe. I don't think the notebook provides any feedback for that
however.

But, as you will know the tab names, and know the font you are using,
you could use [font measure] on all of the tab names, sum up the total
pixel size of the set of names, and compare that sum with the pixel
width of the area in which you are positioning the notebook.

If the sum is larger, then truncation will occur. If the sum is much
smaller, no truncation would occur. You may have to do some
experiments for "sum close in size to view" to determine what value
indicates possible truncation with reasonable probability.

Am 07.05.2023 um 18:57 schrieb Luc:
> Will you please look at this screenshot:
>
> https://0x0.st/HZVM.png
>
> I am using ttk::notebook for the tabs. Apparently, my limit before
> the tab names are truncated is 16 tabs.
>
> Instead of bothering with scrolling or anything like that, I have
> decided to just create a new row of tabs under that one. So I will
> have 32 tabs. I for one think that having all tabs visible all the
> time without the need for scrolling may be a better experience than
> the one I'm used to having.
>
> I am stil thinking about what to do if the user wants to have more
> than 32 tabs. I already have some ideas.
>
> Anyway, my screen has room for 16 tabs, but what about other people?
> I only found 16 by trial and error, not with any kind of calculation.
> For other people's screen, the application will have to do some math.
>
> But how? Is it possible to determine how many tabs anyone's window
> can have before the tab names get truncated?
>
> Note: the tab names *will* vary.
>

The notebook is horrible in this respect. Csaba has created scrollutil
on it, where you get solutions for two issues:
- tabs scrolling arrows
- window resize on max of clients excluding the tabs.

As a side note, I want to remember Eric Boudalliers great BWidget, which
had all this 20 or 30 years ago. He recently gave a message on the core
list, so thanks to him on this way ;-).

Harald

On Sun, 7 May 2023 21:55:23 -0000 (UTC), Rich wrote:

> Luc <luc@sep.invalid> wrote:
> >
> > But how? Is it possible to determine how many tabs anyone's window
> > can have before the tab names get truncated?
>
> Maybe. I don't think the notebook provides any feedback for that
> however.
>
> But, as you will know the tab names, and know the font you are using,
> you could use [font measure] on all of the tab names, sum up the total
> pixel size of the set of names, and compare that sum with the pixel
> width of the area in which you are positioning the notebook.
>
> If the sum is larger, then truncation will occur. If the sum is much
> smaller, no truncation would occur. You may have to do some
> experiments for "sum close in size to view" to determine what value
> indicates possible truncation with reasonable probability.

For whatever it's worth, [font measure] didn't work at all. It kept
giving me very short pixel counts such as 118, 138 or 150 depending
on how much "padding" (additional spaces) I added to the calculation.
The correct number was 178.

What really worked (and gave me the 178) was [winfo geometry widget]
which gave me accurate numbers of pixels, a correct final sum and a
correct estimate of the maximum number of tabs per row.

Case closed. Thank you.

--
Luc
>>