ENH: updated SliceTracker logo and contributors

[che85]

No description provided.

[cpinter]

If I paste this URL in the browser, I get a 404. The previous link, however, works

[fedorov]

Oops - thanks for checking!

[fedorov]

This is the correct URL: https://www.slicer.org/w/images/b/b1/SliceTracker_Logo_1.1_128x128.png

[fedorov]

@che85 the wiki does not maintain the prefix for the uploaded file.

[che85]

@cpinter let me check that. I am having some issues with the wiki. Updating the previous logo didn't even work properly.

[che85]

@cpinter I am also having some issues with the SlicerDevelopmentToolbox where I set the iconURL to a raw image on github, but it never shows up in the ExtensionManager... Do you know why that happens?

[fedorov]

Ah, now I remember - I've been through this before!

The issue is that Slicer factory does NOT take the icon URL from s4ext, but takes it from the CMakeLists.txt (here as an example, which you didn't update: https://github.com/SlicerProstate/SliceTracker/blob/master/CMakeLists.txt#L10).

It is super-misleading. I had a long discussion with @jcfr somewhere about this, but I don't remember where. Basically, you have to accept it!

[fedorov]

In SlicerDevelopmentToolbox CMakeLists.txt your icon URL is invalid: https://github.com/QIICR/SlicerDevelopmentToolbox/blob/master/CMakeLists.txt#L11)

[che85]

I don't understand. It worked in the beginning. Did anything change regarding the wiki?

Another thing that I don't get is why I have to define dependencies in both CMakeLists.txt and within the s4ext. Wouldn't it make sense to get all those information from the CMakeLists only? Same for the icon url ...

[che85]

Does the icon actually need to be 128x128 or would it be automatically scaled down if it's larger than that?

[fedorov]

I don't understand. It worked in the beginning. Did anything change regarding the wiki?

It probably will be difficult to identify what exactly "worked in the beginning". Did you have a URL that worked before, and doesn't work now?

Wouldn't it make sense to get all those information from the CMakeLists only?

I did find the earlier discussion that I had in mind: #1425

Does the icon actually need to be 128x128 or would it be automatically scaled down if it's larger than that?

I don't know.

[cpinter]

This may be the same issue that caused my newer tutorials and files become unavailable. They changed the file storage on the wiki and now these generated links are unstable it seems. For example, embedding links within the wiki pages is only possible with the relative wiki reference. I started using Midas to store files I link to statically.

[fedorov]

I agree it is good idea not to have Slicer wiki anywhere in the critical path.

[fedorov]

I started using Midas to store files I link to statically.

@cpinter note that Midas's fate does not look very exciting, based on the discussions we had with @jcfr at the 2017 Winter project week Girder session. You might want to consider using yet another alternative. One possibility is GitHub releases, which can be used to store binary data. Basically, you can attach any binary payload to your GitHub repository. We use this mechanism in some projects already.

[jcfr]

(1) wiki and icon url

They changed the file storage on the wiki and now these generated links are unstable it seems.

Older wiki URL are expected to remains. Let's work with Greg to address this.

cc: @pieper

(2) midas for storing images

using Midas to store files I link to statically. + Midas's fate does not look very exciting,

Unless we explicitly ensure old URL remains valid (which we will do our best to maintain), these urls will likely change when we will transition to an other data management system.

(3) Github issue and/or released used to store images for embedding in documentation

Github release to store images, etc ...

GitHub release raw URLs will change as they already did in the past. Maintaining permanent URL is not part of the public "API".

An easier approach is to associate all images with a GitHub issue and use the raw link. Same thing, raw link will change as they did in the past.

(4) Improvement to s4ext

Improvement to s4ext

An option would be to trim the information available in the description file to the minimum required:

scm
scmurl
scmrevision

with the following one being optional

depends
build_subdirectory
svnusername 
svnpassword

It is super-misleading. I had a long discussion with @jcfr somewhere about this, but I don't remember
where. Basically, you have to accept it!

The system is not perfect and can definitively be improved. See proposal above.

Currently, CMakeLists.txt is the "source" of the metadata and the only file with the metatdata available in your extension source tree.

s4ext is then generated from it. You can for example find it in your extension build directory.

If you happen to manually update the description file already available in the extension index ( which is indeed very convenient). You would have to make sure that redundant metatdata (url, ...) match.

[fedorov]

GitHub release raw URLs will change as they already did in the past.

I didn't know that!

Improvement to s4ext

I've just started a Labs page about ExtensionsMetadata, as I promised long time ago, but forgot.

What do you think about codemeta for describing extensions (and Slicer itself, for that matter!)? Here's an instantiation of their schema that also helps to get an idea: https://github.com/codemeta/codemeta/blob/master/codemeta.json.

[lassoan]

What do you think about codemeta for describing extensions

I like it. I don't see anything specific that would make it stand out of the crowd of software metadata file formats, but it's better than the current completely arbitrary format that we use now. Most current tags don't have direct mapping to codemeta (scm type, revision, username/password, iconurl, screenshoturls, etc.) but I guess we can just add new tags for these; and maybe even request adding them of them to codemeta.

[fedorov]

@lassoan can you point to some other examples of software metadata formats, or add those to the labs page?

GitHub release raw URLs will change as they already did in the past.

@jcfr I followed up on this with GitHub support, and here is what they said:

"We don't expect this URL format to change, and we take breaking changes very seriously to our APIs and URLs. However, I can't promise that this URL format will never change."

So if I had to choose between Slicer wiki, Midas and GitHub releases for storing the data, it seems to me GitHub has most robust support and maintenance.

[jcfr]

Thanks for following up.

Assets associated with documentation

Generally speaking, it should be possible to find, manage and update the assets (images, ...) associated with the documentation text where the documentation text is itself managed.

This means that Midas (or girder) is probably not the solution to manually store assets associated with documentation managed on outlet like the slicer wiki or git-book, ...

Testing data

To manage test data, I like the approach applied by ITK community (cc: @thewtex) where they have redundancy of storage locations with the sync of these locations being handled automatically.

In a nutshell, during active development data are uploaded to Girder (aka https://data.kitware.com), then after each release, data are consolidated across different mirrors (e.g github, ... ). This ensure that around 90% of the data required for testing are served from highly efficient and distributed server. The other 10% being added during the on-going active development cycle.

Use of GitHub release for data storage

GitHub release are awesome. They allow to serve the build artifacts. That said, using them to host scientific data require some tooling to properly manage and update them.

Worth noting that, if this is relevant to your use case, only two weeks of download stats are available ...

[fedorov]

during active development data are uploaded to Girder

Is Girder open for uploading the data by any Slicer developer?