MattP
-
Posts
4,485 -
Joined
-
Last visited
Posts posted by MattP
-
-
The presentation video says that it's compatible with iPad Air 2 and later.
Too bad there is an error on the Store.
Best regards!
We're genuinely really sorry about that - there's no way in the App Store to limit it to Air 2 or greater, so we tried to make it clear on the description that it only "supports iPad Pro, iPad Air 2 and iPad (early 2017). Please note that older iPads are not supported" - but I realise that if the 'compatibility' section at the bottom lists your device, you just buy it without reading the text... Again, we whole-heartedly apologise, we tried to do everything we could with the frameworks and mechanisms we have available, but there is currently no way to specify simply Air 2 and above. The reason is just down to hardware support for particular Metal features that isn't there in the original iPad Air :(
Thanks for you understanding,
Matt
- Mark Ingram, ronnyb, F_Kal and 3 others
-
6
-
If you happen to find one that you know is going to crash (a file with one saved in that state, perhaps) then could you save it and email it to us please? I can try to sort that out - I'm sure it must be very frustrating, sorry :(
Anything you email to support@seriflabs.com will be treated confidentially and not used for any purpose than fixing this issue, of course...
Thanks!
Matt
-
Increase your Miter limit to at least 1.5 and all should be well :) Miter limit is the point at which a sharp corner will decay into a bevel corner - at present you have it set to '1 line width', so when it goes around a corner, it would require it to be greater than one line width (in this case, a 90 degree corner like you have would require sqrt(2) as the value, so just put 1.5 and it will work fine)
I think that made more sense in my head than when I typed it, sorry... :)
-
@steve_m:
Are you ever going to get a Staff badge?
hahaha! I did ask for him to get a 'promotion' - but it obviously hasn't materialised yet! ;)
-
-
-
Actually, I can put it more succinctly: if you just want features, we can get them in faster. If you want features that are great to use, we have to make sure they're written by the right people, in the right order :) There are lots of other vector packages - and I personally don't enjoy using them as much...
-
I wrote DrawPlus's mesh fill tool over 10 years so we have no issues with our ability to achieve it. However, it hasn't yet reached the top of my list so my time is currently best spent achieving other goals which will become more clear as time passes. Our code base is easily extendible, very forward-thinking and there is nothing remotely 'worrying' about certain tasks being best undertaken by certain people- everyone has their own strengths :)I'm not talking more dev (although they also need more dev like they employed Steve, I guess not too long ago), I was referring to the other devs that have been collaboration for years already
if they can not code a mesh fill tool or sth. that is a weird state of their code base/ code complexity of a brand-new project and is worrying
- VIPStephan and A_B_C
-
2
-
Sorry, your points seems to exist for the purpose of changing the subject.
I have to reply to this: R C-R's points actually exist because he doesn't share the same opinion as you, and that's completely fine. Everyone has their own opinions and that's a good thing - and all opinions are listened to and we try to react to them to improve. Sorry when we don't get things right first time, but that's part of being human - we're trying at least.
- Krustysimplex, bagmetv, Aammppaa and 3 others
-
6
-
To put that in context, Steve did say that he was 'experimenting' right now - because he's trying to change our design to be more like customers are asking for... We had a design of our own before going public - and Steve implemented it. There was no lack of foresight here.. The only reason this thread is still being responded to is either by people who are happy we're listening and responding to criticism, or those that are criticising because it wasn't right first time - but design is something which is personal so it's unlikely we'd hit the sweet-spot without customer response... we liked it, hence why we implemented it...
Those icons are poorly aligned, I'm happy to agree there - and they can (and should) be fixed, but this is a task for our Creative department, not for Steve. We'll make sure to pass it along, thanks :)
-
"Edited to add: I think I've actually mentioned this a number of times before, but it's worth stating again... Sometimes, the things that you'd think are easy as an observer, are in fact very involved and slow to implement and sometimes the things that you might think are nightmarishly complicated are actually a few hours worth of work. Development is an unpredictable thing..."
this is sth. I do not get in any way e.g.
instead of experimenting and trashing it it would have been a 100% safe bet to implement a search for the layers panel e.g.
or touch that expand stroke thing
"I haven't touched expand stroke or divide yet, so there should be no difference (in theory at least!)"
or the mesh fill tool where you said "I know exactly what to type" in the first or second ezine
or a bleed preview box, just a box which you had working during the 1.4 cycle already as far as I remember
or an arrow head line ending
....this is really weird to me
this is just out of my world of understanding
This is exactly why I said what I said. Things which seem obvious to an observer, yet if they were easy or obvious they would already be done. The problem with most of the things on your list of things there is... they all need me to do them - and I've been working pretty much all day, every single day doing other things. I have had no part in the light UI, hence why this feature has appeared before the others on that list. I also had nothing to do with the Mirror application, which again was implemented by another developer so did not interfere with whether the items on that list would've been implemented or not...
It's not just about what work there is to do, it's also about which developer is appropriate for each feature...
I do understand what you're saying, and I do appreciate that it's coming from the perspective of a keen user so I'm not taking it in the wrong way, I'm just trying to explain that we're not just making random decisions and doing them in a strange order - there's method to the apparent madness...
-
Hi MBd, sorry you see it that way - but as Steve has tried to suggest, it's more about the fact that we have hundreds of assets and custom controls in our application, and each one has been recreated to work properly on a light background - so it's not as simple as just exposing a colour choice... you must surely know from us by now that if something matters to our users and we can enable it quickly, we'll pop it in there - this has actually been a long process to get to where we are now, for both Steve and for our Creative team...
Edited to add: I think I've actually mentioned this a number of times before, but it's worth stating again... Sometimes, the things that you'd think are easy as an observer, are in fact very involved and slow to implement and sometimes the things that you might think are nightmarishly complicated are actually a few hours worth of work. Development is an unpredictable thing...
- A_B_C, Ian, smallreflection and 2 others
-
5
-
-
It looks a lot better to me. How did you get that?
(Steve's in charge of writing the light UI - so he just changed the code a bit in response to the comments here) :)
- smallreflection, R C-R and anon1
-
3
-
Any news on when the Prototyping feature is going to be enabled for testing ?
It's not going to be turned on for 1.6 after all... we actually sat and used the finished thing and weren't 'wowed' by it so we have come up with a different plan - it'll be better for everyone but it won't happen in the timeframe of 1.6, I'm sorry to say :(
-
I haven't touched expand stroke or divide yet, so there should be no difference (in theory at least!)
-
-
Matt, if I drag the eyedropper in the Color panel (not the Color Picker tool) out of the document to pick a color from somewhere else on the screen, for example the desktop's background image or some window open in the background belonging to another app, what does Affinity "ask" for the value?
If you sample from outside the document view itself then we obviously just ask the screen for the colour under the mouse :)
-
-
Right, it does look like there's something wrong with space-bar panning in some tools (move and pixel tools seem fine)
Thanks everyone! :)
-
Hi Fernando,
Thanks for your feedback - it's always welcomed :) I haven't got time at the moment to give a thorough response (sorry) but I thought I'd reply to your main points so you have more information:
- With snap to pixels turned on, it should always generate a pixel snap - unless you've also got some object, guide or grid snapping turned on that is snapping the data to an already-off-pixel object or centre?
- The issue is that the artboards are created not on a whole pixel - and this is causing the artefact. I should just force artboards onto a pixel boundary and all the problems would go away... :/
- To get a one pixel high line, just choose a 1px line in the stroke panel and draw a horizontal line - but remember that it needs to have a y value that is on a half-pixel so your 1 pixel high line covers only that pixel. This is exactly the same as how Apple tells designers to draw lines too - nothing terribly unorthodox?
- If your colour picker is picking different values for the same object, then something is wrong - we don't ask the screen what the value is, we ask the document and if the document returns two different numbers for the same object in different places then it's seriously broken! Let us know an example and we can fix it... :)
Thanks again,
Matt
-
Well, I see some redrawing lag of the artboard background when zooming quickly … and some blurry and low contrast icons, yes … but panning seems fine …
Hi Alex :) Is this different to 1.5? Whereabouts are the blurry/low contrast icons? Thank you! :)
-
Stabliser tool with textured brushes are creating lots of anomalies as you draw. Disappear once let go but makes hard to see what you're doing.
Is there any chance that you could do a quick screen grab or something so I could see it? Thank you! :)
-
Affinity Designer Customer Beta (1.6 - Beta 1)
in [ARCHIVE] Designer beta on macOS threads
Posted
Hey, at least everyone knows why we've seemed 'distracted' recently now... ;)