Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[unfrostedpoptart]

Hi.

Please have the window sizing work like a Mac in the Mac version.
It should not be _ ☐ X
It should be Red/Yellow/Green circle.

More importantly, the green circle should move the MC window in and out of Mac's Full-Screen mode.
This is not the same as just maximizing the window.
It's a different mode where the window takes up the whole screen AND the window cannot have any other windows in front of it.
The second part is the most important for a program like MC - especially in party mode - so that it doesn't get buried behind other program windows.

Thanks,

 David

[unfrostedpoptart]

I just saw that the colored circles are available in some of the skins so that's not an issue; just the functionality of Full-Screen.

[Peter_T]

+1 - Full Screen mode is a nice feature for Mac apps... I didn't think it would make any difference but I really get used to using apps in full screen mode, and switching my full screened apps with a 3-finger swipe. 

[Awesome Donkey]

I just saw that the colored circles are available in some of the skins so that's not an issue; just the functionality of Full-Screen.

The stoplight buttons are bundled as images with the skins themselves, MC doesn't actually support the native Mac/Apple way of displaying the stoplight buttons - it has its own method of doing it (like Steam, Adobe apps, etc.). For example, if you change to dark mode the stoplight buttons system-wide change... except for MC, which doesn't have the dark mode button images available.

The point I'm trying to make is, yes, the buttons are there, but I don't think I ripped the full-screen stoplight button, which would need to be ripped.

[tyler69]

It is not the first time I see this request and it fits nicely in the "more native macOS" experience topic that comes also up from time to time. In my opinion not everything can be solved by adding or reworking a skin. I would be very happy to see a better macOS integration.

[tjobbins]

I made the same request in the v23 macOS forum, in this post.  I'll add the key points also to this post:

Besides being a worthwhile general improvement needed to better integrate into a macOS environment, the lack of a native Full Screen mode also causes one problem, and one disadvantage:

Problem: 
When using multiple monitors with "Displays have separate spaces" enabled, if a video is played full screen on one screen it has two possible effects:
1.  If the video window is focused, the menu bar disappears from all other monitors;
2.  If the video window is not focused (some other window on another screen is), then a menu bar is superimposed over the top of the playing video, as seen in this photograph of a MC full screen video.

Both of these are problematic.  Obviously it's not a good look to have a menu bar at the top of a playing video, and this happens whenever the user interacts with any window besides the video itself - ie when they want to simultaneously watch a video and use some other application.  The menu will be partially greyed-out, but it's still ugly and distracting.

And when the video is highlighted, it's also annoying that no menu bar is visible on any other screen, as it means the user can't see their clock and other icons that may contain useful information.

Both issues can be solved if either:  a) MC (optionally) automatically enters native Full Screen when theatre mode or a full-screen video is playing,  or b) MC allows for manual selection of native Full Screen.  Or ideally, both.

Disadvantage:
A further  factor is that having a full-screen video in native Full Screen means it moves out to its own Space.  This is handy, as it means the video can be switched to directly via Mission Control and shortcuts assigned to moving left/right a space.   This can be seen in this screenshot of Mission Control - here Firefox is in full screen, and so is a separate selectable Space.

If MC were to put any playing video (and Theatre View) in its own native Full Screen window, it would allow the user to switch back to it specifically, rather than simply switching to the space on which MC is on, and which may contain other applications hidden by MC.   In Safari it also means that a user can full-screen a video and then switch back to the main Safari window to interact with it, for example creating a new tab.

So the ideal implementation would be for MC to launch a new video window and (optionally) put it in native full screen, and then allow the main MC window to still be interacted with separately.   I believe this actually already works OK on Windows, when the user chooses to Full Screen to a different monitor than the one MC is on.  The video window is separate from the interface window and both may be used separately.

Thanks.

[tyler69]

Can we please get a native macOS fullscreen for MC?

[unfrostedpoptart]

Can we please get a native macOS fullscreen for MC?

