gwennie-chan posted:

Firefox 57/Quantum is in Beta currently. It fully releases in November. If you're a Firefox user, you'll need to delete Greasemonkey and install Tampermonkey from the Add-On website, otherwise you won't be able to use userscripts.

Yeah, my script flat out doesn't work on Greasemonkey's latest update and the last time I checked their migration information none of it was remotely relevant to Dynasty Thingifier. Though it looks like it needs some work to actually fully function on Tampermonkey anyways. When I switched over it had some strange issues. For some reason none of your settings, with the exception of text size and user posts, gets stored/loaded properly. (And there seems to be no errors logged in the console either.) It's going to be a bit before I get to that though. I'm far too busy playing through Danganronpa V3 at the moment.

last edited at Sep 30, 2017 2:51AM

Alice Cheshire posted:

gwennie-chan posted:

Firefox 57/Quantum is in Beta currently. It fully releases in November. If you're a Firefox user, you'll need to delete Greasemonkey and install Tampermonkey from the Add-On website, otherwise you won't be able to use userscripts.

Yeah, my script flat out doesn't work on Greasemonkey's latest update and the last time I checked their migration information none of it was remotely relevant to Dynasty Thingifier. Though it looks like it needs some work to actually fully function on Tampermonkey anyways. When I switched over it had some strange issues. For some reason none of your settings, with the exception of text size and user posts, gets stored/loaded properly. (And there seems to be no errors logged in the console either.) It's going to be a bit before I get to that though. I'm far too busy playing through Danganronpa V3 at the moment.

Yeah in Tampermonkey it isn't fully operational but I'm writing this reply in place so at least it's partially-functional. It seems the largest issue is just saving local option values (and the invocation on refresh based on those values). Regardless we'll get there!

gwennie-chan posted:

Yeah in Tampermonkey it isn't fully operational but I'm writing this reply in place so at least it's partially-functional. It seems the largest issue is just saving local option values (and the invocation on refresh based on those values). Regardless we'll get there!

There seems to be two issues. One is an issue with the @require for jQuery, though I've intended to remove jQuery for quite awhile anyways. Still not remotely sure why that is an issue however. The options values are a stranger issue though. There's no errors regarding them and the values get stored correctly but for some reason they're not being read. (Well not correctly at least. The "your posts" thing works correctly and the font size slider works and loads, although the slider itself doesn't reflect your font size properly.) I'm finished with Danganronpa V3 now so I should be able to find some time soon to get these issues fixed up hopefully.

And in the process I should try to remember to get a Github repository setup for it since I apparently totally spaced that, lol. Changing things over to a Github repository should allow me to restructure things a bit too. I should be able to split the stylesheet bits off from the script and add them to the repo as a separate stylesheet which will help with keeping things organized a bit better.

last edited at Oct 6, 2017 10:44AM

So, do I need to install something new or you will fix it so it will still work on Greasemonkey? Also I'm not sure if it is related in any way to those new updates or it's something on my (piece of crap) side, but since the mention of changes, Thingifer seems to lag and slow down dynasty a lot, I had to disable it, because it was getting ridiculous. I'm only turning it on when I'm responding to someone.

Nevri posted:

So, do I need to install something new or you will fix it so it will still work on Greasemonkey? Also I'm not sure if it is related in any way to those new updates or it's something on my (piece of crap) side, but since the mention of changes, Thingifer seems to lag and slow down dynasty a lot, I had to disable it, because it was getting ridiculous. I'm only turning it on when I'm responding to someone.

Chances are I'm going to have to just not support GreaseMonkey. The changes they're making are a totally different focus than simplistic scripts like the Thingifier. I'd recommend switching over to Tampermonkey which is a little different but should work out the same once I get the current issues fixed. And if it's lagging you may try disabling the magnifier if you have it enabled. It seems to be having issues when enabled at the moment for me, though I don't know if this is your issue for certain. (It's definitely the single laggiest part of the script though. The way I did it definitely isn't the best way. CSS isn't intended to be abused the way I'm abusing it for the magnifier, lol.)

