90% of addons that use DD also use Ace2 to a fair degree still.
If you really really need it then your going to either create a hard embed of a LS'ed Version, deal with Ace2 or seek alternate solutions like so: http://forums.wowace.com/showthread.php?t=15763
The problem is, that we don't want a bunch of "temporary fixes" that will turn out to be not so temporary and stick around for far longer then its good for them. Say you create a LS-DD now, people start using it because they think its the real finished deal, and we'll never get rid of it again. Now consider that everyone does that, just create a temporary library to fit his own needs. We'll be swamped with libraries that solely exist because people wanted to get rid of AceLibrary?
We'll most likely not accept any libraries that had only been converted from AceLibrary to LibStub for the sole purpose of removing Ace2. Whats your issue with just embedding AceLibrary the same way you embed LibStub? Or even just copy the file in if its more convenient for you?
If you really want to help, then help with writing a proper Ace3-Config compatible Dropdown library, and don't just port some old, abandoned code that even requires a second type of option table, or manual formatting, just because it was convenient for you.
You're right, we have a community, and we want to advance forward.
Porting DewDrop to LibStub is not the way to advance forward. Finishing and polishing the new dropdown library is the right goal, and if you want to help with that, sure, any help is appreciated - as i've said, its already half-done.
Thanks for the explanation. I still disagree and think it's preemptive fear of something that in practice may not be an issue at all (or more precisely is no more of an issue than addons still sitting around based on Ace2).
The fear of acelib->libstub flooding is also a bit irrational, because I can think of only very few libs that could even possibly fall into that category.
Basically the argument swings both ways. Using libstub is no worse than acelib. In fact the minute advantages have been discussed in this thread.
But alas, you guys have the power to decide admissability.
As for helping, I help where I can. I am still concerned that this feels very much like "this is where you can help" by a boss, and not like a community where people can tinker and even offer up temporary solutions or solutions that some people may not like.
Finish and polish up dewdrop-3.0 is a great goal. I'm sure well-maintained addons will switch to it quickly when it exists (mostly because aceconfig-2.0->3.0 is fairly easy!) But I strongly disagree that a council-of-few gets to decide goals for the community and confine what is permissible to the goals they set, which is how this feels.
I totally disagree that a libstubbed DD-2.0 does not advance anything. In fact I'm sure a lot of addons that have not gone from ace2->ace3 do that precisely because the overhead in porting is too great or just weird. Sitting on two frameworks simply because "you cannot have it libstubbed because it's not advancing" is roadblocking.
And yes I have my own private example, with a perfectly functional ace3 baggins in personal use. Well minus dropdowns... I would use a libstubbed DD-2.0 until DD-3.0 is here, but I won't double framework, exactly for the reasons also explained in this thread. You are entitled to disagree on this but aren't we supposed to be allow multiple ways of doing things? I.e. even if people personally disagree with a solution?
Clearly addons are improved by transitioning to ace3 for various reasons, so I would actually argue that while you want promote advancements, really you are roadblocking forward steps by requiring leaps.
For me the topic isn't dd at all, it's how free this community is to tinker and use different coding standards and philosophies. I still think you guys take a too confining stance and hope things will loosen up some.
I agree with Elsia. What has been blocking me from upgrading serenely to Ace3 is the lack of dropdown config menus.
Dropdown menus will always remain the fastest way to access settings... GUI are great when you have complex/many changes to make but for turning on/off a feature quickly or just check something, it's just a pain in the a..
IMO a "Ace3" Dewdrop lib would be bad IMO, bad like it was bad back in the day of the 5 teir menus that DD had. There is a great guide in the guides forum about how to use the blizzard drop down stuff. TBH if you need more than that then you might want to rethink your approach.
IMO a "Ace3" Dewdrop lib would be bad IMO, bad like it was bad back in the day of the 5 teir menus that DD had. There is a great guide in the guides forum about how to use the blizzard drop down stuff. TBH if you need more than that then you might want to rethink your approach.
- I do need a menu that is able to update its entries on the fly without having to close and re-open it.
- I don't like to duplicate code.
It really is a question of efficiency versus usability.
Dewdrop is incredibly efficient and powerful. But of course, one can always beat a generic solution with a tailor-made one when it comes to usability. This trade-off really is for the authors to decide.
- I do need a menu that is able to update its entries on the fly without having to close and re-open it.
- I don't like to duplicate code.
While i can applaud both points, this is not what i am conserned about really. I am conserned about this Ace3 Dewdrop turning into a horendus mess of multi-tired menus mucking about. Just don't want a flash back to those days... They where bad.
In those days, Dewdrop was the only simple and efficient configuration interface available... It's completely different now.
For complex configuration tasks, users will naturally use a config panel instead of fighting with multi-level drop-down menus!
That's why having a unique table for your options is important else you will deny users the choice (some options will only appear in drop-downs and others only in the panel...)
While i can applaud both points, this is not what i am conserned about really. I am conserned about this Ace3 Dewdrop turning into a horendus mess of multi-tired menus mucking about. Just don't want a flash back to those days... They where bad.
Very few addons ever forced you to use a dropdown menu interface for configuration. In fact, the only addon I can think of that did (and still does) do that is ElkBuffBars. For everything else, you've always been able to use a command-line interface or Waterfall.
I disliked the plethora of dropdown configuration menus at least as much as the next guy, but I have to admit that just because there was one over-represented bad use case for Dewdrop doesn't mean there aren't any good ones. Manufac/Producer is an interesting approach to tradeskill accessibility via multi-tier menus, for example.
Poo-pooing an Ace3 Dewdrop is throwing the baby out with the bathwater IMO.
Porting DewDrop to LibStub is not the way to advance forward. Finishing and polishing the new dropdown library is the right goal, and if you want to help with that, sure, any help is appreciated - as i've said, its already half-done.
been a while since this was mentioned. has there been any progress in the interim?
if so, can anyone point me to an example of use (test code, an addon using it, whatever) that could serve as some form of "documentation"?
If you really really need it then your going to either create a hard embed of a LS'ed Version, deal with Ace2 or seek alternate solutions like so: http://forums.wowace.com/showthread.php?t=15763
We'll most likely not accept any libraries that had only been converted from AceLibrary to LibStub for the sole purpose of removing Ace2. Whats your issue with just embedding AceLibrary the same way you embed LibStub? Or even just copy the file in if its more convenient for you?
If you really want to help, then help with writing a proper Ace3-Config compatible Dropdown library, and don't just port some old, abandoned code that even requires a second type of option table, or manual formatting, just because it was convenient for you.
You're right, we have a community, and we want to advance forward.
Porting DewDrop to LibStub is not the way to advance forward. Finishing and polishing the new dropdown library is the right goal, and if you want to help with that, sure, any help is appreciated - as i've said, its already half-done.
The fear of acelib->libstub flooding is also a bit irrational, because I can think of only very few libs that could even possibly fall into that category.
Basically the argument swings both ways. Using libstub is no worse than acelib. In fact the minute advantages have been discussed in this thread.
But alas, you guys have the power to decide admissability.
As for helping, I help where I can. I am still concerned that this feels very much like "this is where you can help" by a boss, and not like a community where people can tinker and even offer up temporary solutions or solutions that some people may not like.
Finish and polish up dewdrop-3.0 is a great goal. I'm sure well-maintained addons will switch to it quickly when it exists (mostly because aceconfig-2.0->3.0 is fairly easy!) But I strongly disagree that a council-of-few gets to decide goals for the community and confine what is permissible to the goals they set, which is how this feels.
I totally disagree that a libstubbed DD-2.0 does not advance anything. In fact I'm sure a lot of addons that have not gone from ace2->ace3 do that precisely because the overhead in porting is too great or just weird. Sitting on two frameworks simply because "you cannot have it libstubbed because it's not advancing" is roadblocking.
And yes I have my own private example, with a perfectly functional ace3 baggins in personal use. Well minus dropdowns... I would use a libstubbed DD-2.0 until DD-3.0 is here, but I won't double framework, exactly for the reasons also explained in this thread. You are entitled to disagree on this but aren't we supposed to be allow multiple ways of doing things? I.e. even if people personally disagree with a solution?
Clearly addons are improved by transitioning to ace3 for various reasons, so I would actually argue that while you want promote advancements, really you are roadblocking forward steps by requiring leaps.
For me the topic isn't dd at all, it's how free this community is to tinker and use different coding standards and philosophies. I still think you guys take a too confining stance and hope things will loosen up some.
Dropdown menus will always remain the fastest way to access settings... GUI are great when you have complex/many changes to make but for turning on/off a feature quickly or just check something, it's just a pain in the a..
IMO a "Ace3" Dewdrop lib would be bad IMO, bad like it was bad back in the day of the 5 teir menus that DD had. There is a great guide in the guides forum about how to use the blizzard drop down stuff. TBH if you need more than that then you might want to rethink your approach.
You'd better tell nevcariel, then. He's about to get started on some AceConfig voodoo based on some Dropdown menu code Antiarc wrote. :D
- I do need a menu that is able to update its entries on the fly without having to close and re-open it.
- I don't like to duplicate code.
Dewdrop is incredibly efficient and powerful. But of course, one can always beat a generic solution with a tailor-made one when it comes to usability. This trade-off really is for the authors to decide.
Looking forward to an Ace3 Dewdrop.
While i can applaud both points, this is not what i am conserned about really. I am conserned about this Ace3 Dewdrop turning into a horendus mess of multi-tired menus mucking about. Just don't want a flash back to those days... They where bad.
For complex configuration tasks, users will naturally use a config panel instead of fighting with multi-level drop-down menus!
That's why having a unique table for your options is important else you will deny users the choice (some options will only appear in drop-downs and others only in the panel...)
Very few addons ever forced you to use a dropdown menu interface for configuration. In fact, the only addon I can think of that did (and still does) do that is ElkBuffBars. For everything else, you've always been able to use a command-line interface or Waterfall.
Poo-pooing an Ace3 Dewdrop is throwing the baby out with the bathwater IMO.
Any news about this ?
Edit: just found this : http://www.wowace.com/projects/libdropdown-1-0/
It's not really usable yet.
been a while since this was mentioned. has there been any progress in the interim?
if so, can anyone point me to an example of use (test code, an addon using it, whatever) that could serve as some form of "documentation"?
thanks.