full screen mode (maximize)

[mifi]

as suggested here #421, it could be nice with a button that removes all controls to allow a full screen video preview (or possibly only with playback controls).

• implement full screen
• hide menu bar on Windows, see this electron bug: [Bug]: Application menu visible while embedded video is in fullscreen electron/electron#38414
• add fullscreen timeline/ui controls full screen mode (maximize) #543 (comment)

[markusd1984]

A true full screen mode is always nice, with the full editing interface to make the most of the screen estate,

while a clean playback fullscreen mode would also be handy, but more so if that can playback the simulated merged video cut points to check the segments what they will look like when exported. (#253 / #480 (comment))

[shedali]

would love to have a way to toggle the editing interface for distraction free viewing

[mifi]

leave a thumb up if you like to see something implemented

[erdemdev]

Lossless Cut is so good that I even watch movies with it now. As a content creator, being able to watch videos and easily extract the parts that catch my eye has made my work much easier. The biggest drawback I see right now is that we cannot toggle the fullscreen mode by double-clicking on the preview screen.

[mediamixer]

Absolutely loving LLC, probably the coolest thing I've seen anyone do with ffmpeg. Kudos! I have voted on several additional wanted features, but they're mostly huge overhaul-level changes like both forms of batch/NLE editing (AKA #89/#976) or a perfected audio waveform. I appreciate how massive those requests are, and LLC is likely to remain a big part of my experiments even if those never come to fruition.

Full-screen mode, conversely, feels like a relatively quick and easy thing to implement, yet it would mean I would no longer feel compelled to open a bunch of Potplayer instances as I search for the prefect snipping frame. I'm mostly chopping out small video segments to experiment with AI-based upscaling and frame interpolation and then comparing extremely nuanced results side-by-side in Nvidia's ICAT, so I really need to be constantly looking at every pixel of video data I can fit on my screen. Even a simple F11 or Ctrl+F in LLC would make a huge difference.

Ideally, of course, this feature would involve both a remappable hotkey, and erdemdev's double-click alternative, and a way to preview merged segments in FS, and also some form of hidden, mouse-over-to-unhide minimal UI (maybe even with some way to reconfigure which buttons appear there?), but even a hardcoded "dumb" full-screen hotkey would completely change the way I use LLC. Seems like the very best bang-for-your-buck use of your precious dev time, at least for what I'm doing.

Many thanks for continuing to work on this fantastic tool you have created!

[mifi]

Hi! I'm not sure which OS you're on but nn MacOS I can press Cmd+Ctrl+F and it will full screen losslesscut (or any other app) and remove the title bar etc:

I'm sure Windows and Linux based desktops have a similar feature.

Additionally the right side bar can be hidden in order to make even more space for the video. Or are you asking for a fullscreen where we remove all UI controls and simply just play back the video without any functions like setting cut in/out-point because you need to also use the pixels currently occupied by the UI?

[mediamixer]

Apologies for not being more clear - I am definitely asking for a fullscreen mode that hides all UI elements and fills the monitor with only video. Anything beyond that is gravy.

Using Potplayer as my example, I can either press Enter or middle-mouse-click to have a video touch all four monitor corners, with a minimal mouseover popup UI and additional settings for dealing with overscan/black bars, different aspect ratios, pan/zoom, etc.; MPC-HC is similar, but uses F11 and double-click by default. Even if some of those other features might be nice to have, all I need to significantly alter my workflow is a simple hotkey and/or mouse-based command (double-click, middle-click, whatever) to view full-size video.

Ideally, I imagine it should not be terribly difficult to also enable all hotkeys to function in this new fullscreen mode, meaning that I could pop into fullscreen, scroll through the timeline with mousewheel, jog between frames with comma/period, select a segment with I/O, and then pop back into "UI Mode" to do exporting or whatever else. You have a really excellent hotkey schema already baked into LLC, and (for me at least, but I suspect for several other posters here as well) this would really unlock a major part of LLC's untapped potential. That such an impactful change would seemingly require a pretty small amount of work is why I bothered submitting the request when there are a million other things you also want to add. 😁

One last note: On Win10/11, Ctrl+F does nothing, but the somewhat-more-common F11 does replicate the "title-bar-less 'full'-screen mode" you describe, even when the LLC instance is not maximized. It's nice, but it's still not enough pixels for me, I want them all! 😆

Many thanks for taking the time to consider this addition, it's very appreciated!

[mifi]

Ok I've added a fullscreen feature. double click the video or bind your own key (default f, same as youtube). will be out in the next version (and nightly build)!

[mediamixer]

Great, fantastic! The segmenting workflow I described seems to work very well in FS mode, many thanks for adding it! I just have one remaining quibble and a rather bizarre bug report (is this even the right place for that?)

Under Win10&11, F works exactly as I had hoped, except it retains the menu bar. F11 still removes the title bar, but also leaves the menu bar. This is a perfectly valid method of protecting users from getting "lost" in this new mode, but it also means I'm stuck with black bars (albeit thin ones) on either side of a typical video. This is not exactly intolerable, but I'm left wanting some way to hide the menu bar, as well.

Would it be reasonable to additionally request a simple "Hide menu bar in fullscreen mode" toggle in the Settings, defaulted to off (i.e., the current build's behavior)? That would seem to prevent inexperienced users from stumbling into fullscreen mode accidentally with no apparent way out while also satisfying 100% fullscreen absolutists like me. 😁

Also, an odd bug is identically present on both a Win10 PC and a different Win11 PC, and persistently repeatable: In FS mode, when alt-tabbing or clicking on any other window or even clicking the desktop of a second monitor and then clicking back into LLC, suddenly Space to play/pause begins acting very strangely - Space now behaves more like "hold to play/pause," and after holding down the spacebar for a second or two begins exhibiting lag as though it were processing a stream of contradictory commands. This is all the more inexplicable because merely clicking out or alt-tabbing to a second window, clicking around or whatever in that window, and then alt-tabbing back to LLC does not exhibit the weird behavior, only clicking back on a fullscreened LLC instance that is out of focus causes it. As LLC is an application that is likely to be juggled alongside an NLE, etc., this bug merits at least cursory investigation. The good news, thankfully, is popping back to "UI mode" and clicking the blue play/pause button (or even a single Space press) seems to completely reset things back to the expected behavior (a welcome sign of resilient code), but does not prevent the bug from immediately recurring when switching to another window and clicking into LLC again. Weird!

I am happy to provide additional testing, but I'm a bit of a Github newbie - any additional directions are very welcome, and I thank you for your patience and ongoing effort. 🙏

[mifi]

Under Win10&11, F works exactly as I had hoped, except it retains the menu bar. F11 still removes the title bar, but also leaves the menu bar. This is a perfectly valid method of protecting users from getting "lost" in this new mode, but it also means I'm stuck with black bars (albeit thin ones) on either side of a typical video. This is not exactly intolerable, but I'm left wanting some way to hide the menu bar, as well.

I can't reproduce this on macOs. When I fullscreen, there is no menu visible here. I don't even know how to fix this, because I'm using the requestFullscreen API. the only option I see is navigationUI, but I already set this to hide.

Also, an odd bug is identically present on both a Win10 PC and a different Win11 PC, and persistently repeatable: In FS mode, when alt-tabbing or clicking on any other window or even clicking the desktop of a second monitor and then clicking back into LLC, suddenly Space to play/pause begins acting very strangely - Space now behaves more like "hold to play/pause," and after holding down the spacebar for a second or two begins exhibiting lag as though it were processing a stream of contradictory commands. This is all the more inexplicable because merely clicking out or alt-tabbing to a second window, clicking around or whatever in that window, and then alt-tabbing back to LLC does not exhibit the weird behavior, only clicking back on a fullscreened LLC instance that is out of focus causes it. As LLC is an application that is likely to be juggled alongside an NLE, etc., this bug merits at least cursory investigation. The good news, thankfully, is popping back to "UI mode" and clicking the blue play/pause button (or even a single Space press) seems to completely reset things back to the expected behavior (a welcome sign of resilient code), but does not prevent the bug from immediately recurring when switching to another window and clicking into LLC again. Weird!

i can reproduce this issue. will fix

[mediamixer]

Under Win10&11, F works exactly as I had hoped, except it retains the menu bar.

I can't reproduce this on macOs.

That is frustrating! It definitely is not a "sometimes" bug, rather there's absolutely nothing I can do to get the menu bar to go away under either Win10 or 11. Isn't one of JS+Electron's selling points that the same code is supposed to run the same in any environment? 🤨

I am entirely out of my depth here - the only leads I've gotten are the obvious reminder that the Fullscreen API only works on the referenced Element and its descendants (it seems unlikely that MacOS would work fine, but Windows would somehow "forget" the same dependencies), something inscrutable about Promise, and this either worthless or prescient suggestion from ChatGPT3.5:

BrowserWindow Configuration:
When creating your Electron BrowserWindow, make sure that you set the fullscreen option to true. Additionally, consider setting the autoHideMenuBar option to true to hide the menu bar automatically in fullscreen mode.

const { app, BrowserWindow } = require('electron');

app.on('ready', () => {
  const mainWindow = new BrowserWindow({
    width: 800,
    height: 600,
    fullscreen: true,
    autoHideMenuBar: true,  // Set to true to auto-hide the menu bar
  });

  mainWindow.loadFile('index.html');
});

Since menu bars are very OS-dependent, I can almost believe MacOS and Windows have different defaults when autoHideMenuBar is not explicitly called when entering fullscreen. Is that worth trying? Also sounds like there may have been an Electron-level bug with all this at some point. Apologies if any of this is silly or insulting to your intelligence, I'm just trying to do whatever fumbling legwork I can. 😆

I'll try to keep digging and eventually drop into the LLC Discord to hunt for more clues. I realize this is probably no longer a quick and easy request and we might never stumble upon one of the few people who would know exactly what's happening here, but I'm not ready to give up my 100% fullscreen dreams just yet! 😁

[mifi]

someone needs to do some testing on windows. i'm on macos so it's not trivial for me to run/debug in development mode on windows. but if there's a simple fix, i'm open to PR a fix

[mediamixer]

i'm open to PR a fix

I hope I'm not the guy for that job, as I've never touched JS nor so much as forked anything ever. Is this starting to look like a situation in which it might be appropriate to @ or email a Windows-focused Electron dev or possibly a past collaborator?

Alternatively, it seems the only real clue we have thus far is the autoHideMenuBar: true thing (or one of several possible equivalents). Is it fair to say that's something you should probably be calling (or, IDK, toggling?) alongside the existing fullscreen logic anyway? Make the implicit explicit? I still have hope that one of these, e.g. win.removeMenu(), may yet magically fix this odd discrepancy. I would be happy to do Windows testing on nightly executables whenever requested, if that's a path you wanted to pursue. 🙏

[mifi]

Ok i've enabled autoHideMenuBar: true (on Windows) now. so in the next nightly you can test it if you like

[mediamixer]

Ah-ha! Significant (but qualified) success! Under Windows 10 and 11, the most recent nightly hides the menu bar entirely from first execution, and it remains hidden in fullscreen mode. I was worried this rendered LLC unusable, however a peek at the Electron docs revealed I can make it reappear with a press of the Alt key, both inside fullscreen mode and in windowed/maximized mode, even before loading a video, while playing one, etc.. It works! 100% fullscreen mode under Windows achieved! 🥳

Of course, from a usability standpoint, hiding the menu bar by default is almost certainly not a best practice, and at this point I doubt the average Windows user would even know that Alt is the conventional key to access the menu bar. In the most recent full release of LLC, Alt does what I expect, allowing arrow-key navigation of the menu bar, and this is also true in the nightly; however, autoHideMenuBar really wants to always hide the menu bar, meaning Esc or even clicking outside the menu/title bars (or even clicking outside the LLC window!) makes the menu bar disappear again. In other words, the nightly's menu bar is only visible if it has focus/one of the menus is highlighted, and you can currently only get there if you are aware of Alt's functionality. All this is fine for my purposes, but perhaps not ideal for a wider release.

So, where you go from here is a question largely of design philosophy (and the extent you can get Electron to cooperate.) The quick-and-dirty solution might be to default autoHideMenuBar to false and provide a toggle in the Settings with a warning, e.g., "Advanced (Windows) users only! Hide menu bar; press Alt to access menus"? Getting Electron to produce more elegant behavior (e.g., getting back to parity with MacOS such that the menu bar is hidden only in fullscreen) would be nice, but I could see it devolving into a wrestling match even if you did have a Windows machine.

I'm happy to continue testing for as long as you want to keep experimenting with this (and many thanks for getting us here!), but we are probably rapidly approaching a point where your time would be better spent elsewhere. 🙏

[mifi]

oh.. yea that's what i feared. i think another option is to set mainWindow.autoHideMenuBar = true when entering fullscreen and mainWindow.autoHideMenuBar = false when exiting fullscreen (only for Windows) but not sure if that would work at all, I also see in electron docs that:

A boolean property that determines whether the window menu bar should hide itself automatically. Once set, the menu bar will only show when users press the single Alt key.

If the menu bar is already visible, setting this property to true won't hide it immediately.

I also found this open electron issue which is probably the same problem, however i'm baffled that there are not more people experiencing this issue.

[mediamixer]

i think another option is to set mainWindow.autoHideMenuBar = true when entering fullscreen and mainWindow.autoHideMenuBar = false when exiting fullscreen (only for Windows)

Docs seem to suggest this wouldn't quite work, but we're already outside expected operation, so it might be worth trying. I'll be checking this thread pretty frequently, so you'll have at least one longwinded Windows tester to try out any changes. 😁

Correct me if I'm wrong, but I feel like it's still an open question whether autoHideMenuBar is even the preferred function for this versus what seems like a whole lot of other overlapping functions. Even above that, what are the merits of the requestFullscreen API versus calling fullscreen: true on your BrowserWindow as ChatGPT suggested? I don't know where Electron gets a lot of use, but menu-bar-less fullscreen isn't exactly an obscure feature across all Windows applications, quite the opposite. A plausible reason why there isn't more chatter around this disconcerting Windows/MacOS disparity is simply because you're trying to do a common thing in an unorthodox way? 🤷‍♂️

One final thing I can add that might dictate which solution is "most" correct: The one other feature I most want in LLC is a collapsible timeline UI AKA "seek bar" inside fullscreen mode, exactly of the sort PotPlayer, MPC-HC, and virtually any media player with a fullscreen mode has adopted. In short, when I need to jump from the beginning to the end of a video file, I'd like to drag my mouse down to a hot zone at the bottom of the LLC window, have a minimal clickable timeline UI element pop up that obscures the bottom of the fullscreen video (as opposed to resizing and placing black bars), click myself to the general area I want to be in, drag up out of the element thus instantly hiding it again, and scrollwheel to precisely where I want to make cuts. Yes, I could just exit fullscreen mode to achieve this kind of navigation, but when you're doing it hundreds of times per video, that small amount of friction really adds up. An additional ribbon of useful buttons or even bringing up the entire bottom section of LLC's windowed UI for momentary use would be great, but simply having quick access to click around the timeline without exiting or resizing fullscreen mode would make this mode feel complete. I suspect there is a fairly painless way to achieve this using one set of the options before you, and probably a bunch of relatively painful ways using the other competing functions, but that's why you're the developer and I'm just some guy. 😋

[mifi]

I've reverted the autoHideMenuBar option because i agree it's not nice to hide it for everyone.

what are the merits of the requestFullscreen API versus calling fullscreen: true on your BrowserWindow as ChatGPT suggested?

the reason why i'm calling requestFullscreen API is because we need to fullscreen only parts of the UI (the video player), but not all the surrounding stuff.

besides, the issue was reproduces by the person in the above issue and happens even with a normal <video> tag, so it doesn't seem to be related to the requestFullscreen API: https://github.com/c3er/electron-fullscreen-issue/blob/master/app/index.html - I would think using <video> tags in apps is quite common.

One final thing I can add that might dictate which solution is "most" correct: The one other feature I most want in LLC is a collapsible timeline UI AKA "seek bar" inside fullscreen mode, exactly of the sort PotPlayer, MPC-HC, and virtually any media player with a fullscreen mode has adopted. In short, when I need to jump from the beginning to the end of a video file, I'd like to drag my mouse down to a hot zone at the bottom of the LLC window, have a minimal clickable timeline UI element pop up that obscures the bottom of the fullscreen video (as opposed to resizing and placing black bars), click myself to the general area I want to be in, drag up out of the element thus instantly hiding it again, and scrollwheel to precisely where I want to make cuts. Yes, I could just exit fullscreen mode to achieve this kind of navigation, but when you're doing it hundreds of times per video, that small amount of friction really adds up. An additional ribbon of useful buttons or even bringing up the entire bottom section of LLC's windowed UI for momentary use would be great, but simply having quick access to click around the timeline without exiting or resizing fullscreen mode would make this mode feel complete. I suspect there is a fairly painless way to achieve this using one set of the options before you, and probably a bunch of relatively painful ways using the other competing functions, but that's why you're the developer and I'm just some guy. 😋

I will reopen this issue with the potential remaining fullscreen improvements.

[mediamixer]

I will reopen this issue

You are the actual best, mifi. Thanks! I can report it appears you already crushed the fullscreen alt-tabbing bug, too; the most recent Windows nightlies play nice and smooth and so far I haven't been able to knock them into that weird press-to-play state like I easily can with the last full release. What a boss! 🤩

Hopefully using the superior API will make popping up an existing UI element fairly straightforward, but I expect the Electron-level menu bar bug might take a while to get a proper fix, if one even comes. I'll be standing by for further nightlies and anything else I might be able to assist with.

Keep up the awesome work! 👍

[mifi]

menu bar visible issue seems to be fixed in electron in electron/electron#43402

so next time losslesscut upgrades electron it should be fixed

[nymation]

so next time losslesscut upgrades electron it should be fixed

good news! I'd be happy to test this on Windows if shipped an executable (the menu bar is still present in the latest nightly). : )

[mifi]

yes, it seems to be ocming in electron 33 which has not yet been released
yangannyx/electron@6d4783e#diff-c21189076792cbf92bc10794257ef9b91d2ef6403bfae4d5a0af1805b21850c8R18

[mifi]

now upgraded to electron 33. next nightly build will have it