[Cuis] HelpSystem in core vs. external package
Casey Ransberger
casey.obrien.r at gmail.com
Mon Jan 28 08:22:23 CST 2013
Honestly things would be easier if we used the tree morph that squeak uses. As far as pros and cons go, I will make a cursory analysis soon and report back to the list unless someone else does first.
I'm taking it easy right now, as I've had a nasty stomach flu for two days. It's kept me awake, so I've been able to get some work done (albeit with interruption,) but eventually all things end up equal and I've got to get some rest.
Cheers all, and here's to a brighter future! I mean fever!
Casey
On Jan 28, 2013, at 5:37 AM, Juan Vuletich <juan at jvuletich.org> wrote:
> Casey Ransberger wrote:
>> Oops. The class I was saying was missing was actually PluggableTreeMorph, which seems to have replaces HierarchicalListMorph in the other dialects.
>>
>
> Then you can compare them, form your opinion on them, and advice. We can:
> - Adapt any client code to use HierarchicalListMorph
> - Replace HierarchicalListMorph with PluggableTreeMorph
> - Include both of them
> - Make HierarchicalListMorph compatible with PluggableTreeMorph
> - Any other options?
>
>> I'm kind of exploring porting the latest version from squeaksource and the one from Squeak at the same time. Not sure which I'll keep. It seems like the bits on squeaksource have acquired a dependency on Polymorph which would be a pain to work around.
>
> Welcome to the joys of package porting. :)
>
> Cheers,
> Juan Vuletich
>
>> On Sun, Jan 27, 2013 at 7:21 AM, Juan Vuletich <juan at jvuletich.org <mailto:juan at jvuletich.org>> wrote:
>>
>> Hi Casey,
>>
>>
>> Casey Ransberger wrote:
>>
>> 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.
>>
>>
>> What is the "PluggableListMorph issue"? Cuis includes both
>> PluggableListMorph and HierarchicalListMorph.
>>
>> Maybe some protocol is incompatible with Squeak. If that's the
>> case, for code to be included in the base Cuis image, the
>> preferred solution would be to adapt the code to use Cuis' idioms.
>>
>> Cheers,
>> Juan Vuletich
>>
>> 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 <mailto:garduino at gmail.com>
>> <mailto:garduino at gmail.com <mailto:garduino at gmail.com>>> wrote:
>>
>> +1
>>
>> 2013/1/26 Juan Vuletich <juan at jvuletich.org
>> <mailto:juan at jvuletich.org>
>> <mailto:juan at jvuletich.org <mailto: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 <mailto:Cuis at jvuletich.org>
>> <mailto:Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>>
>>
>> >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>> >>
>> >
>> >
>> >
>> > _______________________________________________
>> > Cuis mailing list
>> > Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>> <mailto:Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>>
>>
>> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>> <mailto:Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>>
>>
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>>
>>
>> -- Casey Ransberger
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>>
>>
>> --
>> 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
More information about the Cuis
mailing list