Help System

>> But it got loaded when I updated a core 1.1. Is this help system really
>> part of the Core?
>
> Yes, the help system is now part of the core to help documenting the
> system. It's also in Squeak trunk.
>
>> I suspect a duplication of effort between Glamour and HelpBrowser.
>
> No, I dont think so. The minimalistic HelpBrowser is too simple
> to make it dependent on Glamour. Otherwise you would have to
> bring Glamour into core or dev-images and rebase all kinds
> of browsers on it (Monticello Browser, Class browser, ...)
>
> The class "HelpBrowser" is like an interface so you can write
>
>  HelpBrowser open
>  HelpBrowser openOn: Integer
>
> and has only the minimal support to display the contents.
>
> We can easily implement a mechanism so that you can register another
> custom (enhanced/glamour based) help browser class that is loaded
> afterwards.
>
> I already have this in squeaksource/HelpSystem - have to merge
> tomorrow.
>
> Bye
> T.
>
>
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> +1
>
> Stef
>
> On May 3, 2010, at 9:05 PM, Torsten Bergmann wrote:
>
>>> But it got loaded when I updated a core 1.1. Is this help system  
>>> really
>>> part of the Core?
>>
>> Yes, the help system is now part of the core to help documenting the
>> system. It's also in Squeak trunk.
>>
>>> I suspect a duplication of effort between Glamour and HelpBrowser.
>>
>> No, I dont think so. The minimalistic HelpBrowser is too simple
>> to make it dependent on Glamour. Otherwise you would have to
>> bring Glamour into core or dev-images and rebase all kinds
>> of browsers on it (Monticello Browser, Class browser, ...)
>>
>> The class "HelpBrowser" is like an interface so you can write
>>
>> HelpBrowser open
>> HelpBrowser openOn: Integer
>>
>> and has only the minimal support to display the contents.
>>
>> We can easily implement a mechanism so that you can register another
>> custom (enhanced/glamour based) help browser class that is loaded
>> afterwards.
>>
>> I already have this in squeaksource/HelpSystem - have to merge
>> tomorrow.
>>
>> Bye
>> T.
>>
>>
>>
>> --
>> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>>
>> _______________________________________________
>> 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

> The class "HelpBrowser" is like an interface so you can write
>
>  HelpBrowser open
>  HelpBrowser openOn: Integer
>
> and has only the minimal support to display the contents.
>
> We can easily implement a mechanism so that you can register another
> custom (enhanced/glamour based) help browser class that is loaded
> afterwards.
>
> I already have this in squeaksource/HelpSystem - have to merge
> tomorrow.

> I think it is a design flaw that the help system doesn't make use of
> extensibility in the spirit of the new preference system, the
> extensible menus, or the metacello configurations. They all don't have
> external dependencies and load fine into any image.
>
> Being forced to have strong references to the HelpSystem package (with
> subclasses and class references) makes it impossible to just include
> some documentation into a package, without introducing a dependency
> onto the HelpSystem. This doesn't encourage me at all to provide some
> quick documentation (e.g. for Gofer, PetitParser, RB, OB, ...),
> because I would need to create separate packages.
>
> For deployment I usually use kernel images, or core images with
> unnecessary code unloaded (tests, examples, help system, ...). With
> the current setup I cannot just include some documentation into a core
> package without being forced to package it separately.
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Lukas
>
> I agree with you. Now my point was let us learn
> there is a builder that can use pragma and this is the one we should use.
> See my mails and the answers of torsten.
>
> What I would love to have is
>        - HelpSystemBuilder that collect some class comments and tests
>        based on a given pragma.
>
> Alain? Lukas? Torsten? Other? what could be a nice pragma for a Sunit
>
>
> testAbsoluteAuthority
>        "self debug: #testAbsoluteAuthority"
>
>        <test: #URI about: 'absolute uri with authority' tag: #(network )>
>
>        | uri absoluteURIString |
>        "An absolute URI with authority. An absolute URI starts with a scheme:"
>        absoluteURIString := 'http://www.pharo-project.org'.
>        uri := URI fromString: absoluteURIString.
>        self assert: (uri asString = absoluteURIString).
>        self assert: (uri isAbsolute).
>        self assert: (uri authority asString = 'www.pharo-project.org').
>        self deny: (uri isOpaque).
>
>
> Then now we could use help system to force us to write better tests.
>
>
> Stef
>
>
>> I think it is a design flaw that the help system doesn't make use of
>> extensibility in the spirit of the new preference system, the
>> extensible menus, or the metacello configurations. They all don't have
>> external dependencies and load fine into any image.
>>
>> Being forced to have strong references to the HelpSystem package (with
>> subclasses and class references) makes it impossible to just include
>> some documentation into a package, without introducing a dependency
>> onto the HelpSystem. This doesn't encourage me at all to provide some
>> quick documentation (e.g. for Gofer, PetitParser, RB, OB, ...),
>> because I would need to create separate packages.
>>
>> For deployment I usually use kernel images, or core images with
>> unnecessary code unloaded (tests, examples, help system, ...). With
>> the current setup I cannot just include some documentation into a core
>> package without being forced to package it separately.
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> _______________________________________________
>> 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
>

> Yes, I imagine something along ...
>
> PPParser class>>helpOn: aBuilder
> <help>
>
> aBuilder newBook: [ :book |
> book
> title: 'PetitParser';
> newPage: [ :page | page title: 'Tutorial'; contents: self  
> blogArticle ];
> newChapter: [ :chap | chap title: 'Operator API'; methodComments:
> PPParser selectors in: PPParser ];
> newChapter: [ :chap | chap title: 'Parser Classes'; classComments:
> PPParser withAllSubclasses ] ]
>
> This allows me to assemble the help from things that I have already
> written anyway. It does not introduce new dependencies and is small
> and concise.
>
> Lukas
>
> On 5 May 2010 11:24, Stéphane Ducasse <[hidden email]>  
> wrote:
>> Lukas
>>
>> I agree with you. Now my point was let us learn
>> there is a builder that can use pragma and this is the one we  
>> should use.
>> See my mails and the answers of torsten.
>>
>> What I would love to have is
>>        - HelpSystemBuilder that collect some class comments and tests
>>        based on a given pragma.
>>
>> Alain? Lukas? Torsten? Other? what could be a nice pragma for a Sunit
>>
>>
>> testAbsoluteAuthority
>>        "self debug: #testAbsoluteAuthority"
>>
>>        <test: #URI about: 'absolute uri with authority' tag:  
>> #(network )>
>>
>>        | uri absoluteURIString |
>>        "An absolute URI with authority. An absolute URI starts with  
>> a scheme:"
>>        absoluteURIString := 'http://www.pharo-project.org'.
>>        uri := URI fromString: absoluteURIString.
>>        self assert: (uri asString = absoluteURIString).
>>        self assert: (uri isAbsolute).
>>        self assert: (uri authority asString = 'www.pharo-
>> project.org').
>>        self deny: (uri isOpaque).
>>
>>
>> Then now we could use help system to force us to write better tests.
>>
>>
>> Stef
>>
>>
>>> I think it is a design flaw that the help system doesn't make use of
>>> extensibility in the spirit of the new preference system, the
>>> extensible menus, or the metacello configurations. They all don't  
>>> have
>>> external dependencies and load fine into any image.
>>>
>>> Being forced to have strong references to the HelpSystem package  
>>> (with
>>> subclasses and class references) makes it impossible to just include
>>> some documentation into a package, without introducing a dependency
>>> onto the HelpSystem. This doesn't encourage me at all to provide  
>>> some
>>> quick documentation (e.g. for Gofer, PetitParser, RB, OB, ...),
>>> because I would need to create separate packages.
>>>
>>> For deployment I usually use kernel images, or core images with
>>> unnecessary code unloaded (tests, examples, help system, ...). With
>>> the current setup I cannot just include some documentation into a  
>>> core
>>> package without being forced to package it separately.
>>>
>>> Lukas
>>>
>>> --
>>> Lukas Renggli
>>> www.lukas-renggli.ch
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Yes, I imagine something along ...
>
> PPParser class>>helpOn: aBuilder
> <help>
>
> aBuilder newBook: [ :book |
> book
> title: 'PetitParser';
> newPage: [ :page | page title: 'Tutorial'; contents: self blogArticle ];
> newChapter: [ :chap | chap title: 'Operator API'; methodComments:
> PPParser selectors in: PPParser ];
> newChapter: [ :chap | chap title: 'Parser Classes'; classComments:
> PPParser withAllSubclasses ] ]
>
> This allows me to assemble the help from things that I have already
> written anyway. It does not introduce new dependencies and is small
> and concise.
>
> Lukas
>
> On 5 May 2010 11:24, Stéphane Ducasse <[hidden email]> wrote:
>> Lukas
>>
>> I agree with you. Now my point was let us learn
>> there is a builder that can use pragma and this is the one we should use.
>> See my mails and the answers of torsten.
>>
>> What I would love to have is
>>        - HelpSystemBuilder that collect some class comments and tests
>>        based on a given pragma.
>>
>> Alain? Lukas? Torsten? Other? what could be a nice pragma for a Sunit
>>
>>
>> testAbsoluteAuthority
>>        "self debug: #testAbsoluteAuthority"
>>
>>        <test: #URI about: 'absolute uri with authority' tag: #(network )>
>>
>>        | uri absoluteURIString |
>>        "An absolute URI with authority. An absolute URI starts with a scheme:"
>>        absoluteURIString := 'http://www.pharo-project.org'.
>>        uri := URI fromString: absoluteURIString.
>>        self assert: (uri asString = absoluteURIString).
>>        self assert: (uri isAbsolute).
>>        self assert: (uri authority asString = 'www.pharo-project.org').
>>        self deny: (uri isOpaque).
>>
>>
>> Then now we could use help system to force us to write better tests.
>>
>>
>> Stef
>>
>>
>>> I think it is a design flaw that the help system doesn't make use of
>>> extensibility in the spirit of the new preference system, the
>>> extensible menus, or the metacello configurations. They all don't have
>>> external dependencies and load fine into any image.
>>>
>>> Being forced to have strong references to the HelpSystem package (with
>>> subclasses and class references) makes it impossible to just include
>>> some documentation into a package, without introducing a dependency
>>> onto the HelpSystem. This doesn't encourage me at all to provide some
>>> quick documentation (e.g. for Gofer, PetitParser, RB, OB, ...),
>>> because I would need to create separate packages.
>>>
>>> For deployment I usually use kernel images, or core images with
>>> unnecessary code unloaded (tests, examples, help system, ...). With
>>> the current setup I cannot just include some documentation into a core
>>> package without being forced to package it separately.
>>>
>>> Lukas
>>>
>>> --
>>> Lukas Renggli
>>> www.lukas-renggli.ch
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project