Hello @kne42! Thanks for updating the PR.

• There are no PEP8 issues in the file gui/elements/_viewer.py !

• There are no PEP8 issues in the file gui/elements/_window.py !

• There are no PEP8 issues in the file gui/elements/qt/_viewer.py !

• There are no PEP8 issues in the file gui/layers/__init__.py !

• There are no PEP8 issues in the file gui/layers/_base.py !

• There are no PEP8 issues in the file gui/layers/_image.py !

• In the file gui/layers/_layer_list.py, following are the PEP8 issues :

Line 63:5: E301 expected 1 blank line, found 0
Line 64:5: E301 expected 1 blank line, found 0
Line 65:5: E301 expected 1 blank line, found 0
Line 66:5: E301 expected 1 blank line, found 0
Line 67:5: E301 expected 1 blank line, found 0

• In the file gui/layers/_register.py, following are the PEP8 issues :

Line 76:17: E201 whitespace after '{'
Line 76:26: E203 whitespace before ':'
Line 76:32: E202 whitespace before '}'

• There are no PEP8 issues in the file gui/layers/_visual_wrapper.py !

Comment last updated on October 23, 2018 at 00:18 Hours UTC

What if a layer does not define the notion of 'shape' -- that's very much an image-centric concept.
I would suggest that in that case, you simply ignore that layer for the purpose of computing the
max shape parameters... In general, pay attention to the generality of a layer's base properties,
an devise elegant strategies that address this. Luckily, many properties -- such as opacity -- exist for all layers...

@royerloic Actually I would like to require some sort of required API that helps us determine the shape of the layer (perhaps even by slice but this may be costly in terms of memory) so that we can show a visual selection rectangle on the gui to allow users to move, scale, and rotate the visual.

Ok, makes sense. Maybe my question really is: what units do we have for 'shape' if the units is pixels of images that would work, assuming that we use the same units for the coordinates of other layers...
So, in fact if we think about a 'points' layer, you could set the shape to be (1000,1000) or (123,456), that would then help understand how to position the pints within a bounding box... But that also means that we need to know more that just with and height... We actually need (x, y, width, height) to be able to really make sense of the point coordinates -- note that (x,y) is a corner of the box.... Of course from that bounding box, the shape is trivially inferred. In most cases (x,y) will be (0,0), but it does not have to be (even in stacked mode! we want to keep the coordinates of the points relative to the box!). I am actually realising all this while I write.

Important: just as for image layers, other layers can have different shapes, but can be stacked together nevertheless, using the bounding box info...

Ah, perhaps we should instead just require them to provide their ndims and some function that returns (x, y, width, height) given a set of indices (like in _set_view_slice)?

why can't we infer the shape to be the min and max of the data? This should be super fast. If we want to allow offsets, we can add origin=(0,) * ndim as the default, but settable by new layers.

Oh you mean because you are doing all this crazy resizing/moving around inside the canvas that I told you was a bad idea? =P

Ok I'm gonna wait till our meeting to discuss since I feel some drawing is required. =)

I'm looking through the PR right now and ran into a problem not sure what I'm missing. When I run the following code the opacity and colormap changes work fine, but I get an error message when trying to change the clims. It's nice that when I change the opacity etc. the gui window automatically updates

window = gui.imshow(patch)
layer = window.layers[0]
layer.opacity = .5
layer.colormap = 'viridis'
layer.clim = (0,100)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-54-e8219f68bee2> in <module>()
      3 layer.opacity = .5
      4 layer.colormap = 'viridis'
----> 5 layer.clim = (0,100)

TypeError: clim() takes 1 positional argument but 2 were given

Thanks! No rush. I also think I've encountered the opacity bug you mentioned at the top of the thread, and saw your chats in vispy. Looks like it is being handled there

Is there a remove layer / delete layer function? Would be nice.

Also might be nice to be able to create an empty window, could be with something like window = gui.imshow()

Another thing that might be nice is if you pass a list of images window = gui.imshow([A, B]) then you get two layers with A and B inside them respectively

Also is it worth including the concept we talked about on thursday where if we call window=gui.imshow(A, layers=[2,3]) where dim(A)=5 say, then we'd get a collection of 3D images all as different layers. I guess an argument against this is that a simple reshape and list comprehension would generate a list of arrays that could then be passed to imshow if the behaviour in the above point is supported. A pro though is this is something people might want to do often for color-channel dimensions and it could be a convenience to do it inside imshow. I can really see it both ways.

Also unclear to me why window.add_image(image, meta) and gui.imshow(image, meta=None, multichannel=None, **kwargs) take different inputs, it would seem to me that they should take the same, and that we might as well have window.add_image(image, meta=None, multichannel=None, **kwargs)

Yes, right now this is implemented as Viewer.layers.remove(layer).

ok nice, i get it now, it's just like any list, i can use remove or maybe easier pop with a coordinate. thanks it works for me