Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

Post reply on HN
Print view View original

411–420 of 748 posts

Re: We're forking Flutter

#411

Post by basilgohar »

milch wrote: post #382
pastage wrote: post #374

Earlier quoted context omitted.

You have to listen to the details, like "where is the back button", "Why does text work differently". There are some people that understand that it is different from the standard, but most just get annoyed. The discussion here is from a technical perspective why it is better, conformity of the app on different platforms vs standard behavior between different apps. There are very few people that care about the technic…

I'd also like to meet all these mythical users that have devices from every platform and want all their apps to look the same across all platforms. 99% of people I know IRL are in one ecosystem, with the exception of some that have an iPhone/iPad + Windows PC

It's not the end users that care about the uniformity but the fact the corporate design team wants there to be uniformity across all their platforms they support. This is part of branding and user experience. I'm not arguing for or against, just stating that is where the push for this comes from. It would make support, for example, easier, if all versions of your app user experience were similar.

Re: We're forking Flutter

#412

Post by loic-sharma »

eseidel wrote: post #243
irq-1 wrote: post #169

Earlier quoted context omitted.

> ...the Flutter team is in maintenance mode for 3 of its 6 supported platforms. Desktop is quite possibly the greatest untapped value for Flutter, but it's now mostly stagnant. Can you make any comment on this? Is it accurate?

I can no longer speak for the Google team (since I no longer lead it), but my understanding is that yes, Google is focusing their efforts on other platforms rather than Desktop (despite themselves using Flutter on Desktop for a variety of platforms). Canonical is contributing to the Desktop efforts substantially.

Canonical gave an update on Flutter desktop last weekend at their Ubuntu Summit: https://events.canonical.com/event/51/contributions/533/

Re: We're forking Flutter

#413

Post by skissane »

epcoa wrote: post #342
jeremyjh wrote: post #307

Earlier quoted context omitted.

Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there. Yes, the same vendor provides other toolkits. Linux is a kernel project, and different distributions are for many purposes best considered to be different OS's. Desktops based on Linux mostly are either GTK or QT, and so the native toolkit depends on the desktop you are using. Is this too much fragmen…

> Linux is a kernel project, Is that useful pedantry? From context, you really think that's my confusion here? I didn't include *BSD either, but it isn't any different for the relative handful of people using that for a desktop system. > Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there. Except for Microsoft's numerous attempts to supplant it and the…

> If you insist on pedantry, you should know Win32 isn't a GUI toolkit either, it's an anachronistic term for the Windows API.

I don’t think it is “anachronistic” - as far as I am aware it is still the official name. And I don’t think calling it the “Windows API” is right, since Win32 is just one of the APIs that Windows offers. If I’m calling CreateFile, I’m using the Win32 API, but if I’m calling NtCreateFile, I’m not using the Win32 API, I’m using the native NT API instead. If I set the subsystem as NT instead of Win32 in my executable’s PE header, calls to native NT APIs such as NtCreateFile will still work fine, attempts to use Win32 subsystem APIs won’t. And there are other APIs Windows has which aren’t (strictly speaking) part of either the native NT API or the Win32 API - COM and the many APIs built on top of it, .Net, WinRT, DirectX, etc.

But you are right that Win32 isn’t a GUI toolkit. It contains a rather basic and old-fashioned GUI toolkit (USER), but it contains a lot of non-GUI APIs too. I’m reasonably familiar with those parts of the Win32 API used by services and console mode apps, but if you asked me to write a Win32 GUI event loop I’d be asking ChatGPT to remind me how, because while I’ve read tutorials I’ve never actually attempted it.

Re: We're forking Flutter

#414

Post by Vt71fcAqt7 »

xster wrote: post #170
pzo wrote: post #128

Earlier quoted context omitted.

> Also frankly, nobody forking Flutter will be nearly skilled enough to work on the Flutter engine (Impeller). For me its so weird they ditched google/skia to develop Impeller in Dart from scratch in the first place. If skia was not ready they could move just 1-2 developers to Skia team to collaborate with them. Now they want to even write their own 3d rendering lib based on Impeller (flutter_gpu, flutter_scene) even…

https://github.com/flutter/engine/blob/main/impeller/docs/fa... discusses the reasoning a bit. There's more of a difference in the approach

Also related: https://github.com/flutter/flutter/issues/77412 - Hixie's issue that led to Impeller (or one of many issues)

Some related iOS jank issues from that time: https://github.com/flutter/flutter/issues/32170 https://github.com/flutter/flutter/issues/61450

Re: We're forking Flutter

#415

Post by refulgentis »

Vt71fcAqt7 wrote: post #380
refulgentis wrote: post #376

Earlier quoted context omitted.

Flutter two finger scroll "bug" is gone. I wouldn't say its unlikely they carried a patch for it, I just wrote a framework patch that I apply at build time in CI and locally. I refuse to sideload arbitrary APKs, especially from bytedance. I feel bad because that is irrational, you did, and it'd be really helpful if I did and just did this myself, but, you should install FlutterShark and check: https://play.google.com…

