Mouse scroll event

[arka6]

Hi, this is an enhacement proposal: Wouldn't it be useful to have a way to answer to the mouse wheel in shoes? Some time ago I asked this which later went to a ticket in shoes 4 and seem to work fine, but there's still no workaround for this in shoes 3. Any help?

[ccoupe]

Thanks for including the link to the Shoe 4 issue.

[arka6]

Thanks to you Cecil for keeping shoes walking. Any suggestion to start looking around about this?

[IanTrudel]

• Add g_signal_connect for scroll-event to the main window.
• http://stackoverflow.com/questions/10355779/how-to-catch-gtk-scroll-event-on-menu-item

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_SCROLL_MASK mask.

[ccoupe]

Sadly, I'm going to move this to Shoes 3.3.4 which doesn't fix anything. It's not lost.

[ccoupe]

I think I'll work on this. A year is a long time to wait. I need to collect some requirments. Based on the Shoes4 example, this mouse_wheel method would be documented in the manual at Shoes->App where the mouse() method is. Correct?

Shoes3 already has a shoes_app_wheel - It's short so your don't have to know much C, but there are assumptions in there. It looks like the place where we could invoke an app->wheel (e.g.) ruby block if set by a mouse wheel call from the app. That block would return true if it's handled the wheel event or false if it it wants Shoes to handle it.

We'll need some more args sent to shoes_app_wheel() built from the native event structures: Delta_x,and Delta_y? Gdk3 Cocoa

[IanTrudel]

It shouldn't be difficult to do though GDK_SCROLL_MASK needs to be passed down to all widgets or something like that. mouse_wheel is such a bad api name for Shoes. I thought scroll was more in line with what Shoes already has, e.g. click, motion, hover and keypress to name a few.

We'll need some more args sent to shoes_app_wheel() built from the native event structures: Delta_x,and Delta_y?

The most important is direction.

[ccoupe]

It shouldn't be difficult to do though GDK_SCROLL_MASK needs to be passed down to all widgets or something like that.

Sorry, It's not a native widget method! - it can only applied to a canvas/window (osx and gtk rules). and thats OK - write a test program - please, I need one. I know you believe you want a call back method for edit_box/ list_box/combo_box scrolling but those are native widgets and that's different from what was asked for and gtk is not the only toolkit involved.

The most important is direction.

You might have noticed ID dir is in the parameter list? Perhaps we need a 'how much' return value.? @arka6 ? It would help a lot to have a use-case/test-script

mouse_wheel is such a bad api name for Shoes.

I don't like it either and it's easy to change, for know - it's just a branch . I'm just following along with the Shoes4 response/example. app.scroll(t/f) would be misleading- IMO but we can take it up with the shoes4 folks now that we are unified.

[IanTrudel]

Sorry, It's not a native widget method!

You are correct but the problem is that GTK widgets will ignore the scrolls when the mask is not applied.

write a test program - please, I need one

The following simple test program should do.

Shoes.app do
   @p = para
   scroll do |direction|
      @p.text = "direction: #{direction}"
   end
end

RE: naming mouse_wheel vs scroll

The name for the physical wheel is either mouse wheel or scroll wheel. Both are valid. Now the wheel can be associated to different function/action than scrolling but it's physically scrolling anyway. So I would say that scroll still remains acceptable regardless of the function attached to it.

[ccoupe]

but the problem is that GTK widgets will ignore the scrolls when the mask is not applied.

Do you mean edit_box does not respond to wheel? Different issue and potential solution.

I'm going to name the method 'mouse_wheel' for now since it's the source of the event (like cllck() is or mouse() is) - it would be up to the user code how to respond to it. Scroll implies visual behavior will occur and that's not given.

Hopefully a wheel up event will provide a negative delta_y (down would be positive) or vice versa. If so, I'll return the singed amount which provides the direction and amount. OSX, of course will do it differently and it the user has configured his theme/system to do something else co-ord wise - we can't detect that.

[IanTrudel]

Do you mean edit_box does not respond to wheel? Different issue and potential solution.

It should always respond to scroll events. My understanding of the API is that our Shoes.app user-defined scroll event handler might have black spots when the mouse is over widgets that will not use the mask. So the widget will respond to the scroll but it won't go through the Shoes.app scroll handler.

RE: Scroll implies visual behavior will occur and that's not given.

The truth is that scroll would be just fine. We can argue both ways including there is no mouse wheel on a trackpad but still scrolling abilities. I never quite met anyone who didn't understand what scroll means on a computer, even when it is attached to different functions.

We really should avoid multiple words (and underscores) in Shoes API as much as possible.

Hopefully a wheel up event will provide a negative delta_y (down would be positive) or vice versa. If so, I'll return the singed amount which provides the direction and amount.

Shouldn't it always return a positive delta considering a direction is given? It is a one-dimension vector that can only go positive (because negative implies going in a different direction).

[ccoupe]

My understanding of the API is that our Shoes.app user-defined scroll event handler might have black spots when the mouse is over widgets that will not use the mask. So the widget will respond to the scroll but it won't go through the Shoes.app scroll handler.

Correct. Clicks are sent to native widgets, wheel events are sent to native widgets and that behavior - that won't change. It's only useful for app's that don't use native widgets. @arka6 really needs to tell us what he envisions or how he intends to use it. Until he/she responded, this is going back on the back burner.

[IanTrudel]

We may experience similar problems as we have with Shoes.app click, such as #329. Shoes.app events should always catch everything and let the user decide whether it is relevant or not. So this is where the mask will be relevant.

