Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: GadTools functionality
Message-ID: <6354@amiga.UUCP>
Date: 1 Feb 91 19:55:29 GMT
References: <MWM <18312@ <MWM.91Jan30172855@raven.pa.dec.com>
Organization: I and I Computing, Palo Alto, CA
Lines: 142

(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