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

fde101

Members
  • Posts

    4,936
  • Joined

  • Last visited

Recent Profile Visitors

5,531 profile views
  1. 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.
  2. 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.
  3. 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.
  4. Is this a feature request (you want Serif to continue breaking things with every update), or is it a misplaced bug report in the wrong place on the forums?
  5. Agree, 96 = 4 * 24, 72 = 3 * 24, so need 12 * 24 = 288 to make this work.
  6. 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.
  7. 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.
  8. It actually stores and uses non-integer values behind the scenes, but rounds them for display. Some values allow the rounding to be adjusted in Preferences/Settings, but I don't see one for percentage values (which would be nice to have added). I believe that may have been requested before.
  9. 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).
  10. 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).
  11. 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.
  12. I believe that is via dynamic translation though, not with a native ARM build?
  13. 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.
  14. 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.
  15. 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.
×
×
  • 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.