Re: Help on Polymorph [was How to build a GUI]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Help on Polymorph [was How to build a GUI]

laurent laffont

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Help on Polymorph [was How to build a GUI]

Stéphane Ducasse

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
Reply | Threaded
Open this post in threaded view
|

Re: Help on Polymorph [was How to build a GUI]

laurent laffont


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.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Help on Polymorph [was How to build a GUI]

Stéphane Ducasse

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
Reply | Threaded
Open this post in threaded view
|

Re: Help on Polymorph [was How to build a GUI]

Brian Brown-6
In reply to this post by laurent laffont

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
[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
Reply | Threaded
Open this post in threaded view
|

Re: Help on Polymorph [was How to build a GUI]

Brian Brown-6

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
Reply | Threaded
Open this post in threaded view
|

Re: Help on Polymorph [was How to build a GUI]

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Help on Polymorph [was How to build a GUI]

Brian Brown-6

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
Reply | Threaded
Open this post in threaded view
|

Re: Help on Polymorph [was How to build a GUI]

Stéphane Ducasse

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
Reply | Threaded
Open this post in threaded view
|

Re: Help on Polymorph [was How to build a GUI]

Alexandre Bergel
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Help on Polymorph [was How to build a GUI]

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Help on Polymorph [was How to build a GUI]

Alexandre Bergel
> 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