>Flutter two finger scroll "bug" is gone. Why is "bug" in scare quotes here? It was most definitely a bug. >I wouldn't say its unlikely they carried a patch for it, I just wrote a framework patch that I apply at build time in CI and locally. The actual fix was pretty involved. I doubt a large company like Bytedance would want to carry around extra patches at the gesture level that make the dev cycle more difficult. H…

> Why is "bug" in scare quotes here? It was most definitely a bug.

Is it? I thought it was cool, I can't think of why its disruptive to scroll a list faster if you scroll with more fingers.

> I doubt a large company like Bytedance would want to carry around extra patches at the gesture level

I'm a solo endeavour, and I spent ~30 minutes to do exactly this (patch gesture behavior) two days ago. I was stunned how easy it is. But I grew up on versioned closed source dependencies on Apple iOS frameworks that you had to patch the runtime at runtime to fix, so I'm easily wowed.

> 200 devs are using Flutter which would make no sense if it was used in Douyin

Seems reductive: "Only" 200 fulltime, 800 in the company...and we're in a discussion about how 50 maintain _the entire framework_. :)

Re: We're forking Flutter

#416

Post by refulgentis »

rvnx wrote: post #379
999900000999 wrote: post #373

Earlier quoted context omitted.

I'm going to be honest. C# , NodeJS, Python and rarely Java( had a rough year), pay my bills. Flutter/Dart doesn't. If you know someone hiring a Flutter developer I'm 100% down to interview. I don't hate Kotlin, it feels like Google's answer to Swift( although Java was never as hard as Objective C). I even built a small project with it. Can we at least agree it's weird Google is trying to promote 2 different language…

They want both implementations to compete, and then they deprecate one of them.

Thats an excellent summary, and its fair for you to assume that question has been settled.

Re: We're forking Flutter

#418

Post by malkia »

lolinder wrote: post #400
malkia wrote: post #364

Earlier quoted context omitted.

Python is an engine, flutter is the whole car.

If Flutter is a car, Python is at least four different models of car, plus three models of light truck and one airplane. The scope of Python's standard library is just enormous.

true, but still - these libraries can be updated independently, one from each other - with a framework, things have to be orchestrated.

Re: We're forking Flutter

#419

Post by epcoa »

skissane wrote: post #413
epcoa wrote: post #342

Earlier quoted context omitted.

> Linux is a kernel project, Is that useful pedantry? From context, you really think that's my confusion here? I didn't include *BSD either, but it isn't any different for the relative handful of people using that for a desktop system. > Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there. Except for Microsoft's numerous attempts to supplant it and the…

> If you insist on pedantry, you should know Win32 isn't a GUI toolkit either, it's an anachronistic term for the Windows API. I don’t think it is “anachronistic” - as far as I am aware it is still the official name. And I don’t think calling it the “Windows API” is right, since Win32 is just one of the APIs that Windows offers. If I’m calling CreateFile, I’m using the Win32 API, but if I’m calling NtCreateFile, I’m…

The name itself is anachronistic, what does the 32 stand for? You call CreateFile with 64-bit pointers, it was still considered Win32 (until they officially changed it).

But take it up with Microsoft: https://learn.microsoft.com/en-us/windows/win32/apiindex/win...

"Using the Windows API, you can develop applications that run successfully on all versions of Windows while taking advantage of the features and capabilities unique to each version. (Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)"

The URL still has win32 in it, lol.

Though this naming goes back nearly 2 decades https://learn.microsoft.com/en-us/previous-versions/tn-archi...

The API provided by ntdll is semi-officially called the "Native" API and much of it is subsumed into the Windows API. The PE subsystem names you are referring to are IMAGE_SUBSYSTEM_NATIVE and IMAGE_SUBSYSTEM_WINDOWS_GUI/CUI, so it's somewhat consistent. Microsoft officially refers to that API as Native System Services in the documentation for the DDK.

https://learn.microsoft.com/en-us/sysinternals/resources/ins...

Re: We're forking Flutter

#420

Post by DaiPlusPlus »

deskr wrote: post #336
stux wrote: post #264

https://github.com/flutter/flutter/pulls?q=is%3Apr+author%3A... - 0 open PRs - 2 PRs merged, 1 PR closed in the past 4 years - All PRs reviewed by a member of the Flutter team within 24hrs - [“If I'm still supposed to write tests, even for this change, then this is probably as far as I take the PR.”]( https://github.com/flutter/flutter/pull/128910#issuecomment-... ) - 40+ PRs from 2019 So, disgruntled ex-employee?

I can understand the test frustration on both sides. * He's being asked to fix tests that were already failing. That can be an enormous task depending on the nature of the failure and the code base. * The team doesn't want to merge his PR since they don't have a test. The code is presumably working without his PR and understandably they won't change a single byte without seeing tests work.

If existing tests are failing then how are they accepting any PRs at all?
Post reply on HN