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.
@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.