January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fun with ProfStef

by laurent laffont

On Thu, Jan 28, 2010 at 10:13 PM, Danny Chan <chan_dhf(a)yahoo.de> wrote: > Hi Laurent! > > I see your point. It is definitely a good idea to keep the core ProfStef as > simple as possible. Right now ProfStef itself can serve as a simple > application to begin exploring the language, so that even a dummy like me > has > a chance to understand it. Maybe it is a good idea to create a new package > that builds on the ProfStef core application you wrote, call it > ProfStefCenter > or something, and add additional functionality there? That way ProfStef > itself > would stay simple and be in the spirit of a playful introduction to > Smalltalk, > and a full fledged interactive help and tutorial system could evolve from > there. > > Cheers, Danny > Mariano has just suggested to create 3 separate packages 1) ProfStefBrowser 2) ProfStefCore 3) ProfStenTests so 2 + 3 = current stable version, and put all the GUI stuff in 1. Would you like to create ProfStefBrowser ? Laurent > > Am Donnerstag, 28. Januar 2010 20:45:35 schrieb laurent laffont: > > Hi Danny, > > > > > I have pushed a version to Monticello that has a bit of a GUI with > nicer > > > navigation, see the screenshot. I did not find out how to place the > > > buttons better, and I don't know how to tell the tree morph to select > > > another entry when I navigate through the lessons using the buttons or > > > the workspace contents. Please tell me what you think about this. Since > I > > > know how little Smalltalk I really know, I certainly managed to destroy > > > something, so please > > > have a look and tell me what to do better. > > > > The GUI you write is great, it push ProfStef from an interactive tutorial > > to an integrated help system. > > > > But :) I think we should keep the idea of the interactive tutorial (the > > basic LessonView) using ProfStef go. Because ProfStef go is a little > game, > > it must be attractive, funny. I like the idea of ProfStef which talk to > the > > user and interact. My inspiration was http://tryruby.org/ > > > > So IMHO you should put all your changes in a new class, like > > TutorialBrowser. So we will have: > > - "ProfStef go" for the interactive tutorial > > - "TutorialBrowser open" for the pseudo-help system. > > > > This way we can keep existing classes clean. > > > > And take care of unit tests and class comments :) . > > > > > > Cheers, > > > > Laurent > > > > > Here are a few ideas I've had, which I as a relative beginner would > find > > > really > > > neat in an interactive tutorial application. As time allows, I would > try > > > to implement at least some of the points below: > > > > > > - Clickable items in the text window. So that a tutorial writer could > for > > > example write something like this: > > > <code>SystemWindow new openInWorld</code> > > > , and the code together with a button saying 'doit' would appear. So in > > > principle a markup language for interactive tutorials which adds a bit > of > > > interesting short cut functionality and eye candy to the tutorial. > > > > > > - Tabbed browsing for having several tutorials opened at the same time > > > > > > - A button saying 'save lesson', that overwrites the appropriate method > > > with > > > the current state of the workspace; users can annotate the tutorial > with > > > their > > > own notes or experiments; also the ability to add additional lessons > > > > > > - A button to push the current tutorial with all the additional > > > annotations to > > > a Monticello repository, from which future versions for everyone can be > > > generated. Wiki for interactive tutorials! > > > > > > - Some additional functionality to generate a whole new tutorial from > > > within > > > the tutorial browser > > > > > > - (Semi-)Automatic update of tutorials > > > > > > - And, of course, many, many tutorials. Wouldn't it be great to have a > > > tutorial for all the important and interesting aspects of a system, and > > > even > > > for every additional package you download? With the system Laurent > > > designed, > > > writing a tutorial is only so very slightly harder than writing example > > > classes and methods, but so much more expressive and approacheable for > > > someone > > > new. > > > > > > Cheers, Danny > > > > > > Am Mittwoch, 27. Januar 2010 19:00:25 schrieb laurent laffont: > > > > 2010/1/27 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > > > > > > > I forgot to ask.... > > > > > > > > > > Does the DEVImageWorkspaces openGettingStartedWorkspace still > make > > > > > sense having ProfStef ? > > > > > > > > > > Can you take a look and "merge" it to ProfStef if there is > something > > > > > > cool > > > > > > > > not included by Stef ? :) > > > > > > > > > > I would like to have only one reference form the Pharo welcome > > > > > > workspace. > > > > > > > > Thanks > > > > > > > > > > Mariano > > > > > > > > I agree for merging > > > > > > > > I will put these snippets from getting started in ProfStef: > > > > 42 explore > > > > Date today explore > > > > 'abc' asUppercase. > > > > 'Hello World' reverse. > > > > > > > > There's cool comments too. > > > > > > > > I put global Read & Write on ProfStef so everybody can destroy it :) > > > > > > > > > > > > Laurent > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 28, 2010

