hawk
-
Posts
120 -
Joined
-
Last visited
Posts posted by hawk
-
-
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.
-
-
Is this a place to post suggestions? If so, I'd like snapping to transparent pixel edges.
Much love.
-
+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!
-
23 minutes ago, TonyB said:
Affinity will support
YES YES YES!
23 minutes ago, TonyB said:Javascript
🥴
(joking of course, lots of people did want JS after all)
25 minutes ago, TonyB said:and also have a 'C' based API binding interface that people can use to write plugins.
Nice! That sounds like I could write a Swift package wrapping that API. The same could probably be done for Python and others.
26 minutes ago, TonyB said:We will also have the ability to create UI to support their scripts and plugins with dialogs and panels.
That's great to hear!
27 minutes ago, TonyB said:We have a team developing this but the amount of work is very large so unfortunately users will need to be patient.
Send my regards to the programmers, I really appreciate their painstaking work!
Thanks for the update, @TonyB !
-
17 minutes ago, v_kyr said:
Related to Swift and scripting, that would be possible too , see also here, at least for/under MacOS
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. 🫤
-
@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.
-
@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.
-
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.
-
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.
-
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.
-
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:
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?
-
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?
-
What about a checkbox like this?
-
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:
* Aside: it would be great to have more fine-grained control over unlinking text attributes (and the ability to re-link attributes).
-
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.
-
I'm seeing the same issue on Apple M1 with "Metal compute acceleration".
-
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.
-
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.
-
On 6/4/2021 at 11:17 PM, rparmar said:
You don't need semicolons but you do need braces.
And one can easily write multiline lambdas/closures in Swift thanks to that, unlike Python.
On 6/4/2021 at 11:17 PM, rparmar said:You can't have heterogeneous lists, but you do have a different type for this functionality.
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.
On 6/4/2021 at 11:17 PM, rparmar said:Slower than Objective-C
But still faster than Python, right?
On 6/4/2021 at 11:17 PM, rparmar said:but more cumbersome than Python
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.
On 6/4/2021 at 11:17 PM, rparmar said:missing the extensive library and platform support
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.
-
I think the language should be Swift! After learning Swift I don't want to use any other programming language anymore!
-
I don't see what's the problem.
QuoteTo Show/Hide "star" or toggle visibility of "w1" and "w2" on all pages, toggle respective layer in "global" layer stack.
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.
-
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!
- iMatt, supermundane and Patrick Connor
-
3
-
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!
Merge Selected without Trimming
in Affinity on Desktop Questions (macOS and Windows)
Posted
Is there a way to merge two pixel layers without the result being trimmed to the canvas?