Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.sys.amiga.programmer Subject: Re: GadTools functionality Message-ID: <18297@cbmvax.commodore.com> Date: 30 Jan 91 03:08:11 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: >This is exactly the problem - using GadTools is harder than using the >stuff I've already got, and the two don't intermix - because of >limitations in GadTools. I think Peter has had his say on this, but I'll make one response (I don't want to get drawn into another protracted discussion). If your stuff is already done, and doesn't mix with Gadtools, then don't mix it. It's not meant to be a universal solvent. It is however a step in the right direction that can save many (not all) programmers time and effort. >Fine - how about the relative placement gadgets? You told me "They're >not adequate". Once again - no indication of future plans, and I don't >recall seeing a flag (even tagged as unimplemented). Last time around, >I didn't press the matter. Ditto for some facility to move the gadgets >after they've been created. With tags you never have to say "I'm sorry". :-) We can add tags at any point without sacrificing backwards and forwards compatibility (or certainly quite a few can be added). >Fine. Provide _feedback_. Even if you believe the problem isn't a real >problem, say something. I've dealt with companies who's normal >response was "That's not a bug, that's a feature." Even that is better >than nothing. Requests for this (or release notes stating what CBM >thinks have been fixed, etc) are a common occurence in the BIX support >areas. We've tried to start giving out release notes again (however, the release manager has to find time to do this, we have to find time to edit them after he breaks them out, and that has proved troublesome). Without major work our bug database can't handle responses (and I mean major). We can query it to see how a bug report was resolved. >BTW, the bugs in question aren't yours; neither is the response >problem. This is all part of the general lack of information - and >slow responses on requests - from CBM in general. Most people don't realize how few of us there are, or how much we're trying to get done. Be glad that 2.02 and later have held very close to initial schedules, and haven't slipped like past releases. This _is_ an improvement (a big one). However, it doesn't mean we don't need twice the number of people have (and could find good use for four times as many). We have been hiring lately, if you noticed (Martin Taillefer (vertex) being the latest aquisition, with others starting soon). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)