Well, I noticed that pretty much all my minimap buttons look a bit different. Since I'm pretty much a freak, I would like them to look all the same. So my idea for an addon is basically something you can create minimap buttons with, which execute commands (like /atlas) and maybe also the possibility to hide others. I dont know how far something like this would be possible, since I'm not that much into .lua yet. If I would be, I would give it a try myself probably. But something like this would be awesome for sure.
In my sig you will find a way to edit BLPs (textures) without addon, I used that very method to get all my minimap buttons looking the same (they're all square without a border, unless the texture/icon of the addon itself is made round by the author of that addon)
Hm, it looks like my post was not so understandable. Actually, I was talking about minimap buttons who would all behave the same. Not the textures. Like, see. I got a square minimap, but some of my buttons still move in a circle around it. Also, some buttons seem to have a larger radius than others.
Some addons that don't auto-detect the minimap shape have an option to treat the minimap as square. Alternatively you can just manually position the frames. Put your mouse cursor over the button you want to move and enter:
This will move the button so that the center of the button is anchored to the middle of the left edge of the minimap. The two numbers at the end are the horizontal and vertical offset, in that order, with the lower left corner of the screen being the origin (so negative horizontal offsets move left, positive right, and negative vertical offsets move down, positive up). So if you wanted to put a second button 20 pixels higher than the first, you'd use:
Possible anchor points are CENTER, TOPLEFT, TOP, TOPRIGHT, RIGHT, BOTTOMRIGHT, BOTTOM, BOTTOMLEFT, and LEFT.
Once you've gotten the hang of it, you can use this method to move any frame around. And rather than having to execute /run commands every time you log in, you can put the actual commands (everything but the /run) at the top of any addon's Lua file. So you might end up with:
You can also use Frame:SetScale(0.8) to make overlarge buttons smaller (or too-small buttons larger). You can even anchor one button to another, although I wouldn't recommend doing this since it will generate errors if you disable the "another" addon.
It's probably quite feasible for someone to write a quick addon that controls the positions of minimap icons. I've seen one before, but it was horribly made (using ->slider<- :o bars to reposition the icons), and was clearly improvable upon.
Well, I'm not going to write it, but if you wanted to automate the process you'd have to:
(1) count the number of minimap buttons present, and then
(2) calculate the same number of available positions, and then
(3) assign each button to a position.
#1 is the main problem. You'd either have to rely on minimap buttons being parented to the Minimap, and assume all children of the Minimap needed relocation, or add some frame-finding code (see Xparky for a good example of this).
Lol, in general chat we just determined that MBB was written by someone who didn't know not to create fresh tables in the OnUpdate function. People were hitting 2FPS and 10megs of memory usage from just that one mod alone. I think it would be best to just re-write it from scratch, using libraries to trim the 1k lines that it currently is.
When disembedded, it saves harddrive space. When embedded, it still saves memory from duplicate code. And, that addon was so horribly written, and was bloated in size due to the fact that the author was basically re-writing several libraries and writing his addon in the same file.
I'm not saying it would be better Ace'd, I'm saying it would be better with the organization that would be imparted through the use of libraries.
Organizing and streamlining your addon code doesn't necessarily require using libraries, either.
Your point about saving disk space only applies if you have more than one addon using the same libraries. And depending on what you're doing, it may actually use more memory to implement something through a library. If all your addon needs is a simple event handler for a single event, you're much better off just doing:
-- do stuff here
MyAddOn.frame = CreateFrame("Frame")
MyAddOn.frame:SetScript("OnEvent", function(frame, event, ...) MyAddOn[event](...) end)
... than using an entire framework. In that example, Ace2 would only save you one line of code (the SetScript line) in your addon, and add some 200kb of code to your addon's total footprint (albeit reduced in proportion to the number of addons using the same libraries).
There are plenty of well-written addons with clean, organized code that don't use any libraries at all. If it helps you as an author write better code to use a framework, then use the framework. But the presence or absence of a framework doesn't inherently say anything about the quality or organization of the addon's code.
Also, although I haven't looked at MinimapButtonBag, it doesn't sound like it would really have any need for libraries, unless you want to use a framework to handle the basics of event handling, function hooking, saved variable management, and configuration. Non-framework libraries should only be created/used for functions that multiple addons are likely to use; I don't think identifying and moving/hiding minimap buttons is really a function that multiple addons need to be using side-by-side. :P
I used to use MinimapButtonBag a long while ago and didn't have any issues with it except for a few unnamed buttons not wanting to go in. I've also seen people using it recently and heard them recommending it to their friends and people on various forums. I don't use it myself, but this is the first I've heard of fps problems with that mod.
Just to be sure, you were using the current version of MBB that's hosted here, right? (It doesn't use any libraries, btw.)
Just to clarify why it would have been better to use libraries in that case was that the author re-wrote DewDrop into the mod, and the addon itself dealt mainly with FuBarPlugin mods, which almost guarantees the pre-existance of DewDrop on the user's computer.
I know the benefits of not using libraries, but MBB is a special case, as it is designed out of a need to organize a lot of addons, expected to deal with FuBarPlugin addons, and yet created a ton of duplicate code which was almost certainly already on the user's computer.
See, you would have had a valid point if you'd just said "it could benefit by actually using the Dewdrop library instead of stealing most of the Dewdrop library's code" instead of just "libraries would make it more organized" in the first place. ;)
Sorry about that, was trying to speak a little too generally.
And man, did that guy's code HURT. His OnUpdate and OnEvent handlers almost guaranteed trashed one (possibly multi-level ) table, and that was just directly inside those functions, not counting any other functions they might call. It actually was bloating itself to 10MB of memory and people were hitting 2 FPS with just it enabled.