At least, I attempted what you suggest with I3, and not much has come of it.

Loud and clear.

I'm thinking many firms (mine included) would pay towards a desired feature, although not the entire dev cost.

Would love this feature as well.

My patch seems to be stuck. Oh well.

Please where you say "To add files, drag and drop them into the comment text area.". be sure to also say what to do if one cannot/does not know how to do that !!!!!!!!!!!!

Just chiming in to say I also have this issue as I use i3. I can drag and drop but it goes against the entire i3/tiling workflow.

From T7447:

I think we should wait until we implement T8060. There will, undoubtedly be some javascript unpleasanstries that will influence the level of customization allowed for this. If we push the user preference patch now, the most inconvenient outcome is that there might be a need to split out format customizations into date selection control format and timestamp format, which is too much preference noise, if we can avoid it. The best outcome, as far as date selection controls go, would be if we can improve and simplify the date selection control, then find a way for the user preference to be the master of both controls and timestamps.

I would probably punt on this until we pursue true internationalization.

My primary concern here is that I strongly dislike adding options to the product (see T8227 for discussion). In most cases, I personally bear the brunt of the long-term cost of adding options.

This requires:

In T1460#109400, @asteinlein wrote:

In T1460#108778, @avivey wrote:

The Done state should maybe propagate to the replies of the comment?

Very much +1 to this.

In T1460#108778, @avivey wrote:

The Done state should maybe propagate to the replies of the comment?

See T7447.

We're liking the new feature to mark inline comments as done, however, we dislike the change that makes old comments "stick" to updated diffs. This makes it much harder to read the new updated diff when there are lots of inline comments. Any plans to improve this somehow?

The Done state should maybe propagate to the replies of the comment?

These aren't universally deployed yet, but are substantially complete and are deployed in multiple applications. See T7858 for some followups. These will deploy everywhere over time, although they may not come to some lesser-used applications for a bit.

After T7849 (in review), there's a sort of kludgey workaround for this that has some caveats but should get you 90% of the way there:

All typeaheads/tokenizers should still work correctly.

A big chunk of this is in HEAD. This should be where we are, roughly:

In D12444 I changed the default Differential query to use viewer(), instead of implicitly resolving the user's PHID. That means that when you "Edit Query", you get:

I don't think this makes sense separate from T7820.

Anyway, this is somewhere in the 4-8 hour range and I don't think it needs to block on T7805. If T7805 happens first, that might reduce the estimate here by unearthing some of the common technical debt.

Yeah, that could work. The v0 dropdowns don't feel too awful to me, just a bit clunky.

Yeah, like even basic tabs in the dialogs what toggle between object types. There are ways to do it, I just don't know if it's valuable.

That is, I think you still need to make a distinct "relationship type" choice somewhere along this workflow or we'll just end up with an unusable mess of a dialog at the end, especially because objects will probably eventually be able to have multiple different relationships to the same object (I think revisions already can: they can both "revert" and "depend on" another revision, although this doesn't make a huge amount of logical sense).

I'd probably just go with your mock for a v0, and look if a generalized selector could work from a design pov down the road.