[Update] Toolbar for Fusion 16 Viewer [SUBMITTED]

[andromeda_girl]

oh thank the gods...
at last, the fu16 GUI is now a step closer to functional.
thank you.
i can't wait to have this sucker installed...

we just need the rest of its GUI to be fixed now...
no futt-bugly icons... wasted space... other hidden tools... fit to view covering up functions...
omfg who designed the fu16 GUI anyway?

Added in 31 minutes 47 seconds:
so... how do you get it to dock into the actual gui instead of being a floating bar?
O_o

Added in 2 minutes 45 seconds:
... just to clarify; it opens on mouse pointer position-
however your mouse pointer is always going to be located where the reactor dropdown menu is; specifically the location of where the toolbar16 is listed in here
...meaning it will land in that spot.
can it not be docked into the GUI?

[AndrewHazelden]

Hi @andromeda_girl.

Earlier on this thread Movalex posted the hotkey combination for automatically showing the toolbar window:

I use shortcut to launch the script, and it shows just where I need it. I put cursor under the PlayForward button where split window cursor appears and and press alt+shift+T

[Movalex]

Thanks for kind words, I've spend some time making this usable. And it would not been possible without great support of WSL community.
After you set the position you like, you can turn off launching at mouse position in preferences (little triangle on the right). Next time UI is launched, it will restore position. You can also dump saved position with the button in prefs!

[Movalex]

Small update for Toolbar16, to make it compatible with latest Fusion versions (16+)
https://gitlab.com/WeSuckLess/Reactor/merge_requests/95

[SecondMan]

Available now!

[Lester]

So glad I found this! Got it in my reactor now. Thanks for the development!

Would it be possible to add a "Normalize Color Range" button to this? I find the right clicking in resolve to get to it rather cumbersome. Is there a hotkey I'm missing for this task?

[Movalex]

Thanks @Lester!
Unfortunately, I did not find any mentions of "Normalize Color Range" in current API.

[bfloch]

Feels like my productivity just went back up. Thanks!

[Movalex]

Hey, guys, I wonder if I can make this tool somewhat more useful.
1) First, I'd like to make the window draggable. But I would like to leave it headerless so it would be as small as possible.
There's number if hints how to move frameless window with some QT hacks with onMouseY(X)Changed (https://evileg.com/en/post/280/) with, but I'm not sure, how to implement this in Fusion.
If we could add this frame dragging feature, we could make it more like a floating toolbar we've had in Fusion9
@PeterLoveday? Someone?
2) While Fusion16 toolbar is not much useful since it is not detachable and too large (to my taste), it still has some advantages: floating tooltips and draggable tools, we can move them to the flow. Is it possible to do with current UI manager?

[AndrewHazelden]

Hi @Movalex.

One option is to scan for a keypress code when the mouse is inside the Toolbar window region, then read the current mouse cursor position onscreen when you release the keypress. Then the window geometry could be moved to new location with an offset value aligned to the button/control.

Another option is to live adjust the window position after a user clicks on a custom "move window" ui:Button ui:Icon on the Toolbar GUI. This could be done on the click or the release state of the button. And you could make your button look like the "frame dragging feature" icon you seem to like already.

Similarish Examples in Reactor

Look at the "HypertextCompositor.lua" script for an example of keypress checking when you hold down the "shift" key and click on a hyperlink in the HTML document preview window.

For a general-purpose window geometry moving example you could check out the "UI Manager Lua Examples" atom package for the "Window Snap" demo which is found at "Reactor:/Deploy/Scripts/Comp/UI Manager/Window Snap/Window Snap.lua". It had a bit of extra intelligence added to that script to check for an unset window layout preference this week. IIRC the geometry values are checked to see if they are unset at a value of something like "-1". Then the Fusion global preferences window "Layout" section is auto-opened to help guide the user towards that required step.

KeyPress Basics

Near the top of your UI Manager "AddWindow" tags, just after "ID", "TargetID", "WindowTitle", and "Geometry" you should add an "Events" chunk of code:

Events = {Close = true, KeyPress = true, KeyRelease = true,},


Then after the "win:GetItems()" section add a chunk of keypress scanning code like this:

Code: Select all

-- Add your GUI element based event functions here:
local itm = win:GetItems()

-- Track if the shift key is currently held down
shiftKeyPressed = false

-- The shift key was held down
function win.On.htmlWin.KeyPress(ev)
	if ev.Key == 0x1000020 then
		shiftKeyPressed = true
	end
end

-- The shift key was released
function win.On.htmlWin.KeyRelease(ev)
	if ev.Key == 0x1000020 then
		shiftKeyPressed = false
	end
end

Then finally you could add code to a "move window" button like code snippet has:

Code: Select all

-- Move Window Button
function win.On.MoveButton.Clicked(ev)
  if shiftKeyPressed == true then
    -- Read the mouse XY position
    local x = fu:GetMousePos()[1]
    local y = fu:GetMousePos()[2]

    -- Add your code here
    -- ...
    -- ...

    -- Possibly force unset the shift key pressed flag
    shiftKeyPressed = false
  end
