Photoshop toolbar

[lblb]

Ah the joy of computers!
We can change the default options for the hover icons pretty easily. I'll try to think of ways to make it better. In the meantime, since you seem to be using ArtRage quite a bit, you may want to not have the hover icons start with the toolbar. To do that, just deleted lines 512-515 in the Toolbar_Subroutines file. Then if you need the icons in Sai, just launch them from the Options window. (I never had that cpu usage problem before (I guess I never had ArtRage opened without Sai) but it's good to know that it does that!)

When you have your pen issues figured out (hopefully it will be straightforward!), tell me if you get the eraser to interfere with the top side button. If you don't get that nasty interference, then I should be able to modify the script that I included to make it easier to use (i.e. no awkward switching between the top and bottom pen buttons for zooming).
Hopefully your pen issues can be fixed easily. From what you say, it doesn't seem like its AHK-related (but I may be wrong). But to make sure, you should maybe open the Task Manager and close any residual AHK script that may accidentally be running in the background (they're usually hanging around 4000-6000 k in Task Manager).

[Steve B]

OK, so far a lot of this is really really good. No finicky bugs yet, outside of the more major Pan issue in Sai.

Artrage-
-Upper Button-
no issues with the upper button making the eraser appear. It's been smooth sailing for me, and is a clear improvement to work flow to have zoom and resize as a pen-based action. So if you can get it to work without switching buttons, well, that's seems veeeeeery cool.

Sai-
-Pan-
I rebooted, and that helped some with the right-click to Pan, but its not as regular as it was a few weeks ago, before we introduced the Hover Icons. I just don't understand why..... I really felt like we had this in the bag back at that iteration-- when we had option #5 and #2, and I think we went with the #2 alternative, which worked very well. Now, it engages sometimes, but not regularly-- I'm often seeing the hand icon, but only briefly. It's like I don't have enough time to get to the screen before it disengages. It reminds me very much of the experience in #5. I'm making lots of stray marks and then undoing. As it is, its not been regular enough to use yet.

-Transform is a PITA-
As mentioned before, this is the one major issue I've got with the current redesign in Sai. It's clearly not as smooth as it used to be. However, I was having issues with the older version as well (before we did this setup), because I've been wanting to use more of the Transform functions more fluidly. Sai has some great Transform stuff that works really fast- Free Deform, and Perspective come to mind quickest, that I've wanted to use more regularly. I actually thought of some sort of mini-panel or just a set of 4 buttons to add as a group to the main AHK bar. Will ponder more, and try and figure that out.


General Note-
It'd be nice if there were the option to switch between a 24 hour clock versus the 12 hour version in the Setup Window. I'm definitely having to do math to figure out what time it is in the afternoon if I use the current setup. ;P

[lblb]

Ah Americans and the 12-hour system! Should have thought of that! Actually, I thought that the command I used would use whatever hour-system the user set for his computer, but I misread as it clearly states it will use the 24-hour system. I'll see what I can do... While we're on the matter of the clock: is it good as a right-click? Would it be better if it were permanent?

It's good to know that it's not too buggy! For the Transform button: Maybe we could just add the "old" transform three-step button next to the transparency button. And also have the other "transform mini-panel" for more intense/complex stuff?

I still don't understand your right-click pan issues... especially since they started not when we introduced something new but apparently for no real reason... The toolbar is still using the same Right_Click_2 file (I verified and the code hasn't changed). I know you've tried it before but let's see again: in the latest toolbar folder, that file is in the png\options folder. If you launch this file with no other AHK script going (and maybe only Sai running), does it work? Is it more or less reliable if ArtRage is also running? One thought could be that maybe the "Tip feel" in the ISD changed??? (Really just brainstorming out of nowhere here as you are way more knowledgeable about these things...)

