Hermes has a "core" engine addon, a separate "UI" module, and then multiple modules for the UI itself.
Basically, I have something like:
Hermes [core]
Hermes [UI]
Hermes [UI-OptionalModule1]
Hermes [UI-OptionalModule2]
Hermes [UI-OptionalModule3]
I'm not sure the best practice for packaging up and shipping my addon. My concerns are maintenance, localization, intuitiveness, and not making things a pain for my users.
Right now I ship the "UI" as a module including with Hermes. But two things have always bugged me:
1. It's never been obvious to my users that the UI is actually a separate module which can be enabled/disabled (as exposed through Hermes configuration options). Yes, there are reasons to do this.
2. Localization gets ugly. I probably have 40 locale strings for Hermes, and 100 for the UI. I use the locale generation support here and I hate how these are both lumped together.
If I shipped the UI as a separate addon, then it would probably make point #1 above more clear to users, as they'd literally see two Hermes related addons in their addon list. It would (presumably) also allow me to split up localization between the two since I assume I'd have to make a new project for the UI on curse.
Then come the modules for the UI. Because they can be fairly extensive, I'd really like to be able to prevent them from loading. Which means also packaging them up as addons instead of modules included with the UI addon (this way the user can uncheck them in the blizzard addon list)
I guess my questions are:
1. If I make everything a completely separate addon (core, UI, and UI modules) what kind of problems am I going to be causing myself or my users?
2. Assuming I make one "package" for Hermes and all it's separate addons, how do I make it so that the UI and it's related addons aren't listed on curse? I would only want to release Hermes as one single package.
I'm unclear how curse packaging handles this but I know I can find examples (DBM perhaps?)
Well, here's my answer, looking for suggestions for better practices please:
1. Create a Modules folder in Hermes repository. Make a folder for each module there where the code gets checked in.
2. Create separate Localization folders/files for each module in the modules subfolder as well.
3. Stop using wowace locale tools (just manually edit the files for each locale).
4. Locally in my wow addons folder, checkout each module path so that I can actually test each module as an addon (even though it'll point to a deeper subfolder in the Hermes repository)
5. Update the pkgmeta for Hermes to move from the Modules folder using "move-folders:"
Thank you. If you saw any glaring issues I'm confident you'd have told me. So far this seems best. I don't expect anything "massive" like Pitbull where you have to scroll through 60 items to uncheck them :)
Also you can keep using the WowAce localization app. Just create namespaces for each of the modules. And specify the namespace when you use the keyword substitution.
You might also consider distributing optional modules as separate downloads. I absolutely hate addons like PitBull that add 40+ entries to the addon list. If it's a core element of your addon that you expect the majority of people to use (eg. a health bar in a unit frame addon) just put it in the main addon folder. If it's an optional feature or skin that won't be used by everyone, let people download it (or not) separately.
You might also consider distributing optional modules as separate downloads. I absolutely hate addons like PitBull that add 40+ entries to the addon list. If it's a core element of your addon that you expect the majority of people to use (eg. a health bar in a unit frame addon) just put it in the main addon folder. If it's an optional feature or skin that won't be used by everyone, let people download it (or not) separately.
I always wondered why the PB4 author didn't do stuff like that. You could still have the option to turn it off in the addon's settings, if that was a concern.
But yeah, when I don't play Warlocks or Hunters or Druids, why is my addons folder filled with their modules? The specific class modules should have been optional, separate, downloads, imo. Same with things like the raid frames, or even some other things. Cool that they exist, but not necessary to force-bundle them.
1) Put all your modules in your main addon folder.
2) Only reference the core modules from the main addon.
3) Create pseudo-addons which only have references to some of the modules in your *main* addon folder, but themselves contain no modules. This reference should be to a single xml file in your main addon which then references the modules for that optional addon.
Why?
Because if for some reason your main addon is updated without the other addons being updated you addon will *almost always* be up to date regardless.
Now. Optional modules.
The "Prat way" makes a trade-off that I think the users can live with. In prat there aren't 50 folders 1 for each module. Instead all the modules get loaded (fast) and then freed from memory if they aren't going to be used (fast).
This is an option that noone will mention to you - but it works *very* well. If you program it right, and don't do any work during the loading of the main chunk (which you shouldn't be doing anyways). Then the process is fast, and the garbage collector takes care of the rest.
Doing the above things are more complicated - but they have their updside.
EDIT: Not claiming to be "best-practice" on anything
Basically, I have something like:
Hermes [core]
Hermes [UI]
Hermes [UI-OptionalModule1]
Hermes [UI-OptionalModule2]
Hermes [UI-OptionalModule3]
I'm not sure the best practice for packaging up and shipping my addon. My concerns are maintenance, localization, intuitiveness, and not making things a pain for my users.
Right now I ship the "UI" as a module including with Hermes. But two things have always bugged me:
1. It's never been obvious to my users that the UI is actually a separate module which can be enabled/disabled (as exposed through Hermes configuration options). Yes, there are reasons to do this.
2. Localization gets ugly. I probably have 40 locale strings for Hermes, and 100 for the UI. I use the locale generation support here and I hate how these are both lumped together.
If I shipped the UI as a separate addon, then it would probably make point #1 above more clear to users, as they'd literally see two Hermes related addons in their addon list. It would (presumably) also allow me to split up localization between the two since I assume I'd have to make a new project for the UI on curse.
Then come the modules for the UI. Because they can be fairly extensive, I'd really like to be able to prevent them from loading. Which means also packaging them up as addons instead of modules included with the UI addon (this way the user can uncheck them in the blizzard addon list)
I guess my questions are:
1. If I make everything a completely separate addon (core, UI, and UI modules) what kind of problems am I going to be causing myself or my users?
2. Assuming I make one "package" for Hermes and all it's separate addons, how do I make it so that the UI and it's related addons aren't listed on curse? I would only want to release Hermes as one single package.
I'm unclear how curse packaging handles this but I know I can find examples (DBM perhaps?)
Perhaps I should just consider getting away from using the wowace localization web-site tools?
1. Create a Modules folder in Hermes repository. Make a folder for each module there where the code gets checked in.
2. Create separate Localization folders/files for each module in the modules subfolder as well.
3. Stop using wowace locale tools (just manually edit the files for each locale).
4. Locally in my wow addons folder, checkout each module path so that I can actually test each module as an addon (even though it'll point to a deeper subfolder in the Hermes repository)
5. Update the pkgmeta for Hermes to move from the Modules folder using "move-folders:"
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumJust do what seems best to you.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI always wondered why the PB4 author didn't do stuff like that. You could still have the option to turn it off in the addon's settings, if that was a concern.
But yeah, when I don't play Warlocks or Hunters or Druids, why is my addons folder filled with their modules? The specific class modules should have been optional, separate, downloads, imo. Same with things like the raid frames, or even some other things. Cool that they exist, but not necessary to force-bundle them.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1) Put all your modules in your main addon folder.
2) Only reference the core modules from the main addon.
3) Create pseudo-addons which only have references to some of the modules in your *main* addon folder, but themselves contain no modules. This reference should be to a single xml file in your main addon which then references the modules for that optional addon.
Why?
Because if for some reason your main addon is updated without the other addons being updated you addon will *almost always* be up to date regardless.
Now. Optional modules.
The "Prat way" makes a trade-off that I think the users can live with. In prat there aren't 50 folders 1 for each module. Instead all the modules get loaded (fast) and then freed from memory if they aren't going to be used (fast).
This is an option that noone will mention to you - but it works *very* well. If you program it right, and don't do any work during the loading of the main chunk (which you shouldn't be doing anyways). Then the process is fast, and the garbage collector takes care of the rest.
Doing the above things are more complicated - but they have their updside.
EDIT: Not claiming to be "best-practice" on anything