Am 25.08.21 um 15:04 schrieb Harald Oehlmann:

Am 25.08.2021 um 14:48 schrieb Christian Gollwitzer:

Am 25.08.21 um 13:50 schrieb Harald Oehlmann:

Dear Tk Team,

as Displays have more and more pixels, the following Tk limitation is
gaining priority for me:

When a frame grows over 32767 pixels, strange things happen:
- only the first 32767 pixels are displayed, while the frame size is
reported as larger
- other widgets like buttons are painted at position 0,0 (upper left
screen corner) or are not painted at all.

My practical application is an automated property window which has a
ttk::frame with the following parents:
toplevel->ttk::frame->ttk::notebook->ttk::notebook->scrollutil::scrollarea->scrollutil::scrollableframe


The frame items are created in a loop and may exceed 32767 pixels
quite quickly. In a font height of 19 Pixels, this limit is reached
with 1000 config items. But we reach today easily font heights of 30
pixels which leads to 700 items etc.

For 700 items, maybe you should try an editable tablelist instead? I
guess the underlying text widget (as well as the canvas, yet another
possibility) won't have the same limitations. I can easily create
tables with many 1000s of rows.

     Christian

Christian,

thank you for the hint.

Yes, there are a couple of alternatives. In the past, I used tktable.
The presentation of the configuration items is quite variable, sometimes
a list of radio buttons, sometimes entry widgets, sometimes comboboxes. Tablelist may be configured to support all this using subwidgets.
But the current solution of gridded items is easier.

The aim of my message was also to get other opinions on this
limitations. IMHO we will get soon screens of sizes where this is
getting really annoying.

I should also start to create sample scripts and to test where it really happens. Eventually, the problems are not there when using 64 bit
Windows. I still use 32 bit. And we may check other platforms.

So much work to do, so nice weather, so nice lakes to go swimming in
Berlin ;-).

Thank you,
Harald

As pointed out by Christian W., there is very probably no chance to
exceed the maximum short integer value of 32767. And, as mentioned by Christian G., using a tablelist widget with editable cells could be a
working alternative to creating a large number of widgets. In addition,
this would consume by far less memory and CPU.

You could use a tablelist widget with two columns, where the first
column would contain the property names and the second one (with
editable cells) the corresponding values. Please recall that the
-editwindow option is available not only at column, but also at cell
level. Based on my experience with property editors, the edit window
types supported by Tablelist should be sufficient for editing any type
of properties. For example, instead of a list of radiobuttons you could
use a ttk::combobox (no need for a subwidget). For editing strings, you
can choose between (ttk::)entry, text, and ctext widgets, for numerical
values you can use a ttk::spinbox widget, for booleans a
(ttk::)checkbutton widget, etc. In addition, 6 mentry widget types as
edit windows are supported out of the box, along with several widgets
from the BWidget and Iwidgets packages.

--
Csaba Nemethi https://www.nemethi.de mailto:csaba.nemethi@t-online.de

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

Am 25.08.2021 um 16:29 schrieb Christian Werner:

see the various Xlib drawing functions: they all have coordinates expressed as short integers.
So, no, one can't express pixel coords greater than 0x7FFFF.

I meant 0x7FFF, of course.

Dear Chrstian,

thank you for the information. That is quite bad news. It is a different
task, to:
- support a display with more than 32767 pixels in width or height
- support a frame, which is only partly shown with a height larger than
32767

In addition, there is no error message. At least on MS-Windows, Tk
accepts it silently, but has issues to paint.
A ttk::frame may have more than 32767 pixels in height, but we get huge
drawing issues. If there is a larger frame somewhere, Tk fails to paints
other widgets (3 levels up in Window hirarchy).

It should wether fail with an error or really support it.
I can understand that it smells like work...

Example scripts are needed to show the issues.

Thank you all,
Harald

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

On 8/25/21 11:23 AM, Harald Oehlmann wrote:

Am 25.08.2021 um 16:29 schrieb Christian Werner:

see the various Xlib drawing functions: they all have coordinates
expressed as short integers.
So, no, one can't express pixel coords greater than 0x7FFFF.

I meant 0x7FFF, of course.

Dear Chrstian,

thank you for the information. That is quite bad news. It is a different task, to:
- support a display with more than 32767 pixels in width or height
- support a frame, which is only partly shown with a height larger than
32767

