I dont think there are plans to port FuBar or FBP for that matter to Ace3. A minimap-button-lib however, why not. Maybe someone will care to create that.
Though a generic interface lib that could be used to integrate an addon into different bar or minimap addons where both 'clients' and 'servers' register to would be even better.
Though a generic interface lib that could be used to integrate an addon into different bar or minimap addons where both 'clients' and 'servers' register to would be even better.
Just what we need, a new lib to register 50 minimap buttons!
IMO libs need to be more independent. Especially things like FuBarPlugin. (Seems to me like a Rock monopoly.)
only because it's a skewed perspective.
In the beggining... there was nothing.. just addons mindlessly poluting the global space, and for a time this was good. Then we discovored that there was soemthing better.. locals, thus many things where developed because of this, one of witch was "Ace" as we know it now as "Ace1"
Then many good things happened and "Ace2" was created, and for a time this was also good. But in our arogance and pride those that had not had Ace2 began to become jelous, and the flame began. In Retrospect of Ace2, LibStub was born. It hailed the creed of independance of the monolitic-ness of Ace2. But we forget that Ace2 was a Singularity... there was nothing else like it.
It's not that Rock has the monopoly on LFBP3, or that Ace2 has the same with FBP2.. it's just that's what it was designed on. if you want to use the plugin there are requirements for it and that is how the author has decided it, end of story, no appeals.
Now if you'd like something different.... your prolly gona have to either write it yourself or find one to do it for you :D
I think that's skewed! You don't need Ace or Ace2 to have good code, or good coding practices. Nor does every independent addon mindlessly pollute the global namespace and run rampant with the CPU and garbage. In fact, I'd go so far as to say with the misconceptions about Ace2 and what Ace2 can provide easily, there's been just as large a flood as bad coders utilizing Ace to write poorly written addons as there are authors writing wasteful independent addons.
Any way, that's not really what I meant. But really that I don't like the design of basing libraries like FBP which are required to plug into FuBar off of a framework, especially given that it works as a mixin. Any other addons looking to utilize it now have to either base themselves off Rock or run through a little workaround and end up including Rock in their addon anyway. Doesn't seem like a clean solution to a plugin stub.
But yeah, that's the way it is, regardless. And depending on how complex FPB's code is, maybe I'll try to tackle an independent version of it... given that it won't suck up too much time to do.
I think that's skewed! You don't need Ace or Ace2 to have good code, or good coding practices. Nor does every independent addon mindlessly pollute the global namespace and run rampant with the CPU and garbage. In fact, I'd go so far as to say with the misconceptions about Ace2 and what Ace2 can provide easily, there's been just as large a flood as bad coders utilizing Ace to write poorly written addons as there are authors writing wasteful independent addons.
... obviously never saw the animated serize of matrix...
what you say is a given...
w/r to fubarplugin, it's the way it was made. You write as if there is a misconception about whats going on here, that is that the lib was coded as a plugin stub in a sense you identify with. In fact the lib was written for a purpose with in a exsiting system for what it was designed for and nothing more.
if you make your own, it will not have the same context nor use as fubarplugin. it'll have a different context and use, thus not comparable.
Just what we need, a new lib to register 50 minimap buttons!
I was rather thinking of a way for an addon to specify that they want an icon/text/tooltip and for addons providing the capability stating that they are able to show such things.
So for eg an addon for minimap buttons or a bucket of buttons, one for a FuBar style bar, Lego, ... register to the lib as servers and the other addons simply register as clients. The user is then able to choose for each client which server should be used to show it.
So as an addon developer you don't have to care about where to show your stuff since it's up to the user to decide.
Elky's got a great idea really. The biggest problem to hit Titan and Fubar has been that addons are specifically written for the "parent" bar mod. Even though they all do the same thing... an icon, text, hover tooltip and on-click action... people write specifically for one addon. Then it gets to the point where they aren't even writing an info addon that displays thru Fubar/Titan, but instead it's just a "quick launch" on-click only addon... god how I hate these...
To flesh out Elk's idea, this is what I think we *really* need. Drop the old Titan design of a base addon to manage the bar and plugins that render on it. Instead have addons provide an INTERFACE... something simple like GetText, GetIcon, OnEnter (returns back a frame, ideally a tooltip, which is anchored by the display addon and shown), OnClick and RegisterCallback (Called by the addon when it needs it's display refreshed). Then just register into a global table if your addon provides this interface.
On the flip side, Fubar, Titan... ANY addon can look at that global table and find information to render. The render addon handles all the details of layout, the info addon handles it's own crap and calls any registered callbacks when it needs a redraw.
To use Elk's client/server analogy, the info addon is like an RSS feed, and the Bar mod is like a feed reader.
*edit*
Side thought, "quick launch" addons should *not* register into this table. If anything, come up with a second interface for them to provide (icon, name, onclick) and a seperate table to register into. This way the bar addon could still provide support for them, and addons specifically designed to be a quick launch bar/menu/whatever can be made, without "true" info-display bar mods getting flooded with these no-info addons.
To flesh out Elk's idea, this is what I think we *really* need. Drop the old Titan design of a base addon to manage the bar and plugins that render on it. Instead have addons provide an INTERFACE... something simple like GetText, GetIcon, OnEnter (returns back a frame, ideally a tooltip, which is anchored by the display addon and shown), OnClick and RegisterCallback (Called by the addon when it needs it's display refreshed). Then just register into a global table if your addon provides this interface.
Or you could just say that the addon implements the model-part of the MVC design pattern and Titan/FuBar/whatever implement the view/controller-part. :)
Yes, that is the right way to do it. I don't even think it's that far from how it is being done today in FuBar due to the existence of FuBarPlugin. The difference is mainly that plugins explicitly assume FuBarPlugin today. If you could get rid of that direct dependency, you'd be close to an MVC-design. Though I might be too optimistic with this; I haven't studied FuBarPlugin that close. It might be a bit more difficult than that, I guess.
Author: pernicius
Date: Thu Jan 17 14:20:45 2008
New Revision: 58671
Log:
LibMMButton-1.0: initial commit
- A simple library to handle an minimap button.
but it needs alot of revision to update some methods..
--IMHO--
The CreateButton() needs to take a name and db object to put all it's stuff into that way we don't inadverantly create an interdependancy on AceDB and putting it in self.db place where it may or may not be.
Useage of CBH could be employed for handling the OnEnter/OnLeave/OnClick ect.
Yea Bam, right now every fubar addon out there either ReqDep's on Fubar proper, or embeds FBP in it so that it is ALWAYS displaying. What we need is to move to that thar fancy MVC crap and have the addon simply provide the data (be the model), Fubar/Titan display the data (be the view)... and I guess the controller would just be the callbacks from the data addon to the display addon for a refresh?
Info addon provides the data, but not the way to view it, simple as that.
Yea Bam, right now every fubar addon out there either ReqDep's on Fubar proper, or embeds FBP in it so that it is ALWAYS displaying. What we need is to move to that thar fancy MVC crap and have the addon simply provide the data (be the model), Fubar/Titan display the data (be the view)... and I guess the controller would just be the callbacks from the data addon to the display addon for a refresh?
The distinction between the view and the controller is not always clear. In most practical implementations of the MVC pattern you actually "collapse" the view and the controller into one component. The controller handles events from the user interface and the view is responsible for drawing (or writing or speaking or whatever). Since the underlying Blizzard widgets also handle both, that is probably the most natural way here too.
The model provides an interface for retrieving data and for registering listeners to be notified of changes (Observer pattern). The important thing is that the model has no knowledge about who or what is using it. It must know nothing about the view/controller.
So how does the view/controller know which models are available? One way could be a central registry of some sort - using the global environment (ugh!). I suppose one could also use meta-fields in the toc-file. I don't know which way is better.
so it sounds like we got the ideal fundamentals down. but this seems like we're recreating the AceGUI methods allready in place. The GUI lib provides the fundamentals that build the UI, the config registry holds the options tables, and the Config lib actualy implemnts the otpions table into the UI Elements. Am i to understand we're transposing this to having the module plugin to a generic system then have another addon that converts that data into it's own methods ect? basicly redesigning fubar or titan pannel?
You could call it applying the AceConfig design to fubar/titan if you want, but that's not really a great way to say it... you'll confuse people.
We're just looking into uncoupling the data addon (PerformanceFu) from the display addon (FuBar). Make the data addon completely independent, and the display addon (FuBar, Titan, whatever) pull it's data and display it. While it doesn't quite make sense when you think of all the plugins specifically designed for Fu, it makes a lot of sense for addons that use Fu as a secondary interface... like say, TourGuide could provide the interface and thus players could move it onto FuBar if they use it. I never intend to add Fu support to TG because I don't want all those god damn libraries in my addon, and many other devs feel the same way... but I'd be more than happy to provide a lightweight interface for ANY display addon to pull from, as then I don't have to support a specific one.
I really really like this idea, and I'd love to use TourGuide as a testbed for doing it...
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorJust what we need, a new lib to register 50 minimap buttons!
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumif config wrangler had a minimap icon that drop'ed down to show the configs that's registered to ace3config that'd be ideal imho
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumonly because it's a skewed perspective.
In the beggining... there was nothing.. just addons mindlessly poluting the global space, and for a time this was good. Then we discovored that there was soemthing better.. locals, thus many things where developed because of this, one of witch was "Ace" as we know it now as "Ace1"
Then many good things happened and "Ace2" was created, and for a time this was also good. But in our arogance and pride those that had not had Ace2 began to become jelous, and the flame began. In Retrospect of Ace2, LibStub was born. It hailed the creed of independance of the monolitic-ness of Ace2. But we forget that Ace2 was a Singularity... there was nothing else like it.
It's not that Rock has the monopoly on LFBP3, or that Ace2 has the same with FBP2.. it's just that's what it was designed on. if you want to use the plugin there are requirements for it and that is how the author has decided it, end of story, no appeals.
Now if you'd like something different.... your prolly gona have to either write it yourself or find one to do it for you :D
Any way, that's not really what I meant. But really that I don't like the design of basing libraries like FBP which are required to plug into FuBar off of a framework, especially given that it works as a mixin. Any other addons looking to utilize it now have to either base themselves off Rock or run through a little workaround and end up including Rock in their addon anyway. Doesn't seem like a clean solution to a plugin stub.
But yeah, that's the way it is, regardless. And depending on how complex FPB's code is, maybe I'll try to tackle an independent version of it... given that it won't suck up too much time to do.
If you have Ace3 standalone installed you don't need configwrangler, just hit /ace3 :p
As for a minimap button, Ace3 will never have that. Only the standalone Ace3 has a few slashcommands that's it.
-Ammo
-
View User Profile
-
View Posts
-
Send Message
Curse Premium... obviously never saw the animated serize of matrix...
what you say is a given...
w/r to fubarplugin, it's the way it was made. You write as if there is a misconception about whats going on here, that is that the lib was coded as a plugin stub in a sense you identify with. In fact the lib was written for a purpose with in a exsiting system for what it was designed for and nothing more.
if you make your own, it will not have the same context nor use as fubarplugin. it'll have a different context and use, thus not comparable.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI was rather thinking of a way for an addon to specify that they want an icon/text/tooltip and for addons providing the capability stating that they are able to show such things.
So for eg an addon for minimap buttons or a bucket of buttons, one for a FuBar style bar, Lego, ... register to the lib as servers and the other addons simply register as clients. The user is then able to choose for each client which server should be used to show it.
So as an addon developer you don't have to care about where to show your stuff since it's up to the user to decide.
To flesh out Elk's idea, this is what I think we *really* need. Drop the old Titan design of a base addon to manage the bar and plugins that render on it. Instead have addons provide an INTERFACE... something simple like GetText, GetIcon, OnEnter (returns back a frame, ideally a tooltip, which is anchored by the display addon and shown), OnClick and RegisterCallback (Called by the addon when it needs it's display refreshed). Then just register into a global table if your addon provides this interface.
On the flip side, Fubar, Titan... ANY addon can look at that global table and find information to render. The render addon handles all the details of layout, the info addon handles it's own crap and calls any registered callbacks when it needs a redraw.
To use Elk's client/server analogy, the info addon is like an RSS feed, and the Bar mod is like a feed reader.
*edit*
Side thought, "quick launch" addons should *not* register into this table. If anything, come up with a second interface for them to provide (icon, name, onclick) and a seperate table to register into. This way the bar addon could still provide support for them, and addons specifically designed to be a quick launch bar/menu/whatever can be made, without "true" info-display bar mods getting flooded with these no-info addons.
Or you could just say that the addon implements the model-part of the MVC design pattern and Titan/FuBar/whatever implement the view/controller-part. :)
Yes, that is the right way to do it. I don't even think it's that far from how it is being done today in FuBar due to the existence of FuBarPlugin. The difference is mainly that plugins explicitly assume FuBarPlugin today. If you could get rid of that direct dependency, you'd be close to an MVC-design. Though I might be too optimistic with this; I haven't studied FuBarPlugin that close. It might be a bit more difficult than that, I guess.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttp://groups.google.com/group/wowace/browse_thread/thread/79829a5d7322e9e3
but it needs alot of revision to update some methods..
--IMHO--
The CreateButton() needs to take a name and db object to put all it's stuff into that way we don't inadverantly create an interdependancy on AceDB and putting it in self.db place where it may or may not be.
Useage of CBH could be employed for handling the OnEnter/OnLeave/OnClick ect.
would work..
Yea Bam, right now every fubar addon out there either ReqDep's on Fubar proper, or embeds FBP in it so that it is ALWAYS displaying. What we need is to move to that thar fancy MVC crap and have the addon simply provide the data (be the model), Fubar/Titan display the data (be the view)... and I guess the controller would just be the callbacks from the data addon to the display addon for a refresh?
Info addon provides the data, but not the way to view it, simple as that.
The distinction between the view and the controller is not always clear. In most practical implementations of the MVC pattern you actually "collapse" the view and the controller into one component. The controller handles events from the user interface and the view is responsible for drawing (or writing or speaking or whatever). Since the underlying Blizzard widgets also handle both, that is probably the most natural way here too.
The model provides an interface for retrieving data and for registering listeners to be notified of changes (Observer pattern). The important thing is that the model has no knowledge about who or what is using it. It must know nothing about the view/controller.
So how does the view/controller know which models are available? One way could be a central registry of some sort - using the global environment (ugh!). I suppose one could also use meta-fields in the toc-file. I don't know which way is better.
## X-DataFeed: MyAddonObject
Something of the sort. As for "events", yea that's why we'd need a method to register a callback for data refreshes. CallbackHandler FTW!
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumtrue... sorry...
so it sounds like we got the ideal fundamentals down. but this seems like we're recreating the AceGUI methods allready in place. The GUI lib provides the fundamentals that build the UI, the config registry holds the options tables, and the Config lib actualy implemnts the otpions table into the UI Elements. Am i to understand we're transposing this to having the module plugin to a generic system then have another addon that converts that data into it's own methods ect? basicly redesigning fubar or titan pannel?
We're just looking into uncoupling the data addon (PerformanceFu) from the display addon (FuBar). Make the data addon completely independent, and the display addon (FuBar, Titan, whatever) pull it's data and display it. While it doesn't quite make sense when you think of all the plugins specifically designed for Fu, it makes a lot of sense for addons that use Fu as a secondary interface... like say, TourGuide could provide the interface and thus players could move it onto FuBar if they use it. I never intend to add Fu support to TG because I don't want all those god damn libraries in my addon, and many other devs feel the same way... but I'd be more than happy to provide a lightweight interface for ANY display addon to pull from, as then I don't have to support a specific one.
I really really like this idea, and I'd love to use TourGuide as a testbed for doing it...
-
View User Profile
-
View Posts
-
Send Message
Curse Premium