While I'm getting that weird behavior with the top side button (now tested with my two Axiotron pens), it's good to know that it's working well for you. Because of that problem, it's difficult for me to try to optimize this particular function. But here is attempt number two (let's call it ArtRage_Top_Side_Button_2.ahk). Open the first file, delete all the text and replace it with the text below. Save the file as ArtRage_Top_Side_Button_2.ahk, then double-click on it. What this should hopefully do:
If you go for a middle-click with the top button (and by that, I mean you are drawing normally, you lift the pen a bit, press the top side button, and put the pen back on the canvas and keep holding down the side button (so you need a "physical" middle click), it should be the tool resize. As we are testing, with this function I added a "Tool size" tooltip for now. If however you press and hold the side button while hovering and don't put the pen on the canvas, it should be zooming. For this, the tooltip should say "Zooming". Does it work?

Here is the text for ArtRage_Top_Side_Button_2.ahk:

#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
#SingleInstance, force
SetBatchLines -1
SendMode Input
SetControlDelay, 0
SetWinDelay, 0
SetMouseDelay,0

#IfWinActive, ahk_class ArtRage 3
mbutton::
Send {shift down}
sleep 200
getKeyState, State, LButton
if State = D
{
tooltip, Tool size
Sleep 1000
tooltip
}
if State = U
{
tooltip, Zooming
Send {shift down}
send {rbutton down}
Sleep 1000
tooltip
}
KeyWait, mbutton, U
Send {shift up}{rbutton up}
return

#IfWinActive

[Steve B]

Hey, I'll try that one out in Artrage. Looks cool! I hope it works.

edit- tried the new stuff in Artrage, and the upper button works fantastically. I'm very excited to try this out in Artrage for a whole painting session!! This setup is going to be so cool to share with the forum there. BTW, is there a way I can just get rid of the contextual labels? I like the idea of them a lot, and could see there use in a couple of other applications of the AHK toolbar, but here I'd just as well have this function be seemless).
end edit

BTW, I did a little "programming" (HAHA! Overstatement of the year....) in AHK today, and I improved the performance of the Right-click to Pan function. I went into the script and changed line 12 from "sleep 100" to "sleep 500". This is providing me a much longer time to tap the pen to the screen before the Hand went away and is stopping a lot of the errant marks I was getting when I was putting the pen tip to the screen too slowly after pressing right-click. Yay!

One thing that I noticed though is that if I press right-click, move stuff around, and then lift my pen while still holding right click that if I put the pen back on the screen I make a mark instead of Panning. I thought that would work differently. The truth is that the way AHK works currently is that I press the right-click, it starts the Pan operation for the 500 ms, and then if I press the pen tip to the screen Pan is held as active regardless of whether or not I hold down the right-click button while panning. If possible, it would be nice to, say, hold right-click, activate pan, do panning with right-click held in place, and then be able to lift the pen while still holding the right-click and immediately pan again without having to re-press right click. I'm beginning to think that's just not the way AHK works, but I thought I'd ask. I'm cool re-pressing to start panning a second time, but I thought I'd check.

One last thing that would be nice (again, I don't know if it can be done in some way) is that I can sometimes (rarely) get an errant mark if I put the pen tip down too quickly when pressing the right-click to Pan. This is clearly because the AHK command just hasn't been engaged yet. Is there a way to make it engage faster? If not, no bigee, as I can just get used to very momentarily pausing before doing so, but I thought I'd check.

BTW, I also did the change you suggested for the Toolbar Subroutines and deleted the few lines you recommended. That worked and has made sure that the Hover Icons only open up for now when I go into Sai and change it over to them.

[lblb]

Did we just witness the birth of a new AHK wizard?

The change you made is good! But that means that it can take up to 500 ms for the pan function to kick off once you take the pen off the screen. Maybe try getting the value as low as you can. I would just start at 100 ms and gradually increase by 50 ms increments.

I'll see what I can do for the rest for pan but I think it's unlikely that you can just hold the right button down and continue panning if you take the pen on and off the canvas. The difficulty is the following: if you look at the code, the line that says "Keywait, lbutton, u" means that it's actually waiting for the LEFT mouse button to be up before releasing the pan function. Why?
First: Even though you are using the right button to pan, as I mentioned earlier the way the right button seems to work with Wacom (and you saw it when sometimes right-clicking on the AHK toolbar repeats the command many times) is not that it holds down the right button, but that it repeatedly sends right-clicks really really fast. But that means that for the pan function you can't ask it to do something like "release the pan function when I release the right button" because the right button is actually being released very very rapidly as soon as you press it.
Second: Earlier I said that part of this code doesn't make sense. Well that's the part! Apparently, when you right-click and hold, it is still detecting the left button as being held down. The only reason we know that is because the line "Keywait, lbutton, u" actually works!

If you want to test if it's possible on your system to have pan on as long as the right-click button is pressed: on that line, change "lbutton" to "rbutton". This means that the code will wait for the right button to be released before terminating the pan function. On my system, this is instantaneous (as the right-click is "instantly" released as soon as you hold down the right button.) Does that make any sense? Does it work for you with rbutton in the code (would be great!)?

For the ArtRage function: I'm glad it works! To get rid of the tooltips, delete the four lines in the code above that start with "tooltip". The code works this way:
- As soon as you press the top button, the code presses down Shift.
- Then you have 200 ms to put the pen on the canvas
- Then Shift is released after 1000 ms, but as long as you keep the pen on canvas you can resize the tools.

Why the 200 ms? Since I can only get the zooming function to work when the RIGHT button is held down, if you didn't put the pen on the canvas before 200ms the code presses down the RIGHT BUTTON and now you can zoom. This means that if you are zooming and you press the pen on canvas without releasing the middle top button, you may be able to resize the tools but you may also have a regular right-click/fullscreen that is also sent (which is annoying).
To optimize it for your use, you may want to change the 200ms and the two 1000ms delays and see what works best for you. I think you could certainly shorten the 1000 ms delays to much lower values (and then it won't "hang" when you release the button).

[Steve B]

Sweetness! Took a few trys but I got the tooltips to go away and still have functionality. I tried out the lbutton vs. rbutton thing in Sai, and its a no go for me in Sai as well, so back to the way it already was on that.

BTW, re: tooltips in Artrage-- I was wondering if we could do something like have a toolitp that instead told us the real-time brush size as we resized? That would actually be very helpful, as it sometimes unclear when working in clear screen mode. By the same token, it would be helpful to know what scale I was resizing to to in Artrage when using the pen button-- this comes into play when I have things set up at a certain zoom level on a secondary monitor, to simulate printing scale, and then want to match that scale on my laptop. During that time, it would be helpful to have a live, real-time scale % show as a tooltip. I don't even know if this sort of thing is possible, but I thought I'd bring it up. Who knows?

I have to say, now that the Hover Icons and Right-click to Pan are full functioning in Sai, and the Middle-click to zoom and resize are working in Artrage.... well, damn, I gotta say that I'm very satisfied with the time we've spent on this. These are the sorts of "pie in the sky" concepts that I never expected we would be able to do, and yet are giving (in my mind) some really critical and impressive work flow improvements. It's awesome, and I can't really imagine going back to the way things were.

I've got the mockup to finish for Artrage, and there are a few minor wrinkles to iron out of Sai's setup, but after that... well, I'd say we're on to user setup mode, but I've got a few things up my sleeve that I'd still like to explore. More Hover Windows for AHK panels, and maybe some sort of CMYK Color panel or some such thing? I've found some great jpeg images for CMYK Color Panels, but the issue is that they're not the value/shade/chroma combination that you get in programs like Artrage or Sai or PS. They're just one of those sets. I want something that does CMYK values, that have grey scale, and have value as well. Like what Artrage already has on its popup, but with just CMYK colors in there instead of what they've got.

Thoughts?

Anyways, I'm just super excited by these developments. It feels like every week something new and unexpected comes into fruition.

[lblb]

Yeah, when starting this thread I didn't imagine that we would get into this kind of stuff and it's a lot of fun! Admittedly, the coolest stuff so far doesn't have much to do with the toolbar itself! Although I actually catch myself taking the toolbar for granted when testing stuff out... by that I mean that there is some stuff that I wouldn't really know how to do without the toolbar!

For right-click pan: It's really cool that you found how to make it work again! You may want to try to optimize it as I mentioned in the previous post (and then tell me whatever delay works best for you and I'll include as the default value). Also, there are a few commands that can be added at the top of the code to try to make it engage faster. These were actually an inexplicable omission from my part! While they probably can't be bad and maybe they won't have a positive effect, I think they could (in fact, it's probably "should") make it engage a little faster. If these don't work, I don't know of other ways to speed it up. So in Right_Click_2 just add the following lines below the line "#MaxThreadsPerHotkey 1" (it can't hurt, I think!):

SetBatchLines -1
SendMode Input
SetControlDelay, 0
SetWinDelay, 0
SetMouseDelay,0

For the new middle-click stuff: now that it works, and now that we don't need the tooltips to show that it does, we can change the code and delete the two 1000 ms delays (which means it won't hang if you use the resize or zoom functions very briefly). While this may be a case of "if it ain't broke, don't fix it" I think a shorter code will ultimately be more reliable. Below is the code for ArtRage_Top_Side_Button_3.ahk. In my limited tests (goddamn pen button problems!), it seemed to behave just as well. Does it also work as well for you? If not, I think it's just a matter of modifying it a bit (or even modifying the previous one to remove the two 1000 ms delays, or even just keeping it the way it is right now).

For the tooltips: For now, my AHK knowledge allows me to send commands to programs, but it's still very limited on how we can get AHK to listen to a program. An example of the latter would be having a tooltip that shows the zoom changing in real time. So for now, this seems like it's a little (read: completely) out of my league (and unfortunately, unlike most other programs, ArtRage just doesn't give out any info easily to AHK or any program of that type). I'll ponder this, but for now it doesn't seem like it will be possible any time soon.

For the CMYK color panel: How would you see that working? Would it be like a replacement for the Sai/ArtRage color wheels? as a separate program that just gives/detects color codes, that you then input in the art program? as something like a layer (in a ArtRage script?) from which to pick the colors? As something to pick colors in any window?

By the way, you've mentioned it before and I'm absolutely not against fragmenting the toolbar into individual scripts if you feel it would be better. Maybe when we are more at something like a definitive stage with the ArtRage toolbar? As I'm not really going to use the toolbar (after all that work!), it really comes down to whatever is more practical for you to use. And I also think that once we've taken care of the ArtRage setup, and solved the countless bugs, a next logical step might be to go for user customization/friendliness. Or maybe after SBP? And indeed going for drawings tools may be fun! Or maybe try to go for cool ArtRage scripts?

As a side note: You've most probably discussed this an infinite number of times in this forum, but do you know of a stylus with two side buttons that could be good for non-artists? Or can you just direct me to one of the good threads on this (there are so many of them, and so little time for me to browse around!). I'm starting to like the extra functionality of using the full potential of the two side buttons (and I also suspect that my problems may be related to my cheap (yet very useful!) Axiotron pens.)

Here is the code for ArtRage_Top_Side_Button_3.ahk:

#NoEnv
SendMode Input
#SingleInstance, force
SetBatchLines -1
SetControlDelay, 0
SetWinDelay, 0
SetMouseDelay,0

#IfWinActive, ahk_class ArtRage 3
mbutton::
Send {shift down}
sleep 200
getKeyState, State, LButton
if State = U
{
Send {shift down}{rbutton down}
KeyWait, mbutton, U
}
Else
KeyWait, mbutton, U
Send {shift up}{rbutton up}
return

#IfWinActive

[Steve B]

Ok. Put the two alterations in-- one for the right-click to Pan and one in the top-side-button for Artrage-- and all seems fine. No big deal yet. I'll try them more later though and see what they do. I'll explore the timing optimization in Sai later on, when I get the chance. For now, 500 seems fine enough that I'm not experiencing any hiccups, but I'll see. Perhaps this weekend. The next few days are going to be busy.

Re: the CMYK Color Wheel idea I had. The idea was sparked by the Magic Picker addon to PS that I found. The issue is that neither Sai nor Artrage support working only in the CMYK color space, so there's no real option to "switch" to it in either program. As such, it'd more about just having an appropriate color picker to start the process off with. In Sai atleast you have the option of the swatches, which piggy tails on the the Color Wheel. In Artage, you have to use the Color Samples option, which is clumsier and bulkier. Though we have it set up in the AHK toolbar to be used, I've just never really set it up to be of real use to me-- it requires a lot of initial leg work, and even then I'm not sure it'd give me what I really want-- the strip is too narrow, the samples larger and larger spaced then they need to be, and again, you can get shifts in color, but not in value.

So, in my mind, the ideal version would be something that didn't work through Artrage. I just don't think we could get Artrage to do something in a window that would be useful. In my mind, the Color Wheel would be somehow engaged and run by AHK, but the color values would be read by Artrage. I suppose there are two versions--

1) One version (the simpler one) is that AHK would pull up a custom color picker image, from which I would somehow be able to pick a color that would then be read by Artrage-- it would need to be a CMYK image, that shifted in value and had some grey tones (essentially a sort of jpeg of a PS swatches setup, with some variety in terms of greys and values). I have some of these images, as I did some leg work to try and build something useful in Sai. In my mind, I guess I presumed it would work like the Hover Icons in Sai. This version has some interest to me, though I'm not sure how useful it really would be if I couldn't the real sort of variance you get from the current color picker. ?? I think I'd need to test it out to see. I've attached a "Tint" jpeg, to give you some sense of what I'm looking for-- though none of these are perfect, as they don't have grey values as options for the colors.

2) Somehow AHK would engage a sort of alternate program or CMYK color picker UI (although I have no program to use, as I don't think Magic Picker works in anything but PS) that would appear above Artrage. It would work much like the current Artrage color picker setup, in that it would have a space to pick the hue (in Artrage this happens to be in the circle around the exterior), and yet an alternate space (in Artrage this is the inner square) to pick the value (black versus white of the color), as well as chroma (pure color versus quantity of grey in the color). This chosen color would then would be used by Artrage. Of course, the thing in this setup is that the opened Color Wheel is "active" in that it's not just a jpeg, but actually has "moveable" parts. I know, it sounds impossible to me too, but that's the dream.

3) An alternate version that just occurred to me while looking over the jpegs is one where AHK pulls up a static image that has all the hues and tints we want in one section, and the shades (grey tones) separated in another space. AHK would sort of see them as two separate images. I could then pick the color I wanted as one small step, and then pick the grey-scale I wanted as the second step. AHK could somehow highlight the two selections, combine them, and show me a version of the combined color in a square up top. It would then transfer it to Artrage, and I would paint with it. The second one attachment (Real Color Wheel Print Palette) is what prompted idea #3, as you can see it has all the hues and tints up above, with the black and white values down below.