Re: [Pharo-project] Fun with ProfStef

by Danny Chan

Hi Laurent! I see your point. It is definitely a good idea to keep the core ProfStef as simple as possible. Right now ProfStef itself can serve as a simple application to begin exploring the language, so that even a dummy like me has a chance to understand it. Maybe it is a good idea to create a new package that builds on the ProfStef core application you wrote, call it ProfStefCenter or something, and add additional functionality there? That way ProfStef itself would stay simple and be in the spirit of a playful introduction to Smalltalk, and a full fledged interactive help and tutorial system could evolve from there. Cheers, Danny Am Donnerstag, 28. Januar 2010 20:45:35 schrieb laurent laffont: > Hi Danny, > > > I have pushed a version to Monticello that has a bit of a GUI with nicer > > navigation, see the screenshot. I did not find out how to place the > > buttons better, and I don't know how to tell the tree morph to select > > another entry when I navigate through the lessons using the buttons or > > the workspace contents. Please tell me what you think about this. Since I > > know how little Smalltalk I really know, I certainly managed to destroy > > something, so please > > have a look and tell me what to do better. > > The GUI you write is great, it push ProfStef from an interactive tutorial > to an integrated help system. > > But :) I think we should keep the idea of the interactive tutorial (the > basic LessonView) using ProfStef go. Because ProfStef go is a little game, > it must be attractive, funny. I like the idea of ProfStef which talk to the > user and interact. My inspiration was http://tryruby.org/ > > So IMHO you should put all your changes in a new class, like > TutorialBrowser. So we will have: > - "ProfStef go" for the interactive tutorial > - "TutorialBrowser open" for the pseudo-help system. > > This way we can keep existing classes clean. > > And take care of unit tests and class comments :) . > > > Cheers, > > Laurent > > > Here are a few ideas I've had, which I as a relative beginner would find > > really > > neat in an interactive tutorial application. As time allows, I would try > > to implement at least some of the points below: > > > > - Clickable items in the text window. So that a tutorial writer could for > > example write something like this: > > <code>SystemWindow new openInWorld</code> > > , and the code together with a button saying 'doit' would appear. So in > > principle a markup language for interactive tutorials which adds a bit of > > interesting short cut functionality and eye candy to the tutorial. > > > > - Tabbed browsing for having several tutorials opened at the same time > > > > - A button saying 'save lesson', that overwrites the appropriate method > > with > > the current state of the workspace; users can annotate the tutorial with > > their > > own notes or experiments; also the ability to add additional lessons > > > > - A button to push the current tutorial with all the additional > > annotations to > > a Monticello repository, from which future versions for everyone can be > > generated. Wiki for interactive tutorials! > > > > - Some additional functionality to generate a whole new tutorial from > > within > > the tutorial browser > > > > - (Semi-)Automatic update of tutorials > > > > - And, of course, many, many tutorials. Wouldn't it be great to have a > > tutorial for all the important and interesting aspects of a system, and > > even > > for every additional package you download? With the system Laurent > > designed, > > writing a tutorial is only so very slightly harder than writing example > > classes and methods, but so much more expressive and approacheable for > > someone > > new. > > > > Cheers, Danny > > > > Am Mittwoch, 27. Januar 2010 19:00:25 schrieb laurent laffont: > > > 2010/1/27 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > > > > > I forgot to ask.... > > > > > > > > Does the DEVImageWorkspaces openGettingStartedWorkspace still make > > > > sense having ProfStef ? > > > > > > > > Can you take a look and "merge" it to ProfStef if there is something > > > > cool > > > > > > not included by Stef ? :) > > > > > > > > I would like to have only one reference form the Pharo welcome > > > > workspace. > > > > > > Thanks > > > > > > > > Mariano > > > > > > I agree for merging > > > > > > I will put these snippets from getting started in ProfStef: > > > 42 explore > > > Date today explore > > > 'abc' asUppercase. > > > 'Hello World' reverse. > > > > > > There's cool comments too. > > > > > > I put global Read & Write on ProfStef so everybody can destroy it :) > > > > > > > > > Laurent > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 28, 2010

