I'm more interested on how packageable it is. Will we get it in a state were it builds sanely? If it's only available as snap and distros don't package it because it builds as horrible as electron for example, I don't think it will gain a lot of traction.
Announcement
Collapse
No announcement yet.
Canonical Continues To Talk Up Google's Flutter UI Toolkit
Collapse
X
-
Originally posted by kpedersen View PostCode:Widget titleSection = Container( padding: const EdgeInsets.all(32), child: Row( children: [ Expanded( /*1*/ child: Column( crossAxisAlignment: CrossAxisAlignment.start, children: [ /*2*/ Container( padding: const EdgeInsets.only(bottom: 8), child: Text( 'Oeschinen Lake Campground', style: TextStyle( fontWeight: FontWeight.bold, ), ), ), Text( 'Kandersteg, Switzerland', style: TextStyle( color: Colors.grey[500], ), ), ], ), ), /*3*/ Icon( Icons.star, color: Colors.red[500], ), Text('41'), ], ), );
Not to mention the next task will be to bind the C++ code that people use to actually write software to sodding Dart. This is a very awkward workflow I must say.
Are there any flutter users here that have also used a standard GUI toolkit to compare against? It would be really interesting to hear why they like Flutter. I feel like I must be missing something!
Whether we're talking a Java UI SDK, CSS, Flutter or whatnot, you still need to be able to specify layout, positioning, alignment, margins, insets, colors...
- Likes 13
Comment
-
-
Originally posted by t.s. View Post
Could you share whats the minuses of Qt toolkits? As i know, they're qute easy to use, and you can choose to separate UI/UX with logic, or half-combine that.
* C++ sucks, and I mean it. Because Qt has an asynchronous event model combined with custom object system and ownership prepare for tons of memory-related issues for anything bigger than hello world.
* There are bindings for some other languages in different maturity states but in general it's pretty hard to bind anything to C++ FFI.
* The need for the moc compiler, so the sources are plagued with non-standard language extensions and macros. I think there is a 3rd-party library to partially overcome this.
* The framework itself is huge. It's not practical to build any custom version of it for a particular purpose.
* Packaging and deploying is a PITA. Tons of dependencies, plugins, helper files that must be assembled properly. And the resulting bundle is quite big.
* The WebEngine is based on Chromium, so pulls another 50MB if your application uses web views. It doesn't support MinGW compiler which forces a complicated set of separate build scripts for Windows/Visual Studio and *nix systems with clang/gcc.
* LGPL or very expensive license, which limits it in some contexts. This is highly subjective though.
* Qt Company is not very fast in fixing reported issues.
- Likes 12
Comment
-
Yeah, let's all get on board with another GUI framework written in a web technology [/sarcasm]
I wish these idiots would use proper tools, or to put it another way, actual systems programming languages. Web technologies suck. GC sucks.
We're just throwing performance down the drain because people won't learn to program properly in something like C, C++, or even Rust (not a fan of Rust myself, but at least it's a proper systems programming language).
- Likes 10
Comment
-
Originally posted by kpedersen View PostDo people find this particularly good to lay out 3 trivial components in a classic row / column container? Now don't get me wrong, even an ancient toolkit like Motif had its own issues but it seems to look elegant in comparison.
Practically speaking, behind the scenes GUIs are a whole lot of linear algebra equations so your only choices are between heavily nested JSON/XML for interface description languages or heavily functional (and possibly nested) functional DSL that do both the description and the logic. The latter is what people did with latex and tkinter. The former is what people been trying to do since the 90s with HTML and the likes. Both approaches had their hits and misses. The underlying issue is that that C/C++ are uniquely poor at manipulating binary trees due to their imperative syntax so whatever it is you come-up is going to be a bad compromise between performance and convenience.
Rust's generics are a bit too verbose for the job. Dart is close but doesn't really perform all that well. Go recently approved generics might hit the mark but that will take half a decade to flesh out...
So, meanwhile, flutter I guess :/
- Likes 8
Comment
-
Originally posted by kpedersen View PostCode:Widget titleSection = Container( padding: const EdgeInsets.all(32), child: Row( children: [ Expanded( /*1*/ child: Column( crossAxisAlignment: CrossAxisAlignment.start, children: [ /*2*/ Container( padding: const EdgeInsets.only(bottom: 8), child: Text( 'Oeschinen Lake Campground', style: TextStyle( fontWeight: FontWeight.bold, ), ), ), Text( 'Kandersteg, Switzerland', style: TextStyle( color: Colors.grey[500], ), ), ], ), ), /*3*/ Icon( Icons.star, color: Colors.red[500], ), Text('41'), ], ), );
Not to mention the next task will be to bind the C++ code that people use to actually write software to sodding Dart. This is a very awkward workflow I must say.
Are there any flutter users here that have also used a standard GUI toolkit to compare against? It would be really interesting to hear why they like Flutter. I feel like I must be missing something!
- Likes 7
Comment
-
Originally posted by c117152 View PostRust's generics are a bit too verbose for the job.
- Likes 8
Comment
-
I am strongly against using web-derived technologies for desktop (and mobile for that matter) applications. Yes, it is easier and quicker. But soon we will need 256GB RAM and 128 cores to lift 682 instances of Chromium running concurrently. Each time I see the next Electron application I want to scream.
I didn't manage to build an example Flutter desktop application due to missing Chrome (my distro has only Chromium), so I assume it might be something "electronish".
EDIT: I did manage to compile an empty desktop app on my OS (Void Linux) with Chromium as Chrome.
FFS, 54MB application to count button clicks, flickering furiously when resizing window and taking 44% CPU and 131MB resident memory sitting idle? That's the future Canonical is seeing for Linux?Last edited by Pyth0n; 19 March 2021, 01:46 PM. Reason: Fixed - successfully compiled empty demo application
- Likes 18
Comment
Comment