[Cuis] HelpSystem in core vs. external package

[Casey Ransberger]

Alright then. I've spoken with Torsten about it, and he'll be glad to take
any changes we need upstream, so long as we don't degrade the user
experience on the other target platforms (i.e. Pharo and Squeak.)

One question: I don't know of a way deal with the PluggableListMorph issue
without overriding the method that uses it after loading it into Cuis,
except to create a dummy PluggableListMorph which maps the sends to the
actual HierarchicalListMorph class. In an external package, I'd probably go
that route, but in core it's a bit kludgy for my tastes.

Well, I guess we could implement the required protocol on
HierarchicalListMorph and create a global variable called
PluggableListMorph. That also seems kind of yucky. Using a global to solve
a problem seems like washing down chocolate with orange juice.

Probably what I'll do is make as many of the necessary changes as possible
in the upstream package, and then make the smallest possible changes inside
Cuis.

I bring this up hoping someone else has a better idea than the above.

On Sat, Jan 26, 2013 at 1:35 PM, Germán Arduino <garduino at gmail.com> wrote:

> +1
>
> 2013/1/26 Juan Vuletich <juan at jvuletich.org>:
> > Hi Casey,
> >
> > If the code is nice and small (I trust you), then let's integrate it in
> the
> > image. Having it at hand will encourage other people to use it to
> document
> > both external packages and core functionality.
> >
> > Cheers,
> > Juan Vuletich
> >
> > Casey Ransberger wrote:
> >>
> >> 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
> >> ------------------------------------------------------------------------
> >>
> >>
> >> _______________________________________________
> >> Cuis mailing list
> >> Cuis at jvuletich.org
> >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>
> >
> >
> >
> > _______________________________________________
> > Cuis mailing list
> > Cuis at jvuletich.org
> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130127/7b47cb8c/attachment-0002.html>