HelpSystem in core vs. external package
Locked
HelpSystem in core vs. external package
 
|
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 [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
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). 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. The same could apply to the Keyboard Shortcuts, Useful Expressions, and packages specific help. Then, my vote is to have an integrated Help System on the image (of course unloadable to permit a good shrink via #reduceCuis). -- Sincerely, Germán Arduino about.me/garduino 2013/1/25 Casey Ransberger <[hidden email]>: > 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 > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: HelpSystem in core vs. external package
|
|
Inline.
On Jan 25, 2013, at 2:04 PM, Germán Arduino <[hidden email]> 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 <[hidden email]>: >> 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 >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: HelpSystem in core vs. external package
|
|
Hello Casey
On 1/25/13, Casey Ransberger <[hidden email]> wrote: > Inline. > > On Jan 25, 2013, at 2:04 PM, Germán Arduino <[hidden email]> 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.. pages. And no executable code, i.e no right-click menu with 'do it'. One of the major advantages of Smalltalk is that you can build a "GUI" just by presenting executable text is lost. Anyhow the text for WebClient is good but it can be presented just in a regular README.md with subtitles without problems. 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++!) You can do that as well if you call the right method. :-) >> 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. Yes. >> The same could apply to the Keyboard Shortcuts, Useful Expressions, >> and packages specific help. We already have this in Cuis. And as written above, the code in 'useful expressions' is executable. In Squeak BTW the 'Useful Expressions' entry is not in Torsten's help system either, though it is in the help menu. > 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 I'd say put it into a github repository as of now. If Juan integrates it then you later can delete that repository again, no problem. Pharo uses it a bit more than Squeak, see attached screen shot. But still the fact that code is not executable is a clear regression. Regards Hannes _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
HelpSystemInPharo2.0.png (55K)
Re: HelpSystem in core vs. external package
|
|
P.S. the keyboard shortcuts work in the help system
e.g. ALT-D for 'do it' in Windows ALT-B for 'browse class' And I see one of the main advantages of the help system that it allows to include 'Readme' type of information in the package files as such and it gets displayed in help system automatically. And it is simple. -- Hannes On 1/26/13, H. Hirzel <[hidden email]> wrote: > Hello Casey > > On 1/25/13, Casey Ransberger <[hidden email]> wrote: >> Inline. >> >> On Jan 25, 2013, at 2:04 PM, Germán Arduino <[hidden email]> 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. > > Yes, it is. But it is only plain text. And no hyperlinks between > pages. And no executable code, i.e no right-click menu with 'do it'. > One of the major advantages of Smalltalk is that you can build a "GUI" > just by presenting executable text is lost. > > Anyhow the text for WebClient is good but it can be presented just in > a regular README.md with subtitles without problems. > > > > 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++!) > > You can do that as well if you call the right method. :-) > >>> 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. > > Yes. > >>> The same could apply to the Keyboard Shortcuts, Useful Expressions, >>> and packages specific help. > > We already have this in Cuis. And as written above, the code in > 'useful expressions' is executable. In Squeak BTW the 'Useful > Expressions' entry is not in Torsten's help system either, though it > is in the help menu. > > >> 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 > > I'd say put it into a github repository as of now. If Juan integrates > it then you later can delete that repository again, no problem. > > Pharo uses it a bit more than Squeak, see attached screen shot. But > still the fact that code is not executable is a clear regression. > > Regards > Hannes > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: HelpSystem in core vs. external package
|
|
In reply to this post by Casey Ransberger-2
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 > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
+1
2013/1/26 Juan Vuletich <[hidden email]>: > 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 >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: HelpSystem in core vs. external package
|
|
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 <[hidden email]> wrote: +1 Casey Ransberger _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: HelpSystem in core vs. external package
|
|
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 <[hidden email] > <mailto:[hidden email]>> wrote: > > +1 > > 2013/1/26 Juan Vuletich <[hidden email] > <mailto:[hidden email]>>: > > 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 > >> [hidden email] <mailto:[hidden email]> > >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > >> > > > > > > > > _______________________________________________ > > Cuis mailing list > > [hidden email] <mailto:[hidden email]> > > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > _______________________________________________ > Cuis mailing list > [hidden email] <mailto:[hidden email]> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > > -- > Casey Ransberger > ------------------------------------------------------------------------ > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: HelpSystem in core vs. external package
|
|
Oops. The class I was saying was missing was actually PluggableTreeMorph, which seems to have replaces HierarchicalListMorph in the other dialects.
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.
On Sun, Jan 27, 2013 at 7:21 AM, Juan Vuletich <[hidden email]> wrote: Hi Casey, Casey Ransberger _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: HelpSystem in core vs. external package
|
|
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 <[hidden email] > <mailto:[hidden email]>> 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 > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> wrote: > > +1 > > 2013/1/26 Juan Vuletich <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>>: > > > 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 > >> [hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>> > > >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > >> > > > > > > > > _______________________________________________ > > Cuis mailing list > > [hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>> > > > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > _______________________________________________ > Cuis mailing list > [hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>> > > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > > -- > Casey Ransberger > ------------------------------------------------------------------------ > > _______________________________________________ > Cuis mailing list > [hidden email] <mailto:[hidden email]> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > > _______________________________________________ > Cuis mailing list > [hidden email] <mailto:[hidden email]> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > > -- > Casey Ransberger > ------------------------------------------------------------------------ > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: HelpSystem in core vs. external package
|
|
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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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 >> <[hidden email] <mailto:[hidden email]> >> <mailto:[hidden email] <mailto:[hidden email]>>> wrote: >> >> +1 >> >> 2013/1/26 Juan Vuletich <[hidden email] >> <mailto:[hidden email]> >> <mailto:[hidden email] <mailto:[hidden email]>>>: >> >> > 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 >> >> [hidden email] <mailto:[hidden email]> >> <mailto:[hidden email] <mailto:[hidden email]>> >> >> >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> >> > >> > >> > >> > _______________________________________________ >> > Cuis mailing list >> > [hidden email] <mailto:[hidden email]> >> <mailto:[hidden email] <mailto:[hidden email]>> >> >> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> _______________________________________________ >> Cuis mailing list >> [hidden email] <mailto:[hidden email]> >> <mailto:[hidden email] <mailto:[hidden email]>> >> >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> >> >> >> -- Casey Ransberger >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Cuis mailing list >> [hidden email] <mailto:[hidden email]> >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> >> >> _______________________________________________ >> Cuis mailing list >> [hidden email] <mailto:[hidden email]> >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> >> >> >> -- >> Casey Ransberger >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |