Finding the embedding text widget for an embedded window

[Erik Leunissen]

L.S.

Text widgets may embed other windows.

Problem: given the name of an embedded window, is there a straight
forward method to determine the embedding text window?

I mean considerably less involved than searching for a window "W" that
matches all of the following conditions:

- is the parent of the embedded window or a descendant of its parent
(a rule stated in the man page for "text")
- returns "Text" for [winfo class $W]
- the name of the embedded window is an element of [$W window names]


Thanks in advance for any directions,
Erik Leunissen
--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

[Donal K. Fellows]

On 18/05/2019 15:33, Erik Leunissen wrote:
> Problem: given the name of an embedded window, is there a straight
> forward method to determine the embedding text window?

If you're following best practices, it's the direct parent. If you don't
do it that way, scrolling of that text widget (one of the main reasons
for using a text widget to hold other widgets) is likely to cause weird
problems with clipping since that's managed exclusively in Tk by the
widget hierarchy.

The same also applies to canvases and ttk::notebooks (though for very
slightly different reasons that are also rooted in the nature of the
hierarchic widget system).

Donal.
--
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.

[Erik Leunissen]

On 18/05/2019 19:03, Donal K. Fellows wrote:

> If you're following best practices, it's the direct parent.

Thanks Donal.

I can use that for a strategy that starts with the assumption that the
direct parent is the embedding text widget, followed by a check whether
it really is so.

B.t.w. I'm using this for inspecting graphical user interfaces developed
by others, and that includes those that didn't follow best practices.

Erik.
--

If you don't
> do it that way, scrolling of that text widget (one of the main reasons
> for using a text widget to hold other widgets) is likely to cause weird
> problems with clipping since that's managed exclusively in Tk by the
> widget hierarchy.
>
> The same also applies to canvases and ttk::notebooks (though for very
> slightly different reasons that are also rooted in the nature of the
> hierarchic widget system).
>
> Donal.


--

[Rich]

Erik Leunissen <lo...@the.footer.invalid> wrote:
> On 18/05/2019 19:03, Donal K. Fellows wrote:
>
>> If you're following best practices, it's the direct parent.
>
> Thanks Donal.
>
> I can use that for a strategy that starts with the assumption that the
> direct parent is the embedding text widget, followed by a check whether
> it really is so.
>
> B.t.w. I'm using this for inspecting graphical user interfaces developed
> by others, and

> that includes those that didn't follow best practices.

Which means you can't rely on "direct parent" to find the windows.

Is there a reason why you can't use the "window names" subcommand?

$ rlwrap wish
% text .t
.t
% button .t.b -text Button
.t.b
% .t window create end -window .t.b
% .t window names
.t.b

[briang]

What I would recommend is to scan the entire widget hierarchy recursively using [winfo children] starting from ".".
Then use [winfo class] to identify the type of each widget.
Use [winfo manage] to figure out which geometry manager to query about each widget.
Once you've identified all the Text widgets, and all the widgets managed by "text", then you can introspect each Text widget using [$txt window names], and collate the relationships.

-Brian

[Erik Leunissen]

Hi Rich and Brian,

Thanks for your responses.

Yes, I know how to do a search using a strategy that contains your
suggestions (I already mentioned them in my original post).

My problem is the computational cost of such a search. Therefore, I was
after a strategy that prevents searching, determining the embedding text
widget directly given (for example) an appropriate configuration option.
Using the example that Rich supplied, something like:

[.t.b cget -embeddedby]

From your responses, it appears more and more so, that such a command
doesn't exist.

So, either I need to do a search, or I need to decide not to support
cases that deviate from best practices.

Greetings,
Erik Leunissen.

[Harald Oehlmann]

Am 18.05.2019 um 19:03 schrieb Donal K. Fellows:
> On 18/05/2019 15:33, Erik Leunissen wrote:
>> Problem: given the name of an embedded window, is there a straight
>> forward method to determine the embedding text window?
>
> If you're following best practices, it's the direct parent. If you don't
> do it that way, scrolling of that text widget (one of the main reasons
> for using a text widget to hold other widgets) is likely to cause weird
> problems with clipping since that's managed exclusively in Tk by the
> widget hierarchy.

Wouldn't the raise command fix that ?
pack [text .t]
label .l -text ABC -background yellow
.t window create 1.0 -window .l
raise .l .t

On the other side, the man-page clearly states that it must be a parent
of the text window. Than, the upper script should give an error. It does
not.

> The same also applies to canvases and ttk::notebooks (though for very
> slightly different reasons that are also rooted in the nature of the
> hierarchic widget system).

Could you be more detailed on that ?

Thank you,
Harald

[Rich]

Erik Leunissen <lo...@the.footer.invalid> wrote:
> Hi Rich and Brian,
>
> Thanks for your responses.
>
> Yes, I know how to do a search using a strategy that contains your
> suggestions (I already mentioned them in my original post).
>
> My problem is the computational cost of such a search. Therefore, I was
> after a strategy that prevents searching, determining the embedding text
> widget directly given (for example) an appropriate configuration option.
> Using the example that Rich supplied, something like:
>
> [.t.b cget -embeddedby]
>
> From your responses, it appears more and more so, that such a command
> doesn't exist.

Why does the "window names" subcommand of the text widget not do what
you want?

If will give you all of the embedded window names.

If you only want a specific subset, well, then you will have to
evaluate each name to see if it is of the specific type you want.

[Erik Leunissen]

On 19/05/2019 21:12, Rich wrote:
> Why does the "window names" subcommand of the text widget not do what
> you want?
>

Hi Rich,

You seem to misunderstand the problem that I have :-)

It's not that [$w window names] is inadequate per se.

It's that I don't have the name of the embedding text widget in the
first place, and I'd rather not traverse the widget hierarchy in search
for it.

Greetings,
Erik.

> If will give you all of the embedded window names.
>
> If you only want a specific subset, well, then you will have to
> evaluate each name to see if it is of the specific type you want.
>

[Rich]

Erik Leunissen <lo...@the.footer.invalid> wrote:
> On 19/05/2019 21:12, Rich wrote:
>> Why does the "window names" subcommand of the text widget not do what
>> you want?
>>
>
> Hi Rich,
>
> You seem to misunderstand the problem that I have :-)

Yes, indeed, upon review of your OP, I have misunderstood the problem.

> It's not that [$w window names] is inadequate per se.
>
> It's that I don't have the name of the embedding text widget in the
> first place, and I'd rather not traverse the widget hierarchy in
> search for it.

I'm not sure that you have any other option. If the heirarchy is
fixed, you'll need to traverse it at least once to collect at least the
names of the text widgets. Then, knowing that, you just have to search
each text widgets embedded windows list to find the containing text.

But if the heirarchy changes dynamically as the app executes, you
likely have no choice but to do the traversal each time you want to do
the reverse lookup.