It would be too expensive to add a description for packages in Configuration Browser?
Is there a specific reason why this was not implemented? Is someone working on this? See the "Perl Package Manager" for example. When you launch it, takes some time to update but each item displays the Details and you have an Abstract colum. Cheers, Hernán
On Dec 7, 2013, at 8:44 PM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Is there a specific reason why this was not implemented? Is someone working on this?
We added catalog metadata to configuration now - the tools should take into account about that - people should add such metadata to their configuration If you modify the package browser to present description it will be in the system Stef
See the "Perl Package Manager" for example.
When you launch it, takes some time to update but each item displays the Details and you have an Abstract colum.
Cheers,
Hernán
Cool :) I started to think about a nice Pharo app store since a while :P I should give a try soon then Ben On 07 Dec 2013, at 20:52, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 7, 2013, at 8:44 PM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Is there a specific reason why this was not implemented? Is someone working on this?
We added catalog metadata to configuration now - the tools should take into account about that - people should add such metadata to their configuration
If you modify the package browser to present description it will be in the system
Stef
See the "Perl Package Manager" for example.
When you launch it, takes some time to update but each item displays the Details and you have an Abstract colum.
Cheers,
Hernán
On 07 Dec 2013, at 20:58, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
Cool :)
I started to think about a nice Pharo app store since a while :P Awesome. Was wanting this for a year :)
I should give a try soon then
Ben
On 07 Dec 2013, at 20:52, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 7, 2013, at 8:44 PM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Is there a specific reason why this was not implemented? Is someone working on this?
We added catalog metadata to configuration now - the tools should take into account about that - people should add such metadata to their configuration
If you modify the package browser to present description it will be in the system
Stef
See the "Perl Package Manager" for example.
When you launch it, takes some time to update but each item displays the Details and you have an Abstract colum.
Cheers,
Hernán
I am also interested into making or contributing to something like this. I think configuration browser is already there, simple to use, straight to the point, no nonesense. The only thing it misses is an unistall button. I was thinking also some nice graphics and maybe small description of packages and a rating system with user reviews. Standard app store stuff. On Sat, Dec 7, 2013 at 10:35 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 07 Dec 2013, at 20:58, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
Cool :)
I started to think about a nice Pharo app store since a while :P
Awesome. Was wanting this for a year :)
I should give a try soon then
Ben
On 07 Dec 2013, at 20:52, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 7, 2013, at 8:44 PM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
Is there a specific reason why this was not implemented? Is someone working on this?
We added catalog metadata to configuration now - the tools should take into account about that - people should add such metadata to their configuration
If you modify the package browser to present description it will be in the system
Stef
See the "Perl Package Manager" for example.
When you launch it, takes some time to update but each item displays the Details and you have an Abstract colum.
Cheers,
Hernán
On 07 Dec 2013, at 20:52, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 7, 2013, at 8:44 PM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Is there a specific reason why this was not implemented? Is someone working on this?
We added catalog metadata to configuration now - the tools should take into account about that - people should add such metadata to their configuration
If you modify the package browser to present description it will be in the system
Stef, what is the spec, the API, is there an example config with description in the image already ?
Stef
See the "Perl Package Manager" for example.
When you launch it, takes some time to update but each item displays the Details and you have an Abstract colum.
Cheers,
Hernán
We added catalog metadata to configuration now - the tools should take into account about that - people should add such metadata to their configuration
If you modify the package browser to present description it will be in the system
Stef, what is the spec, the API, is there an example config with description in the image already ?
really simple 4 class side methods catalogDescription ^ 'Soup is a frameworks for scrapping HTML. It offers a simplified query mechanism to abstract over the XML and HTML structures of a document.' catalogKeywords ^ #(HTML web query scrapping Soup XPath) catalogChangeLog ^ '- Version 1. 4 21/02/2013 migrated to SmalltalkHub [[[ (ConfigurationOfSoup project version: ''1.4'') load ]]] - Version 1.3 adding better stable version. [[[ (ConfigurationOfSoup project version: ''1.3'') load ]]] ' catalogKeyClassesAndExample ^ 'It is composed of some keys classes: - ==SoupElement== is the root of elements that are extracted during the parsing of an HTML document. Contrary to traditional HTML Parser, Soup produces a limited set of elements which approximate the HTML elements but supports querying and extracting information. - Soup. ==Soup== is the main public class of the package. It is the class to interact with as shown by the tests. The best way to get started is to get a soup of html elements using ==Soup class>>fromString:== as follows: [[[ Soup fromString: ''http://www.bedetheque.com/album-105582-BD-Atomium-Express.html'' asUrl retrieveContents ]]] Tests of the ==Soup== class are the place to start to learn the API.' have a look at SOUP
On 08 Dec 2013, at 09:31, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
really simple 4 class side methods
OK, I see that this can be in Pier syntax. No problem for me, but that does mean that weâll need a Pier parser and renderer in the base image, no ? Else tools will not be able to show this, right ?
The reason is simple: when I wrote the config browser there was no such additional description on the configs itself and one would have to load the config into the image first. Think of 2000 config's (note each is a package) loading in the future when the config browser opens. This will take ages. I think this is not good since the app should be responsive. Maybe a "show details" button helps when the package is selected. I would rather see: 1. Either a simple hosted seaside app "Pharo Store" that one can use to register a config for a specific pharo version (similar like squeakmap) maybe directly from the STHub interface with description, ... This app can be queried by the config browser (JSON/XML/Fuel/...) to display infos on the package, maybe also a rating about downloads, ... 2. Or a general mechanism that loads the configs, runs tests and if OK provides them for the config browser as "yes these config really work" Bye T.
On Dec 8, 2013, at 11:16 AM, Torsten Bergmann <astares@gmx.de> wrote:
The reason is simple: when I wrote the config browser there was no such additional description on the configs itself and one would have to load the config into the image first.
Think of 2000 config's (note each is a package) loading in the future when the config browser opens. This will take ages. I think this is not good since the app should be responsive.
Maybe a "show details" button helps when the package is selected.
I would rather see: 1. Either a simple hosted seaside app "Pharo Store" that one can use to register a config for a specific pharo version (similar like squeakmap) maybe directly from the STHub interface with description, â¦
Indeed open and downloading all the files containing the configuration does not scale Now having the descriptions in the configuration let us build the catalog on a server
This app can be queried by the config browser (JSON/XML/Fuel/...) to display infos on the package, maybe also a rating about downloads, ...
2. Or a general mechanism that loads the configs, runs tests and if OK provides them for the config browser as "yes these config really work"
I will ask inria for an engineer to do 1 and 2
Bye T.
Hi Torsten, 2013/12/8 Torsten Bergmann <astares@gmx.de>
The reason is simple: when I wrote the config browser there was no such additional description on the configs itself and one would have to load the config into the image first.
Think of 2000 config's (note each is a package) loading in the future when the config browser opens. This will take ages. I think this is not good since the app should be responsive.
Maybe a "show details" button helps when the package is selected.
I agree (see attached screenshot). I have added the button but the thing is: Package can be fetched from the repository, but there is no package description. There are only textual descriptions of commits. So anyone see any workaround here?
I would rather see: 1. Either a simple hosted seaside app "Pharo Store" that one can use to register a config for a specific pharo version (similar like squeakmap) maybe directly from the STHub interface with description, ...
This app can be queried by the config browser (JSON/XML/Fuel/...) to display infos on the package, maybe also a rating about downloads, ...
2. Or a general mechanism that loads the configs, runs tests and if OK provides them for the config browser as "yes these config really work"
Absolutely. Configurations should be certified. Hernán
I agree (see attached screenshot). I have added the button but the thing is: Package can be fetched from the repository, but there is no package description. There are only textual descriptions of commits.
If you have a look at the packages I maintain I added catalog metadata to htem and I generate automatically https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? Now this would require to load all the configruatiion files in the images and this is not what you want.
So anyone see any workaround here?
What we could do is to extend the catalog builder server to emit STON files in addition to the html one and the browser could just load these files without having to download all the configurationOf. If somebody want to help, the code of the catalog builder is available and the jenkins job up and running here: https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/
I would rather see: 1. Either a simple hosted seaside app "Pharo Store" that one can use to register a config for a specific pharo version (similar like squeakmap) maybe directly from the STHub interface with description, ...
This app can be queried by the config browser (JSON/XML/Fuel/...) to display infos on the package, maybe also a rating about downloads, ...
2. Or a general mechanism that loads the configs, runs tests and if OK provides them for the config browser as "yes these config really work"
Absolutely. Configurations should be certified.
Hernán
<Configuration browser.png>
El 08/12/2013 19:04, Torsten Bergmann escribió:
Hi Hernan, the problem is not the button - but the missing standard and standardized descriptions on the configs...
I see. Let's attack the real problem then.
For instance I also write markup docu on my configs (see ConfigurationOfINIFile) - it is loadable as a usual config but adds two class side methods: #documentation and #tutorialOn: using the <onlineTutorial> pragma. The documentation is stored as class comment in markdown format on the ConfigurationOfINIFile class. I use the same description then for the STHub project page.
I am not a big fan of pragmas, but if people is fine with them I can parse the markup. However I imagine that would require a parser preloaded in the image...
If one loads additionally the "PharoOnlineHelp" package afterwards it will also appear magically in my Pharo online help as a tutorial. This was my proposal - but so far it looks like nobody is really interested.
Maybe because often this ends in "which syntax" discussions and due to the lack of good in image default text display facilities for markup, pier-syntax, ...
Please let's take a decision and live with it. The real point is that only a friendly String saying "The selected package does this" would improve usability, specially for newcomers. Do not forget we can just enforce a method in the ConfigurationOf... packageDescription ^ 'My purpose is to blabla'
In general it can be done easily, but we have to agree on some kind of "common standard" for configurations and documentation on - how to describe a package (also the format, either markdown or pier syntax with http://smalltalkhub.com/#!/~Pier/Pillar <https://3c.gmx.net/mail/client/dereferrer?redirectUrl=http%3A%2F%2Fsmalltalk...>) - how to name the methods or pragmas that are used Stef also did something (with Catalog), the ConfigurationOfINIFile for instance has two supporting methods: #catalogDescription and #repositoryUrlString. Still Catalog uses Pier and is not really visible - and STHub does support markdown by default.
Ok, just waiting for a decision here.
As of today I would like to see Pharo moving into the following direction: - using the configs for describing the help/documentation/package descriptions - also tagging with package categories (for instance there are packages/projects for "database access", others for "parsers", or "games") - maybe use pier syntax for descriptions (it can be parsed by Pillar and other formats like HTML, markdown, Latex, ... be generated) - generate pages like catalog https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? but with a better design and visibility like "http://packages.pharo.org" together with a loadable list for the config browser - when one uploads such a ConfigurationOfMyKillerApp to STHub it should automagically update the STHub description (which is currently only possible via the web interface) - additional rankings (number of downloads like on STHub, successful CI builds, member rankings, ...) - automated verfication - ... <snip>lot of other ideas</snip> Bye T. *Gesendet:* Sonntag, 08. Dezember 2013 um 22:12 Uhr *Von:* "Hernán Morales Durand" <hernan.morales@gmail.com> *An:* "Pharo Development List" <pharo-dev@lists.pharo.org> *Betreff:* Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser? Hi Torsten, 2013/12/8 Torsten Bergmann <astares@gmx.de>
The reason is simple: when I wrote the config browser there was no such additional description on the configs itself and one would have to load the config into the image first.
Think of 2000 config's (note each is a package) loading in the future when the config browser opens. This will take ages. I think this is not good since the app should be responsive.
Maybe a "show details" button helps when the package is selected.
I agree (see attached screenshot). I have added the button but the thing is: Package can be fetched from the repository, but there is no package description. There are only textual descriptions of commits. So anyone see any workaround here?
I would rather see: 1. Either a simple hosted seaside app "Pharo Store" that one can use to register a config for a specific pharo version (similar like squeakmap) maybe directly from the STHub interface with description, ...
This app can be queried by the config browser (JSON/XML/Fuel/...) to display infos on the package, maybe also a rating about downloads, ...
2. Or a general mechanism that loads the configs, runs tests and if OK provides them for the config browser as "yes these config really work"
Absolutely. Configurations should be certified.
Hernán
Hi Hernan,
the problem is not the button - but the missing standard and standardized descriptions on the configs...
For instance I also write markup docu on my configs (see ConfigurationOfINIFile) - it is loadable as a usual config but adds two class side methods: #documentation and #tutorialOn: using the <onlineTutorial> pragma.
The documentation is stored as class comment in markdown format on the ConfigurationOfINIFile class. I use the same description then for the STHub project page.
If one loads additionally the "PharoOnlineHelp" package afterwards it will also appear magically in my Pharo online help as a tutorial. This was my proposal - but so far it looks like nobody is really interested.
this is not that this is a question of time. And sorry but I will not use markdown.
Maybe because often this ends in "which syntax" discussions and due to the lack of good in image default text display facilities for markup, pier-syntax, ...
In general it can be done easily, but we have to agree on some kind of "common standard" for configurations and documentation on - how to describe a package (also the format, either markdown or pier syntax with http://smalltalkhub.com/#!/~Pier/Pillar) - how to name the methods or pragmas that are used
Stef also did something (with Catalog), the ConfigurationOfINIFile for instance has two supporting methods: #catalogDescription and
#repositoryUrlString. this one is deprecated after discussing with versioner.
Still Catalog uses Pier and is not really visible - and STHub does support markdown by default.
As of today I would like to see Pharo moving into the following direction: - using the configs for describing the help/documentation/package descriptions - also tagging with package categories (for instance there are packages/projects for "database access", others for "parsers", or "games") - maybe use pier syntax for descriptions (it can be parsed by Pillar and other formats like HTML, markdown, Latex, ... be generated) - generate pages like catalog https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? but with a better design and visibility like "http://packages.pharo.org"
The code is open. My time is really counted. Just merged your convention to mine and unify.
together with a loadable list for the config browser - when one uploads such a ConfigurationOfMyKillerApp to STHub it should automagically update the STHub description (which is currently only possible via the web interface) - additional rankings (number of downloads like on STHub, successful CI builds, member rankings, ...) - automated verfication - ... <snip>lot of other ideas</snip>
Bye T.
Gesendet: Sonntag, 08. Dezember 2013 um 22:12 Uhr Von: "Hernán Morales Durand" <hernan.morales@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser? Hi Torsten,
2013/12/8 Torsten Bergmann <astares@gmx.de> The reason is simple: when I wrote the config browser there was no such additional description on the configs itself and one would have to load the config into the image first.
Think of 2000 config's (note each is a package) loading in the future when the config browser opens. This will take ages. I think this is not good since the app should be responsive.
Maybe a "show details" button helps when the package is selected.
I agree (see attached screenshot). I have added the button but the thing is: Package can be fetched from the repository, but there is no package description. There are only textual descriptions of commits.
So anyone see any workaround here?
I would rather see: 1. Either a simple hosted seaside app "Pharo Store" that one can use to register a config for a specific pharo version (similar like squeakmap) maybe directly from the STHub interface with description, ...
This app can be queried by the config browser (JSON/XML/Fuel/...) to display infos on the package, maybe also a rating about downloads, ...
2. Or a general mechanism that loads the configs, runs tests and if OK provides them for the config browser as "yes these config really work"
Absolutely. Configurations should be certified.
Hernán
Ok, in 12374 (incomplete, needs love) https://pharo.fogbugz.com/f/cases/12374/Display-package-description-on-selec... Cheers, Hernán 2013/12/9 Stéphane Ducasse <stephane.ducasse@inria.fr>
Hi Hernan,
the problem is not the button - but the missing standard and standardized descriptions on the configs...
For instance I also write markup docu on my configs (see ConfigurationOfINIFile) - it is loadable as a usual config but adds two class side methods: #documentation and #tutorialOn: using the <onlineTutorial> pragma.
The documentation is stored as class comment in markdown format on the ConfigurationOfINIFile class. I use the same description then for the STHub project page.
If one loads additionally the "PharoOnlineHelp" package afterwards it will also appear magically in my Pharo online help as a tutorial. This was my proposal - but so far it looks like nobody is really interested.
this is not that this is a question of time. And sorry but I will not use markdown.
Maybe because often this ends in "which syntax" discussions and due to the lack of good in image default text display facilities for markup, pier-syntax, ...
In general it can be done easily, but we have to agree on some kind of "common standard" for configurations and documentation on - how to describe a package (also the format, either markdown or pier syntax with http://smalltalkhub.com/#!/~Pier/Pillar<https://3c.gmx.net/mail/client/dereferrer?redirectUrl=http%3A%2F%2Fsmalltalkhub.com%2F%23%21%2F%7EPier%2FPillar> ) - how to name the methods or pragmas that are used
Stef also did something (with Catalog), the ConfigurationOfINIFile for instance has two supporting methods: #catalogDescription and
#repositoryUrlString.
this one is deprecated after discussing with versioner.
Still Catalog uses Pier and is not really visible - and STHub does support markdown by default.
As of today I would like to see Pharo moving into the following direction: - using the configs for describing the help/documentation/package descriptions - also tagging with package categories (for instance there are packages/projects for "database access", others for "parsers", or "games") - maybe use pier syntax for descriptions (it can be parsed by Pillar and other formats like HTML, markdown, Latex, ... be generated) - generate pages like catalog https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? but with a better design and visibility like " http://packages.pharo.org"
The code is open. My time is really counted. Just merged your convention to mine and unify.
together with a loadable list for the config browser - when one uploads such a ConfigurationOfMyKillerApp to STHub it should automagically update the STHub description (which is currently only possible via the web interface) - additional rankings (number of downloads like on STHub, successful CI builds, member rankings, ...) - automated verfication - ... <snip>lot of other ideas</snip>
Bye T.
*Gesendet:* Sonntag, 08. Dezember 2013 um 22:12 Uhr *Von:* "Hernán Morales Durand" <hernan.morales@gmail.com> *An:* "Pharo Development List" <pharo-dev@lists.pharo.org> *Betreff:* Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser? Hi Torsten,
2013/12/8 Torsten Bergmann <astares@gmx.de>
The reason is simple: when I wrote the config browser there was no such additional description on the configs itself and one would have to load the config into the image first.
Think of 2000 config's (note each is a package) loading in the future when the config browser opens. This will take ages. I think this is not good since the app should be responsive.
Maybe a "show details" button helps when the package is selected.
I agree (see attached screenshot). I have added the button but the thing is: Package can be fetched from the repository, but there is no package description. There are only textual descriptions of commits.
So anyone see any workaround here?
I would rather see: 1. Either a simple hosted seaside app "Pharo Store" that one can use to register a config for a specific pharo version (similar like squeakmap) maybe directly from the STHub interface with description, ...
This app can be queried by the config browser (JSON/XML/Fuel/...) to display infos on the package, maybe also a rating about downloads, ...
2. Or a general mechanism that loads the configs, runs tests and if OK provides them for the config browser as "yes these config really work"
Absolutely. Configurations should be certified.
Hernán
The problem is that to see the description you will need to load all the configurations. So I think that the way to go is the following: - extend the catalog to generate a STON file with all the configuration and their descriptions - publish it in a stable url - fetch this description and display it in your tool. This would be really great. Stef On Dec 10, 2013, at 6:38 AM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Ok, in 12374 (incomplete, needs love)
https://pharo.fogbugz.com/f/cases/12374/Display-package-description-on-selec...
Cheers,
Hernán
2013/12/9 Stéphane Ducasse <stephane.ducasse@inria.fr>
Hi Hernan,
the problem is not the button - but the missing standard and standardized descriptions on the configs...
For instance I also write markup docu on my configs (see ConfigurationOfINIFile) - it is loadable as a usual config but adds two class side methods: #documentation and #tutorialOn: using the <onlineTutorial> pragma.
The documentation is stored as class comment in markdown format on the ConfigurationOfINIFile class. I use the same description then for the STHub project page.
If one loads additionally the "PharoOnlineHelp" package afterwards it will also appear magically in my Pharo online help as a tutorial. This was my proposal - but so far it looks like nobody is really interested.
this is not that this is a question of time. And sorry but I will not use markdown.
Maybe because often this ends in "which syntax" discussions and due to the lack of good in image default text display facilities for markup, pier-syntax, ...
In general it can be done easily, but we have to agree on some kind of "common standard" for configurations and documentation on - how to describe a package (also the format, either markdown or pier syntax with http://smalltalkhub.com/#!/~Pier/Pillar) - how to name the methods or pragmas that are used
Stef also did something (with Catalog), the ConfigurationOfINIFile for instance has two supporting methods: #catalogDescription and
#repositoryUrlString.
this one is deprecated after discussing with versioner.
Still Catalog uses Pier and is not really visible - and STHub does support markdown by default.
As of today I would like to see Pharo moving into the following direction: - using the configs for describing the help/documentation/package descriptions - also tagging with package categories (for instance there are packages/projects for "database access", others for "parsers", or "games") - maybe use pier syntax for descriptions (it can be parsed by Pillar and other formats like HTML, markdown, Latex, ... be generated) - generate pages like catalog https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? but with a better design and visibility like "http://packages.pharo.org"
The code is open. My time is really counted. Just merged your convention to mine and unify.
together with a loadable list for the config browser - when one uploads such a ConfigurationOfMyKillerApp to STHub it should automagically update the STHub description (which is currently only possible via the web interface) - additional rankings (number of downloads like on STHub, successful CI builds, member rankings, ...) - automated verfication - ... <snip>lot of other ideas</snip>
Bye T.
Gesendet: Sonntag, 08. Dezember 2013 um 22:12 Uhr Von: "Hernán Morales Durand" <hernan.morales@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser? Hi Torsten,
2013/12/8 Torsten Bergmann <astares@gmx.de> The reason is simple: when I wrote the config browser there was no such additional description on the configs itself and one would have to load the config into the image first.
Think of 2000 config's (note each is a package) loading in the future when the config browser opens. This will take ages. I think this is not good since the app should be responsive.
Maybe a "show details" button helps when the package is selected.
I agree (see attached screenshot). I have added the button but the thing is: Package can be fetched from the repository, but there is no package description. There are only textual descriptions of commits.
So anyone see any workaround here?
I would rather see: 1. Either a simple hosted seaside app "Pharo Store" that one can use to register a config for a specific pharo version (similar like squeakmap) maybe directly from the STHub interface with description, ...
This app can be queried by the config browser (JSON/XML/Fuel/...) to display infos on the package, maybe also a rating about downloads, ...
2. Or a general mechanism that loads the configs, runs tests and if OK provides them for the config browser as "yes these config really work"
Absolutely. Configurations should be certified.
Hernán
really simple 4 class side methods
OK, I see that this can be in Pier syntax. No problem for me, but that does mean that weâll need a Pier parser and renderer in the base image, no ? Else tools will not be able to show this, right ?
For the description and the keywords this is plain text. After the server is crawling the configurations and generating HTML using Pillar (now it is broken I have to check why). Note also that the fly by help of Nautilus shows this description as shown by guille a while ago. Nobody payed attention to this but this is really nice and supporting self documentation. stef
Nobody payed attention to this but this is really nice and supporting self documentation. i said i will weeks ago. I will try today. Alain
<Screen Shot 2013-11-07 at 16.14.26.png>
stef
Ok. I am taking a look now, still trying to figure out how Spec manage the layout offsets. Should I commit changes as a Slice in http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main ? Hernán 2013/12/7 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Dec 7, 2013, at 8:44 PM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
Is there a specific reason why this was not implemented? Is someone working on this?
We added catalog metadata to configuration now - the tools should take into account about that - people should add such metadata to their configuration
If you modify the package browser to present description it will be in the system
Stef
See the "Perl Package Manager" for example.
When you launch it, takes some time to update but each item displays the Details and you have an Abstract colum.
Cheers,
Hernán
On Dec 7, 2013, at 11:46 PM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Ok. I am taking a look now, still trying to figure out how Spec manage the layout offsets. Should I commit changes as a Slice in http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main ?
Yes with a bug entry. I will be great liek that I can browse my configruation :) Stef
Hernán
2013/12/7 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Dec 7, 2013, at 8:44 PM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Is there a specific reason why this was not implemented? Is someone working on this?
We added catalog metadata to configuration now - the tools should take into account about that - people should add such metadata to their configuration
If you modify the package browser to present description it will be in the system
Stef
See the "Perl Package Manager" for example.
When you launch it, takes some time to update but each item displays the Details and you have an Abstract colum.
Cheers,
Hernán
Hi Hernán, On Sat, Dec 7, 2013 at 11:44 AM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
Is there a specific reason why this was not implemented? Is someone working on this?
This is such a gaping hole in Monticello. I hope Pharo and Squeak can implement this compatibly. I hope the repository web interfaces can display the latest version of the package description too. And I also hope that any extension can be backward-compatible.
See the "Perl Package Manager" for example.
When you launch it, takes some time to update but each item displays the Details and you have an Abstract colum.
Cheers,
Hernán
-- best, Eliot
This is such a gaping hole in Monticello. I hope Pharo and Squeak can
I don't see it as a Monticello responsibility. MC should remain concerned solely with SCM. Configuration should be handled one layer above it. Whether by Metacello, SqueakMap, Installer, PackageInfo, Universes or something else of the configurators choice.
implement this compatibly. I hope the repository web interfaces can display the latest version of the package description too.
Which package do you mean by "the package"? Currently, package version comments _are_ already displayed by the web-interface. (So, this supports that we should not let the SCM tool dual as a Configurator).
participants (10)
-
Alain Plantec -
Benjamin -
Chris Muller -
Eliot Miranda -
Hernán Morales Durand -
kilon alios -
Stéphane Ducasse -
Sven Van Caekenberghe -
Torsten Bergmann -
Yuriy Tymchuk