Earlier quoted context omitted.
If you're referring to the increased scroll speed with two fingers issue, that was patched within the last year.
Unfortunately, not talking about that.
Don't elaborate or anything.
We're forking Flutter
471–480 of 748 posts
Re: We're forking Flutter
#472Earlier quoted context omitted.
I doubt that complexity of a language is comparable to that of a widget library. After the text input cell and scrolling window it’s basically dumb geometry/drawing code all along.
Flutter has its own language (Dart) which I suspect is included in these stats.
The Dart team is separate from the Flutter team, though they do interact as Flutter is now the primary use of Dart and as such, influences what is worked on in the Dart team.
Re: We're forking Flutter
#473Re: We're forking Flutter
#474Earlier quoted context omitted.
What are some examples of good 'impossible to tell' UIs built with flutter on desktop or web?
Google Wallet & Google Classroom
> Google Wallet
Do you mean https://wallet.google/, which says “only available on Android”?
Your parent comment asked for “on desktop or web”.
Re: We're forking Flutter
#475Earlier quoted context omitted.
This. They can have all the deviations they want, but “input core” must be native. If a framework ignores it, users will notice and frown upon it immediately. When flutter came out publicly, first I thought no way it can get away with custom everything. But it turned out some developers don’t care about that at all.
you know that zero texting apps nowadays use native input anyway right? even native apps will implement their own input and it's always awful, but the pm needs those style previews... (you're still right thought)
Do you have an example of a texting app that doesn't use native input? This just straight up doesn't seem accurate.
Re: We're forking Flutter
#476Earlier quoted context omitted.
Flutter in Kotlin instead of Dart would have killed ! Alas. Hopefully, Kotlin Multi-Platform holds up as good as Flutter has (the rendering architecture based on Skia seems similar between the two frameworks).
> Flutter in Kotlin instead of Dart would have killed! Killed the framework for good, true. No pattern matching, joke destructuring, static delegation, reliance on Gradle (puke). I don’t understand how Dart still has bad reputation when it leapfrogged this joke of a language long time ago.
Just seems like personal preferences. I've used languages with extensive pattern matching and don't feel like I'm missing out without them. Don't really see the problem with Gradle or Static Delegation either.
Re: We're forking Flutter
#477> We describe Flock as "Flutter+". In other words, we do not want, or intend, to fork the Flutter community. Flock will remain constantly up to date with Flutter. That was the first fear when I saw the title - splitting community and having two incompatible versions. Good to see it addressed in the post. The second was just a fear of how it would complicate the development process, but it seems to be a drop-in replac…
> Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell You can't be serious. Maybe on Android, but on other platforms—especially iOS—they stick out like a sore thumb. A number of them just look like Material Design Android apps awkwardly transplanted over, but I know that's down to the developer so I won't hold that against Flutter. But scrolling through th…
> but I know that's down to the developer so I won't hold that against Flutter.
That is absolutely an issue with Flutter, which throws away the underlying platform UX and draws to a canvas. It gives you relatively few tools to target "native look" controls for each platform without maintaining multiple UIs in parallel composed of entirely different widgets.
Re: We're forking Flutter
#478Earlier quoted context omitted.
> This could explain a lot. Only if you're oblivious to the day-to-day activities of a software project. They work on building a framework, not on using said said framework to build something entirely different that has no bearing in how to build a framework.
I think the experience of building something atop a framework should absolutely have bearing on how to build the underlying framework.
> I think the experience of building something atop a framework should absolutely have bearing on how to build the underlying framework.
You'd be wrong. If your job is maintaining a framework then your focus is on internal details, and how the framework is used would be limited to your concerns in putting up test sets.
Believing that working on a framework gives you equivalent or even similar experience to using said framework in professional settings is a kin to believing that all mechanics are excellent drivers just because they work on cars.
Re: We're forking Flutter
#479Earlier quoted context omitted.
“Flutter team members don't actually use Flutter.” (as per the website). This could explain a lot.
Very rarely do the people working full time on a framework/tool also use that framework/tool in a non-toy setting. They aren't working two full time jobs after all.
Always, always, dogfood what you produce. The number one way devs cease making products people care to use is by not using what they make.
Re: We're forking Flutter
#480Earlier quoted context omitted.
I can appreciate that as a developer, but as a user I don’t particularly care that some company wants to ship identical looking apps on every device under the sun. I would prefer the apps I use to work and behave in a consistent way, using the same platform idioms I am used to. The software available and how it works was a large part of the reason I chose the platform I did. Of course, I recognise that, a. most peopl…
Pretty sure most large succesful apps have their own UI and UI design teams. Cant remember the last time i saw anything cupertino in an app. Even Apples own 'Home' app only loosely use cupertino. Id say the most noticable effect is the bottom modal sheet slide up effect. on ios the original screen animates into the background a little bit. Apps that dont implement this can be spotted but thats not unique to flutter a…
"cupertino" is the name of a Flutter widget set, not of the native platform controls or L&F.
Few Flutter apps are going to use cupertino because the whole goal of using Flutter is to create cross platform codebases to save development effort. To use an alternative widget set per platform is a huge amount of additional work, and having a cupertino app running on Android is even more of a sore thumb than a material app on iOS.