Studio panels un-snapped and in the wrong monitor after waking from sleep

[JGD]

Hi guys,

 

I know it's at least the second time I'm complaining about this, but this time Affinity's behaviour is really irking me big time. Just to freshen up your memory (and because the earlier behaviour, while still undesirable, wasn't all that bad compared to the current one), last time I mentioned this nagging issue, this was what happened:

 

When waking a dual-display Mac from sleep which had parts or the whole of the Studio on the secondary monitor, said panels were moved to the primary monitor, as a snapped-on block , in a similar location as they would appear on the secondary one (see screenshots “Designer” and “Photo”, below), which is conveniently located to the right of my main screen and only shifts the panels a bit from their default location. The only way to avoid this issue would be to quit Affinity Designer/Photo before putting the Mac to sleep, but at least if you forgot about that you could drag all of your panels to the secondary monitor.

 

[By the way, while I'm at it, another bug/undesirable behaviour that I detected back then and which still hasn't been fixed in 1.5.x or in these 1.6.x betas is that if you drag the panel group from the topmost panel and push it even one pixel above the lower edge of the menu bar – regardless of whether you are doing it on the main monitor or on the secondary one –, the whole panel group will start breaking apart and grouping panel tabs in undesirable combinations all by itself, which is a serious abuse of Fitt's Law (it should be applied in useful functionality like hot corners, menus and other UX interactions like maximising or snapping, not semi-random, uncontrollable interactions that feel more like bugs rather than features; in this case, dragging the panel group against or above the menu bar should obviously result in, well, absolutely nothing besides it stopping its movement along the y axis).]

 

 

 

 

Enter screwed-up scenario #2, under the 1.6.x betas:

 

Now, when you wake up the Mac from sleep, the panels will reappear on the right-hand side of the primary monitor, in a semi-snapped state (they are not actually snapped but spaced with 5 px gutters between them), and some of them even lose their width info (I like to expand the Glyphs panel, for instance, so it opens up as a large window covering almost the entire remaining space in the secondary monitor, but it reverts to its default, minimum width) which screws up my setup even further (see screenshots “Designer Beta” and “Photo Beta”, below). Whereas before, I could just drag the whole thing back to its rightful place, now I have to either piece them all back together from scratch, or force quite the apps so they purge their current, unsaved – and patently undesirable – preferences and revert to their earlier state (which, while already an option before, is something I'd rather avoid doing, especially if I have open documents).

 

 

 

 

To add insult to injury, InDesign, Illustrator and Photoshop CC do not even put the panels in the wrong monitor (they just shift them around a bit, but enough to render them unusable), and I managed to fix the issue by assigning an easy to remember keyboard shortcut (Cmd+Opt+hyphen) to the “Reset Workspace” command, which works a charm.

 

I know this is actually a macOS issue (because besides Adobe apps, iTunes and other apps will sometimes also forget where they are supposed to draw their windows and shift them around the secondary monitor or redraw them on the main one) but please, oh please, can't you try to make Affinity play nice[r] with multiple monitor setups, on the Mac at least? There are a lot, and I mean *a lot* of professional Mac users who run such setups… And if you can't make it put the panels in the right monitor automatically (because macOS and its APIs, or its lack thereof), can't you at least make the apps revert to their older 1.5.x behaviour or implement some sort of Workspace functionality, to give us more advanced customisation management options and compete head-to-head with Adobe?

 

[P.S.: I'll be sending Apple feedback on macOS and link to this topic thread; it's a damn shame that the OS which offers what is currently still the best multiple monitor support in the market can't get something as simple as this absolutely right and provide developers with the tools to do it as well].

[steve_m]

Thanks for flagging this up JGD. I'll take a look into it.

[steve_m]

JGD - could you please let me know which Mac and OS version you're using? Thanks.

[Andrew Tang]

JGD - Can you also provide your monitor setup (make and model), and the connection type you use?

[VIPStephan]

On 10/9/2017 at 5:53 PM, JGD said:

if you drag the panel group from the topmost panel and push it even one pixel above the lower edge of the menu bar – regardless of whether you are doing it on the main monitor or on the secondary one –, the whole panel group will start breaking apart and grouping panel tabs in undesirable combinations all by itself

I’ve reported this before already and can confirm it. Also, I’ve reported waaay back that when plugging my external monitor into my laptop the studio panels will move to that monitor (since it’s now declared as the main monitor – or, however Apple treats this internally, but for me it’s supposed to be, anyway) but not to the edges of the display but at the same size as the previous (smaller) display, and somewhere in the lower left area of the new one.

Since I’m frequently plugging and unplugging the monitor I have to rearrange the panels everytime, it’s annoying.

I have a 13" MacBook and an HP w2408h monitor.

[tomn]

+1 I experience the same problems in 1.5.5. I had to reset the studio from time to time so the pesky panels appear again, and then I have to rearrange them again  In my case some of the panels don't want to show up again

[JGD]

Hi Guys (@Andrew Tang, @steve_m)!

I'm running macOS Sierra 10.12.6, on a 27'' Late '09 iMac, with an upgraded 2.93 GHz Core i9 and the original 512 MB ATI Radeon HD 4850. My external screen is a 24'' 1080p Philips LCD TFT, model no./ID 237E4LHSB/00, connected through a bog-standard HDMI cable and a Delock Mini DisplayPort to HDMI adapter.

 

I mean, maybe it's something on my setup, but… I've been running external screens on Macs and they tend to flash a bit and be undecided about window positioning before they settle down. On the other hand, I don't remember the 21'' LG Flatron CRT I used to have connected to my 21.3'' iMac, back in 2010 when I was working on the Mac Room, ever doing that to Adobe CS5's palettes and other windows, so… Yes, maybe something is wrong with my setup, but I can't honestly guess what. macOS and other apps should really play nicer with standard components, and fully respect the Arrangement tab settings on the Display panel in System Preferences (otherwise, what good is that for?).

 

As for the behaviour @VIPStephan mentioned, I didn't state it as eloquently (or at all), but I can confirm I also experience that, with Adobe apps, iTunes, and others, at least (not Affinity apps, though; those will always appear on the main monitor), their respective windows and panels will move to the proper monitor but to the wrong place (and I know I said they shift a bit, but “a bit” is a bit of an understatement, as sometimes entire panels will get cropped)…

[JGD]

Oh, I should also add that I also have a spare screen just like this one lying around (I ordered two, one for my and one for my father, but he didn't like having it connected to his MacBook Pro and never made much use of it, so it's just sitting on a desk at my parents' place as a dust-gathering back up in case this one fails, or in case I feel the need to use my own MacBook Pro over there instead of my main iMac setup), and two more Mini DisplayPort to HDMI + HDMI cable pairs to test with, in case you really think there may be something wrong with any of the individual components themselves.

 

And I can use the MacBook Pro with the other one right away (it's an Early 2011 13'' model, also running macOS Sierra 10.12.6), as I said, and also with my cheap-ass 1080p Crown TV (its colour reproduction and contrast ratio are terrible and its PPI count low, and, to top it off, it has a ginormous bezel; that's why I would never consider using it alongside the iMac for any serious work, and in fact got it as a hand-me-down from my brother to plug into my cable DVR and other HDMI sources to watch video, and free up the Philips for precisely this secondary monitor use), to check whether I can reproduce the bug on other setups. My gut tells me there isn't (maybe with the monitor model, yes, but it seems to work just fine otherwise), but if you think it's worth giving it a shot, do let me know.

[steve_m]

Thanks very much for the detailed info JGD. I don't think that there's anything wrong with your hardware, but after a chat with Andy T, we suspect that the issue is HDMI related. We'll keep looking into it.

[VIPStephan]

Oh, I might add that I’m also connecting my monitor via HDMI with an HDMI to DisplayPort adapter.

[JGD]

Hi again, Steve. Thank you for looking into the issue… This seems to be a tricky one. :\ I suspect this should really be escalated to Apple (or at least it could be useful to involve them in the conversation in some way or let them know of our findings). You see, I can't seem to reproduce the issue on my MacBook connected to the crappy Crown TV, but other people are complaining of the same thing, on different brands of monitors, and also with different apps.

 

If I had to venture a guess, Occam's Razor tells me that the trigger is most likely a timing issue (it seems that the secondary monitor is taking too long to wake up, and macOS just thinks “eff it, I'll just slap these around elsewhere”); what doesn't look as clear cut is the reason why afterwards some windows revert to their proper positioning, some don't, and some do end up on the right monitor but shuffled around. You'd think that macOS would do all of this [near-]instantly, and not in separate steps, one app at a time, or that it would have some mechanism to be able to put them in the right place even if you forcibly disconnected and reconnected the screen or turned it off and then on, but… alas, if it has one, it's messed up in some serious ways. Oh, actually… it *does* have one. I just turned my monitor off, and the palettes promptly jumped to the left-hand side of my main screen as a snapped-on bloc (as they did on the MAS release), then shortly after jumped to the right-hand side immediately as separated entities with said gutters (as they do on the latest Designer and Photo betas). But when I turned it on again, everything reverted back to normal. What. the. hell.

 

I will do some further testing on my part, and try other computer-monitor combinations as well as cleanly turning the monitors off and on (during normal usage, after the wake-from-sleep bug manifests itself, etc.), and let you know how it went.

[JGD]

Great! Now I can't even reproduce it on my own main setup, even after waiting for the computer to fully go into sleep. I absolutely, positively, hate this kind of bug. If it was predictable and easily reproducible, I could probably learn how to live with it, but it consistently catches me off-guard and I haven't been able to precisely pin-point what's causing it so as to at least avoid it.

[JGD]

AHA! Eureka! I seem to have found a common pattern! Whenever Affinity Designer or Photo is the current, topmost application, whether it has open windows or not, its panels will also move from one screen to the other when I turn off the secondary monitor or the whole setup goes into sleep mode, yes (and the Betas will exhibit that extra-garbled behaviour), but they *will* always revert to their proper place.

 

It doesn't help me much personally, because I'd have to remember to always switch to either one before putting my Mac to sleep (and believe me when I say that's a usability issue; I always have a lot of open apps and I would consistently forget about that, as I already did when it came to quit them, which I thought was the only remedy), and if I have both open [and it's only bound to get worse once Publisher comes out], with open documents… at least one of them [or, when Publisher *does* come out, two of them] will end up with a messed up studio, and force me to save everything (even if I don't want to because of… reasons) and force quit it [them] to make it right again. But maybe that helps you or Apple to isolate the issue.

 

By the way, I've been fooling around with my iTunes mini player window (one of the affected by this bug), and I think I finally figured Apple's API for multiple monitors and window positioning upon screen disconnection. It works as follows: at first, upon turning off a secondary monitor, windows will jump from their current coordinates on monitor 2 to the exact same coordinates on monitor 1, taking the top-left corner as the origin; but then, macOS, trying to be all user-friendly and whatnot, moves the window to the closest possible coordinate so as to have its right – or left, depending on screen arrangement – edge adjacent to the corresponding edge – and former inter-monitor boundary – on the main screen, and adjusts the y coordinate according to said screen arrangement, to make it seem as if the window was “pushed” from the secondary screen into the main one, instead of superimposed (like in a “flatten layers” command, using a photo editing analogy). The thing is, sometimes something ends up completely borked in the process (especially if the app, in Affinity's case, isn't the topmost one; so much for multitasking!), and I believe it's up to Apple to figure out why.

 

Also, I noticed that *some* older apps, like Singer Song Reader (which I have always open underneath my iTunes mini player, right under the Up Next list so I can seamlessly toggle between said list and that lyrics viewer/fetcher), don't seem to honour that “being-pushed-from-the-other-side” behaviour (even though it sometimes ends up in the right place after turning the screen on, and sometimes it doesn't, as if macOS “forgot” about the y axis readjustment, and so does iTunes and Adobe apps, because I obviously configured my arrangement to make mouse movements as seamless as possible even with the slight PPI difference between both screens), which leads me to believe that this API is either a recent development, or something that developers have to actively implement. I should also add that this app, though apparently out-of-date, is already a 64-bit app, so it must've been coded in Cocoa, which means this isn't a Carbon vs. Cocoa issue (or so I think; could it still be?).

 

Oh, I should also add that, per iTunes' behaviour and when turning the secondary monitor off and on again, Illustrator and InDesign always end up with their panels on the “wrong” x coordinates (i.e. zero; they stick to the left-hand side of monitor 1, just like they would on monitor 2) but on the right y coordinates (i.e. more than zero, accounting for monitor arrangement, so… they show an “in-between-ish” behaviour), and Photoshop gets the y coordinates right and tries to do so with the x ones as well to simulate said “pushed-from-the-other-side” thing but fails miserably, because the panels edges aren't adjacent to the right edge of the monitor (in fact, only 1/3 of them is visible, because Apple has decided to crop out-of-view elements instead of showing the rest on the secondary monitor ever since they came up with Mission Control and solved the conundrum of having multiple desktops in multiple monitores with, dare I say it, nearly enough aplomb, if not for these weird-ass bugs). Also, none of them revert to their proper positioning when turning the monitor on, so it seems that Affinity apps are, indeed, better coded in that regard, as they behave somewhat like Apples' first party ones, but would be perfect if they did so even without being the topmost app when waking up from sleep, and would be even better if they matched Adobe's customisable Workspaces (and, of course, allowed for an also customisable keyboard shortcut for resetting/toggling between them).

 

I know that instead of being a full-blown permanent bug fix, going the Workspace route would be a palliative, and a temporary and incomplete solution that could end up becoming permanent, but seeing that you *may* be dependent on Apple to get this right, please do consider implementing those features if all else fails. Or even regardless of that, because they could indeed be useful for some professionals, as adding more and more Personas may not be the right way to go about managing different workflows or be enough (or desirable) for some people. Take, for instance, eclectic designers who work both for print and UI, and who Affinity seems to be tailored to or to encourage to become and do just that; they would likely love to have both print-bound and UI-bound custom workspaces, with the same Personas customised for different functions/jobs. That would keep the apps simple for *most* customers, and allow a certain subset of pro users to make it more complex if they really need it. Plus, it would make Affinity a better choice for multi-user office/school environments, where sysadmins, art directors and/or educators may not wish, for some reason, to configure separate, full-blown OS user accounts for separate people, and make their life easier if they need to reset workspaces/preferences, or copy them over from one machine to another (and, no, copying preferences from weird iCloud/MAS app ~/Library/Containers/* folders is *not* user-friendly at all, I'm afraid; cumbersome and archaic as Adobe's products may be – even going so far as sometimes requiring full preference resets to open at all because they become corrupted –, their Workspace tools are indeed useful); I speak from experience, as I had to give workshops at the Mac Room in my Faculty back when I was a monitor there: those tools are indeed useful in that kind of setting.

[JGD]

So, yeah, here are a couple of updates on the state of RC1. It seems that my complain about the gutters has been addressed, yay! But moving the panels manually is still less than optimal… In case you're wondering, the second time when I clicked and dragged the panels back and forth between screens, I never let go of the mouse button; they just went crazy on their own.

 

 

On the other hand, we finally have Fitt's Law working in our favour, as moving the cursor along the y axis further than the edge of the monitor no longer wreaks havoc. Now, if only they were as stable on the x axis when being moved across monitors…

 

 

[JGD]

I think another issue here with the Studio is the fact that it doesn't have a main, top group header like the Adobe CS/CC panels have (you know, the one with the x/close and chevron/collapse buttons). With their current scheme, you can clearly and easily click and drag: a) one individual panel, b) a sub-group of tabbed panels by clicking to the right of the last tab, or c) a super-group made up of sub-groups (either stacked vertically or horizontally) of panels by clicking said header.

 

Affinity apps, on the other hand, have to sort of figure out the users' intentions on their own. As you can see from my video, that method seems to work good enough when just dragging them around in the middle of the screen, but they end up breaking apart and regrouping in weird, undesirable and irreversible ways when reaching the edges and triggering the snap-to-the-edges translucent overlay (or is it the inter-monitor transition that triggers it? I can't seem to be able to figure it out,  because the two phenomena go hand-in-hand). Once you reach that state, it's game over, as leaving it isn't very forgiving. And boom, it's back to either manually putting everything back into its right place, or force-quitting the app again to reset them in one fell swoop.

 

Oh, by the way and if I may add, you can only drag the whole Studio super-group if you grab onto the top-left tab/panel sub-group, which can be troublesome if you have too many tabs on said sub-group. The space between the rightmost tab and the panel properties (in case the currently selected tab features one) is so small a clickable target that more often than not you end up selecting the rightmost tab instead and dragging it out of the sub-group by accident. Affinity apps should, thus, have a hard-coded gutter between those interface elements, to allow for easier sub-group and super-group drag operations.