GTK3 Progress

[mmstick]

I might could pull it off in a short time frame, if you'd like to have a GTK3 interface, in addition to the CLI.

[jackpot51]

Yeah, that would be great!

[mmstick]

Alright, I'll send over a PR soon which splits the project up into a library, a CLI binary, and a GTK binary. The GTK binary will be a dummy at first, though, but I'll immediately begin working on the GTK interface after submitting the PR.

[mmstick]

Didn't get to spend much time on it today, but this is what I've got thus far:

[WatchMkr]

Nice start! Let's give it a GNOME 3 feel similar to the screenshot utility. (My symbolic images are awful but I'm sure we can find better ones).

[WatchMkr]

Thinking through this a bit more, changing the button to the file name/drives is a bad idea. We can try adding the image name and drives under the button once they're selected that way the user can press the button again to change the image or drives.

[mmstick]

@WatchMkr Thanks! I'll look into this later today. Only got to spend about 30 mins ~ hour on the GTK binary yesterday.

[jackpot51]

[jackpot51]

That is @cassidyjames quick suggestion. Symbolic icons and default color scheme as @WatchMkr suggested, and I think we are all on the same page

[WatchMkr]

Why are we not using GNOME 3 header bar? This does not match the design of other GNOME apps.

[cassidyjames]

My sketch was super simple and not supposed to be taken pixel-by-pixel. :P We could easily add a headerbar, and having the Flash button in the headebar might work. My only concern with that is that this is a closable window, so the close button goes in the far-right headerbar position, and an affirmative Flash button might look awkward there.

I think the screenshot tool is a parentless dialog, which is explicitly discouraged in the toolkit. Initial Setup is not closable, so it doesn't have the problem of the affirmative button and the close button fighting for space.

[cassidyjames]

Spec being hashed out per @WatchMkr's request at https://github.com/pop-os/muff/wiki/GUI-Design

[mmstick]

@cassidyjames Tell me when you're finished with the spec, and I'll quickly implement everything w/ gtk-rs

[cassidyjames]

@mmstick first two screens have been more specced out. Working on the last two.

[cassidyjames]

@mmstick alright, I think it's ready for you. Hit me up if you have any questions.

[mmstick]

I'll start on it soon, once I finish up with the distinst-related stuff I'm working on at the moment.

[mmstick]

Made some initial progress. Moving forward will set the animation to right to left, and moving backward will move from left to right. The next button is set to sensitive after an .iso or .img is selected (which are filtered in a file chooser dialog). Not currently displaying the ISO path after it is selected, or setting the hash yet. The devices screen also isn't implemented beyond the image and description.

Source code is available here.

[jackpot51]

Looks good!

[mmstick]

Made a little more progress. Hashes for MD5 & Sha256 are working.

[jackpot51]

I am not sure the generate button is necessary, if it can regenerate when the selection is changed

[cassidyjames]

I might learn how to use GTK in Rust and poke at some margins, but this is looking great!

[mmstick]

@cassidyjames This might be helpful. I was working on it shortly before getting hired: https://mmstick.github.io/gtkrs-tutorials/

[cassidyjames]

We discussed the hash a bit, and I did some thinking about how to avoid the performance hit of calculating unless the user explicitly wants to, without adding too much crazy UI. Here's what I came to:

This would be a grid with a right-aligned Hash: label, then a dropdown button linked to an entry (I think this is supported in GTK and our stylesheet, if not, let me know).

The dropdown label would be Type by default, and the menu would have all the accepted types in it. Selecting a type should change the dropdown label to match the type and begin calculating a hash.

While calculating, we should pack a spinner in the entry's primary icon location. The entry should be non-editable, monospace, and have a width request of the maximum length a hash would be (that way it's predictable and shouldn't resize the window when the has loads.

Let me know if that doesn't make sense or work out. I'll also add this to the wiki.

[mmstick]

Device selection & flashing works, but the progress & summary views aren't fully implemented yet.

The devices are populated once that view is opened, but it doesn't yet perform any live updates to update the list, so it will only update if you go back and click next again.

Changes were also made to the image selection view, which now preloads the ISO in RAM in advance, and only calculates a hash (using the in-memory copy of the ISO) when a hash is selected. Haven't yet added the spinner though.

[jackpot51]

Looks good @mmstick!

[mmstick]

Spent a little time on this today, and was able to get the multiple progress bars working in the progress view, as can be seen. One of the three flash drives is USB 2.0, while the other two are USB 3.0. It's easy to tell which one is USB 2.0.

Used a GTK Grid for the view, and Arc'd atomic integers for storing intermediate progress values.

[mmstick]

Spent some time refactoring the code base, and then improved the styling in the progress view. Also added labels to show the rate of each device being flashed.

[mmstick]

Here's a GIF of the program in action, as it is now.

[mmstick]

There's now a .desktop and .policy file that gets installed, and it's possible to set the GTK app as the default application for opening ISOs. The write rate label has also been improved.

[jackpot51]

That is looking good @mmstick , it is time to merge.

[jackpot51]

I have merged it. Future GTK3 items will be handled in separate issues, on the master branch.

[mmstick]

@jackpot51 Thanks!