Photoshop toolbar

[Steve B]

Wanted to drop a line about my finding on the right-click-pan, having tested it while drawing today. I've only worked on the #5 code, but I did hit upon a very regular and repeatable way to make the "Right-click to Pan" code malfunction.

Press right click and hover, and you’ll see the cursor trying to decide between the tool and the hand—it changes depending on the proximity to the screen. If I keep right-click pressed but hover pretty close to the screen—within about 1/2” and wait just a second or less (just hesitating a bit while I decide where to go can cause it, but you can test it by deliberately waiting a little longer), and then press the cursor to the screen, the pen will draw instead of pan. However, if instead I press and hold the right-click and then rather abruptly press the pen to the screen, then it’s more likely to engage the Pan function. It seems to have something to do with a timing and proximity, more than anything else. It's the momentary hesitation that gets it to malfunction for me.

I thought that might be of some use to you, and is easily repeatable for me.

Also, as per the last post-- if I had to give up the few right-click functions we have in the toolbar to get right-click to work right for Pan, I'd take Pan over secondary toolbar functions any day.

Besides, we've been sort of accidentally weeding right-click functions out of the toolbar anyways-- there's no longer currently a Rotation button that needs a reset, there's no Focus button to right-click, and we're no longer doing the right-clicks on the Tool buttons either. If we could get the clock/battery thing to work differently (such as having it somehow automatically show the info at the top of the pull-down menu, for example, which takes only a single click), there'd be almost no right-click functions at all, which could free things up. ??

Not that I'm gunning to remove the right-click on toolbar functionaltity-- there still may be good use for it, but I'm open to it if you think it's the only way to get it work right for Pan. Who knows? I'll test out the code #2 tomorrow and let you know my results on that.

[Steve B]

Just FYI- I began testing code #2, and it is remarkably more consistent than #5 in terms of functionally panning. If I tried I could sometimes make it fail, by hovering briefly and making quick strokes, reclicking and trying one after another, but in general it works great. If you right-click and hover you can see the cursor blinking and re-assigning the Hand priority, so its clearly not perfect, nor totally consistent. I think this has to do timing again and whether you hit the pen to screen at the wrong time to get Pan to fail. Still, it is much much better.

[lblb]

Thanks for the detailed feedback, that's very helpful. Hopefully #2 will be more robust. From what I've tried, it seems the main issue is that sometimes (but not very often) the right-click pan doesn't "bite". As you mention, it seems to only happen if I am "lazy" on the right-click and hover a bit before hitting the screen: when I do a quick and clean right-click, it seems to bite all the time. Fortunately, at least in my limited testing, it seems that now the function doesn't get stuck and is released correctly when you stop panning.

I think what you mention may ultimately turn out to be the best solution: in order to have an efficient pan mode in Sai, we may have to sacrifice the right-clicks on the AHK toolbar. Importantly, that would only apply to the Sai toolbar (as the right-click pan thing can easily be set to be in effect only when Sai is the active program). Fortunately, because Sai has these four very useful windows that can now be called up at will, the number of right-click functions that we have set for the Sai toolbar is already very small so we wouldn't be losing much.

The main difference between #2 and #5 is the following:
- AutoHotkey is truly great at sending different commands when the identity of the active program changes. So #2 is just set to something like "if the active window is Sai, make the right-click a panning function". And by default, if the other windows are not Sai, it just does normal right-click.
- Unfortunately for our purpose we are setting up the AHK toolbar so that is never becomes the active window. This means that when the pen is over the AHK toolbar, it still sees Sai as the active program. To circumvent that, we can do as in #5 and include a function where the script looks at the identity of the window under the pen (not necessarily the active window) and changes the command according to that. However, you can't just have a simple "when X is under the pen, do this". Instead, you need to have something like: "if X is under the pen, do this; but if Y is under the pen, then do this; but if Z is under the pen, do this". And it seems that it's when the code has to cycle through these different options that it can get messed up if the identity of the window under the pen changes too quickly.

Also: I've tried all kinds of things to address the blinking cursor when hovering but I'm not sure there will be a way around it. There seems to be two reasons for the blinking:
1) The code includes a timer that is constantly monitoring the state of the button to make sure the pan function is released when the button is released.
2) But importantly, this also happens even when there is no timer in the code. This is because the way that the Wacom right-click on the pen seems to work is just that it constantly sends multiple right-clicks very very fast when you hold the button down.

