With a stable framework in place, this release brings a slew of interesting add-ons from the community, as well as updates to existing ones. We are seeing an uptick in contributions from kbin members adding their own features and suggestions. Thank you!
@1chemistdown and @Twelph did some thorough testing on mobile devices, allowing us to diagnose and solve issues with iOS and the KES menu being inaccessible on phones with narrower screens. Now the KES wrench icon resides in the hamburger menu if on a mobile device with a viewport < 576 pixels.
First, a short summary of user-facing fixes, followed by a large list of exciting new add-ons.
Fixes
- Hamburger menu disappears when using toggle logo add-on on mobile
- Alignment of wrench icon in hamburger menu
- Notifier and settings icons: better visibility across all kbin themes
KES is now more compliant with kbin’s internal theming and the various icons and notifiers should resolve correctly regardless what theme you are using.
Notable new additions
-
Resize fonts globally (@minnieo)
We have added a new Accessibility page to the sidebar that will gradually be expanded with more content. The first addition is this add-on, which allows you to independently customize the font size in 0.1 pt increments of virtually every element onscreen, be it threads, comments, or the navbar. As you increment this number, the KES window will become transparent so you can see the changes. -
Hide threads permanently (@shazbot)
What if you could hide threads forever? This feature adds a “hide” button to the toolbar below posts. Clicking this will banish the thread and store its ID. If you wish to reset this history, you can toggle the feature off. This add-on works best with infinite scroll enabled, so you can hide as many posts as you like, and the thread index will continuously update with more content. -
Mobile cleanup (@Twelph)
This is the first in a series of proposed features geared at letting mobile users remove, resize, or change elements that may otherwise clutter the view on small devices, and make them more tappable. -
Move/hide federation warning (@PrinzKasper)
Coming from a new contributor, this add-on lets you move the large federation warning when browsing instances off-site. Choose to remove it altogether or tuck it into the sidebar. -
Always expand post bodies (@shazbot)
With this add-on enabled, long posts will start expanded, rather than being collapsed. When toggled off, it will roll-up previously expanded posts. -
Rearrange thread element order (@shazbot)
A lot of people like the post comment text area to be directly beneath the OP. This add-on lets you freely rearrange the order elements appear inside a thread based on a numerical index. Assign a number from 1 to 5, with increasing numbers indicating lower position on the page. You can move the text area and activity to the top, move the comments to the bottom, or reverse the entire order if you like. Try the suggested layout on the add-on’s settings page. -
Alpha sort subs list (@shazbot)
A simple fix that makes the subscriptions page easier to read by converting the magazines into an alpha-sorted list. -
Clarify recipient on compose (@shazbot)
It can be unclear to whom you are sending a message when composing a PM. This simply modifies the header above the compose area to read: “Sending message to <NAME>”.
Updated add-ons
-
Notifications panel: smoother load and pagination (@blobcat, @shazbot)
This is a collab between @blobcat and @shazbot to spruce up the existing panel, with the former handling the design and the latter handling the backend. Now the notifications panel fetches notifications in the background and loads in smoothly, with proper pagination and read/clear functionality. Though subtle, this necessitated a significant rewrite of the old panel. -
Hide sidebar: show/hide specific elements of the sidebar, such as random posts/threads (@shazbot)
Based on the idea suggested in this thread. Instead of just hiding the sidebar on or off, the feature now lets you granularly hide specific parts of the sidebar. -
Hide thumbnails: granular toggles for thread index/inline thumbnails (@shazbot)
You may want to hide thumbnails on the thread index but still see them in threads. Now you can do that. -
Collapsible comments: several fixes for nested replies, reply threads 10+ comments deep, infinite scrolling (@artillect)
This is a very complex add-on that needs to be aware of infinite scrolling, replying, long nested comment chains, et cetera. All of that functionality should be working as intended now.
API
- Pass mutation events through to mods for parsing
For add-ons that need to recur in the event of infinite scrolling or other changes, KES now passes through information about the caught mutation event so that the destination script can parse it and act accordingly. This further obviates the need to set up special observers and ensures that your script does not simply recur on mutation events, but can filter them accordingly.
Final remarks
Thank you for your interest, bug reports, and suggestions. We continue to receive useful feedback and contributions from the community. If you wish to include your own script or need help doing so, please do not hesitate to reach out.
I’m only finding v. 1.9 on tampermonkey
Are you trying to search for it from within Tampermonkey? You should navigate to the KES page and install it directly from there.
I’ll try that, thank you
I was able to find and install 2.1.0. I activated the hide posts feature and am noticing a potential bug: I have the feature to display images automatically set to on. If I hide a post without first toggling the image off, the post disappears but not the image. It remains in the feed even after closing kbin, refreshing the tab, switching to another page and back.
2.2.0 was released today, so you should be installing via here
This is good feedback, wasn’t aware of the auto images feature. Will investigate how it works and issue a fix.
My bad. I’m on that version! I tried to deactivate and reactivate the hide feature. It reset everything but I noticed that, even for posts that I toggle shut the image and then hide the post, if I then refresh the page, the images reappear “without” the post. I used quote because for a split second, the post also appears
Hope this helps!
Also: kudos for responding to everyone so quickly!
Yes, I just tested it and the issue was quite clear. I have the fix complete and ready to go here, just want to test it a bit to make sure there are no unforeseen effects.
Alright, this should be fixed with version 2.2.2 if you update again.
Yup! There’s a barely there moment on refresh for the script to suppress the already hidden posts but the images stay hidden even when switching to another page and back
Cheers for fixing this so quickly. Love having this feature
It’s a known limitation, won’t get into the technical reasons therefor, but will continue trying to narrow this gap to remove the blink.
It certainly doesn’t bother me. tbh my brain sort of anthropomorphizes it. Like, oh no! The script is working too hard
@shazbot I am on version 2.1.0 but I don’t see any of the new features as far as I can tell. From what I can see only the “addons” from the previous version show up in the settings menu.
*edit: Ah my bad, you have to actively install the update by pressing the green button. That’s a little intuitive. This is the first userscript I encounter that doesn’t have auto updates.
Which extension are you using?
Auto updates are not something provided by scripts themselves; it’s a feature of the script manager you use, and the update frequency and type of update can be controlled in that extension’s settings. If your extension is set to passively reinstall only the main script in the background, but not the included resources, it might not work. It needs to pull in all of the other resources to populate the sidebar, etc. Otherwise, it’ll be loading from cache.
@shazbot Hey thanks for the replay, I am aware. For some reason the latest version of KES got installed alongside the existing 1.20 version I was using for what ever reason. Now everything works tho. Thanks again, love the script.
Hmm, I am thinking. I am making a note of what you said (concurrent versions get installed).
My original message was also lacking in sufficient context, so I think I owe it to you to elaborate: other scripts probably auto-update because they are self-contained and don’t contain external resources. (Long explanation follows.)
KES fetches remote resources (from the same repository and by the same authors), such as a list of add-ons, metadata on the layout and look of the menu, and the add-ons themselves. The “auto update” logic seems to be implemented slightly differently in each script manager, and from what I understand, the original Greasemonkey project recommends against script managers implementing auto-updating because it is unreliable due to caching etc, but some do it anyway.
As for the updating itself and why this might occur: by design a script should fetch its resources once when installed for the first time and cache them, but the script manager won’t update those resources again when passively updating the main script due to the principle of zero-trust. The script manager assumes that the first time the script is installed, the related resources (other URLs etc.) are being authorized by the user, so it makes a local copy, but in order to prevent the rare case where those resources changed out of lock-step with the main script (e.g., the remote resource is updated with something bogus but its name remains the same), the script manager only attempts to update the main script and will skip fetching new copies of resources UNLESS the resource names have changed or if the user explicitly forces a reinstall, at which point this is taken to mean that the user implicitly accepts all of the other resources as trusted.
When KES updates, the metadata and manifest (responsible for creating the pages and sidebar) may contain new content, but the script manager sees that they have the same name, so it assumes the resource is the same, and falls back to using the cached copy, which by this point is old. If you take a look at a script manager like Tampermonkey, it has a setting called “Externals”, which by default is off. This is, again, by design done for security. Tampermonkey assumes that scripts should never automatically update their remote resources, since, while you can audit the actual content of the script itself, the remote resources could potentially point to anything. I don’t recommend changing this setting, but it can be set to different update intervals.
I think this is part of why the original GM project considers the idea of scripts updating themselves fundamentally flawed, because there is no method of implementing it that satisfies both security and convenience at the same time.
Thus, in order to pull in not just KES, but its associated updates, the best way to do so is to reinstall the master script, which will trigger all of the previously cached resources to be updated to the latest ones. This is a small usability tradeoff, but it’s why the button was provided in KES when there is a new version.
I have yet to find a signal we can send to every type of script manager to indicate that everything should update, but I don’t think it’s possible for the reasons above: each extension seems to implement this slightly differently, and the traditional, canonically correct way of “updating” a script in the original GM specification was to just reinstall it. The auto-update feature kind of exists as a stopgap measure today, but it doesn’t always work in more complex cases like the above.
I’m not sure what would be the best compromise here, but I think we take reasonable steps by notifying the user that a new version is available and providing a click-through link to the script itself. We could probably add extra error handling to check whether the main script is out of synch with the resources and warn the user accordingly, but it’s going to come down to the different script managers in how they update. If anything, the better approach (for KES, at least) would be if we could tell script managers to not passively update, since it’s liable to cause the KES frontend to report the current version, when it’s actually missing critical components.
I’m facing an issue with hide sidebar function on mobile android. I checked all of the boxes to hide all of the stuff thinking it would only block the ones at the bottom of the page but now i can no longer open the hamburger menu at the top left to access KES settings and I’m not able to revert this setting. Is this a bug or intended?
Shouldn’t be intended or related in any way. What script manager are you using?
I’m using Tampermonkey
I will try to reproduce this tomorrow. In the meantime, have you tried reinstalling? I don’t think it’s possible for the hide sidebar add-on to interfere with the hamburger menu at all, but at first blush, it sounds like the selector names might be colliding. When you say you can no longer open it, do you mean tapping it does nothing, or did the entire menu go missing?
I tried reinstalling it but it didn’t change anything. The menu i on is still there but tappi g it does nothing. It works fine when I disable KES
OK, I was able to untangle the root cause and get it fixed, but I want to allocate some time first to making sure all of the functionality remains intact before issuing an update.
Okay thank you!
This should be fixed in version 2.1.2, please have a look.
OK, I know exactly what you are talking about now. I encountered this bug myself during development, but our mobile testers confirmed they could open the hamburger menu on their devices, so I thought it was okay. I’ll try to debug why it’s blocking tapping.
This might have already been addressed, but would there be potential of this being hosted on the codeberg with kbin so people could add issues to it / kbin in the same location? I tried to understand their requirements and it didn’t seem like you needed to be a member and it seemed like MIT license was acceptable but wasn’t quite sure as I’m not great at licensing stuff (or even just an issue tracker repo). Either way, definitely not trying to dictate anything, was just curious, and I can see benefits of not doing so as well.
I did want to mention (sorry for this, don’t have a github account atm >.> ) profile -> drop downlinks, when clicking them in my profile, all of them seem to redirect me to
kbin.socialfor my username there, rather than my local instance on version2.1.3(edit: ah, and that is true for any non-kbin social profiles it seems)Thanks for the suggestion. I can’t square it in my mind, because this tool exists to satisfy features that cannot/will not be added through conventional means. The projects also have different requirements, protocols, and workflows, so it sounds like it would just lead to gridlock, and I can’t really understand what the proposed benefit is, here. If this is for the sake of not having to register an extra account, I apologize, but I think it is a relatively low barrier to entry if you wish to submit a bug report via an approved channel. All development and changes are taking place in the open, so it should be fairly easy to transparently see what is going on provided you visit our repository.
As for the second point, it is definitively an oversight, will fix it in the forthcoming version if not sooner via a hotfix. We should be parsing the current domain rather than hardcoding that. Thanks for mentioning this. If you see anything else that behaves this way (hardcoded to kbin social), let me know.
Alright, this is updated in
2.1.4. It also affected the notifications panel, so both of those use the generic hostname now.
