[TCLCORE] Re: Labeled frames (fwd)

[Eric M. <er...@aj...>]

Comments?

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions

---------- Forwarded message ----------
Date: Fri, 28 Jul 2000 10:37:18 +0200 (MET DST)
From: Peter Spjuth <d1...@dt...>
To: Eric Melski <er...@aj...>
Subject: Re: Labeled frames (fwd)

> For
> example, instead of introducing 4 new fields for internal borderwidth, why
> not just two, overrideInternalBorderWidth and
> overrideInternalBorderWidthSide?  The first indicates an overriding value
> for the internal borderwidth, the second indicates to which side that
> value applies.  Only if the second is set to some meaningful value (ie,
> top, bottom, left, or right) is it used; otherwise, everything behaves
> exactly as before.

Yes, that is also possible, and I've thought some about that solution.
Here are my views of it compared to the solution in my patch:

1. A benefit is that it saves memory since only two fields are added to the
   TkWindow struct. 
2. It is still not backwards compatible and writing a geometry manager that
   is both 8.3 and 8.4 compatible would still be about as tricky.
   I can't see any difference between them in this aspect, but if I miss
   something, please let me know.
3. It is more complex and a bit harder to use for the geometry managers.
   To look up the left side width you'd need something like 
   field1 + (field2 == LEFT ? field3 : 0)
   instead of just looking up the left field.
4. It is less general, e.g. it does not allow for adding -padx/y options.
   That I like a general solution should be rather clear by now, but
   specifically I would find -padx/y very useful.

2. is the most important point, but since I can't see any difference there
I let the others decide. I think 1. is too small a benefit to justify 3. and 
4., so I still prefer mine.

Hmm, I'll try to put some of my thoughts about 2. into ascii.

For an extension implementing a geometry manager (which I think is the main
thing that are interested in this) I get the following relationship 
between versions:

One field for each side solution:

Ext  Core  
8.4  8.4 : Works easily.
8.4  8.3 : The extension needs to detect 8.3 and use the deprecated field.
8.3  8.4 : Works, as long as new frame stuff is not used.

Two new fields solution:

Ext  Core  
8.4  8.4 : Works easily, though not as easy as the other.
8.4  8.3 : The extension needs to detect 8.3 and not use the new fields.
8.3  8.4 : Works, as long as new frame stuff is not used.

So, you can see why I don't see much difference there.

I hope the above makes some sense, otherwise ask.

And I agree that this needs more discussion.
 
/Peter

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.