My (perhaps incorrect) guess is that trying to limit it to one click would not be viable as it wouldn't be interpreted as a click-and-hold (i.e. the click-and-hold doesn't exist, it needs to be simulated by fast repeat of single clicks). Again, I may be wrong and maybe we'll find that it's completely possible to do it. (Also, from what I have read in the AHK forum, it seems like the repetition of right-clicks when you hold the button down would be way too fast for AutoHotkey to cleanly stop it after one).

Another way to maybe alter this would be to change the pen settings (but that may not be somewhere we want to go). I don't have my tablet right now, but I seem to remember that there is a place in the Wacom pen settings where you can modify the hover/click behavior and the distance at which the pen is detected.

[Steve B]

I just had the strangest experience. I was using Sai and AHK, and I completely shut down AHK. However, with AHK still shut off I started using Sai and found I could pan with right-click now, blinking Hand cursor and all, just as I the script were still running. I shut down Sai and tried it again. Still worked. AHK still closed.

Is script #2 changing something with the setup outside of Sai? Can you replicate this? Kinda trippy and unexpected.

[lblb]

Interesting! Actually, it's a bug but it's easily explained: the pan function is now in a script separate from the toolbar and when you close the toolbar, it is programmed to send a command to close the pan script. Apparently that part is not working perfectly! (By the way, this also means that you can just launch the file for the pan function without starting the toolbar).

The last line of the code for the pan function is:
^!+w::ExitApp

Which means that the hotkey to close that pan script is Ctrl+Alt_Shift+w and that's what the toolbar sends when it is closed. Apparently it doesn't do it correctly every time. I can't post a corrected toolbar script right now, but you can just use the keyboard to send that hotkey to close the pan script. Will correct this soon!

Edit:
I can only imagine how surprising that was!!!

[Steve B]

Haha! That's good to know. I didn't understand I was running two scripts at once. Makes more sense now.

Btw, I've been thinking of a kind of user interface improvement for the AHK Panels in general. Do you think some sort of scroll over- drop down version of the palettes is possible? I was thinking, for instance, that it would be very cool to have the Color Palette open all the time in a more centralized location, but shrunk to something very small- the Color Taskbar or a small icon that shows the current active color, for instance. Then, when your cursor scrolls over the icon, down pops the Color Palette. As long as you hover over it and pick colors it stays open, but when you move the cursor away, the Palette shrinks back down automatically to the smaller icon. Sort of like a combination between a Photoshop add-on called Magic Picker and the way the Artrage Color Panel opens. I was just trying to think of a way to have things like the color and layer palettes more regularly available, without having to have them take a bunch of space, nor requiring extra button pushes on buttons on the side of the screen. Just an idea.

I know, I know... You basically nail down one thing and I propose another.

[lblb]

What a great idea! I have no clue how I could do this, but this gets my brain going... actually... maybe I have the beginning of a clue... we'll see!

When you say "the cursor SCROLLS over", do you have in mind to actually scroll or to just position the cursor on the "mini icon"?
Would you see this as a mini-icon that the palette shrinks to at the location where the palette is on the screen, or more like a button on the toolbar that spits out the palette when the cursor is over it?

[Steve B]

Well, in my mind the idea would probably be that you'd still need the Palette Subpanel buttons to launch those panels or icons you want to set up. Then you'd position the icons/palettes where you'd want on the screen. You'd then have a very small icon-- a square with the active color in it, or perhaps a version of the header for that palette somewhere, say, in the upper middle area of the screen (or wherever I wanted it to go), where I could just pass my hovering cursor above it and down/out would drop the full palette. Do my work there, choose my new color, etc. then just move the pen cursor away and the palette would shrink back down to the mini-icon automatically.

Essentially, there'd be a tiny bit of setup required at the beginning, but you'd then never have to press a button to open or close a regularly used palette again for that drawing session. AHK would see the palette as always open once you actually did open it with the already existing Palette Subpanel. There'd just be this interface shrinking the palette to a smaller visual icon until it was scrolled over/the pen hovered over it.

