[Userscript] Danbooru EX

Danbooru EX is a userscript that adds a variety of enhancements and new features to Danbooru, to make the site faster and easier to use. See https://github.com/evazion/danbooru-ex for a full overview with demos of what it does.

Demos

Thumbnail previews: https://gfycat.com/VelvetyWeakKangaroo
Preview panel: https://gfycat.com/FamousPastItalianbrownbear
Tag scripting: https://gfycat.com/AnyNewIrukandjijellyfish

Installation

Chrome: Install Tampermonkey
Firefox: Install Greasemonkey

Install this script: https://github.com/evazion/danbooru-ex/raw/stable/dist/danbooru-ex.user.js.

To configure the script, go to My Account > Settings > EX Settings, or click the Settings link at the very bottom of the page.

Main features

• Search bar and mode menu available on every page.

• Thumbnail previews: hover over any thumbnail or post #1234 link to popup a large image preview.

• Preview panel: Select Preview from the Mode menu then click a thumbnail. A panel will appear showing you the full post without leaving the page.

• Redesigned tag script mode: Clicking thumbnails selects the post and opens a preview instead of applying tags immediately. After your posts are selected, click Apply or press Shift+A to apply tags. This helps you avoid mistagging posts, lets you select posts in bulk, and lets you see the full image as you work.

• Resizeable tag sidebar: collapse it to get more space, or expand it to read long tags that normally wrap around the tag list.

• Colorized tags in the wiki and in the forum.

• Visible comment scores and extra post info.

• Many more: see https://github.com/evazion/danbooru-ex for the full list.

Releases

• v2284 (2016-11-11): https://github.com/evazion/danbooru-ex/blob/v2284/dist/danbooru-ex.user.js

Changelog

Can you give us a screenshot, maybe? Just to make sure. Or this script won't affect Db's appearance at all?

Check the webm in the OP. I'll post some more in a sec.

Oh so you're the other person who was mass adding the greyscale tag.

On a more serious note, how much use would this be for everyday tagging? Sure it's useful for removing mass vandalism, but that doesn't happen often, and for other uses greyscale is the only tag I know of that is:
- Heavily underused
AND
- Possible to bring up searches where just about every image wants the tag to be added (in this case by artists/pools that are almost exclusively greyscale)
AND
- You can usually tell from the quickest of glances at thumbnail only that the tag wants adding to that image, with a fail rate of <1 in 100 if you pay full attention when scanning through.

If all three of those conditions aren't met, it becomes quicker to just skim through using the inbuilt tag scripts to tagging images that visibly match the tag. The only tags that I can think of that meet both the latter two are *koma, comic, greyscale, monochrome, sepia and blank_page. And of those, only greyscale is very much undertagged (although far less so now than it was a few months ago).

The other situations it would be useful are those where having a certain combination of tags means that another tag must exist, but:
If tag a -> tag b then an implication is better
Tag a + tag b -> tag c is extremely rare, and although where it does occur in very large quantities then this would be useful, it's probably generally quicker just to use the existing tag script. Using mousekeys for clicking makes that almost as fast as this and far more precise.
tag a -tag b or -tag a and -tag b -> tag c relies on every image being tagged with tag b (and tag a in the second one) when it should. Which is never the case.

Yeah, greyscale is an ideal case, not the typical one. But mass tagging is not all this is intended for. A lot of it is just miscellaneous small efficiency gains:

• Using Alt+S/Q/E to instantly rerate a post.
• Using Shift+0 to jump straight to the last page.
• Using V and T to quickly pop in and out of tag script mode, for quick edits.
• Using T to focus the tag script box to adjust your script quickly.
• Being able to middle click posts in tag script mode.
• Being able to edit your tag script without scrolling back up and losing your place.
• Being able to always see your active tag script (handy when you have several).
• Being able to select posts first and apply the script after, so you can double-check before making mistakes.

Tag a + tag b -> tag c is extremely rare, and although where it does occur in very large quantities then this would be useful, it's probably generally quicker just to use the existing tag script. Using mousekeys for clicking makes that almost as fast as this and far more precise.

