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

hawk

Members
  • Posts

    120
  • Joined

  • Last visited

Recent Profile Visitors

3,574 profile views
  1. Is there a way to merge two pixel layers without the result being trimmed to the canvas?
  2. What is the process for copying a gradient from an object's stroke context to another object's fill context? Quick edit: I just added the gradient to the swatches list for now.
  3. YES! That sounds amazing. Thank you so much!
  4. Is this a place to post suggestions? If so, I'd like snapping to transparent pixel edges. Much love.
  5. +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!
  6. 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 !
  7. 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. 🫤
  8. @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.
  9. @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.
  10. 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.
  11. 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.
  12. 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.
  13. 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?
  14. 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?
×
×
  • 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.