Re: [Pharo-project] Monticello diff between chosen revisionsisbroken

by Mariano Martinez Peck

http://code.google.com/p/pharo/issues/detail?id=1890 2010/1/28 Gary Chambers <gazzaguru2(a)btinternet.com> > It is on the "wish list"... has been for some time now. Having had a look > in light of recent thread I believe it will be possible. > > Regards, Gary > > ----- Original Message ----- > *From:* Mariano Martinez Peck <marianopeck(a)gmail.com> > *To:* Pharo-project(a)lists.gforge.inria.fr > *Sent:* Tuesday, January 26, 2010 12:40 PM > *Subject:* Re: [Pharo-project] Monticello diff between chosen > revisionsisbroken > > > > On Tue, Jan 26, 2010 at 8:58 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> gary what would be great is to have a label on top of the two methods >> shown >> I never now what I'm reading >> >> Incoming InWorkingCopy >> New Current >> >> would be so great! >> >> > And if you do it also in the merge, it would be a dream :) > > >> Stef >> >> >> >> On Jan 25, 2010, at 7:25 PM, Gary Chambers wrote: >> >> > Yes, in this case it is a bug with Polymorph. >> > >> > Try with >> > >> > MCVersionInspector>>changes >> > "Open a patch morph for the changes." >> > >> > self viewChanges: self version changes >> > >> > >> > Hopefully no bad side-effects... >> > >> > With a bit more work it may be possible to show both versions between >> which the changes apply (unlike the old MC tools) ;-) >> > >> > Regards, Gary >> > ----- Original Message ----- >> > From: Gary Chambers >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Sent: Monday, January 25, 2010 6:05 PM >> > Subject: Re: [Pharo-project] Monticello diff between chosen >> revisionsisbroken >> > >> > >> > MCVersionInspector>>diff >> > | ancestorVersion | >> > self pickAncestor ifNotNil: >> > [:ancestor | >> > ancestorVersion := self version workingCopy repositoryGroup >> versionWithInfo: ancestor. >> > (self version asDiffAgainst: ancestorVersion) open] >> > >> > >> > Regards, Gary >> > ----- Original Message ----- >> > From: Gary Chambers >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Sent: Monday, January 25, 2010 5:50 PM >> > Subject: Re: [Pharo-project] Monticello diff between chosen >> revisionsisbroken >> > >> > Needs looking at since it is confusing. IIRC the Diff button creates a >> .mcd file of the changes between some versions... >> > >> > Regards, Gary >> > ----- Original Message ----- >> > From: Mariano Martinez Peck >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Sent: Monday, January 25, 2010 5:34 PM >> > Subject: Re: [Pharo-project] Monticello diff between chosen >> revisionsisbroken >> > >> > >> > >> > 2010/1/25 Gary Chambers <gazzaguru2(a)btinternet.com> >> > The "Diff" button on the Monticello repository browser does what its >> balloon help says... >> > >> > 'Create an equivalent version based on an earlier release'. This is a >> diff version. I never use them as they can be confusing :-) >> > >> > >> > Ok...I never used before...but something is clear: the second ask about >> a version, has no sense, and even is wrong if it compares to the last >> version. See step 6 of Stefan. Then, we have to options: >> > >> > - Or we remove that second prompt, as it always will use the last >> version >> > - Or we change the diff implementation so that it uses the selected >> version instead of the last. >> > >> > What do you think ? >> > >> > Does someone really know what this "diff" should do ? >> > >> > Cheers >> > >> > Mariano >> > >> > If you want to compare two existing versions you should: >> > >> > 1. Open Monticello Browser >> > 2. Select a repo >> > 3. click open >> > 4. Select a revision, not the latest one >> > 5. Click HISTORY >> > >> > 6. chose an ancestor from the list >> > >> > >> > Regards, Gary >> > ----- Original Message ----- >> > From: Mariano Martinez Peck >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Cc: Lukas Renggli >> > Sent: Sunday, January 24, 2010 12:59 PM >> > Subject: Re: [Pharo-project] Monticello diff between chosen revisions >> isbroken >> > >> > >> > >> > On Sat, Jan 23, 2010 at 9:51 PM, Stefan Marr <pharo(a)stefan-marr.de> >> wrote: >> > Hi: >> > >> > In the current dev image (10508), Monticello is broken with respect to >> showing the differences of between chosen revisions. >> > >> > However, that seems to be broken already in 10496. (and maybe earlier) >> > >> > To reproduce: >> > >> > 1. Open Monticello Browser >> > 2. Select a repo >> > 3. click open >> > 4. Select a revision, not the latest one >> > 5. Click diff >> > 6. chose an ancestor from the list >> > Now you got a window 'Version: ...5' >> > Saying (Diff against ...2) >> > Here I would expect the changes button to open a window showing the >> changes between the chosen revisions, but it always diffs against the latest >> version. >> > >> > >> > Yes, I could reproduce the problem. Can you open a ticket ? >> > >> > Maybe Lukas Monticello guru can help us ? hahaha >> > >> > Cheers >> > >> > Mariano >> > >> > >> > Best >> > Stefan >> > >> > -- >> > Stefan Marr >> > Software Languages Lab >> > Vrije Universiteit Brussel >> > Pleinlaan 2 / B-1050 Brussels / Belgium >> > http://soft.vub.ac.be/~smarr <http://soft.vub.ac.be/%7Esmarr> >> > Phone: +32 2 629 3956 >> > Fax: +32 2 629 3525 >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ------------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 28, 2010

