Please add full screen option for VNC

[gaionim]

As said from mzamot in #8392

Having a full screen button or the option of opening the VNC in a different tab would be really nice

I'll try to do it by myself, but I'm new to react/js :-(

[skobyda]

I believe it could be achieved. Our vnc display is basically a single react component
We can either make the VNC display component to stretch to the 100% height of the browser.
Or we truly make it fullscreen, there seem to be some npm libraries that can lock the whole component to the fullscreen.

I'm now not sure if it should be a replacement for our already existing "Expand" option.
Or maybe just an alternative, offerend next to "Expand", something like:

@garrett WDYT?

[skobyda]

It would also have some fitting icon next to "Fullscreen" just like expand option has an icon.

[garrett]

You can already expand VNC in Cockpit-Machines.

Then click expand

And you'll have a larger view.

However, the bar is still at the top and the navigation is still there on the side.

I guess you'd prefer a pop-out (with minimal Cockpit UI) or fullscreen option instead? (I'm not sure doing true fullscreen is possible.)

[garrett]

I think we'd want to make a minimal version or fullscreen (if possible) replace the current expand functionality.

[gaionim]

My naif idea was to add the alternative to open in new tab/window only the single component and delagate to the browser the fullscreen

[garrett]

@gaionim: Yeah, that'd be nice. That's what I meant as a popout option. It would be an almost-empty new tab (or window) with just the terminal. Then you could then maximize that or even hit F11 to fullscreen the browser window. Or we could just handle it as a sub page with a very minimal link at the top to go back (without all the rest of the Cockpit UI).

Using fullscreen support directly is special, and I'm not sure if that's possible in a reasonable way (as, IIRC, hitting ESC will kick you out of fullscreen, breaking a lot of apps, especially vim). https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API

I guess the best option would be to have an extremely minimal page with just a back link at the top and the terminal sized to the rest. And if you middle click it'd open in a tab. Otherwise, use the breadcrumb link at the top.

[garrett]

It'd basically look like this if we stripped out everything not 100% relevant to the terminal:

(This is just a modification of one of the above screenshots.)

I do have a different mockup @ #553 (comment) for when the terminal is embedded, regarding how to handle setting up ports and configuration. The other issue could affect how this works too. Perhaps we want the widget to basically zoom on page to take up the entire page instead?

And it could then possibly resize over everything else, where it stretches like this:

(Expand would be collapse with a different icon.)

[gaionim]

Using fullscreen support directly is special, and I'm not sure if that's possible in a reasonable way (as, IIRC, hitting ESC will kick you out of fullscreen, breaking a lot of apps, especially vim). https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API

I think that full screen is useful when working with gui, when the click of the mouse trigg the window/frame scroll;
for text program ( like vim ) I ( whe) can work nice with "expand" ;-)

[garrett]

Fullscreen means different things. You can hit F11 to maximize your browser and we can make some changes so there's not as much Cockpit around VNC. That's what I'm talking about being possible to implement.

The fullscreen API is almost assuredly not what you (and most other people) actually want, as if you hit the ESC key in vim while using the embedded VNC viewer, it will stop fullscreen mode and won't be passed to vim... which makes vim kind of impossible to use, unless you know the alternate escape key sequence, Ctrl-[... but most people use ESC.

What you probably want is a page where VNC takes up almost all of it instead. (Almost all, so we have very minimal UI to get back to Cockpit.) And then you can either just have a larger VNC area than right now and you can maximize it or even fullscreen your browser window (but not the VNC part itself).

Summary: I agree; maximizing VNC is a great thing Cockpit Machines should do. (But we shouldn't use the fullscreen API, which is meant for games and would pose some issues for us.)

[johnjtran]

Great discussion. How about a pop-up/detachable window? so Expand and Detach?

[shodanshok]

Great discussion. How about a pop-up/detachable window? so Expand and Detach?

Yeah, it would be nice to have a detachable windows, maybe in addition to the existing (or, even better, the proposed "trimmed") expand option.

[Betonhaus]

is it possible to resize the screen to fit in the window? I can never get the expand view to fully fit so I always have to pan up and down to navigate

[tgwaste]

Don't hold your breath. For some reason they just don't want to improve this experience. This is the worst aspect of cockpit imo. A resizable pop-out would make this whole thing 1000x better.

[Betonhaus]

Don't hold your breath. For some reason they just don't want to improve this experience. This is the worst aspect of cockpit imo. A resizable pop-out would make this whole thing 1000x better.

As it being a Fedora affiliated project that's a given, but I'm sure eventually they can be convinced that this is a valid use case. I have Remote Desktop set up but when not on the local network or doing configurations it's nice to be able to pull it into a proper view.

[mac2net]

I do not have knowledge of internal discussions of priorities or how resources get allocated, but after observing Cockpit development for a couple of years, it is my opinion that the functions of Cockpit have improved in most areas of the app. Frankly the VNC option in Cockpit is really more one of convenience – which it is – then for day to day GUI management. I setup XFCE on the metal and VMs - a light weight DE – and VNC into that when the need arises – it could be hourly or only every two weeks. There are certain GUI apps – while still avoiding FlatPacks – that add value and – make it worth it for the user to invest the extra time to install it but is not necessarily a priority of the Cockpit project as a whole.

[martinpitt]

they just don't want to improve this experience

It's not willingness or malice, we just haven't had a proper cockpit-machines developer for a long time now, so we can only do life support and a little maintenance these days. 😢 If someone has some time and dedication to improve this, we'll gladly help/review/give guidance etc.

[Betonhaus]

they just don't want to improve this experience

It's not willingness or malice, we just haven't had a proper cockpit-machines developer for a long time now, so we can only do life support and a little maintenance these days. 😢 If someone has some time and dedication to improve this, we'll gladly help/review/give guidance etc.

There were a few things that I felt could improve the experience, but I'll concede that it's largely functional as it is.
I will note the issues that I had when setting up a Windows VM, though I don't know how feasible they are to deal with

1. I had a seperate SSD that I wanted to dedicate to the VM. AppArmor blocks access to anything that isn't in the default libvirt image directory and it isn't made clear how to configure a data pool on a different drive to be whitelisted, and I ended up having to disable the relevant security feature as that what people with the same issues ended up doing - there didn't seem to be anything in documentation about this
2. When adding a shared folder to a Windows guest I had to find a guide to find and install relevant drivers. The guides are easy to find, however.
3. The Windows VM had a severe performance hit, which required editing the VMs .XML file directly to disable several scheduling systems and pinning specific CPU cores as per this guide, something that I feel should be partly the default configuration for windows guests, and partly exposed in the settings page for the VM
   I concede that if the project is understaffed there's not much I can do, the software seems sufficiently stable and I'd have to wait a while for fixes anyways as I'm using the Debian repository for cockpit

[garrett]

We definitely want to improve the VM part of Cockpit machines, and I have even worked on this feature a few times over the years, making mockups and spec'ing out how it should work, and have pushed for this to be improved more than a few times. However, it requires someone dedicated to the task to implement it.

Meanwhile, I've converted some of the issues mentioned here to issues, in hopes that they can be fixed meanwhile. As they're more standalone (instead of having to rewrite a more complex component like the viewer), they might be addressed sooner, whereas the viewer will require refactoring a component to improve it as intended.