Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Config window text and control elements alignment issues [v4.0.3] #4374

Closed
LostInCompilation opened this issue Sep 5, 2022 · 8 comments
Closed
Milestone

Comments

@LostInCompilation
Copy link
Contributor

LostInCompilation commented Sep 5, 2022

Describe the issue
The config window of the VMs have alignment issues. The text and control elements are cut. This happens on most pages like "Input", "Sharing", "Display", ...

Screenshot 2022-09-05 at 13 49 09

Configuration

  • UTM Version: 4.0.3 (62)
  • macOS Version: 12.5.1
  • Mac Chip (Intel, M1, ...): M1 Pro
@brunocastello
Copy link

Same happens with the buttons for drive reclaim and compress space. I think the previous UI for that action is better, because semantically speaking, compressing the image is also a way to reclaim space (on host, it is).

@LostInCompilation
Copy link
Contributor Author

LostInCompilation commented Sep 5, 2022

Can confirm, the text on the buttons are misaligned.

I think the previous UI for that action is better, because semantically speaking, compressing the image is also a way to reclaim space (on host, it is).

I disagree. The old UI is just an unnecessary extra click. It is far better like it is now. Those are also two completely different functions. Compressing is not the same thing as reclaiming free space.

Screenshot 2022-09-05 at 16 41 32

@osy osy added this to the v4.0 milestone Sep 5, 2022
@brunocastello
Copy link

brunocastello commented Sep 5, 2022

I disagree. The old UI is just an unnecessary extra click. It is far better like it is now. Those are also two completely different functions. Compressing is not reclaiming free space.

As a professional UI/UX Designer, It's not an extra click when you want to do both reclaim and compress, which is what I have been doing on all vms prior to 4.0.2. Now I have to press one then wait till it reclaims to hit another to compress. Users will find its better to do it all in one go.

Compressing is reclaiming free space, yes. Example: I have a 2GB DOS vm. It uses approx 1GB. After compression, it now uses 500mb of my host disk storage for that disk image. So I reclaimed 500mb back for my host machine. In a world where Apple machines are expensive and you have to save some bucks buying the entry level ones with less storage sizes, it's a must have to do it.

@osy
Copy link
Contributor

osy commented Sep 5, 2022

But you don’t. If you click compress it literally says it will do both operations. This is also to make the UI consistent across multiple versions. On macOS 11 SwiftUI doesn’t support 3 button alerts so we just dropped the compress option.

@LostInCompilation
Copy link
Contributor Author

LostInCompilation commented Sep 5, 2022

Yeah I think you misunderstood something @brunocastello... It's literally the exact same thing, except those are now two separate buttons instead of a separate dialog which contains the same buttons previously. It is just one click less now, with the same functionality. Therefore much better UI design.

However I think you misread my sentence "Compressing is not reclaiming free space.". This was not meant to say that the compress option doesn't relcaim free space beforehand. Just that those are two different functionalities based on your argument about semantics. I edited my post to make it clear.

@brunocastello
Copy link

OK, I may have misunderstood it then. BTW, The current compression method on 4.0.3 is compressing much less than it did in 4.0.2. I noticed quite a bit of diffence between them when I compressed the exact same vm on both. I guess it has to go in another issue instead of here.

@osy
Copy link
Contributor

osy commented Sep 5, 2022

By how much? We changed to zstd which should be ~5% worse in compression but should be much faster during reads.

@LostInCompilation
Copy link
Contributor Author

Reclaiming space seems to be buggy too, see #4377. I could not test compression reliably, since reclaiming inflates the size by a great degree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants