Re: Status for the release

[Marc-André Lureau <marcandre lureau gmail com>]

On Tue, Aug 28, 2012 at 1:30 PM, Alexander Larsson <alexl redhat com> wrote:
> One issue is that you can't change the ram/disk size during the install.
> I ran into issues where the default size of ram was to small to be able
> to install, and it doesn't always pick a disk size that is what I wanted
> either. This really needs to be implemented, and we even have a design
> for it:
>
> https://github.com/gnome-design-team/gnome-mockups/raw/master/boxes/boxes-install5.png https://github.com/gnome-design-team/gnome-mockups/raw/master/boxes/boxes-install5.5.png

Agreed, this is of highest priority. However, we really need to get it
ready ASAP (this week) if we want it for 3.6.

> There are some issues with the scaling of the VM display. The long term
> goal is that any boxes-installed vm should have the right guest drivers
> to allow guest resize in a way that the guest always have the same
> resolution as the boxes window. This doesn't seem to work quite
> right at the moment (at least with a rawhide guest). It resizes when i
> resize the window, but to a somewhat smaller resolution, and then
> scaling it up a bit, making things slightly fuzzy.
>
> Even worse is when the guest does *not* have the right drivers/guest to
> allow resizing. Then it essentially picks a random resolution (whatever
> the window size is when the vm boots or installs or something) and then
> we always stretch the display. This makes it impossible to resize the
> window to get 1:1 pixel size, or even just the right aspect ratio. IMHO
> we should *never* magnify the VM output, only ever scale it down if it
> doesn't fit the current window (as scrolling a VM is a total pain).
>

This is less important issue, imho. If we get Christophe Windows
driver installation, and update qxl & agent in f18 (which I think is
planned very soon), then this will be less of a concern, since it's
only an issue during installation or switching to console for example.

> I feel that I don't really have enough control over the virtual boxes.
> This has several aspects:
>
> * Its very hard to read out the state of the boxes in the icon view. Is
>   the machine turned off, or is it in some hibernated mode? If its
>   turned off the screenshot still may display a desktop with running
>   apps yet when you click it you start at the bios boot. We really need
>   to better convey the different non-running states.

This requires some non-obvious UI tweaking. I would also consider this
of less priority than the two points above.

> * When I click a non-running box it may take quite some time to start
>   it, but there is no information about what is happening (restoring
>   from hibernation, starting vm, authentication or whatnot).
>   The design mockups in:
>    http://fedorapeople.org/~jimmac/gnome3/Boxes-login.webm
>   Shows a label in the toolbar during these phases which sounds like
>   a good way to give more feedback here.

That should be quite easily fixable hopefully.

> * Sometimes my boxes freeze or get into some weird state where I can't
>   do anything with them. In this case I would like to just force a
>   reboot or a power off, but there is nowhere in boxes where I can
>   currently do this. Instead I have to start virt-manager in order to
>   get control back over my vm.

In general, the force shutdown menu is enough.

> Its too easy to accidentally get the top-of-screen toolbar when in
> fullscreen mode. A lot of OSes have things at the top, like the
> gnome-shell hot corner or the unity menu-at-top. We need to make it
> harder to trigger this during normal VM use.

That has been tweaked already several times in the past (timer/delay).
Could be easily changed again. However, the design for it is not yet
really clear, so I didn't touch it more (John talked about bar opacity
animation for example)

-- 
Marc-André Lureau