kbin Enhancement Suite: a community-curated script manager that lets you customize your kbin experience
A couple of weeks ago, @shazbot made this post about a project that they were working on. Since then, @shazbot, @ori, @minnieo and I have been hard at work, and we are excited to finally announce the official release of kbin Enhancement Suite (KES)!
kbin has seen an explosion of user-made add-ons, but keeping track of them in one place, letting them share settings with one another, and toggling them on and off can be a challenge. KES is an expandable add-on manager that aims to rectify this by providing a unified interface and framework for script makers to collaborate, and letting you use them all in one place.
KES brings together userscripts from the community, with a built-in settings menu that lets you tailor your experience to your liking. It also offers a flexible framework that empowers script authors to effortlessly integrate scripts into KES and set up custom input fields with no additional code.
KES gives you a single window onto a collection of enhancements that is growing by the day. And those features can be added to by you!
We’ve focused on making customizing your kbin experience as easy as possible, whether you are on mobile or desktop. After we sort out the bug reports from this release, we plan on adding many more features! Here’s what we have so far:
Once KES is successfully installed, access the settings menu by clicking on the wrench icon located at the top-right corner next to your username. From there, you can enable the features you like, and customize your browsing experience.
More information
For bug reports and feature requests, visit our GitHub repository’s issues page. If you have any questions or need assistance, don’t hesitate to ask here or make a post on /m/enhancement!
Developers
If you are a userscript author, we’d love it if you could try porting your userscripts into KES, or try writing completely new ones for it! @shazbot has made it easy to integrate your scripts: you just need to add your script’s information to manifest.json, make a few small modifications to your script, add it all to the GitHub repository, and you’re good to go!
KES benefits:
Turnkey integration: a simple, declarative framework for dynamically adding features to the UI without touching the underlying code
Sharing of user-defined settings through script namespaces: access your script settings, and those from other scripts, through a well-defined object
Automatically responds to infinite scroll and page reload events
Attribution of script authors
Easily toggle scripts on/off
Explore KES’s documentation here to get started. If you have any questions, feel free to reach out here, on /m/enhancement, or at our GitHub repository.
Very cool. I hope that some of these nice features will eventually be upstreamed/ported to vanilla Kbin, but it's great to already have a strong community of add-ons. Keep up the great work!
Ernest is definitely aware of some of these (he's been spying on us over at @kbinStyles lol), it'd be great to have them be built in! I love that we've got so many people making mods for kbin, it allows you to make things at a super quick pace
I appreciate the effort, but am curious as to why this is needed in an open source project. I would much prefer these types of things be part of the default experience instead of a third party solution. Is this just my own ignorance showing? Is there a reason to handle this with a third party tool instead of a pull request in the kbin code?
RES was needed because reddit went closed source and didn't prioritize the things people wanted.
Please don't take my comment as being ungrateful for the great work you've done. It's just an idle question that will probably serve only to demonstrate how little I know. haha
Honestly, it's a great question! While kbin is open source, making userscripts allows you to iterate on changes and get updates out very quickly. It's also much easier to start making userscripts than it is to contribute directly to the project, since you only really need to be familiar with JS, HTML, and CSS. To contribute to kbin, you need to be familiar with PHP and Twig, and set up your own instance for testing your changes.
Plus, while kbin is open source, not every single change will be merged, and there will likely always be features "missing" from it. Userscripts also give you a ton of freedom and flexibility in how you use sites, so you could make crazy changes that aren't remotely possible to merge into it.
I'll also add, from the POV of a kbin contributor (not writing code, but triaging issues, answering questions, opening a lot of tickets, etc) that it makes sense to have user scripts to add some settings that are like.....too much.
For example, I proposed that we have a preference for "delay before the user profile popover shows" and the user can enter a time between 0ms and 15 seconds. It was decided this is too much customization to have built in, and maybe we can do "off," "slow," and "fast." But this seems like a great thing for a project like KES (though i love the suggestion to call it KEK) to add and overwrite, for power users.
^^^^^^^^^^^^^^^^^ note all of this is unofficial and not the opinion of /kbin the project. It's my own personal opinion, and just educated from having seen both sides of the discussion.
I think the analogy is akin to hotrodding. Some third party modifications may make their way back to the original manufacturer, but there is always a desire/need among enthusiasts for more outlandish proposals that may not align with the vision of the original maker. Particularly when they involve subjective aesthetic details. If anything, the open-source ecosystem has shown itself to be robust to fragmentation, with 19,000 ways of solving the same problem that are generally interoperable with each other, so I don't think it's a bad thing per se, but rather a strength.
Yeah. I guess my concern (perhaps unfounded) is that changes won't get pushed to the software because there is no presumed need since "the user can already do this with a user script".
Kbin Subscriptions Panel - adds a collapsible, filterable side panel with a list of all magazine subscriptions (KES has an "Add subs to navbar" option, but the subscriptions panel is a more sophisticated and user-friendly alternative)
I'm still running these three scripts in addition to KES, but if they were ported to KES it would make managing them easier (via a common interface for options) and reduce the potential for conflicts.
For example, running Kbin Subscriptions Panel a well as KES produces this visual glitch in the navbar, where the icons get mixed up:
Kbin Notification Panel for sure, it's SO much better than the vanilla notifications.
I'd like to see @raltsm4k 's Floating Subs List make the cut instead of that Subscription Panel though. Its the same functionally, just more aesthetically pleasing.
Not that I've been able to identify after toggling various options KES on and off.
The visual glitch also appears if I disable the Notifications Panel and Better Page Navigation scripts, so it seems to be something in the interaction between KES and Subscriptions Panel.
If it makes a difference, I use Firefox on Windows with Tampermonkey.
vger.app web app for Lemmy is annoyingly stuttery when collapsing comments, this is much better!
I'm hoping there will eventually be a kbin update or userscript that allows you to change the text size of comments separately from the rest of the site. The text is too small for me.
i activated him too, he is so cute! im glad me and aclist finally figured out a design that made him readable on all scales, which was a struggle the first few tries lol ( ˶ˆ꒳ˆ˵ )
Love the concept, though it looks like Firefox ViolentMonkey comment collapsing doesn't work quite right. The comments end up stacked on top of each other like cards.
I feel this is my fault for not sufficiently testing against ViolentMonkey; apologies. I have made a few hotfixes now that should ensure the manager itself functions as intended. As for the comment collapsing add-on, that is the responsibility of @artillect, but I've suggested a fix and it should be making its way into the app presently.
It's totally fine! Public exposure essentially blasts any project with just about every combination of variables. Something is bound to slip by. I was just commenting to make sure you guys knew it was happening.
EDIT: Just got the update, everything works beautifully now. Great work!
it isnt currently working properly with violentmonkey, as @artillect details in this comment. a fix is ready and waiting to be implemented currently :D
I apologize for the inconvenience. This should be fixed in 1.1.3. The update should be available momentarily as a prompt within KES. If you don't see it, try invoking Ctrl-F5 to refresh cache.
ViolentMonkey can at times be more idiosyncratic than TamperMonkey in the syntax it expects, and I don't usually recommend it because I don't think it has feature parity with TM, but regardless, this issue was my fault for not testing more thoroughly against different extensions.
Edit: It appears that this doesn't completely work, we'll keep working on it
I've figured out the issue, as soon as @shazbot sees my pull request on GitHub there should be an update that fixes it! For a temporary fix for now though, you can Ctrl-F GM. and replace them with GM_ (there should be 4 of these, on lines 17, 18, 128, and 133), and remove the await on line 133
I've seen a couple prompts to update the script via wrench menu, but the changes don't seem clear at a glance. Is there a changelog somewhere we can view what has changed?
It's a valid concern, will be doing that going forward once the dust settles. I think it will be an external document rather than a widget inside the menu. You are just seeing custodial changes (hotfixes) to some of the bugs reported today. If the third number is incrementing, it is a hotfix.
Thanks @shazbot! That makes sense to keep it external; although I think a static link to an external doc would not be out of place next to the version number on the wrench menu.
I really appreciate what you guys are doing, these scripts make all the difference in experience on kbin.
GreaseMonkey is a bit antique by today's standards--is it possible to use TamperMonkey? Also, can you provde the OS, Firefox, and GreaseMonkey version numbers? We are trying to reconcile these differences between extensions internally so that the tool is more agnostic to different browser extensions. This is a high priority at the moment.
This is tentatively fixed and we have it working on all flavors now. The update should be forthcoming over the weekend or start of next week, we are just verifying things.
I love it! I have one question though, wouldn't it be better to separate KES version from all of the userscript/settings versions? Updating from 1.1.4 to 1.1.6 only moved the version up in userscript info, since all the userscripts are updated separately anyway. Updating KES would make sense only if something in kes.user.js is changed, right now users just get KES update prompts that do nothing.
This is done to force re-cache of the new version of a userscript when it gets added as a feature. MINOR version bumps indicate addition of a mod (userscript) or internal feature, while PATCH version bumps indicate a hotfix. By design in GM, when the version number of the main script is bumped, it will redownload the requisite remote resources. We leverage this functionality to serve new files.
This should partially be rectified by the addition of the changelog link (flask icon) in 1.2.0.
When new mods are added to KES, they are integration tested, so bumping the MINOR version does imply some feature change to the KES interaction itself, albeit not necessarily at the code level.
The userscripts are not updated separately, they are cached once per KES version download. Hope this makes sense.
Oh, I guess that makes sense, tampermonkey only allows you to automatically update externals monthly, weekly, or daily (and it's also a global setting that users need to set) so that would be annoying.
I know this is a few days old, but I'm just now seeing this, and wanted to thank you for collapsible comments. This one little addition makes things so much cleaner now!
Do you know if hiding individual threads from the feed is something that can be added to this, as well? Or does that require an update with Kbin, itself?
By hiding threads, are you referring to blacklisting certain types of threads based on a keyword, or are you talking about "cleaning" the thread index by clicking a hide button to wipe it from the view?