Ref T10319. This swaps the default in the Picture Chooser to allow picking of the custom unique avatar. We're currently going with 100k unique possibilities. The logic roughly hashes a user name and picks an image pack, color, and border. Based on that, we select the first character of their username, or fall back to Psyduck if not [a-z][0-9].
Details
Details
- Reviewers
epriestley - Maniphest Tasks
- T10319: Generate unique? profile images for each new user
- Commits
- rPf095a81b008d: Allow custom image generation when choosing a profile image
Set the following usernames from ProfilePicture as a test: chad, epriestley, sally, 007, _cat_, -doggie-.
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Branch
- user-gen-image (branched from master)
- Lint
Lint Warnings Severity Location Code Message Warning src/applications/files/builtin/PhabricatorFilesComposeAvatarBuiltinFile.php:116 XHP95 Self Class Reference - Unit
Tests Passed - Build Status
Buildable 15812 Build 20911: Run Core Tests Build 20910: arc lint + arc unit
Event Timeline
Comment Actions
Faked the profile image one for now. I think I need to take maybe another 1-2 hours at cutting out some of the lame colors. If we're doing color x color, we have a pretty big depth to work with. Not a fan of mustard avatars.
| src/applications/files/builtin/PhabricatorFilesComposeAvatarBuiltinFile.php | ||
|---|---|---|
| 61–67 | I think this won't get the right result if the alpha part has a leading zero (like 0.3) or more than one digit (like .25). Since nothing else calls getBorderMap(), can you just have it return values like these instead? array( array(255, 255, 255, 0.3), // ... ); Those should be easy to convert into either the r, g, b, a or rgba(r, g, b, a); forms. | |
| 73–80 | I think all of these calls can fail and return false -- if they do, we should throw an exception. | |
| 87 | This should have static or be called nonstatically (-> instead of ::). | |
| 95 | (Can this be private?) | |
| 100 | It doesn't matter in this case, but for consistency prefer phutil_utf8_strtoupper(). Plain old strtoupper() has some crazy behavior for some UTF8 inputs. | |
| 106–108 | You should add some junk to the end of the username, or we'll always get the same value for a range with the same endpoints. That is, if you digest "chad" into the range 1-10, let's say you get a 6 out. Then you do: $border_key = digest('chad', 1, 10);
$color_key = digest('chad', 1, 10);Since the digest is stable, the border and color will always both be the same, 6. So there are only 10 possible border+color combinations, not 100 like you want. You can fix this by digesting "chadborder" and "chadcolor" instead, like this: $border_key = digest($username.'border', 1, 10); $color_key = digest($username.'color', 1, 10); Then you'll get two different results -- both still stable and only functions of the username, but no longer guaranteed to be the same value. | |
| 152–153 | I can look at this, it sounds like a bug in FileFinder -- especially if only ., and not .., is appearing. | |
| src/applications/files/builtin/PhabricatorFilesComposeAvatarBuiltinFile.php | ||
|---|---|---|
| 68–72 | These calls can each individually fail. This is only checking the last one -- the full set of checks is like: $ok = imagefill(..);
if (!$ok) { throw }
$ok = imagesetthickness(...);
if (!$ok) { throw }
etc
etcimagecreatefromstring() and imagecreatetruecolor() may also fail. The full error-checking version of this will unfortunately be 100000 lines long and there's no real avoiding it | |
| 158–160 | Should be fixed now. | |
Comment Actions
This currently just generates on demand when a user goes to pick a new photo. I presume I should land this after release cut.