I did for now, will see what FontAwesome 5 brings, but the was never something I really liked for Phame anyways.

And before you file it, no, cat facts are not supported.

Not intentional -- @chad, I can figure out what's going on there since it might reasonably be me and I have a local repro.

Are we not supposed to have permission to "Edit Favorites", or is the Favorites application still being worked on?

This is complete for now, there may be more minor updates, but all top level goals have shipped.

This is in a reasonable state, will follow up with a new task on errata.

no no those are for the Meterology application

Theres like 20 thermometers for a health application.

also conflicts with Phabricator Health Records Application

Nobody loves making tasks and projects… what is this, a tool for PMs?

Or use heart for favorites?

It also occurs to me that Project profile menus already show up in a main menu dropdown on mobile, so we must have some PhabricatorActionView::newActionViewFromItemView(...) sort of code in there somewhere.

please also add "close menu" and a label that says "menu items" and help text that says "click an item to activate it"

Resign Header -> Redesign Lists -> Redesign ProfileMenu

hahaha
ha
h

phuix-js builds phabricator-action-view, so that's what I was planning to be king.

This diff will be a wondrous, wandering tale or action, adventure, mystery, intrigue, and touch lots of random stuff that should have been broken apart.

Yeah, I'm not aware of any real difference between them or good reason to have both. Maybe I'm forgetting something but I'm pretty sure we can merge them eventually.

Yeah I think we shouldn't have two types of lists.

I think there are two approaches:

One thing I haven't been able to build is the ProfileMenuItemConfigurationQuery -> ActionView

Presumably resolved by D17171?

oh ok, I think I can do that

we can probably ditch that outright?

You should be able to return a list of appropriately configured PhabricatorEditEngineProfileMenuItem objects as builtins, rather than defining a new class for each application -- since "Create Task" is just "EditEngine link to the create task form", etc.

I also think you have some special magic that turns "Create Task" into a mini-menu automagically - we can probably ditch that outright?

I think I need to make PhabricatorProfileMenuItem files for each "default" I want to ship?

T12089 has a narrower description with some screenshots, I think the behavior got flipped by accident.

At least one user over email (and I think @epriestley also) mentioned the light highlighting of full lines is hard to distinguish / understand as full change in diffs. I'll look more into these issues before next release is cut.

Started building and insanely easier as an application. "Favorites" unless you have a better suggestion. Seems more flexible.

Yep, that looks good to me.

Just for my own understanding:

They said it's a definite improvement. Nice!

Thanks for the quick response! I'll send that last image over to our user, and see if it's an improvement for them as well.

I'm not actually sure which will end up being easier, I think they have like 95% of the same problems. Quick Create probably is a bit easier, though.

I really want a small remarkup block sometimes.

Haha, maybe it's like when Blizzard uses a simulator to build a colorblind mode they screw it up, therefor the simulator must not work?

He said simulators don't work well... but I'm like (how would you know................)

Ah, cool. I'm 100% onboard with it if an actual affected user has confirmed that the change is good, I'm just really uneasy about accessibility changes that don't actually involve the affected users.

I'm working with a color blind designer in another chat channel, they're looking over my work. We don't think it's needed.

Do you specifically not want to add a red-green colorblind mode to the existing "Accessibility" settings?

I think I'd learn, if that's the way I always saw red/green.

If a change only had one of those colors (e.g., just one added section, or just one removed section) I think I'd have no clue if it was removed-red or added-red.

I'm for whichever is easiest, since the other will fall in line quickly after.

I think I can get by just tweaking the red/green current diff colors.

You were thinking about doing this one first, then Home later, right?

That's easy to add, but I'd worry it will result in much worse readability for all users for diffs with a lot of small corrections. If there are just 1-2 big edits the extra "+" and "-" probably aren't a big deal, but choppier edits will get a lot of extra annotation.

Yeah I'm wondering if a quick patch for this is just add + and - to the prose diffs.

I'm hesitant about using math to solve this because I think Blizzard did that in Overwatch (apparently? or something?) and ended up with modes that were worse for colorblind users than users with normal vision:

I wonder we could solve this with math since most colors are stored as hex (we'd have to move diff colors to hex, but that's not a huge deal).

@epriestley I feel like we had this conversation on how to implement this somewhere... (on a diff)? Not sure where these extend from, just move it into Personal/Global settings?

Yeah, seems to be a bug in Chrome. I would follow up with them. There is no correct means to style it in Ubuntu, just some hacks.

Unclear if I can globally style these consistently across all browsers / OSs. But no one complained about my select styles yet.

Ubuntu - Mac

The bug seems to be with Chrome/Ubuntu, as it's inconsistent with their other platforms. Did you file a task in their upstream?

Does it reproduce here as well? We don't take bug reports from that install from non-admins. It's a forked install and not up to date.

Chrome 54 / Ubuntu 14.04. Tabbing through the comment edit form fields looks like this (screenshots are from phabricator.wikimedia.org):

outline: 4px solid red;

yeehaw