Web dialogs stealing focus within my tool.

Dan Rathbun

BTW.. I think Fredo was playing with a way to draw toolbar or setting controls, directly onto the model viewport during a tool's active state.

driven

@eneroth3 said:

... so the shortcuts keys within my tool doesn't work until the main window is clicked.

thinking out load...

why send the shortcut when you can send your tool an instruction directly?

john

jolran

I fiddled a bit with this, but it activates the shiftkey after shift+c. Maybe it can be improved... Paste in ruby code editor or such. Only tried in Windows..
BTW I think it might be better to use onkeyup then onKeyDown since it fires so often..
Also combinations might be harder to track..

@dlg = UI;;WebDialog.new()
   @dlg.set_size(400,200)
   RUBY_PLATFORM =~ /(darwin)/ ? @dlg.show_modal() ; @dlg.show()
   
   def html()
      html =  %Q(
         <!DOCTYPE html>
         <html>
         <head>
            <meta http-equiv="content-type" content="charset=UTF-8" />
            <meta http-equiv="MSThemeCompatible" content="Yes" />
            <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
            <style>
           body { background-color;grey;}
           h1 { color;white; }
            </style>
         </head>
         <body>
         <h1>Press shift,ctrl, shift+c or other</h1>
            <script>
            
            function sendtoRuby(ki) {
               window.location.href = 'skp;keyspressed@'+ki;
            }
            
            window.onkeyup=function(e) {
               var kc = e.keyCode;
               if( kc === 16 &&! e.shiftKey ) {
                  return sendtoRuby("shift");
               } else if( kc === 17 &&! e.ctrltKey ) {
                  return sendtoRuby("ctrl");
               } else if( e.shiftKey && kc === 67 ) {
                  return sendtoRuby("shift+c")
               } else {
                  return sendtoRuby(kc);
               }
            }
            
            </script>
         </body>
         </html>
      )
      html
   end
 
   def testkey(pressed)
      puts pressed
   end
 
   @dlg.add_action_callback("keyspressed") {|d,params|
       testkey(params)
   }
 
   @dlg.set_html(html)

eneroth3

@driven said:

@eneroth3 said:

... so the shortcuts keys within my tool doesn't work until the main window is clicked.

thinking out load...

why send the shortcut when you can send your tool an instruction directly?

john

Then I have to make a separate list of what to do with what key. I haven't written any of this code yet but the idea was to have one javascript function for all my different tools that just sends the key code to onKeyDown which differs between the tools and and does different things with different keys.

@dan rathbun said:

BTW.. I think Fredo was playing with a way to draw toolbar or setting controls, directly onto the model viewport during a tool's active state.

I've thought about that but it would require me to recode a lot of stuff. Also some of the web dialogs are quite big so it's good to be able to move them around so they don't cover the part of the viewport where the user currently draws.

eneroth3

I've just written the code and it seems to work nicely.

