Prototype for Modernized Fedora Media Writer

Project Discussion
,
1

Fedora Media Writer Modernization

This DESIGN PROTOTYPE[1] is a WORK IN PROGRESS

TLDR.

I have been learning QML[2] during my OOO time[3] and I worked on a prototype of modernized Fedora Media Writer for practice, that I wanted to share here. The technology felt intuitively powerful that I was able to cook great things in a relatively short period. It made me wonder just why we are not revamping the aging Fedora Media Writer application experience to be more welcoming. I think, we should use this opportunity!

While most of us have their hands filled with work, I want folks to have this at the back of their minds and we can probably get back to it six-seven months[4] time. What do you think @jflory7, @jspaleta, @ekidney, @madelinepeck, @theprogram, @lochipi, @fatherlinux, @blc and others interested? How can we help push the Fedora Linux adoption in the desktop market, and hopefully get some contributors along the way?

Animation

anim

Full animation is massive.

Motivation

This design prototype is an exploration of what Fedora Media Writer could potentially become. It is neither a final design nor a demand for change. It is a conversation starter – a concrete documented reference point for discussing modernization with the upstream maintainers, and the wider community. All the things done here are subject to revision, and the goal here is collaboration, not prescription. To add to that, this has been a learning experience for me since I learned QML recently.

First impressions really matter

For a vast majority of folks here, Fedora Media Writer is the very first point of interaction they have with Fedora Project. It is the gateway through which curious users take their first step into Fedora Linux ecosystem, and therefore to the Fedora Project community too. That first impression around the look of
the tooling and the feel of the experience shapes whether someone walks away excited to explore further or is discouraged before they even boot into the live Fedora Linux environment.

Most of the people who contribute to the Fedora Project community had started off as Fedora Linux users first, and arguably, most of those users arrived via Fedora Media Writer. If we want a thriving community and a welcoming space, it is in our best interests to get this moment right. A hospitable and intuitive
beginner’s experience signals that Fedora Project values efforts spent in the out-of-the-box experience that leads to the user potentially wanting to become a contributor in the community.

Emerging case for modernization

The experience, in its current state, while functional, feels archaic. It tries to feel at home across various platforms using the default Qt platform styling, which means it never quite achieves that on any platform, i.e. neither across desktop environments nor on proprietary platforms. Rather than playing catchup with the look and feel of every platform, a thoughtfully designed custom-built interface can deliver a consistent and polished experience that establishes the Fedora Project brand identity.

Beyond the (immediately noticeable) visual appeal, there are authentic user experience improvements that can be made, Better information hierarchy, clearer navigation through variants, current affairs of the Fedora Project community, and a design language that communicates approachability – these are the changes that make a tool genuinely easier to use, not just prettier to look at. Along with those changes, we can also use this opportunity to onboard contributors to maintain the project codebase.

Illustrations

  1. ↩︎

  2. Departing from QtQuick nightmare ↩︎

  3. Bad example - Please do not follow ↩︎

  4. Did you see what I did there? :stuck_out_tongue_winking_eye: ↩︎

3 Likes
2

This really is a graphical update, very much moving on. I would in general support it.

What I really like in your prototype is that there is much more information on screen.

Perhaps we could provide a very short bio or link to a bio of each edition or spin?

With such an amount of information, we should make sure that the software will still work on the lowest callible monitor anyone may have - which would probably be a 720 screen.

Some questions to answer before proceeding:
Who currently maintains the existing Fedora Media Writer. If there is an active team we should def loop them in ASAP.

Is the technical backend the same? Are you building a new GUI around the same process, or reinventing it?

Where does the list of Editions, Spins etc come from? Is it pulled dynamically or hardcoded?

3

The current team that “owns” Fedora Media Writer is the Fedora KDE SIG, through its Fedora Qt efforts. @jgrulich is the current main maintainer.

1 Like
4

Yeah, I am trying to ensure that the information is presented in a way that helps the incoming users make an informed decision of which variant of Fedora Linux they would want to go for (and why). Take, for instance, Fedora Workstation might not always be the objective best choice, so maybe providing a dynamic screenshot slide deck, could be in order here for whenever a user hovers or selects a variant.

