71–80 of 92 posts
From a quick look at the sample code and a scrub through the video, it sounds a lot like JavaFX, especially when combined with the Kotlin TornadoFX extensions. Relatively recent build of a custom widget toolkit? Check. GPU accelerated 60fps compositing, render and animation layer? Check. IntelliJ as the IDE? Certainly. Although JFX is perfectly usable from any Java IDE? Cross platform including across iOS and Android…
Earlier quoted context omitted.
Microsoft also did that in WPF. For Windows PCs, it was already a widely used native look and feel. Also wide selection of native Win32 controls, mostly implemented in ComCtl32.dll. Yet in WPF I can easily replicate native look and feels, if I want so.
That's because WPF like winforms used native windows controls under the hood. Calls would be marshaled via pinvoke.
I also played with Flutter recently. Timeline: heard Kotlin announcement at I/O, went through some Kotlin exercises, wanted to compare with Flutter/Dart. Dart feels somewhere in between JavaScript on the one hand and a more-static OO, GC'd lang w/type inference (like Kotlin!) on the other. You can probably look closely at some sample app code and start doing some basic stuff quickly if you've worked much with JS and…
Also, the Dart plugin for VS Code is starting to add Flutter support. In that case you'd use the command line for hot reload.
- a Googler working on Flutter plugin.
I also played with Flutter recently. Timeline: heard Kotlin announcement at I/O, went through some Kotlin exercises, wanted to compare with Flutter/Dart. Dart feels somewhere in between JavaScript on the one hand and a more-static OO, GC'd lang w/type inference (like Kotlin!) on the other. You can probably look closely at some sample app code and start doing some basic stuff quickly if you've worked much with JS and…
Earlier quoted context omitted.
Microsoft also did that in WPF. For Windows PCs, it was already a widely used native look and feel. Also wide selection of native Win32 controls, mostly implemented in ComCtl32.dll. Yet in WPF I can easily replicate native look and feels, if I want so.
That's because WPF like winforms used native windows controls under the hood. Calls would be marshaled via pinvoke.
Unlike that, Spy++ itself uses Win32 (wrapped by MFC but it doesn’t matter) for GUI, you’ll see these SysTreeView32, msctls_statusbar32 and other native controls there.
Earlier quoted context omitted.
That's because WPF like winforms used native windows controls under the hood. Calls would be marshaled via pinvoke.
Simplest way to verify, launch visual studio 2015, press Tools/Spy++, in Spy++ find the visual studio’s main window, you’ll see that Win32 thinks visual studio is a single window with no children, with class starting with “HwndWrapper[DefaultDomain;” Unlike that, Spy++ itself uses Win32 (wrapped by MFC but it doesn’t matter) for GUI, you’ll see these SysTreeView32, msctls_statusbar32 and other native controls there.
Earlier quoted context omitted.
That's because WPF like winforms used native windows controls under the hood. Calls would be marshaled via pinvoke.
While interop is indeed available if you need to consume a Win32 control (not without limitations but generally works), by default WPF doesn’t use native controls. Instead it paints stuff on GPU with Direct3D 9, and on top of that implements its own markup, styling, layout, animation, behaviors, composition, etc…
> If there were dropped frames anywhere, I sure didn’t see them I would be curious to know what terminal the author uses. On my N6P, I can see a lot of dropped frames in the flutter demo app.
The Flutter app in the Google Play store does lag for me during the first run of most large animations (nav drawer open/close, shared transitions, etc.). The second time those animations are run, everything is smooth. There must be some sort of caching in place for animations.
As far as I could tell, everything else seemed to be fine. Scrolling performance was good, as were smaller animations like checkboxes and switches.
Alas, I stopped reading the moment I read it is being developed by Google despite the open-source nature.
Being developed by Google it means the chances of a project being discontinued are quite high: https://en.wikipedia.org/wiki/Category:Discontinued_Google_s...
While other big corporate entities have their own share of shut projects (no project is forever) the moment this project stops getting official Google support it will wither and die.
Maybe I am reading this wrong and we could have a Open Office/Libre Office situation.
Cross-platform development has been the holy grail for some 30+ years. Alas, I stopped reading the moment I read it is being developed by Google despite the open-source nature. Being developed by Google it means the chances of a project being discontinued are quite high: https://en.wikipedia.org/wiki/Category:Discontinued_Google_s... While other big corporate entities have their own share of shut projects (no project…
So whilst it's reasonable to hold off until they adopt it themselves and use it in their own deployed Apps, but once they do I'd be more confident in a commercially-sponsored Google project than an Indie OSS community led project. You just don't hear about the thousands of OSS projects being abandoned because they're from multiple Indie authors.
But I wouldn't trust a project with this large a scope without mega corporate backing. But I'd agree that if Google stops committing resources to Flutter than it will die despite being OSS'ed since it's too big to maintain without a well-resourced team.
Not all Google projects should be considered equal, if adoption is low and they don't have flagship Apps, high-profile initiatives or cost center's backing/funding the project then the project's future would be at risk if it doesn't become successful, but any project that is successful, has adoption or paying customers are very unlikely to discontinued, e.g. Angular, Firebase, Google Cloud Platform or any of their popular platforms, i.e. Chrome, Android, YouTube, etc have zero chance of being abandoned.