Alice Cheshire

I'm finished with Danganronpa V3 now so I should be able to find some time soon to get these issues fixed up hopefully.

Well this is just not going well at all. For fuck sake. I spent like six hours the other day reworking like 2/3rds of the script before going to bed. At that point the script wasn't quite back in working order but I knew what was broken. Next day it's seemingly totally randomly like 10x more broken and I didn't end up working on it for several days because I wasn't feeling well and couldn't concentrate.

So I decided to try and redo my work today. I've had a lot more success at least. It's kinda sort of working. Except for some reason it doesn't correctly activate things according to your settings when you load a page properly and I can't figure out why. It also doesn't do your quoting correctly but I think I overlooked something on that bit. The config bit is seriously pissing me off though. Unless I set a 100ms timer before loading the config it simply doesn't actually do shit with your config at all. If I do a 100ms timer first then it ticks the boxes in the menu more or less correctly (it wasn't at first though, looks to now at least other than the pending tags option for some random as fuck reason) but despite ticking shit correctly it doesn't actually activate those options like it should and I have no idea why.

Like just as an example:

function configload() {
//Only run once the page is loaded
$(document).ready(function() {
    //Deal with our current menu state
    menuclose("load");

    setTimeout(function() {

       //Check if the fixed navbar is enabled
        if (DT.navbar) {
            $('#thingifier-fixed-navbar').click();
        }

This is the config loading code regarding just the fixed navbar. If DT.navbar is true then it clicks it after 100ms. This happens correctly and it ticks the navbar option in the menu. For some reason, however, the code for actually clicking it no longer runs like it should.

//Fixed navbar option
$('#thingifier-fixed-navbar').click(function() {
    DT.navbar = $('#thingifier-fixed-navbar').is(":checked");
    setItem("DT", DT);
    console.log("Navbar option clicked");
    if (DT.navbar) {
        $('.navbar').addClass('navbar-fixed');
        $('div.forum_post').css("padding-top", 40);
        $("<div class=\"nav-padding\"></div>").insertAfter(".navbar");
    } else {
        $('.navbar').removeClass('navbar-fixed');
        $('div.forum_post').css("padding-top", 0);
        $('div.nav-padding').remove();
    }
});    

Even though it's clicked, this never runs. If you click it yourself though it does run like it should. I have no idea why this isn't working though because it used to work.

So yeah, update on this is that I don't know when it'll be done since it's being an enormous uncooperative pile of shit for seemingly no reason. I did however get around to figuring out how to get it uploaded to Github. Personally I don't use Git, I use Mercurial (specifically TortoiseHG) and had to use this tutorial to figure out how to get it to cooperate. Should, however, be setup for others, such as gwennie-chan, to collaborate now if they so wish.

Well good you're making progress. I'm reminded of just how much I can't code.

Well good you're making progress.

Yeah, for all the good it's accomplishing right now though. I'm thinking that at this point I may just have to go ahead and recode everything from scratch like I was initially planning but without worrying about discarding jQuery and just using the other one as a template so I don't have to just recreate everything from scratch so much as retype it all while carefully considering the code I'm reading over, line by line.

I'm reminded of just how much I can't code.

Just keep practicing at it and you'll get better. Everyone starts out knowing basically nothing about coding.

I'm reminded of just how much I can't code.

Just keep practicing at it and you'll get better. Everyone starts out knowing basically nothing about coding.

Honestly though, JavaScript makes my brain do funny things. I just doesn't make sense.

Thanks for putting it on Github. I'm not very familiar with jQuery but I'll try fiddling with it when I need a break from boring work stuff :)

last edited at Oct 12, 2017 5:38PM

gwennie-chan posted:

Honestly though, JavaScript makes my brain do funny things. I just doesn't make sense.

In my experience it's a lot easier to understand than most languages. Though it has some really strange gotchas that you have to learn to work around at times.

cyricc posted:

Thanks for putting it on Github. I'm not very familiar with jQuery but I'll try fiddling with it when I need a break from boring work stuff :)

jQuery's a bit easier to learn for most people than normal Javascript. Most of what we're using jQuery here for though has fairly straightforward equivalents in Javascript though. For example jQuery's $() operator is basically just an extension of Javascript's document.getElement(s)By(ClassName/Id/TagName) operations. Then there's a lot of stuff that's actually really no simpler in jQuery than it is in Javascript. jQuery's addClass() and removeClass() are basically identical to Javascript's classList.add() and classList.remove(). Stuff like this:

$('div.forum_post').css("padding-top", 40);    

is only marginally simpler than the Javascript equivalent of:

let el = document.getElementsByClassName("forum_post")
then running this on each of those elements through a loop:
el[i].style.paddingTop = "40px";    

Something like $('#thingifier-fixed-navbar').is(":checked") is the same as document.getElementById("thingifier-fixed-navbar").checked;. The $().click(function() {}) stuff is basically the same as element.addEventListener("click", function() {}). The $().html() command is the equivalent of element.innerHTML or element.outerHTML, I forget which off the top of my head but I believe it's the first. (Same with $().text() being equivalent to element.innerText.) $().val() is the same as element.value.

Of course there are some things that don't have a simple equivalent, as far as I know, in Javascript though. $(el1).insertAfter(el2), for example, doesn't have an easy equivalent in standard Javascript. The element.appendChild(el) command is the closest but it's definitely not the same thing. In order to emulate it you'd need something a bit more complicated which takes the first element's parent, disassembles its pieces, then reassembles it while inserting the new element where you want it.

Then there's other such as $("#thingifier-options").animate({width:'toggle', height:'toggle'},0); and $("#magnifier-submenu-toggle").fadeToggle(0); which I don't believe have any actual equivalents in standard Javascript and I'm not sure they can really be emulated without some complicated code.

As you can see though, most jQuery commands (at least the ones used in the Thingifier) are basically just short versions of basic Javascript commands. Although they pretty consistently perform far worse than the Javascript equivalents in my experience. Hopefully this is a good enough reference that you'll get your bearings on things pretty easily.

Since Dynasty already has a jQuery script on the site I'll probably leave some of the jQuery stuff in here, specifically the difficult to replace code, but I'd actually like to eventually get rid of as much of the jQuery code as possible. At the time I wrote this I was still learning Javascript so I ended up relying on jQuery's selectors and event listeners since they were a lot simpler and easier to remember than Javascript's.

I think I've resolved the issue with configuration not being loaded. The root cause appears to be a race condition (OH GOOD THESE DON'T GIVE ME NIGHTMARES AT ALL). I put in a pull request detailing the changes, though you might want to check yourself whether something somewhere else got broken since I don't know what's supposed to be working or not.

edit: Oh yeah, and you might want to use your own diff tool to compare the changes, Github's web diff really does not know how to deal with moving large blocks of code around. It thinks I've made hundreds of lines of changes when I really just changed and moved a few lines around.

edit 2: Though, the more I look at it the more I get confused about how it was broken in the first place. Why does $(document).ready sometimes fire before parts of the script above it? Wtf jQuery.

last edited at Oct 12, 2017 7:09PM

I'll have a closer look later (I only quickly skimmed over it just now) but yeah, jQuery does some odd things at times. The script is really weirdly structured in places too due to things not wanting to cooperate. I've got stuff just running immediately, running in jQuery's $(document).ready, and an anonymous (function() {})() somewhere iirc. Then I also had a $(document).ready inside another function at one point for some reason. Really not sure why I thought that was a good idea.

Edit: Also now that I think of it, there was an issue I vaguely remember way back early in the script's life involving a race condition. I remember that I fixed that with the // @run-at document-end setting in the script header. I can't recall but that may have been a settings thing too. (Edit2: I quickly tested removing that line to see what happened and got the wonderfully confusing result of it loading my settings perfectly fine one time then going back to not loading them, lol...)

last edited at Oct 12, 2017 7:49PM

Alright, had a chance to test it out. Appears to work fine from my end of things, at least on Firefox. The only remaining issues (quoting and setting a link for your own posts. I'm not entirely certain what got screwed up with quoting yet but setting a link for your own posts seems to be a messed up check on my end. It's still considered set even when it's not which shouldn't happen) are ones mostly unrelated to the settings other than the fact the setting for gwennie-chan's addition to the script still isn't saving/loading properly. Must be something I'm overlooking on that one though.

...the setting for gwennie-chan's addition to the script still isn't saving/loading properly. Must be something I'm overlooking on that one though.

Right, I missed that one since it wasn't in the same place as the other event handler definitions. The event handler for thingifier-pending-suggestions should be moved into the setmenuhandlers function. It's also got a preexisting bug where the setting will only save if you're on the suggestions page, so the first few lines should be changed to

        $('#thingifier-pending-suggestions').change(function() {
            DT.pendtags = $(this).is(":checked"); //Updated to use new settings object
            setItem("DT", DT); //Saves changed settings
            if (pageurl.match(/user\/suggestions/)) {
                if (DT.pendtags) { //Updated to use new settings object
                ...

Fixing the quoting was simple enough. It was an oversight on my end with the getItem() function I made. It uses JSON.parse() which apparently errors out on items that are just a simple value, such as a username or a quote link. Though I should probably consider using sessionStorage there instead of localStorage anyways. Fixing the link for your own posts was a dumb oversight on my end but an easy fix. The code needed to be if (DT.yourid == "Not set!") { but instead it was if (DT.yourid == "Not Set") {. Needed an exclamation point and a lowercase 's' instead.

The thing with gwennie-chan's pending tags function I'm really not certain on however. In the config loading section the code set to click the checkbox on page load is the same as the other checkboxes and targets the correct element and it even checks it properly now after a quick repositioning of the code that sets the value. (The way I previously had it, it would only actually change the value in your config if you were on the user/suggestions page.) But despite that it doesn't automatically run the code like it should if the box gets checked on page load. It still only does it if you manually check it like the previous issue with the other options. The strange part is that the code for it was one of the ones you change ($('#thingifier-pending-suggestions').change(function() {) to use change instead of the click.

Change is (finally, after way too long trying to figure out why it wasn't cooperating) merged into the one on Github now.

cyricc posted:

Right, I missed that one since it wasn't in the same place as the other event handler definitions. The event handler for thingifier-pending-suggestions should be moved into the setmenuhandlers function. It's also got a preexisting bug where the setting will only save if you're on the suggestions page, so the first few lines should be changed to

        $('#thingifier-pending-suggestions').change(function() {
            DT.pendtags = $(this).is(":checked"); //Updated to use new settings object
            setItem("DT", DT); //Saves changed settings
            if (pageurl.match(/user\/suggestions/)) {
                if (DT.pendtags) { //Updated to use new settings object
                ...

What you've got there is what's already in the script. (Including the exact changes I'd just posted about actually, lol.) It was already using .change in the version I'd merged in so I assumed that was you. .change still results in the same issue though for me.

Edit: As for its location, I actually agree. That's where gwennie-chan put it and I never got around to moving it since I'd been planning on recoding everything.

The event handler for thingifier-pending-suggestions should be moved into the setmenuhandlers function.

I overlooked this bit before my edit. Are you talking about the configload portion or the change event itself?

Edit2: Neat. Apparently Greasyfork doesn't allow // @downloadURL in the header. I set one when I pushed your changes and my new ones to Github and uploaded that new version to Greasyfork thinking that it might just start updating Github's version now but nope. They just removed the tag without even telling me. Checked the script on Chrome though and it appears things are working correctly there too thoguh at least.

last edited at Oct 12, 2017 11:12PM

I sent up another PR. It's just moving the change event.

Edit: I haven't tested it with actual suggested tags, but the debugger does seem to indicate that the correct code path gets executed regardless of whether the option is clicked while on the suggestion page, or if enabled by a saved config. (i.e. it enters the if (DT.pendtags) block every time I visit suggestions as long as the option is enabled)

last edited at Oct 12, 2017 11:47PM

Alice, pending tags seems to save but not activate on load unless newly-set on the suggestions status page.

gwennie-chan posted:

Alice, pending tags seems to save but not activate on load unless newly-set on the suggestions status page.

Also you should totally remove the non-SSL includes because dynasty only does https now.

cyricc posted:

I sent up another PR. It's just moving the change event.

Edit: I haven't tested it with actual suggested tags, but the debugger does seem to indicate that the correct code path gets executed regardless of whether the option is clicked while on the suggestion page, or if enabled by a saved config. (i.e. it enters the if (DT.pendtags) block every time I visit suggestions as long as the option is enabled)

Merged it. It appears to work fine on my end too. Also just a note for any future merges: You should always increment the version in the header by 0.01 as well as the ver variable (it's close to the header so it'll be fairly easy to find) in the future so anyone who installs from Github will update properly.

gwennie-chan posted:

Also you should totally remove the non-SSL includes because dynasty only does https now.

Ah, does it only do https now? I haven't really checked but I think it still did http and https when I added that. Either that or I just didn't think to check. I've got it fixed on my local copy but figuring out how to get Mercurial to actually freaking cooperate will take awhile and I don't really have the time to figure out its incredibly vague error of abort: pushing refs/heads/master overwrites d289dae31733 right now.

Apparently when I merge changes on Github and download those changes through Mercurial I have to explicitly tell it to subsequently merge those changes with my local files for some reason before I can modify them in any way. If I don't happen to do that first then it's a complete and utter mess trying to resolve whatever the issue is.

This is a total mess due to me trying to figure out how to resolve the issue. I'm having issues figuring out how to rollback a change. I found a prune option which just seems to hide changes and there's "backout" or "revert all files" but neither of those seems to actually do anything when I try them.

Alice Cheshire posted:
Apparently when I merge changes on Github and download those changes through Mercurial I have to explicitly tell it to subsequently merge those changes with my local files for some reason before I can modify them in any way. If I don't happen to do that first then it's a complete and utter mess trying to resolve whatever the issue is.

Ah yeah, learning how Git works is kind of a... hostile experience, to put it mildly. I'm not sure what you mean by Mercurial (a Git plugin for a Mercurial client, I'm guessing?), but sounds like it does not automatically merge into your local workspace after fetching from the remote repository (as git pull does). Maybe there is a differently named command that does this?

However, in the case where you have made modifications locally before merging changes from Github, you should be able to resolve this by committing locally -> fetch + merge from Github -> push, provided you resolve whatever merge conflicts it might throw at you. Alternatively you could push with --force to just overwrite the Github history with your local repo, if you're not concerned about possibly wiping out commits.

This is a total mess due to me trying to figure out how to resolve the issue. I'm having issues figuring out how to rollback a change. I found a prune option which just seems to hide changes and there's "backout" or "revert all files" but neither of those seems to actually do anything when I try them.

How to rollback a change depends on how far it's gotten in the whole Git process (stage -> commit -> push). Each command is, naturally, unintuitively named:

• To revert unstaged changes: git checkout -- <file or folder> (I'm guessing this is what "revert all files" does in your client)
• To revert staged changes: git reset --hard
• To revert to a local commit: git reset --hard <commit> (e.g. git reset --hard HEAD~1 reverts to the commit before the latest one)
• To undo a specific commit in the middle of the history: git revert or rebase (this is more complicated so I depend on a GUI for these)
• To revert a commit that has already been pushed to Github: revert the local commit with git reset as above, then push with the --force option

last edited at Oct 13, 2017 2:49AM

cyricc posted:

Ah yeah, learning how Git works is kind of a... hostile experience, to put it mildly. I'm not sure what you mean by Mercurial (a Git plugin for a Mercurial client, I'm guessing?), but sounds like it does not automatically merge into your local workspace after fetching from the remote repository (as git pull does). Maybe there is a differently named command that does this?

I'm using hggit which is one of the default plugins for Mercurial. And I'm not sure but I think this may be what I needed to do:

The default option was "none" and this sounds more or less correct. I'll have to try it out next chance I get to test it though.

How to rollback a change depends on how far it's gotten in the whole Git process (stage -> commit -> push). Each command is, naturally, unintuitively named:

• To revert unstaged changes: git checkout -- <file or folder> (I'm guessing this is what "revert all files" does in your client)
• To revert staged changes: git reset --hard
• To revert to a local commit: git reset --hard <commit> (e.g. git reset --hard HEAD~1 reverts to the commit before the latest one)
• To undo a specific commit in the middle of the history: git revert or rebase (this is more complicated so I depend on a GUI for these)
• To revert a commit that has already been pushed to Github: revert the local commit with git reset as above, then push with the --force option

It's just local commits I'm trying to revert. Basically what happens is that I merge your changes on Github then when I sync through Mercurial it considers those changes to not be the main branch for some reason. So if I don't merge them then any changes I make will refuse to push to Github if I try. So what I need to figure out is how to revert back to the point where I downloaded your changes so I can properly get them merged with the main branch locally so I can subsequently change things and actually push them to Github when I'm done. I'm not entirely certain which of those you described this would fall under. I think it may be the last one though.

I've read that Git isn't the most user friendly thing out there but I wasn't expecting to stumble about with it quite this badly, lol.

Alice Cheshire posted:

I'm using hggit which is one of the default plugins for Mercurial. And I'm not sure but I think this may be what I needed to do:

The default option was "none" and this sounds more or less correct. I'll have to try it out next chance I get to test it though.

Yeah, you definitely want to be using the second option (first is equivalent to git fetch, which by itself does not actually apply any changes to your local repository).

It's just local commits I'm trying to revert. Basically what happens is that I merge your changes on Github then when I sync through Mercurial it considers those changes to not be the main branch for some reason. So if I don't merge them then any changes I make will refuse to push to Github if I try. So what I need to figure out is how to revert back to the point where I downloaded your changes so I can properly get them merged with the main branch locally so I can subsequently change things and actually push them to Github when I'm done. I'm not entirely certain which of those you described this would fall under. I think it may be the last one though.

You should be able to get it to push by pull + update from Github, then doing the push. Although this does result in a more spaghetti commit history and you get to deal with possible merge conflicts. To do what you're describing, you could reset --hard to the commit before you made your local modifications, then pull + update, then reapply the changes. Hopefully your client has an easy way to do this, perhaps by right-clicking the commit and choosing a "Reset to this" command? Just make sure to save your changes elsewhere before you do this (you can actually rebase to do this without losing changes, but, uh.. let's not go there for now, tis a silly place).

last edited at Oct 13, 2017 3:00AM

cyricc posted:

You should be able to get it to push by pull + update from Github, then doing the push. Although this does result in a more spaghetti commit history and you get to deal with possible merge conflicts. To do what you're describing, you could reset --hard to the commit before you made your local modifications, then pull + update, then reapply the changes. Hopefully your client has an easy way to do this, perhaps by right-clicking the commit and choosing a "Reset to this" command? Just make sure to save your changes elsewhere before you do this (you can actually rebase to do this without losing changes, but, uh.. let's not go there for now, tis a silly place).

You'd think there'd just be a "revert to this commit" option in the context menu or something but it doesn't really seem like it. And I can do Git commands in Mercurial's console but it gives an error when I try:

Not entirely certain what this means and Git's help page on the reset command doesn't have any functional examples (a very common issue with documentation for most programming related things in my experience) that might indicate what parameter I'm messing up and how.