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
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.
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...
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.
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
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.
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?
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?
Dear Tk Team,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:
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
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.
On Wednesday, 25 August 2021 at 12:50:18 UTC+1, Harald Oehlmann wrote: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.
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 34:15:51 |
Calls: | 6,449 |
Calls today: | 1 |
Files: | 12,052 |
Messages: | 5,255,071 |