Personally, I'm very excited by this idea. I've been lurking around on the forums here for a while, and finally bit the bullet to sign up for the forums yesterday. I must say I'm very impressed with the community here, and with Ace gathering support on the standard WoW forums, and its inclusion over more bloated alternatives, the futures looking alot brighter than it once was.
If anyone were to provide a TitanPanel addon based on Ace, i think this would be a major stepping stone in its evolution. A big break, if you will. Titan panel has been languishing away, neglected, for many months now. Although theres TitanPanel 2.xx being actively maintained,in my personal view, it simply no longer does anything useful but everything badly. There is such a thing as too much, and TitanPanel 2.xx defines that benchmark for me.
What TitanPanel needs is a sucessor. One that does everythign the old, simple, TitanPanel bar used to, but that can be extended into the functionality required by the users. Since many UI compilations use TitanPanel 1.25 over 2.xx for its smaller memory footprint, an newer version of TitanPanel would be greatly appreciated by many. But it also comes at the cost of allowing the user to do with it what they want. Adding one bar, with the option of adding a second, third, fourth, or even Nth bar. Setting width of the bar, anchor points, plugins loading per bar. The list goes on.
I'm fairly new to LUA, but I'm picking it up. Yes, its a little slow, but I'm picking it up much faster than I thought I would. In any case, I'd be happy to have a look at AceBar. I understand the need for many to have the ability to take old TitanBar plugins and have them link directly into TitanBar. The only think I am weary of though is the amount of overly zealous hooking that goes on, which would be completely unhandled by Ace. In my view this is a large potential problem since the dependancies of AceBar should be behaving nicely. The should be Ace'd. They should all be load on demand. Infact they should be a lot of things that they just won't be.
If I could have my own way, I would take away any backwards compatability between AceBar and TitanPanel plugins, but in the short to medium term, including such plugins would be a great boon to the user. And after all, if we don't provide their functionality, people simply won't use it. However in the medium to long term, I would suggest that the aim should be to phase out many, if not all, of the "non-native" AceBar plugins in favour of newer, Ace friendly, ones. I'm sure that if you start this project back up again, there would be many people who are willing and/or able to port various mods across to AceBar, even if only the most popular ones.
PS: Sorry this became so long. I have a habit of rambling aimlessly through my posts to try to get my point across.
You bring up many good points Stun. I'll toss in my say (again) :)
As I've become more familiar with Ace I think my biggest issue with Titan is that initially it was a good idea that didn't flesh out "the basics". Titan provided a great place to display info, and a fairly simple means to create settings UI that was plenty (dropdown menus). Setup UI's don't need to be big and bulky, most the time they're simple on/off toggles and menus handle this fine.
But after the initial concept, the bar with modules, was made no real progress was made with the base mod. It basically became a compilation, merging in one "useful to some users" feature after another. I've hated compilations ever since my first... yes the one that's everyone's first, Cosmos. Compilations are bloat, plain and simple.
So what do I expect Acebar to be? A wonderful base mod, easy for users and programmers alike. Naturally I'd love to see it integrate with the base Ace as much as ppossible, become just an appendage to the system. You couldn't imagine living without your arms, and Ace wouldn't be the same without AceBar.
What don't I want to see in Acebar? First and formost, no included modules, period. Yes, it should be released at the same time as a bunch of modules for it, the basic crap just like Titan, but for gods sake don't integrate them in! I think everyone who works on an Ace mod eventually begins to modularize their code. AceBar mods should all be modules of the base code.
Another thing I hated about Titan, it's "easy to use" settings API for programmers. For one I found it to ba a major PITA, there were a number of flaws. The defaults never would accept "off" as a value it seems. Nils didn't exist, the code stored a value, a placeholder sting, insted of "storing" a nil. Nils really aren't that hard to work with once you get used to how lua handles tables.
Anywho, enough partially drunken rambling from me, sorry if the typing is a mess :)
I agree tekkub. My idea is that AceBar should be more of a framework for a bar mod than an actual bar mod in its own right. It would have an overall basic layout similar to that of TitanPanel, but what it is realistcally is a framework for plugins. It says I will display what you tell me to display, now just go away and write a plugin to tell me what you want me to display, where as I worry about how I display it.
That to me was what made TitanPanel a great mod. You didn't need much UI experience to write a mod for it, all you needed to to was call the backend functions to get the numbers, strings, or whatever. Then you just said "Show this thing" and Titan handled it.
To me, the way forward seems to be almost the exact opposite of what AUF is aiming to do. AUF tells you what you can show the user, and you worry about how to show it. AceBar in my view should be handling all of the display, but it provides a framework which allows you to tell it what you are displaying. If i had my way, AceBar would also be hadling all AceBar plugin registration with the underlying Ace system.
That way the plugin writers will only need to worry about extracting the basic functionality or information from the game itself, and then Ace bar will display it. For example, if we want an ammunition count on the bar: You tell the panel to display an icon and a count. The icon is the same one that appears in your ammunition slot of the paperdoll, the item count is attainable by some other method that you write. Also you can then add functionality, so say if you mose over the icon, it'll show you the tooltip for the ammunition. The event regstration and handling for this would be done through the bar itself, which in turn registers it through Ace. Tthe bar will also just display the information you provide to it in a standardised format.
The idea is to basically make AceBar plugins Ace compliant by proxy. Even if the addon is written badly, if the registration is done through the bar, and the bar itself registers through Ace, you gain the ability to load and unload on demand regardless of whether or not the user can write the addon with Ace ideology in mind.
Good ideas all, i firmly am convinced that it should launch with no included modules also (although a money display and amm/bag slot count wouldnt hurt). and backwards compatibility shouldnt really be a priority, if its easy to make modules then hell i might actually get off my butt and release something :P.
I am also in agreement that AceBar should be nothing more than the handler of all plug-ins. Leave it up to the coding community to create the plug-ins. /nod
Thinking back, this is why I stopped using Titan. All the included stuff that I simply didn't use. The bloat. I hadn't really attributed the cause to that until Tekkub mentioned it.
Yea one should be adding modules they want, not removing ones they don't.
Frankly the more I think about this, AceBar should work much the way AceDebug works. Ace authors add in the funcs needed to drop info to AceBar. If the user has AceBar in they can enable output to it. AceBar would build it's menus off the basic command structure laid out for the addon, if there is one. The author wouldn't have to do any extra work, his menu would just be created using already defined info.
In the End, AceBar itsself would just be a highly adaptable display mechanism. Give the user control over where stuff is put, not just the simple "build up from the left" layout of Titan.
Man I can hardly wait for this, I made so many Titan mods just casue it was so easy to display info and make config menus without getting all involved in the XML.
Good ideas all, i firmly am convinced that it should launch with no included modules also (although a money display and amm/bag slot count wouldnt hurt). and backwards compatibility shouldnt really be a priority, if its easy to make modules then hell i might actually get off my butt and release something :P.
I think if it came with two modules I wouldn't use, it would hurt a lot. :)
AceBar would build it's menus off the basic command structure laid out for the addon, if there is one. The author wouldn't have to do any extra work, his menu would just be created using already defined info.
I believe you just described AceCommander... at least, on some level.
How would it handle, say, my mod that takes 2 number arguments, a word argument, and a string argument, to one of the commands?
/foo bar 3 4 Monkey See Monkey Do
Just converting basic settings options to a bar is nice, and a lot of mods are just a small info display with a bit more info they might want which fits into a tooltip... Are we saying that the titan mods like Inventory Hawk shouldn't work in our system, because they are too complex? I mean, I can see that. Inventory Hawk worked just as well without titan as it did with it. All it did with Titan was dock it for you...
KC is the one "in charge" of AceBar, right? KC, what are the general design ideas that are already there?
On the subject of "easy API" --
I think that's one thing that made TitanBar so popular. Anyone could come along and make a mod that did something they were interested in. Maybe Titan's sucked and was buggy and bloated, but it's important to consider... but I think it's one of the most important parts of a good system.
Helpers eh? I assume you mean to help you construct plaugins... Well, I would like to see a right-click menu, of course, and some other things. Nothing major though.
As for helpers, as I said I think displaying info on AceBar should mimic AceDebug in it's basic functionality (from the programmer's viewpoint). Only big diff is that you could display an icon if you want. Menus should build themselves from the command options of the mod, but also make it easy for a author to build a custom menu (i.e. you handle bar placement and behavior, the mod passes in what items to display on it.
Oh and drop this "update frequency" nonsense in Titan. Only update when the mod passes new data in. Titan Mods seem to run on OnUpdates from TitanPanel or OnEvents from the mod's own XML... AceBar mods should run off their normal events registered with Ace, or in a few rare cases off their own OnUpdates. In the case of OnUpdates AceBar should only update when the data changes.... I guess ideally the mod shouldn't be passing data to AceBar unless it's changed...
Yup, I've only ever used one OnUpdate, in SpecialEventsMovement... and look at how small it is :)
*Corrects self* Oh yea I use it in the cooldwon module too. Again I wrote it so that 90% of the time it just returns out quickly, and on the rare chance a update is needed then it does it.
I'm thinking though that perhaps AceBar shouldn't have any helpers at all aside from the menu thing and even that could be done cleverly by building a dynamic AceGUI module into the AddOn itself which the plugins send information to dynamically. Just use the GetID to figure out which set of information is plugged into the AceGUI dropdown.
Anyway, I was always thinking that Titan went too far, you know what I'd like to see? A basic 'panel' element with a text entry part that I could inherit. I'd then make my XML and inherit that. I'd use SetText myself and that would be that. The only real communication would be the right-click stuff and registering with the main bar-AddOn.
The main reason I think it should register back is the anchoring. I think Titan went too far. This is what I meant by having a frame that I could inherit, this frame would be like a tooltip background frame with an offset of five pixels and a fixed height. It would set the width dynamically AddOn-end by going via the text-string's length (there's a function for that).
Then, if a plugin's frame goes offscreen, dock it down onto the next "row" instead of vertically. So what you'd have are all these little tooltip-esque frames sitting next to each other. I'll try and draw up an example later to show you what I mean but personally, I think it'd look really minimalist and nifty because you'd get free screen space wherever you didn't have a plugin.
I'm almost thinking the reverse Rowne... why do we need the XML template at all. I look at all my Titan plugins and whet do they do... inherit the template and register it back to titan. After that everything I do is LUA, occationally telling Titan to update my button. Why not just make x generic buttons in AceBar, and when a module registers assign it the first free bar and plug it's info into it. Kinda like the way Timex works.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
If anyone were to provide a TitanPanel addon based on Ace, i think this would be a major stepping stone in its evolution. A big break, if you will. Titan panel has been languishing away, neglected, for many months now. Although theres TitanPanel 2.xx being actively maintained,in my personal view, it simply no longer does anything useful but everything badly. There is such a thing as too much, and TitanPanel 2.xx defines that benchmark for me.
What TitanPanel needs is a sucessor. One that does everythign the old, simple, TitanPanel bar used to, but that can be extended into the functionality required by the users. Since many UI compilations use TitanPanel 1.25 over 2.xx for its smaller memory footprint, an newer version of TitanPanel would be greatly appreciated by many. But it also comes at the cost of allowing the user to do with it what they want. Adding one bar, with the option of adding a second, third, fourth, or even Nth bar. Setting width of the bar, anchor points, plugins loading per bar. The list goes on.
I'm fairly new to LUA, but I'm picking it up. Yes, its a little slow, but I'm picking it up much faster than I thought I would. In any case, I'd be happy to have a look at AceBar. I understand the need for many to have the ability to take old TitanBar plugins and have them link directly into TitanBar. The only think I am weary of though is the amount of overly zealous hooking that goes on, which would be completely unhandled by Ace. In my view this is a large potential problem since the dependancies of AceBar should be behaving nicely. The should be Ace'd. They should all be load on demand. Infact they should be a lot of things that they just won't be.
If I could have my own way, I would take away any backwards compatability between AceBar and TitanPanel plugins, but in the short to medium term, including such plugins would be a great boon to the user. And after all, if we don't provide their functionality, people simply won't use it. However in the medium to long term, I would suggest that the aim should be to phase out many, if not all, of the "non-native" AceBar plugins in favour of newer, Ace friendly, ones. I'm sure that if you start this project back up again, there would be many people who are willing and/or able to port various mods across to AceBar, even if only the most popular ones.
PS: Sorry this became so long. I have a habit of rambling aimlessly through my posts to try to get my point across.
As I've become more familiar with Ace I think my biggest issue with Titan is that initially it was a good idea that didn't flesh out "the basics". Titan provided a great place to display info, and a fairly simple means to create settings UI that was plenty (dropdown menus). Setup UI's don't need to be big and bulky, most the time they're simple on/off toggles and menus handle this fine.
But after the initial concept, the bar with modules, was made no real progress was made with the base mod. It basically became a compilation, merging in one "useful to some users" feature after another. I've hated compilations ever since my first... yes the one that's everyone's first, Cosmos. Compilations are bloat, plain and simple.
So what do I expect Acebar to be? A wonderful base mod, easy for users and programmers alike. Naturally I'd love to see it integrate with the base Ace as much as ppossible, become just an appendage to the system. You couldn't imagine living without your arms, and Ace wouldn't be the same without AceBar.
What don't I want to see in Acebar? First and formost, no included modules, period. Yes, it should be released at the same time as a bunch of modules for it, the basic crap just like Titan, but for gods sake don't integrate them in! I think everyone who works on an Ace mod eventually begins to modularize their code. AceBar mods should all be modules of the base code.
Another thing I hated about Titan, it's "easy to use" settings API for programmers. For one I found it to ba a major PITA, there were a number of flaws. The defaults never would accept "off" as a value it seems. Nils didn't exist, the code stored a value, a placeholder sting, insted of "storing" a nil. Nils really aren't that hard to work with once you get used to how lua handles tables.
Anywho, enough partially drunken rambling from me, sorry if the typing is a mess :)
That to me was what made TitanPanel a great mod. You didn't need much UI experience to write a mod for it, all you needed to to was call the backend functions to get the numbers, strings, or whatever. Then you just said "Show this thing" and Titan handled it.
To me, the way forward seems to be almost the exact opposite of what AUF is aiming to do. AUF tells you what you can show the user, and you worry about how to show it. AceBar in my view should be handling all of the display, but it provides a framework which allows you to tell it what you are displaying. If i had my way, AceBar would also be hadling all AceBar plugin registration with the underlying Ace system.
That way the plugin writers will only need to worry about extracting the basic functionality or information from the game itself, and then Ace bar will display it. For example, if we want an ammunition count on the bar: You tell the panel to display an icon and a count. The icon is the same one that appears in your ammunition slot of the paperdoll, the item count is attainable by some other method that you write. Also you can then add functionality, so say if you mose over the icon, it'll show you the tooltip for the ammunition. The event regstration and handling for this would be done through the bar itself, which in turn registers it through Ace. Tthe bar will also just display the information you provide to it in a standardised format.
The idea is to basically make AceBar plugins Ace compliant by proxy. Even if the addon is written badly, if the registration is done through the bar, and the bar itself registers through Ace, you gain the ability to load and unload on demand regardless of whether or not the user can write the addon with Ace ideology in mind.
Thinking back, this is why I stopped using Titan. All the included stuff that I simply didn't use. The bloat. I hadn't really attributed the cause to that until Tekkub mentioned it.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFrankly the more I think about this, AceBar should work much the way AceDebug works. Ace authors add in the funcs needed to drop info to AceBar. If the user has AceBar in they can enable output to it. AceBar would build it's menus off the basic command structure laid out for the addon, if there is one. The author wouldn't have to do any extra work, his menu would just be created using already defined info.
In the End, AceBar itsself would just be a highly adaptable display mechanism. Give the user control over where stuff is put, not just the simple "build up from the left" layout of Titan.
Man I can hardly wait for this, I made so many Titan mods just casue it was so easy to display info and make config menus without getting all involved in the XML.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThough, I've stopped updating it since a few months ago... the new versions just seems too big =)
I think if it came with two modules I wouldn't use, it would hurt a lot. :)
-x
I believe you just described AceCommander... at least, on some level.
How would it handle, say, my mod that takes 2 number arguments, a word argument, and a string argument, to one of the commands?
Just converting basic settings options to a bar is nice, and a lot of mods are just a small info display with a bit more info they might want which fits into a tooltip... Are we saying that the titan mods like Inventory Hawk shouldn't work in our system, because they are too complex? I mean, I can see that. Inventory Hawk worked just as well without titan as it did with it. All it did with Titan was dock it for you...
KC is the one "in charge" of AceBar, right? KC, what are the general design ideas that are already there?
On the subject of "easy API" --
I think that's one thing that made TitanBar so popular. Anyone could come along and make a mod that did something they were interested in. Maybe Titan's sucked and was buggy and bloated, but it's important to consider... but I think it's one of the most important parts of a good system.
-x
I'm reading this trying to get an idea of the ammount of 'helpers' people really want.
So please keep the discussion up, but trust that I'm going for a KISS approach.
I was flat-out amazed at the smooth look, feel, and function.
Perhaps some ideas and concepts can be utilized from this for our version?
It's called..... BhaldieInfoBar over at WOWI...
As for helpers, as I said I think displaying info on AceBar should mimic AceDebug in it's basic functionality (from the programmer's viewpoint). Only big diff is that you could display an icon if you want. Menus should build themselves from the command options of the mod, but also make it easy for a author to build a custom menu (i.e. you handle bar placement and behavior, the mod passes in what items to display on it.
Oh and drop this "update frequency" nonsense in Titan. Only update when the mod passes new data in. Titan Mods seem to run on OnUpdates from TitanPanel or OnEvents from the mod's own XML... AceBar mods should run off their normal events registered with Ace, or in a few rare cases off their own OnUpdates. In the case of OnUpdates AceBar should only update when the data changes.... I guess ideally the mod shouldn't be passing data to AceBar unless it's changed...
*Corrects self* Oh yea I use it in the cooldwon module too. Again I wrote it so that 90% of the time it just returns out quickly, and on the rare chance a update is needed then it does it.
Anyway, I was always thinking that Titan went too far, you know what I'd like to see? A basic 'panel' element with a text entry part that I could inherit. I'd then make my XML and inherit that. I'd use SetText myself and that would be that. The only real communication would be the right-click stuff and registering with the main bar-AddOn.
The main reason I think it should register back is the anchoring. I think Titan went too far. This is what I meant by having a frame that I could inherit, this frame would be like a tooltip background frame with an offset of five pixels and a fixed height. It would set the width dynamically AddOn-end by going via the text-string's length (there's a function for that).
Then, if a plugin's frame goes offscreen, dock it down onto the next "row" instead of vertically. So what you'd have are all these little tooltip-esque frames sitting next to each other. I'll try and draw up an example later to show you what I mean but personally, I think it'd look really minimalist and nifty because you'd get free screen space wherever you didn't have a plugin.