Jump to content

jclounge

Members
  • Content count

    26
  • Joined

  • Last visited

  1. Amazing brushes once again, thanks Stuart!
  2. jclounge

    Vegetation Brushes Set 1

    Lovely brushes, thanks Stuart!
  3. Sorry for replying to an old thread, but I ran into this issue too. To the devs: Could there at least be a "Paste with same physical size" option in the edit menu? Ideally there would also be a preference setting to always do this by default.
  4. jclounge

    Panning Jumps Around

    Hey thanks MEB! I tried turning off Better Touch Tool and the problem went away! It's also possible to disable BTT only for the Affinity apps, which is not ideal but still much nicer than having the jumpy panning. You just made my day so much better!
  5. jclounge

    Panning Jumps Around

    Thanks Chris, I was already in OpenGL mode, but also now tried changing the modes to Metal and Software, and the jumping still happens. When instead holding the space bar down and using the left-button, the problem does not seem to occur, so it appears likely something to do with just the middle button panning. Also, you can tell for sure when the jump has happened even if it happens quickly, since the mouse ends up pointing to a totally different part of the canvas, which has jumped from under the mouse instead of sticking to it like glue as you would expect. Strangely, if dragging always in the same direction the problem seems to be reduced after the first drag. But if dragging each time in a different direction, the jumps happen almost every time.
  6. jclounge

    Panning Jumps Around

    Hi there, When using the middle mouse-button to pan, there is very often a large and disorienting jump in the panning position. The only time it doesn't seem to happen is when very slowly and cautiously engaging and disengaging the pan. Since I instinctively always try to pan fairly briskly, the jump happens almost all of the time, which is extremely annoying. Cheers, Jules
  7. I don't buy the argument that it would be heavier or more complicated to maintain. Clearly the two apps are using the vast majority of their codebases the same as each other. They can both load each other's file formats, and can both even edit things that only the other app can create, as if they created those things themselves. If they are supposed to serve such different purposes, then why would they ever need to be so tightly compatible? It's plainly ridiculous to pretend they are hugely different in their purposes. Until I see any evidence otherwise, what looks far more likely is that it's a coldly calculated marketing decision. Plus, having two separate apps has certainly not made either one very bug-free, and has caused issues between them where there should be none. I would bet that it is in fact harder to maintain the apps separately because it means keeping track of all their arbitrary superficial differences, and expending time and energy deciding on just the right balance of differences to force people to buy both apps. If they were combined into one app, I would wager that the 1.5 release would have arrived around the same time, with just as many features, and far fewer bugs due to less duplication of effort and dividing of focus.
  8. I stumbled across this issue recently too. When are Designer and Photo going to be merged into a single app the way they probably always should have been? It's a bit annoying having some tools/options here, other tools/options there, breaking compatibility like you have just done, etc.
  9. Has there yet been any progress on enabling pasteboard visibility to Affinity Photo?
  10. Hi folks, I just noticed another bug, this time with the clone and healing brushes in Photo. The clone brush does not obey the force pixel alignment option. This becomes a problem when there is fine-grained texture or very small text or detail that must be cloned. To see what I mean, follow these steps: 1. create a new document and make force pixel alignment enabled. 2. create a grey rectangle. 3. add maximum noise to the rectangle. 4. rasterise the very noisy rectangle. 5. zoom all the way in to clearly see the pixel detail of the noise. 6. select the clone brush tool and set a source point for cloning. 7. without clicking, move the mouse around to preview the clone At this last step, you can see that it's hard to ensure that the clone will be sharp, as most of the time it is off pixel alignment and the resampling destroys all the detail. This is pretty bad. I was wondering why my cloned areas were so blurry, and this was the reason. Also, here are some other issues I noticed while trying to reproduce the clone/heal alignment bug: 1. If you make a fill layer and add noise, either with live or static filters, no noise appears. In fact it looks like no filters or adjustments work when nested inside a fill layer. This is odd, especially because filters and adjustments will work on shapes such as rectangles. 2. Even though adjustments and filters can be nested inside each other at the root tree level, the nested one does not get applied. Cheers, Jules
  11. Hi all, I just found a bug with nudging which exists in the latest versions of both Designer and Photo (v1.4.1). Steps to reproduce it: 1. create a new document 2. paint some squiggles with a pixel-based brush 3. marquee a rectangle region in the squiggles 4. duplicate the region with CMD-J 5. select the move tool 6. move the copied piece with the mouse near to where you want to put it 7. nudge the piece with the arrow keys At the last step, the copied piece jumps back to the position it was before you moved it with the mouse. Cheers, Jules
  12. @Ben, yes I can appreciate that. The more I think about it, the more it seems difficult to find a good balance even in theory, let alone in practice I'm sure. The candidate system you've got is pretty good and quite clever, and it's great that you're refining it. I'm just throwing some ideas out there in the hope that it might be useful. So here's just two more ideas, and then I'm out I promise: 1: Just looking at Inkscape for a moment, it doesn't seem to even allow snapping to infinitely extended box edges like Affinity does, so the majority of the clutter problem is eliminated that way. Maybe something a bit like that could be a "simple" mode: Where all objects are snappable, but they will only snap when up close. Where "close" could be defined as something like within 1X or 2X the size of the object. It wouldn't be overly inelegant to add as a setting either, boiling down to something like one toggle between two snap candidate modes, "short-list" or "proximity", and one proximity limit value. Maybe if that's no good because it loses the guideline-style snapping to objects at a distance, then here's another idea: 2: What if all objects are snappable, but could be explicitly flagged as extending their box lines to infinity for snapping against, and by default only their finite non-extended box edges are snappable. Then the clutter issue is decreased by default, but there's still an option to be able to line objects up at distant parts of the canvas. With the point about games, I understand that this is not exactly the same thing, but also think that there are relevant similarities. I was just agreeing with you by disagreeing with Oval that performance is likely the issue. Anyway, I think you're doing great work, and this is just my (possibly naive and misguided) thoughts to add to the mix. :) Cheers, Jules
  13. The current way to select objects as snap candidates is to hover over them. Their outline flashes subtly for a moment when they become selected, but there is also a snap settings option to show all candidates at all times. There is a limited number (6) of candidates possible at once, and new ones flush out old ones. As far as I can tell, it seems there's currently no way to make a group object into a snap candidate as a whole, you can only select leaf objects within group hierarchies. I agree, it would be nice to be able to snap to recently selected or pasted/duplicated objects. Maybe those could even be maintained as an auxiliary shortlist that won't flush objects out of the other list, or something? If it was a group object that was selected/created, maybe just the root of it could be added as the new snap candidate, so the whole thing would be reliably snappable at least in a bounding box sense, instead of all the little leaf objects which would instantly blow out the shortlist leaving a small random assortment as candidates. Or maybe even this: Once a group is a snap candidate, that could mean that ALL the leaf objects inside that group are snappable. Then it's still a manageable shortlist, but the list could effectively be large due to whole groups being in it. Alright well, I really should snap into bed for the night. :P
  14. The developers have already claimed that it was to help users to avoid snapping clutter. If it was a performance issue, a relatively trivial bit of code would accelerate the performance dramatically. Games do this kind of thing all the time, but at a far more complex level and in 3 dimensions. Hehe, my Illustrator remark was a bit of a cheap shot for dramatic effect to try capturing the attention of the devs, but it is not necessarily wrong. They have stated from the outset that they are competing with Adobe's products head-on, at least that's the narrative that I read. And, as stated, it's not just about reading the manual, it's about having a basic desirable option available too. It's simply annoying the way it works now most of the time. Who on this planet enjoys hovering and waiting for a computer to decide to do something over and over again? Maybe if there was an option to make the hover time much faster, that could help. Or even better, something more inventive like being able to click the right button while dragging an object with the left button, to instantly make whatever you're hovering over into a candidate, instead of having to unnecessarily wait like a helpless sap. It really is the little things sometimes, ergonomics are paramount in such an intensively gui oriented app. Since snapping is something you want to do very frequently, it should always be as quick and painless as possible to do. Fair enough about the text snapping thing, I totally agree that snapping should be a solved problem in 2016. Again for balance I have to reiterate that the Affinity apps are very smooth and slick in many respects, but just a handful of little things here and there would help make it even better!
  15. Hi guys, well I love the Affinity apps, but I have a tiny little suggestion which I think could help a lot: Add an option to simply make all objects snapping candidates. Let the user decide if it’s getting unwieldy and to switch to the shortlist limitation. Make this enabled by default. I would suspect that a vast number of users would leave this option enabled most of the time, if not always. Only when it truly gets unwieldy with too many snap candidates would they look through the snap options and discover that there is an option to switch down to a shortlist. Also, now actually realising that there is a shortlist, the user would then be mentally primed to find out how it works. This would all but eliminate the very understandable current user thought process of “snapping seems buggy, this app is flaky, how can they not have snapping sorted out in 2016? Back to Illustrator I go.” And it's not just a learning curve and app adoption thing. Even though I now know about the candidates shortlist, I would way rather switch it off right now and just effortlessly snap objects together! Cheers, Jules
×