sukuna_shinmyoumaru hat bowl -bowl_hat is one I saw recently. You can't do full pages, but sometimes you find chunks where you can select several in one go. And personally individual clicks are less precise for me, I always have misclicks and have to undo things. Faster ways of undoing mistakes is something I want to work on next.

This is a low-priority item, and it may not be worth your effort, but could you modify how the tag script function sends PUT requests so that when "source:" is seen, it sends that string to post['source'] instead of post['tag_string']...?

Reference:

Forum Post 118649

On the other hand, it may be more useful to modify how Danbooru interprets that string in the Tag Script function then trying to patch that error with a Javascript addon... Thoughts?

Hmm, looking at it, it'd be easier to do server-side. That's how rating: / parent: / pool: metatags are handled. That would let source: work in the normal edit box too. issue #2664.

New version:

Demo: https://gfycat.com/AptIllustriousHippopotamus

Make section headings collapsible on wiki pages

• Useful for collapsing long lists of tags so you don't have to scroll up and down as much.

Add a Table of Contents to long wiki pages.

• Idea taken from topic #13166. Automatically adds a table of contents at the top of long wiki pages.

Fix middle clicking on Related Tags

• Normally when you're editing tags and you middle click on a tag in the Related Tags list, it just adds the tag. I hate this, it keeps you from looking up tags quickly. This makes middle click properly open the tag in a new window.

Now if we only had the ability to add thumbnail images with links to those images in the Wiki ...

Would that be worth making a feature request for though...?

BrokenEagle98 said:

Now if we only had the ability to add thumbnail images with links to those images in the Wiki ...

You mean issue #2538 or something else?

Ah snap... yes, I was looking for that issue but couldn't find it....

That would definitely be an improvement for wikis, however if possible I'd like to go a step further.

https://e621.net/help/show/dtext

That shows thumb #12345 popping up a thumbnail for a picture. There are a few wikis I can think off the top of my head where that would be useful. All of the breast size wikis for instance: flat chest, small breasts, medium breasts, etc. Those wikis have a lot of post links for size comparison, but that requires clicking on each one and waiting for the page to load. It would instead be more useful if a bunch of clickable thumbnails were shown so that users could see a preview of the image before clicking on it, in the same way that clickable thumbnails are more useful on the posts page as opposed to a bunch of clickable "post #####" hyperlinks.

As an alternative to the above (since that requires access to the posts class to get the thumbnail URL), maybe offer some kind of mnemonic that would place something like...

<div style="width: 150px; height: 300px; overflow: hidden">
 <a href=http://danbooru.donmai.us/posts/2480713>
  <img src="http://danbooru.donmai.us/data/db4cd6f8a82812a19fa882cfe6cc55d8.jpg" width="645" height="904" style="margin: -100px -200px">
 </a>
</div>

...which looks like...

https://img42.com/MtYKr

