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%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. 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.mora...@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 <asta...@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
