441–450 of 453 posts
Earlier quoted context omitted.
So interesting, even after years of doing QML, layouting with widgets makes for me much simpler to get what I want
QtQuick Controls 2's QML widgets, along with whatever KDE's MauiKit QML widgets are called now, might suit your needs.
Earlier quoted context omitted.
There is no real reason to have basic enums if you have ADTs , since those can easily provide everything a plain enum gives you. I guess the name was just a historical artifact.
I agree (that’s what I meant under the more expressive part), though it is a bit more complex with identity in the way. Java’s enums are also the singleton pattern. Java recently got ADTs as well in the form of sealed classes and records, here an enum would look like this: sealed interface Color permits Red, Blue, Green { } record Red() {} record Blue() {} record Green() {} You can now create as many Red instance as…
Earlier quoted context omitted.
How is it not a problem if you want to sell closed-source software? I guess you can dynamically link desktop applications (although I'm not sure how this works in Apple's Mac app store), but you can't do that with mobile apps.
If you to sell closed-source software be a good boy/girl and give part of the money pile to Qt developers, so that they keep working on Qt.
Earlier quoted context omitted.
How is it not a problem if you want to sell closed-source software? I guess you can dynamically link desktop applications (although I'm not sure how this works in Apple's Mac app store), but you can't do that with mobile apps.
LGPL is not about dynamic linking, and there are plenty of LGPL (and even GPL) apps in the Apple, Android, Mac and Windows app stores. Like, Chromium itself is mostly LGPL and it's never an issue for electron apps, why would it be for Qt ones
Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere. Apart from Qt , but the licensing issue is a hindrance. And yes, the web backend isn't ideal, but it will improve over time. I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Dart isn't horrible and is getting better,…
I thought I would hate Dart since it seems like such a bland language but after working in it for a year and a half its easily one of my favorites. Its straightforward and tailored directly for Flutter's use-cases. It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages. It is also incredibly readable without hiding how it works behind decades of syntactic sugar. All that to…
Earlier quoted context omitted.
LGPL is not about dynamic linking, and there are plenty of LGPL (and even GPL) apps in the Apple, Android, Mac and Windows app stores. Like, Chromium itself is mostly LGPL and it's never an issue for electron apps, why would it be for Qt ones
LGPL IS about dynamic linking if you don't want to release your source. That's the workaround.
Earlier quoted context omitted.
Google doesn’t think it’s own cross platform framework is good enough for its own applications https://9to5google.com/2021/10/10/google-ios-apps-native/
> The company’s official guidance to past developer users is to “follow Apple’s Human Interface Guidelines and consider using modern UIKit components or SwiftUI instead.” That said, it also plugged Flutter as the way to “get a Material look and feel across all platforms.” Doesn't seem like the article you linked accurately represents your statement.
Earlier quoted context omitted.
Thanks for reporting this. IME-based input is super important to me -- we only speak Japanese at home. I've filed a bug [1]. I manually tested on each of Windows, macOS, Linux, and iOS (where I've done a lot of work specific to CJK input) and was able to correctly input Japanese, Chinese, and Korean text [2], so looks like this is likely an issue specific to Flutter's web runtime. I work on Flutter's desktop embedder…
Fixing that one bug won't fix the plethora of issues * emoji is not the system emoji. * neither the browser's nor the OS's spelling error highlighting works (the place I have my own words registered) * reconvert and other IME options don't work just to name a few. Just please stop with the canvas rendering!
Earlier quoted context omitted.
> While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants. As much as I like Rust’s enums, I think they messed up on the naming. Java (and according to your comment, Dart) gets enum rights. What Rust has under this name is sum types, which is a separate (more expressive) concep…
I disagree. "Sum" and "product" types are really really unclear names that only make sense if you've studied some advanced CS and even then they're bad names - not descriptive at all. Enum is much better - you just enumerate all the values the type can be (plus optional associated data).
For the record, algebraic data types get there names from the fact that the “number” of instances that are under a given type gets added or multiplied together. Let’s say we have a ColorChannel “enum” of R, G, B. That is there are 3 instances ever under this ColorChannel type. Let’s create (with some syntactic sugar) an 8bit unsigned int which has exactly 256 possible instances.
Now create a Pair (ColorChannel, u8) type. This will be a product type, since the number of possible constituents is 3x256.
Let’s look at the often used Option type, which wraps another type. This looks something like enum Option { Some(T), None }
We have two possible types here, but one can contain T possible types. So Some(T) is basically a product type of 1 other type, resulting in it holding that type’s cardinality, while None has a single instance — the Optional sum type thus has card(T)+1 possible instances.