fix: Ensure consistent TextStyle inheritance during button state transitions

[ndonkoHenri]

Fix #5620
Fix #5278
Fix #5895

Summary by Sourcery

Improve button text style handling and polish layout, utilities, and documentation across Flutter and Python SDK components.

Bug Fixes:

• Ensure button text styles resolve with non-inheriting TextStyle across widget states to avoid animation and lerp assertion issues.

Enhancements:

• Refine Row and ResponsiveRow layout behavior wiring to use higher-level alignment helpers and respect intrinsic height flags directly from control properties.
• Refactor text utilities by extracting font variation and text decoration parsing into dedicated helpers for reuse and clarity.
• Tighten pip helper error reporting and exception handling when ensuring Flet-related Python packages are installed.
• Clarify Lottie, Row, and ResponsiveRow Python API docstrings with concrete examples, alignment constraints, and current feature limitations.
• Adjust button content construction to reuse prebuilt content widgets instead of rebuilding inline.

Build:

• Extend Python isort configuration to treat additional Flet packages (desktop and web) as first-party modules.

[sourcery-ai]

We've reviewed this pull request using the Sourcery rules engine

[Copilot]

Pull request overview

This PR fixes TextStyle inheritance issues during button state transitions by setting inherit: false on button text styles, which prevents TextStyle.lerp assertion errors when animating between states. The change also includes various code quality improvements and documentation enhancements.

• Core fix: Modified button text style handling to explicitly set inherit: false to match Material button defaults
• Refactored text parsing utilities to extract reusable helper functions
• Improved Python code quality with better exception handling and import organization
• Enhanced documentation for Row, ResponsiveRow, and Lottie controls

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
sdk/python/pyproject.toml	Added flet_desktop and flet_web to isort's known-first-party packages
sdk/python/packages/flet/src/flet/utils/pip.py	Replaced bare except with except Exception, removed redundant imports, improved error message formatting
sdk/python/packages/flet/src/flet/controls/core/row.py	Enhanced documentation with proper example formatting and detailed property notes
sdk/python/packages/flet/src/flet/controls/core/responsive_row.py	Improved documentation and fixed trailing whitespace
sdk/python/packages/flet-lottie/src/flet_lottie/lottie.py	Added note about layer effects limitations with relevant issue links
packages/flet/lib/src/utils/text.dart	Extracted parseFontVariations and parseTextDecorations as reusable helper functions
packages/flet/lib/src/utils/buttons.dart	Introduced parseButtonTextStyle wrapper that sets inherit: false to prevent TextStyle.lerp assertions
packages/flet/lib/src/controls/row.dart	Refactored to use extension methods for better code organization
packages/flet/lib/src/controls/button.dart	Code formatting improvements and simplified variable usage

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[cloudflare-workers-and-pages]

Deploying flet-docs with    Cloudflare Pages

Latest commit:	7190ce5
Status:	✅  Deploy successful!
Preview URL:	https://9f1c06f4.flet-docs.pages.dev
Branch Preview URL:	https://fix-button-text-style.flet-docs.pages.dev

View logs

[FeodorFitsner]

If I'm not mistaken Flutter DateTimePicker (or other widgets) expect (and outputs) local dates, not UTC.

Converting to UTC date on Python side could give wrong results on UI.

For example, if I specify datetime(2025, 3, 10) in Python and you convert it to UTC then on a device in -07:00 timezone it will show March 9 in the picker, instead of expected March 10.

When a developer writes a naive date like 2025-10-03 in Python, most people mentally model it as a local calendar date, not UTC. Usually, UTC must be explicit.

On the other hand, using of UTC for passing datetime/time over a wire (like in Flet between Python and Flutter) is a good thing. However, on Flutter (or JavaScript in web) side you have to convert the date back to local, either on protocol level or in DateTimePicker using .toLocal(). Selected date in DatePicker should be converted back to UTC with .toUtc().

So, algorithm could be:

• "naive" datetime we convert to a local datetime then into UTC.
• local datetime is converted to UTC.
• UTC datetime goes into the wire "as is".

Does it make sense?

[FeodorFitsner]

...why passing UTC over the wire is the right solution? When you have both Python and Flutter on the same machine (mobile, desktop apps) it's fine to use local, but if you run Flet app on the web then client browsers are in time zones different from server: client receives UTC date and converts it to its local date.