Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!cbmvax!peter From: peter@cbmvax.commodore.com (Peter Cherna) Newsgroups: comp.sys.amiga.programmer Subject: Re: GadTools functionality Message-ID: <18249@cbmvax.commodore.com> Date: 29 Jan 91 16:49:04 GMT References: <91023.105132GHGAQA4@cc1.kuleuven.ac.be> <18096@cbmvax.commodore.com> <18205@cbmvax.commodore.com> Reply-To: peter@cbmvax.commodore.com (Peter Cherna) Organization: Commodore, West Chester, PA Lines: 114 In article mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >In article <18205@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >GadTools doesn't prevent crashes; and it doesn't >make programing the previously-supported gadgets noticably easier. It >does add a slew of new gadgets that are nice to have, but not nearly >as important as making simple gadget creation easier. This is in >comparison to the new window creation routine, which make creating a >window _much_ easier, as well as adding new features to windows. GadTools consists of ready-to-use kinds of gadgets. Programmer-friendly is a good way to describe it. Anybody who's ever tried to get robust mutually exclusive gadgets or properly-behaving scroll-bars will rightly claim that their job IS noticably easier. And most people don't want easier creation of pre-existing gadgets, they want to say "give me a button, give me a string gadget, and give me a set of radio buttons". Because GadTools gadgets are robust, and because they free up programmer time to make the rest of the application better, GadTools does indeed prevent crashes. Some programmers have built libraries of routines, so that creating a mutually-exclusive panel doesn't mean hitting the RKMs for a week, but a cut-and-paste operation. They may find the benefit of GadTools to be less, since they roll pretty well right now. For everyone else, it's a major help. >So far, I haven't seen _anything_ that appears to address the >problems I've raised, and I've seen some things that (to my knowledge) >haven't had a general release to developers yet. Pardon us for not showing you our entire hand. >This also represents a major change from what you said last time >around. Then, it was "why would you want to do it that way," along >with attempts to convince me that "that way" was wrong. At least this >time, I'm being told the problem will be fixed. This is the kind of >thing that makes people not bother telling vendors things. That this >was an enhancement request instead of a bug report doesn't change the >feeling that talking to vendors is a waste. That the first bug I ever >reported in 2.0 both generated at least one "why would you want to do >that" reply from CBM, and still results in software errors in the >latest ROM candidate mailed to me, even though at least two people >have reported it twice, doesn't help. If you put a spin on your understanding of what I said the first time, it should come as no surprise that when I reiterate my thoughts you claim there has been a major change. When you read the function prototypes or autodocs and see a Requester parameter, how hard is it to figure out that we intend to address requesters? Just don't claim you were blown off last time. Nobody tried to tell you requesters were wrong. I merely expressed that developers are migrating to windows-as-requesters, and that you also have that option. And by the way, we rarely fix a bug based on a ballot system. Number of reports doesn't count, provided it exceeds zero. From time to time a bug will fall off the face of the earth, for several reasons. Here are a few: 1. Engineer unable to reproduce bug, due to its dependence on an unseen factor, incomplete description of the problem, etc. 2. Engineer fixes only part of the bug, which is good enough to fix the test-example but perhaps not good enough for the application that was having trouble. 3. Engineer ascertains that the bug was some inappropriate use of the system features, and is in the application code. 4. Engineer determines that the problem cannot be fixed in the context of other changes and the new system. In any of these cases, the Engineer may be correct or not. We try as hard as we can to get them all right, but we're only human. Therefore, it is ALWAYS good to send a bug-reminder if you find that an important bug you reported has not been fixed by a certain major release. Give us one-line descriptions of each. Just drop us a note that says something like: The following bugs I've previously reported are still in 2.02: Clicking on the thingamajig while scrolling the thingamabob locks up the system. This is far better than resubmitting the full report. If we can't find the original report, we'll ask you for details. These are a really useful checkpoint for both of us. So please mail me a brief problem description. >Since you brought up the topic, the menus appears to suffer from the >same stuck-in-one-place problems that GadTools has. It accepts a >single array, and builds menus based on that. There's no way to format >an after-the-fact menu (i.e., after the user has issued the custom >menu commands, or done a mode change, or whatever) without changing >the structure afterwards. Not as bad as the gadgets, but it'd be much >nicer to be able to pass in a windows menu pointer, and have the menus >formatted to be added to that, instead of from scratch. Please see the DevCon notes. They contain an explanation of how you would build dynamic menus. It's not hard at all, and nothing has to be redone from scratch. >In any case, the evidence I have is that Hey. Use a requester and don't use GadTools. My ego can handle it. Feel free to continue to forward suggestions, since they're always taken seriously. Some day in the future GadTools will reach the point where it becomes valuable to you. Then we can both be delighted that you'll switch. The reaction I've got is that GadTools has reached that point for a great many other people. >