Support_Prefs v3.1 - now with keybind

[chrisbot6]

So, doing what you've done, Glass and Support_Prefs now break each other. You've rewritten a majority of Support_Preferences, and then implemented the newer version. Anyone running both will end up with one of them being broken because of the sweeping changes you've made.

When developing an API, you can't just change function names and protocol of an already adopted system. That defeats the entire purpose of having an API.

Also, Support_Preferences should be a stand-alone add-on, not the base of yours. That way, standardized updates can actually be released together. This shouldn't be an issue, since the API should be static. A script to download it if it's not installed isn't hard to write.

The officially released version of Support_Preferences can always be found here. I'll be updating it when the next Glass milestone comes because I don't have the time to just rewrite half of my end of things or work on the old branch anymore. In the future, please take more consideration when working with libraries and APIs.

Wait.

I was told that this API hadn't be adopted by ANYONE or ANYTHING yet. I was told I could change core components and it would still be fine. That's not the case?

Also, it IS standalone. The GitHub is still clientless and doesn't have my menu attached.

I've changed the name of and perameters of ONE FUNCTION here, and rewritten the interaction to send less garbage data. A few changes to lines of code in glass for the newer version mean it can display prefs as before and take advantage of the bugfixes and new types I have added.

I apologise for not being more careful when renaming interaction commands and registration functions. Please don't bin my changes.

[Ad Bot]

[Scout31]

Glass's preference system came out a day before you released this. I can adopt the new system eventually, but we're working on a big milestone right now that requires rewriting a lot of things and it's just a really inconvenient time to release an update to the old (live) branch.

By stand-alone, I meant your release. Support_Prefs shouldn't contain Support_Preferences in it, they should be two separate add-ons.

[chrisbot6]

Glass's preference system came out a day before you released this. I can adopt the new system eventually, but we're working on a big milestone right now that requires rewriting a lot of things and it's just a really inconvenient time to release an update to the old (live) branch.

By stand-alone, I meant your release. Support_Prefs shouldn't contain Support_Preferences in it, they should be two separate add-ons.

oh, right. Sorry, I'll separate them out.

[Zeblote]

By stand-alone, I meant your release. Support_Prefs shouldn't contain Support_Preferences in it, they should be two separate add-ons.

There don't need to be multiple add-ons for everything. Much better (for both the user AND the developers) to have a single system, like rtb was.

All of this should be inside System_BlocklandGlass instead.

[Scout31]

Actually, no, it's not. RTB was packaged together because it was really only meant for a single client. The point of Support_Preferences is to have a common server-ended api, but allow you to use a client of your choice. The server should only need Support_Preferences, and the client should only have whichever client they want to have.

There can also be some compatibility issues with having Support_Preferences inside the add-on itself. Say that Support_Prefs has v1.0 of Support_Preferences, but I just released v1.1 which adds RGB and colorsets, for example. One of the two will overwrite the other.

It's much simpler to have it as an independent add-on. It operates entirely independently on the server side, and since the API will be static in the future, it'll always be backward compatible. The Support_Preferences from the Glass website also already has updater support, so updates come as they're released.

oh, right. Sorry, I'll separate them out.

Sorry if I was a little critical earlier, I didn't realize you weren't aware that Glass had already adopted it.

[chrisbot6]

Sorry if I was a little critical earlier, I didn't realize you weren't aware that Glass had already adopted it.

I was aware that glass was going to adopt it, just not so soon.

[Zeblote]

Actually, no, it's not. RTB was packaged together because it was really only meant for a single client. The point of Support_Preferences is to have a common server-ended api, but allow you to use a client of your choice. The server should only need Support_Preferences, and the client should only have whichever client they want to have.

There can also be some compatibility issues with having Support_Preferences inside the add-on itself. Say that Support_Prefs has v1.0 of Support_Preferences, but I just released v1.1 which adds RGB and colorsets, for example. One of the two will overwrite the other.

It's much simpler to have it as an independent add-on. It operates entirely independently on the server side, and since the API will be static in the future, it'll always be backward compatible. The Support_Preferences from the Glass website also already has updater support, so updates come as they're released.
Sorry if I was a little critical earlier, I didn't realize you weren't aware that Glass had already adopted it.

So... who will make those "multiple clients"? Because I really can't see that happen. As soon as there's a single good one others would be obsolete and essentially a waste of time. It's most likely going to end up with everyone using the same gui for years again, because it works, and they know how to use it well.

And then it really makes no sense to split it in multiple add-ons. This support_prefs shouldn't be separate either, why not just make it part of glass?

[K3k0m@n]

this needs to be part of glass, I don't see any reasons why they should stay seperate

[TheBlackParrot]

So... who will make those "multiple clients"?

whoever wants to? BLG took the opportunity and ran with it. chris has done the same (now) as far as i know.

it's open, i know it's hard for you to think of others potentially experimenting with it. it's ok.

[Xeidious*]

this needs to be part of glass, I don't see any reasons why they should stay seperate

it kinda looks like a competition to get the best mod-manager/prefrence manager out first, that's just what i'm seeing though, probably isn't the case.

[chrisbot6]

it kinda looks like a competition to get the best mod-manager/prefrence manager out first, that's just what i'm seeing though, probably isn't the case.

nu.

We're all using the same pref system, glass just got a bit behind because I pulled the carpet from under them without meaning to.


v3 to v3.1

Code: [Select]

- some bugfixes i forgot
- added keybind