[ccoupe]

Shoes.app events should always catch everything and let the user decide whether it is relevant or not.

I don't disagree, that would be nice. Sadly, It would break every existing shoes script that depends on the current behavior and it would be a major rewrite of event handling, both gtk and cocoa and probably the Shoes 4 code as well. Maybe in Shoes-NG

[IanTrudel]

It shouldn't require major rewrite to do just that because most of the things can be passed down. However, investigating on whether it will break existing Shoes script is indeed important. I suspect it won't break much (or anything at all) considering how Shoes apps are developed but it wouldn't hurt to be sure.

Any pointer of existing Shoes scripts/apps that it would break? I can come up with a test script if you point me in the right direction.

[ccoupe]

Does Numinoes return t/f when it want to process a click or pass it on to a native?

[IanTrudel]

Does Numinoes return t/f when it want to process a click or pass it on to a native?

It's rather an object based approach for which Shoes.app click event is unnecessary.

The board contains 64 playable squares. Each square is a stack with its own click event. Each stack has various states (such as clickable, image, and so on) for which click events, drawing, etc. know how to handle.

Therefore, Shoes.app click and other global events passthru wouldn't affect Numinoes.

[ccoupe]

The click/wheel event goes to the widget with focus. If there is no widget or no focused widgets, then it can be sent to app.click, app.mouse_wheel. It's been a GUI principle forever, along with Click to focus.

[IanTrudel]

It is always been possible for a global event in any GUI to be triggered in addition to existing event handlers. This would make Shoes event handling quite powerful.

Now you may feel strongly about your way. Perhaps we should consider a compromise with an extra parameter for Shoes.app event handling? The default behaviour would be exactly what Shoes is currently doing and the parameter would allow all event passthru.

Shoes.app do
  click(passthru: true) do
    # do something important
  end
end

[ccoupe]

cocoa.m:178 shows the osx implementation of the wheel for ShoesWindow (top level window). Interesting that it uses the delta_y to compute the direction. You can study how mouse events are processed as well as keypress. Pretty simple, as are the shoes_app_methods they call

The only thing preventing those events not be sent to the app.click is if the native widgets/toolkit is delivering clicks to buttons and checkbox and so on. For passthru widgets (Gtk and Cocoa or Shoes level) would have to have code that checked for the click passthru and called it instead (and un-focus as well). There would be issues with x,y since those tend to be inside the widget. Lot of work for someone. I don't see the utility as being worth the effort.

[ccoupe]

I forgot that click (and other events) are defined on canvas. This demonstrates that:

Shoes.app do
  stack height: 200 do
    click do |b,l,t|
     @p.replace "Stack clicked"
    end
    @p = para "None"
    flow width: 200 do
      para "Flow 1"
      click do |b,l,t|
       @p.replace  "Flow 1 clicked"
      end
    end
    flow width: 200 do
      para "Flow 2"
      click do |b,l,t|
       @p.replace "Flow 2 clicked"
      end
    end
  end
  click {|b,l,t| @p.replace "default slot clicked"}
end

Based on that and reading the manual for Slots->Events the better name for the proposed new canvas method is 'wheel' and we can safely say Shoes3 does not and never did have a global event handler for a Top Level window (a Shoes app instance) Should it? What would it look like, what would it do?

Should a wheel move be sent to the existing motion block. Perhaps it is? @arka6 ?

[IanTrudel]

we can safely say Shoes3 does not and never did have a global event handler for a Top Level window (a Shoes app instance) Should it? What would it look like, what would it do?

Isn't the last click a global event handler? "Default slot clicked."

I occasionally use global event handlers such as motion and keypress in colours sample. You would be correct in assuming most of the time click events are and should be attached to elements (stacks, images, etc). One example that I used a global click event was to build a visual GUI builder but the current limitations prevent it to be fully usable.

RE: wheel vs scroll

My favourite would be scroll but I could live with wheel.

Should a wheel move be sent to the existing motion block. Perhaps it is? @arka6 ?

No. They are completely different things.

[ccoupe]

Isn't the last click a global event handler? "Default slot clicked."

Not really, it's the event handler for the first slot for the window. (there is always a first slot). It's not attached to the app/window but to the slot. It's subtle but it's is very different and enforced by the current code. It's not not called if you have more specific click handlers. Try it - replace the @p.replace with 'puts' There is no explicit chain of event handlers that I can see so so that every event gets reported to the "first one"

If you look at the code in canvas.c it descends down or across the tree of slots/and almost native widgets like image/svg/plot to find a click handler and adjusting x.y as it goes down . Your GUI builder does not want to do that for the window your building (a different app instance). You want to turn off events in that second window so that has be an app setting - not a canvas setting.

[IanTrudel]

RE: event on slot

This is basically what I meant by global event handler. For all intent and purpose, it's the same here but I understand that on technical side it is not.

RE: visual GUI builder

This is just a proof-of-concept so far. I wrote hundreds of proof-of-concepts on Shoes but only a few make it to you guys. It got to make sense in the end, right? On the other hand, that would be a really good feature to provide with Shoes. No hurt in talking on how to make it happen. You may have a better approach.

[ccoupe]

It would be easy to store a last event in app global coords witth osx for a ShoesWindow. Not so sure sure about gtk3. swt appears to do that for the Shoes4 example that @arka6 referenced -yes @arka6 I will badger you to explain your request in more detail until I can see your don't care. Leaning that way.

app vs slot is one those things that makes shoes difficult for advanced developers.

[ccoupe]

Closing - Shoes 3.3.5 has a wheel {block}