The tool shed does not handle displaying images included in tool configs like this, nor does it properly link to other files that within the tool's subdirectory hierarchy to which the tool config may point. This is because the files are contained within an hg repository's internal .i files, and the process of deciphering the relative pointer, opening and reading the file and displaying it correctly is non-trivial. The tool shed displays most of the tool though, so the user looking at it is provided an overall general sense of what the tool does. Those developing tools that plan to host them on the tool shed should develop them as usual, not making decisions for the tool page based on what will or will not be correctly displayed in the tool shed. At some point I may make some improvements in this area, but it is nowhere on my development plans at the current time. On Dec 21, 2011, at 8:29 PM, James Taylor wrote:

Hrmmmmm... Don't know if we have a solution in the Toolshed for this yet. Greg, thoughts? Thanks!

-- jt

(composed on my phone)

On Dec 21, 2011, at 5:56 PM, Aaron Quinlan <aaronquinlan@gmail.com> wrote:

...

Okay, last question for the day. For some of the more complicated tools, I'd like to include a little PNG image as an example. I noticed that the gops XML files use references like:

.. image:: ./static/operation_icons/gops_complement.gif

However, I imagine you want something slightly different for Tool Shed tools. I couldn't find any docs on this - how should I setup my repository directory structure for using icons in the XML files?

Sorry to bother... arq

On Dec 21, 2011, at 1:37 PM, James Taylor wrote:

...

Excellent!

On Dec 21, 2011, at 1:31 PM, Aaron Quinlan wrote:

...

Works like a charm. Hoping to have a few tools up on the "shed" by the New Year. Speaking of, have a good one.

On Dec 21, 2011, at 12:58 PM, James Taylor wrote:

...

Aaron, right now Galaxy instances don't come with all the len files in the distribution, there is a cron script to generate them from UCSC tables.

Frankly, that is gross, I'm thinking we should do that once ourselves, keep it version controlled, and let people rsync it down.

But in the meantime, drop hg19.len in tool-data/shared/ucsc/chrom and you should be good to go.

On Dec 21, 2011, at 12:51 PM, Aaron Quinlan wrote:

...

Hey James,

I am putting the finishing touches on a first small release of bedtools on the tool shed. However, I am facing one likely trivial problem. GenomeCoverageBed, when accepting BED input, needs to know the chromosome sizes in order to do its work. On the command line, this done by passing it a chromSizes file as a -g option. However, I believe Galaxy can be told which genome one is dealing with for a given file. In turn, I imagine I can automatically point the tool to the correct chromSizes file without having the user explicitly say which file to use.

I guessed that this is what complement.xml was doing with the -l ${chromInfo} $allchroms call.

However, I can't get this to work. When I added ${chromInfo} as the -g option for genomeCoverageBed, it complained that it couldn't find hg19.len.

Can you point me to a link for how to do this? I imagine I am missing something obvious.

Best, Aaron

On Dec 1, 2011, at 10:46 AM, James Taylor wrote:

> On Nov 30, 2011, at 8:18 PM, Aaron Quinlan wrote: > >> So, I plan to just release XML configs and assume the user has installed the correct version until the fabric script support is present. > > This is definitely the way to go. > >> It'll happen. I hope things are going well. > > Okay, but do let me know if I can help. > > -- jt > > James Taylor, Assistant Professor, Biology / Computer Science, Emory University > > > >

Greg Von Kuster Galaxy Development Team greg@bx.psu.edu