Tk Source Code

In Tk 9.0 a Canvas widget can have a negative borderwidth (whatever
that is supposed to mean):

% canvas .c
.c
% .c configure -borderwidth -2
% .c configure -borderwidth
-borderwidth borderWidth BorderWidth 0 -2

But a button cannot have a negative borderwidth:

% button .b
.b
% .b configure -borderwidth -2
% .b configure -borderwidth
-borderwidth borderWidth BorderWidth 2 0

Surely this inconsistency is not intentional, right?  So I think this is
a bug.

> I suspect that the real point is that an embedded window gets completely redrawn as long as any part of it qualifies for being redrawn.

Fair point. Since X11 behaves this way, other platforms must emulate the same behavior. ;-) Anyway, it is no problem, otherwise Csaba would have noticed it.

In the Canvas, Tk handles embedded windows using the special TK_ALWAYS_REDRAW flag. Canvas windows have no -padx/-pady options, otherwise we could allow negative values for them too.

> For embedded windows this is not a problem, because these are managed
> separately by the OS, not drawn in the text widget itself. So, for your
> specific usecase I see no harm. 

This does not make sense.  It may be true with X11 that embedded windows
are managed by the OS, but it is definitely not true for Aqua.  The OS
is not involved at all in managing embedded windows on macOS and they are
in fact drawn in the Text widget itself.

I suspect that the real point is that an embedded window gets completely
redrawn as long as any part of it qualifies for being redrawn.

> Why forbid negative values if they don't cause any harm?

Tk uses boundary boxes for drawning, and deciding which parts of the screen needs to be repainted. That means, when an image is allowed to go outside its boundary box, Tk cannot know anymore which parts need to be redrawn. I would expect visual artifacts like in [this] ticket.

For embedded windows this is not a problem, because these are managed separately by the OS, not drawn in the text widget itself. So, for your specific usecase I see no harm.

I am not aware of any practical use case for a negative padding in case of an embedded image. Of course, that is just me. OTOH: Why forbid negative values if they don't cause any harm?

> An embedded image having -padx -8 will appear displayed not at the text index specified in the "... image create ..." command, but left-shifted by 8 px (just like an embedded window with -padx -8). This doesn't cause any artifacts.

Is there any use-case to do that?

> Will you merge this into the "revised_text" branch too

Yes, eventually. But I plan to wait for TIP #698, that makes things a lot easier.

1. An embedded image having -padx -8 will appear displayed not at the text index specified in the "... image create ..." command, but left-shifted by 8 px (just like an embedded window with -padx -8). This doesn't cause any artifacts.

2. In the "options" man page the -padx and -pady values are indeed documented to be nonnegative. OTOH, the options of the same names for a window embedded into a text widget are documented in the "text" man page w/o any reference to the "options" man page. I am not aware of any place where the effect of negative pad values would be documented.

3. Jan, many thanks for your quick action! I have seen that you backed out the changes made in tkTextWind.c. Will you merge this into the "revised_text" branch too? And: How about the file tkTextImage.c? (I have mentioned an inconsistency compared to tkTextWind.c, and proposed to simply undo the changes made there, too.)

> -padx/-pady is documented to be non-negative. 

Jan, are you also going to update that documentation?

-padx/-pady is documented to be non-negative. See: here

Thanks, Csaba!

Indeed, it sounds reasonable for embedded windows. I will change it, and add this as an exception to TIP #698.

For embedded images, how do embedded images with negative -padx/-pady values look like? I wouldn't be surprised if this would give unexpected visual artefacts.

That is interesting.  I had no idea that negative padx or pady had any
effect.  Is the effect documented?

In CSS, margins are allowed to be negative but paddings must be non-negative.
A negative margin shifts the location of the element, even outside of its
container.

It sounds to me like we should consistently allow all padx and pady values
to be negative.  I would like to know where else negative values have an
effect, other than for embedded windows.

I can see that in tkTextWind.c, in the functions EmbWinLayoutProc() and EmbWinBboxProc(), negative -padx and -pady values are now being replaced with 0. In tkTextImage.c, the same is only done in the function EmbImageLayoutProc() but not also in EmbImageBboxProc(). IMHO, this is not consistent.

This said, I am strongly in favor of undoing these changes in both files. The reason is that the Tablelist code makes intensive use of negative -padx and -pady values when embedding a window for interactive cell editing. With the current trunk version, that embedded window appears badly misplaced, and I don't see how to fix this broken appearance when the -padx and -pady values are forced to be positive.

Negative -padx and -pady values make it possible for an embedded window to become larger without changing the text index at which it was created. The Tablelist code makes use of this feature, and I am not aware of any bug reports stating that negative -padx and -pady values for windows embedded in a text widget cause any trouble.

With [d6343387] I see the answer to my question.

Great. Will you merge this to the revised_text branch?

Now fixed for "text" widget as well: [41a1464bc1716b25]