Yes!  Any update from JRiver on this?   I'd think this would be pretty easy but I'm not a Mac developer.  The only issue I can think of is how pop-up windows (e.g. DSP) work in a full-screen app.

Can someone please give us some feedback on this?

Thanks,

 David

[Awesome Donkey]

I don't think it'd be easy to do. For one, MC does its own window drawing and stuff like that.

[tjobbins]

Yeah, my main complaint with MC on Mac remains the fact that there's no Native Full Screen support for video playback.  That and the fact that it's impossible to access the MC UI while a full-screen video is playing on another monitor, unlike Windows MC.

In a multi-monitor setup, I constantly have a menubar overlaid over my full screen video whenever the video is not focused.  And when it is focused, I can't see the menubar on any other monitor (thus missing status info like the clock, new emails, etc.)  Both of these would be fixed with Native Full Screen support for the video playback window.

Another annoyance is that it's impossible on Mac to access the MC UI while MC is playing full-screen video.  This is not directly related, but I believe is a side-effect of the rather 'hacky' way MC currently implements full screen video.

Another side-effect of how MC-on-Mac does its full screen video is that whenever I exit out of MC's full screen, my MC window often appears on the wrong Space.  It goes back to the correct position on the correct monitor, but it always goes to the first Space on that monitor, regardless of what Space it was on before.   I guess MC has no concept of Spaces, so it just does something like "Set Window Position to X,Y on Monitor Z"  rather than "Set Window Position X,Y on Space 5".

I do hope this whole area will be looked at sooner rather than the later.  I have no problem with MC not looking and feeling like a 'normal' MacOS app.  Non-standard menus, etc.    And I can even live with the quirks in the main UI window - not resizing properly, etc.  But I really do wish it integrated better for video playback at least.  Native Fullscreen and Spaces have been a part of MacOS for 6+ years now, it's not new tech.

[tjobbins]

I don't think it'd be easy to do. For one, MC does its own window drawing and stuff like that.

I've never developed on MacOS so I don't know how hard it is.  Googling suggests that for a new app the coding required to add Native Full Screen is very simple, but I agree that it might be  harder in more specialist cases like full-screen video.  But I would also say that there are many cross-platform apps that work on Windows, Linux and MacOS and fully support MacOS' specific screen features, like Native Full Screen and an understanding of Spaces.  And not just big-name apps, but also free programs developed by single developers or small teams. 

Personally it's full screen video that I particularly care about.  It'd be nice to have Full Screen for the MC UI as well, but I wouldn't be too upset if that took longer; given, as you say, that the main window is drawn in a non-standard way.  But it's definitely very important for full-screen video and Theatre View, and that's also the area where the code must already be separate for Mac.

mpv comes to mind as a relevant example: a free, cross-platform video player that has had Native Full Screen on Mac for years.  It's open-source, so I looked up the file that implements full screen video. It's in Objective-C and I know MC is C++, so it might not be directly applicable.  But I think the fact that full screen support amounts to no more than 100 lines of code total, half of it boiler-plate stuff, is still significant. 

Again I'm not a MacOS or C++ developer, so I apologise if I'm over-simplifying things.  I just know from a user's point of view that MC is an exception in its lack of support for these features, even amongst cross-platform apps.  In fact I'm struggling to think of another program of any description I've used recently on MacOS that doesn't support Native Full Screen, or which handles Spaces incorrectly.   

Its absence is more readily understandable for the main MC UI, for the reason you mention.  Not that the custom window drawing necessarily does make it hard to implement - after all, MC already has MacOS window components like the red/yellow/green icons, and Full Screen is just a property that needs to be set on the window, then MacOS does the rest.  But in the absence of the right knowledge, it does sound reasonable that it might be harder for the main UI.  But even accepting that, I do find it hard to understand when it comes to full-screen video playback - a separate, newly created window, and specific to MacOS - which is also where it would make the most difference for me personally.

The way MC implements full-screen video now feels like a bit of a hack, at least from a user-experience point of view: when a full-screen video plays, MC shifts its main UI window to the monitor on which video is set to play, paints it black and makes it inaccessible (but still visible in Mission Control, as a black square), then overlays a video window over the top of it.  I must admit I don't understand why the main window has to move to the same monitor as video playback and become inaccessible, nor why it wouldn't be straightforward to add (optional) Native Full Screen to the new video window that's created.  I suppose this could also be a vestige of MC being cross-platform, despite it only doing this on Mac.

But I do still wonder if it's more about it not being a priority for MC's Mac developer(s) to look into this, rather than actually being a big technical hurdle.  If so, I hope that will change. It's "rough edges" like this that I imagine harm take-up.  Long-time MC users like us will use it regardless, but new users are more likely to dismiss an app - especially a relatively expensive one - if it appears not to integrate well with the OS, and has small glitches and annoyances as a result.  I think it would be easy for a Mac user coming to MC for the first time to think this must be a poor port of Windows software and assume it's not going to be much good as a result. And such users are generally invisible - 99% of them won't come to the forum and list their problems, they'll just uninstall MC and move on to something else.  Which is a big shame.  First impressions count.

[Awesome Donkey]

after all, MC already has MacOS window components like the red/yellow/green icons

The red/yellow/green icons (they're called stoplight icons/buttons) are actually loaded from the skin being used via PNG files located in the skins' folder, and not from the OS itself.

[tjobbins]

The red/yellow/green icons (they're called stoplight icons/buttons) are actually loaded from the skin being used via PNG files located in the skins' folder, and not from the OS itself.

Oh yeah!  I see now they don't behave quite like the real OS icons either.  With the real icons, hovering the mouse over any of them causes the + / - / X icons to appear in all.  In MC, it only appears in the icon you're hovering over.

OK, so that wasn't a good example.  And I can certainly believe it's possible the main UI window might present more of a challenge.  All the code I looked at regarding Native Full Screen did make it seem like it's just properties you attach to the window, and the OS does the rest.  But that doesn't necessarily mean it will look OK once the OS automatically resizes it, given the contents is all non-standard.

But I still think that at least the full-screen video playback window should be straightforward, given it's a separate, MacOS-specific creation.

EDIT: actually, I just discovered one complication:  I believe that MC's 'video window' literally only plays video.  And then anything that needs to get overlaid over the top of it, eg the drop-down playback control menu at the top and the progress bar at the bottom, are generated as separate windows that appear on top of the playing video window.

I've confirmed this by going into Mission Control - if you do that while the progress bar is visible it can be seen to be a completely separate window.  Not part of the video window itself.  This might also explain why the main MC UI disappears from its normal position and moves to the monitor with full-screen playback, but appears hidden and blacked-out, behind the video.  I wonder if that UI window is generating those overlays and the quick and dirty way to get them to appear in the right place was to move the UI window there and generate them relative to its position.

So if native full screen was used it would require some re-work to get those overlays to appear over the video.  Really they'd need to be generated inside the video window; I don't think you can have overlapping windows on a Native Full Screen window.  (Though dialogue boxes do usually work, so not 100% sure on the details here.)

VLC and mpv both manage it fine, so I'm sure it's not anything too complicated that's required.  But it is a change from what MC does now; it's more than just adding the FullScreen property to the window.

I have to say that what Mac MC does regarding full screen video appears even more like a big hack to me now.  It's quite understandable as a first attempt when porting MC to a new platform - just finding the simplest way to get working video on an unfamiliar platform.  But to still be using the same hack a while later, with no indication there's any plans to change it despite all the disadvantages it brings, is a bit disappointing.  And just some communication on the subject could go a long way to lessening that - if it's going to take a while to improve this, at least let us know.

[blgentry]

tjobbins,

Do any of the behaviors you are describing manifest in a single monitor setup without Spaces?

You seem to be using the "real" full screen mode, called Display view, or Theater View (which is another "real" full screen).  I initially thought maybe you were trying to maximize the MC window and not use Display or Theater, but now I'm pretty sure you're using the intended full screen views.

I'm unable to test anything you have reported because I do not have a multi-monitor setup and I do not use Spaces.  That's why I asked the question above.

Brian.

[tjobbins]

tjobbins,

Do any of the behaviors you are describing manifest in a single monitor setup without Spaces?

You seem to be using the "real" full screen mode, called Display view, or Theater View (which is another "real" full screen).  I initially thought maybe you were trying to maximize the MC window and not use Display or Theater, but now I'm pretty sure you're using the intended full screen views.

I'm unable to test anything you have reported because I do not have a multi-monitor setup and I do not use Spaces.  That's why I asked the question above.

Brian.

Hi Brian

Yes I am talking about Display View as my primary concern.  And no, the main problems I describe will not happen in a single-monitor setup.  The issues are exclusive to a multi-monitor setup.  Sorry if I've not made it clear in this thread; I've posted my issues a few times in a few different threads, and I probably didn't give the full preamble in this latest one

For reference, here's the first time I posted about the problems lack of Native Full Screen causes me, including a photo of one of the symptoms: Request: support macOS Native Full Screen and use it for video/Theatre View.  That was back in March in the MC 23 Mac forum.

To give some more background, my system setup is as follows:
1. Mac Pro
2. Multiple monitors
3. Multiple configured Spaces on each monitor
4. "Displays have separate spaces" enabled in System Preferences -> Mission Control.  (Which in my view is by far the best setting for any user with multiple monitors who wants to use Spaces, as it allows switching Space on a monitor individually.  This is very powerful, and makes in my view the best 'desktops'/'spaces' system of any desktop OS; better than the equivalents on Windows 10 and the various Linux desktop environments.  Especially when combined with Native Full Screen apps, which in effect become their own Space.)
5. My MC setup is: MC UI positioned on monitor #3.   I then have MC configured to output full screen video to go to a different monitor, with:
Tools -> Options -> Tree & View -> Full Screen (Display View, Theatre View, etc) -> Monitor: Display #2;  Resolution: Desktop Settings (the only option selectable)

In terms of what people are requesting, I think it breaks down into two areas:
1. Native Full Screen for the main MC UI window, as the OP requested.  I'd like this too, and Mac users do expect apps to have it.  But personally it's not my number 1 concern.
2. Native Full Screen for MC's full-screen video mode, ie Display View.  This is what is particularly important to me, because non-Native full screen windows don't work well in a multi-screen setup. 

To re-iterate the problems around the lack of Native Full screen for Display View:  MacOS does not like non-Native full screen windows.  If a window goes full-screen without using Native Full Screen in a multi-monitor setup where "Displays have separate spaces" is enabled, it causes two issues:
a) When the non-Native full screen window (ie Display View) is focused , the menu bar disappears on every other monitor/Space;
b) When the non-Native full screen window is not focused, it has a menu bar overlaid over the top of it.

