adamj@tart28.berkeley.edu.BERKELEY.EDU (Adam J. Richter) (05/08/87)
References: According to the X toolkit documentation, when you associate a geometry manager with a window, you cannot directly pass any additional information. This is incredibly stupid. In the other parts of the toolkit, anytime you specify a call-back procedure that takes a window, you can also specify an extra argument to explain what the window is, which is incredibly smart. PLEASE FIX THIS IN THE NEXT RELEASE. -Adam J. Richter
price@port.UUCP (05/09/87)
Adam J. Ricter writes:
According to the X toolkit documentation, when you associate a
geometry manager with a window, you cannot directly pass any
additional information. This is incredibly stupid. In the other
parts of the toolkit, anytime you specify a call-back procedure that
takes a window, you can also specify an extra argument to explain what
the window is, which is incredibly smart.
I am not convinced at all that this is "incredibly stupid". I believe
the comparison between geometry managers and callback procedures is
innaccurate. I have not found the need to associate any data with
windows for which I register a geometry manager. Geometry managers
typically only care about screen arrangement, not content of individual
windows. Adding an extra argument means that I would have to pass
a NULL for the *great* majority of calls, which I think would be a
pain.
A simple solution exists with the current toolkit, requiring no changes.
Instead of adding yet more parameters to the interface, associate your
geometry information with the window using the Context Management
facilities. Using Context Management, you can associate any amount of
information you wish with the window, and retrieve it within the
geometry manager.
PS: Be kind to our toolkit designers. They really *are* working hard
to make a great mass of free software, and I have yet to find one of
them who is incredibly stupid.
...A little numb from lack of sleep, maybe, but not stupid. :-)
-----------
Chuck Price Internet: port!price@decsrc.DEC.com
Digital Equipment Corporation UUCP: ...!decwrl!decsrc!port!price
EasyNet: decsrc::"port!price"
"See the cat? See the cradle?" DECmail: PRICE@WROadamj@tart2.berkeley.edu.BERKELEY.EDU (Adam J. Richter) (05/09/87)
>> == Me (Adam Richter) > == Chuck Price >> According to the X toolkit documentation, when you associate a >> geometry manager with a window, you cannot directly pass any >> additional information. This is incredibly stupid. In the other >> parts of the toolkit, anytime you specify a call-back procedure that >> takes a window, you can also specify an extra argument to explain what >> the window is, which is incredibly smart. >I am not convinced at all that this is "incredibly stupid". I believe >the comparison between geometry managers and callback procedures is >innaccurate. I have not found the need to associate any data with >windows for which I register a geometry manager. Geometry managers >typically only care about screen arrangement, not content of individual >windows. Adding an extra argument means that I would have to pass >a NULL for the *great* majority of calls, which I think would be a >pain. My apology for refering to the lack an argument to the geometry manager as "incredibly stupid." Let's globally replace that string with "a design problem." >A simple solution exists with the current toolkit, requiring no changes. >Instead of adding yet more parameters to the interface, associate your >geometry information with the window using the Context Management >facilities. Using Context Management, you can associate any amount of >information you wish with the window, and retrieve it within the >geometry manager. Yes, I know. I had done that before I posted, and that is the way I intended to implement the change (by putting Xt{Save,Find,Delete}Entry in Xt(Set,Make/Get,Clear}GeometryRequest). The problem with not being able to pass an arg automatically is that it means that there is no intrinsic way of differentiating one window from another. The only time when you don't need this ability is when you're writing a general window manager (almost by definition), which, Is exactly the sort of thing someone writing code for the toolkit distribution would be doing. Let me put it another way, a trapped geometry change request event is supposed to be just like any other event. The procedures for requesting those events allow an argument to be passed to the handler. Why not insist on only the window being passed, and making the handler procedures use the context manager? From my (comparatively little) experience writing my own event passing code, trying to convert to Sx, and now the X toolkit, I can vouch for the fact that this option is one of the things that makes using any event passing system worthwhile. Finally, [I claim] the context manager is one level of non-abstraction below the ability to pass an argument. Had I had the ability to pass an argument, I would never have had any reason to learn or use "atoms. Now, if the atom mechanism changes, my program may very well break. Furthermore, when I query the value of an atom with respect to a window, I may get an error, because, due to a bug in my program, I neglected to assign it an appropriate value. If the toolkit were to do handle this, then it only happen because of a toolkit bug, which, because the toolkit is distributed software it should eventually become much more reliable than my code. Ergo, this sort of bug would be much less likely. >PS: Be kind to our toolkit designers. They really *are* working hard >to make a great mass of free software, and I have yet to find one of >them who is incredibly stupid. Again, sorry about the insulting language, and I salute your restraint in tolerating it. -Adam J. Richter adamj@opal.berkeley.edu