end

This concept was derived from PeterLoveday's original keypress comments and code snippets on WSL here:

Detect shift-click in a script button?
https://www.steakunderwater.com/wesuckl ... 693#p23693

[Movalex]

Wow, thanks for this treasure, @AndrewHazelden!
I will try to digest it asap and will make another tool update.

[Movalex]

Hi, @AndrewHazelden!

Looks like keypress events don't work with borderless windows... I have WindowFlags = {SplashScreen = true} set.
Maybe I'm doing something wrong?

Code: [Select all] [Expand/Collapse] [Download] (KeyEvents.lua)

1. local ui = fu.UIManager
2. local disp = bmd.UIDispatcher(ui)
3.  
4. win = disp:AddWindow({
5.     ID = 'Win',
6.     Geometry = { 0, 0, 200, 100 },
7.     WindowTitle = 'KeyEvents',
8.     WindowFlags = {SplashScreen = true},
9.     Events = { Close = true, KeyPress = true, KeyRelease = true, },
10.     ui:VGroup{
11.         ui:Button{ID = "Button", Text = "Button",},
12.         ui:Button{ID = "Close", Text = "Close"},
13.         },
14.     })
15.  
16. itm = win:GetItems()
17.  
18. function win.On.Win.Close(ev)
19.     disp:ExitLoop()
20. end
21.  
22. -- A flag to track shift state
23. local shiftdown = false
24.  
25. function win.On.Close.Clicked(ev)
26.     disp:ExitLoop()
27. end
28.  
29. -- If the shift key is pressed, set our flag
30. function win.On.Win.KeyPress(ev)
31.     if ev.Key == 0x1000020 then
32.         shiftdown = true
33.         itm.Button.Text = "Shift+Button"
34.     end
35. end
36.  
37. -- If the shift key is released, reset our flag
38. function win.On.Win.KeyRelease(ev)
39.     if ev.Key == 0x1000020 then
40.         shiftdown = false
41.         itm.Button.Text = "Button"
42.     end
43. end
44.  
45. -- Now we can use our flag to differentiate button presses
46. function win.On.Button.Clicked(ev)
47.     if shiftdown then
48.         print("Shift+Button")
49.     else
50.         print("Button")
51.     end
52. end
53.  
54. win:Show()
55. disp:RunLoop()
56. win:Hide()

[AndrewHazelden]

Looks like keypress events don't work with borderless windows...

That's unfortunate. The keypress works AFAIK when the window has the foreground input focus. So likely a floating view is persistently on top of things but not considered "in focus"?

I'm just brainstorming here, but potentially you might try using a hybrid approach?

A .fu hotkey entry could be used to switch (toggle) your Toolbar into a "move" window state that would modify the WindowFlags = {SplashScreen = true, NoDropShadowWindowHint = true, WindowStaysOnTopHint = show_on_top}, settings to add the "stock" window titlebar back temporarily.

Tapping the same hotkey button a 2nd time would then toggle the window back into your borderless mode.

---

In the longer term, I'm starting to think that it would be cool if you dug through the Fusion native window layout information and worked out the position of the Fusion views in screen pixel coordinates for placement. Then you could have the Toolbar stay locked to the relative position of a specific view.

Thinking out loud, you could possibly use the ui:Timer() function set to refresh at a certain rate. Or an "Action Listener v2" like approach could be triggered whenever the artist does something in the visual Fusion session. That could help trigger an update in your toolbar script so it can roughly track your Fusion layout window positioning information so the toolbar refreshes itself and stays locked in place over time as the user resizes and adjusts their Fusion workspace and the window dividers.

---

Here is an example of the type of screen space (_sxpos, _sypos) and window space (_wypos, _wxpos) coordinate data you can get back from a lot of actions that can be listened to in Fusion:

Code: [Select all] [Expand/Collapse] [Download] (WindowPositionLuaTable.lua)

1.     Args =
2.     _sxpos = 569
3.     index = 1
4.     __flags = 1048832
5.     _wypos = 665
6.     _wxpos = 569
7.     _sypos = 737

---

And at the same time, when a lot of actions trigger you also get some bonus "modifier" keypress information from the Rets variable too:

Code: [Select all] [Expand/Collapse] [Download] (KeyModifiersLuaTable.lua)

1. Rets =
2.  
3.     modifiers =
4.     MetaModifier = false
5.     ControlModifier = false
6.     ShiftModifier = false
7.     GroupSwitchModifier = false
8.     KeypadModifier = false
9.     AltModifier = false

---

Also, you could look at the old 2017-08-14 era UI Manager thread "Editing the FuBox Radial Menu UI Settings" experiment on how the mouse position can be passed from a .fu execute section into the running .lua script:

Code: [Select all] [Expand/Collapse] [Download] (FU_RunScript_With_Mouse_Pos.lua)

1. Execute = [[target:RunScript("$CFG/FuBoxUI.lua", { mousex = args._sxpos, mousey = args._sypos})]],

---

For a .fu file there are several extra things you can define for a hotkeys entry keypress code like adding _RELEASED, or _REPEAT, or _DBLCLICK to the end of the key name.

