These are chat archives for bigdataviewer/bigdataviewer-core

26th
Sep 2018
Christian Dietz
@dietzc
Sep 26 14:58
@ctrueden @tpietzsch we extracted the bdv-ui of @tibuch into a maven project... see https://github.com/gab1one/bdv-panel. The follow todos are open from our side:
  • rename to bdv package structure
  • transfer to bigdataviewer repository
what else would be needed to make it available on maven-central?
(such that we can reuse it in KNIME again :-)).
Curtis Rueden
@ctrueden
Sep 26 18:55
@dietzc The BDV currently uses the groupId sc.fiji, although we should consider changing that.
Supposing we want to release it under that groupId to Maven Central: firstly, all its dependencies need to be released to Maven Central.
Assuming that is accomplished, the next step is to use the travisify script to add encrypted credentials, so that Travis CI has the power to deploy it to its destination.

transfer to bigdataviewer repository

You mean move the bdv-panel repository to the bigdataviewer organization? Or would you integrated it into another repository there?

Gabriel Einsdorf
@gab1one
Sep 26 19:38
Move bdv panel to the bigdataviewer org
John Bogovic
@bogovicj
Sep 26 20:36
Curious what people think about : bigdataviewer/bigdataviewer-core#39
Curtis Rueden
@ctrueden
Sep 26 20:50
@bogovicj There is probably a big discussion lurking here about autoscaling display ranges, and type-specific default behavior, and nonlinear autoscaling, and extensible autoscaling, and ImgLib2 types whose full range exceeds double precision, and transfer functions in general... how much the BDV should know or care about all that, versus assuming the input data conforms to certain assumptions, which the caller must take care to meet. But to address your question about whether to break the API: could you introduce a change like the one you made, but with a new constructor signature, and keep the old one deprecated? That way it won't break API, but still gains the benefits of the new idea... you could avoid the "ctor overload hell" by introducing static factory methods a la FinalInterval and friends.
John Bogovic
@bogovicj
Sep 26 21:02
@ctrueden , definitely agree re: larger discussion. Thanks for having a look! and a new constructor signature could very well be the way to go