"AH" == Andy Hefner ahefner@gmail.com writes:
AH> On 4/27/05, Duncan Rose duncan@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