I dunno..... LOL. All of these sound insanely difficult, and way outside the scale of what we've been doing. I thought I'd bring it up though. Who knows? I've thought of just buying the Magic Picker thing for 15$ just so we could see if AHK could just run it independently from Artrage and somehow port the selected color between the two programs. ?? That's an idea as well.....

Anyways, the current Color Wheel-AHK setups in Artrage and Sai work very well, so I'm not against using them as is, but this is probably the last major "What the heck, I'm curious so I'll ask if this is even possible" kind of idea that I've had. Everything else in Artrage that's an as-yet-to-be-done improvement I think we can do, as they're all about using Hover Icons on AHK subpanels (a Stencils subpanel, perhaps, as well as a Layers subpanel, etc, each with a more sophisticated setup, using scripts and whatnot perhaps).

Thoughts?

edit-
I'm most interested in splitting the toolbar up because I think its the most digestable way to offer it to different communities. If it can be divided easily (and I think that's a big part of what 2.0 made an option-- making it into separate toolbars that are linked by a single UI, rather than one big toolbar), then I think there's real benefit in doing so. I'm very excited about sharing this, and am really chomping at the bit to put it out there and see if we get some additional feedback on what could be done to improve it/ streamline it, etc. However, I don't think it needs to be done immediately, nor even as the final way of doing things. It'd be nice to be able to divide it up, and yet keep a all-in-one version for those that might like it.