[Pharo-project] video in Pharo

by laurent laffont

Hi, Is it possible to play a video in Pharo ? How ? I'm thinking about writing a Pharo interface to Pharocasts, maybe integrated to ProfStef. It can be funny. Laurent

Jan. 28, 2010

Re: [Pharo-project] Fun with ProfStef

by Alain Plantec

laurent laffont a Ã©crit : > Now, a ProfStef tutorial must subclass AbstractTutorial. Danny has > written a simple method to find all tutorials: > > AbstractTutorial class >> tutorials > ^self subclasses sortBy: [:a :b | > a name < b name]. > > Note that the class name is used to generate the tutorial title (like > in Rails). So: > HowToMakeYourOwnTutorial title ==> 'How To Make Your Own Tutorial' > > Laurent > ok, so, no need for registration or pragma then. thanks Alain

Jan. 28, 2010

Re: [Pharo-project] clarifying PopUpMenu vs. MenuMorph

by Mariano Martinez Peck

http://code.google.com/p/pharo/issues/detail?id=1889 On Thu, Jan 28, 2010 at 5:20 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > Sounds good. > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, January 26, 2010 10:00 AM > Subject: [Pharo-project] clarifying PopUpMenu vs. MenuMorph > > > > Hi all > > > > I was reading a bit squeak and PopUpMorph is only used in MVCUiManager. > > So this reminded me that we should > > - replace PopUpMenu by UIManager default... > > - UIManager... uses MenuMorph > > - Remove PopUpMenu > > - funnel some MenuMorph usage to UIManager default. > > > > What the ui guys think? > > > > > > Stef > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 28, 2010

Re: [Pharo-project] What happens with new preferences?

by Alain Plantec

Mariano Martinez Peck a Ã©crit : > Hi Alain. I have a simple question. I know you migrated all > preferences from 1.0 to 1.1 to your new cool scheme. > > Now....what happened with the new preferences that we crated in 1.0 > since you did the migration ? Is there a list of "pending" > migrations so that we are aware to put them then in 1.1 ? > > Right now I remember two: > > - Enable/disable the update stream > > - Use old / new NetNameResolver. > > Cheers In 1.1, just open the old preference browser (Tools/More.../Preference Browser). new preferences should appear in white rows (the others, I mean the old one, are in blue (kept but no setting) or in green (kept with a setting)) Cheers Alain > > Mariano > ------------------------------------------------------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 28, 2010

Re: [Pharo-project] Fun with ProfStef

by laurent laffont

