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

feat(gui): Display image size when drive too small #1807

Merged
merged 1 commit into from
Mar 21, 2018
Merged

Conversation

jhermsmeier
Copy link
Contributor

@jhermsmeier jhermsmeier commented Oct 24, 2017

This adds a display of the determined image size to the
drive label when the drive has been determined to be too small.

screen shot 2018-03-21 at 20 40 59

Change-Type: patch
Changelog-Entry: Display image size in drive selector if drive is too small
Connects To: #1136, #2004

@@ -376,9 +377,10 @@ exports.getDriveImageCompatibilityStatuses = (drive, image) => {
message: exports.COMPATIBILITY_STATUS_MESSAGES.LOCKED
})
} else if (!_.isNil(drive) && !_.isNil(drive.size) && !exports.isDriveLargeEnough(drive, image)) {
const imageSize = _.get(image, [ 'size', 'final', 'estimation' ]) ? image.size.final.value : image.size.original
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This logic looks weird. Basically, if the image final size is an estimation, use that, otherwise use the original one, which means we will use the original size even for compressed sizes that we know their final size for sure (i.e. that are not estimations).

Maybe the intended logic is: If the final one is not an estimation, use that, otherwise use the original size.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh boy, yeah, I messed that up – fixed now :)

Copy link
Contributor

@lurch lurch Oct 25, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the intended logic is: If the final one is not an estimation, use that, otherwise use the original size.

Isn't that exactly what the 'final' size is anyway?

@lurch
Copy link
Contributor

lurch commented Oct 25, 2017

I'm not sure if this is actually needed? In @jhermsmeier 's screenshot above you can clearly see that the (uncompressed as necessary) image size is already shown in the main Etcher GUI anyway...

@jhermsmeier
Copy link
Contributor Author

Yes, you're right – I checked the conversation again, and have now changed it to display the relative bytes missing for the image to fit:

screen shot 2017-10-25 at 13 23 22
screen shot 2017-10-25 at 13 27 16

@jhermsmeier
Copy link
Contributor Author

jhermsmeier commented Oct 25, 2017

I don't think this is completely unnecessary though, as the issue discusses, it's aimed at helping people figure out why a 8GB image won't fit on a 8GiB device, for example.

@lurch
Copy link
Contributor

lurch commented Oct 25, 2017

Instead of "Too Small For Image - 46.15 MB", what about something like "Too Small For Image by 46.15 MB" - might be slightly clearer?

@Shou
Copy link
Contributor

Shou commented Oct 25, 2017

I was just about to say the same @lurch! Also maybe we could make the constant into a template that takes a size field?

@jhermsmeier
Copy link
Contributor Author

Yeah, added the "by" :)

Also maybe we could make the constant into a template that takes a size field?

I thought about it when I started this, but the messages used aren't in shared/messages, but the shared/drive-constraints itself – and moving them all over for no gain seems excessive to me. In this case, string concat is more than enough imho, and not worth overcomplicating (also, I'd actually rather get rid of those lodash templates, but that's a different discussion)

screen shot 2017-10-25 at 13 42 59

Copy link

@konmouz konmouz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree "Too Small For Image by 46.15 MB" works much better, otherwise, the user has to assume what the MB refers to.

@Shou
Copy link
Contributor

Shou commented Oct 25, 2017

(also, I'd actually rather get rid of those lodash templates, but that's a different discussion)

Made #1810 to discuss this

@jhermsmeier jhermsmeier force-pushed the patch-1136 branch 2 times, most recently from 15f9626 to 64a8c14 Compare October 25, 2017 14:10
@jviotti
Copy link
Contributor

jviotti commented Oct 25, 2017

I must confess I'm confused when looking at the screenshot. For example, we have a drive that is 130 MB and the label says "Too small for image by 1.72 GB." I can't tell for sure if it means I should have a drive that is at least 1.72 GB, or that my drive would need to be 1.72 GB larger (in which case I have to do some arithmetic to find that I need a 1.85 GB drive).