It turned out that for "frame", width and height was still not handled correctly.

fixed that now.

I'm sure there are more ...., so keeping open

I see that the scrollbar manual page has already been edited as I suggested.
(I was looking at the online manual).  So all that is needed is to set
borderwidth to 0 when a negative value is specified.

Here is a really weird one, which also does not seem to behave the way
the manual says:

% scrollbar .sb
.sb
% .sb configure -borderwidth -2
% .sb configure -borderwidth
-borderwidth borderWidth BorderWidth 0 -2
% .sb configure -elementborderwidth 3
% .sb configure -elementborderwidth
-elementborderwidth elementBorderWidth BorderWidth {} 3
% .sb configure -elementborderwidth -3
% .sb configure -elementborderwidth
-elementborderwidth elementBorderWidth BorderWidth {} {}

So borderwidth is allowed to have a negative value but elementborderwidth
is set to '' if it is assigned a negative value.

The manual says (about elementborderwidth):
"If this value is less than zero, the value of the -borderwidth option is used in its place."

It would seem that feature could never be activated, since the value
is never less than 0, although it might be ''.  One would need to
read the code to learn that setting the option to {} causes the struct
field to be set to INT_MIN, which is actually a negative value.

Also, the manual says that the -borderwidth is always non-negative:
"Specifies a non-negative value indicating the width of the 3-D border
 to draw around the outside of the widget"

There are many ways to interpret the manual, but the intent is revealed
by looking at tkUnixScrlbr.c, which says in TkDisplayScrollbar:

    elementBorderWidth = scrollPtr->elementBorderWidth;
    if (elementBorderWidth < 0) {
        elementBorderWidth = scrollPtr->borderWidth;
    }

(The other platforms ignore the option altogether.)

So one way to make the behavior agree with the manual would be to
(1) replace negative values of borderwidth by 0; and
(2) edit the manual to say "negative value or {}" and perhaps point
out that the default value is {}.

But ... be carefull: If the TK_OPTION_NULL_OK flag is set it's slightly different

Then it's best to turn the invalid value into "", so it won't be taken into account.

>Can I do it like this?

+1

Can I do it like this?

#define FIX_NEGATIVE_OPTION(widget, option)          \
	if (widget->option < 0) {                    \
	    widget->option = 0;                      \
	    if (widget->optionPtr) {                 \
		Tcl_DecrRefCount(widget->optionPtr); \
	    }                                        \
	    widget->optionPtr = Tcl_NewIntObj(0);    \
	    Tcl_IncrRefCount(widget->optionPtr);     \
	}


:^)

And [c15c895b789cd7b6|here] is the fix for those examples :-)

Good luck, doing this for all options with the same consistency ...

Here is another inconsistency.   A button treats negative width and height
values differently from how it treats negative borderwidth values in Tk 9.0:

% button .b
.b
% .b configure -width -100 -height -100
% .b configure -width
-width width Width 0 -100
% .b configure -height
-height height Height 0 -100

Another way to drive unit testers crazy is to change the wording of
error messages, causing tests which check the error message to start
giving false negatives.

I think the best strategy for Python would be to raise a Python exception
if a negative value is supplied to an option which is *planned* to not
use the TK_OPTION_NEG_OK attribute, even if the restriction is not yet
enforced by actual Tk widgets.  That way when Tk gets around to finishing
TIP 698 no extra work will be needed for Python.

One way around the error message issue would be to add a prefix to
each message containing a numerical code.  Then the unit tests only
need to check the code, and Tk can change the wording to our heart's
content. IF a message changes from:
  "Tcl_CreateInterp error 123: can't create global namespace"
to
  "Tcl_CreateInterp error 123: cannot create global namespace"
then it will not break any correctly written unit tests.

PS If I were allowed to offer an opinion about the discussion in [0439e1e1a]
I would say that making a message more "formal" by changing can't
to cannot while still omitting articles and using incomplete sentences
seems Quixotic.

In the tkinter unit tests they test assigning a list of values for each option
of each widget type.  They use configure to set the opeion and then use configure
or cget to read the option.  The test compares the input and the output.

They have a set of comparison functions that are supposed to cover the
different possibilities.  But if the behavior varies by widget type, option
name, and Tk version, it makes for a lot of extra work.  And if it also varies
over time with the same Tk version that makes it really hard.  It seems like
it would be better if it just depended on the Tk version and the option name,
and if there weren't too many different behaviors among the different
options.

In Tk 8.6:

% button .b
.b
% .b configure -borderwidth -2
% .b configure -borderwidth
-borderwidth borderWidth BorderWidth 2 -2

This suggests that buttons accepts a negative borderwidth, but in fact it doesn't. See also TIP #698. I think the best way to handle this is as described in the TIP. The second-best way (as some - but not all - widgets already do) is change the negative value to 0 or {}. This is done in Tk 9 for 'button' and 'message', but not yet for other widgets.

Indeed, this is not done consistently yet