As for what to do next, after bugs, etc. I think getting the discussed changes to Artrage into place is good. Getting a finalized setup in the main Sai toolbar as well (with this issue about Transform tools). After that, I'll probably want to share it, or do UI stuff. After that, probably SBP. I'm excited about optimization for SBP, as I use it to work on landscape designs, but it can wait for now. My brain can only juggle so many things!!! And as you said, the trial version isn't very long.

[lblb]

It's good that you will be busy while we have a usable version because I should also be pretty absent until next Monday (last exam blitz of the semester!)

Great ideas for the color wheel. I'll have to think about the different possibilities. I think the most difficult part will be (if at all possible) to transfer the information from whatever we are using into the art program. For example, I just tested very quickly and both Sai and ArtRage can't pick up a color from something from outside the program. For example, here is a pretty free cool color picker that I found a while back:

ColorPic, The Desktop ColorPicker Software

While it does some nice stuff, I have a hard time seeing how we can transmit the information from this to ArtRage or Sai (whether that's mediated by AHK or not). I'll have to think... I just read about Magic Picker and the reason why it's (apparently) so popular is probably because it's an add-in to Photoshop, i.e. you can transfer the info from Magic Picker to Photoshop. I think that may also mean that it will only work in Photoshop. Also, I won't have time to try soon, but there is a 15-day trial for Magic Picker so maybe that's something to try.

I agree about the future work and about how to go on with splitting it up and sharing it. Indeed, it was very much with these things in mind that I opted to go for v2 of the toolbar.

[lblb]

As predicted, I haven't had time to work on this the past few days. However, I was bored while writing an exam so I played around a bit... To get a 12-hour clock, at the very bottom of the Toolbar_Subroutines file, replace the definition of currentTime1 (note: not currentTime2) with the following:

currentTime1:
FormatTime, display3, YYYYMMDDHH24MISS, hh
GuiControl, 20:,display1, %display3%
Return