fde101
Members-
Posts
4,936 -
Joined
-
Last visited
Recent Profile Visitors
5,531 profile views
-
Agreed, and that was never the issue here. When I first saw the post it struck me as reading like a bug report, but it was posted in the section of the forum meant for feature requests. I was questioning if it was posted in the right section on the forums, not whether or not it was permitted to be posted at all.
-
Bit Disappointed reacted to a post in a topic: Once again, the update breaks things that worked before
-
fde101 reacted to a post in a topic: Colour input on the Stroke panel in Designer
-
languidcorpse reacted to a post in a topic: Bring Image trace (image to Vector) to Affinity Designer.
-
The purpose of which is defined here: https://forum.affinity.serif.com/index.php?/forum/122-feedback-for-the-affinity-v2-suite-of-products/ This is primarily a section of the forum intended for feature requests. Granted the name is a bit confusing given that function, but that is how it is set up for use.
-
bbrother reacted to a post in a topic: Once again, the update breaks things that worked before
-
GripsholmLion reacted to a post in a topic: Versioning
-
GripsholmLion reacted to a post in a topic: Once again, the update breaks things that worked before
-
garrettm30 reacted to a post in a topic: What would it take to get Affinity on Linux?
-
You may be better off pushing the Wine project to improve their Windows emulation support in the areas that currently prevent the Windows version from working well via that mechanism. You would *definitely* have been better off adding this to one of the existing threads on the topic rather than forking off yet another pointless duplicate one.
-
Exporting to 72dpi/ppi by default
fde101 replied to PaoloT's topic in Feedback for the Affinity V2 Suite of Products
Agree, 96 = 4 * 24, 72 = 3 * 24, so need 12 * 24 = 288 to make this work. -
I believe the file format was designed to allow the file to be updated in place rather than replaced as a performance optimization. Rather than writing everything each time you save, the application only needs to rewrite parts of the file that have changed. If that is an accurate assessment, then a feature such as the one you describe would defeat that optimization and slow down the save process by forcing the application to write the entire file every time it gets saved, as Photo does now when doing PSD round-trips with DAM/raw processors such as Capture One, which takes quite noticeably longer than saving a native Affinity document does after the initial save. This is not to say that it couldn't be done, or that it shouldn't be considered, but it is a factor to bear in mind that would likely be impacted by enabling a feature like this.
-
Not sure that I agree on that one, but regardless, there is usually more space to make a set of sliders wider than taller, and a longer slider allows for more precision. That said, a slider will never offer the same level of precision for a wide range of values that you can obtain with controls that allow for direct or relative entry as they are always constrained by the pixel resolution sitting underneath them (most GUIs do not allow for sub-pixel mouse tracking so if the slider is 150 pixels in length, for example, the slider can only input 150 distinct values). EDIT: if you were able to dedicate a display to the controls, you might have a case for a more mixer-like interface with a bunch of vertical sliders spread across the screen and controlling various parameters. In practice many of us are on single screens and the time taken to move the mouse from one screen to another (to make a selection on the image then go across to manipulate the values) would probably slow things down, and using that type of interface on a screen shared with the image would result in too little horizontal space for the image itself. A touchscreen could eliminate the mouse movement issue, and one interesting possibility might be an iPad-based remote app (or Android tablet for that matter) to control the parameters of the image displayed on the computer, but for the interface on the computer itself, I'm not sure if a statistically significant percentage of users would find that type of interface to be a net gain.
-
Alfred reacted to a post in a topic: Affinity Photo 2: more precise controls for percentage slider values
-
Randolph reacted to a post in a topic: Please change the "Selection" range item in the print dialog to "Selected layer"
-
myclay reacted to a post in a topic: Linux user base keep growing !
-
faulknermano reacted to a post in a topic: Various feedback after 7-day trial of Affinity Photo 2
-
fde101 reacted to a post in a topic: Various feedback after 7-day trial of Affinity Photo 2
-
Linux user base keep growing !
fde101 replied to Wanesty's topic in Feedback for the Affinity V2 Suite of Products
The Arm64EC thing is kind of interesting, but it is basically a transitional tool for developers to use to gradually provide native ARM64 ports as part of the development process, it is not how the "emulation" Windows provides work. My comment was more that I don't think Serif is doing this at all - I don't think they are explicitly transitioning their apps to ARM for Windows (yet?) - so they are likely fully "emulated" at this point (in whatever sense Windows "emulates" x64 under ARM64 systems). -
UI font size should really be controlled by the operating system rather than the application, but there actually is a "Large" option under the User Interface section of Preferences/Settings (at least on macOS; from what I have seen on the forums the Windows version is missing a few of the UI options that the macOS version offers).
-
No, it isn't. It is not a bad additional option, but named tags would be preferable to color tags, particularly since there are already colors for layer layers which may lead to confusion between the layer colors and the color tags. Named tags are not subject to color blindness or to having subtle shades making them difficult to differentiate. Consider: If you were not familiar with the program, would you know what the layer color was, and what the color tag was, based on seeing something like this in the layers panel? If you could customize the color tags, users may eventually start doing things like what I did here with the layer colors (which are the ones to the left of the thumbnails for anyone who does not know): You can only get so many colors in before you start resorting to things like that - not an issue with tags that have names instead. The one downside of named tags is that they would be too big to reasonably fit in the layers panel, so you maybe would just need a generic tag icon to show that there are tags, and provide the names of those tags in a tooltip or similar.
-
Linux user base keep growing !
fde101 replied to Wanesty's topic in Feedback for the Affinity V2 Suite of Products
I believe that is via dynamic translation though, not with a native ARM build? -
Linux user base keep growing !
fde101 replied to Wanesty's topic in Feedback for the Affinity V2 Suite of Products
It has come up on the forums a few times that they are using one of the native Microsoft frameworks for their Windows version. This has been cited as the reason they have not released an ARM build for Windows, because the framework was (at the time) 32-bit only on ARM, and the Affinity apps are 64-bit only. WRONG. If FFmpeg is compiled to use these codecs it is illegal to use in the USA (and several other countries) unless patent licenses have been obtained. The codecs themselves are covered by necessary patents - not just the implementations of those codecs. -
Not true if you have a pixel selection and there are no layers selected (though offhand I think the option should be disabled in that case - maybe making it even more confusing to users who are not aware of which selection it refers to?) You could do something like "Selected Layer(s)" or "Layer Selection", possibly "Vector Selection" if you would rather go that route, but I agree that some way of more clearly denoting that this is not the pixel selection should be considered.
-
Linux user base keep growing !
fde101 replied to Wanesty's topic in Feedback for the Affinity V2 Suite of Products
Sounds like we are on the same page here. One of the biggest issues that I would encounter right now with a switch to Linux as my primary platform is the way that patented media codecs tend to be handled by the available applications. As I am in the USA where software patents are (sadly) enforced, I can't legally make use of applications which support codecs like the ubiquitous x264/x265 but have not obtained the required patent licenses. Many open source applications either include support for these codecs without having obtained the licenses, making them virtually impossible for users in the USA to use legally, or make them optional so that you can grab them if you are in a country where the patents are not enforced or don't mind taking the risk of using them illegally. There are few if any options that would work across the majority of relevant applications on the platform to enable *legal* support for those codecs, and I need to maintain that support (both read and write) for the foreseeable future. This means that my choices in applications would be substantially more limited than for most.