Reply inline option

[olorin99]

Add setting to control whether reply controls are shown inline or on another screen.

[jwr1]

Sorry I didn't get around to this till now. Just had three things I noticed:

• If the text you're replying to is too long, then the page overflows, so the reply screen probably needs to use a scroll view.
• Should we display the text as markdown, since the text could be from comments or microblogs?
• I'm not really sure what the best way to handle this one would be, but we should have the text editor take up more space height wise, since this external replying was supposed to provide a more comfortable replying experience, especially for longer comments (so people don't need to scroll as much to proofread).

[olorin99]

This should have the markdown editor resize dynamically according to content. Had to emulate TabBarView rather than use directly since TabBarView kept trying to use infinite height.

[jwr1]

I just tested it again. The non-inline reply editor seems good, but when I change the setting back to inline, and then go to the drafts tab and try to scroll, I get a bunch of errors like the following:

Another exception was thrown: The provided ScrollController is attached to more than one ScrollPosition.
Another exception was thrown: 'package:flutter/src/rendering/proxy_box.dart': Failed assertion: line 3047 pos 12: '!debugNeedsLayout': is
not true.

[olorin99]

Ah that should be straightforward to fix. I ran into a similar error with the feed screen a while ago. I should be able to fix it on monday.

[jwr1]

It seems better, but the scrolling is super slow now on the drafts tab, and I get the following error:

Another exception was thrown: 'package:flutter/src/rendering/proxy_box.dart': Failed assertion: line 3047
pos 12: '!debugNeedsLayout': is not true.

[olorin99]

It seems to be scrolling normally for me. I was able to reproduce the error though by trying to scroll really quickly, scrolling slowly doesn't trigger it.

From what I can guess from the stack trace it happens when flutter attempts to run a hit test against the widget but the widget has already been scrolled out of view so the debugNeedsLayout flag hasn't been set. The stack trace frames 244 -> 238 have to do with handling pointer events and pretty much all the rest of the stack trace is hit tests.

Since it seems to be an issue in flutter itself and it only occurs in debug builds I think it's safe to ignore that error. Not sure whats causing the slow scrolling though.

[jwr1]

Alright, just give me time to look at it again, and then I'll merge.