In my mind you'd even be able to close the Palette Subpanel after your opened the palettes you wanted to set up in this way, just like you can right now. So those functions would be separated. You wouldn't even need to be able to move the major AHK panels around with the pin/unpin method, because it'd actually be the existing Sai palettes that you'd be moving around, shrinking, etc. you would still need to be able to truly close the panels though if you wanted though, so the "x" buttons would still need to work smoothly. Particularly if you needed to open up that special Sai Palette that you wouldnt normally be using much, and so would want to immediately close (as you do now).

That's the idea anyways. Most of it rests on the new idea of being able to "minimize" the palette to some user positionable icon onscreen, that would then expand only when the cursor hovered over it. That, and the idea of some simple icon to go on the Color Palette header that could read and display what the current selected color was, regardless of whether or not the full Color Palette was open. That'd be nice. Right now, you can get that info in the Tool Palette, but that's actually not very useful when picking colors with the other palette.

[Steve B]

I did this this soft watercolor landscape painting this weekend in Paint Tool Sai, using your toolbar. "Autumn Fog." The toolbar is pretty remarkably stable right now, or so it seems to me. Yes, I'm still having the "flashing" that occurs for the top two rows of buttons, as described before, and I'm also having a "flash" occur when I open the Palettes still. I'm also still requiring double clicks sometimes to open the Palettes, although no longer to close them. Still, that's all pretty minor stuff.

The Pan functionality works very well with code #2-- good enough that I don't worry right now about making marks by accident, although it does happen a very few times over each session. I spent about 2 hours building up the painting, and it might have happened a few times, if at all. I don't really remember it either way, which is probably the surest measure of whether a function is working properly or not. In general, usage of the program is exceptionally functional.

I'm still having an issue though with the fact that my upper pen button is engaging Pan, as before. You can actually see it do it when you try it. I'd like it to get recognized as other key inputs, so that I can get Stroke It to work simultaneously with the AHK setup. That would be very nice, so I can do things like open new Layers very quickly, clip them , lock opacity, etc. whatever, with a quick movement of the pen. I'm not sure how feasible this is to you.

The alternative response to the issue, or something that would work in tandem is this concept of the "hover-expand-and-drop-down" function for Palettes. This would go a long way towards replicating some of the super quick functionality I get with Stroke It. I like Stroke it, and would like to use it with AHK, but if i can't get both, it'd be nice if one of them did some more heavy lifting to make up for the absence of the other. Just some thoughts.

[lblb]

Very nice! Autumn fog... Sounds like the title of a Rimbaud poem...

I'm glad the toolbar is useful and somewhat stable right now. And it's also cool that the right-click pan is more reliable. That's a tough one! Also, have you had a chance to use the 123 buttons a bit? Do they behave correctly?

I didn't have time to work on this much because of exams (and it's again exam week for my other students in a few days...) but I couldn't resist and started looking at the hover hide/show thing. There is still a lot of work to do but it seems like it may eventually work (at least the hover-and-show process, haven't looked at all at showing the active color). I've been able to do it in a simple fashion (not yet completely reliable) with the Color window in Sai. For now, I have a small icon (can be any bmp image, and set to any size) that is shown on the screen: when the pen hovers over it, it disappears and the Color window appears. If the pen goes away from the Color window, the window disappears and the icon reappears where the Color window was. Still need to work quite a bit on it (and can't promise anything) but the basic idea definitely works. Now let's see if it can be made reliable!

For the pen buttons:
My pen is behaving badly these days so I can't try all I want... I have had problems for a while with my second side button so I can't test for the moment. From what I remember from trying stuff out a while ago, I had set the first side button to right-click and the second side button to middle-click. And then when I set StrokeIt to be activated with middle-click, it really didn't register anything in Sai.
Is that the pen button setup that you have? And you're seeing the pan function "bleed into" the middle-click second button functions? When the ahk toolbar isn't on (and when the file for the pan function hasn't been launched), are you able to use the second button middle-click in Sai to launch StrokeIt commands?
Also, for now, I haven't been able at all to detect something (anything would be helpful!) when the eraser is used. With the various tools that I have used so far, I just can't detect the eraser (so remapping it is not possible for now). But I'll keep on trying (the AHK forum is fabulously filled with all kinds of obscure and useful tools...)