Hi In fact I've managed to build some windows with controls but I feel missing several concepts on how to use Polymorph the right way ( funny, I've built Gtk, Qt, Swing, ... GUI quite easily ... ). - What is the idea behind the word "Pluggable" (PluggableButton, PluggableDialogWindow, ....) ? - It seems that many (all ?) UI in Pharo use the builder pattern. Great, but that's a lot of stuff for me while trying to learn (with almost no time, I had forgotten that a new child take soooo much time). Do you know a package/class with simpler UI to study ? - In Toolbuilder, what the word "Spec" means ? Some thoughts: - Toolbuilder-Examples package is great to study how to use Toolbuilder. I think it should be included in Pharo with some other XXX-Examples packages that might exists. - Is there a somewhat easier way to navigate through class and methods documentation than in System Browser ? I think that documentation is not easily seen, so it doesn't push developers to write documentation, so there's not a lot of documentation, so people don't write tools to read documentation, ... There should be a system / tool to reward developpers that write good class / package documentation with examples. Regards, Laurent _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Aug 12, 2009, at 10:32 PM, laurent laffont wrote: > Not exactly a compreensive documentation but rather a quick start: > > In a workspace evaluate: > > UITheme exampleBasicControls. > UITheme exampleColorControls. > UITheme exampleDialogs. > UITheme exampleGroups. > UITheme exampleOtherControls. > UITheme exampleWindowWithToolbars. > > > Hi > > In fact I've managed to build some windows with controls but I feel > missing several concepts on how to use Polymorph the right way > ( funny, I've built Gtk, Qt, Swing, ... GUI quite easily ... ). this is normal Morphic has not evolved since years. Now I hope that with the UI builder NullPointer is doing it will change a lot. > - What is the idea behind the word "Pluggable" (PluggableButton, > PluggableDialogWindow, ....) ? Normally you pass a symbol or a block and it will be executed (I think that any GUI should be like that :)). > - It seems that many (all ?) UI in Pharo use the builder pattern. > Great, but that's a lot of stuff for me while trying to learn (with > almost no time, I had forgotten that a new child take soooo much > time). Do you know a package/class with simpler UI to study ? > > - In Toolbuilder, what the word "Spec" means ? > > Some thoughts: > > - Toolbuilder-Examples package is great to study how to use > Toolbuilder. I think it should be included in Pharo with some other > XXX-Examples packages that might exists. thanks. Where is the ToolBuilder-Examples in the Squeak trunk? > - Is there a somewhat easier way to navigate through class and > methods documentation than in System Browser ? I think that > documentation is not easily seen, so it doesn't push developers to > write documentation, so there's not a lot of documentation, so > people don't write tools to read documentation, ... There should be > a system / tool to reward developpers that write good class / > package documentation with examples. So far we should invent it. And I totally agree with you. If people do not see the good doc they will not write good comment. I started to work on DrDoc a kind of package meta data to add documentation to a package but it got stole I should push that again. What would be nice is to take one package and do it well as an example. > > > Regards, > > 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 |
It think it should be possible to write documentation at the package level. So developpers have a place where they can write an overview of their package. When we click on a package, documentation should be displayed by default or easily. In the rubygems world, it is a common practice to write documentation in a README file which is displayed by RDoc on startup page (github works the same way). It seems to me that there's the same level of comment between Ruby class/methods and Pharo. The documentation at the package level may be the difference. Python has a real documentation effort.Each release come with its up to date documentation. It's a release criteria. Python shares some similarities with Pharo as they both have "batteries included". May be there should have a process to contribute to a centralized Pharo documentation which can be accessed within the IDE. Laurent. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Aug 13, 2009, at 11:41 AM, laurent laffont wrote: > > > So far we should invent it. > And I totally agree with you. If people do not see the good doc they > will not write good comment. > I started to work on DrDoc a kind of package meta data to add > documentation to a package but it got stole > I should push that again. What would be nice is to take one package > and do it well as an example. > > > It think it should be possible to write documentation at the package > level. So developpers have a place where they can write an overview > of their package. When we click on a package, documentation should > be displayed by default or easily. Yes this is exactly the idea behind DrDoc The browser or another tools could show us that You can have a look at DrDoc and we could pair code more on it. > In the rubygems world, it is a common practice to write > documentation in a README file which is displayed by RDoc on startup > page (github works the same way). It seems to me that there's the > same level of comment between Ruby class/methods and Pharo. The > documentation at the package level may be the difference. Yes > Python has a real documentation effort.Each release come with its up > to date documentation. It's a release criteria. Python shares some > similarities with Pharo as they both have "batteries included". May > be there should have a process to contribute to a centralized Pharo > documentation which can be accessed within the IDE. Yes I think that pushing a bit more DrDoc is the way to go. I'm just flooded by work. > > 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 |
In reply to this post by laurent laffont
On Aug 13, 2009, at 3:41 AM, laurent laffont wrote:
Yes! Here is a post I made in April of 2003: > The biggest frustration with using comments is that there is no good > "starting place" for a given class category. For example, go browse > the Seaside classes and categories and figure out where one should > start. You can repeat this exercise for any number of categories. I > propose that we we add a documentation attribute to the PackageInfo > stuff, so there is a category level documentation spot, with links to > the appropriate class comments. > Any thoughts? I didn't get any response, and I sent a similar type of thought to Stef recently, but he's so busy I don't even know if he read my email :) - Brian
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Aug 13, 2009, at 12:21 PM, Brian Brown wrote: I didn't get any response, and I sent a similar type of thought to Stef recently, but he's so busy I don't even know if he read my email :) Scratch that - Matthew Fulmer thought it was a good idea as well :) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Brian Brown-6
But you know you can also propose a solution with code. :)
Take DrDoc and improve it. I agree more than 200% with you but my day job in not improving pharo or squeak. Pharo is a nice project but I have plenty of other things that I have to do (admin, research, PhD students....) Stef >> So far we should invent it. >> And I totally agree with you. If people do not see the good doc they >> will not write good comment. >> I started to work on DrDoc a kind of package meta data to add >> documentation to a package but it got stole >> I should push that again. What would be nice is to take one package >> and do it well as an example. >> >> >> It think it should be possible to write documentation at the >> package level. So developpers have a place where they can write an >> overview of their package. When we click on a package, >> documentation should be displayed by default or easily. > > Yes! Here is a post I made in April of 2003: > > > > The biggest frustration with using comments is that there is no good > > "starting place" for a given class category. For example, go browse > > the Seaside classes and categories and figure out where one should > > start. You can repeat this exercise for any number of categories. I > > propose that we we add a documentation attribute to the PackageInfo > > stuff, so there is a category level documentation spot, with links > to > > the appropriate class comments. > > > Any thoughts? > I didn't get any response, and I sent a similar type of thought to > Stef recently, but he's so busy I don't even know if he read my > email :) > > - Brian >> >> In the rubygems world, it is a common practice to write >> documentation in a README file which is displayed by RDoc on >> startup page (github works the same way). It seems to me that >> there's the same level of comment between Ruby class/methods and >> Pharo. The documentation at the package level may be the difference. >> >> Python has a real documentation effort.Each release come with its >> up to date documentation. It's a release criteria. Python shares >> some similarities with Pharo as they both have "batteries >> included". May be there should have a process to contribute to a >> centralized Pharo documentation which can be accessed within the IDE. >> >> 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 |
On Aug 13, 2009, at 2:49 PM, Stéphane Ducasse wrote: > But you know you can also propose a solution with code. :) > Take DrDoc and improve it. > I agree more than 200% with you but my day job in not improving pharo > or squeak. > Pharo is a nice project but I have plenty of other things that I have > to do (admin, research, PhD students....) I know that, you do amazing amounts in spite of your responsibilities and I really appreciate it. The only reason I sent you an email is because you were/are working on the PackageInfo replacement, so it seemed appropriate. Is DrDoc on SqueakSource? I'll take a look. - Brian > > Stef > >>> So far we should invent it. >>> And I totally agree with you. If people do not see the good doc they >>> will not write good comment. >>> I started to work on DrDoc a kind of package meta data to add >>> documentation to a package but it got stole >>> I should push that again. What would be nice is to take one package >>> and do it well as an example. >>> >>> >>> It think it should be possible to write documentation at the >>> package level. So developpers have a place where they can write an >>> overview of their package. When we click on a package, >>> documentation should be displayed by default or easily. >> >> Yes! Here is a post I made in April of 2003: >> >> >>> The biggest frustration with using comments is that there is no good >>> "starting place" for a given class category. For example, go browse >>> the Seaside classes and categories and figure out where one should >>> start. You can repeat this exercise for any number of categories. I >>> propose that we we add a documentation attribute to the PackageInfo >>> stuff, so there is a category level documentation spot, with links >> to >>> the appropriate class comments. >> >>> Any thoughts? >> I didn't get any response, and I sent a similar type of thought to >> Stef recently, but he's so busy I don't even know if he read my >> email :) >> >> - Brian >>> >>> In the rubygems world, it is a common practice to write >>> documentation in a README file which is displayed by RDoc on >>> startup page (github works the same way). It seems to me that >>> there's the same level of comment between Ruby class/methods and >>> Pharo. The documentation at the package level may be the difference. >>> >>> Python has a real documentation effort.Each release come with its >>> up to date documentation. It's a release criteria. Python shares >>> some similarities with Pharo as they both have "batteries >>> included". May be there should have a process to contribute to a >>> centralized Pharo documentation which can be accessed within the >>> IDE. >>> >>> 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 > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Aug 14, 2009, at 7:00 AM, Brian Brown wrote: > > On Aug 13, 2009, at 2:49 PM, Stéphane Ducasse wrote: > >> But you know you can also propose a solution with code. :) >> Take DrDoc and improve it. >> I agree more than 200% with you but my day job in not improving pharo >> or squeak. >> Pharo is a nice project but I have plenty of other things that I have >> to do (admin, research, PhD students....) > > I know that, you do amazing amounts in spite of your responsibilities > and I really appreciate it. The only reason I sent you an email is > because you were/are working on the PackageInfo replacement, so it > seemed appropriate. Oh Yes! > Is DrDoc on SqueakSource? I'll take a look. Yes I would be more than happy if someone could take the lead there. I could embed images (UML diagram). I designed in a way that it does not depend on an existing superclass so that we can load the package and its metadata in any squeak/pharo version (so the design is suboptimal from a OO perspective). Stef > > - Brian > > > >> >> Stef >> >>>> So far we should invent it. >>>> And I totally agree with you. If people do not see the good doc >>>> they >>>> will not write good comment. >>>> I started to work on DrDoc a kind of package meta data to add >>>> documentation to a package but it got stole >>>> I should push that again. What would be nice is to take one package >>>> and do it well as an example. >>>> >>>> >>>> It think it should be possible to write documentation at the >>>> package level. So developpers have a place where they can write an >>>> overview of their package. When we click on a package, >>>> documentation should be displayed by default or easily. >>> >>> Yes! Here is a post I made in April of 2003: >>> >>> >>>> The biggest frustration with using comments is that there is no >>>> good >>>> "starting place" for a given class category. For example, go browse >>>> the Seaside classes and categories and figure out where one should >>>> start. You can repeat this exercise for any number of categories. I >>>> propose that we we add a documentation attribute to the PackageInfo >>>> stuff, so there is a category level documentation spot, with links >>> to >>>> the appropriate class comments. >>> >>>> Any thoughts? >>> I didn't get any response, and I sent a similar type of thought to >>> Stef recently, but he's so busy I don't even know if he read my >>> email :) >>> >>> - Brian >>>> >>>> In the rubygems world, it is a common practice to write >>>> documentation in a README file which is displayed by RDoc on >>>> startup page (github works the same way). It seems to me that >>>> there's the same level of comment between Ruby class/methods and >>>> Pharo. The documentation at the package level may be the >>>> difference. >>>> >>>> Python has a real documentation effort.Each release come with its >>>> up to date documentation. It's a release criteria. Python shares >>>> some similarities with Pharo as they both have "batteries >>>> included". May be there should have a process to contribute to a >>>> centralized Pharo documentation which can be accessed within the >>>> IDE. >>>> >>>> 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 >> > > > _______________________________________________ > 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 |
>> Is DrDoc on SqueakSource? I'll take a look.
> > Yes I would be more than happy if someone could take the lead there. > I could embed images (UML diagram). It could maybe be used with Mondrian :-) Alexandre > > > >> >> - Brian >> >> >> >>> >>> Stef >>> >>>>> So far we should invent it. >>>>> And I totally agree with you. If people do not see the good doc >>>>> they >>>>> will not write good comment. >>>>> I started to work on DrDoc a kind of package meta data to add >>>>> documentation to a package but it got stole >>>>> I should push that again. What would be nice is to take one >>>>> package >>>>> and do it well as an example. >>>>> >>>>> >>>>> It think it should be possible to write documentation at the >>>>> package level. So developpers have a place where they can write an >>>>> overview of their package. When we click on a package, >>>>> documentation should be displayed by default or easily. >>>> >>>> Yes! Here is a post I made in April of 2003: >>>> >>>> >>>>> The biggest frustration with using comments is that there is no >>>>> good >>>>> "starting place" for a given class category. For example, go >>>>> browse >>>>> the Seaside classes and categories and figure out where one should >>>>> start. You can repeat this exercise for any number of >>>>> categories. I >>>>> propose that we we add a documentation attribute to the >>>>> PackageInfo >>>>> stuff, so there is a category level documentation spot, with links >>>> to >>>>> the appropriate class comments. >>>> >>>>> Any thoughts? >>>> I didn't get any response, and I sent a similar type of thought to >>>> Stef recently, but he's so busy I don't even know if he read my >>>> email :) >>>> >>>> - Brian >>>>> >>>>> In the rubygems world, it is a common practice to write >>>>> documentation in a README file which is displayed by RDoc on >>>>> startup page (github works the same way). It seems to me that >>>>> there's the same level of comment between Ruby class/methods and >>>>> Pharo. The documentation at the package level may be the >>>>> difference. >>>>> >>>>> Python has a real documentation effort.Each release come with its >>>>> up to date documentation. It's a release criteria. Python shares >>>>> some similarities with Pharo as they both have "batteries >>>>> included". May be there should have a process to contribute to a >>>>> centralized Pharo documentation which can be accessed within the >>>>> IDE. >>>>> >>>>> 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 >>> >> >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
would be nice to save a script and its png.
Now can you have use relationships? Stef On Aug 14, 2009, at 4:53 PM, Alexandre Bergel wrote: >>> Is DrDoc on SqueakSource? I'll take a look. >> >> Yes I would be more than happy if someone could take the lead there. >> I could embed images (UML diagram). > > It could maybe be used with Mondrian :-) > > Alexandre > > >> >> >> >>> >>> - Brian >>> >>> >>> >>>> >>>> Stef >>>> >>>>>> So far we should invent it. >>>>>> And I totally agree with you. If people do not see the good doc >>>>>> they >>>>>> will not write good comment. >>>>>> I started to work on DrDoc a kind of package meta data to add >>>>>> documentation to a package but it got stole >>>>>> I should push that again. What would be nice is to take one >>>>>> package >>>>>> and do it well as an example. >>>>>> >>>>>> >>>>>> It think it should be possible to write documentation at the >>>>>> package level. So developpers have a place where they can write >>>>>> an >>>>>> overview of their package. When we click on a package, >>>>>> documentation should be displayed by default or easily. >>>>> >>>>> Yes! Here is a post I made in April of 2003: >>>>> >>>>> >>>>>> The biggest frustration with using comments is that there is no >>>>>> good >>>>>> "starting place" for a given class category. For example, go >>>>>> browse >>>>>> the Seaside classes and categories and figure out where one >>>>>> should >>>>>> start. You can repeat this exercise for any number of >>>>>> categories. I >>>>>> propose that we we add a documentation attribute to the >>>>>> PackageInfo >>>>>> stuff, so there is a category level documentation spot, with >>>>>> links >>>>> to >>>>>> the appropriate class comments. >>>>> >>>>>> Any thoughts? >>>>> I didn't get any response, and I sent a similar type of thought to >>>>> Stef recently, but he's so busy I don't even know if he read my >>>>> email :) >>>>> >>>>> - Brian >>>>>> >>>>>> In the rubygems world, it is a common practice to write >>>>>> documentation in a README file which is displayed by RDoc on >>>>>> startup page (github works the same way). It seems to me that >>>>>> there's the same level of comment between Ruby class/methods and >>>>>> Pharo. The documentation at the package level may be the >>>>>> difference. >>>>>> >>>>>> Python has a real documentation effort.Each release come with its >>>>>> up to date documentation. It's a release criteria. Python shares >>>>>> some similarities with Pharo as they both have "batteries >>>>>> included". May be there should have a process to contribute to a >>>>>> centralized Pharo documentation which can be accessed within the >>>>>> IDE. >>>>>> >>>>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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 >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 |
> would be nice to save a script and its png.
.png can be easily produced. Just send exportAsPNG to a MOCanvas. This can be done using an inspector. I need to add an entry in the menu. > Now can you have use relationships? Yes, but they need to be defined manually. Alexandre > > On Aug 14, 2009, at 4:53 PM, Alexandre Bergel wrote: > >>>> Is DrDoc on SqueakSource? I'll take a look. >>> >>> Yes I would be more than happy if someone could take the lead there. >>> I could embed images (UML diagram). >> >> It could maybe be used with Mondrian :-) >> >> Alexandre >> >> >>> >>> >>> >>>> >>>> - Brian >>>> >>>> >>>> >>>>> >>>>> Stef >>>>> >>>>>>> So far we should invent it. >>>>>>> And I totally agree with you. If people do not see the good doc >>>>>>> they >>>>>>> will not write good comment. >>>>>>> I started to work on DrDoc a kind of package meta data to add >>>>>>> documentation to a package but it got stole >>>>>>> I should push that again. What would be nice is to take one >>>>>>> package >>>>>>> and do it well as an example. >>>>>>> >>>>>>> >>>>>>> It think it should be possible to write documentation at the >>>>>>> package level. So developpers have a place where they can write >>>>>>> an >>>>>>> overview of their package. When we click on a package, >>>>>>> documentation should be displayed by default or easily. >>>>>> >>>>>> Yes! Here is a post I made in April of 2003: >>>>>> >>>>>> >>>>>>> The biggest frustration with using comments is that there is no >>>>>>> good >>>>>>> "starting place" for a given class category. For example, go >>>>>>> browse >>>>>>> the Seaside classes and categories and figure out where one >>>>>>> should >>>>>>> start. You can repeat this exercise for any number of >>>>>>> categories. I >>>>>>> propose that we we add a documentation attribute to the >>>>>>> PackageInfo >>>>>>> stuff, so there is a category level documentation spot, with >>>>>>> links >>>>>> to >>>>>>> the appropriate class comments. >>>>>> >>>>>>> Any thoughts? >>>>>> I didn't get any response, and I sent a similar type of thought >>>>>> to >>>>>> Stef recently, but he's so busy I don't even know if he read my >>>>>> email :) >>>>>> >>>>>> - Brian >>>>>>> >>>>>>> In the rubygems world, it is a common practice to write >>>>>>> documentation in a README file which is displayed by RDoc on >>>>>>> startup page (github works the same way). It seems to me that >>>>>>> there's the same level of comment between Ruby class/methods and >>>>>>> Pharo. The documentation at the package level may be the >>>>>>> difference. >>>>>>> >>>>>>> Python has a real documentation effort.Each release come with >>>>>>> its >>>>>>> up to date documentation. It's a release criteria. Python shares >>>>>>> some similarities with Pharo as they both have "batteries >>>>>>> included". May be there should have a process to contribute to a >>>>>>> centralized Pharo documentation which can be accessed within the >>>>>>> IDE. >>>>>>> >>>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |