noodlebox / kawaiidiscord Goto Github PK

Allow users to add and configure their own emote sets. Refactor currently hardcoded EmoteSets to cover a few base types:

• native JSON format (like the current SFMLab set)
  • Automatically fetch from a URL
  • Install static list from a local file
• Twitch subscriber/FFZ/BTTV emotes for specific channels (or all of them for the insane)
  • Maybe aggregate Twitch API requests when possible
• Imgur album, identified by album URL
  • Use image captions as emote names
  • Automatically number emotes based on album title
• Steam emoticons, either by game, or for all emoticons owned by a linked account
  • Probably needs an extra API layer to aggregate data from the Steam market API first
• Freeform sets, implementing lookups with some other unique logic
  • Install JS-based plugin from local file (?)

as well as some meta EmoteSet types:

• Combine EmoteSets so that rolls draw from all included sets, instead of only the first with a match
• Blacklist specific names or patterns from an EmoteSet
  • Act as wordfilter for common words
  • Allow an emote lookup to "fall through" to the next EmoteSet

Freeform EmoteSets could perform lookups using other APIs, such as an imgur-based set:

• :imgur~1Waxolh: -> https://i.imgur.com/1Waxolh.png

Requires implementing a settings panel first. Once that's done, also include additional emote sets which not everybody may want, like FFZ's and BTTV's global emotes (possibly disabled by default). Users should also be able to re-order sets to control which take precedence when emote names overlap.

When editing a text-only message that has been edited at least once before, emote parsing is not triggered on the new content.

This most likely happens because ReactJS (in trying to minimize DOM changes) simply changes the data for the text node, which does not trigger the observer callback. If a message had not been edited before, the adding of the "(edited)" tag triggers the callback. If there are any existing emotes, a new text node is created as a child of the img element (the cause of a previously fixed bug), also triggering the callback.

The current implementation completely overrides the default emoji tab-completion behavior. One option is to permit the default tab-completion behavior when no matches are found, but this is clunky-looking and more prone to breakage. Ideally, we would be able to use the improved menu for everything, for consistent sorting behavior and scroll-able results.

In order to include the default emoji they will need to be enumerable, with the most likely source of this data being EmojiPicker in state.metaData when active. Hopefully, there's a better alternative somewhere else. Making our own API calls is possible, though less desirable, and this would only include custom emoji.

Searching adds a noticeable delay to normal text input with large "Twitch-style" emote sets (like the subscriber emotes).

• Make emote searching lazier (like the sorting is now), while still being able to quickly determine whether any match exists (to know whether to stop event propagation).
• Cache last search result.

Allow users to apply custom CSS or theming to the web-based Discord client.

Emote completion breaks the default handling for commands that generates "integration" results, e.g. /giphy. If message begins with one of these commands, custom completion behavior should never override the default.

Most Twitch and BTTV emotes are 28x28, or slightly smaller. Scaling them up to 32x32 in Discord (when .jumboable) is ugly. This CSS improves their appearance:

.emoji {
    object-fit: scale-down;
}

This doesn't work well if the user also has custom styling to make emotes larger, using width and height. zoom works well instead, and will also benefit from high-DPI versions when available (#10), though it currently causes tooltips to appear in the wrong place. image-rendering: pixelated ensures pixel-perfect emotes are scaled up without making them a blurry mess.

.emoji.jumboable {
    object-fit: scale-down;
    zoom: 200%;
    image-rendering: pixelated;
}

Using their native sizes is an option, but will require knowing their dimensions ahead of time (provided by most of the APIs), or else suffer reflows every time an emote loads.

• Add basic CSS, encourage use of zoomtransform: scale() for users wanting giant emotes.
• Fix tooltip position for zoomed-in elements.

