Jump to content
You must now use your email address to sign in [click for more info] ×

Kepa Online

Members
  • Posts

    11
  • Joined

  • Last visited

  1. I just tried it on v2.4.1 on Windows and I can confirm that Affinity Photo on Windows performs the way you describe (focus is on different UI element to Mac so tab key is unnecessary to get to input box and it doesn't have the dialog re-appear after pressing Enter when Apply button has focus). So, yes, this seems to only be an issue on v2.x on Mac OS X.
  2. Ah, Windows probably works differently. I'm on Mac OS v14.2.1 (Sonoma). I'm using v2.4.1 of Affinity Photo. Out of curiosity, how would I get access to a beta version?
  3. Sorry, I thought I included the Affinity Photo version number... I'm on the latest version: v2.4.1. This issue was introduced later v1 because I used v1.x happily until I think this issue started in v2 or one of the minor releases of v2.
  4. At one point Affinity Photo started doing this slightly annoying behavior. Repro steps: 1. Use the loop selection tool to select part of the image. 2. Shift-F6 (on my system I use Shift-Fn-F6 because of how I have the F shortcut keys set up). 3. Tab to the pixel input box (it has 0px to start) and type "30px" (for example) in the input box. 4. Press Enter (this is very important- do not click Apply, just press Enter and you will need to do it twice because the first Enter just "commits" to "30px" input in the input itself while the second Enter essentially triggers the default action button which is "Apply" for this dialog) 5. Watch in horror as the dialog just re-appears with 0px as the input once again. 🙂 I know, it isn't a big bug, but it just annoys me that this is really the only bug I encounter with an otherwise perfect product. *Edit: after getting feedback from others below, I'd like to clarify that this only appears to be an issue on Mac OS X with Affinity Photo v2.x (specifically use v2.4.1 so you're on the latest version because it is possible that this bug was only introduced after a minor update to v2- maybe the initial v2 worked fine... I can't recall exactly when I started seeing the issue, but I know that v1.x did not have it).
  5. I often export large files as PNG and I've found that this takes a while so I often multi-task... I browse other photos I'm processing figuring out what photo I'd like to deal with next. Sometimes I forget about this bug and open the photo in Affinity (directly from Finder or Adobe Bridge) and then it hangs during the export. I'm assuming that some logic just needs to be put in place to handle this scenario better. It is a pain for me because I then have to kill Affinity Photo and restart it and start over and I'd rather avoid that.
  6. It is possible this is related to AFB-7053. I will try the v2.0.4 update and see if it occurs again.
  7. I've designed an app UI with Affinity Designer where I have multiple images laid out. The layout has a mix of portrait and landscape photos. I copied each of these types of "components" to create the flowing layout of images. I then switched out the photos within each of these "components" so that I had some variety in the UI. For example, there are 6 photos shown and 2 of them are portraits while 4 of them are landscape photos. So, all of them were unique when I saved the file. After reloading in Affinity Designer it shows all of the portraits the same and all of the landscapes as the same image! When this first occurred to me I thought I'd done something wrong but then I fixed all of the images and saved and it reverted back again. Even saving to a new file and loading that had the same weird result. I suspect it is somehow keeping a "pointer" to the image it had when I copy each of the "components" that include the image. The really strange thing is that the thumbnails look fine- so I know that the changes should be in the file, but when I open it in Designer it loses the changes and when I resave as a new file that file now has thumbnails that show the duplicated images. I'm going to try it in Designer v1 to see if this is just a new issue in v2.x.
  8. Right, I think this is a Mac specific thing because the scrollbars are hidden until needed. It appears that they are just treated by Affinity's products as always part of the content area on Mac. I believe Affinity should take this into account instead of just aways treating scrollbars as part of the content area for the purpose of displaying different cursors. I've confirmed this is still an issue on the v2 products. I still love the products- they are amazing- so this isn't such a big deal, but it would be nice to see it change. I like your suggestion of using the space bar though- that seems to do what I need too, so I'll be using that going forward. Thanks!
  9. I have a need to automate something myself. I have groups within groups and then items with "toggled" visibility. For example, I have 2 items in a group where one is visible and the other is not visible. I need to write a simple script to basically flip the visibility toggle. The reason for this is that I've designed a UI with "Edit" and "View" states. There are multiple UI elements that are affected by this state. It would probably also help to be able to "tag" these UI elements in some way so that the automation could work better. Anyway, regardless, the most basic functionality I need is a way to trigger this script (button and assignable keyboard shortcut) and the ability to iterate through the hierarchy of elements and see what their names are and then toggle state based on current visibility and name. It would be nice if the language supported was TypeScript but that's less important than the API itself just being available.
  10. The current behavior is that it does not change from whatever tool's cursor you have chosen. It should really change the cursor to a pointer or something else appropriate for scrollbars. This is most obvious with a large brush (expand using right square bracket key `]`) because it is hard to see the center of the brush and when you're hovering over a scrollbar you'd like to know whether you really are over the scrollbar or not. I often find that I guess wrong and then the brush draws on the image instead of performing the scroll operation that I intended.
  11. I've seen others mention this, but felt it would be good to break it out into a forum post by itself so others can vote on this separately.
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.