On Thu, Jun 16, 2011 at 3:26 PM, Greg Von Kuster <g...@bx.psu.edu> wrote:
> Hi Peter,
> I understand, and that is why I am working feverishly to add features
> that do not force the use of hg form the command line (I've got several
> features functional, but not everything yet).  The current tool shed requires
> some use of hg if you want to delete files from the repo, but other than that,
> hg is not really required.

That's great, but I do feel the new hg went live a bit prematurely.

> The current tool shed also provides some very useful features (e.g.,
> browsing tool code files) that were not available in the old tool shed.

Really? I find the browsing the tool code files has regressed.

In old tool shed had a simple non-interactive tree of the files
visible on the main page for a tool or suite, where the individual files
could be clicked on to view/download. It was simple and effective
(at least when there weren't many files which seems typical).

The new tool shed makes you click on tool actions, browse repo,
and then gives an interactive tree which is fully collapsed by default,
forcing lots more clicking to drill down to the files. All that clicking
makes it slow and fiddly to use.

> In addition, tool developers are no longer forced to to the extra work
> that was necessary in the old tool shed to add a tool (i.e., there is no
> longer a requirement for tool suite config definitions ).

For tool suites you have a point, that was a bit of a hassle.

> My hope is that the current features make everyone happy
> enough that they will be able to wait for those messing featuers
> that are wanted, using the current features in the meantime.

It'll get there :)

Another big regression I would prioritise is the complete lack of
any user provided text on a tool's main page. The old tool shed
had the minimal text box where you could summarise the tool,
its requirements, recent changes etc. The new tool shed has
nothing to replace this as far as I can see.

A simple wiki like, ReST, or just plain text details box would do.

Automatic detection of a readme text file in the repo, to be
displayed on the tools' main page would be an elegant solution
(are you familiar with how github.com does this?). It also keeps
the description in the hg repo which is a plus point.

The mock up idea would be another (more complex) way to
tackle this, https://bitbucket.org/galaxy/galaxy-central/issue/565


Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:


Reply via email to