04/20/14, 04:44 AM | #1 | ||||||||
Join Date: Apr 2014
Posts: 5
|
Addon Etiquette
Is there any discussion about how Authors SHOULD built their addons yet ? As like in all programming languages there are things that you CAN do and things that you SHOULD do. I can imagine that over the time the author community for TESO needs some standarts on how to implement your addon to get the maximum amount off compability and usabillity.
Myself I'm not an author (yet (mabye)) and I don't have much experience with lua and such a community like this. But I feel that all authors should have a discussion on how they can work together more efficiently without loosing their own independence. I'm talking about the idea of creating libraries and some basic addons that every addon>user< almost has to use. (https://en.wikipedia.org/wiki/Request_for_Comments) Examples: SkyUI in Skyrim. It was so popular that at some point the devs started implementing tools that other addons used. Same with SKSE. Almost no addon from some point on ran without SKSE. I'm also talking about ways on how you SHOULD implement a feature to work as good as possible with other addons. An Etiquette. These ways are common to occur and should be discussed as soon as possible. To get the discussion going I will start with my own Ideas. Please feel free to post you own Idea on what the community needs to do to get good standarts. This section of the post below is up for anyone to change. Ask a moderator.
Last edited by NonameFTW : 04/27/14 at 10:56 AM. |
||||||||
04/20/14, 06:40 AM | #2 | |
Join Date: Apr 2014
Posts: 5
|
Libraries
Another Idea I suggest is to use common folder for libraries if possible. Some libraries already use the folder "libs" and in my opinion it would be a good Idea for library authors to get a common agreement on that to make it easier for addon authors and prevent redundancy.
As far as I know Minion does check dependencies. I GUESS (don't know) that its through the description txt file. But I didn't work through the material so I don't know. I also don't know if the declaration is actually necessary for the API so bare with me if the following is bull****. In this case two things should be standart: - Authors of addons that use specific libraries are agreeing on declaring the dependency of their addon for minion and every other addon. This should be a absolut MUST! Addon authors should not be allowed to use a library without doing so. Posting an addon that uses any external ressource without declaring its dependency should be removed from esoui after one warning. - Authors of addons and libraries should work in such a way that minion can install all necessary libraries by itself. Addon authors therefore should NOT implement the library in their own zip file and library authors should programm their project as standalone ressource that every addon can use. As always this is a SUGGESTION up for discussion. Last edited by NonameFTW : 04/20/14 at 07:09 AM. |
|
04/20/14, 07:10 AM | #3 | |
Join Date: Apr 2014
Posts: 5
|
Settings Names
At the moment Authors want to consolidate the addons they are making under one settings menu. In general it's a good Idea to save some space. But the following problem will occur later on in my opinion.
The thing is that authors use their username for these settings menus instead of addonnames or addonseriesnames. One thing everyone will have to get their head around on is: Until authors start to use a common (custom) addon menu interface noone will be able to prevent that users will get a looong row of settings. So if you then have a long row of usernames from authors instead of addonnames this behaviour will get quite annoying very quick. You don't want to remember all the authors who created these things and you don't want to search for a setting through all these useless names. Making TESO addons is not a popularity contest! So it would be a good thing in my opinion if authors started to use the addonname as a setting name. If it's part of series then use the Series name. |
|
04/20/14, 07:46 AM | #4 |
There are already some libraries that are in common use, so we're already headed there.
The wiki is being updated regularly and includes example code. Ultimately it's going to take a while as people have jobs and want to play the game also. |
|
04/20/14, 10:35 AM | #5 | ||
What would be nice is if a standard was established, like, if you are going to use non-global/accountwide saved settings, you should have a variable in your savedvariable table called "pretty name" or something similar. This would allow other tool(s) to present settings for manipulation in a much more readable and trackable way. Just one example of standards. I also use standards as I use at my day job. Tabs, not spaces (though completely up to whomever), I strip all extra white space and I use CR+LF for EOLs. The above things allow me to do kdiffs very easily without getting a lot of "non" changed changes, especially the white space strip.
I am a sw engineer by day, and I really want to play the game LOL. I think I have one character @ level 12 (my highest) and that was just from sheer testing of the quest tracker. o.0 I really enjoy the game, and I want to help others enjoy it too, and if there are standards that would be great, but no one is really getting paid. Donations are nice =) but I dont even ask for them. So, its not a job is what I am saying. |
|||
04/20/14, 11:59 AM | #6 |
I am a music teacher by day, not a coder. Everything I have learned I have taught myself or picked up from other authors/addons, along with 7 or 8 years of writing addons for WoW.
Many people are like me. They aren't software engineers, they are teaching themselves because this is a hobby for them. Making them also learn standards/rules and adhere to them is going to be another layer you are putting on them for something that they are doing in their free time for fun. That does not mean that I don't disagree with all of your ideas. But what you propose should come from convention, not rules. And conventions take time to develop, as more authors adopt them for their addons and more new authors learn from viewing those addons. --------------- Let's talk about libraries first. Placing libraries into a libs folder inside the addon folder is a convention brought over by authors from WoW. The addon loads and works just the same whether the folder is called libraries, StuffMyAddonNeedsToWork, or doesn't exist at all (with the libraries in the top level of the addon folder itself). To users, this doesn't matter at all. And to other authors, it shouldn't either. Installing libraries as standalone and not including them in the main addon itself is not a good idea. Even over in WoW, it was discouraged and for those that wanted to install their addons this way, it was stressed that they should only do this if they were "power users" and "knew what they were doing". (Now, I do create my libraries so that they may be used as standalone if the user or author so chooses to install them this way, or the author may pull the actual library code's folder out to embed in their addon.) To users, standalone libraries give them a headache of worrying why an addon isn't working if they've accidentally disabled or uninstalled a library that they didn't know the addon uses. Also, to users, it either forces them to use Minion to install their addons or suffer the consequences of needing to make sure they have everything installed that they need. Really, addons should just work. This brings me to my next point. I have ported LibStub over to ESO for the purpose of creating libraries that may be embedded. Any author that creates a library *should* use LibStub in their library. (But if they want to code this into their libraries themselves instead of use LibStub, whatever.) A library registers with LibStub as it loads. If you have 5 addons installed, for example, that all use LibAddonMenu-1.0, then all five instances of LAM make a call to LibStub, passing along their version numbers. LibStub only accepts the library with the most recent version number and discards the rest. What does this mean for a user? They may have 5 copies of LAM installed inside their addons, but only 1 is being used. What of the extra 60kb of memory on your hard drive from the other four? What does it really matter, if you have a 500GB hard drive? ---------------- Now, let's talk the settings menu. I agree that the scroll menu should not get too long. From day 1, I've been saying that authors should condense their addons into one settings panel, if possible. I have been placing the settings from all of my ZAM addons into one panel as an example. This is easier to do if your addons follow a naming scheme, as mine do. Some authors choose to be more creative with their addons names or don't wish to brand them with a naming scheme. These authors, if they wish to condense their settings onto one panel, may be those who name their panel after their username. That doesn't mean that they're turning this into a popularity contest. It just means that they're saving users some room. And, so long as they tell users where to find their settings panel, what does it matter? Now, here come conventions for certain circumstances.
---------------- Next, let's discuss saved variables. This is not anything that is enforceable across addons. I don't even use the ZOS API for creating saved variables. Instead, I do it with the much easier method that I use in WoW. You shouldn't force authors to follow a specific naming scheme for saved variables either. What if they want more than one saved variable? (Yes, I realize that saved variables can be a table, but some authors want two distinctly separate saved tables.) What if their addon is named My_Addon2, but they just want their saved variables named MyAddonDB? What if the only thing an author wants to save is whether or not the addon has been loaded for the first time already? Then their saved variable name may be MyAddonLoaded. To users, saved variable names do not matter. To other authors, saved variable names, do not matter. To Joviex's addon, and his addon only, they matter. A standard or convention should not be created for one use-case. Instead, I keep saying that it should be up to the addon authors themselves to place profile support within their addons. If Joviex wants to write a library that makes that easier, they may adopt profile support faster. Me, if I make profiles in my addons, I'll just do it based on the same way I did it in the past with WoW. This is what I know, this is what I'm comfortable with, and this is something that works. ----------------- Lastly, let's discuss formatting. I use tabs myself. Others use spaces. Those that use spaces may vary from 2 to 4 to 5... It's all about personal preference. Tab size may vary from editor to editor, but spaces stay the same. This is not something that needs a "standard". Semi-colons at the end of lines/commands are not necessary in Lua, yet some authors choose to include them from experience coding in other languages. Semi-colons don't hurt any, so it does't matter whether they're included or not. This is not something that needs a "standard". Some authors choose to put in extra white space for readability and/or separation. So, it may add 1b to your file size, but it adds 0b to your addon's memory usage. Extra white space is not something that needs a "standard". |
|
04/20/14, 12:44 PM | #7 | ||
Join Date: Apr 2014
Posts: 5
|
Thats actually a better solution. Some authors may create mutliple addon that are totally unrelated. In this case I would disagree with you. One author should be "allowed" to create more than settings menu. It's not confusing YET to have these kind of username named settings. But there will be players who are gonna heavily modify their interface with HUNDREDS of addons. Now try to think of the situation here: This user would have thousands of settings he has to manage. This is not the problem. The problem comes down when multiple addons with totally different purpose use the same settings menu. You then have about 60 settings menus. Not the problem. The problem is when you have 60 settings menus which do not tell you which settings are inside. I think that such a user would rather like to have 200 settings menus which tell him excatly what settings are inside than to click through 60 settings menus and scroll through them. Again! I'm not against consolidating multiple addons into one settings menu. But there should be another logic behind it. One setting menu per Addon or Addonseries. Not one settings menu per author. Of course the whole situation is a crappy solution. The best would be a integrated Interface which would create just one settings menu called "addon settings" or something. This would open up a new window with all addons that use the library. Each addon would have their name on the left side and be clickable. I think this solution would solve the whole problem because most authors would start to use the addon names by themselves. I've seen in the comment section of you library that you're considering this for version 2.0 . This would defenitly help the whole community! __________ Btw in general: The only enforced standarts can be applied by zenimax. What you call conventions and what I mean with standarts is the same. Last edited by NonameFTW : 04/20/14 at 12:48 PM. |
||
04/20/14, 04:04 PM | #8 |
I said that if it was possible*, then it would only be done for a total rewrite of the entire library - hence, version 2.0. I never said that I was already considering creating a version 2.0 or planning out features/changes for it.
Also, I never said that an author should be forced to only use one settings panel. I said that I encourage it, "if possible". Also related to your paranoia about the addons list, I also gave three scenarios where an author should NOT use LAM. And even still, addon authors that want options panels DON'T have to use LAM at all. And not all addons will have settings to configure. ZAM_Notebook has 0, for example. *Adding a header/button to the Settings menu automatically creates a panel for it that opens when you click this header/button as per the game's API. So if I do make a 2.0, it may not be located in that menu at all. Last edited by Seerah : 04/20/14 at 04:06 PM. |
|
04/20/14, 04:41 PM | #9 | |||
Just saying having some reduced entry points, like shared code/libs, would go a long way to rapid development versus writting the same code over and over and over and over.... that everyone else is doing. Which I think when you do that, from my experience as an engineer (20 years), it is always better to have a set way of doing things.
But that is completely selfish for my recent plugin so that instead of posting the SavedVariable tabe key, it would look for this pretty name and present that, so things like "IIB_Save" actually show up as "Inventory Item Borders" so someone knows what they are transferring
It makes kdiff(s) or any diff(s) run better without a lot of false positives on changesets. And when I say white space, I mean white space like a line with nothing but a tabspace on it, or 10+ spaces at the end of a code line. True white space, not indented, or purposeful whitespace. I know, not everyone uses a repository to push changes; again, I do, so probably selfish, but my preference is to simply have "smart" commits with actual changes to code versus a bunch of changesets that were zero merges except white space. I dont think anything is "throw all your toys on the ground go home" just some thoughts on having a cleaner, potentially faster development environment for some. |
||||
04/20/14, 04:56 PM | #10 | |||||
If you're talking about ways to write code as in templates for authors to use, that is free for anyone to put up onto the wiki.
|
||||||
04/20/14, 05:02 PM | #11 |
heh!
No worries. Your code is some of the most helpful for me. And it is not a deal breaker by any means. Unfortunately, you have SVN and GIT but no BB support. I use HG and TFS (no support for that obviously) but HG would be nice =) And I think I am in the process of making a community lib for things like CHAIN, etc... There is a lot of stuff in wykkyds framework that would be nice, but loading all the other stuff (Bazgrims toolbar, etc...) is heavy handed. Some nice UI support (not settings menu), general string support, blah blah.... would be keen. |
|
04/20/14, 05:10 PM | #12 |
Some good points floating around here. I have one thing I might add / aproof of as well:
I also feel like that Addons Settings tend to use up to much space right now (especially if you have to many of them installed ). However, if LibAddonMenu would put up only one Main-Entry in the native Settings-Section named like "Addon-Settings" and then add an List-Box on the top of the Right-Side with all the addons setting names like they're used right now (just in the List-Box) it might be way more accessible and save up Screenspace after all. And it would make it clear that those are Addon-Settings after all. And I guess it wouldn't be as big of a change as it would require any API-Changes. What do you think about that idea Seerah? Edit: Retard me, next time I should check your comment-section beforehand. http://www.esoui.com/downloads/info7....html#comments. I'd be willing to volunteer for it if you dont have time or don't want to add it right now (as I feel like it would be a big improvement). But I wouldn't want to do it without your approvement or official patch thereafter as I'd find that a bit of a waste of time if it 's unofficial and not pushed out. I could understand if you want to do it yourself thought! After all coding is something personal and needs to make fun - and sometimes you don't feel like others should mess with your code after all. Last edited by thelegendaryof : 04/20/14 at 05:21 PM. |
|
04/20/14, 05:35 PM | #13 |
|
Re Addons, think we already had a discussion on it : http://www.esoui.com/forums/showthread.php?t=507
Well, tried to anyway. Seeing my addon menu getting a bit populated now. Personally I like / commands, but I can certainly understand users wanting to use the GUI as the number of options in one of my addons has grown quite a lot. But I would rather just have an option like /jy setup that will then trigger XML Frames to configure that addon. At least until we can get our own "Sub-config" setup, a bit like how Ace3 (I think it was) had all the addon with options in its own little GUI. On Libraries, been thinking about making one so I grabbed LibStub to get an idea on how to go ahead. Hopefully will figure it out. |
04/20/14, 09:42 PM | #14 |
Now that you guys are making me think about, I may have an idea for LibAddonMenu-2.0, but I'll need to investigate into it and see what ugly hacks are needed. Once summer hits, I'll have more time on my hands. Not sure how much work I'll have at school.
For LibStub, the documentation is pretty solid on the download page. There's also a thread around here somewhere where someone wrote it all out even more verbosely. |
|
04/21/14, 06:20 AM | #15 |
|
Seriously, when I saw this topic I thought it was another 'what things shouldn't we do with our addons' type of thread.
I like the discussion going on though. I actually like the idea of addons being able to share one settings menu entry but I can see where some people wouldn't find it as easy. I never originally planned on using LibAddonMenu to create a settings menu entry, but did so after requests from users (and my ineptness with adding things like slider controls to my own menu window. |
04/21/14, 09:29 AM | #16 | |
Great discussion going on here! I may be off my rocker, but I seriously think the biggest concern ANYONE should have regarding the standards/conventions being used with addon development would be poorly named global variables. I couldn't care less how awkward and convoluted your globals name is as long as it is unique enough to not pose potential overlaps with the default UI and other addons. As for your locals, you could obfuscate them to a letter table for all I care, tbh... |
||
04/21/14, 09:30 AM | #17 |
04/21/14, 09:42 AM | #18 | |
Join Date: Apr 2014
Posts: 5
|
Give me some examples and I'll add in the first post. I'm currently making a Summary of all topics and their current Status.
|
|
04/21/14, 10:50 AM | #19 |
|
Starting to move to Local for everything I can. Think I should update the "AppTest" I made, as it was a nice learning exercise - especially with some of the feedback I got when doing it.
One thing that is starting to seem annoying to me, even though it shouldn't, is that we are getting into an AppStore issue with 15 version of basically the same addon for everything. Yes, I know each have their approach to it and its good to have options but, yea, I really shouldn't think like that, Healthy competition makes for better addon scene overall. And well most of the things being made are more like simple hacks. Course, the really good/big ones will not have much "competition", like FTC, Zgoo, Wykkyds suite etc.. |
04/21/14, 11:28 AM | #20 | |
Lua Code:
I just sort of threw this together so it may have typos. Also, please correct me if I am mistaken with any of this and let me know if you want more detail. Last edited by Vicster0 : 04/21/14 at 12:13 PM. |
||
ESOUI » Developer Discussions » General Authoring Discussion » Addon Etiquette |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Linear Mode |
Switch to Hybrid Mode |
Switch to Threaded Mode |
|
|