slider range fix

[will-moore]

As noticed by @bramalingam, if images have min-intensity above 9999 then the slider range min was incorrectly set at 9999, since this was hard coded.
Same is true for slider max.
This should now be fixed.

To test:

• For image where min pixel intensity of a channel > 9999, channel slider min should be set correctly.
• Same is true for images where max < -9999, but it might be tricky to find such an image, so I think we can assume that if the fix works for min, it also works for max.

[jburel]

Do you have such images already imported?
if yes, could you indicate where they are?

[bramalingam]

@jburel : There were a couple of figures I had made with the python script, please check the following figure, http://web-dev-merge.openmicroscopy.org/figure/file/19810/

[bramalingam]

user-1 on eel

[jburel]

The range issue is fixed.
The text box with the value is too small
Still no background for the slider.

[will-moore]

The background for the slider is because the script we used has set the channel color to ffffff instead of FFFFFF which is what OMERO.figure expects.
If you set the channel colour to white in the app itself, you'll see the slider background grey.

[will-moore]

Last commit should fix the strange borders seen around image panels:

[jburel]

improving the "expected" value will be good i.e. handling both ffffff and FFFFFF

[will-moore]

Last commits should fix the slider background on channels with colour ffffff and
fix strange black borders on the same file (http://web-dev-merge.openmicroscopy.org/figure/file/20006/), see #213 (comment).

NB: This PR includes tiny fixes to shape-editor.js which should be ported to a new shape-editor 2.0.1 but that repo is currently being migrated to ome...

[joshmoore]

console.log tend to be removed, right? Have you looked into a longer-term debugging strategy? Likely depends on the framework of course but https://stackoverflow.com/questions/94934/what-debug-logging-tools-are-available-from-javascript

[waxenegger]

@joshmoore it's perfectly true that logs for development and debugging purposes should of course be taken out (for production) but the stackoverflow topic as well as other discussions are all based on what I would call an obsolete condemnation of the use of cosole.xxx methods for logging. They used to not be implemented by all browsers and/or undefined (if not in the dev tools) but that is a thing of the past: https://developer.mozilla.org/en/docs/Web/API/Console/log

I actually use console.error in some try/catch to log an error because given minification and loaders it is almost the only way to log an error and have the user (telling them to press F12) communicate the error to you. The only other way -and I have thought about this multiple times myself- is to implement as logging resource/service (restful I guess) and post errors to it via ajax. That could be fairly neat and relatively simple thing. Multiple web apps could make use of that.

[waxenegger]

Latest change works, choosing white color results in #ccc background.

[jburel]

@will-moore could you remove the console.log so we can merge it?
This PR prevents the reverse intensity one to be included

[will-moore]

@jburel Sorry, missed that. Removed it now.

[jburel]

Maybe also remove the change to shape-editor
This should be done in the correct repo

[will-moore]

@jburel Removed changes to shape-editor.

[jburel]

Changes can be made against https://github.com/ome/shape-editor
we can then tag and include the new version in the coming release of figure