Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.

hawk

Members
  • Posts

    116
  • Joined

  • Last visited

Everything posted by hawk

  1. +1 Trying to slice up a large grid of sprites is almost impossible right now. (I didn't make the sprites, it's just one large image.) I'm having to manually make hundreds of slices without even any snapping! (Forgot there's slice-to-slice snapping at least, but I'm finding it to not be 100% reliable and having to adjust some of the slices by 1 pixel.) What would help me right now is: A way to convert a layer slice to a regular slice. Then I could make rectangles all over the grid easily with power duplicate, select all, make slices, convert to regular slices, hide/remove the rectangles and export. Fix the inordinate beach-balling when exporting a large number of slices. I clicked export for about 600 slices five minutes ago and it's still beackballing on the destination folder picker... Thanks!
  2. YES YES YES! 🥴 (joking of course, lots of people did want JS after all) Nice! That sounds like I could write a Swift package wrapping that API. The same could probably be done for Python and others. That's great to hear! Send my regards to the programmers, I really appreciate their painstaking work! Thanks for the update, @TonyB !
  3. Good stuff. Really, I skimmed that article and it looks like a great resource/tutorial. However, it really shows that Swift is far from well-suited for OS scripting, or at least for interoperating with shell tools/processes. The amount of boiler plate required to get piping to work is just outrageous. If you're going to use Swift for scripting, you'd better try to stick with the built-in frameworks as much as possible. And even with that there are portability issues because Foundation is slightly different on macOS than Linux or Windows. 🫤
  4. @fde101 Nice! Swift is getting improvements to its static abilities (build-time constants for starters) in the near future, so I will try to bring this up during those discussions. The closest thing to this right now would be enums, for which every value has to be named, or property wrappers, which are not statically checked. I agree now that JS is one of the worst, and Lua would be a good choice. I've been using Lua a bit with the macOS scripting tool Hammerspoon.
  5. @fde101 I somewhat agree with you. I learned a bit of Pascal in high school, it was fun. I've never used Ada but I read through the introductory pages and I kinda like it, but I noticed that many of the features it boasts exist in Swift. Of course, Swift doesn't have a clear distinction between declarative and imperative code as does Ada, but also nothing is stopping you from organizing your code that way. Descriptive block statements (like if ... then ... end if versus if ... { ... }) can be nice but that could be remedied with inline hints in modern code editors if you really needed it (don't know of any examples though) like they already do for type inference. I don't think Ada would be a bad choice for Affinity. There are surely some things that it's simply the best at, and that's not necessarily limited to industrial / safety-critical applications. But if we're going to eschew weakly-typed and popular "scripting" languages like Python, I would submit Swift for consideration as a balanced middle-ground, with its bidirectional type inference, and less rigorous rules. Personally I find that the strong type system and other compiler features help quite a bit in catching mistakes during refactoring! I almost always get errors when I change stuff around and addressing those errors usually ends me up in the right place. (Sometimes the compiler just refuses to parse a large/complex expression and doesn't give you any helpful pointers though. 🥲) Of course, the other mentioned languages, like Kotlin, would be pretty equal contenders in that regard as well, from what I've seen. I'm not a Swift shill as some have previously in this thread accused me of being.
  6. Yes, you understood it precisely! I would add another scenario, an extension of Scenario 4, just to illustrate what happens when the user zooms out again. Scenario 5: User sets the brush size to 64px. User sets the functionality ON. User sets the zoom to be 200%. Software resizes the brush to 32px (or whatever the maths works out to be). User sets the brush size to be 40px via the Context Toolbar drop-down/field. Software sets the brush size to 40px (exactly what the user set it to be irrespective of the original brush size). User sets the zoom to be 100%. Software resizes the brush to 80px (or whatever the maths works out to be). Thanks for hashing out the minute details of this feature with me. Also, to address your earlier point, with this model I think there would be no problem if it was added to other brush-based tools as well, because it'd be no different than manually resizing the brush. In other words, it's a "stateless" feature. Nothing extra is stored. The only thing that is stored is the current size and your existing brush presets, which aren't touched by this feature. (And of course the toggle state itself is stored like other tool settings.) Unless you meant that changing the brush size on its own doesn't make sense or is unusual for some reason, for vector brushes? I don't know, I'm not really an artist myself, more of a mock-up / programmer art / sketch user, as you can maybe tell from the difference between your profile picture and mine. 😅 Personally, I'd probably only use this with the selection brush tool. Thanks for your supportive words.
  7. Thanks for your discerning inquiry! I think there would always be a single source of truth for the brush size, which would be either in document pixels or screen pixels, depending on which works best for the developers. The text box would always show document pixels like it does now. Then if you enabled it, nothing would happen until you zoomed in or out, and you'd see the brush size automatically change proportional to the change in zoom level. Likewise, when you turned it off, nothing would immediately happen. It would just keep the brush size fixed relative to the document, and the cursor brush outline would scale when zoomed, as is the case today. So to answer all three of your questions, toggling the option on or off would preserve the current size, and the app would not keep track of two different settings. (This is how it works in Blender, by the way.) How does that sound to you? A small toggle button would be good. Not sure about the icon but a zoom lens kind of makes sense to me.
  8. Even if you remove all constraints (by deleting the objects even), the constraints group doesn't become a layer and there's no way to convert it back to a layer. I suggest that the "Promote Group to Layer" menu item should work on constraints groups if there are no more constraints.
  9. Please add an option to the selection brush (in Affinity Photo or AD/APb pixel personas) to keep the brush size fixed in terms of screen size when zooming in or out. Motivation: when using the selection brush I often find myself zooming in to work around delicate areas. This is almost always accompanied by manually decreasing the brush size proportionately. (Then the process is repeated in reverse.) Perhaps this could be extended to regular pixel/vector brushes, similar to Blender's sculpt brushes. (Blender also has a circle select mode which is fixed relative to the screen.) I know Blender is a different type of software, but it's the only example of a feature like this that I know of.
  10. I'm seeing the same issue on Apple M1 with "Metal compute acceleration".
  11. The hardware acceleration issue affects macOS too, at least on my M1 MBA. But even with acceleration turned off, I often find the blur brush tool too weak for my purposes, even with the basic brush.
  12. And one can easily write multiline lambdas/closures in Swift thanks to that, unlike Python. You can. It's not as frictionless in Swift, but you can get the same behavior of Python with type erasure and forced down-casting. Ideally you'd mix types based on a common trait (protocol), though that has limitations at the moment. It is work in progress. But still faster than Python, right? Debatable. Swift has excellent type inference, function overloading, full-fledged struct and enum types, and safety features that make debugging easier. Along with argument labels, this makes it possible to design a really nice, natural API for Affinity. Swift is cross-platform, supported by popular editors like VSCode, and has a growing package ecosystem with an official package registry on the way. There's also PythonKit (based on Swift for TensorFlow) that would allow you to "use Python APIs as though they are directly embedding Python itself". So there's no need to fear missing out. Swift is a beautiful, modern language that could be an unusual but innovative choice for Affinity. It could be a bit risky, but I believe it would be for the better in the long run. It will be easier to write and maintain bigger scripts with Swift's sophisticated static type system, which can only be clunkily retrofitted to Python, and the ergonomic advantages of Python in smaller scripts are negligible! Availability of existing libraries and familiarity should be considered Python's biggest advantages, but Swift is easy to learn and can be bridged with Python libraries.
  13. I think the language should be Swift! After learning Swift I don't want to use any other programming language anymore!
  14. I don't see what's the problem. You can do the same in Affinity by creating your own "Global Layers" master layer and applying that to your other masters. I don't know how ID works, but Affinity seems flexible enough here.
  15. I got the announcement email after the live stream had already ended, but at least the replay was available right away. Congratulations on completing the triumvirate, Affinity team! You've done a great amount of work in a short time!
  16. I bought Designer on the MAS because that was the only option available at the time, and I bought Photo when I think it was still only available on the MAS or I didn't know about the possibility of direct purchase (would have preferred it). Then I preordered Publisher through the web store because that was the only choice again (and I had no idea about Studio Link). But now Studio Link won't recognize Designer & Photo (1.7), and I don't find that acceptable. Please make Studio Link work regardless of where we bought the apps from, or refund my purchase, or convert my Designer & Photo licenses to the DRM-free versions since I would prefer that because I basically only use the MAS for Affinity anyway. Nevermind, I didn't see the 1.7.1 update and now it works!
  17. Ctrl+Cmd+F toggles fullscreen by default. There's no default shortcut for switching between single-window and separated mode.
  18. You can also hold space or switch to the view tool [H] if you just want to temporarily get a clear view.
  19. I'm seeing it now, too, but sometimes it only briefly disappears and when I go back it doesn't happen, other times I can get it to remain hidden by stopping the cursor in just the wrong spot like in your clip. I've been playing around with lots of different settings and all I can say is that zooming out makes it more noticeable/easier to reproduce, and it only seems to happen when sliding the node horizontally (even with all snapping options turned off), but it does not happen when dragging (resizing) from one side in transform mode with both nodes selected.
  20. I cannot reproduce it. The highlight doesn't disappear for me.
  21. It's not just 'on the todo list' anymore, it's being worked on. It's not just one person developing Affinity, and those things probably didn't take much time.
  22. You can disable sync in the symbols panel to change individual symbols' text, but there's no way to propagate it to other symbols after that, or to re-sync. I would like to see those options come to Affinity.
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.