161–170 of 224 posts
Earlier quoted context omitted.
I mean it's not primarily a web app framework, it's a native GUI toolkit which has a web back-end.
It isn't native on any other platform either.
Earlier quoted context omitted.
First comment on that Reddit thread: --- Hey folks! Kevin, product manager on Flutter and Dart here. The layoffs were decided AT LEAST a couple of layers above our team and affected a LOT of teams. (I think I can say that). Lots of good folks got bad news and lots of great projects lost people. Flutter and Dart were not affected any more or less that others. It was a tough day...tough week. It was crazy to be seeing…
Building anything on top of Google tech that isn't Android or GMail is a huge risk, and the fact that the higher-ups will just randomly decide to fire large parts of teams confirms that caution is the right approach.
Earlier quoted context omitted.
Ah, so extremely localized uses of pointers, got it, thanks.
More or less, yes, but it doesn't have to be extremely local. Here's a variant of the example that introduces a function call boundary: https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename...
https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename...
Earlier quoted context omitted.
What you described is Google breaking your code constantly but also giving you a tool to automatically fix the code they broke, so it fits well within the general philosophy of not taking breaking changes seriously. It sounds like the tool might make the specific case of flutter version upgrades easier though, if the tool works well, so that's nice. Most Google software doesn't come with similar tools.
There is nothing about that that allows you to come to a good faith conclusion of “doesn’t take breaking changes seriously” when they literally do all of the work for you.
Earlier quoted context omitted.
Yes, as a longtime software developer people have been trying to solve this problem different ways my entire career. The closest we got was Java swing. And it works well enough for things like eclipse but for some reason, nobody wants to use it and they want to use things like Electron instead
Isn’t Eclipse written using SWT?
Ghidra is an example of a large, cross-platform application I use regularly that does use Swing. While it's a terrific reverse engineering tool, its UI leaves at least a little to be desired. Examples, not necessarily Swing's fault:
• Non-native text controls. This is particularly painful on macOS, where Ghidra text controls don't provide access to useful system services (Web search, dictionary look-up, translation, spell check, text-to-speech, sharing, … [it's an extensible list]) and don't honor custom key bindings defined in ~/Library/KeyBindings/DefaultKeyBinding.dict.
• Non-native file open/save and print/page setup dialog boxes.
• Non-native font selection with very limited options: can't choose weights other than standard or bold, can't choose widths (condensed, expanded, etc.), can't choose OpenType stylistic alternatives, etc.
• Per-window menu bars even on platforms where global menu bars are an option (KDE) or standard (macOS). As a consequence, no menu bar search or ability to remap menu item keyboard shortcuts on macOS.
• Other fiddly control differences. For example, on macOS, Option+Right/Left Arrow on a tree view node typically expands/collapses all descendants. On Ghidra, Option+Left Arrow collapses all, but Option+Right Arrow expands only children, with an additional level expanded for each subsequent Option+Right Arrow keypress. While Ghidra's behavior is arguably more useful, it's still inconsistent with platform norms.
• High DPI scaling inconsistent across platforms (works fine by default on macOS, requires fiddling on Windows and Linux).
• No integration with system-provided dark modes.
• No out-of-box support for installation as a native GUI application (macOS app, Windows Start Menu shortcut, Linux .desktop file). To be fair, with the arguable exception of Mac apps, this is out of scope for a GUI toolkit, and I suspect most people in Ghidra's target audience have no problem hand rolling a solution.
Earlier quoted context omitted.
How do generics change this? Can a type bound on a generic work like a static interface implementation specification, and recover the cost of wrapping the struct?
You can declare generic structs and generic functions, and get monomorphized copies (not erased to "any") of each function for all concrete types used. You can't look them up by reflection. You can't declare generic methods, and still can't overload methods by type.
That's not exactly true. You get one concrete function for all generic pointer types for instance. Generic functions take a hidden paramater called a dictionnary, which is fairly similar to vtable, since it contains type information and pointers for all methods of the generic type that the function calls.
So methods on generic types are still performed through an indirection.
https://github.com/golang/proposal/blob/master/design/generi...
Earlier quoted context omitted.
Why would it be easier now? What does a better compiler get you in terms of building a cross-platform UI toolkit? We now have GPUs, mobile OSs with their own separate UI abstractions, the web, WebAssembly, etc. And people want write-once deploy anywhere. You didn’t have any of that 30 years ago.
>You didn’t have any of that 30 years ago. Java ?
My point was that making GUIs today should not be any easier than 30 years ago because we have a lot more complexity across different OSs, phones, and the web.
Update: I think I understand your comment. I think you latched on the very last past of my comment about "write-once deploy anywhere". I meant that as in people want to create their GUIs with one language and one toolkit and have them deployable across different stacks without having a custom version for each and every final target platform.
Yes, technically Java did deliver on that as a programming language and runtime. And I guess swing also deliver on that as a cross-platform UI toolkit. However, we don't see a lot of Java UI applications around, with the exception of a few big ones, so it's fair to say that in the end it didn't work out. Of course, Java as general purpose language and runtime is alive and doing well today.
Earlier quoted context omitted.
Both frameworks have various packages that add OIDC support to them so that shouldn't be an issue. As for beginner - there's quite a bit of learning curve in terms of writing GUI applications themselves. Avalonia is kind of like WPF* but good(tm) and cross-platform. Uno platform is more like Xamarin and MAUI except in a better shape as of today. From technical perspective, Avalonia focuses on consistent rendering on…
That's a great answer, very helpful. I just picked up Avalonia for a test drive. Why do you think Uno is better than Avalonia for mobile?
Earlier quoted context omitted.
Native UI for anything that requires polish. I’ve been through too many iterations of frameworks that promise everything and don’t deliver. You’re up and running faster, then soon after you’re patching the core libraries after an OS update to try to get the FPS closer to native, or match a system animation more closely. The time saving only exist if you never polish your UI. Core logic can be shared. I use gomobile -…
I don’t think that premise of “native UI for anything that needs polish” is true these days. Canonical the company behind Ubuntu have said for some time now that all future app UIs of theirs would be done in Flutter starting with the very first thing people see the installation process. Google just rewrote Google Earth’s UI in Flutter. BMW are doing all of their in-car entertainment systems in Flutter.
I suppose if the alternative is “this only exists on one platform” or “this doesn’t exist at all” then maybe, but I find it a bit sad how keen we are as a profession to accept compromise and mediocrity to save developer time and expense.
I get it, but I don’t like it.
Seemingly it's using a to render everything just like Flutter on Web, which is known to have problems with accessibility and feel non-native.