ashf Posted November 20, 2022 Share Posted November 20, 2022 Slider knob is hard to see with the Light UI. loukash, François R and Old Bruce 3 Quote Link to comment Share on other sites More sharing options...
eluengo Posted December 2, 2022 Share Posted December 2, 2022 Not only it’s difficult to see it (in this slider and especially in other sliders such as the size of selection brush or other brush sizes in the tool bar), but also the sizes obtained when displacing the slider grow inappropiately quick from the left edge to the right, making difficult to obtain a precise brush size when a moderate size is wanted (i.e. less than 100pt), needing to key in the value into the number field (and precisely in brush sizes where the precise size number is less intuitive than optical/seeable brush size). But moreover, aesthetically the new sliders are more modern and delicate than older in v1 Quote Link to comment Share on other sites More sharing options...
Hangman Posted December 2, 2022 Share Posted December 2, 2022 5 hours ago, eluengo said: Not only it’s difficult to see it but also the sizes obtained when displacing the slider grow inappropiately quick from the left edge to the right, making difficult to obtain a precise brush size when a moderate size is wanted (i.e. less than 100pt), needing to key in the value into the number field (and precisely in brush sizes where the precise size number is less intuitive than optical/seeable brush size). FWIW, you can use keyboard shortcuts to adjust the stroke width, Shift ] and Shift [ will increase and decrease the stroke width in 1px increments, ] and [ will increment the stroke width using a factor of 1.111111 px (I've no idea why that particular value), so you'll get 1 px, 1.111111 px, 1,234568 px, 1.371742 px and so on. Note: These increments will also apply to pt sizes in a 72 dpi document, however, while ] and [ will maintain 1.111111 px and pt increments, Shift ] and Shift [ will translate to increments of 0.24 pt at 300dpi, resulting in strokes of 1 pt, 1.24 pt, 1.48 pt, 1.72 pt and so on... Quote Affinity Designer 2.4.2 | Affinity Photo 2.4.2 | Affinity Publisher 2.4.2 Affinity Designer Beta 2.5.0 (2402) | Affinity Photo Beta 2.5.0 (2402) | Affinity Publisher Beta 2.5.0 (2402) Affinity Designer 1.7.3 | Affinity Photo 1.7.3 | Affinity Publisher 1.10.8 MacBook Pro 16GB, macOS Monterey 12.7.4, Magic Mouse Link to comment Share on other sites More sharing options...
eluengo Posted December 4, 2022 Share Posted December 4, 2022 Yes yes I know But in not-english keyboards access to [, ], {, }, \, ´, > etc... is difficult, using multiple key modifiers Sure you can change the keyboard shortcuts, sure... but all, and every time the preferences reset (what it's not so infrequent...) So is no good solution But, no problem, is not a heavy problem, we can survive without it And I'm reasonably happy with the app suite (and a bit more happy when the iOS versions grow to matureness) Quote Link to comment Share on other sites More sharing options...
loukash Posted December 4, 2022 Share Posted December 4, 2022 19 minutes ago, eluengo said: every time the preferences reset This is a long known bug. Yet to be fixed… Quote MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2 Link to comment Share on other sites More sharing options...
loukash Posted December 4, 2022 Share Posted December 4, 2022 Thinking of it, I actually have a plan to remap a few keys on my MacBook to type [ and ] by using the fn modifier. So on the Swiss keyboard, I'll remap fn-ö and fn-ä (which are the keys where [ and ] would be) to type [ and ] instead. That can be done via karabiner-elements.pqrs.org I'm already using Karabiner to simulate NumPad (that doesn't have any effect in Affinity but it was important in InDesign) and the + key via the fn modifier. Quote MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2 Link to comment Share on other sites More sharing options...
eluengo Posted December 4, 2022 Share Posted December 4, 2022 Know and use Karbiner Elements already This job can also be done into aff apps I could also change keyb.shortcuts to any Fn key, that are seldom used, is an interesting solution…. Quote Link to comment Share on other sites More sharing options...
Staff DWright Posted December 5, 2022 Staff Share Posted December 5, 2022 I have logged this issue with our developers ashf 1 Quote Link to comment Share on other sites More sharing options...
loukash Posted December 6, 2022 Share Posted December 6, 2022 On 12/4/2022 at 6:19 PM, loukash said: Thinking of it, I actually have a plan to remap a few keys on my MacBook to type [ and ] by using the fn modifier. So on the Swiss keyboard, I'll remap fn-ö and fn-ä (which are the keys where [ and ] would be) to type [ and ] instead. That can be done via karabiner-elements.pqrs.org On 12/4/2022 at 9:53 PM, eluengo said: This job can also be done into aff apps It doesn't work the way I expected. All I can do in Karabiner (at least in v11 for El Capitan) is to remap fn-ö and fn-ä to simulate option-5 and option-6, i.e. to type [ and ]. But Affinity still catches it as option-5 and option-6. So the only usable solution for Affinity would be a custom keyboard layout with square brackets without modifiers until the shortcut bug is fixed. That's a job for Ukelele. Nonetheless, my Karabiner mod works in other apps that use square bracket shortcuts like cmd-[ and cmd-] and that follow Apple's shortcut standards. There, typing fn-cmd-ö is the equivalent of cmd-[. The modifications are explained on karabiner-elements.pqrs.org/docs/manual/configuration/configure-complex-modifications E.g. the JSON snippet that remaps fn-ö to open bracket looks like this: "from": { "key_code": "semicolon", "modifiers": { "mandatory": [ "fn" ], "optional": [ "shift", "control", "option", "command" ] } }, "to": [ { "key_code": "5", "modifiers": [ "left_option" ] } ] Quote MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2 Link to comment Share on other sites More sharing options...
eluengo Posted December 6, 2022 Share Posted December 6, 2022 Hi @loukash Thanx for your ideas. Solutions with kbd can be multiple. But the real problem is the way the interface behaves. The sliders are little in size, its increment mey be excessively potential (quick on beginning, slower with bigger sizes).... all the elements in the interface are small. Solutions come through, i.e., enhancing size of sliders, managing number in number fields lively with simple keys like arrows, etc… Also occurs with other commanding structures. With big screens or far screens, all presenting small sizes of interface elements to the eye of the user, the daily use of the apps need a lot of training. Possibly I’m too old to have a crisp seeing capability ( I’m near to 70 year old), but for young eyes this tiny elements pose a high strain to the eyes (possibly ergonomically inappropiate). We really don’t should tell Serif-Affinity to change it’s interface idea, ‘cause apps are as they are’, we only can adapt to what Affinity will offer. I like the suite of apps as a whole (idea, interface, price, outcomes, etc…), and try to adapt to them instead of fight against. Sorry for the excess of philosophy. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.