Completion menu should show possible rolls (emotes ending with #) among completion options. There are a few things to decide or figure out first:

Ordering

Potential rolls should appear either before or after all other numeric matches. Normally, name# would appear between name and name2. As a parameter for the collator, ignore­Punctua­tion causes name# and name to be treated as equal, though this may not be foolproof as sort is not be guaranteed to be stable. A custom comparator could resolve all possible ordering issues.

Useful results

Only show non-trivial rolls, as any valid emote followed by # is a technically valid roll (first emote in any set does not have a 1 suffix). Only show rolls when:

• there are multiple possible matches (show for :mike, but not :mimi)
• the current query does not end in an explicit numeric suffix (show for :mike, but not :mike3)
• ... unless the "root" name ends in a number (show for :h3h3, but not :mike3 or :h3h)

If the current query contains a roll which would which would be valid (even if not otherwise shown, based on the previous rules) or a wildcard match as described in #12, show it as the only match.

Rendering

Rolls could either be rendered as the fallback emote (rollDefault), or could be animated by quickly cycling through potential matches.

There aren't many text strings yet in this plugin specifically, but this would be a handy feature for all of my other plugins as well.

A simple implementation like this should do fine:
https://gist.github.com/samogot/774d3d2059402d5173a72524e39dd7d0

May also be able to grab existing localization strings from Discord where I need the same text.

The background color is now defined on .tooltip.tooltip-brand.

Update (2017-09-09): emoji (and some other) tooltips now use .tooltip-black instead of .tooltip-brand in Canary.

.tooltip-brand exists still exists on Canary, but .tooltip-black does not exist yet on Stable, so keep the script as is until the change makes it into stable.

Include some metadata to help rendering emotes better:

• width and height (should help resolve #11 for certain special cases of irregularly sized emotes)
• available sizes (necessary to implement #10 properly)
• render options, such as whether to avoid scaling, or pixelate when scaled up (also helpful for #11)
• custom styles (e.g. FFZ's Halloween emotes like StabZ)

May need to manually trigger an input event, or avoid cancelling another. Also affects the message content that is copied into an upload modal.

A few things to do to bring the user experience up to par with native emotes.

• Emote tooltips
• Tab-/auto-complete
• Emote picker with recently used and/or favorites
• Settings panel for managing emote sets and other preferences.

Custom emotes always get the jumboable class, but they should only get it when there is no other text in a message. Also, Discord emojis never get the jumboable class when custom emotes are used in the same message, because custom emotes are considered to be text.

When a message with emotes is edited, the wrong element is replaced by React. The old message remains, "duplicating" it on each edit.

• The structure of the autocomplete menu has changed, as well as all of the class names which now have randomized suffixes.
• A few more builtin behaviors now use an internal field to keep track of the current message, instead of checking the value of the textarea. Related to #21.
• maybeShowAutocomplete is now also called inside componentDidMount and componentDidUpdate, so it can no longer be easily interrupted by event handlers. Monkey patching this method will probably be necessary.

The update has also caused several other regressions, so more will likely change before making it to stable.

Waiting on these to be fixed before continuing (so that it's clearer which behavior to replicate):

• https://trello.com/c/CGNt4lUD/827-text-from-chat-box-doesnt-auto-move-to-upload-dialog (fixed)
• https://trello.com/c/20pY7SMO/828-last-message-duplicated-when-uploading-images-right-after (fixed)

And this in case there's any class/style changes:

• https://trello.com/c/WzCklIbl/813-some-emojis-are-warped-not-displaying-there-correct-demensions-in-the-new-modal (fixed, mostly)
• https://trello.com/c/KlfOLg7E/879-in-the-emoji-autocomplete-menu-rows-for-tall-and-thin-1x128-emoji-fill-the-entire-screen

The new method of inserting completed text (added in 5c03113) does not work at all in Firefox. Need to find an alternative to this that also properly updates Discord's internal state.

Use srcset to specify 2x- and 4x-scale versions of emote images when available. Twitch emotes always have larger versions available, scaling up smaller emotes when necessary. Larger versions of FFZ emotes return 404 when not available, so checking the API data first will be necessary.

A less elegant alternative would be to attempt loading the largest size first for any emote, falling back to the default size on error.

The scripts should check for updates to emote sets so that a page reload is not necessary to see new emotes. Frequency of checking could depend on how often the set is expected to be updated:

• polled at a regular interval, such as hourly
• when an unrecognized emote is seen (with an appropriate cooldown)
• triggered manually by the user

Default emoji completion behavior is not correctly overridden for queries containing ~, usually leading to a broken completion menu.

When new emotes are added, previously rolled emotes should not change. Emote data now includes a creation date, making it possible to build a list of the emotes that existed when an older message was originally sent.

Messages before the emote epoch (2017-02-08 or some arbitrary date between that and release) should use all emotes created on or before that date.

Since fixing this will likely change many older roll results anyway, it may finally be worth including this old fix for some ugly roll math: 3448e80.

I just finished putting KawaiiDiscord.plugin.js into the betterdiscord plugins folder, after I restarted discord it gave me the error "Cannot read property 'default' of undefined"

The UI can feel sluggish when large changes occur (like switching channels), or when there's a lot of emotes to replace. This should probably happen before fixing #5, which needs to additionally handle mutations to element data.

Ideally, the work should be put off until a requestAnimationFrame callback. It may also help to break work up into smaller chunks (<~3ms), though this should try avoid triggering a ton of ugly layout changes if possible.

Emote data could be extended to include a few things to help with browsing and searching for emotes. Some possibilities:

• category (to organize in emote picker)
• tags, keywords, aliases (similar to emoji)
• description (many Twitch emotes have these available)

As this project grows, improved modularity would make it easier to maintain. There are at least four versions of the core emote parsing implementation duplicated across several projects:

• KawaiiDiscord (userscript and BetterDiscord plugin)
• A fork of BetterDiscord with alternative emote parsing
• KawaiiEmotes plugin implementing the same for stock BetterDiscord

Factoring this and a few other things out into separate modules will eliminate the hassle of porting fixes between them, allow building for the different targets from a single set of source files, and allow for automated testing to avoid dumb regressions. Webpack seems like a nice choice of build system, and could also make bundling external libraries cleaner for BD plugins.

Add support for wildcard (*) emotes in addition to rolls. Basically, bring back the original roll behavior changed by 4024f75, using * instead of #. Also, implement suffix and substring matching (at least) as well.

• Prefix match :name*:
• Suffix match :*name:
• Substring match :*name*:

Also, now that "roll tables" would potentially become more complicated, determine whether building them ahead of time is worth doing. Roll resolution could be deferred to limit the impact of searching for an arbitrary wildcard match, showing the fallback emote until then (rollDefault), and giving the opportunity to animate the result as originally planned.