Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!seismo!uunet!cbmvax!peter From: peter@cbmvax.commodore.com (Peter Cherna) Newsgroups: comp.sys.amiga.programmer Subject: Re: GadTools functionality Message-ID: <18376@cbmvax.commodore.com> Date: 31 Jan 91 17:46:01 GMT References: <91023.105132GHGAQA4@cc1.kuleuven.ac.be> <18096@cbmvax.commodore.com> <18205@cbmvax.commodore.com> <18249@cbmvax.commodore.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >The answer "you don't want/need that" the biggest part of the >perception that you thought the world was the way it was supposed to >be. Note that saying "we're working on it" doesn't involve revealing >_what_ solution you're thinking about, or which direction you're >going, or etc. Just that you acknowledge the problem exists, and have >are working on a solution (possibly still trying to find one, even). Don't confuse "there are acceptable alternatives" or "we're sorry, but you can't do that" with "you don't want/need that". Second, don't infer from the absence of a "we're working on it" comment that we're not interested or have said our last word in the matter. In some cases, saying "we're working on it" may be incorrect, since we're working on other things, too, and it may not have bubbled to the top of the list. Finally, please trust that no limitation was applied arbitrarily and without consideration. The application-interface to GadTools has virtually no restrictions. The _implementation_ that was chosen for GadTools was dictated by a number of parameters, including available Intuition technology to leverage off, time and space constraints, etc. The current implementation applies some restrictions, but because the application-interface is sound, they can be removed when the time comes. I'll tell you that in the case of GadTools, there exists a high-payoff idea that's a lot of work. In other words, a lot of things will improve when one large difficult job is done. I'm less interested in a series of small individual steps that will be made obsolete by the big important one that will be done anyways. If you insist on reading between the lines, do it here: ------------------------------ WE THINK IT'S A GOOD IDEA (tm) ------------------------------ > Tags are easy to add afterwards. That's their biggest attraction. > >Ok, so I should have said "GREL tag" instead of "GREL flag". No, you should have not made any inferences based on the absence of reserved tags for the functionality you crave. It's not a question of replacing "flag" with "tag", it's fundamentally about the fact that we don't have to figure out or publish future tags until their time has come. >