Now, a ProfStef tutorial must subclass AbstractTutorial. Danny has written a simple method to find all tutorials: AbstractTutorial class >> tutorials ^self subclasses sortBy: [:a :b | a name < b name]. Note that the class name is used to generate the tutorial title (like in Rails). So: HowToMakeYourOwnTutorial title ==> 'How To Make Your Own Tutorial' Laurent > Each package can define each own tutorial entry point method like this: > AlgernonTutorial class>>MyCooooolTutorial > <tutorial> > bla bla bla > > then with: > (PragmaCollector filter: [:pragma | pragma keyword = 'tutorial']) reset > > you get all existing methods with a <tutorial> pragma. > > And no need to manage any registration/unregistration. > > > Cheers > Alain > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 28, 2010

Re: [Pharo-project] Fun with ProfStef

by StÃ©phane Ducasse

Looks cool! Stef On Jan 28, 2010, at 8:27 PM, Danny Chan wrote: > Hi all! > I have pushed a version to Monticello that has a bit of a GUI with nicer > navigation, see the screenshot. I did not find out how to place the buttons > better, and I don't know how to tell the tree morph to select another entry > when I navigate through the lessons using the buttons or the workspace > contents. Please tell me what you think about this. Since I know how little > Smalltalk I really know, I certainly managed to destroy something, so please > have a look and tell me what to do better. > > Here are a few ideas I've had, which I as a relative beginner would find really > neat in an interactive tutorial application. As time allows, I would try to > implement at least some of the points below: > > - Clickable items in the text window. So that a tutorial writer could for > example write something like this: > <code>SystemWindow new openInWorld</code> > , and the code together with a button saying 'doit' would appear. So in > principle a markup language for interactive tutorials which adds a bit of > interesting short cut functionality and eye candy to the tutorial. > > - Tabbed browsing for having several tutorials opened at the same time > > - A button saying 'save lesson', that overwrites the appropriate method with > the current state of the workspace; users can annotate the tutorial with their > own notes or experiments; also the ability to add additional lessons > > - A button to push the current tutorial with all the additional annotations to > a Monticello repository, from which future versions for everyone can be > generated. Wiki for interactive tutorials! > > - Some additional functionality to generate a whole new tutorial from within > the tutorial browser > > - (Semi-)Automatic update of tutorials > > - And, of course, many, many tutorials. Wouldn't it be great to have a > tutorial for all the important and interesting aspects of a system, and even > for every additional package you download? With the system Laurent designed, > writing a tutorial is only so very slightly harder than writing example > classes and methods, but so much more expressive and approacheable for someone > new. > > Cheers, Danny > > > Am Mittwoch, 27. Januar 2010 19:00:25 schrieb laurent laffont: >> 2010/1/27 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >>> I forgot to ask.... >>> >>> Does the DEVImageWorkspaces openGettingStartedWorkspace still make >>> sense having ProfStef ? >>> >>> Can you take a look and "merge" it to ProfStef if there is something cool >>> not included by Stef ? :) >>> >>> I would like to have only one reference form the Pharo welcome workspace. >>> >>> Thanks >>> >>> Mariano >> >> I agree for merging >> >> I will put these snippets from getting started in ProfStef: >> 42 explore >> Date today explore >> 'abc' asUppercase. >> 'Hello World' reverse. >> >> There's cool comments too. >> >> I put global Read & Write on ProfStef so everybody can destroy it :) >> >> >> Laurent >> > <ProfStef.jpeg>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 28, 2010

Re: [Pharo-project] Fun with ProfStef

by Alain Plantec

Mariano Martinez Peck a Ã©crit : > Danny: You don't have an idea of how much important this is for the > Pharo community. Having good documentation, tutorials and so on, is a > KEY aspect from my point of view. So thanks to Laurent for the > initiative and you for the work too. yes!! + 1000 > > Algernon class >> initialize > ProfStef registerNewTutorial: self algernonTutorial. > > ProfStef registerNewTutorial: aTutorial > self addTutorial: aTutorial > > or something like that... But this kind of registration can be problematic. Maybe a pragma could be useful here. It gives the possibility to discover on the fly all existing tutorials when the ui is opened. Something like this: Each package can define each own tutorial entry point method like this: AlgernonTutorial class>>MyCooooolTutorial <tutorial> bla bla bla then with: (PragmaCollector filter: [:pragma | pragma keyword = 'tutorial']) reset you get all existing methods with a <tutorial> pragma. And no need to manage any registration/unregistration. Cheers Alain

Jan. 28, 2010