GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) (01/23/91)
Hi,
I'm just curious but why are the number of composite gadgets
in the GadTools library so few ? I've programmed in XWindows
and the number of composite gadgets in the XWindow ToolKit is
(rough estimate) about 3 times as high. Some examples :
- Edit gadget : a complete editing gadget for multiple lines
including scrolling. This gadget in fact supports an
easy view on a text.
- Multiple line string gadgets.
- Bitmap edit gadget : a complete drawing gadget including
grid, enlargement and scrolling.
- Multiple column lists.
- Popup menu gadgets.
and so one ...
I know that MS-Windows also has a lot of composite gadgets in
the toolkit.
Maybe for the next AmigaDOS release ?
Jorrit Tybergheinmwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/24/91)
In article <91023.105132GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes:
Hi,
I'm just curious but why are the number of composite gadgets
in the GadTools library so few ? I've programmed in XWindows
and the number of composite gadgets in the XWindow ToolKit is
(rough estimate) about 3 times as high. Some examples :
I have a similar complaint about gadtools - the gadgets are about
three times as hard to build as gadgets in the Motif ToolKit. For
example, a simple pushbutton from Gadtools requires specifying
position and size (among other things). Motif requires specifing only
the name and the containing object. When I asked the author of
gadtools about this, his replies indicated that he thought things
ought to be this way. That gadtools are insufficient for building
requesters didn't bother him either.
<mike
--
Come all you rolling minstrels, Mike Meyer
And together we will try, mwm@pa.dec.com
To rouse the spirit of the air, decwrl!mwm
And move the rolling sky.jesup@cbmvax.commodore.com (Randell Jesup) (01/24/91)
In article <91023.105132GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: > I'm just curious but why are the number of composite gadgets >in the GadTools library so few ? I've programmed in XWindows >and the number of composite gadgets in the XWindow ToolKit is >(rough estimate) about 3 times as high. Some examples : > - Edit gadget : a complete editing gadget for multiple lines > including scrolling. This gadget in fact supports an > easy view on a text. > - Multiple line string gadgets. > - Bitmap edit gadget : a complete drawing gadget including > grid, enlargement and scrolling. > - Multiple column lists. > - Popup menu gadgets. Have you ever noticed the size of the XWindows libraries (or programs built that use those features?) Some XClocks are hundreds of K (just for a clock). I think one was approaching a meg. That said, there is some stuff going on to provide more support for applications (see the AppShell stuff from the June 1990 devcon notes for more information) via extended objects, etc. Remember: GadTools has to fit in the ROM. -- 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") ;-)
peter@cbmvax.commodore.com (Peter Cherna) (01/25/91)
In article <91023.105132GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: >Hi, > > I'm just curious but why are the number of composite gadgets >in the GadTools library so few ? GadTools provides around a dozen of the most commonly-needed classes of gadget in an easy-to-use way. >I've programmed in XWindows >and the number of composite gadgets in the XWindow ToolKit is >(rough estimate) about 3 times as high. Some examples : XTK is more than 3 times as big, I would think :-) > - Edit gadget, Multiple line string gadgets, Bitmap edit gadget, > Multiple column lists, Popup menu gadgets. All good ideas, and all possible for a future version. Note also that Intuition has new features that make it much easier to add this type of functionality, either through GadTools or separately. We tried to add gadget types in order of importance, where importance consists of several factors, including: 1 - number of applications that can benefit 2 - difficulty to application of doing it itself 3 - ROM space required to implement the class in GadTools >Maybe for the next AmigaDOS release ? It's quite premature to be dreaming publicly about the next release, however more classes are certainly a good idea. > Jorrit Tyberghein Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"
peter@cbmvax.commodore.com (Peter Cherna) (01/26/91)
In article <MWM.91Jan23105444@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >I have a similar complaint about gadtools - the gadgets are about >three times as hard to build as gadgets in the Motif ToolKit. For >example, a simple pushbutton from Gadtools requires specifying >position and size (among other things). Motif requires specifing only >the name and the containing object. We needed a lot of things in the gadget area. This included easier gadget creation, more powerful gadget types that took care of details, and layout support. It is never possible to have everything, and in the case of GadTools, you get the first two of these three things. Note that nothing in GadTools prevents the solution of the rest of the problem some other time. As well, GadTools does not subtract anything either, since you can still use Intuition gadgets (alone or alongside GadTools gadgets). GadTools is proving to be a very popular part of 2.0 among developers. That it does not yet solve all problems has not deterred developers from using and enjoying it. >When I asked the author of >gadtools about this, his replies indicated that he thought things >ought to be this way. That gadtools are insufficient for building >requesters didn't bother him either. As the author of GadTools, I'm not so pleased to be misquoted in public. My comments about GadTools and layout have never deviated from the above. Any real project requires that real decisions need to be made. Real decisions include the decision to leave a part of a project for next time so that the rest of that project might be available sooner (or at all). The GadTools functions SPECIFICALLY have requester parameters for that future expansion. I consider this support important enough to plan for it. I consider requester support considerably less important than many of the other features and attributes of GadTools and Intuition, which I am also responsible for. Which bugs would you have liked me to leave in exchange? As well, a large number of programmers are forsaking requesters for windows, for several good reasons, including greater homegeneity with other windows, blocking and non-blocking versions possible, dragging possible, etc. The user can benefit from a dialog that was implemented as a window instead of a requester. Such dialogs are not harder to code. So if you want to use GadTools in a dialog, use another window. No big deal. Please let MY words stand for what I think. > <mike Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"
peter@sugar.hackercorp.com (Peter da Silva) (01/27/91)
In article <18096@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: > As well, a large number of programmers are forsaking requesters for > windows, Yeh, I never quite could see the point of requestors. Perhaps Mike could explain just what problem they're solving... -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
SteveX@omx.UUCP (Steve Tibbett) (01/27/91)
In article <91023.105132GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: > I'm just curious but why are the number of composite gadgets >in the GadTools library so few ? I've programmed in XWindows >and the number of composite gadgets in the XWindow ToolKit is >(rough estimate) about 3 times as high. Some examples : > - Edit gadget : a complete editing gadget for multiple lines > including scrolling. This gadget in fact supports an > easy view on a text. > - Multiple line string gadgets. > - Bitmap edit gadget : a complete drawing gadget including > grid, enlargement and scrolling. > - Multiple column lists. > - Popup menu gadgets. Gadtools as it is is their first shot at it, and it would be easy for it to grow more types in the future. You could even use the BOOPSI custom gadget interface to create the gadgets you're talkin about, I believe... -- ...Steve Tibbett...bix=s.tibbett...Plink=STEVEX...BBS=613-731-3419... ...VirusX=4.01...Insert Disclaimer Here...
es1@cunixb.cc.columbia.edu (Ethan Solomita) (01/27/91)
In article <17995@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > Remember: GadTools has to fit in the ROM. Why? What is wrong with putting it in libs:? It seems like it is something with great potential, and could be made much better. How much has it changed since June DevCon? >-- >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") ;-) -- Ethan Why do the Reagans always fly together? Because if they flew separately, and one crashed, the other would have to talk to the children.
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/29/91)
In article <18096@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >When I asked the author of >gadtools about this, his replies indicated that he thought things >ought to be this way. That gadtools are insufficient for building >requesters didn't bother him either. As the author of GadTools, I'm not so pleased to be misquoted in public. What quote? The above _is_ the impression you left me with. You kept trying to convince me that layout programs were the right way to do things, and gave no indication that there were any plans for support of a layout library that moved gadtools gadgets around after creation. The GadTools functions SPECIFICALLY have requester parameters for that future expansion. [...] As well, a large number of programmers are forsaking requesters for windows I.e. - "We're going to fix it, but you shouldn't use it." That's the answer I got last time. To me, that indicates the what I said above - that you don't consider this a problem, but something you're going to have to kludge in a fix for. As to why I would rather have a requester than a window - how about because it's simpler to use? To implement something like the 'okay?' Rexx calls in ADPro, I could (as long as I don't use GadTools, unless you're going to put back relative positions along with requester support) set up a generic requester, and invoke a single function that crams in the text pointer, tweaks the size of the requester, and runs the requester. Using windows and gadtools, I have to recreate the window and at least some of the gadgets in it every time the function gets invoked. This is _not_ making things simpler. <mike -- The weather is here, I wish you were beautiful. Mike Meyer My thoughts aren't too clear, but don't run away. mwm@pa.dec.com My girlfriend's a bore, my job is too dutiful. decwrl!mwm Hell nobody's perfect, would you like to play?
jimm@amiga.UUCP (Jim Mackraz) (01/29/91)
In article <SteveX.3302@omx.UUCP> SteveX@omx.UUCP (Steve Tibbett) writes:
)> I'm just curious but why are the number of composite gadgets
)>in the GadTools library so few ?
)>Some examples :
)> - Edit gadget :
)> - Multiple line string gadgets.
)> - Bitmap edit gadget
)> - Multiple column lists.
)> - Popup menu gadgets.
)You could even use the BOOPSI custom gadget interface to create the
)gadgets you're talkin about, I believe...
Latest DevCon disks include my examples of boopsi composite (group)
gadget classes, and how to implement one or more public classes of
gadgets (or whatever) as an exec library.
Popup menu gadgets, however, will require some semaphore voodoo work
inside Intuition before they can be implemented as boopsi classes.
jimm
--
--- opinions expressed herein are my own. ---
"... Because they can."
- profound punchline to joke about dogspeter@cbmvax.commodore.com (Peter Cherna) (01/29/91)
In article <MWM.91Jan28112420@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >What quote? The above _is_ the impression you left me with. You continue to draw the wrong impression. You confuse importance with relative importance, perhaps with some personal bias added based on what you think is important or difficult. (Personal bias is OK, since we all have it, but we should all be aware of it, myself included). Instead of adding this extension (which turns out to be a reasonable amount of work), we expended our efforts and ROM space on other areas which are more important, like keeping menus which go off-screen from crashing your Amiga. >You kept >trying to convince me that layout programs were the right way to do >things, and gave no indication that there were any plans for support >of a layout library that moved gadtools gadgets around after creation. Naturally, we don't talk about future plans in any detail. It is rarely if ever in Commodore's interest to do so. 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. >I.e. - "We're going to fix it, but you shouldn't use it." That's the >answer I got last time. To me, that indicates the what I said above - >that you don't consider this a problem, but something you're going to >have to kludge in a fix for. No kludge. ONE DAY it will really work correctly, smoothly, and in an integrated manner. Today (and tomorrow, for that matter) it won't. >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. 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. 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. 3. We are not adding any features to 2.0 at this stage. 4. Mailing me any new insights in a concise form increases the probably that I'll notice them, though I try to read relevant stuff as carefully as I can. > <mike Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/29/91)
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. <mike -- Estant assis, de nuit secrette estude, Mike Meyer Seul, repose sur la selle d'airain, mwm@pa.dec.com Flambe exigue, sortant de solitude, decwrl!mwm Fait proferer qui n'est a croire vain.
bj@cbmvax.commodore.com (Brian Jackson) (01/29/91)
In article <MWM.91Jan28112420@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: [ re: Gadtools ... ] > >I.e. - "We're going to fix it, but you shouldn't use it." That's the >answer I got last time. To me, that indicates the what I said above - >that you don't consider this a problem, but something you're going to >have to kludge in a fix for. ^^^^^^ Simply stated, Peter does not kludge things. His work is well thought out and well implemented. Implications to the contrary are off base >This is _not_ making things simpler. I suspect that most folks writing Intuition stuff will find Gadtools to be a major improvement. I suspect that you will use it too since to do otherwise makes for a LOT more work to do the same thing. A lot of folks think it's ok to trade pain for principle... > <mike bj ----------------------------------------------------------------------- | Brian Jackson Software Engineer, Commodore-Amiga Inc. GEnie: B.J. | | bj@cbmvax.cbm.commodore.com or ...{uunet|rutgers}!cbmvax!bj | | "So, through the eyes love attains the heart." | -----------------------------------------------------------------------
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/30/91)
In article <18232@cbmvax.commodore.com> bj@cbmvax.commodore.com (Brian Jackson) writes: In article <MWM.91Jan28112420@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: [ re: Gadtools ... ] > >I.e. - "We're going to fix it, but you shouldn't use it." That's the >answer I got last time. To me, that indicates the what I said above - >that you don't consider this a problem, but something you're going to >have to kludge in a fix for. ^^^^^^ Simply stated, Peter does not kludge things. His work is well thought out and well implemented. Implications to the contrary are off base I didn't mean to imply that his work was a not well implemented. The behavior of the code is proof to the contrary. The attitude of "don't use requesters, use windows instead" indicates that he views adding support for requesters as a kludge, and wishes they would go away. >This is _not_ making things simpler. I suspect that most folks writing Intuition stuff will find Gadtools to be a major improvement. I suspect that you will use it too since to do otherwise makes for a LOT more work to do the same thing. A lot of folks think it's ok to trade pain for principle... If there weren't already a fair number of libraries floating around that did most of those things - both sans restrictions, and with less pain, I'd agree with you. <mike -- Cats will be cats and cats will be cool Mike Meyer Cats can be callous and cats can be cruel mwm@pa.dec.com Cats will be cats, remember this words! decwrl!mwm Cats will be cats and cats eat birds.
peter@cbmvax.commodore.com (Peter Cherna) (01/30/91)
In article <MWM.91Jan28170750@raven.pa.dec.com> 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. > <mike Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/30/91)
In article <18249@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes:
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.
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.
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?
As I pointed out the first time around, I didn't have the autodocs
then. You didn't "it'll be fixed;", you said "use windows instead."
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.
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.
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:
[ list deleted ]
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.
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.
So please mail me a brief problem description.
Let me verify that both bugs are still in the 37.x that I plan on
getting tonight, and if appropriate, I'll have bug reports in the
official channels tonight.
Just as a pointer, try running something that does dynamic menus, and
rolls them to more columns if they are to long. Watch what happens
when the menu gets clipped on the right.
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.
You're correct - I dismissed the method as clumsy (it's clumsier than
my five-year-old link library), and haven't looked at it in a while. I
had forgotten exactly what the problem was.
Hey. Use a requester and don't use GadTools. My ego can handle it.
I had assumed so; others were trying to tell me that wasn't the case.
<mike
--
That time we slept together Mike Meyer
That's as far as it went mwm@pa.dec.com
Yet though we're not quite lovers decwrl!mwm
You're more than a friendjesup@cbmvax.commodore.com (Randell Jesup) (01/30/91)
In article <MWM.91Jan29150653@raven.pa.dec.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") ;-)
bj@cbmvax.commodore.com (Brian Jackson) (01/30/91)
In article <MWM.91Jan29111447@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >I didn't mean to imply that his work was a not well implemented. The >behavior of the code is proof to the contrary. The attitude of "don't >use requesters, use windows instead" indicates that he views adding >support for requesters as a kludge, and wishes they would go away. Again you put words in Peter's (our) mouth. What he said (and I reiterate) is that given (1) the time constraints involved in developing Gadtools along with (2) the time constraints involved in devloping the 2.0 OS along with (3) the ROM size constraints for 2.0 (and, by definition, Gadtools) some choices had to be made. Those choices were made based upon what Peter felt would serve the MOST programmers in the best way. That is a far cry from "wishing requesters would go away." It simply recognizes the fact that *many* programmers have chosen to use windows in favor of requesters for myriad reasons. That doesn't in the least negate the functionality of requesters or the fact that people like them and would like to have them get the Gadtools "treatment" as well. I must admit to a certain level of mystification over your position on this. The Requester hooks are quite obviously there in both the prototypes and the function docs. How can you assume that they weren't considered? > <mike bj ----------------------------------------------------------------------- | Brian Jackson Software Engineer, Commodore-Amiga Inc. GEnie: B.J. | | bj@cbmvax.cbm.commodore.com or ...{uunet|rutgers}!cbmvax!bj | | "We defy augury" | -----------------------------------------------------------------------
peter@cbmvax.commodore.com (Peter Cherna) (01/31/91)
.91Jan29150653@raven.pa.dec.com> Sender: Reply-To: peter@cbmvax.commodore.com (Peter Cherna) Followup-To: Distribution: Organization: Commodore, West Chester, PA Keywords: In article <MWM.91Jan29150653@raven.pa.dec.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. Standard problem. Anything you write yourself and/or already use tends to be easier than something new. Anything it does better or different than the new thing seems (and sometimes is) harder in the new thing. Things that are simple in the new way and complex in the old way but whose procedure you know by wrote (or by cut-and-paste) don't seem helped by the new way. But lots of people don't have a pool of routines to draw from. >As I pointed out the first time around, I didn't have the autodocs >then. You didn't "it'll be fixed;", you said "use windows instead." You must have had the prototypes to get anywhere; they also have the requester parameter. >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. Relative gadgets are both hard to support and insufficient. How do you make a row of three buttons, evenly spaced? The left one would be absolutely positioned, the right one would be GRELRIGHT, and the middle one is, um, GRELRIGHT/2? Moving gadgets are hard, too. Tags are easy to add afterwards. That's their biggest attraction. > <mike Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/31/91)
In article <18312@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: In article <MWM.91Jan29150653@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: Standard problem. Anything you write yourself and/or already use tends to be easier than something new. Anything it does better or different than the new thing seems (and sometimes is) harder in the new thing. Especially when the things you wrote yourself were designed to deal with a specific problem that wasn't dealt with in the new thing. It's not that my tools are easier to use - it's that they solve what I see as the hard problem, whereas GadTools doesn't address the problem, and prevents me from applying my old solutions. Relative gadgets are both hard to support and insufficient. How do you make a row of three buttons, evenly spaced? The left one would be absolutely positioned, the right one would be GRELRIGHT, and the middle one is, um, GRELRIGHT/2? I hear you saying "You don't really want that anyway". This is _not_ the same answer as "we're working on it". With GadTools, how do I keep a gadget 5 pixels from the right edge of the window as the user resizes the window? Your problem with GREL has a fairly simple solution (and a trivial solution using the tools I designed). GadTools makes the solution harder to apply to either problem, if it doesn't make it insoluble. Moving gadgets are hard, too. Actually, moving Intuition gadgets is easy - I do it all the time. Moving GadTools gadgets is impossible (at least you told me I couldn't do it). And this answer _still_ isn't "we're working on it." The last thing from the previous round was layout libraries. What I heard you saying was "You don't really want that anyway", saying that layout programs were the answer. Those are insufficient - they require using to low a bandwidth device, can't adequately deal with system font changes, and don't provide end users enough flexibility. 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). Tags are easy to add afterwards. That's their biggest attraction. Ok, so I should have said "GREL tag" instead of "GREL flag". <mike -- It's been a hard day's night, Mike Meyer And I been working like a dog. mwm@pa.dec.com It's been a hard day's night, decwrl!mwm I should be sleeping like a log.
Jay@deepthot.UUCP (Jay Denebeim) (01/31/91)
In article <18011@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >In article <91023.105132GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: > >> - Edit gadget, Multiple line string gadgets, Bitmap edit gadget, An edit gadget would be very nice. One that handles proportional fonts and clipping and .... >> Jorrit Tyberghein > > Peter >-- > Peter Cherna, Software Engineer, Commodore-Amiga, Inc. > {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com >My opinions do not necessarily represent the opinions of my employer. >"Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!" -- |_o_o|\\ |. o.| || The Jay Denebeim | . | || Software | o | || Distillery | |// Address: mcnc!wolves!deepthot ====== BBS:(919)-460-7430 VOICE:(919)-460-6934
peter@cbmvax.commodore.com (Peter Cherna) (02/01/91)
In article <MWM.91Jan30172855@raven.pa.dec.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. > <mike Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (02/01/91)
In article <18376@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes:
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.
If it's on the list, then "we're working on it" is not an incorrect
statement. You are working on it - just not right now. Given that
you've got a limited number of people, and are trying to get a release
out the door, to infer that "we're working on it" means "we've got
someone writing code now" would be ludicrous.
In other words, a lot of things will improve when one large difficult
job is done.
In other words, "we're working on it."
No, you should have not made any inferences based on the absence of
reserved tags for the functionality you crave.
Actually, the inference wasn't based on the absence of flags or tags.
The inference was based on the response "that functionality is
insufficient" (aka "You don't want that") when I asked about them
being missing. Now, if it's insufficient and something you believe is
better is going to be made available, saying "That's insufficient;
we're going to give you something better" (aka "We're working on it")
is fine. If I ask what that "better" is and get told that you aren't
ready to reveal it; that's also fine. To be told that it's not
sufficient when it's obviously sufficient and necessary for the
problem at hand _isn't_ fine.
Being left alone in a dark tunnel is much worse than being in a dark
tunnel with the light at one end, even if you won't know whether the
light is a train or the end of the tunnel until you get there.
<mike
--
Tried to amend my carnivorous habits Mike Meyer
Made it nearly seventy days mwm@pa.dec.com
Loosing weight without speed decwrl!mwm
Eatin' sunflower seedspeter@cbmvax.commodore.com (Peter Cherna) (02/02/91)
In article <MWM.91Jan31143357@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >In article <18376@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >In other words, "we're working on it." Yes, based on your definition, we are. > No, you should have not made any inferences based on the absence of > reserved tags for the functionality you crave. > >Actually, the inference wasn't based on the absence of flags or tags. >The inference was based on the response "that functionality is >insufficient" (aka "You don't want that") when I asked about them >being missing. Here are your original words that raised this comment: 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. > <mike Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"
david@twg.com (David S. Herron) (02/02/91)
In article <17995@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > Have you ever noticed the size of the XWindows libraries (or programs >built that use those features?) Some XClocks are hundreds of K (just for a >clock). I think one was approaching a meg. Yeah, but look at what you buy in the size of Xt -- independance from particular display characteristics. -- independance between location of CPU use and display location. That is, the program can be anywhere on the network and the display(s) can be anywhere on the network. The Xt programmer doesn't particularly care. -- indepenance from particular communications protocols to reach the display. The Xt programmer also doesn't particularly care about what communications protocol is used between client & server. -- powerful (as powerful as can be in C) object system which allows you to extend existing objects in myriads of ways. GadTools only does the last. I say that Xt and GadTools are two (somewhat) different beasts and which shouldn't be directly compared. Indirect comparisons are fair. Also remember that Unix doesn't, at least not until fairly recently, have good support for shared libraries. Unlike AmigaDOS. This is one of the reasons that memory disappears faster on Unix than AmigaDOS. > That said, there is some stuff going on to provide more support for >applications (see the AppShell stuff from the June 1990 devcon notes for >more information) via extended objects, etc. Good .. > Remember: GadTools has to fit in the ROM. er.. do you have to fit *ALL* of GadTools into ROM? Don't you really just need to fit in enough to get the system running? -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- MS-DOS ... The ultimate computer virus.
jimm@amiga.UUCP (Jim Mackraz) (02/02/91)
(Mike (My Watch Has Windows) Meyer) writes: )(Peter Cherna) writes: ) Standard problem. Anything you write yourself and/or already use tends to ) be easier than something new. Anything it does better or different than ) the new thing seems (and sometimes is) harder in the new thing. ) )Especially when the things you wrote yourself were designed to deal )with a specific problem that wasn't dealt with in the new thing. It's )not that my tools are easier to use - it's that they solve what I see )as the hard problem, whereas GadTools doesn't address the problem, and )prevents me from applying my old solutions. Is there a mystery here? GadTools doesn't solve all the problems you wanted solved? I think you're wandering a little off-base here, Mike. I'm having a hard time seeing that you have made peace with the basic concept that GadTools solves the problems it was required for, but not all the world's problems. However, it's designed to be fixable/extensible. Almost all the complaints I see below are you making presumptions about C='s view of the thing, and your being upset that certain functionality isn't present. C= engineers have reminded you that resources are limited, and that they tried to accomplish the most essential functionality, while preserving extensibility, but your followup makes me wonder if you've thought that through. ) Relative gadgets are both hard to support and insufficient... )I hear you saying "You don't really want that anyway". This is _not_ )the same answer as "we're working on it". I hear Peter saying that he wants to provide a better solution to the layout problem than just that junky GREL... stuff. He might have gotten some of that from me. Implying that he's punting the problem is unfair and untrue. )With GadTools, how do I keep )a gadget 5 pixels from the right edge of the window as the user )resizes the window? Your problem with GREL has a fairly simple )solution (and a trivial solution using the tools I designed). GadTools )makes the solution harder to apply to either problem, if it doesn't )make it insoluble. Use your own gadgets for now, or use GadTools in simpler situations. Big deal? ) Moving gadgets are hard, too. ) )Actually, moving Intuition gadgets is easy - I do it all the time. )Moving GadTools gadgets is impossible (at least you told me I couldn't )do it). And this answer _still_ isn't "we're working on it." I hope they don't waste too much time worrying about moving gadgets. I'm glad you can do them, and you can encapsulate them into a whole range of boopsi gadget classes with a new MoveGadget method if you want. But that's far from essential. You don't need moving gadgets to do an Interface Builder. (Moving boopsi images, maybe...) )The last thing from the previous round was layout libraries. What I )heard you saying was "You don't really want that anyway", saying that )layout programs were the answer. Those are insufficient - they require )using to low a bandwidth device, can't adequately deal with system )font changes, and don't provide end users enough flexibility. If Peter thinks that run-time layout isn't important, then I disagree with him on that. I doubt it though. I don't know if layout should go in a library or where, though. I'm also interested in what you think the layout "solution" is. I know it to be a very hard problem, one I would have liked to have had the luxury of time, romspace, and assistants to solve ... )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). I don't think there's much of a requirement to make sure you hear the version of the words you want to hear. I think Peter has made it very clear that GadTools implements a set of prioritized functionality choices. Difficult choices... When he explains why he thinks the functionality is fundamental, and why he thinks that some missing pieces shouldn't be sorely missed, are you presuming that they're not working on improvements for the future? I strongly approve of not littering gadtools with features that will make it harder for it to evolve to a better toolkit. If your frustration is that gadtools isn't complete, boopsi-integrated, and perfect, I'm sure your frustration is shared by the rest of us who had to deal with the real constraints on this OS release. Your insensitivity to matters of such constraints makes me wonder whether you've experienced such things firsthand... ) Tags are easy to add afterwards. That's their biggest attraction. ) )Ok, so I should have said "GREL tag" instead of "GREL flag". I'd prefer a "LAYOUT_" set of tags... GREL_ blows. But the point is that GadTools interface is *extensible*, "I read in your words" that you miss that point, but I'd hope you actually don't. As I read *your* words, they seem to be either a frustration that not everything important got implemented, or a presumption that problems you consider important aren't being worked on. I think you might improve your perspective in either case. As an aside, I'll confess that my original suggestion for GadTools was that it be just sufficient for doing the Prefs editors or other in-house utilities, and not made public until it was more complete and boopsi-integrated. That would have definitely cleaned up the interface (less behind-the-back processing of messages, no "fake" composite gadgets), and made for even fewer problems with extensibility/compatibility problems in the future (i.e., near zero). Would you have preferred that (i.e., nothing)? I think it's better this way, providing people don't violate the "black-box" intent and make a whole new generation of the nasty compatibility hacks that I, and now Peter, have been fighting with to make progress over the last few years... Barring compatibilty problems, the only remaining difficulty is when people want more more more. That's understandable, people always want more from the OS, but the difficult and hard-thought decisions about what level of support fits in best today vs. tomorrow don't deserve this disparagement. So, don't hold GadTools up to Interface Builder and diminish it. Perhaps the best way to look at missing toolkit functionality is as a "market opportunity". jimm -- --- opinions expressed herein are my own. --- "... Because they can." - profound punchline to joke about dogs