JGD
-
Posts
549 -
Joined
Posts posted by JGD
-
-
Hi guys. As I said on my last bug report, I've been putting Separated Mode through its paces, and have been founding a few bugs.
So here's the other one I'm reporting today: whenever I switch, in Separated Mode, from a Persona to another, the entire contents of the toolbar shift upwards, as shown in the following screenshot:
After the first switch, the toolbar buttons will be shifted upwards on all Personas until I toggle Separated Mode off and on again, or quit the offending app and relaunch, but the bug will always manifests itself on the first switch afterwards.
This bug is relatively recent, affects the entire suite (once again, I decided to pick the AP forum as it's the app I'm likeliest to use in such a way that I'll run into it) in both stable and beta releases and is, I believe, Big Sur-specific, as I can reproduce it both on my Retina 5K iMac and 2012 MacBook Pro running macOS 11.0.1 but can't do so in my only Catalina machine, a 2010 MacBook.
It is, as far as I could ascertain, strictly cosmetic, but seeing how it's present in both MAS and beta releases, it kind lends some credence to my theory that not many people at Serif use it at all, and not many professionals do so either on account of its overall suckiness. I'm sorry that I didn't catch this earlier on the Big Sur betas, but guys, it's an entire interface mode that not only is broken by design, but now also looks the part and crashes all apps in the suite for good measure.
-
Hi guys,
So, I've been testing Separated Mode on Affinity apps lately (I still think Serif's implementation is utterly broken, in that the toolbar and toolbox don't dock to the screen edges and document windows don't avoid them, like in all classic Mac apps, but I decided that if I need Separated Mode I can live with just chucking the toolbar to the bottom and be done with it), and I've been running into some bugs (that's the other one I reported today; it's not as serious, as it can't result in data loss, but still glaring and telling).
Here's the one I found today: if I launch Affinity Photo and had Separated Mode set up beforehand and the Welcome panel open*, issuing the “Affinity Photo Beta > Check for Updates” menu command instantly crashes the app.
If, however, I toggle Separated Mode off and on again (or if, alternatively, I toggle it off beforehand, launch AP in regular mode and toggle it back on), and then perform the update check, AP doesn't crash.
The bug is also reproducible in the latest AD and APub betas, but I decided to post it in this sub-forum, as AP is the only Affinity app I ever intend on using in Separated Mode.**
As for versions, it is both reproducible in the latest betas of the suite (AP 1.9.0.206 / AD 1.9.0.10 / APub 1.9.0.857) and even on older ones (AP 1.9.0 / AD 1.9.0.9 / APub 1.9.0); also, I tested the latter on my older MacBook running Catalina, because I hadn't used that computer in a while and knew I still had those in there, and took the time to update them to the latest ones and redo the test on that computer as well to the same results, so it's not just a Big Sur-specific thing.
Interestingly, those older versions did spawn the Update window automatically, so what's crashing the app is not the window itself spawning but very the act of issuing the corresponding menu command.
(*) Edit: Still on the topic of open windows/panels, I did some further testing and realised the Welcome panel may be the culprit here, as closing it before manually issuing the “Check for Updates” menu command also prevents the crash. Please bear in mind, though, that the presence of both the Update window and the Welcome panel on the screen doesn't seem to be the problem here, as 1.9.0 / 1.9.0.9 spawned those on launch and worked without issue. Also, the crash is reproducible even after closing the Welcome panel and manually reopening it through the “Window > Welcome…” menu command.
Regarding the stable, non-MAS versions of Affinity apps, I'm not sure if this bug is reproducible on those, as I bought the entire suite from MAS way back when and can't test your custom – is it Sparkle-based? – update mechanism outside of the betas, but you might want to check that out as well.
If you want, I can send you the related crash logs for all three apps.
________________________________________________________________
(**) Again, this is due to the inherent variability in document sizes and overall unique document philosophy and workflows in photography editing; accordingly, Photoshop is also the only CS/CC app I kept on using in classic mode after Adobe made application frames in document-centric workflows a thing on the Mac – they were aping tabs on Safari 1, as if that ever translated well to Photoshop, where dragging layers from one document to another is only possible with floating windows, but it's a good thing their old default model always was, and still is, very nice and properly kept.
Personally, I loathe using photo editing tools in the inexplicably popular “Monolithic Mode”, and I know I'm not alone in this. You see, this was a trend you shouldn't have focused too much on emulating as not only the default, but the only usable option for the entire suite, and little UX details like the ones mentioned in that extensive feature suggestion I linked to absolutely matter.
-
On 11/23/2020 at 10:35 AM, Sean P said:
Hi JGD,
Thanks for letting us know - this is something I noticed a whole back and have passed on to development, as it does differ quite a bit when compared to the Windows version. The Windows version will list Studio Preset 1-9 in the shortcuts list which are applied to the first 9 (sorted alphabetically) items in the preset list.
Looking into your post I did notice a memory leak when attempting to scroll the list of shortcuts after adding one, so I've also passed that over to development as well.Hi Sean!
I've tested this again and it's still not completely fixed, but progressing in the right direction. The shortcuts are still not recognised after launching the app, but I only have to open the Window > Studio Presets submenu; from the moment my preset and the corresponding shortcut are visible, the shortcut works.
-
Another addendum: the other day, on an Affinity Designer user group on Facebook, yet another user posed THE SAME QUESTION:
https://www.facebook.com/groups/affinity.designer/permalink/2894383684174789In this case, she was a textile/fashion designer, who wanted to lay some patterns spanning across several printed sheets, as you can see from the image she offered as an example and reproduced below. We had, again, to explain all of this to her, and the users' suggestions for workarounds were all over the place.
Unsurprisingly, I was the only one who could somewhat elaborate on the advantages and limitations of each one of them, as well as on the sad reality that none will match – at least for the time being – Ai's bog-standard, no-frills, WYSIWYG UX in this camp.
The. Artboard. Model. Is. Broken. I warned Serif devs that professional designers would run into this issue and, sure enough, time and time again they do. How many of those will just cave in and pay up for CC, I wonder?
Yes, I know there are better, specially-tailored (ha! See what I did there?) tools for industries like that one (quite literally so; a PhD colleague of mine is a textile/fashion designer who happens to be an expert in patterns, and I know for a fact she did use specialised, ultra expensive software for that in the last company she worked at, not a run-of-the-mill vector editor), but should Serif be passing up on the chance of selling workable tools for students and freelancers across all industries? Wouldn't avoiding their departure or, worse even, negative word-of-mouth be worth slapping a checkbox somewhere to fix this mess once and for all?
I'm sorry if this bothers any of you, but anytime another one pops up, I'll be posting it here on this thread (or create a new one if this one's closed), because if there's one thing I know is that hiding your head in the sand does you no good in the long run. Don't forget: for every user that actively complains about this, there is potentially an entire class of similar cases who may just be silently calling it quits.
-
Hi guys,
I was trying to replicate the keyboard shortcut system I used in Adobe CC to reset my Workspaces, as my dual monitor setup hasn't worked nicely with Affinity for some years now (and also started acting up with CC as well, mind you; interestingly, the Studio panel reshuffling after waking from sleep appears to be fixed either in these last versions or in Big Sur, which is nice and may even obviate my personal need for all of this) and I thought I had gotten it working.
Basically, my workflow consisted on adding Studio Presets for all personas, both in Separated Mode and normal mode, then manually reapplying each Preset in View > Studio Presets > [my preset] and finally adding keyboard shortcuts for them (without applying them first the Preferences > Keyboard Shortcuts panel doesn't recognise them straight away) and saving my own Keyboard Shortcut preset in ~/Library/Application Support/Affinity Designer (for good measure I also tried saving it directly in my home folder, but to no avail, so it's not a permissions issue).
The thing is, whenever I restart my applications (any of them, as this bug is reproducible in Publisher and Photo as well), if I move one of my Studio panels and attempt to apply my custom Studio Preset using said shortcut, it won't work. However, if I manually select said Studio Preset from the menu, all subsequent attempts at doing so using its keyboard shortcut will indeed work.
Also, before manually selecting those Presets from the menu, it won't even appear on the Keyboard Shortcut customisation panel, much like it happened right after creating them.
Maybe Affinity apps aren't just scanning for dynamically-generated menu items after creating new Presets and on application launch, as they probably should?
-
As an addendum, to all Serif developers, after doing a quick test in the latest Beta and seeing that this would indeed work:
For the love of all that is good and sacred, if you're not giving us a quick but undiscoverable and potentially confusing – but definitely very much usable – fix such as the one I proposed (I'll refresh your memory: using a modifier key+mouse/trackpad click to ad hoc override that single-layer focus for selection operations, either to switch to a different layer altogether or to select objects across different layers by adding Shift to it), and the only viable way to work in that mode will indeed be having to constantly drag the cursor all the way to the Studio and click the “Edit All Layers” toggle button in any project complex enough, at least PLEASE give us a – preferably customisable – keyboard shortcut for it. PLEASE. And if you're weary of setting a precedent, well, just leave it blank but give us the option to pick one.
Do not underestimate how much extraneous cursor drag + click operations add up in wasted time and make using a piece of software feel more like a frustrating chore and less like an almost fun activity (even lowly web developers across the world know this, and you seem to underestimate it… In my interactions with you, it sometimes feels as if you eventually and begrudgingly address some general grievances without actually understanding what they were really all about in the first place, which, in the infamous and maybe apocryphal words of Comrade Dyatlov, is “not great, not terrible”). It's the least that you could do for v.1.x, without bothering anyone or introducing too much complexity.
As a matter of fact, this is such an important feature, because it changes the entire MODE of operation of AD, that it should also be featured somewhere in the Layer menu (and not on a sub-menu, but at the top level, for that matter; maybe right above or under the Show/Hide and Lock/Unlock groups). I get that adding an entire section to your Preferences > Keyboard Shortcuts system just to enable customizable shortcuts for Studio panel buttons would be a PITA at this point, and it's something I would only expect for a v.2 or even v.3 release of the suite, but that alternative would just be sensible UX, enhance feature discoverability and solve a lot of issues in one fell swoop.
And yes, I know that all items in the Layer menu only affect the currently selected object(s) but, to be fair, you also have a completely redundant (and at times useless) “Find in Layers Panel” item in there; the behaviour triggered by it is also automatically triggered the moment you select an individual object on the document, and if you have more than one object selected it becomes inactive… Chuck it away, use the spot it currently occupies for a perfectly standard “Edit All Layers” checkmark toggle and the menu doesn't even have to grow in size. Boom, problem solved!
Still feel uncomfortable with that option? Well, put it under Select, as it affects – duh – object selection, or under View, a menu also featuring items such “Lock Guides”, which definitely affects direct interactions with elements and not just their visibility; and in a roundabout way, since the “Edit All Layers” model is also all about visibility, maybe you could and should put it in View > View Mode, right under “Clip to Canvas”, as that's the feature it is most closely related to in real-world usage.
Look, please figure it out, that's just what I'm saying. As always, you are this close to a perfectly workable – if not 100% elegant – solution, and yet soooo far, so I hope you don't take this as anything but a little, constructive nudge. About the only thing I can't be faulted for is not dishing out enough sensible solutions for the problems I come across.
-
On 10/30/2020 at 8:59 AM, fde101 said:
Bad analogy: if you move an icon so that it is partly inside an partly outside a window in the operating system, does it not get clipped?
I suspect the reason the objects get clipped is to avoid confusion if there are two artboards particularly close together and the object would appear to overlap them. In this case someone might be confused when the object does not get printed/exported as part of the "other" artboard, and the software might have difficulty in determining which artboard such an object was meant to belong to, so by limiting the display of the object to only one of them, it is making it clear which artboard the object is part of.
I would argue that it should instead be clipped at the boundary of the other artboard in this case, so that anything outside of the artboard it belongs to would be visible up to the point of potential confusion, but I am again just guessing that this is why it was implemented this way.
The reason Serif took this route was, I believe, because they always wanted to cater to the iPadOS crowd, where you'll have a single artboard onscreen (I'm not sure if that's how Affinity apps behave on that platform, as my iPad is too old for me to test them, but even if that isn't the case by design and you can zoom out and rearrange them just like in desktop Affinity apps and Ai, 90% of the time you will work zoomed in because even the bigger iPads Pro are tiny when compared with, say, a 27'' iMac like the one I work with).
As for Ai, guess what, it's the other way around, and you don't see people complaining about it. Sure, you will have to use clipping masks to prevent that from happening, but doing the opposite, i.e. having objects spanning multiple artboards, InDesign/APub-style, is MUCH easier by design.
I've said it before, and I will say it again: this all comes down to a philosophical decision from Serif's developer team regarding workflows. Their “container-like” model makes no sense from a WYSIWYG approach to classical, hand-made artistic workflows… In the real world, if you want to crop your artwork, you have to do it BY HAND, by folding, cutting, erasing, masking, whatever. And anyone with a background in fine arts, life drawing, illustration, yadda yadda, made with real, physical media and supplies, will look at artboards as SHEETS OF PAPER on a desk, atop which stuff can be laid, and not as abstract containers in a database, which have a life of their own and crop stuff automatically.
I warned the Serif dev team about many users potentially becoming unhappy with this model in the long run, and it took them years to even add the option of toggling automatic clipping of objects into artboard boundaries, and only partially at that, with some less than stellar consequences. The only way you can prevent artboards from sucking objects in is by creating one or multiple layers, and disable “Edit All Layers”.
It almost works like Ai, except… you can't quickly switch from one layer to another and select an object from a different layer, or even make a selection of different objects across different layers, without having to go to that ghastly, do-it-all, jack-of-all-trades-master-of-none Layers+Artboards panel. Also, it's not like you could create a super-layer to work around that, as clicking that automatically selects all objects inside all sub-layers.
If I didn't do so already for that last, super-layer idea (maybe I did, but my memory fails me, so please bear with me), I could and should do a video demonstrating just that and its frustrating limitations but, as I've also said several times before, I'm now doing a PhD to become a Design teacher.
I'm not fooling around, and was not joking either when I said my teachers, supervisors, fellow workshop tutors, classmates, students, etc., no longer pay much attention to Affinity Designer (or not as much as they did after the initial hype). I sincerely hope Serif polishes this thing up for v. 2 of the suite, because if Adobe gets their act together (or *gasp* backtracks on their subscription-only model!), they are either toast, or will forever be relegated to third place at best, no matter how much Apple propped Affinity up to keep their long-term frenemy on their toes (something oh-so-convenient considering their upcoming ISA transition, which tends to shake up the market and can be very dangerous to proprietary platforms like the Mac). Ehhh.
Oh, but I'm putting my money where my mouth is… As much as I love and respect Affinity apps – which, mind you, I will always buy, as I feel I have an obligation towards my students to stay informed and know what's out there in the market, and the price of admission is low enough for me not to balk at it – and Serif's lofty goals – again, I know I'm extremely harsh, but I am indeed rooting for them; it's just that I'm not a “yes-man” for anyone, and when I see BS and bad design/UX/etc. I will speak up –, I'm very likely taking some of my upcoming research scholarship allowance and putting it towards a Creative Cloud student subscription, as I will indeed need a graphic design suite for my project at some point (even if it's just to make some diagrams, and edit my final thesis manuscript in InCopy and typeset it in InDesign) and don't have time to deal with these shenanigans or retrain my muscle memory for the next 3-5 years of my life. #sorrynotsorry
-
I had a chance to redo my Studio arrangement in this replacement build, on my main Catalina volume, and it looks like they stuck and everything's more stable now even after multiple restarts and a lot of floating panel dragging and docking. Thank you for the quick turnaround!
-
Guys, just a quick question: what's up with zoom scaling? A new A4 document is displayed differently – and inaccurately – at 100% zoom in this beta…
In the MAS version of AD, 100% matches the real physical size of an A4 sheet of paper:
Whereas in this beta, it's visibly smaller:
Any thoughts? I've fidgeted with all sorts of settings, and I can't seem to find what's wrong here.
-
16 hours ago, AdamW said:
Crashing on Startup
It looks like the instability on startup with this build occurs if you have certain panels floating by default in your studio layout. To work around, hold CTRL while running up and check 'Reset Studio'. We will issue an update to fix this issue as soon as we can.
Thank you for the clarification, Adam.
I may give this build a spin on my Big Sur external SSD just to see how it behaves but, for the time being, I'm likely skipping it on my main machine's default, internal Catalina volume, as not using floating panels isn't exactly ideal in a dual-monitor setup like my main one.
If I have the time to test it in depth under Catalina, I guess I'll stick to doing so on the MacBook Pro, where almost all of my Studio panels are docked (and in Publisher's case, that may vary well apply to all of them).
-
This beta of Publisher is crashing on launch under Catalina 10.15.7…
Edit #1: I'm trying to isolate the issue, and I believe it must have something to do with my Studio panel arrangement. I was redoing it from scratch after resetting all my preferences, and when reopening it so that I wouldn't accidentally lose my customization, I got it stuck in a new crash loop.
Edit #2: Lending further credence to that theory, a simple Studio reset did the trick.
Edit #3: Dragging the Layers panel tab off from its group instantly crashed Publisher (and it's reproducible, every single time). Something must've gone seriously wrong with the Studio code in this Beta, IMHO… I hadn't seen this level of instability in a long time.
-
On 9/23/2020 at 12:46 PM, fde101 said:
This is really a different category of selection than the other options. The current set of options work at the object level but this would almost require discontiguous text selection to be implemented first as these are properties of a subset of a text object, rather than an entire object.
I would suggest that if this functionality is needed Find and Replace should be used instead, though that is only available in Publisher - this could easily take the form of a "Find Same Font/Style/..." option which would configure and execute the search to do exactly that as well as displaying the Find & Replace panel if it is hidden, in one step.
I really like your thinking here. I'm not sure how the Find & Replace functionality works, because I haven't tested it yet, but if it works like it does on most Mac apps (with an immediate, more subdued highlight for all occurrences, and a more prominent one for the one in focus), there could very well be some nice little buttons there for selecting all strings, select all containing objects, etc.…
And this would be such a powerful tool that it absolutely must be included in Designer as well. I know most documents done in AD aren't as text-rich as those done in APub, but some scenarios, like the one I mentioned, can absolutely benefit from it.
-
On 9/15/2020 at 10:46 AM, MattP said:
You can *nearly* do this already - I split out text objects into the main types: Art Text, Frame Text, Path Text, so you currently have to choose which type of text you'd like to select, but it does as you'd expect - traverses the whole document and selects those objects wherever they are, whether they're locked or not
Do you need the 'all' text option still?
Ohhhh really?
Look, you all know I'm terribly biased, but I just have to ask for “Select same font/style/size/character style/paragraph style” (I'm not sure how you'd deal with strings or frames containing more than one of those, though, but I'm sure there could be a way around that, or at least have those options work with typographically homogeneous objects even if it had to fail or otherwise appear greyed out for the rest)… Break it down inside a “Typography” submenu if you must.
This would be great for a lot of scenarios, really (even stuff like the technical drawing for a shop window decoration I'm working on right now, not just complex typography-heavy projects).
-
Thanks! I'll give it a spin on Catalina and on the latest Big Sur customer beta when I get around to boot it and update it.
-
On 8/17/2020 at 9:00 PM, DEWLine said:
Some of you might be interested in this video from Comicraft, one of the comic-book font design and lettering houses, via YouTube and apparently, they're taking steps into variable font tech. Narrated by John Gaushell...
https://www.youtube.com/watch?v=yYgZ_jX_36sHa! I didn't want to be that guy again, but… now that good, comic-bound variable fonts exist, maybe Serif will take notice. 🙃
Naaah, in all seriousnesss, not only do comic artists likely use other dedicated software packages, instead of the more generic Photoshop or Affinity Photo (though you could argue they might leave their balloons blank for a designer to finish or even localize them, or that they might want to do so themselves on a vector-based package, like Publisher), but this font is legitimately cool in its own right. And any cool and useful variable font deserves my praise, regardless of its application or the implications on the design market, so… thanks for sharing!
On 8/17/2020 at 9:07 PM, Alfred said:Cascadia Code is another one.
Oooooo, this is cool. It's like Fixedsys, only from the 21st century and on a lot of steroids. 😂 And it's published under an SIL OFL 1.1 license?! I like all of what Microsoft is doing here. Thank you for sharing this one, too!
-
On 7/23/2020 at 2:09 PM, lxx said:
Just want to +1 this.
I don't even care about the variable width stuff, but right now I'm trying to use MS' Bahnschrift font and all of the different font weights display Normal instead of the actual font weights. I'm guessing the weights are now programmed instead of each weight being staticly available or something?
I was reading the Microsoft docs page on that font and that seems to be the case.
Even from a font managing standpoint, I am absolutely for abolishing separate, dedicated weight files. It could be interesting to have a “snap to weight” flag/checkbox, too. And the same goes to “snap to width” (on that subject why wouldn't you care for variable width? It would also simplify things on that department). Then again, that should become an OpenType and UX standard of sorts.
IMHO, the only styles that could still be separated into their own files are the italics. Then again, it's not like there couldn't be a convention of sorts, a more restricted, glorified stylistic set of sorts, which could still allow for parametric changes to angle. That way, you could indeed have an instant upright italic, an oblique version, etc., all in the same file.
Yeah, I got a bit lost there. I think as a type designer and font editor teacher, so this is just me creatively rambling at this point. In any case, Serif could and should be at the forefront of typographic innovation, instead of just focusing on illustration and classical DTP. I know it will take years for them to match Adobe's Single- and Multiline composers, RTL support, yadda yadda, but variable fonts are really just easy pickings, even if they're just based on a bunch of custom parameter sliders at this point. It's the standardization further down the road that really matters, and the only way for them to partake on that is to enter that market ASAP.
Also, thank you for pointing me to that Microsoft font. I had absolutely no idea they were toying with variable fonts already. That makes me extremely hopeful for an eventual appearance of variable font support in Microsoft Office, and not just at the OS level. That would solve so many headaches, really…
-
On 7/9/2020 at 6:59 AM, Andy Somerfield said:
Morning all,
Further to the comments made by Dan, I'm pleased to report that the transition to Apple Silicon has been completed. We will, of course, use the time between now and any Apple hardware release to test what we have internally - but I see no reason why we will not be available on day one with all three apps.
To address questions regarding ongoing support for Intel based Macs: We will support Intel based Macs as long as they are supported by Apple (ie. until the last Intel based Mac is considered "obsolete" by Apple). This will be years after the last Intel Mac has shipped - and will only mean that we stop providing updates - not that the app will stop working.
Hope this helps,
Andy.
As I suspected, that was quick! It's good to know, and further confirms my theory on why Apple would rather use Affinity Photo as a demo for Rosetta 2 (which, mind you, feels a bit like cheating, because Affinity apps are lean enough to make them somewhat usable even under binary translation), rather than as a poster child for Universal 2.
Adobe users are still stung by Quark having dragged their feet during the transition from Classic to then Mac OS X, which led them to switch to InDesign in the first place, and by Adobe, in turn, having dragged their feet during the transitions from Carbon to Cocoa, from PowerPC to Intel and from macOS to i[Pad]OS. Seeing how those users are still in the majority, it would be suicidal of Apple not to prioritize those apps and pretty much ensure they would be universal on day one…
As for Serif apps, those were among the first desktop-first apps to appear on the iPad. It was patently obvious they would be the first to run natively on Apple Silicon macOS, even without advance warning from Apple. Adobe, on the other hand, had to be given early access to the DTK and likely extra help from Apple engineers. It's both sad and impressive to see the difference in treatment here…
-
9 minutes ago, Alfred said:
I don’t think we should assume that we’re going to see the Affinity 2.x roadmap!
Yeah, you're probably right… Now that we're past the “obvious & vital features” stage, it makes sense they'd hold their cards closer to the chest. Still, one can dream, eh?
I'm optimistic about both Affinity 2.x and variable fonts coming sooner rather than later though, whether the features contained therein are a complete surprise or not. And the whole Apple Silicon transition only set them back by a couple of weeks, which is also great news.
- Alfred and konstantnnn
-
2
-
Well, seeing how there's been some reactions meanwhile, I shall bump this thread again and add in my €0,02, mmkay?
Fast forward to 2020 and I'm now entering a PhD in Design come October (the theme will, again, be centred around modular fonts, but this time on their usage in type design education), my buddies and I got, at the 10th ET (the conference I mentioned earlier), a sneak peek at Glyphs 3 given by none other than Rainer himself (with whom I've kept contact through the years), FontLab 7 is already out, CorelDraw is once again available for the Mac, Affinity apps still don't support variable fonts, and here we are.
Guys, any ETA or thoughts on this feature? Maybe we'll see it on the Affinity 2.x roadmap?
-
On 7/2/2020 at 2:36 AM, v_kyr said:
Hard to tell at the moment, since they didn't told in WWDC sessions much about possible virtualization support, or the future of tools like their Boot Camp etc. at all. - Instead they talked more about how to port Intel CPU based mac apps to the upcoming ARM64 architecture and what steps have to be taken into account to successful manage these tasks. So most related things here will have to be discovered, have to be found out and shown over time. At the moment it is still difficult to make specific and concrete forecasts here.
However, for apps like the Affinity line, it will probably take some time until those will be available for the ARM architecture then, since every needed code dependency (all by Affinity used third party libs etc.) will also have to be first natively compiled and ported over here. Thus all that the AF iPad versions still don't offer in contrast to macOS versions yet, will need to be adapted/ported over then.
Thank you for the links!
Well, let's hope they get around to solving those dependencies and recompiling their code soon. Everything points to that, and I'd say their pervasive use of platform-agnostic (if not completely ISA-agnostic) C, as well as Metal (which, I'm guessing, in the context of 2D apps shouldn't be so complex as to require much rewriting), should help on that… From all I've read here on the forums before, Serif always seemed to keep a good balance between keeping things abstracted enough from the hardware, while at the same time making use of native APIs and frameworks.
I don't know how they manage it, and I still feel their apps could and should look and feel more native, but they're still leagues better than Adobe apps on that regard (well, if anything, they don't have to deal with decades-old spaghetti code
). I'm willing to bet that they'll transition their current three Mac apps way quicker than Adobe will (the absence of universal Illustrator and InDesign demos was notably conspicuous, for one).
And when I say quicker, I say “way before the Big Sur GM even drops”, which might be earlier than the first Apple silicon Mac release. Of course, we won't know anything about that, as it'll likely be heavily protected by Apple's NDA, but we'd be naïve to think that Serif doesn't have an Apple DTK being shipped on their way or already set up on their offices somewhere. That's the only way they can promise to have it up and running on day one.
-
On 7/6/2020 at 12:46 PM, McD said:
Wow. Someone really can’t differentiate between a component & a product.
I particularly liked the part where iPhone notifications were copied from Android as opposed to macOS or Growl. Most ‘Android innovations’ were straight lifts from previous desktop OS’
What difference does it make whether it's a component or a product we're talking about? That's not the crux of the matter…
Many of the examples I've mentioned were, in fact, bolted-on, third-party components, even if they were sold or otherwise distributed as products, and which became, one way – through acquisition – or another – through wholesale rip-off –, first-party ones. And the same happened with whole applications, and even entire GUI philosophies. I don't get why you're so hung up on the scale of the copying itself, as what really mattered to me in that post was the way it was done and the size of the parties involved themselves.
The TL;DR of it is: it only irks me when the 800 lb. gorilla rips off the tiny indy dev; I couldn't care less when the 800 lb. gorilla rips off another 800 lb. gorilla. Especially if it's something obvious, essential and not especially creative like notifications or widgets (it's not like those are “aha!” innovations like, say, multi-touch as an entire interaction model), which ends up benefiting large numbers of users.
-
On 6/28/2020 at 6:56 PM, v_kyr said:
Yes it was initially developed on other CPUs than the one used by black hardware (Motorolla CPU). Later the NS/OS was adapted/ported over to other CPU platforms, among those the Intel x86 CPUs (used by IBM & Clone PCs aka Dos/Win machines those days) and Sun and HP RISC Workstations. Development and porting over of apps etc. was pretty easy and almost just a project recompile with enabled settings for code generation for all four architectures, which resulted into fat binary (universal binaries) executables.
I think the main point for Apple is here instead, to be independent from other chip manufactors (Intel) and so to have the whole control of chip manufactioring, it's capabilities and availability in their own hands. And as one can see from the chips they used in former times (Newton devices) and nowadays iPhones/iPads or their T2 and other custom chips, they are long time able to do so. They have long time experiences with the ARM CPU architecture and also the tools to make use out of those equally good.
Sure, that was never in contention. I'm just saying that “hackers gonna hack” and, if the demand is there and the returns justify it, they will cave in to the market pressure. When they did the switch to Intel, Windows compatibility was never their main goal (if at all, which I also think it wasn't, as they ditched the vintage BIOS spec but never adhered to UEFI when it did become the norm on the Wintel world) and, yet, since that compatibility was there ripe for the taking and the investment on drivers for such a lean line-up was negligible, they went ahead and created Boot Camp. And the rest is, as they say, history.
Them coming up with a Boot Camp 2, on an ARM-dominated or at least ARM-infested PC world (to the point that universal Windows x86-64/ARM-64 binaries also become the norm, that is), wouldn't be totally farfetched. Their SoCs would still likely eat Qualcomm's for lunch and make Macs, more than ever, the best PCs around for running any OS, so it would be a win-win situation, if you ask me.
Then again, there's the whole virtualization angle. Perhaps they have an ace up their sleeve with that one? Maybe some great new way of doing it that actually makes the overhead of macOS also negligible? The very fact that they emphasized virtualization so much on the WWDC keynote, and not on some random session, is a dead giveaway that they must have some grander plans for it in the future. With Apple, more often than not, you have to do a lot of “Kremlinology” and tea-leaf reading; it's usually what's left unsaid that is truly relevant. Surely they don't expect Linux to be the only alternative OS to ever run on Parallels/VMware/Virtual Box (by the way, there was no mention of macOS itself running on a VM, but it also damn well should, especially considering how Rosetta 2 will eventually be axed, just like Rosetta [1, the PowerPC variant] and Classic/Blue Box were before it)…
-
5 hours ago, v_kyr said:
I come more from NeXTstep/OpenStep times, where people like Bud Tribble, Jean-Marie Hullot and Co. tended to do software based things more their individual way. - Hardware transition wasn't a theme OS wise in the past, since the whole software was already build and compiled the way to support different CPU architectures (those days Motorolla and Intel CPUs and also Sun and HP RISC CPUs).
Let’s hope that macOS doesn’t deteriorate too much to the iPad operating system at some point, i.e. to a simple decrippled and sandboxed thing with Touch & Click and not many other interoperating third-party development opportunities at all.
Massive respect! I am aware NeXTSTEP was built with the entire ISA-agnostic philosophy from te get-go, to the point that there was actually an x86 version, am I right?
As for macOS devolving into a souped-up iPadOS, I'm siding with @R C-R on this one. They actually seem to be making the whole “security level” thing more transparent and easy to toggle on a per-volume basis, which is just great. And they were pretty vocal about allowing one to install and run outdated, unsigned versions of macOS… To do a 180° on that would be mindbogglingly stupid, represent a massive breach of trust towards their loyal power users and be completely out of character especially after releasing the beast that is the new Mac Pro. I'm not buying that, and the ARM-based replacements to the Xeon-powered machines are actually the ones I'm more curious about; think Afterburner card, but on massive amounts of steroids.
As a matter of fact, I'm going one step further in my speculation: I can even envision people hacking Windows ARM-64 (whenever that comes to pass and evolves out of OEM-only status) onto A-series Macs using custom boot loaders and Apple eventually caving in and reviving Boot Camp, in pretty much the same way they created it in the first place only after Windows x86 installations were hacked on top of a kludgy BIOS emulation thing on the very first Intel Macs. And even if that doesn't happen, we'll see at least Windows ARM hacked onto virtualisation software (legally or otherwise), mark my words.
-
5 minutes ago, BofG said:
What is this "testing" of which you speak?
Firing it up on a DTK Mac Mini (my guess is it'll run just fine, as most of the code was already ported to iPadOS), about which they won't be able to talk because they'll be under a heavy NDA.
Make toolbar and toolbox dockable in Separated Mode; force windows out from under docked UI elements so that UI chrome is accessible; make Zoom [+] (Opt.+Green Button)/Window>Zoom command adhere to HIG
in Feedback for Affinity Photo V1 on Desktop
Posted
@Kal, I like that you're paying attention to the topic, and all, but that is definitely not what this request was about.
Tiling windows was never something we were clamouring for here, and recent macOS versions are great for that by default even in non-fullscreen mode, in that they automatically snap edges in a very elegant way.
Sure, it works for that use case, even if it looks a bit kludgy (and I believe it is; the combination of Separated Mode and macOS's default fullscreen mode, whether with tiled windows or not, is still a bit of a disaster – and there's a reason why Adobe doesn't support it –, as the toolbar will obscure important UI elements like the rulers), but it doesn't address the impracticality of not having dockable toolbars, toolboxes and palettes, and windows smart enough to avoid them if they can.
The large majority of Mac apps got these very basic concepts just right since the late '80s, and many modern ones still do, so why the heck should we cut Serif devs any slack here? We're talking about decades upon decades of accrued, tried and tested UX knowledge here.
In any case, I will just say this: if you need fo perform 13 steps – if you just added two more, it would've been a nice nod to Radiohead, har – in Affinity apps to achieve something that can be done in both Photoshop 2021 and FontLab 7 – two currently shipping apps with a decent classic Mac palette model – in just one step (i.e. respectively turning off Application Frame, or tearing off the toolbars and palettes you wish to have in floating mode and snapping/docking them to the screen edges instead), clearly their entire UX underpinnings are broken/wrong by design and need more work.
I said it before and I'll say it again: Separated Mode was, and still is, an afterthought. The fact that it has glaring cosmetic bugs in Big Sur, both on the latest stable release and the latest betas makes me even more certain that a) nobody at Serif tested something as basic as Persona switching in Separated Mode because nobody uses it at all, and it wasn't detected by beta testers either because anyone who cares for it doesn't use it much, as it's so sucky.
I finally got around to it (and ended up running into several other issues, because of course I did), as I did some outside-of-the-box thinking and realised that if I just chucked the toolbar to the bottom and lined up the toolbox to the bottom-left corner, like in the enclosed screenshot, I could at least work with it without being constantly enraged at these shortcomings.
Sure, having a different Studio layout in Affinity Photo isn't great for muscle memory, and having toolbars next to the menu bar also makes more sense from a Fitt's Law perspective (having the Dock constantly pop up by accident is a bit intrusive, and I may end up pruning it and putting it on the left screen edge if I end up working with AP a lot, but then I won't be able to summon it on my secondary screen), but being able to compare photos, quickly switch between several ones just by picking them on a visible stack, etc., is absolutely invaluable.
As you can see, I found a much better workaround, so this is no longer a hill I'm willing to die on… But I still feel that the very existence of a thread that is now more than a year old, regarding a glaring shortcoming that has been plaguing an important feature since its very inception and which hasn't been addressed at all (I mean, have any devs chimed in here yet?), is a bit concerning.