How to use Brush Size by Ring Function Intuos Pro

[Roland Rick]

HELP!

 

I am completely stuck. I tried all settings but somehow it will not work...

 

Q: How to configure Wacom Intuos Pro + Affinity Photo, that key ring can be used to

1. alter brush size?
2. configure zoom in/out to work correctly?

Will appreciate any help! :)

 

CU, Roland

[Roland Rick]

Off topic: if I use the "bulleted list" or "numbered list" function of forum editor, this will be killed after posting...

 

 

 

[Leigh]

Do you have [ and ] assigned to the Touch Ring in the Wacom Tablet driver? This user had a similar issue and reset the Keyboard shortcuts for the Brush Size within the app and it worked correctly. 

 

The Lists feature not working is a known issue, sorry. Unordered bullet list seems to work tho :/

[Roland Rick]

Ahhh, I assumed, the ring function of tablet is an origin function, but it is trivially assigned to the keyboard commands...

 

By the way: important functions should not be fixed to keys you an only reach by US or UK keyboards. With German or Swiss-German (and I assume many else) [ and ] can not be reached directly, and Shift+Alt+5 ( [ ) and Shift+Alt+6 ( ] ) never work.

 

The problem is: todays programmers assign the ASCII code to the functions instead of the so called SCAN Code. The scan code defines the geographical position (!!!) of a key on the keyboard and is always the same key code - whatever for keyboard and language settings are used.

 

While editing a photo, I do not use ö (the key position of [ on US keyboard) and ä (the key position of ] on US keyboard) for typing text and the keys can "automatically" be used for de-/increase brush size.

 

Back in 1986 I learned this becoming an auto didactic software developer. Why is today no one working with scan codes??? What would avoid a lot of work at customer/user side, by being forced to first redefining the keyboard shortcuts for my language and keyboard or working with an US keyboard.

 

ASCII code is a pain in the a?? for keyboard controlled functions. Use scan code. Makes MANY things MUCH easier. ;)

 

 

Do you have [ and ] assigned to the Touch Ring in the Wacom Tablet driver? This user had a similar issue and reset the Keyboard shortcuts for the Brush Size within the app and it worked correctly. 

 

The Lists feature not working is a known issue, sorry. Unordered bullet list seems to work tho :/

[R C-R]

The problem is: todays programmers assign the ASCII code to the functions instead of the so called SCAN Code. The scan code defines the geographical position (!!!) of a key on the keyboard and is always the same key code - whatever for keyboard and language settings are used.

 

As I understand it, in OS X hardware scan codes generated by keyboards are mapped by the system to a set of "virtual key codes," of type alias CGKeyCode. It is these virtual key codes that are hardware-independent, although they require a supported keyboard for the mapping to occur. I'm not sure the raw scan codes are available to user domain applications -- I hope they are not because this could create enormous security vulnerabilities.

 

Regardless, the virtual key codes are generated by low-level keyboard events like 'keydown' so detecting a complete keypress event requires testing for each key held down & released (including each modifier key). For example, that would be six total events for Shift+Alt+5.

[Roland Rick]

Hi R C-R

 

Many thanks for reply.

 

Uh-oh, I never got myself that deep into OSX/Mac system programming but for me it was a kind of logical, that this somehow must be still working identical as in early DOS, TOS (Atari), AmigaOS times ;)

 

Why should scan code create security vulnerabilities?

 

Scan code - as I can remember it - just says "physical key xy is pressed" - independent of national language or keyboard layer.

 

Let me remain on the example with [ or ö and ] or ä and let's do a little bit pseudo code:

If the key is pressed where on Swiss German kbd the "ä" and on US kbd the "]"is located increase the brush size. (FYC: it's the same physical key)

 

Hmmmmm, if you code this referencing scan code (I confess, I have no clue where this is hidden in Swift), the worst thing to happen is, to get rid of the national language and keyboard layer. There must be a API for this, I assume the national kbd drivers are also using it for communication one step down closer to the hardware ;)

 

However, I just tried to make a suggestion in a positive way ;)

 

CU, Roland

(enthusiastic Affinity Photo user)

 

PS: thanks for the link to CGKeyCode :)

 

 

As I understand it, in OS X hardware scan codes generated by keyboards are mapped by the system to a set of "virtual key codes," of type alias CGKeyCode. It is these virtual key codes that are hardware-independent, although they require a supported keyboard for the mapping to occur. I'm not sure the raw scan codes are available to user domain applications -- I hope they are not because this could create enormous security vulnerabilities.

 

Regardless, the virtual key codes are generated by low-level keyboard events like 'keydown' so detecting a complete keypress event requires testing for each key held down & released (including each modifier key). For example, that would be six total events for Shift+Alt+5.

[R C-R]

Hi R C-R

Why should scan code create security vulnerabilities?

Because it is a system domain function. If you let user domain apps have direct access to that, malevolent user domain code could potentially become an extremely effective keyboard logger, recording every keystroke you made while using any app while it was running, through privilege escalation or other exploits. It isn't like in the old days -- now, good security practice demands limiting the attack surface to the minimum needed for an application process to get the job done by sandboxing everything possible & limiting app access privileges to other functions indirectly through things like launch agents & daemons, which themselves have limited access privileges to other functions.

 

Also, the virtual key code mapping is keyboard dependent because different keyboard models do not necessarily have all the same keys in the same physical locations (because they do not all have the same physical layout), nor do they necessarily generate the same scan codes for the same keys. I learned this the hard way when experimenting with a Raspberry Pi running the Raspbian OS -- I have a number of old Apple USB keyboards, all with the U.S. layout, but they do not all generate the same key codes for the same keys.

 

So for example you (as a programmer) cannot rely on the physical position of a key being the same on every keyboard designed for U.S. English or British English language users (they are not exactly the same even on Apple's current keyboards), much less third party keyboards designed for English, German, or whatever; & even if you could you can't assume the raw scan codes would be identical.

 

I'm not saying it could not be done, but it would be impractical, inefficient, unlikely to support every keyboard model users might hook up to their systems, & weaken its security.