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

fde101

Members
  • Posts

    4,950
  • Joined

  • Last visited

Reputation Activity

  1. Like
    fde101 got a reaction from Pšenda in Please display the image dimensions in the UI at all times!   
    Consider this from the other direction: why should the space be wasted on what is largely static information which most of us don't really care to see 99.99% of the time instead of being used to display more tools that we can then conveniently access to get our work done?
  2. Like
    fde101 got a reaction from Alfred in Why is it so hard to rotate something?   
    Oh...  Affinity Photo, right... gotcha.
    The Transform panel applies to a vector-based selection, while most of the tools in Photo ignore that and work with raster-based data, which is treated separately.
    The Transform panel works with most of the vector-oriented tools, such as the shape tools, pen tool, text tools, and so on, though its exact meaning changes depending on the context.
    With the raster-oriented tools there is no valid vector selection so it makes sense that the controls in the panel would be disabled.
    I actually do find that to be quite intuitive.
     
    I agree there could be some improvement here to the sizes of the zones in which these work.  I think the overall behavior is good, but as you indicated, the sizes of the target areas can be a bit of a problem.
    It is a double-edged sword though, as making those areas too large can make it difficult to work with multiple objects when they are close together - instead of selecting a nearby handle you might windup transforming the already-selected object, so it could get somewhat frustrating in the other direction if they make those zones too large.
    I can actually find them fairly quickly, quite consistently by now, so it is not a problem for me, but it did take a few times before I got there - and not all pointing devices are made equal; I could imagine hitting that target would be more difficult with some than with others, and for users who are newer to the application.  Thus I believe the size of these target zones should really be made into a preference.
     
    It wouldn't hurt, no.  I'm not sure how much it would help either, as the handles of the layer do turn into "X" indicators, so there is already visual feedback to indicate the layer is locked...  but it wouldn't hurt.
     
    We're not.  Sometimes different users have different ideas about what is easy and what is intuitive.  There are definitely areas where the application could be improved, but many of the things you are pointing to as problems were done the way they were for a reason which makes perfect sense and improves the overall flexibility of the program.  Some of the things you are asking to change would actually make the program less intuitive rather than more.
  3. Like
    fde101 got a reaction from Fun Art Sam in Remove individual master pages   
    You can remove an individual master by deleting its "layer" in the layers palette.
  4. Like
    fde101 got a reaction from emmrecs01 in Why is it so hard to rotate something?   
    Oh...  Affinity Photo, right... gotcha.
    The Transform panel applies to a vector-based selection, while most of the tools in Photo ignore that and work with raster-based data, which is treated separately.
    The Transform panel works with most of the vector-oriented tools, such as the shape tools, pen tool, text tools, and so on, though its exact meaning changes depending on the context.
    With the raster-oriented tools there is no valid vector selection so it makes sense that the controls in the panel would be disabled.
    I actually do find that to be quite intuitive.
     
    I agree there could be some improvement here to the sizes of the zones in which these work.  I think the overall behavior is good, but as you indicated, the sizes of the target areas can be a bit of a problem.
    It is a double-edged sword though, as making those areas too large can make it difficult to work with multiple objects when they are close together - instead of selecting a nearby handle you might windup transforming the already-selected object, so it could get somewhat frustrating in the other direction if they make those zones too large.
    I can actually find them fairly quickly, quite consistently by now, so it is not a problem for me, but it did take a few times before I got there - and not all pointing devices are made equal; I could imagine hitting that target would be more difficult with some than with others, and for users who are newer to the application.  Thus I believe the size of these target zones should really be made into a preference.
     
    It wouldn't hurt, no.  I'm not sure how much it would help either, as the handles of the layer do turn into "X" indicators, so there is already visual feedback to indicate the layer is locked...  but it wouldn't hurt.
     
    We're not.  Sometimes different users have different ideas about what is easy and what is intuitive.  There are definitely areas where the application could be improved, but many of the things you are pointing to as problems were done the way they were for a reason which makes perfect sense and improves the overall flexibility of the program.  Some of the things you are asking to change would actually make the program less intuitive rather than more.
  5. Like
    fde101 got a reaction from AcrobaticMelon in Org chart view for history/futures   
    Hi @AcrobaticMelon, welcome to the forums!
     
    I agree that the current icon-cycler behavior is a less than optimal way to display this, but I'm not sure that a tree view is the best choice either.
    At what point would it break this into a hierarchy?
     
    I suspect a more org-chart-like display would probably work better - more like the snapshot manager in some of the VMWare products:
    https://pubs.vmware.com/ws6_ace2/ws/wwhelp/wwhimpl/common/html/wwhelp.htm?context=ws&file=ws_preserve_sshot_manager.html
  6. Like
    fde101 reacted to AcrobaticMelon in Org chart view for history/futures   
    Would it be possible to display futures in a tree-style view instead of cycling through them with an icon next to an operation?
    Using an icon works when there are only a few possible futures but it can get clunky when flipping back and forth with futures with their own child futures.
  7. Like
    fde101 reacted to casterle in Studio panels (AP 1.8.3)   
    The OCD in me is triggered by the behavior of the various Studio Panels. Specifically, I'm frustrated with the behavior of the panels which insist on changing their height for no good reason. It drives me nuts when I click between panels in a group and the height of that group changes, changing the height of everything else in the stack. For this reason I have to find panels that don't behave this way and group them together, whether it makes sense or not. But wait, it gets worse.
    Since the fixed-height panels are of different sizes, you can't dock them in the same group without the group resizing as you switch between them. Thus, you need one group for each panel, and you have to find other (resizable) panels that are useful at that size. What shall I dock with the Transform Panel?
    Worse, at least one panel allows resizing when floating, but when switching to their tab in the group resizes the group anyway - I'm looking at you, Sources Panel. 
    Panels have acted this way since I started with AP (1.5.x); I'm now using 1.8.3. I hope you'll find time to remove the max-height limitations.
    Thanks for listening. 😊
  8. Like
    fde101 got a reaction from angelhdz12 in Scripting   
    No matter what features the devs add to the app, there will always be people with more specialized use cases who can leverage scripting to automate tasks that would otherwise be repetitive.
    There are largely two categories of use cases with different sets of requirements:
    One is a need to automate tasks within the application itself.  If someone is repeatedly doing something basic that may well be specific to their line of work which would not be a good fit for a general feature of the program, a scripting language integrated into the application can often create specialized functionality that could help to avoid repeatedly doing the same task for those users.  This is the use case that most of the people who are arguing Python vs. Lua vs. Javascript etc. are likely thinking of.  This feature would benefit more of the individual layout artists and designers compared to the other bullet point below, as it would enable them to more efficiently tailor the software for their individual needs and workflows. The other major use case is the need to integrate multiple applications by tying together programs that each do some specialized task.  This one cannot be handled by a programming language that is integrated into the application but rather by having the application support the OS-provided scripting languages so that multiple applications can be tied together by a script to automate tasks that no one of the programs could do by itself.  This is the use case that the AppleScript users are mostly thinking of (or OS-provided JavaScript/VBScript - OSA/WSH/etc.) as it enables control of multiple applications from within the scripting language, a case that could not be readily handled by an embedded Python, Lua, etc. interpreter.  This is a critical capability in some production environments and would benefit some individual artists/designers as well. In both cases, it boils down to providing support for more specialized needs without otherwise bloating the functionality of the app itself trying to handle every little corner case that every possible user might come up with, and both sets of requirements will be important to different users.
     
    Dashboard is still there.  If AppleScript does fall into disuse, it is more likely to lose out to Swift than to JavaScript, at least in the Apple world.  (Yes, Swift can be used as a scripting language...)
  9. Like
    fde101 reacted to Lorox in Resizing text frame using scale handle should scale contents   
    Possibly, I haven't really thought of it this way...
    Personally, I think that Adobe has it adressed quite satisfactory: in InDesign all handles firsthand affect only the container as such and the content stays as it is (except from text flowing differently by forming longer or shorter lines according to the changes in the size of a text frame). But when you press the command key while dragging the handles the frame's content gets scaled along. You learn this once and you've got it, I'd say.
  10. Like
    fde101 reacted to Fixx in White, grey and black picker for color balance   
    It would be useful. But I find it easy enough to set white and black points by dragging triangles in histogram, using eyedropper to click black and white does not bring much advance. YMMV.
    But what really handy things are missing now:
    auto (will set white and black points automatically, can be tweaked by user after)
    white balance (the grey eyedropper)
    tone clipping alert (available only in develop persona, would really help in setting white and black points)
  11. Like
    fde101 reacted to Claudio60 in White, grey and black picker for color balance   
    It would be very useful and appreciated (at least for me) adding this feature under levels and curves adjustement.

  12. Like
    fde101 got a reaction from Gokhan Eser in Alignment   
    It is not clear from that exactly what you want?
     
    First, look at the context toolbar (the one below the main toolbar that you opened the popup from):

     
     
     
    As another option, consider enabling alignment handles, using this button on that same context toolbar:

     
    This places an assortment of small arrow-shaped handles along various edges of selected objects:

     
    Combined with snapping, you can drag those handles to align the objects with other objects.

  13. Like
    fde101 reacted to garrettm30 in Compatibility with Mac services   
    I request making Publisher compatible with the Mac standard feature Services.

    It is a good way for people to extend functionality of existing apps in many different ways, a lot of times with rather personalized needs. Here are a couple scenarios:
    Word count. Many have requested word count (an example thread), but a partial solution would be available already if Affinity apps just supported this Mac standard feature. People could just install word count as a service (such as in this how-to example), and they could get word and character counts from selected text.
    Dictionaries and grammar. A few of us have been requesting integration with the French and English grammar checker Antidote, but Antidote is already available as a service. We could probably get a long way toward integration if Affinity apps merely supported services for rich text.
     
     
     
  14. Like
    fde101 reacted to Lem3 in Warp Tool Should Work on Layer Mask   
    If I add a mask to a pixel layer and modify the layer with the Warp Tool, only the pixels are affected, the mask doesn't change.  I don't understand the logic here, the tool should work on the mask as well.  Like in that "other program".
  15. Like
    fde101 got a reaction from Paul Mudditt in new cameras support   
    The response you pointed to was in a section of the forum related to the iPad versions of the Affinity products, which only use Apple's RAW engine.
    This thread was posted for the desktop versions, which can use both Apple's RAW engine (Mac only) and Serif's own RAW engine (both platforms).
  16. Thanks
    fde101 reacted to Alfred in Corner Tool Node Types   
    Thanks.
    Those nodes are only smaller when the Corner Tool is active. I presume that’s simply to indicate that the tool will have no effect on them.
  17. Like
    fde101 reacted to Alfred in Corner Tool Node Types   
    Or rather, the Corner Tool only works on a sharp node. The real question here is why the left and right semicircles in the OP’s screenshot don’t have two sharp nodes like the middle semicircle does.
  18. Like
    fde101 reacted to Alfred in Blurring everything   
    I don’t think it should be. As I see it, ‘Move by whole pixels’ should be presented as an alternative to ‘Force pixel alignment’, thus allowing the user to retain decimal values (as @MEB described) rather than having each pixel coordinate rounded to the nearest whole number.
  19. Like
    fde101 got a reaction from Alfred in Blurring everything   
    Bingo.  Logically, if an object starts on a pixel boundary and is moved by whole pixels, it will stay on a pixel boundary.  Similarly, if it starts on a pixel boundary and is forced to stay on a pixel boundary, then it will always be moved by whole pixels.
    The option to force pixel alignment as currently implemented has no effect when "move by whole pixels" is enabled; when moving by whole pixels takes priority, then anything which is not on a pixel boundary is forced to stay on a non-pixel boundary.
    On the other hand, force pixel alignment mostly implies moving by whole pixels when the pixels are aligned to begin with - and if they are not, then that is the entire point of the option - to force them to be aligned after they are moved.
    Using both of these options at the same time is completely pointless.
     
    For those cases the option to "move by whole pixels" should be a property of those specific objects and override the global setting.  It should not be a global or document-wide setting that imposes on everything as this defeats the purpose of "force pixel alignment".
  20. Like
    fde101 got a reaction from dominik in transformation origin   
    It is command on the Mac.  It will resize around the transformation origin instead of the center when the transformation origin is visible.
    Same with shear: holding down command shears around the transformation origin when it is visible, or the center when it is not.
  21. Like
    fde101 reacted to MikeW in [ADe] Select same color / fill / stroke / appearance   
    Geez. So Matt writes that select same us the next feature he's going to work on, writing that today, and that initially it will work like Illy with it to be extended in the future and you feel the need to be a glass half full type of person?
    Any wonder why Serif stopped responding much to requests? 'Cause if this is the type of response, I would too.
  22. Like
    fde101 got a reaction from Brinomi in Changing node from sharp to smooth via modifier   
    All,
    Remember to check the help/status bar along the bottom of the window for things like this...  it shows all of that information when you point at the nodes.
  23. Confused
    fde101 got a reaction from robinp in [ADe] Select same color / fill / stroke / appearance   
  24. Confused
    fde101 got a reaction from robinp in [ADe] Select same color / fill / stroke / appearance   
    No, it is to "like" the original post.  That is one of the greatest benefits of having the ratings feature, but only if people actually use it.
  25. Sad
    fde101 reacted to robinp in [ADe] Select same color / fill / stroke / appearance   
    If that’s the case, then why didn’t you just react to my message and leave it at that?
×
×
  • 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.