[mcclim-devel] possible buglet in highlighting shapes

[rpgoldman at real-time.com]

>>>>> "AH" == Andy Hefner <ahefner at gmail.com> writes:

    AH> On 4/27/05, Duncan Rose <duncan at robotcat.demon.co.uk> wrote:
    >> Also things like specifying an :application pane type in the :panes  of
    >> an application frame, passing ':scroll-bars t' but not having the pane

    AH> <grumble>
    AH> Can you find where in the spec this is required? I think this keyword
    AH> is fictional, and I'm astonished at the number of people trying to use
    AH> it. Maybe it is a vendor extension, but it doesn't make any sense to
    AH> me. Scrolling is acheived by embedding the pane in another pane which
    AH> provides scroll bars and a viewport. If I expect :scroll-bars t to
    AH> work as expected, make-pane would have to return the scroller pane
    AH> rather than the the pane I asked it to create (which makes no sense at
    AH> all), or there would have to be some magic backdoor whereby adopting
    AH> my pane caused a chain of parents to be adopted in its place. I don't
    AH> much like that either (if I was modifying the UI dynamically, with a
    AH> bunch of gadgets in a container, I'd no longer know which one to
    AH> disown when its time came without walking the entire tree of
    AH> children).

    AH> I have heard this complaint so often now that it is tempting to add a
    AH> check which will yell at programmers who expect this to work.
    AH> </grumble>

I have sympathy with both sides of this debate, because it seems like
a clash of intuitions, and they are both right.  And because I
suffered through this with the Garnet toolkit, which had the same
thing with its scrollable windows.

Andy does a great job of explaining why, from an implementation pov,
it would not be great to have :scroll-bars t.  He also explains why
it might hamper developing new interfaces by specialization.

However, the other side is valid, too.  It seems like an entirely
valid intuition that scrollability is an ATTRIBUTE of a window, rather
than a container around the window.  OK, the latter corresponds to
implementation better, but the former corresponds better to the
intuitions of a programmer who is not familiar with the implementation
of his toolkit.  I also think we have plenty of evidence from other
graphics toolkits that this is a reasonable intuition.

Having said that I see both sides of this debate as reasonable, I'm
not sure what the hell to propose.  Most unsatisfactory.

R