[Cuis] HelpSystem in core vs. external package

Casey Ransberger casey.obrien.r at gmail.com
Fri Jan 25 15:27:58 CST 2013


So I'm looking at a design decision.

Either I port the package on squeaksource (which I take it is the Pharo
version) as an external package, or...

???

I'd honestly love to have HelpSystem in "the image we ship." Which is
currently the "core" but doesn't always have to be. I don't want to go all
the way back down that rabbit hole today, though, so I'm going to try to be
on topic here.

I think having a help menu actually *is* a creature comfort that's worth
investing in. One could argue that "no one ever looks up help" but that's
just because they're literate, in the conventional sense of "computer
literacy" which basically boils down to knowing how to surf the web, and
use Excel and Word; as such, one could also argue that most people aren't
doing crazy advanced stuff like navigating an object-soup, or especially
doing open-heart surgery on an object-soup.

HelpSystem is small enough, and Torsten seems willing to take changes, that
we could probably keep it in core and still keep it up to date.

Anyhow, I'd like a show of hands about whether or not I should aim for
internal or external. I'm raising my hand in favor of internal, which isn't
something I do lightly (for the record!)

The main decision is whether or not to replace PluggableListMorph with
HierarchicalListMorph and call it a fork (something I'd be more likely to
do if we integrated it) or map the APIs onto the Cuis Pharo-compat lib
(which I would *only* do if HelpSystem remained external [we don't have
Pharo-compat in the core.])

Let me know what I should shoot for, folks.

-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130125/eb50a943/attachment-0001.html>


More information about the Cuis mailing list