Fun with ProfStef

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 <[hidden email]>
> > >
> > > > 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
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Thu, Jan 28, 2010 at 10:13 PM, Danny Chan <[hidden email]> 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 <[hidden email]>
> > >
> > > > 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
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Am Donnerstag, 28. Januar 2010 21:20:00 schrieb Mariano Martinez Peck:

> 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.

I have a secret (well, now not so secret) agenda. I want a help system that
allows me to learn all the cool stuff I don't know, and where developers of
great software are asked immediately 'Hey, sounds great, but where is the
tutorial?'. So that people like me, who are not really software developers,
can start using this stuff, too.

> - I found a little bug in the UI. If you double click on a lesson, a
> debugger comes. Can you reproduce it ?

Yes, I am still learning how to work with Morphic in general and this
TreeMorph in particular

>
> - Maybe you can integrate this in "Tools -> More -> ProfStef Tutorials"

How?

>
> - For Pharo 1.0 release, I will include the workspace version (the old one)
> as I don't want to incorporate new stuff.

Very wise. I wouldn't want to include new stuff by someone who committed
himself to really learn Smalltalk only a few weeks ago for my welcome screen.

Cheers, Danny

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi!

As discussed I've added a new repository ProfStefBrowser and uploaded a
version which builds on top of the current ProfStef version from Laurent
without touching the code in the ProfStef package.

> - I found a little bug in the UI. If you double click on a lesson, a
> debugger comes. Can you reproduce it ?

I think I found out why this happens. Apparently, when you double click on an
item, the item is deselected. The callback that is called in this case
receives as the item which was clicked nil. I added a workaround, but since
the callback is set using a message 'setSelectedSelector:' I personally feel
that this behaviour is not intuitive and that this callback shouldn't be
called at all when deselecting items. Who are the guys to talk to for this
behaviour?

Danny

Am Freitag, 29. Januar 2010 15:38:58 schrieb Mariano Martinez Peck:

> On Fri, Jan 29, 2010 at 3:33 PM, Danny Chan <[hidden email]> wrote:
> > Hi!
> >
> > As discussed I've added a new repository ProfStefBrowser and uploaded a
> > version which builds on top of the current ProfStef version from Laurent
> > without touching the code in the ProfStef package.
>
> Cool. Just be aware that you don't need to create a separete repository for
> that. You can have more than 1 package in a repository. Then, you can have
> the ProStef repository, where inside you have different packages like
> ProfStef core (Laurent) and ProfStefBrowser. This is easier because you
>  have all together in the same repository.
>

Ah, understand. I was confused by packages vs repositories. I will copy the
packages to the ProfStef repository.

Danny

Hi Dale

> In putting together a couple of ProfStef tutorials last weekend, I found
>  that I'd like to be able to #goto a lesson (out of sequence), essentially
>  hitting a branch point where the student can skip a set of lessons or move
>  to a different set of lessons. My thought was something like:
>
>   ProfStef goto: #lesson15 "jump to lesson15"

We have now split the GUI changes I did into a separate package
ProfStefBrowser. In this I have something like this

ProfStefBrowser goto: SmalltalkSyntaxTutorial lessonAt: 3

This is used to replace the current lesson when I click in the tutorial tree.
I just checked, and if I move three methods up the hierarchy, it works exactly
the same in the ProfStef core.

Laurent, if you like this, can we move this into ProfStef core? Then people do
not have to work with a different interface and tutorials written for ProfStef
will work exactly the same in the GUI browser.

Danny

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Dale

> In putting together a couple of ProfStef tutorials last weekend, I found
>  that I'd like to be able to #goto a lesson (out of sequence), essentially
>  hitting a branch point where the student can skip a set of lessons or move
>  to a different set of lessons. My thought was something like:
>
>   ProfStef goto: #lesson15 "jump to lesson15"

We have now split the GUI changes I did into a separate package
ProfStefBrowser. In this I have something like this

ProfStefBrowser goto: SmalltalkSyntaxTutorial lessonAt: 3

This is used to replace the current lesson when I click in the tutorial tree.
I just checked, and if I move three methods up the hierarchy, it works exactly
the same in the ProfStef core.

Laurent, if you like this, can we move this into ProfStef core? Then people do
not have to work with a different interface and tutorials written for ProfStef
will work exactly the same in the GUI browser.

Danny

Welcome ProfStef-Core and ProfStef-Tests !

----- "laurent laffont" <[hidden email]> wrote:
|
| Hi,
|
| isn't it quite complex ? One can do:
| 3 timesRepeat: [ProfStef next].
|
| Less to type, Smalltalkish, and maybe more fun ?
|

Laurent,

The #goto: style allows one to label a lesson ... #timesRepeat: fails if I reorder the lessons.

I apologize for using #goto:, but my first language was FORTRAN:)

I think that #call: or #jumpTo: or maybe #lesson: would work just as well without being heretical...

Dale

----- "laurent laffont" <[hidden email]> wrote:
|
| Hi,
|
| isn't it quite complex ? One can do:
| 3 timesRepeat: [ProfStef next].
|
| Less to type, Smalltalkish, and maybe more fun ?
|

Laurent,

The #goto: style allows one to label a lesson ... #timesRepeat: fails if I reorder the lessons.

I apologize for using #goto:, but my first language was FORTRAN:)

I think that #call: or #jumpTo: or maybe #lesson: would work just as well without being heretical...

Dale

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project