search

flutter / flutter

Flutter makes it easy and fast to build beautiful apps for mobile and beyond
https://flutter.dev
BSD 3-Clause "New" or "Revised" License
162.27k stars 26.66k forks source link

Suggestion: decouple more widgets from Android/iOS design guidelines #53059

Open filleduchaos opened 4 years ago

filleduchaos commented 4 years ago

Use case

The number of platforms that Flutter officially targets to a reasonable level of stability has grown beyond just Android and iOS to include the web, Windows, macOS, and Linux. Yet most of the widgets the SDK provides are still tied to the design guidelines/systems of those two mobile OSes. This seriously impacts the out-of-box usability of the widget library for developers who are using Flutter for other platforms/who do not necessarily prioritise mobile.

I think there is a strong case to be made that there are a lot of widgets in flutter/material and flutter/cupertino that really should be/be based on flexible, extensible widgets in flutter/widgets so that developers can take direct advantage of logic that's often hidden away in private classes and hardcoded constants, rather than having to duplicate it.

Proposal

Much like with the new plugin system, I think it would be a great idea if certain Material/Cupertino widgets were rewritten to decouple the general "behaviour" of the widget from design-specific guidelines (and probably make more use of delegates and painters). A prime candidate would be Slider and CupertinoSlider, for example.

One set of widgets that I think already does this decently well is the set of Scrollbar (from flutter/material), CupertinoScrollbar (from flutter/cupertino) and ScrollbarPainter (from flutter/widgets). With the latter it is easy to build a custom scrollbar without having to think too much about (or copy the logic of) how a scrollbar should work, and you also have built-in scrollbars that follow Material guidelines or HIG if that's what you want. The only thing I would change about this set is to update the documentation of ScrollbarPainter with a minimal example of how to put together a scrollbar with it.

HansMuller commented 4 years ago

We've often talked about creating a "building blocks" library in between widgets and material/cupertino/etc, to make it easier to build things like the components in the material/cupertino/etc libraries. That said, at the moment there's no such project in the plan, but we have been thinking about it :-).

That said, appreciate the feedback about ScrollbarPainter; an example sounds like a good idea.

CC @justinmc

justinmc commented 4 years ago

I definitely agree with this! I think this is going to become more and more important for Flutter over time. I will try to update this issue if I see any concrete steps happening anywhere.

lukepighetti commented 4 years ago

I am of the opinion that material and cupertino should be pub packages and flutter should expose a mid-level API for widgets and especially slivers

justinmc commented 4 years ago

That was one of my first thoughts when I started working with Flutter. There might be more support for that kind of move as we add more platform design styles. A big positive of keeping them in the library now is that it's so easy to write a Flutter app with everything you need right out of the box. Maybe we'd have to include the material library by default but make it really easy and obvious to swap in/out Cupertino or others.

lukepighetti commented 4 years ago

@justinmc They can just add material and cupertino to pubspec.yaml dependencies by default if they want to, like they do with cupertino_icons. And get rid of that "uses-material-design: true" flag.

satvikpendem commented 4 years ago

I also agree, a lot of values are hard-coded into certain widgets without a way to overwrite them, such as the box shadow with ReorderableListView, which shouldn't be a Material widget but more a generalized list widget that supports different theming.

darrenaustin commented 3 years ago

Hey folks, we are ramping up a design to try to address this and other issues with ReorderableListView. We are tracking it with #66080 and in a design doc. Feedback welcome.

Hixie commented 1 year ago

I've been noodling on this topic recently and wrote some thoughts up here: https://flutter.dev/go/blankcanvas Comments welcome.

mateusfccp commented 10 months ago

@Hixie I like very much the idea proposed in the mentioned document.

Is there any planning about when will this be done? Or is it still just in discussion phase?

Hixie commented 10 months ago

I've been working on a proof of concept (I have buttons and scrollbars implemented so far) but it's more of a hobby than something I'm working on full time currently. When there's something to report I'll leave a note at the top of the design doc.

iapicca commented 3 months ago

this issue has been indirectly referenced in 2024 road map as related issue of blankcanvas