External javascript file (loaded by all web dialogs:


function port_key(){
  //Sends the keycode from the event to a Ruby callback.
  //This can be used for web dialogs inside a custom tools to send key events to the tool to change its behavior even when the web dialog is focused.
  //Run "document.onkeyup=port_key;" to initialize. onkeyup is used to avoid overriding calls to onkeydown already in use in the dialog. onkeypress doesn't fire for modifier keys.
  e = window.event || e;
  keycode = e.keyCode || e.which
  
  //It might be wise to only proceed for certain keys here, e.g. modifier keys or whatever keys are used in the tool.
  
  window.location='skp;port_key@' + keycode;
}

In Dialog.show:


js = "document.onkeyup=port_key;"
@dialog.execute_script js

Dialog callback:


#Port key event to tool
@dialog.add_action_callback("port_key") { |_, callbacks|
  self.onKeyDown callbacks.to_i, false, 0, Sketchup.active_model.active_view#This tool doesn't use flags so it can just be set to 0
}

I haven't really bothered locking into the flags since my tools doesn't use them, just tab, alt, and arrow keys.

Here's a list of the constants representing key codes in SU and here's the key codes from the javascript events in different browser.

It's only tested on windows but the key codes seem to match quite well for most of the keys. My code might have some Mac bugs though, idk since I can't test it.

Dan Rathbun

There is a difference between your code calling a key handling callback, and the SketchUp engine doing it.

The SketchUp engine bubbles the keyCode up to the application, (something that often causes the exit from a custom RubyTool.) The API does not have an "official" way to sen keystrokes to SketchUp, but there are some platform dependant ways. On PC, you use the Win32OLE class and sendKeys() method from Windows Scripting Host (WScript).

tt_su

I've used the Win32 for this in the past:
https://bitbucket.org/thomthom/tt-library-2/src/9ff3a5f08604ed477eb4b17fd63612bfc42832dd/TT_Lib2/sketchup.rb?at=Version%202.9#cl-88

Never found a OSX solution though.

eneroth3

To make this script 140% complete you probably need to send those key events directly to the Sketchup main window as Dan says and also make the javascript function check that no form input is currently focused.

However this seems to solve my issue and the only thing you need to do in my plugin to be able to use all Sketchup shortcuts is to either click in the main window (just as before) or close the web dialog containing the tool settings which automatically activates the select tool.

Aerilius

Would there be a way for SketchUp to modify WebDialogs to "continue bubbling up" from the document root to the SketchUp main window?

I've implemented something similar to jolran's method that sets a Tool class variable for the status of the ctrl, shift and alt keys (Select Entity tool in Ruby Console+).

tt_su

@aerilius said:

Would there be a way for SketchUp to modify WebDialogs to "continue bubbling up" from the document root to the SketchUp main window?

That would be a great feature. I'd love to see some improvements to the Tool class and in particular the WebDialog class.

If people can flesh out use cases and scenarios that's be of great help to determine the shape of these improvements.

eneroth3

Sidenote: when using paint bucket tool and the main window is focused the mouse cursor changes wen pressing and releasing modifier keys as expected. When the material browser is focused the mouse cursor changes when pressing down a key BUT NOT when releasing it. However the mouse cursor updates as soon as you move the mouse so the tool seems to know that the modifier keys aren't hold down, it's just the cursor that doesn't update.

Tested in SU 2013 and 2014 on Windows7

jiminy-billy-bob

@tt_su said:

If people can flesh out use cases and scenarios that's be of great help to determine the shape of these improvements.

In Layers Panel, I wanted to allow users to use their SU shortcuts even if my dialog was focused (Except the ones I trap).

Aerilius

Scenario 1:
When a webdialog is designed to be used in parallel with the currently selected tool (any replacement for a native inspector dialog, like layers panel), not consistently workig shortcuts interupt the user's workflow.

Scenario 2:
When a webdialog is used as toolbar to launch a tool, the tool won't get modifier keys until you have clicked at least once into the drawing (and maybe you didn't want to do that click).

eneroth3

I've been thinking about an implementation. In some cases the developer might not want this so it shouldn't always be enabled (and it could break existing plugins). What about an extra argument for creating web dialogs that by default is false?

There could also be a check on the web side that prevents the key event from being sent to SU in case an input or textarea element is focused.

One scenario where the developer don't want to send the key events to Sketchup (except for the obvious one of writing in a form) could be custom shortcuts within the web dialog (save, reload etc).

Dan Rathbun

It would be alot simplier if there was a UI::send_keys() module function very similar to (or wrapping) this Windows Scripting Host function:
http://msdn.microsoft.com/en-us/library/8c6yea83(v=vs.84).aspx
.. in fact here is a C++ implementation:
http://www.codeproject.com/Articles/6819/SendKeys-in-C

Aerilius

@eneroth3 said:

In some cases the developer might not want this so it shouldn't always be enabled.

Absolutely right!

The event bubbling concept in the HTML DOM allows to "cancel" further bubbling, if your event listener has already "fullfilled" the event and there is nothing left that you want to happen (otherwise the next, outer event handlers would get the event and act on it). Expanding this concept from WebDialogs to the SketchUp window could be done re-use something with which developers are familiar, without adding new API methods or arguments.

No matter how it would be realized, it would really be useful for us developers if SketchUp could incorporate this feature.

Would it make sense to allow this for different kinds of events, or should it filter out all except keyboard events?

Dan Rathbun

@aerilius said:

Expanding this concept from WebDialogs to the SketchUp window could be done re-use something with which developers are familiar, without adding new API methods or arguments.

How can a feature be added, without adding some interface to the SketchUp API ? Impossible.

There needs to be some key_bubble flag ( true by default for backward compatibility,) that the SU engine checks in Tool class instances.

Basically the engine would do a check like:
bubble = tool.respond_to?(:key_bubble) ? : tool.key_bubble : true

We need to concentrate the talk on keystrokes. Other events just complicate the issue.

tt_su

You can already return true/false in the key event to prevent some propagation.

Dan Rathbun

@tt_su said:

You can already return true/false in the key event to prevent some propagation.

In Ruby ?

tt_su

Aye.
One of them things not mentioned in the docs I think. (On our list to fix.)
I came across it once when I noticed odd behaviour with key events and realized it depended on the return value of my last statement in the onKey events.