...in the HTML after the DText gets rendered. The above option offers a number of pros, such as being able to show a cropped version of an image instead of just the thumbnail image (most thumbnails aren't very illustrative). A potential con is that it could be abused to point to extremely large images causing pages to load slowly.

An example mnemonic could be...
#thumb(width,height,imgsource,imgwidth,imgheight,marginx,marginy,htmllink)

Anyways, I've derailed this topic enough. I'll just leave the above, and we can create a new topic if there's interest.

New release: https://github.com/evazion/danbooru-ex/raw/stable/danbooru.user.js

Show thumbnail previews when hovering over a post #1234 link. (Demo)

This discussion just reminded me of a userscript I wrote like seven years ago that did something like this (topic #2885). But that code is long since bit rotten, so I rewrote it. IIRC my old script was fancier and had the full image with tags and metadata and stuff. I may add that later.

Added to the list in about:userscripts.

Ah, that's pretty cool. I'm assuming your script does something like send a JSON request for that post and then pulls up a thumbnail based on the data it gets back...?

Yes, exactly. It's not as smart as it could be - it does a new request every single time you mouseover a link instead of just once. But it seems to work okay.

Also, I'm open to feature requests / feedback / bug reports on this script. Part of my goal here is to test out ideas for potential UI improvements, see how well they work in practice, before seeing about incorporating them into the base site.

The following has been a long desired feature request of mine. I don't know if it'd be easier to prototype it out first with your Javascript functionality or go straight to a Danbooru feature request...?

Anyways, I've tried the forum subscribe function, and I suppose it works if you don't visit that site that often, but is otherwise useless as it only e-mails once a day. Even if it did e-mail more often, I'd rather have something on the website, that way I don't have to keep going back to the tab with the forum open and mash the F5 button every couple of minutes in order to track a forum topic. The italicizing of the forum link is likewise useless, as it keeps italicized unless I mark all as read, and even then it updates for any topic updated/created and not the ones I'm interested in.

So the idea would be to add the forum topic # and it's "updated_at" timestamp to a maintained list (maybe with a cookie...?) when I subscribe to it, and each time I navigate to a different page on Danbooru, it'd poll those topics for me to see if they've been updated. If so, indicate that along with the total number of my tracked forum topics that have been updated, then offer some way to see those topics titles and a way to navigate to them. As a touchup item, each time I visit a tracked forum topic, it would update the "updated_at" timestamp.

Corollary to that is being able to track comments on any post. Instead of having to check on a post that I've commented on every once in a while to see if someone has responded, it'd be nice to have the same thing as described above for forum topics. That's a little more tricky though as that requires using the list function as opposed to the show function, but can be simplified by doing something like...

http://danbooru.donmai.us/comments.json?group_by=comment&search[post_id]=2479847&limit=1

...and grabbing the latest "created_at" timestamp.

For both of the above, they could be set to be subscribed either manually and/or automatically (like if I leave a comment/forum post).

Would be nice if the e keybind worked to open the edit page on artist and wiki pages. Also, when you search an artist and then click the Artist page next to Wiki if e took you to the editing page as well.

Also tag suggestions when using the search box at the top of each page.

@chodorov:

Actually it looks like 'e' already is edit on wiki pages. TIL. My userscript broke it though since I didn't know it existed. Will fix it.

The broken autocomplete is a known issue, it's been annoying me too, will fix it when I get a chance.

@BrokenEagle98:

Better forum/comment notifications are both things I've wanted for a long time as well. I've had the same issues: forum subscriptions are worthless, and manually checking for new comments is a big hassle.

Some kind of notification system / event feed in general is something I've always wanted. There are a lot of things I'd like to be notified about:

• New posts by my favorite artists (yes, we have tag subscriptions/saved searches, but you still have to remember to check your profile for them)
• New forum posts in threads I've posted in.
• New comments in threads I've posted in.
• New comments on my uploads.
• New notes/translations on my uploads.
• New translations in general for posts I'm hoping will be translated.
• Other new things with my uploads: flags, deletions, maybe gaining favorites.

I think some of this could be doable in a userscript, essentially how you describe. Basically: keep a list of posts/comment threads/forum topics you're interested in, poll them for changes on every page load, compare them with what was seen last check to see if they changed. Notifications could be sent via DMail, or maybe even via a little Facebook-esque notification icon at the top of the page.

Doing this in a userscript is very hacky, of course. The other thought I had was to basically 1) write a little bot that continuously scrapes everything from the API 2) send out updates for every new comment / post change / etc to Google Pub/Sub 3) have another bot that polls Pub/Sub, compares the incoming updates against people's subscriptions, and sends out DMail notices 4) have a web API for that bot so the userscript can communicate with it and tell it what to subscribe to.

This is something I've thought about a lot and wanted for a long time myself. So I can't make any promises, but I'm very interested in seeing what I can do about it.

evazion said:

manually checking for new comments is a big hassle.

You mean, see new comments for posts you've commented on? search comments for comm:evazion.

That said, event feed probably should find its way to the main codebase. I had the same idea for flags at forum #119735. Making it configurable for other events would also make a nice addition to gold+ benefits. I'll raise the issue.

E: issue #2672.