Can we rephrase the whole label to something like "Too small. Should be at least XXX MBs" or something like that?

Copy link
Contributor

@jviotti jviotti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good code-wise, but I think the UX still needs to be discussed/polished.

@lurch
Copy link
Contributor

lurch commented Oct 25, 2017

Can we rephrase the whole label to something like "Too small. Should be at least XXX MBs" or something like that?

But as I mentioned earlier, that would simply duplicate the (uncompressed) image size, which is already visible in the main Etcher GUI anyway?

Perhaps @jhermsmeier didn't choose the best examples (who has a 130MB drive these days?! 😉 ), but imagine that you have a compressed image that's 8001MB when uncompressed, but your SD card (labelled as "8 GB") actually has a capacity of 8000MB. With @jhermsmeier 's last proposal Etcher would display "Too Small For Image by 1 MB" whereas @jviotti 's proposal would display "Too small. Should be at least 8 GBs"
*shrug*

(P.S. Yes, I can never remember whether Etcher uses 1024 or 1000 when converting from bytes to kilobytes, megabytes, etc. so please ignore any mistake I've made in that regard!)

@jhermsmeier
Copy link
Contributor Author

who has a 130MB drive these days?! 😉

I do :P It's an old marketing gift thing I picked up somewhere, came in handy for testing every now and then :)

P.S. Yes, I can never remember whether Etcher uses 1024 or 1000 when converting from bytes to kilobytes, megabytes, etc. so please ignore any mistake I've made in that regard!

Pretty-bytes (which we're using atm) uses base-10 (aka "hipster-units"), so generally 1KB = 1000B in Etcher (I think there might be an internal place or two where be use 1024B for reasons).

@jhermsmeier
Copy link
Contributor Author

I concur with @lurch – the "Should be at least XXX MB" would just dupe the image size; How about "Insufficient space, additional XX MB required" or something along those lines?

@lurch
Copy link
Contributor

lurch commented Jan 29, 2018

This would also fix #2004

@jhermsmeier
Copy link
Contributor Author

Changed the message to 'Insufficient space, additional XX required' & rebased against master

Copy link
Contributor

@Shou Shou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM after the linter is satisfied

statusList.push({
type: exports.COMPATIBILITY_STATUS_TYPES.ERROR,
message: exports.COMPATIBILITY_STATUS_MESSAGES.TOO_SMALL
message: exports.COMPATIBILITY_STATUS_MESSAGES.TOO_SMALL.replace('XX', prettyBytes(relativeBytes))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is failing with Prefer '_.replace' over the native function lodash/prefer-lodash-method

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@@ -303,7 +304,7 @@ exports.COMPATIBILITY_STATUS_MESSAGES = {
* @description
* The drive is too small for the image.
*/
TOO_SMALL: 'Too Small For Image',
TOO_SMALL: 'Insufficient space, additional XX required',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should make these into template arrow functions? We can keep it as-is now and open a new PR for that, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've now moved the compatibility messages from drive-constraints to shared/messages and made them functions

Copy link
Contributor

@Shou Shou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jhermsmeier jhermsmeier dismissed jviotti’s stale review February 14, 2018 15:43

UX has been updated

@jhermsmeier
Copy link
Contributor Author

@jviotti can you have another look at this?

Copy link
Contributor

@lurch lurch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool :)
Could you update the screenshot in the first comment?

This adds a display of the determined image size to the
drive label when the drive has been determined to be too small.

Change-Type: patch
Changelog-Entry: Display image size for comparison if drive is too small
@jhermsmeier jhermsmeier merged commit ad7c876 into master Mar 21, 2018
@ghost ghost removed the in progress label Mar 21, 2018
@jhermsmeier jhermsmeier deleted the patch-1136 branch March 21, 2018 22:37
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

Successfully merging this pull request may close these issues.

5 participants