In addition, there is no error message. At least on MS-Windows, Tk
accepts it silently, but has issues to paint.
A ttk::frame may have more than 32767 pixels in height, but we get huge drawing issues. If there is a larger frame somewhere, Tk fails to paints other widgets (3 levels up in Window hirarchy).

It should wether fail with an error or really support it.
I can understand that it smells like work...

It may not be TK that is silently failing, it may be XLib (or the
Windows XLib translation layer),

It sounds kind of like an integer overflow error is either being
disabled at compile time or trapped and not reported.

--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald.Lester@kng-consulting.net | +----------------------------------------------------------------------+

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

Am 25.08.2021 um 18:05 schrieb nemethi:

Am 25.08.21 um 15:04 schrieb Harald Oehlmann:

Am 25.08.2021 um 14:48 schrieb Christian Gollwitzer:

Am 25.08.21 um 13:50 schrieb Harald Oehlmann:

Dear Tk Team,

as Displays have more and more pixels, the following Tk limitation
is gaining priority for me:

When a frame grows over 32767 pixels, strange things happen:
- only the first 32767 pixels are displayed, while the frame size is
reported as larger
- other widgets like buttons are painted at position 0,0 (upper left
screen corner) or are not painted at all.

My practical application is an automated property window which has a
ttk::frame with the following parents:
toplevel->ttk::frame->ttk::notebook->ttk::notebook->scrollutil::scrollarea->scrollutil::scrollableframe


The frame items are created in a loop and may exceed 32767 pixels
quite quickly. In a font height of 19 Pixels, this limit is reached
with 1000 config items. But we reach today easily font heights of 30
pixels which leads to 700 items etc.

For 700 items, maybe you should try an editable tablelist instead? I
guess the underlying text widget (as well as the canvas, yet another
possibility) won't have the same limitations. I can easily create
tables with many 1000s of rows.

     Christian

Christian,

thank you for the hint.

Yes, there are a couple of alternatives. In the past, I used tktable.
The presentation of the configuration items is quite variable,
sometimes a list of radio buttons, sometimes entry widgets, sometimes
comboboxes.
Tablelist may be configured to support all this using subwidgets.
But the current solution of gridded items is easier.

The aim of my message was also to get other opinions on this
limitations. IMHO we will get soon screens of sizes where this is
getting really annoying.

I should also start to create sample scripts and to test where it
really happens. Eventually, the problems are not there when using 64
bit Windows. I still use 32 bit. And we may check other platforms.

So much work to do, so nice weather, so nice lakes to go swimming in
Berlin ;-).

Thank you,
Harald

As pointed out by Christian W., there is very probably no chance to
exceed the maximum short integer value of 32767.  And, as mentioned by Christian G., using a tablelist widget with editable cells could be a
working alternative to creating a large number of widgets.  In addition, this would consume by far less memory and CPU.

You could use a tablelist widget with two columns, where the first
column would contain the property names and the second one (with
editable cells) the corresponding values.  Please recall that the -editwindow option is available not only at column, but also at cell
level.  Based on my experience with property editors, the edit window
types supported by Tablelist should be sufficient for editing any type
of properties.  For example, instead of a list of radiobuttons you could
use a ttk::combobox (no need for a subwidget).  For editing strings, you
can choose between (ttk::)entry, text, and ctext widgets, for numerical values you can use a ttk::spinbox widget, for booleans a
(ttk::)checkbutton widget, etc.  In addition, 6 mentry widget types as
edit windows are supported out of the box, along with several widgets
from the BWidget and Iwidgets packages.

ear Csaba,

thank you, I appreciate. Great Tablelist is so universal.

Thank you,
Harald

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

At Wed, 25 Aug 2021 15:04:09 +0200 Harald Oehlmann <wortkarg2@yahoo.de> wrote:

Am 25.08.2021 um 14:48 schrieb Christian Gollwitzer:

Am 25.08.21 um 13:50 schrieb Harald Oehlmann:

Dear Tk Team,

as Displays have more and more pixels, the following Tk limitation is
gaining priority for me:

When a frame grows over 32767 pixels, strange things happen:
- only the first 32767 pixels are displayed, while the frame size is
reported as larger
- other widgets like buttons are painted at position 0,0 (upper left
screen corner) or are not painted at all.

My practical application is an automated property window which has a
ttk::frame with the following parents:
toplevel->ttk::frame->ttk::notebook->ttk::notebook->scrollutil::scrollarea->scrollutil::scrollableframe


The frame items are created in a loop and may exceed 32767 pixels
quite quickly. In a font height of 19 Pixels, this limit is reached
with 1000 config items. But we reach today easily font heights of 30
pixels which leads to 700 items etc.

For 700 items, maybe you should try an editable tablelist instead? I
guess the underlying text widget (as well as the canvas, yet another possibility) won't have the same limitations. I can easily create tables with many 1000s of rows.

    Christian

Christian,

thank you for the hint.

Yes, there are a couple of alternatives. In the past, I used tktable.
The presentation of the configuration items is quite variable, sometimes
a list of radio buttons, sometimes entry widgets, sometimes comboboxes. Tablelist may be configured to support all this using subwidgets.
But the current solution of gridded items is easier.

The aim of my message was also to get other opinions on this
limitations. IMHO we will get soon screens of sizes where this is
getting really annoying.

I should also start to create sample scripts and to test where it really happens. Eventually, the problems are not there when using 64 bit
Windows. I still use 32 bit. And we may check other platforms.

*I* have a piece of software that potientionally creates large numbers of widgets (using things like tabbed widgets, with possibly many tabs). The program works just fine on all of my Linux machines, but the MS-Windows
version crashes on a user's MS-Windows machine. *I* don't have a machine running MS-Windows, so I am not able to debug it. I cross build my code for Win32, so it is possible it is a Win32 problem, but I don't really know. I don't really have any way to realisticly support MS-Windows, since I have no machines, real or virtual, running any version of MS-Windows.

Tk under MS-Windows uses "native" MS-Windows wigets. I suspect that there
might be limitations in the MS-Windows widget library/toolset (maybe Win32 specific limitations). I don't know if these limitations are inhierent in MS-Windows or are bugs in the MS-Windows Tk code.

So much work to do, so nice weather, so nice lakes to go swimming in
Berlin ;-).

Thank you,
Harald

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

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

Harald Oehlmann <wortkarg2@yahoo.de> wrote:

The frame items are created in a loop and may exceed 32767 pixels quite quickly. In a font height of 19 Pixels, this limit is reached with 1000 config items. But we reach today easily font heights of 30 pixels which
leads to 700 items etc.

The question that comes to my mind is rather off topic, but: Which user on earth should review and click, resp. fill in 700 items?


--
EL

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

On 8/25/21 12:45 PM, EL wrote:

Harald Oehlmann <wortkarg2@yahoo.de> wrote:

The frame items are created in a loop and may exceed 32767 pixels quite
quickly. In a font height of 19 Pixels, this limit is reached with 1000
config items. But we reach today easily font heights of 30 pixels which
leads to 700 items etc.

The question that comes to my mind is rather off topic, but: Which user on earth should review and click, resp. fill in 700 items?

It is likely an app created for a modernized version of one of the
circles of Dante's Infernal.

--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald.Lester@kng-consulting.net | +----------------------------------------------------------------------+

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

Am 25.08.2021 um 19:45 schrieb EL:

Harald Oehlmann <wortkarg2@yahoo.de> wrote:

The frame items are created in a loop and may exceed 32767 pixels quite
quickly. In a font height of 19 Pixels, this limit is reached with 1000
config items. But we reach today easily font heights of 30 pixels which
leads to 700 items etc.

The question that comes to my mind is rather off topic, but: Which user on earth should review and click, resp. fill in 700 items?

Thank you. I was sure, this question will arise.
There is a raw view which shows all parameters.
Normally, the user controls it by Wizards, which only show a part.
But the "view all" is possible and has the given issues.

Thank you,
Harald

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

* Robert Heller <heller@deepsoft.com>
| Tk under MS-Windows uses "native" MS-Windows wigets. I suspect that there
| might be limitations in the MS-Windows widget library/toolset (maybe Win32
| specific limitations). I don't know if these limitations are inhierent in
| MS-Windows or are bugs in the MS-Windows Tk code.

On Windows, the number of graphical handles is limited:

https://docs.microsoft.com/en-us/windows/win32/sysinfo/gdi-objects