You have the following "modifiers" you can add to a keypress code if you are running out of unmapped single key combination hotkeys that are available on your keyboard:

• SHIFT_
• CONTROL_
• ALT_
• META_
• KEYPAD_
• MOUSEMOVE
• MOUSE1_
• MOUSE2_
• MOUSE3_
• MOUSE4_
• MOUSE5_
• MOUSE6_
• MOUSE7_
• MOUSE8_

From looking at some random notes on my hard disk from back in 2017 I saw a tip I got from a little birdie about the possibility of using a mouse-only "hotkey" for things like a smooth view zooming:

Code: [Select all] [Expand/Collapse] [Download] (Fu_Action_Entry.lua)

1.     Action
2.     {
3.         ID = "View_Zoom_Mode",
4.         Modal = true,
5.  
6.         Args =
7.         {
8.         },
9.  
10.         Targets =
11.         {
12.             PlayerView =
13.             {
14.                 Start = [[ ]],
15.                 Enter =
16.                 [[
17.                     mode:Set("StartZoom", target.Zoom)
18.                     mode:Set("OrigX", target.OriginX)
19.                     mode:Set("OrigY", target.OriginY)
20.                 ]],
21.                 Execute =
22.                 [[
23.                     local dx = args._wxpos - mode.EnterPosX
24.                     local zoom = (2 ^ (dx * 0.005))
25.  
26.                     local cx = mode.EnterPosX - target.ViewWidth/2
27.                     local cy = mode.EnterPosY - target.ViewHeight/2
28.  
29.                     target.Zoom = mode:Get("StartZoom") * zoom
30.                     target.OriginX = cx + (mode:Get("OrigX") - cx) * zoom
31.                     target.OriginY = cy + (mode:Get("OrigY") - cy) * zoom
32.                 ]],
33.                 Exit  = [[ ]],
34.                 End = [[ ]],
35.             },
36.         },
37.     },

And then you could use a pair of mouse button interaction based event/modifier based hotkeys entries like this:

Code: [Select all] [Expand/Collapse] [Download] (Fu_Hotkeys1.lua)

1. -- Mouse button 1 & 3
2. MOUSE3_MOUSE1_RELEASED = "View_Zoom_Relative{ scale = 1.414, mouse = true }",
3. -- Mouse Button 2 & 3
4. MOUSE3_MOUSE2_RELEASED = "View_Zoom_Relative{ scale = 0.707, mouse = true }",

or even this is a possbible hotkeys entry kind of option:

Code: [Select all] [Expand/Collapse] [Download] (Fu_Hotkeys1.lua)

1. MOUSE1_MOUSE3_MOUSEMOVE = "View_Zoom_Mode",

I haven't tested the above code in like 2 years so my memory is hazy with any issues that might come up from that approach.

[Movalex]

it would be cool if you dug through the Fusion native window layout information and worked out the position of the Fusion views in screen pixel coordinates for placement

This is aldeady done with my latest update. I'm quite happy with this solution, but I did not push it to reactor though.
I wanted the UI to be launched under Left viewer in a center of Fusion frame, with a small offset. But gotdamit Resolve does not "resolve" ==app:GetPrefs("Global.Main.Window") correctly:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.lua)

1. table: 0x028b7f277d48
2.     Left = -1
3.     Width = -1
4.     Top = -1
5.     UseWindowsDefaults = true
6.     Mode = 3
7.     Height = -1

Toolbar16.lua

EDIT: jeez, I started answering while your reply eventually increased to a whole new level to me! I need some time to become a bit comfortable with this new knowledge.

[AndrewHazelden]

I love that you are pushing your Fusion16 toolbar effort further each week. It's great.

jeez, I started answering while your reply eventually increased to a whole new level to me! I need some time to become a bit comfortable with this new knowledge.

Yeah. My first post this morning was a bit short on insight. I thought you might like some more information so I dug around for all the tips I had that might apply and appended them to the post. There's some fun stuff you can do with those kinds of approaches. I'm excited to see what you make of it all!

---

The main window data usually is empty like that IIRC until the Fusion-based artist manually goes to the Fusion Preferences window > Global and Default Settings > Layout preference page and manually saves their active window layout.

If you look at the UI Manager Lua example file "Window Snap.lua" you will see the issues I had with empty window values and all that jazz.

Edit: Here is the code I used to check for an empty main window preference:

Code: [Select all] [Expand/Collapse] [Download] (Get_Fusion_Main_Window_Prefs.lua)

1. ------------------------------------------------------------------------
2. -- Set up the initial window size
3.  
4. -- Read the previously saved window position + size from the Fusion user prefs "Profiles:/Default/Fusion.prefs" file.
5. mainWindow = fusion:GetPrefs("Global.Main.Window")
6. if not mainWindow or mainWindow.Width == -1 or mainWindow.Height == -1 then
7.     print("[Error] The Window preference is undefined. Please save a initial window position in the Layout Preference section.")
8.     app:ShowPrefs("PrefsLayout")