[Cuis] HelpSystem in core vs. external package

[Casey Ransberger]

Inline. 

On Jan 25, 2013, at 2:04 PM, Germán Arduino <garduino at gmail.com> wrote:

> Hi Casey:
> 
> I tend to think in external packages to not bloat Cuis itself, but
> .... currently we have several text editor windows with help opened at
> start (that I close as my first operation in a new image).

Indeed. Code ought to give a big bang for the buck to go in. That said, after reviewing Torsten's code, I'm pleased. It's pretty clean, and small. I wonder how many source lines of code e.g. Windows Help is, given it does the same thing + hyperlinks, - the auto API docs (surely Windows/Visual Studio has some other thing which does that.) 

I bet there's at least an order of magnitude less code text to read, though that isn't saying much about complexity (we can move mountains in one line of Smalltalk code. Try doing that in C++!)

> Additionally, in my job of port WebClient, I had not ported the
> detailed help of the package because we have not the help system, and
> I think that this sort of help (as the included in the current text
> windows) is very useful and not only for newbies.

Yeah and Andreas really did a fantastic job of documenting WebClient using HelpSystem. I think part of why I glommed onto WebClient/Server had to do with his docs. They aren't long, but they're well written and make use of the library very easy. 

> The same could apply to the Keyboard Shortcuts, Useful Expressions,
> and packages specific help.

Not to mention that we could do a Terse Guide to Cuis (the Squeak terse guide is already in the help system, so we'd just have to curate it.)

> Then, my vote is to have an integrated Help System on the image (of
> course unloadable to permit a good shrink via #reduceCuis).

Oh yes! Documentation should always be unloadable when one wants a small image. 

+1

> -- 
> Sincerely,
> Germán Arduino
> about.me/garduino
> 
> 
> 2013/1/25 Casey Ransberger <casey.obrien.r at gmail.com>:
>> 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