We got bitten by this when a large number of icons was created (although
they were not all shown at the same time). Effects are 'black' windows
in the wrong position, and eventually crash of the application. So this
might be what's happening at your Windows users' side.

R'

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

On Wednesday, August 25, 2021 at 6:50:18 AM UTC-5, Harald Oehlmann wrote:

Dear Tk Team,

as Displays have more and more pixels, the following Tk limitation is
gaining priority for me:

When a frame grows over 32767 pixels, strange things happen:
- only the first 32767 pixels are displayed, while the frame size is
reported as larger
- other widgets like buttons are painted at position 0,0 (upper left
screen corner) or are not painted at all.

My practical application is an automated property window which has a ttk::frame with the following parents: toplevel->ttk::frame->ttk::notebook->ttk::notebook->scrollutil::scrollarea->scrollutil::scrollableframe

The frame items are created in a loop and may exceed 32767 pixels quite quickly. In a font height of 19 Pixels, this limit is reached with 1000 config items. But we reach today easily font heights of 30 pixels which
leads to 700 items etc.

Are there any comments or thinking on this issue?

This happens on MS-Windows with AWDark and native theme.

I suppose, we also hit some old MS-Windows limitations, where for
example su bwidget coordinates were limited to 32767. I remember this on Windows 95.

Thank you all,
Harald

Common technique is to create a "virtual window" and update the view in the constrained viewport thereby reducing the use of limited resources. Depending on what you want to display you can either:
1) create a limited number of widgets where each widget can represent any data item it might encounter and as you scroll change the data in each widget.
2) or as you scroll remove the destroy the items that are no longer visible and create new items to display .
an example of technique 1 follows: it creates 5 labels and a scrollbar to scan through a file listing. I added a <Configure> event handler to add /remove labels when the
frame is resized. The data in this case is a line from a directory listing and each line is displayed by a configuring an existing label. You can replace the label with more complex widget if your data is more complex.

#!/bin/sh
# the next line restarts using wish \
exec /opt/usr8.6.3/bin/tclsh8.6 "$0" ${1+"$@"}

foreach pkg { Tk } {
if { [ catch {package require $pkg } err ] != 0 } {
puts stderr "Unable to find package $pkg\n$err\n ... adjust your auto_path!";
}
}
proc scrollTo { w args } {
global currentpos d windowSize numItems
set pages $::windowSize
set units 1
lassign $args op amount type
if { $op eq "scroll" } {
set currentpos [ expr { $currentpos + ($amount * [ set $type ]) } ]
} else { # moveTo
set fraction $amount
set currentpos [ expr { round( $::numItems * $fraction) } ]
}
if { $currentpos < 0 } { set currentpos 0 }
if { $currentpos > [expr { $::numItems - $::windowSize} ] } {
set currentpos [expr { $::numItems - $::windowSize} ]
}
$w set [ expr { ( 1.0 * $currentpos ) / $::numItems } ] [ expr { 1.0 * ( $currentpos + $::windowSize) / $::numItems } ]
set j 0
for { set i $currentpos } { $i < [expr { $currentpos + $::windowSize} ] } { incr i } {
$::label($j) configure -textvariable ::d($i) -justify left
incr j
}
}
set windowSize 5 ; # number of labels to show in window
set tframe [ frame .tframe -width 400 ]
set lframe [ frame .tframe.lframe -bg blue ]
set vsb [ scrollbar .tframe.vsb -command { scrollTo .tframe.vsb } ]
for {set i 0 } { $i < $windowSize } { incr i } {
set label($i) [ label ${lframe}.label$i -text "" -bg white -fg black -justify left ]
pack $label($i) -side top -fill x -padx 5 -anchor w
}
# if contiaining frame expands or contract fill or remove labels as necessary bind .tframe.lframe <Configure> {
if { [ winfo geometry .tframe.lframe ] eq "1x1+0+0" } { return ; }
if { [ winfo geometry $::label(0) ] eq "1x1+0+0" } { return ; }
lassign [split [ winfo geometry .tframe.lframe ] "+x" ] frameWidth frameHeight xf yf
lassign [split [ winfo geometry $::label(0) ] "+x" ] labelWidth labelHeight xl yl
set currentitems [ array size ::label ]
set numlabelsNeeded [ expr { int( $frameHeight / $labelHeight ) } ]
set ::windowSize [ expr { int($numlabelsNeeded) } ]
if { $::windowSize > $currentitems } {
for { set i 0 } { $i < $::windowSize } { incr i } {
if { ![info exists ::label($i) ] } {
set ::label($i) [ label ${lframe}.label$i -text "" -bg white -fg black -justify left ]
pack $::label($i) -side top -fill x -padx 5 -anchor w
}
}
} elseif { $::windowSize < $currentitems } {
for { set i $::windowSize } { $i < $currentitems } { incr i } {
if { [info exists ::label($i) ] } {
destroy $::label($i)
array unset ::label $i
}
}
}
scrollTo $::vsb scroll 0 units
}
# generate some data and put into an array
set data [exec ls -la ]
array set d {}
set j 0
foreach item [split $data \n ] { set d($j) "$j:$item" ; incr j ;}
set numItems [array size d ]
$vsb set 0 [ expr { $windowSize / $numItems }]
# tracks top of data so d($currentpos) will be displayed by label(0)
set currentpos 0
# load data
scrollTo $vsb scroll 0 units
grid $vsb -row 0 -column 1 -sticky ns
grid $lframe -row 0 -column 0 -sticky nsew
grid columnconfigure $tframe 0 -weight 1
grid rowconfigure $tframe 0 -weight 1
pack .tframe -side top -fill both -expand 1 -anchor center

Carl

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

On Wednesday, 25 August 2021 at 12:50:18 UTC+1, Harald Oehlmann wrote:

When a frame grows over 32767 pixels, strange things happen:
- only the first 32767 pixels are displayed, while the frame size is reported as larger
- other widgets like buttons are painted at position 0,0 (upper left
screen corner) or are not painted at all.

It's a limitation of the use of 16-bit values in C structures for dimensions and window coordinates, and that's inherited from X11. I don't know exactly why they're going wrong in the way they do in your case, but that's absolutely the cause.

It's not fixable under X11 (the network protocol itself needs an update and that's caught up in the Wayland debacle), but could be fixed on Windows (and maybe macOS when not using X11) by changing the size of particularly the event-related structures. At
least in that case we actually own the structure definitions (we mostly don't under X11). It's definitely a binary-incompatible change; the structures concerned are allocated on places like stacks, and aren't versioned.

If it is just for display, you might be able to fake it with two (or more) borderless windows placed next to each other. That's probably rather difficult to get right for anything truly complicated.

Donal.

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

Am 28.09.2021 um 10:52 schrieb Donal K. Fellows:

On Wednesday, 25 August 2021 at 12:50:18 UTC+1, Harald Oehlmann wrote:

When a frame grows over 32767 pixels, strange things happen:
- only the first 32767 pixels are displayed, while the frame size is
reported as larger
- other widgets like buttons are painted at position 0,0 (upper left
screen corner) or are not painted at all.

It's a limitation of the use of 16-bit values in C structures for dimensions and window coordinates, and that's inherited from X11. I don't know exactly why they're going wrong in the way they do in your case, but that's absolutely the cause.

It's not fixable under X11 (the network protocol itself needs an update and that's caught up in the Wayland debacle), but could be fixed on Windows (and maybe macOS when not using X11) by changing the size of particularly the event-related structures.

At least in that case we actually own the structure definitions (we mostly don't under X11). It's definitely a binary-incompatible change; the structures concerned are allocated on places like stacks, and aren't versioned.

If it is just for display, you might be able to fake it with two (or more) borderless windows placed next to each other. That's probably rather difficult to get right for anything truly complicated.

Donal.

Dear Donal,

thank you for caring. You are amazing. You know every corner of TCL/Tk.
Thank you for the explanation.
Yes, with high DPI screens, the limits are getting closer. And on
Windows, the X coordinate goes over all screens. So, if you have 4
screens of 10000 Pixels width each, you have hit the limit physically.

I wanted to investigate further what the effects on Windows really are.
It is quite funny. On the canvas, the size and scrollbars can get over
the limit, but we get drawing issues.

It would be great to fix this at least on Windows.
I wonder why we have no tk 9.0 branch to make incompatible changes there.
You also mentioned the removal of all the code for limited pallets, as
at least rgb is standard today for displays and everything else.

Thank you again,
Harald

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