For sure, the default size of the window is 480p and it is responsive across various display environments. Dragging to resize or using keyboard combinations work too, but I also plan for assistive technologies.

@jgrulich has been the first person that I had reached out to on this, on an internal chat. I wanted to have an understanding of both the interest in such a revamp project as well as the time that we could dedicate.

The backend is the same. I mean, why fix things that are not broken right? Fedora Media Writer already makes use of C++ and QML so this would only add new useful things to the existing functionality.

At the moment, it is hardcoded because it is barely a prototype. I wanted to bring something up for folks to have discussions about and workshop ideas on before going all guns blazing into the actual work. The last thing I would want to do is waste folks’ time and effort into something that we do not necessarily need or have the time to maintain, and hence, it is crucial to steer ourselves to the direction of the wind blowing.

If you have folks who are into user interface designing/development or they might have something to say about this, please feel free to share this with them too. While both @jgrulich and I might not have the time at the moment to go into it at the moment, I do not necessarily want to kill the project. Maybe we can come back to it at a later point in time or better yet, this can help someone else get started with this.

1 Like
5

new-writer

Hi i have seen the the post and find it a nice idea to implement it. I have chosen not to use qt, i have not worked with it and instead used rust iced. Some limitations still exist in my prototyp because of this, like a blur. But the rest looks fine. The translation is in the work, most has ki done until now in this front. The repo is https://gitlab.com/MythicByte/new-writer and for the backend Markus Götz / flashkit · GitLab . The application works on Linux,Windows and macos in theory. Only Linux and Windows was tested. The library implements it, but i have no testing device for it. The app downloads the release.json and translate this, which should be later optimized for local mirrors. The Sha256 is checked two times like standard, and one is for custom there is the hash derived and then checked later. I plan for using in the custom Iso to use Blake3 and not Sha256 in the moment. Because it can have until to 7gb the second scan and sha256 like 500mb. The security level is mostly the same. I have added animations to the screen. I have not figured out how fedora media writer or balena etcher can write on windows without starting in admin mode, if you have a idea please let me now. The minimum space constraint is checked and looks good even on wide monitor screen, i have tested this on my own. The custom theme from iced i have integration but the two main themes are toggled, in the advanced settings.

I would like to have feedback and your opinion on it.

home-light
home-light1011Ă—617 128 KB

home-dark
home-dark1011Ă—617 125 KB

first-light
first-light1011Ă—617 161 KB

first-dark
first-dark1011Ă—617 159 KB

download-light
download-light1011Ă—617 98.1 KB

download-dark
download-dark1011Ă—617 84.3 KB

danger-light
danger-light1011Ă—617 103 KB

danger-dark
danger-dark1011Ă—617 88.8 KB

2 Likes
6

The application is something about 20mb big(release build). The verification blink animation has some async problems, where the fade does not happen or when a new message appears. But not with the flasher animation, but they use the same function.

7

Hi @t0xic0der

This is an amazing initiative! Huge appreciation to you for spending your OOO time learning QML and channeling it into something that directly benefits the Fedora ecosystem.

The idea of modernizing the Fedora Media Writer is spot on. As the first tool many new users interact with when joining the Fedora family, having a fresh, welcoming, and intuitive UI/UX is crucial for driving desktop market adoption. Your prototype is a great catalyst for this discussion.

8

I’ve been thinking about how we could make the media writer even more seamless and accessible, perhaps something inspired by a lightweight WebUI approach (similar to Ventoy).

image
image1368Ă—699 88 KB

“Imagine a user just opening a browser, accessing a clean web interface, and preparing their installer media from there.”

However, implementing this purely remote/web-based brings up some fascinating technical challenges:

  • Local Hardware Access: Browsers have strict sandboxing rules, so accessing and writing directly to local USB/flash drives would likely require a small local background agent or a specialized browser extension/plugin to bridge the web UI with local disk management.

  • Image Size & Bandwidth: Loading a multi-gigabyte ISO over the web to write it locally could be heavy. Though, as a workaround, we could potentially leverage a minimal image/network installer footprint to keep the initial load times and resource usage as low as possible.

It might complicate the architecture a bit compared to a standalone QML desktop app, but a web-first or hybrid approach would definitely be a game-changer for accessibility.

