More > JRiver Media Center 24 for Mac

[Request] Mac - support Full-Screen Mode

<< < (3/4) > >>

tjobbins:

--- Quote from: Awesome Donkey ---I don't think it'd be easy to do. For one, MC does its own window drawing and stuff like that.
--- End quote ---

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:

--- Quote from: tjobbins on October 08, 2018, 10:26:11 pm ---after all, MC already has MacOS window components like the red/yellow/green icons
--- End quote ---

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:

--- Quote from: Awesome Donkey on October 09, 2018, 03:12:29 am ---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.

--- End quote ---

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:

--- Quote from: blgentry on October 09, 2018, 03:26:34 pm ---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.

--- End quote ---

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 :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page