I've moved!
You can now find me at @Ori.
@ernest - I appreciate the heads up and echo the sentiments of @Perry and @minnieo.
Both kbin-code-highlighting and the supporting script, kbin-mod-options, continue to be functional on lab2.
@shazbot will need to take a look at the first 3 mods inside of kbin-megamod - it looks like in some instances they try to function before DOM is finished and only intermittently work on lab2. However, the megamod itself is functioning as intended.
Probably 50/50, maybe slightly more on the Reddit side of things, so 60/50 in favor of Reddit? While a lot of my old subs are here on the Fedi, a lot aren't, arguably most of the ones I spent most of my time in aren't. The ones that are present, are noticeably a lot quieter.
Depends on your mobile browser. There are numerous third-party chromium-based browsers that support mobile extensions, such as Opera. There's also Firefox that supports mobile extensions. In either of those situations, you'd simply install TamperMonkey. I do agree that Chome/Edge should bring extension support sooner rather than later.
0.4 was just merged to main. You should update automatically if you're on 0.2. If you want to update immediately, simply click here. Notes and examples have been updated in OP.
Worth noting that some of the changes in this version are to make it easier to integrate with @shazbot megamod.
Yep, I've looked at it, used it a bit. I feel as though the two projects are distinct enough that they could co-exist. Whereas megamod is a mod manager where you can toggle on/off, it becomes a burden for script writers to maintain two separate sets of options for their scripts - one for megamod and one for a standalone version.
In contrast, this script isn't intended to be installed as a userscript. Instead, it's to supplement other developers userscripts. A userscript that is setup to work with megamod could still utilize this script and simply lightens the load on the developer.
My reasoning is that I agree with @JohnEdwa and, subsequently, @SirPsychoMantis - at least partially. It makes sense for options to be standardized in one place, in this case the options menu. I also believe that if megamod does go mainstream, it's mod manager should be separate.
Hope that makes sense. ( っ- ‸ - c)
Well, I mean it works a little... But I think your main problem is on the .icon transform.
Version 0.2 released.
It is a breaking change, but I do believe it is better to get it out quickly before any known adoption. The major change is to add collapsibility. This change does require your header to be passed as the first argument to each 'Add' function. Example code has been updated, but the gist of it is to store your header in a variable and update your add calls to reference the variable in the first argument position.
Just took a look. With the previous version of kmo, it does in fact work when compatibility mode is enabled. I think that's probably the best solution to hope for without slowing down your own enhancements to the point of being a visual hindrance. Thanks for taking a look.
I just need to up my visual appearance game now. Your dropdown appearance and effect is much more visually appealing and while my implementation is meant to make mod options more accessible for would-be devs, it would be ideal to make it visually appealing as well.
Awesome. Thanks for this. Made a slight tweak to it - https://files.catbox.moe/y2497f.png
// replace lines 39-41
link.innerText = '📨';
link.className = 'item-link';
link.style.cssText += 'margin-left: 5px; font-size: 18px;';
And here I am putting together a simple script to allow collapsing of those pesky sidebars, lol! However, doesn't RES also handle settings in a similar was as is here? I think they open a new page entirely now, but it's still a dedicated button, no? At the very least it would be familiar to users of RES.
Version 0.2.2 released.
I noticed that KUP (Kbin Usability Pack) 0.2.1 by @Perry added some settings refactoring that hides the old .settings-list instead of updating in place. This unfortunately has a side-effect of causing script's settings that are slower, or wait on DOM to load, to be hidden instead of displayed with their new refactor.
In order to prevent this issue in the future, I've updated to create our own DIV and simply append it to the #settings.section DIV instead. Without KUP, you'll notice no difference in how settings are displayed from version 0.2.1, but if you're using KUP, it currently puts your options section at the top of the new section created by KUP. I imagine this will change if KUP moves to prepend instead of append. In my view, mod options should have always been last in any settings list solution, so I do hope that change is made at the very least.
thanks for using Leebra!
go to feed...