c4
c4 copied to clipboard
qqueue
Unfortunate: the the un4chan userscript toolkit
i.e., the non-ui parts of c4, so others can userscript without being tied to either 4chan's UI choices or c4's UI choices (as much as possible, anyway). unf for short.
I aiming for this library to be usable with polymer, so one could make a Material Design(tm) userscript on top. So far so good, though polymer itself might take some convincing to work within greasemonkey though (haven't tried it yet).
Still TODO is extracting the fancy new SharedWorker-based updater into something usable. I basically want to have an API like:
unf.data.subscribe board, tno, (thread) ->
ui.rerender-with-new-data thread
which should plug in to most MVWhatever libraries (polymer, react, mithril, etc) nicely. Then, just wrap this up in a separate buildscript/repository, add npm + publishing for greasemonkey @require, and it's ready for use, albeit probably buggy (like c4).
There are some other parts of c4 that might be worth extracting as well, such as the relative dates, lightbox/tooltips, the youtube api queue, and the posting logic. Once that's extracted, c4 is a pretty tiny codebase: some html templates, styles, and a bundle of hideous dom-mangling.
@saxamaphone69 , 4u.
as I said - why not move your helpers-thingies into some npm module as well, and require it both from unfortunate and from the other one?
You can expect great things in @qqueue... You just need to wait a bit : d
why not move your helpers-thingies into some npm module as well
I might, but after looking through the code several times, the helpers really aren't that much helpful, and they make the source ever-so-slightly-harder to read without familiarizing yourself with my idiosyncratic set of symbol-named functions. I might extract timing.co, but the other helper/utils seem pretty useless outside of the "hideous dom mangling" done in inlinereplies.co.
After much wrangling, I managed to get a <paper-button> from Polymer working within greasemonkey. I used [vulcanize][0] to get rid of the imports, then manually concatted the rest of the javascript into this:
https://gist.github.com/qqueue/0489a75a10caba0746f4
The userscript block (my code) starts at 18397 . Since it's running at document-start like c4 does, I just replaced the existing document.body and style with the output from vulcanize.
It didn't quite work at first, but after liberal application of console.log, I figured out that the weirdness around Greasemonkey's window and this context confuse some parts of the polymer library code that somehow define window.Polymer as function and var Polymer/this.Polymer as an object, presumably for legacy reasons. Changing window.Polymer to this.Polymer made everything (so far) work fine.
This means that my grand plan for polymer+unfortunate is likely feasible. I'll still need to to dig in to vulcanize and figure out how to output it in a userscript-friendly (styles as text, scripts inline) format, but fixing it to work with greasemonkey was at least a little easier than expected.
Interesting you got it working, the Polymer website doesn't even load correctly for me.
And that's on Nightly. Maybe it's finally time to start using Chrome (isn't it easier to create "apps" too using it)?
I'm getting the same breakage on polymer's site, though only if I have dom.webcomponents.enabled set to true in about:config. Do you have that turned on @saxamaphone69 ?
Re: chrome extensions, I've always planned to make c4 work in chrome eventally (I did have it working in tampermonkey at one point), but since my userbase has always been just me, I don't have a lot of incentive. One thing i do have incentive for is moving out of greasemonkey and into the jetpack addon API (i.e., firefox extension), which seems to have a lot better debug tooling than greasemonkey. I could also then intercept 4chan page loads in a less hacky manner, and make my SharedWorker use an actual file instead of a data URI. https://github.com/mozilla/jpm is probably worth a try.
One other spec I've been keeping track of lately is ServiceWorkers, which allows you to intercept requests for a given domain and mangle the responses however you want, all from a separate javascript worker thread. If you think about it, that's pretty much what I've turned greasemonkey into with the DOM replacement trick--given a URL and the original response, output whatever you want with the old content as input. While it's not built for site augmentation like greasemonkey/addon api is, it does have some interesting parallels.
Flipped the pref and the site now works. I must have set it when it first got announced for Firefox and never bothered reading up on it or something.
I only mention Chrome because as far as I know, you can actually debug and test a lot of things within Chrome's console and stuff. But, I'm not an expert. A solo Firefox add-on might be cool, as I would assume doing so would also allow you greater control and such. The only reason I mention Chrome is because from memory, you don't need to worry about fancy stuff, and you can pretty much create one with straight HTML/CSS/JS? I don't know. You guys are the expert, I just like sitting and watching, as I've said before. :hamburger:
@qqueue Please note that there's a 5$ fee to upload extensions to the store, and that "vanilla chrome" can't install non-store extensions (even in dev. mode). You need chromium or chrome canary to dev extensions. Yes, this is awful.