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.
1 Like
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 ?
Thanks!
2 Likes
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.
12 Likes
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.
4 Likes
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?
1 Like
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 en_BE.
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”?
3 Likes
+1
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)
2 Likes
Hirsute Hippo is the version under development that will become Ubuntu 21.04.
2 Likes
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.
2 Likes
I found Arabic is missing from languagelist and I make PR to add it
ar_EG, ar_SA
Hmm… That list is very short even if Arabic gets added.
1 Like
that correct, if they do like google android in setup guide
first choose the language then choose the region/country will be better
2 Likes
Hello,
Yes i’am familiar with github, i am going to submit a PR.
Thank you.
1 Like
I don’t know if this is going to be the correct place to put this, but the most important feature to add is the ability to resize the installer window. I have a 1440p monitor, and a number of disks, and it’s an absolute pain using ubiquity to sort out the disks during install. I should be able to see them all at once, especially on such a large screen, but the inability to resize the window makes me feel like it’s still 2010.
3 Likes
Done. thank you very much
Good day.
Could you please make sure that the new installer allows and provides the use of explicitly selected EFI partition (meaning non-default one which could be occupied by some foreign OS)? Ubiquity now ignores user settings on that: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1822464
Also, it would be a nice if you add support for encrypting user’s home directory with fscrypt as a modern and more secure replacement for long ago deprecated eCryptfs. For those who still prefer ext4 and f2fs. If working on it, this should be taken into consideration as well: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1889416
As long as this feature of Ubiquity remains https://wiki.ubuntu.com/UbiquityPreserveHome, so I can still do this procedure to rescue borked installs, I’m fine with the change.
1 Like
Where is the problem when other operating systems are using the same EFI-System-Partition?
I think many people don’t want any operating system to silently overwrite some other OS’ boot files. Using separate $ESPs is an easy solution to that, but it’s not possible (using Ubiquity installer means), so that’s the problem you asked about. Also, it is “allowed” by Ubiquity atm, at least GUI option is present. What I’m taking about is that that option actually doesn’t work.
There were cases when Windows overwrote Ubuntu’s loader in BOOT/BOOTX64.EFI. Also, out of all major Linux distros, Ubuntu is the only one which has such bug in the installer. All others have no problem with following user’s preferences during the install procedure.
I am not aware of any operating system, which is overwriting the primary boot files of Ubuntu. And I am not aware, that Ubiquity is overwriting the primary boot files of other operating systems.
Are you sure, that all UEFI implementations are handling several ESPs correctly? If a firmware detects an ESP on the first disk (excluded removable disks), why should it search on all the other disks for existing ESPs?
And what is with the boot entries in the NVRAM? Some firmware implementations are updating boot entries, some do not.
\EFI\BOOT\bootx64.efi is a default file name and used for removable boot devices (UEFI spec 2.8B chapter 3.5.1.1). You cannot expect, that \EFI\BOOT\bootx64.efi is not overwritten.
Ubuntu is using \EFI\ubuntu\shimx64.efi and \EFI\ubuntu\grubx64.efi and other operating systems are not overwriting these files (if they are not official Ubuntu flavours).
I don’t see this as a bug. Using an existing ESP is normal, less confusing and I would say also the expected behaviour.
1 Like