What are your thoughts on handling local storage access for something like this?
@jflory7, @jspaleta, @ekidney, @madelinepeck, @theprogram, @lochipi, @fatherlinux, @blc

1 Like
9

I love the idea of a web based installer, but to be honest, I don’t understand how that works. Could you unpack that or give me bit or a rundown?

It looks like we have two willing contributors here on this now, going in different directions. You two should set up a meeting wirh @t0xic0der and agree on a collaborative effort.

@mythicbyte why Blake3? I’m no crytpo expert, with no disrespect, I would love to see a FESCO opinion or other long term specialists opinion on what algo to use.
I do very much like your version, it looks fantastic. Great work.

1 Like
10

A nice UI would be cool to have. Don’t mean to pour cold water on this, but just as a reminder, the biggest issue with the Media Writer by far is that it produces a bootable USB with a broken media check: Install media sometimes fail media check at 4.8%

1 Like
11

That happens when Windoze mounts the drive again after the image has been burnt and ejected.
It would be a fantastic fix in the new version.

Anyone got ideas about how to preserve the integrity of the burned iso?

12

Over the past months, the community finally narrowed down the exact cause for this. Some potential strategies have been outlined, but not implemented yet: 2420697 – Install media sometimes fail media check at 4.8%

1 Like
13

Not sure, but Rufus (dd) and Etcher’s been seemingly fine (I wrote Fedora/etc images for years from Windows and only FMW had inconsistencies)

Etcher doesn’t seem to unmount the drive immediately after writing, but iirc Windows can only see the FAT32 EFI partition (not sure if Windows can affect ext4/ISO partition without native R/W?)

14

Will try to look into it. Good point

15

For Blake3 look here https://discussion.fedoraproject.org/t/switch-from-sha2-to-sha3-or-blake3-for-better-security/153575, the points are good summarized there. You can try the new version out made a release for it, note on windows needs to be run as admin and in the moment does not ask for it. Uses now the mirrorlist and async if a device was inserted or removed.

16

I did not expect the thread to have so many responses almost after a month’s time since the previous response but I suppose there is a first time for everything here. First things first, @mythicbyte - amazing work on the functional prototype. I have not yet gotten the time to take it for a spin locally but from a skim of the source code, it looks pretty cool. Admittedly, I know next to nothing about Rust but it still looks impressive.

Like not just in the actual codebase but also in the spirit of free and open source software, you took the baton passed over by me and built something amazing on the top of it. I also got a lot of inputs from my Reddit posts on r/Fedora[1] as well as r/CoolGitHubProjects[2] that I have not yet been able to incorporate as apart from the Fedora Forge development and Fedora Badges mentoring, we do have Flock To Fedora 2026 in the horizon.

@g4ridwan, thanks for your kind words! I do plan on keeping this strictly desktop native though, since as you mentioned, both the storage permissions (sharing that with a complete browser) and binary sizes (bundling a browser in the binary) could be a major struggle. I do know of the Chromebook Recovery Utility[3] that does something similar to what you have in mind using the JS V8-exclusive[4] WebUSB API[5].

@yurislnx, good point. The reason why I have yielded the baton and/or put this initiative on ice now is because apart from finding some free time, I also want to look into the foundational problems of the codebase in its current state. As much as I want to redo the user interface of the application project, I really do not want that to come at the cost of a complete rewrite as that would be rather wasteful of time/efforts.

@Espionage724, it might be worth exploring both Rufus’[6] and Etcher’s[7] codebases to understand that they fundamentally do differently than Fedora Media Writer. While being written in different programming languages, there is certainly a lot we can learn from these toolings to understand what could best serve our interests. I do plan on getting do this but it would most certainly be a long while before I can commit to it.

  1. ↩︎

  2. ↩︎

  3. ↩︎

  4. ↩︎

  5. ↩︎

  6. ↩︎

  7. ↩︎

1 Like
17

You’re absolutely right about the binary size and storage permissions or similar wrappers can get heavy real quick for this kind of use case.

Thanks for pointing out the Chromebook Recovery Utility and the WebUSB API, that’s a really interesting reference point for how they bypassed some of those limitations.
I do wish someone out there could help build a web-based media writer similar to the Chromebook Recovery Utility someday.

Anyway, looking forward to seeing how your project evolves!