That's an eye catching topic title, isn't it?
Everything works except that I can't scroll the monster. I can see
the first half a dozen sets of boxes and can't reach the others.
So I tried a canvas. But it won't scroll either! That's weird. I should
be able to scroll a canvas.
What approach do you recommend in my case?
Additional problem: I can only have so many child text widgets, more or
less 4,200. With 5,000 the application won't load anymore, it crashes
after trying for a few seconds. I wonder if that can be fixed too.
Alright! It's a subtitle editor. One box for subtitle number, another one
for subtitle timestamp, then another one for the original subtitle, one
for the translated subtitle and another one for certain indications
(e.g. character count, errors etc.) A feature length movie can have 1,200 subtitles, that's 6,000 boxes.
That's an eye catching topic title, isn't it?
I've created a monster.
I had this big text widget that didn't suit my purposes.
So I left it where it was and inserted hundreds of text boxes as children
of that one text widget. It looks like a big table or grid.
I know what you're thinking. You're thinking why in the red hot blazes of this blue round world would anybody do that???
Well, they absolutely need to be separate from all others individually.
They even have their own number IDs each. It's a requirement. And I need
many text editing features including colors.
Probably the OP is on Windows, where you have additional constraints of**************************
how many graphics handles (the exact term just won't come to mind) you
can create.
**************************
Luc <[email protected]d> wrote:
That's an eye catching topic title, isn't it?
Yes, indeed, and unnecessary. :)
Everything works except that I can't scroll the monster. I can see
the first half a dozen sets of boxes and can't reach the others.
Again, demo code or else it is not happening.
This scrolls 6000 text widgets just fine:
#!/usr/bin/wish
text .t -yscrollcommand [list .vsb set]
scrollbar .vsb -orient vertical -command [list .t yview]
grid .t .vsb -sticky news
for {set i 0} {$i < 6000} {incr i} {
text .st$i -width 40 -height 5
.t window create end -window .st$i
.t insert end \n
}
So there must be something else interfering.
So I tried a canvas. But it won't scroll either! That's weird. I should
be able to scroll a canvas.
For a canvas you have to explicitly tell it the area to scroll,
otherwise it won't scroll at all. Read the manpage carefully.
What approach do you recommend in my case?
Not creating 6000 text widgets.
Additional problem: I can only have so many child text widgets, more or less 4,200. With 5,000 the application won't load anymore, it crashes
after trying for a few seconds. I wonder if that can be fixed too.
My code above creates 6000, no crash.
Changing 6000 to 60000 takes a few minutes to run, and consumes 437MB
of memory (according to top). But once up, scrolling to the bottom
happens just fine.
Alright! It's a subtitle editor. One box for subtitle number, another
one for subtitle timestamp, then another one for the original subtitle,
one for the translated subtitle and another one for certain indications (e.g. character count, errors etc.) A feature length movie can have
1,200 subtitles, that's 6,000 boxes.
No, that's 6,000 datapoints, which does not need to equate to 6,000
boxes.
You need enough boxes to fit on screen without scrolling, and you move
the 6,000 datapoints through the smaller set of boxes that are
on screen. The screen boxes let you look through a screen sized
peephole at the 6,000 datapoints, and "scrolling" moves the data
through the peephole.
https://wiki.tcl-lang.org/page/Virtual%20Scrolling
This doesn't work:
--------------------
package require Tk
toplevel .scroller -background "#c0c0c0"
text .scroller.t -yscrollcommand [list .scroller.vsb set]
scrollbar .scroller.vsb -orient vertical -command [list .scroller.t yview] grid .scroller.t .scroller.vsb -sticky news
focus .scroller.t
for {set i 1} {$i <= 600} {incr i} {
frame .st$i -width 40 -height 5
.scroller.t window create end -window .st$i
text .st$i.text$i -height 2 -width 50
pack .st$i.text$i
.scroller.t insert end \n
.st$i.text$i insert end "this is $i"
}
--------------------
Why?
Luc <[email protected]d> wrote:
This doesn't work:
--------------------
package require Tk
toplevel .scroller -background "#c0c0c0"
text .scroller.t -yscrollcommand [list .scroller.vsb set]
scrollbar .scroller.vsb -orient vertical -command [list .scroller.t
yview] grid .scroller.t .scroller.vsb -sticky news
focus .scroller.t
for {set i 1} {$i <= 600} {incr i} {
frame .st$i -width 40 -height 5
.scroller.t window create end -window .st$i
text .st$i.text$i -height 2 -width 50
pack .st$i.text$i
.scroller.t insert end \n
.st$i.text$i insert end "this is $i"
}
--------------------
Why?
Read the text manpage, particularly the section entitled "EMBEDDED
WINDOWS". Pay *very close attention* to the parenthetical clause at
the end of the first paragraph of that section.
On Sun, 29 Jan 2023 13:47:28 -0000 (UTC), Rich wrote:
Luc <[email protected]d> wrote:
This doesn't work:
--------------------
package require Tk
toplevel .scroller -background "#c0c0c0"
text .scroller.t -yscrollcommand [list .scroller.vsb set]
scrollbar .scroller.vsb -orient vertical -command [list .scroller.t
yview] grid .scroller.t .scroller.vsb -sticky news
focus .scroller.t
for {set i 1} {$i <= 600} {incr i} {
frame .st$i -width 40 -height 5
.scroller.t window create end -window .st$i
text .st$i.text$i -height 2 -width 50
pack .st$i.text$i
.scroller.t insert end \n
.st$i.text$i insert end "this is $i"
}
--------------------
Why?
Read the text manpage, particularly the section entitled "EMBEDDED
WINDOWS". Pay *very close attention* to the parenthetical clause at
the end of the first paragraph of that section.
Yes, I read that before I asked, and I still don't see the point.
It says:
(subject to the usual rules for geometry management, which require the
text window to be the parent of the embedded window or a descendant of
its parent).
I made the big parent .scroller then made the text widget .scroller.t
then made its big series of numbered children:
.scroller.t window create end -window .st$i
Yet, the error says:
can't embed .st1 in .scroller.t
while executing
".scroller.t window create end -window .st$i"
But .scroller.t is the parent of .st$i. So what is going on? I'm stumped.
Yet, the error says:
can't embed .st1 in .scroller.t
while executing
".scroller.t window create end -window .st$i"
But .scroller.t is the parent of .st$i. So what is going on? I'm stumped.
No, . is the parent of the .st$i windows.
I think you misunderstand what "parent"/"child" is in Tk. It is defined
by the name. A child of .scroller.t would be named, e.g., .scroller.t.st1
In your first example, you used a "sibling" of the text window, not a
child as well.
Christian
**************************
Luc <[email protected]d> wrote:
That's an eye catching topic title, isn't it?
Yes, indeed, and unnecessary. :)
Everything works except that I can't scroll the monster. I can see
the first half a dozen sets of boxes and can't reach the others.
Again, demo code or else it is not happening.
This scrolls 6000 text widgets just fine:
#!/usr/bin/wish
text .t -yscrollcommand [list .vsb set]
scrollbar .vsb -orient vertical -command [list .t yview]
grid .t .vsb -sticky news
for {set i 0} {$i < 6000} {incr i} {
text .st$i -width 40 -height 5
.t window create end -window .st$i
.t insert end \n
}
So there must be something else interfering.
So I tried a canvas. But it won't scroll either! That's weird. I should
be able to scroll a canvas.
For a canvas you have to explicitly tell it the area to scroll,
otherwise it won't scroll at all. Read the manpage carefully.
What approach do you recommend in my case?
Not creating 6000 text widgets.
Additional problem: I can only have so many child text widgets, more or less 4,200. With 5,000 the application won't load anymore, it crashes
after trying for a few seconds. I wonder if that can be fixed too.
My code above creates 6000, no crash.
Changing 6000 to 60000 takes a few minutes to run, and consumes 437MB
of memory (according to top). But once up, scrolling to the bottom
happens just fine.
Alright! It's a subtitle editor. One box for subtitle number, another
one for subtitle timestamp, then another one for the original subtitle,
one for the translated subtitle and another one for certain indications (e.g. character count, errors etc.) A feature length movie can have
1,200 subtitles, that's 6,000 boxes.
No, that's 6,000 datapoints, which does not need to equate to 6,000
boxes.
You need enough boxes to fit on screen without scrolling, and you move
the 6,000 datapoints through the smaller set of boxes that are
on screen. The screen boxes let you look through a screen sized
peephole at the 6,000 datapoints, and "scrolling" moves the data
through the peephole.
https://wiki.tcl-lang.org/page/Virtual%20Scrolling
Hi, Rich. About the code that you shared, quoted below,
do you have idea of how I can jump to any specific box
and make it immediately visible?
I need something like the [see] command.
All the boxes are children of a text widget, but that
text widget doesn't have any lines of text so I can't
really use the [see] command here.
Less important: how do I scroll that big collection of boxes without
using the mouse? I mean, jump from one box to the other and scroll accordingly?
Luc <[email protected]d> wrote:
Hi, Rich. About the code that you shared, quoted below,
do you have idea of how I can jump to any specific box
and make it immediately visible?
I need something like the [see] command.
The parent text widget holding all the embedded windows has a [see]
command. Use that.
All the boxes are children of a text widget, but that
text widget doesn't have any lines of text so I can't
really use the [see] command here.
Ah, study the code more closely. You will see that each embedded
window is one line in the text widget.
Also study the text widget man page, specifically the index option "pathName".
Less important: how do I scroll that big collection of boxes without
using the mouse? I mean, jump from one box to the other and scroll accordingly?
If keyboard scrolling is not already working using the standard Tk
bindings, then you'll need to setup your own custom bindings on
specific keys actuations to effect scrolling.
Do keep in mind that when keyboard focus is inside an embedded window
that this fact may cause the parent to not 'hear' some of the relevant keyboard events.
Also, please don't put your quoted message underneath a line containing
just two hyphens and a space, that denotes a "signature" on Usenet, and standard clients omit quoting the signature when replying.
**************************
Yeah, well, now I see you put a line break after every box.
I didn't. That's why I couldn't move around comfortably.
I guess that will change the game in scrolling too. I'm surprised it
even scrolled at all though only with the mouse.
Ah, you ended up with a huge single long line with 'word wrap' giving
you the vertical aligment. That's why you could not scroll. Doing
that causes the text to consume a huge amount of CPU time computing
word wrapping.
But, as you'll likely more often than not have keyboard focus inside
the inner widgets, you will likely have to build your own keyboard
scrolling bindings.
An alternate would be for you to rethink your approach, back up, and
use something like tablelist (https://www.nemethi.de/) which has much
of what you'll need to recreate yourself already written and ready to
use (including editing within cells).
That's an eye catching topic title, isn't it?
I've created a monster.
I had this big text widget that didn't suit my purposes.
So I left it where it was and inserted hundreds of text boxes as children
of that one text widget. It looks like a big table or grid.
I know what you're thinking. You're thinking why in the red hot blazes of this blue round world would anybody do that???
Well, they absolutely need to be separate from all others individually.
They even have their own number IDs each. It's a requirement. And I need
many text editing features including colors.
Everything works except that I can't scroll the monster. I can see the
first half a dozen sets of boxes and can't reach the others.
So I removed the big underlying text widget and used a frame instead.
Silly me, the scroll command won't even work with a frame. Back to the drawing board.
So I tried a canvas. But it won't scroll either! That's weird. I should
be able to scroll a canvas.
What approach do you recommend in my case?
Additional problem: I can only have so many child text widgets, more or
less 4,200. With 5,000 the application won't load anymore, it crashes
after trying for a few seconds. I wonder if that can be fixed too.
Alright! It's a subtitle editor. One box for subtitle number, another one
for subtitle timestamp, then another one for the original subtitle, one
for the translated subtitle and another one for certain indications
(e.g. character count, errors etc.) A feature length movie can have 1,200 subtitles, that's 6,000 boxes.
--
Luc
What's the point of creating such a high count of text widgets when you
can only use one at the time?
I would just create a single one, either permanent or on-demand, and map
or unmap it as desired on the different areas of text.
Using a combination of tags and bindings it's easy to do what you want.
On Mon, 6 Feb 2023 11:20:03 -0300, Emiliano Gavilan wrote:
What's the point of creating such a high count of text widgets when you
can only use one at the time?
I would just create a single one, either permanent or on-demand, and map
or unmap it as desired on the different areas of text.
Using a combination of tags and bindings it's easy to do what you want.
You are probably right, but I was in a hurry and went with the first
design that occurred to me. Perfect or not, it's working very well.
I'm having two very productive weeks with it. I'm surprised I could
get it to work so well in so little time. I may redesign it in the
future. There are quite a few rough edges yet though so I'll
probably work on those first.
design that occurred to me. Perfect or not, it's working very well. I'm having two very productive weeks with it. I'm surprised I could get it
On 2/7/2023 5:09 AM, Luc wrote:
design that occurred to me. Perfect or not, it's working very well. I'm having two very productive weeks with it. I'm surprised I could get it
That is interesting. After all, this is what it all comes down to at the
end: whether something is useful to you or not. is this some kind of a personal productivity app?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 02:22:14 |
| Calls: | 12,098 |
| Calls today: | 6 |
| Files: | 15,003 |
| Messages: | 6,517,869 |