Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.programmer Subject: Re: GadTools functionality Message-ID: Date: 28 Jan 91 23:07:50 GMT References: <91023.105132GHGAQA4@cc1.kuleuven.ac.be> <18096@cbmvax.commodore.com> <18205@cbmvax.commodore.com> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 100 In-Reply-To: peter@cbmvax.commodore.com's message of 28 Jan 91 21:35:01 GMT In article <18205@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: You continue to draw the wrong impression. You confuse importance with relative importance, perhaps with some personal bias added There isn't any such creature as "absolute importance" - importance is a property assigned by a person, and that person is going to use their priorites. I agree, preventing crashes is more important than making programming easier. 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. Naturally, we don't talk about future plans in any detail. It is rarely if ever in Commodore's interest to do so. Complaining about what you haven't got is pointless. Why? Because: 1. We've already thought of the enhancements you'd like. 2. If we hadn't, we would have noted them down the first time you brought them up. If you don't want people complaing about the (apparent) lack of direction in software utilities, you can't just do a black hole imitation and quietly swallow bug reports and enhancement requests, while telling people that the feature they've asked be supported "isn't adequate", you've got to let people know what that direction is. 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. 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. I've never dealt with a vendor who didn't have this problem. CBM isn't the worst such vendor, but they're a long way from the best. I would note that menus are built in two steps: a creation step and a menu step. So don't pretend that the concept is lost on us. 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. >As to why I would rather have a requester than a window - how about >because it's simpler to use? If you code it right, once you have ONE window (which you need before you can put up a requester), whipping off more windows is easy. Yeah - opening the window is about the same as opening the requester under 2.0. Of course, the _requester_ already has all the gadgets attached and ready to go, and you can use it immediately. You can do that with the window - if you don't use GadTools. If you do, you have to recreate the gadgets. You are more than welcome to decide that in spite of evidence to the contrary, you find it easier to put up a requester without GadTools than a window with. Twelve months from now we can compare notes, and see how many people went down your road and how many people went down mine. Uh, right - with the line from CBM reps being "don't use requesters, use windows", people are going to use requesters? Betting against that is like betting that a third-party politician will be elected to a national office. In any case, the evidence I have is that 1) a simple push-button gadget is no easier to open with gadtools than intuition, and is harder to open if you want it with relative positioning; thereore 2) a requester/window that can have different heights/widths on each invocation requires no changes to edge-relative intuition gadgets to be opened; it requires recreation of similar GadTools gadgets to be opened. I can't think of any combination of circumstances that would make the GadTools version of this window "easier" than the requester version. I'm willing to look at any code you think demonstrates otherwise.