> 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.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 >
