Would be great if this incorporated an option to use systemd-boot. GRUB2 is so slow!
Looks promising. I take it the Yaru theme for Flutter is still in development? Material Design looks a bit out of place for a system installer.
Prototypes showing off the localization, YES! Hopefully 2021 will be the year of seamless East Asian localization support
Thanks, does this change fundamental things underneath? I hope that the EFI partition choice bug gets fixed one day https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379
I too feel like flutter would be out of place.
No need to force it just to showcase it, GTK would be just better and more consistent
@Wimpress This is great news. Since the switch to Flutter might impact the flavo(u)rs and remixes out there, I have a few questions about
ubuntu-desktop-installer (the new installer):
- Will it allow custom theming for the distributions? (other than official flavo(u)rs, like remixes and derivatives like Linux Mint and non-Ubuntu-based distributions, as it will then be a viable cross-distribution alternative to Calamares)
- Will it operate properly on QT desktops? (there are many UI glitches that occur when using applications that use the Flutter toolkit on QT desktops like KDE)
- Will it allow custom slideshows? (as it is possible with Ubiquity)
While I understand using new tech is exciting and all I think flutter is not the right choice for this particular job. The installer does not need to be cross platform, the apps don’t look anything like the rest of the Ubuntu session and Google has a way of abandoning projects such as these. Is there any reason it can’t be done in GTK4?
I for one think Flutter is a great choice here. It will encourage other developers to use it to create Apps for Ubuntu given a very core part of the OS will be using it. Flutter as first-class citizen FTW!
Also I think people need a bit more practical when they say “Flutter is snap-only”. Snap, just like any other packaging format is an application delivery container. Flutter is open-source software. Anyone wanting to run a Flutter based app on their desktop can do so, with a little bit of effort.
I can see great things happening
I am a Kabyle localizer, I am a contributor on the translation of Ubuntu into my native language wich is Kabyle on https://launchpad.net/ubuntu.
and I already see an error on the screen shot of the new installer, the native name of the Kabyle language is : “Taqbaylit” not “Tamaziɣt Taqbaylit”, please can someone tell me where to report this error? thank you.
I don’t understand this move. Why not leveraging the work being done upstream in GTK4 (or even GTK3) for example? Flutter is still a baby in the Linux desktop scene, and it does not look as native as GTK4 or 3 under GNOME.
Thanks for reporting this @slimaneamiri1. The list of languages comes from the subiquity project, would you mind filing a bug in Launchpad, and/or if you’re familiar with git and github submit a PR ?
Note that Flutter uses GTK3 on the Linux desktop.
For the same reason that so many Electron apps exist: it’s easier for developers.
As a user, I really like GTK3/GNOME applications. They often look great, respond quickly and are really easy to understand. As a developer, however, I find it very hard to use. It has a steep learning curve and has all the issues of a niche project without strong commercial backing.
So what’s the alternative? Electron?
Flutter is a great compromise: it’s almost as easy to use as Electron, but it creates native binaries and has native integration with GTK. Given that Google pushes it so much, there is a high chance that many developers will know how to use it.
So, in the context of “we want more people developing apps for Linux”, I think this is a great decision. With such a core part of Ubuntu using Flutter, Canonical will be forced to make sure Flutter works great on Linux. This has the potential to get a lot more people contributing to Ubuntu and developing apps for Linux.
One think I’d like to see improved is smarter language selection. In Ubiquity, if I select English as language and select Brussels/Belgium as my timezone, my dates are in German. In the installer, there is no way to see this will happen and no way to change this.
In hirsute that combo will result in Dutch dates due to bug #1907914. Please also see the discussion at that bug report. What would be the “smarter” solution in your opinion?
Using Dutch is an improvement over German. Creating
en_BE seems like a good long-term solution to me and makes sense given the high number of English speaking people in Belgium. I’m personally using
en_IE but there is still some difference with
I think that including locale selection in the UI makes sense too. I disagree with the statement that this is an isolated case. From my experience, many people use English as the language in Ubuntu even though it’s not an official language of the country they’re residing in. I think the current approach of “timezone == locale” is too simplistic and I think it’s very easy for people to grasp what a “regional format” is. Especially when you include an example like this:
PS: what is “hirsute”?
Pretty much the same situation for me. As a Java Dev I find gtk pretty weird to say it the nice way. But I think more than the toolkit the problem is a missing proper IDE. Gnome builder is okay, but it lacks many features compared to intelij, eclipse and even compared to vscode.
For example flutter snap + Vs code + flutter extension feels like Java in eclipse just faster.
As far as I understood the licenses, flutter and dart are a more “free” than Qt.
(Could be wrong though)
I think that this is a good alternative to pure gtk and gives room for nice cross platform desktop apps that now can easily target the Linux desktop, too.
Also I don’t see a reason why Gtk3/4 and flutter apps shouldn’t co exist in Linux. I use an electron app (vscode) at least 60% of the day, 30% Thunderbird and Firefox and 10% gtk apps (basically only GCC, Nautilus and lutris)
Hirsute Hippo is the version under development that will become Ubuntu 21.04.
Ok. I usually describe the “timezone == locale” approach as the installer making a guess of a reasonable locale. But I suppose the new installer is a good opportunity to reconsider it, and allow the user to select regional formats explicitly.
I found Arabic is missing from languagelist and I make PR to add it
Hmm… That list is very short even if Arabic gets added.