Shoes image click weird behavior

[dredknight]

Dear all I experimented a bit with some rotation on images and bumped into a weird behavior.

Shoes.app do
   @my_image = (image("image.png", left: 30, top: 50).rotate 90)
   @my_image.click do
       para "nothing"
   end
end

For example if the image is a thin horizontal line and you flip it 90 degrees it becomes vertical but the click area remains what the original image area was (horizontal).

I have uploaded a test image below.

Why is this happening ?

[IanTrudel]

Why is this happening ?

This is very likely to be an oversight. Also, it may be challenging to implement for all degrees and other visual effects (blur, scaling, etc) that can be applied on an image. We don't have ways to test Shoes in a consistent, repetitive and automatic way. See #79 (specs) and #383 (@ccoupe suggested we generate events for GUI testing).

Well done. It is a good catch on your part. Thanks for reporting.

[ccoupe]

I just happened to have been looking at the hit detection code for #383 - the hit is for an image in a slot. In this case the default slot of the window which doesn't change (normally). Just a guess. Try putting the image in a an a second slot.

[IanTrudel]

Try putting the image in a an a second slot.

Good idea but doesn't seem to work.

[ccoupe]

It's always possible that rotate does not trigger a redraw of everything. What if you manually resize the window - just to generate an re-layout/redraw?

[IanTrudel]

It's always possible that rotate does not trigger a redraw of everything.

I don't think it's about redrawing. There are few hypothesis but let's stick to one here.. the internal values (at C level) are the original image position and size for which click event is using because rotate is drawn/applied in real-time (click event has no knowledge of).

It implies we should consider things like rotate, skew and so on as filters and apply them and make a distinction on the rendering and the original values (which we still need to keep considering rendering is in real-time). This would require some work to hack and a lot of work to make it the proper way.

What if you manually resize the window - just to generate an re-layout/redraw?

We have no way to handle this at the moment, aka #370 and #372. I suggested a resize event in #384 to handle resize event. In any case, resizing has really no effect on Shoes content according to past experiments.

[ccoupe]

In any case, resizing has really no effect on Shoes content according to past experiments.

This issue. This bug. Does it make a difference? I'm deep into so cranky places in the event branch and I rather not switch to master to test this.

[IanTrudel]

This issue. This bug. Does it make a difference? I'm deep into so cranky places in the event branch and I rather not switch to master to test this.

You don't have to break your back and bend backward. It's more important to get the event manager right. My understanding is that it is a long standing issue that nobody noticed until @dredknight do some experiments. It should eventually be fixed but this issue can wait.

[ccoupe]

Which is why you or @dredknight could try manually resizing the outer window with your mouse and report back what happens. Data collection.

[IanTrudel]

Which is why you or @dredknight could try manually resizing the outer window with your mouse and report back what happens. Data collection.

Already done. Not working.

[dredknight]

I opened this to report the issue so you can have it for future reference.
Workaround is easy - I just use image viewer to rotate the image so I do not need to do it in Shoes.

Let me know if I can help with something here.

[dredknight]

Decided to test how this issue is behaving with GTK3. It seems there is no change and it still exists.