Jump to content

hawk

Members
  • Posts

    115
  • Joined

  • Last visited

Everything posted by hawk

  1. 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 !
  2. 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. 🫤
  3. @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.
  4. @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.
  5. 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.
  6. 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.
  7. 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.
  8. The 'New Document' panel appears on the same virtual desktop it was last opened on, which can be different from the desktop which the main window is currently on. This happens only if Affinity Designer is not assigned to a desktop (i.e. if you click the Dock icon and Options -> Assign to: None is selected), which is the macOS default. Note: this is without macOS fullscreen. Steps to reproduce: Launch Affinity Designer. Create a new document (File -> New). Open Mission Control and move the Affinity Designer window to a different desktop. Create a new document again. In the unified window mode, the new document is added to the existing window. Furthermore, if the existing window was minimized in the Dock, it is automatically un-minimized and you're automatically switched back to that desktop. In the separated (floating panels) window mode, the new document is created in a new window on the same desktop as the 'New Document' panel. However, if you subsequently click and drag the title bar to reposition the new window, the new window may suddenly be warped back to the original window when you release the left mouse button (this doesn't happen consistently). Demonstration: new-document-spaces-glitch-compressed.mov If the 'New Document' panel simply opened on the current desktop, then these issues could be avoided. Also, if you're using Affinity Designer in native macOS fullscreen and you open the 'New Document' panel, it kicks you back to the last desktop. You then have to manually switch back to the fullscreen space to see your newly prepared document. Question: Is it not possible, and would it not be better also in this case, to show the panel on top of the fullscreen window?
  9. Thanks! It just occurred to me that this happens without the Transform Objects Separately option too. So it's just about transforming objects inside symbols when the transform/constraints attribute is linked. My next question would be: how should this actually work without Transform Objects Separately? I don't think there's a correct answer... maybe the current behavior is more logically consistent after all?
  10. If the same synced object is selected inside multiple instances of a symbol, there is an issue with the Transform Objects Separately option: Transforming the objects with this option enabled, applies the transform delta multiplied by the count of selected objects, causing the bounding box to diverge from the actual result. (if the transform/constraints attribute is linked) While it is true that this can be avoided by deselecting the object in all but one of the symbol instances, that can be inconvenient. For example, consider this scenario: You've got a bunch of symbol instances in your document. Some of the symbol attributes are unlinked (e.g. Text*). You make a multi-selection and start editing a bunch of those unlinked attributes. At some point throughout this process you need to tweak the size or position of the object inside the symbol. Now you need to click to select only one object, transform it, and then reselect all of the other copies, before you can get back to editing the unlinked attributes. That's at least 3 extra clicks, and some cognitive friction. Furthermore: There's no special capability that is unlocked by this behavior. If you want to transform proportionately to the number of objects selected, you could just do that manually. If there really is a great need for this behavior, why is it limited to symbols? Shouldn't it also be available as a general modifier/option on regular groups, layers, etc? This seems like something that could and should be better served by custom scripts if and when those become available. Therefore I consider this a bug which should be fixed by treating the transform/constraints attribute as temporarily unlinked when using Transform Objects Separately. Exact reproduction steps: symbol-transform-separately-bug.mov * Aside: it would be great to have more fine-grained control over unlinking text attributes (and the ability to re-link attributes).
  11. 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.
  12. I'm having these stalls all over macOS since I got my M1 and I thought it was just me because I asked around and nobody else seemed to be experiencing it.
  13. I'm seeing the same issue on Apple M1 with "Metal compute acceleration".
  14. 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.
  15. Version: 1.10.4 (latest) Reproducible: Yes It happens with new documents (new files). Modified documents that are based on opened image files (not .af* project files) are not saved after hopping from one Affinity app to another. Example steps: Open an image file like PNG in Affinity Photo. (Optional: make some edits.) Select Edit in Designer... (Optional: make some edits.) Select Save (⌘S), or close the document (⌘W) and in the prompt click the Save button. Actual result: the Save command seems to fail silently. The original file is untouched, no new file can be found, and no error message, bell, or notification is raised. When the document is closed, your work can be simply lost. Expected: the changed document should be written to the original file (flattened) or I should be prompted to make a choice. In most other macOS apps, issuing ⌘S on unsaved work either writes back to a file, or produces a prompt without fail. At the very least there would be an alert sound (and screen flash if configured) for unrecognized or unavailable keyboard shortcuts. macOS 12 Monterey -- Designer, Photo, and Publisher are equally exhibiting this behavior.
  16. 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.
  17. I think the language should be Swift! After learning Swift I don't want to use any other programming language anymore!
  18. 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.
  19. 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!
  20. 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!
  21. You can also hold space or switch to the view tool [H] if you just want to temporarily get a clear view.
  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.
  23. Have you tried Master Pages aka Symbols? You can toggle the Sync option to customize master objects on individual pages. The big problem, I think, is not having a clear indication whether sync is on or off (you have to check the icon, and even that is a bit low in contrast), and not being able to re-sync attributes. Being able to set some attributes to be desync'ed by default would also help.
×
×
  • 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.