search

sizzlemctwizzle / GM_config

A lightweight, reusable, cross-browser graphical settings framework for inclusion in user scripts.
https://github.com/sizzlemctwizzle/GM_config/wiki
GNU Lesser General Public License v3.0
205 stars 48 forks source link

Capstone 4.0 #108

Closed sizzlemctwizzle closed 1 year ago

sizzlemctwizzle commented 1 year ago

I decided to create an overall issue for the new milestone. After all of the other issues have been resolved, this will serve as one last completion and integration check. This issue is also a place to discuss adding additional issues to this milestone. I already have some large changes to the internal mechanics in a local branch, which is covered by this issue as well. pull request.

That being said, it's likely that I will complete this milestone, in part or whole, at some future date. To that end, an issue will be labeled May Fix until work is actually being done and when it is labeled Will Fix.

Remember, I have practically zero motivation to work on this, aside from idle curiosity. I'm happy to review pull requests and merge in my local changes. Realistically, I'm too lazy to review pull requests, and a bit of a control freak when it comes to GM_config, so all changes will almost certainly come from me (~sorry #107 but #69 is mine~).

sizzlemctwizzle commented 1 year ago

111 is a blocking change for this milestone. Initialization is at the core of GM_config so I won't touch any other part until that change is locked-in and merged.

sizzlemctwizzle commented 1 year ago

111 also fixes #92 due to an overlap with changing where and how GM_config internal APIs (getValue, setValue, etc.) are defined.

sizzlemctwizzle commented 1 year ago

90 has been selected as the next issue to be worked on after #111 has been merged and #92 gets closed. I'm finishing some personal business. I had a project where I adapted GM_config (meaning edit GM_config source) to do getValue and setValue via REST AJAX. The resulting code was an absolute mess. #111 was done from scratch. In another project, I used GM_config with custom fields that were nearly identical to basic "text" fields, so there was some copy/pasting going on. This explains my interest in #90. In that same project, I had to adapt GM_config to be able to add an arbitrary number of new fields to the open frame. This was the messiest thing I've ever done with GM_config. This use case is covered by #105, and will likely be worked on after #90. This leaves #69 as the "nice to have" feature (the reason it's the oldest), which could honestly be covered by what you get with #90 completed. But #69 isn't a big ask in terms of additional functionality, and it's not a breaking change. Still it might get rejected after #90 is complete.

Bottom-line: the issues included in this milestone are far from arbitrary. Now you know my motivation to work on this milestone and why I'm doing it now.

sizzlemctwizzle commented 1 year ago

Dumped #90 because of too much complexity due to tightly coupled logic. But custom types are already good enough imo. Moving too #105

sizzlemctwizzle commented 1 year ago

Completed #105 and ultimately decided to finally reject #69. With that, this milestone is complete. I'm keeping #113 open for visibility. Bug reports will be handled outside of this milestone.

That being said, it's likely that I will complete this milestone, in part or whole, at some future date.

And pretty much all at once 'cause that's how I roll.