This is not specific to MC.  In Firefox for example, if I make a YouTube video full screen, it does the exact same thing.  However Firefox has the ability to first put its window into Native Full Screen, which solves the problem.  Chrome and Safari by comparison implement the best solution: they automatically go into Native Full Screen if you click the full-screen icon on any video.

Unfortunately neither solution is available in MC.

On top of all that, I have a second problem that's actually even more annoying:  the fact that the MC UI disappears and becomes unusable whenever Display View or Theatre View is entered.   Again this wouldn't be an issue with only one monitor where you couldn't hope to use both at once. But in a multi-monitor setup the user would expect to be able to access the MC UI while also having full-screen video play.  And in Windows (and I presume Linux), that's exactly how it works:  Display View generates a new full-screen window on the chosen monitor, and the main MC UI remains where it was and is fully usable.

On Mac, it's different.  As soon as Display or Theatre View is entered, the main MC UI window disappears.  Going into Mission Control reveals that it's been moved to the same window that is playing full-screen video, and is painted black so its contents are invisible.  I have theorised that this is part of a hacky solution for playing full screen video with information overlaid over the top - ie the progress bar.  I am guessing that the the invisible MC UI window is actually generating those overlays, eg progress bar, and therefore is positioned behind the full-screen video so they appear in the right place. Though even that doesn't make a whole lot of sense, given those overlays are actually their own separate windows and could be positioned anywhere.  But I can't think of any other reason why the UI has to move monitor and get hidden behind the Display View video window.

Then when Display View is closed, the MC UI is moved back to its original position.  But this causes another annoyance, a more minor one:  MC has no concept of Spaces.  So it correctly puts the MC UI back in the original place on the original monitor, but it always does so on the first Space of that monitor.  So the user can't decide to have it on a different Space, because every time Display View is entered and exited, it will end up on back on the first Space of whatever monitor it's on.

Although the inability to to use the MC UI while in Display View seems unrelated to "no Native Full Screen", I believe it is at least tangentially related.  At the least, providing proper Native Full Screen support for Display/Theatre View would likely require fixing this second problem as well, in that in order to have Native Full Screen, it's necessary for those overlays to be generated inside the same window that's playing video (because you can't have other windows overlaying a Native Full Screen one.)  So although that means more work, it also means that for me it's a double-fix:  provide a proper video window that can be Native Full Screened, and that would necessarily also fix the MC UI becoming unavailable.

Now I do realise that a multi-monitor setup is not the majority case.  Perhaps that's why it's not a great priority for the MC team.  Nonetheless it is an area that's growing, and as MC is a media player it should be expected to work well on systems that have a separate display - eg a separate TV cabled up to watch films/TV shows while the main display is used for normal computer work.  Besides which, this is sadly an area where MC on Mac comes off looking a little shoddy, and it doesn't fit with its otherwise premium, high-end feel.  And a premium feel is important for a premium price tag, which MC has.

So in conclusion my issues are a little different to that which the OP raised.  Other people asking for Native Full Screen are no doubt expecting it throughout MC, starting with the main UI window.  I'd like that too, but my main concern is potentially easier to resolve: at the least get Display View in Native Full Screen, and let me access the UI at the same time.  If I had that I wouldn't grumble too much about the fact that the MC UI itself doesn't support MacOS' normal display features like Native Full Screen.

Anyway I've now written more on this subject than seems reasonable, so I'll try and stop now

[Hendrik]

the fact that the MC UI disappears and becomes unusable whenever Display View or Theatre View is entered.

This is actually default behavior on every OS, unless you specifically detach the Display View into its own window (and its never an option with Theater View).
I'm not sure if detached displays are implemented for Mac, but they might not, because they require certain extra magic.

A lot of the behavior you describe as a "bug" is just how its supposed to work. If you enter Theater View, the entire MC UI is replaced with the Theater View interface (and as such the MC window moves to whichever screen you denoted the "fullscreen screen"). The same applies to Display View. Those are all "Views" that change the primary MC interface, its not designed to have "Standard View" and any of the others in parallel - with one exception, that you can theoretically detach a Display View into its own window, practially I would have to check with John or Bob if this is implemented for Mac, or if there are any immediate plans for that.

For fullscreen, the sad truth is that Apple keeps reinventing their stuff every few years. Its practically impossible to write an application without reserving endless of hours of future maintenance without it breaking horribly.
We support the Fullscreen API that they've had for a bit longer, for Video and Theater View, but in their endless "wisdom" they decided to replace that with yet another one some versions ago, hence it doesn't work properly in all cases anymore.

We will have to investigate the effects of that new API and if all the appropriate overlays can still be shown, it'll probably take some time. Do note that at this point this would only apply to Display View and Theater View. Not sure there are any other plans to get the Standard View into some sort of special Fullscreen mode. I may be missing the advantage of that.
We also target an unusually broad range of OS X versions (at least for Apples likings, for all they care anything but the latest is dead), which doesn't make this any easier.

[tyler69]

We also target an unusually broad range of OS X versions (at least for Apples likings, for all they care anything but the latest is dead), which doesn't make this any easier.

There is also the possibility to restrict any upcoming major MC version to only a few of the latest OS X/macOS versions.