#1605 embedded windows (in text/canvas) are not cropped

[Vince Darley]

For the canvas:

canvas .c -width 100 -height 100 -bd 10 -relief raised
pack .c -fill both
frame .c.f -bg red -width 200 -height 200
.c create window {20 20} -window .c.f

Similarly for the text widget. For both one can also
look closely at the widget demos.

It appears as if Tk_MaintainGeometry and friends are
not paying any attention to widget borders.

[Vince Darley]

Logged In: YES
user_id=32170

Here's a good script to illustrate the problem. This script
produces three toplevels. The first is ok (uses a
labelframe) the other two contain a text widget and canvas
widget respectively, and both have embedded windows which
completely overlap the window border.

catch {console show}

# This one works ok
labelframe .p -width 100 -height 100 -borderwidth 15 \
-relief raised -text title

pack .p
pack propagate .p 0

frame .p.q -bg red -width 100 -height 20
pack .p.q
label .p.r -text "say hello there..." -bg blue -anchor w
pack .p.r

# Now for a text widget
toplevel .t
wm title .t "Text widget"
text .t.t -width 10 -height 5 -borderwidth 15 -relief raised
pack .t.t

frame .t.t.q -bg red -width 100 -height 20
label .t.t.r -text "say hello there..." -bg blue -anchor w

.t.t window create end -window .t.t.q
.t.t insert end \n
.t.t window create end -window .t.t.r
.t.t insert end \n

# Now for a canvas widget
toplevel .t2
wm title .t2 "Canvas widget"
canvas .t2.t -width 100 -height 50 -borderwidth 15 -relief
raised
pack .t2.t

frame .t2.t.q -bg red -width 100 -height 20
label .t2.t.r -text "say hello there..." -bg blue -anchor w

.t2.t create window 1c 0c -window .t2.t.q
.t2.t create window 1c 1c -window .t2.t.r

[Vince Darley]

test script showing problem

[Donal K. Fellows]

Logged In: YES
user_id=79902

I'm not quite sure what's wrong here (but I accept it is
confusing). Windows are always and only clipped by the main
windowing system, not Tk, and borders are drawn inside the
underlying window, so child windows naturally overlap borders.

The other odd thing is that canvas coordinates include the
border space too, but again that is a consequence of borders
being inside windows.

[Vince Darley]

Logged In: YES
user_id=32170

I don't understand how dkf's comment explains why there is a
difference in behaviour between text/canvas widgets (no
clipping) and labelframe widgets (clipping).

I also don't understand why this behaviour is deemed not
really wrong. The "fact" that windows are "always and only
clipped by the main windowing system" (assuming that is true
despite the observed difference between labelframes and
canvas/text) clearly leads to a bug and therefore should be
fixed. Just because something is true doesn't make it
correct, but that seems to be the gist of dkf's argument here.

More bluntly: I see no way in which the current Tk behaviour
can be considered desirable at all, so therefore it's a bug.
Perhaps that bug is difficult to fix (and perhaps that
difficulty is difference on X, Win, Mac), but that doesn't
mean we shouldn't acknowledge the problem and look into
fixing it.

my 2 cents, anyway.

[Vince Darley]

Logged In: YES
user_id=32170

Another way of fixing this would be to redraw the window
border in the areas which might be affected by such embedded
windows, after the embedded windows have been displayed.

[Donal K. Fellows]

Logged In: YES
user_id=79902

The key problem is that subwindows float over the main
window's drawing surface (though ISTR there is a way to draw
over the top of subwindows?) The labelframe is either not
using a widget or is geometry-managing the widget specially.
I can't recall which offhand.

Because geometry management causes layout differences, the
only easy fix is window clipping, but we've not got any of
the technology for doing that in the core at the moment so
it is minimally a big job.

A workaround is to put a borderless canvas inside a frame
with a border.

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

That any window higher in the stack draws over another is
100% correct, even if "embedded" using Tk commands. The
only issue here is that the call that tells the embedded
window what space allowance it has should be accounting for
highlightthickness and bd of the canvas, subtracting that
from the total.

[Vince Darley]

Logged In: YES
user_id=32170

Jeff: here's the current tkTextWind.c code:

/*
* Compute the window's location and size in the text
widget, taking
* into account the align and stretch values for the window.
*/

EmbWinBboxProc(chunkPtr, 0, screenY, lineHeight,
baseline, &lineX,
&windowY, &width, &height);
windowX = lineX - chunkPtr->x + x;

if (textPtr->tkwin == Tk_Parent(tkwin)) {
if ((windowX != Tk_X(tkwin)) || (windowY != Tk_Y(tkwin))
|| (Tk_ReqWidth(tkwin) != Tk_Width(tkwin))
|| (height != Tk_Height(tkwin))) {
Tk_MoveResizeWindow(tkwin, windowX, windowY, width,
height);
}
Tk_MapWindow(tkwin);
} else {
Tk_MaintainGeometry(tkwin, textPtr->tkwin,
windowX, windowY, width, height);
}

so, if I understand you correctly, something needs to be
added to this to tell the embedded window that it can't use
a certain portion of the display.

Note: we don't want the embedded window to re-layout its
contents to account for a different height/width, but rather
just to clip what it displays accordingly.

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

That's correct - the width and height shouldn't be allowed
to be Tk_Width and Tk_Height at all times. They must
account for a window's border stuff, the highlightthickness
and bd. Bug 795869 has the same issue for panedwindows. It
may be in EmbWinBboxProc that the truncation checks are needed.