ATM I'm thinking about doing the following changes to the API:
- adding a lib:IsAcquired("name") method,
- adding a "alignment" parameter to the tooltip:SetCell method, so one could override the column default.
We also have a lot of "setters" but no "getters", like :GetColumnAlignment(colNum), :GetColumnCount(), :GetLineCount(), ... Though they are not mandatory, they are easy to implement, sometimes handy and avoid to mess with the internals.
lib:IsAcquired() and :GetX() would definitely be things of great utility :)
ok, I'll start brain storming a clean API for this. hrm...
I think this would be a nice feature to have (colspan). And speaking of brainstorming...I go to work today and come home to a bunch of new code commits using the new API ideas... You've all been busy :)
About LDB, please remember that OnEnter, OnLeave and OnTooltipShow should be supported by the data object itself, not by the tooltip. That said, the tooltip might provide some GameTooltip compatible API (probably no more than :AddLine and :AddDoubleLine).
Yah, the idea is to have it as close to GameTooltip as possible, but without its cruft. AddDoubleLine() could be done easily by two calls of AddColumn()
The implementation is looking good so far, however, if we want to be using this on OnTooltipShow (speaking strictly from an LDB viewpoint) then we need the library to somehow return a frame that the displays can properly anchor to the objects, preferably a frame that has a unique naming convention, related to the object.
I'm trying to have this behave as closely to GameTooltip as possible, without having to do a bunch of arcane dances on the user's end - I provided Tooltip:SetPoint() so we could do this exactly in the same manner.
EDIT: Ok, I see what you mean. Yah, there should be a frame to pass for OnTooltipShow.
I guess things are way easier if people use this on OnEnter, OnLeave, we can ignore my first comment I guess, since we are handling the anchoring and with proper methods the displays can set tooltip attributes inside their objects script handlers (hopefully).
Ok, Adirelle, I added you as an author to http://www.wowace.com/projects/libtooltip/. I'd talked with Kaelten about this project last night and realized I needed to set the width and height of the columns for the FontString to show up (duh!) Looking at the code, you've done that and fixed the anchoring - as well as tweaking the orientation of the FontString to actually do what we're telling it to.
I had initially added the working data to the library object itself, but thought that exposed implementation details to addons which used it so I moved it to the data table to encapsulate it. You're right, though - that would end up leaking every time a new instance of the library was loaded and the Tooltip object itself is local to the file. That's what I get for being used to C/C++ :)
I thought I'd done that with GetFrame() and RemoveFrame() - must have missed something. I also see that you moved the backdrop init outside of Tooltip:Show(), which is where it properly belongs - no point re-creating the bgFrame every time we display.
Meh. So, I slapped something together that's an extreme alpha version. And since I'm a command-line coder with zero GUI experience, I can't seem to figure out the proper way to anchor frames: therefore, I can't test/fix what I have so far because the text doesn't display. Feel free to rip this apart and laugh at my ignorance. Mainly, fix my damn anchoring so I can continue. :D
Why complicate it really ? I agree with the idea of 2 separate libs (and people can just bugger off and embed whatever they need :p). Btw, I remember Orion saying that Tablet doesn't really depend on Ace2 which contradicts what Adirelle says. Afaik it does require AceLibrary but I have no idea if it is feasible to "port" it to Ace3 with only slight modifications.
Hehe, yea we are on the same page, only diff is me hoping that someone using the advanced lib woulndn't need to include the basic lib too.
I suppose the advanced lib could start out as the basic lib and then throw all the extensions in, but to me that's a maintenance nightmare. If something is changed/fixed in the basic lib, and the advanced lib requires it - it's already fixed there as well.
Ahh I think you misunderstood, I meant two libraries ;) I like where this is going, though I'm sure I'd need the more full version at one point or the other. How possible is it that the full version would embed (as in in the same file just using libstub) the lite version?
Ie. two libraries in one file/folder, so if the user has the lite version already loaded it'd upgrade or not the lite functions/methods as needed, as well as have the extended functions/methods as a seperate lib. So people who want the full version could just embed that and still have no code duplication with the lite version? (just thinking aloud here, could be a very dumb idea)
I'd think there should be two separate libraries. I don't want to have an immense library file in a small addon if I'm only going to be using the smaller subset. If I want the advanced functionality, then I'd include the lib that provided it. Ideally, the advanced lib would require the basic lib to implement its functionality/API, and have its own extensions.
To be honest, the whole idea is to make something a bit more simple than the current tablet but a bit more complicated than GameTooltip (yes I know, good luck to us :p), eg support proper columns with let's say alignment etc. If people really want most of the features of the old tablet, then whats the point really, we can use it as it is right now.
I don't want to embed a huge library for a small addon. :D