As to why:
I disliked having bars overtaking eachother etc, I'd rather have a longer bar for longer cooldowns etc, just a linear expansion would be un-usable. Hence with this you can use a logarithmic function. where if 2 cooldowns are in the same place they will finish at the same time regardless of the total cooldown.
(a hacked cooldowntimers with log(time^3) used in calculating the bar length and the current bar value)
I would love these style bars as an option in bigwigs etc :)
Bar 1 (10s duration:
Bar 2 (2minute duration:
You should remember (especially on bosses like Noth) there are bars for blink (relatively short) and a bar for teleport. Your idea would make bars have stupidly small scales in order for them to fit on people's screens or scales which just go off the end of a screen.
Edit: I read you wanted to use a log scale, in which case I refer to my QFT with Ammo.
As an author of a CandyBars addon, and a user of several CandyBars addons, I think it'd be nice if we could try to come up with a system that allows for standardized configuration of CandyBars appearance.
As it stands right now, the amount of configurability and default settings for addons like oCD, CDT, Chronometer, Antagonist, etc. are all over the map, and for each of these addons users must learn a new set of commands to control the appearance of the bars. In some cases, there is simply no way apart from editing the code for the addons to get a uniform appearance from all of the bars.
So I've been trying to think of some potential implementations for this - here are a couple of my ideas.
A "CandyBars options" table stored in the library (or accessible via an accessor function that could change some parameters such as the location of the variable in which to store settings). Client addons would retrieve this table and inject it into their own options table and/or other configuration mechanism.
The CandyBars options would be pointed at a table variable to modify - probably stored in the addon's AceDB profile. A default table would also be retrievable from the library to allow a uniform default appearance.
The options table would be passed as a whole to a CandyBars function rather than using individual accessors. This would allow addon/removing/changing members of the options table without each addon author having to go through and change how his or her addon creates bars.
Sharing configurations between CandyBars addons would still need to be solved (although it would be easier to configure them individually to the same appearance, with a uniform configuration UI).
A CandyBars configuration management utility/addon. Addons based on CandyBars would not actually set any of the CandyBars appearance options themselves; instead, the options would be arranged into CandyBars option-sets by the configuration management utility, and addons would select which option set to use by name.
This allows for more easily sharing configurations, although I'm sure there are some downsides I haven't yet foreseen, as I didn't spend as much time thinking this one through.
Textures would be the other issue, and they seem to be a bit more complicated (as we seem to have found from the old default texture which had to be removed so that people stopped getting transparent bars). Maybe haste's new SurfaceLib can help with this one.
As CandyBar is a library and can be used in numerous ways there can and will be no real way of making sure every Candybar looks the same. Sometimes the bars need to be embedded in a frame of a certain size etc. For instance Candybars used in oRA2 cooldown are slightly less width than the default ones. Forcing every candybar in game to look the same way will cause more trouble than it would solve.
Getting a uniform appearance for all bars is easy: Don't touch the settings per default. The default look is the default look. At the moment Chronometer is the only candybar addon that has a different default look, maybe you should start by not changing it per def.
I can understand where people come from when they want a uniform look across all their addons, that's why candybar has an in my eyes sane default. Giving the user options to change the look depends on the author of the addon that uses it. Changing the look of all candybars to one layout from the library itself will never happen because that can and will break the look of another addon using the bars in for instance a frame of a certain width etc.
ct = AceLibrary("CandyBar-2.0");
ct:RegisterCandyBar("boo", 10, "text");
-- On another event handler, mine was @ UNIT_SPELLCAST_DELAYED
-- Some really evil mob hit me and delayed my spell for 110s
Expected result: the 2 minutes bar should vanish after 2 minutes.
What it does: sets the running bar to 2 mins and vanishes after 10 seconds.
I used this logic for aUF_CastBars (gonna rename mEnemyCastbar, it's not on enemy frame only anymore, and 100% tied into aUF), wondered why everything was wrong if a mob hits me and extend my casting time, and came to the conclusion that CandyBar-2.0 didn't take the new cast time in account.