Greedy writing mode #951
Comments
|
This is what we've done for the "headless Etcher" hack at the summit, so we have a clear idea about what it takes already. We have everything needed technical wise, so I'll mark this issue as "pending design" so we can start discussing how this would work UX-wise. /cc @konmouz |
|
I think having it automatically write to any removable drive it detects sounds far too risky! 😨 I guess if you're using an SD card-reader, it might be "safe" to select that as the drive in Etcher, and then have Etcher write the selected image to the drive every time it detects that you've (removed and then) inserted an SD card. (which obviously only works for those SD card-readers where the whole device doesn't disappear when you remove the SD card. If the SD card-reader device disappears, we can't know that the next time a removable device reappears if it's the same SD card-reader and not a USB harddrive (unless we start getting down to the USB VID/PID level...)) |
|
The definition of the target is certainly sth to think about |
|
Sounds risky indeed but also very effective. |
|
I'd like to investigate ways of making it safer while keeping it effective.
In particular, perhaps a "new medium detected in slot X, starting write in
5...4...3... (abort button)". Another would be to only do that if the
target medium is blank, as in mass-production situations you'd most
certainly be using new cards.
In fact... come to think of it... what if Etcher auto-wrote to blank cards?
In general? Can anyone think of any downsides?
…--
*Alexandros Marinos*
Founder & CEO, Resin.io
+1 206-637-5498
@alexandrosm
On Wed, Dec 7, 2016 at 9:10 AM, Konstantinos Mouzakis < ***@***.***> wrote:
Sounds risky indeed but also very effective.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#951 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABLUCHc8MnC9qllycMj-2hqmijwc9TDrks5rFnf2gaJpZM4LFwx4>
.
|
|
A small notification says that we're about to write to that drive kinda mitigates that risk IMO. |
|
How do you define a "blank" card? All new SD cards that I've seen come pre-formatted as FAT32 / exFAT. I guess if we're going to show a countdown-alert, then we'd need to ensure that Etcher jumps to the foreground and doesn't just display the countdown in the background ;) |
Yeah, cards without file-system are rare. In the case of FAT, we can use something like https://github.com/natevw/fatfs to actually see the files inside. |
|
If we go through the flow of displaying a notification modal, then we can have a confirmation CTA. It is kind of an extra step but can help to avoid trouble. Plug the new drive, get a modal in foreground with 'proceed' and 'abort' CTA. |
|
The first post in this thread says "with no etcher-clicking required" ;-) |
We can show a small modal with confirmation/cancel icons in the form of a notification (like OS X does), but still default to just write if there user doesn't says anything in X amount of seconds, so we get the best of both worlds. |
|
Agreed |
|
...and that would also allow impatient users to click 'Continue' if they don't want to wait for the timeout to expire ;-) |
Would there be a way to put Etcher into a mode that will have it automatically write an image, with no additional interaction, to any removable media it detects? This would make writing multiple cards much easier, by just waiting for the OK and then inserting another, until done, with no etcher-clicking required.
This is another Hard Etcher motivated feature.
The text was updated successfully, but these errors were encountered: