Re: [Pharo-project] Help on Polymorph [was How to build a GUI]
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 ... ). - 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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. 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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 13, 2009, at 3: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! 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 Pharo-project@lists.gforge.inria.fr 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 :)
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (4)
-
Alexandre Bergel -
Brian Brown -
laurent laffont -
Stéphane Ducasse