Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
Ok, so I worked a bit on your LibTooltip-0.1, that has become LibTooltip-1.0. I joined a full standalone lib with a test.lua.
You can test it by issuing "/run ttTest1()" (see joined pic).
I tried to :
- store most working data in the library table,
- reuse most tables to avoid leaks,
- make library data local to save some table lookups,
- run initialization codes only once.
I kept the metatable stuff, though I'm not sure what you intended to do with it.
About the API itself, I think we should take into account what Tekkub wrote in the LDB data specifications. This is not mandatory but it would help to easily integrate LibTooltip in any LDB display.
This looks very promising. I wonder if handle inline graphics better then Tablet do. I'll try to have a look at it sometime this week.
Ok, I've looked at the code. Some thoughts on this, feel free to jump at any time, correct any misconceptions, call me weird names or club me to death.
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. Perhaps implement a :Register method with the DO name as an argument that returns this (and probably an :IsRegistered method as well so that displays can use it for "detection") ?
Displays may want to manipulate the tooltip frame, font size wise or transparency/alpha wise. Do we want this to implement support for this ? Do you think it will bloat the library ?
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.
About the API itself, I think we should take into account what Tekkub wrote in the LDB data specifications. This is not mandatory but it would help to easily integrate LibTooltip in any LDB display.
What do you suggest to facilitate easier integration with LDB? This shouldn't really be LDB-only, though it is the initial reason I started working on the library...
EDIT: Ok, we should probably have a frame we can pass to the LDB display for OnTooltipShow.
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.
Displays may want to manipulate the tooltip frame, font size wise or transparency/alpha wise. Do we want this to implement support for this ? Do you think it will bloat the library ?
Yes, we want this. No, it won't bloat the library if done properly and it should mirror as exactly as possible how it's done in GameTooltip.
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).
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).
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()
Ok, I updated the library to the API we discussed yesterday. It is all dry-coded so I don't expect it to work at all.
I used the column/line layout that Kaelten proposed but I'm not sure if I made it right :
- columns : width is fixed using SetWidth, the LEFT is anchored to the RIGHT of the previous column (or the LEFT of the tooltip), the TOP and the BOTTOM are anchored to the TOP and BOTTOM of the tooltip,
- lines : height is fixed using SetHeight, the TOP is anchored to the BOTTOM of the previous line (or the TOP of the tooltip), the LEFT and RIGHT are anchored to the LEFT and RIGHT of the tooltip.
- cells: the LEFT and RIGHT are anchored to the LEFT and RIGHT of the column, the TOP and BOTTOM are anchored to the TOP and BOTTOM of the line.
Respecting the KISS principle, the tooltip only grows when its content does, i.e. it doesn't shrink when you update a cell with a shorter text (that would require to rescan all cell of a line and a column). However, the tooltip grows as soon as you add content to it, so there is no need to make a resizing pass when it is first displayed.
Looking at the API, I don't see how I'm going to change the alignment of a particular column or cell. Does this mean that there will be only a standard for that, something like Left, Center, Center, ..., Right?
Do you intend to have a maximum number of columns. The current Tablet is limited to 4 and that's annoying at time.
Also, have nothing to tell how many columns a section should have. Will the line be aligned based on the maximum number of columns in the tablet or will the lines with the same number of columns share the alignment implicitly?
Here's an example where some lines have 1 columns but other have two done with the current Tablet library, how would I use the API to replicate this? :
This is a sample of how the tooltip can be shown, in an LDB plugin (Broker RaidSave). The frame is a bit desaturated for my tastes but I didn't really play much with the frame provided by the library other than achor it properly and set its framestrata to TOOLTIP. So far, so good I guess, though the lib is still work in progress.
Looking at the API, I don't see how I'm going to change the alignment of a particular column or cell. Does this mean that there will be only a standard for that, something like Left, Center, Center, ..., Right?
You basically define the number of columns you want your tooltip to use when you "acquite" a tooltip frame, from the frame pool, using a name, eg the name of your addon.
Syntax is : lib:Acquire(name, numColumns, orientation1, orientation2, orientation3, ...)
the orientation can be the usual "LEFT", "CENTER", "RIGHT".
Do you intend to have a maximum number of columns. The current Tablet is limited to 4 and that's annoying at time.
We haven't really discussed it, I believe that at the moment there is no hardcoded limit but nothing is set in stone (yet).
Also, have nothing to tell how many columns a section should have. Will the line be aligned based on the maximum number of columns in the tablet or will the lines with the same number of columns share the alignment implicitly?
Here's an example where some lines have 1 columns but other have two done with the current Tablet library, how would I use the API to replicate this?
In my example, I used "smart" column assignment (for a lack of a better term). I basically did not acquire a frame right away (because I would have to specify a "static" number of columns and those may change either dynamically or by user preference from an addons options) but rather incremented a counter depending on the number of options active/selected and used a table to define orientation per "active" column. I then acquired the frame and used simple :AddLine methods to populate it (didn't even use a header, though I guess I could cook something up).
That being said, it was a bit more complicated than what I had envisioned :p but Kaelten and the rest of the peeps insisted ;)
Looking at the API, I don't see how I'm going to change the alignment of a particular column or cell. Does this mean that there will be only a standard for that, something like Left, Center, Center, ..., Right?
ATM the number of columns and their alignment are defined in the Acquire call. It might be possible that we added an alignment parameter to SetCell.
Do you intend to have a maximum number of columns. The current Tablet is limited to 4 and that's annoying at time.
No limitation yet. Given Lua 5.1 allows an unlimited number of arguments to :AddLine (which was not the case with Lua 5.0 when TabletLib was written), I don't think we'll add such limitation.
Also, have nothing to tell how many columns a section should have. Will the line be aligned based on the maximum number of columns in the tablet or will the lines with the same number of columns share the alignment implicitly?
There is no section (or category) as in TabletLib. The number of columns is fixed for the whole tooltip. And I'm not aware of any plan to add cells that spans several columns or rows.
Though now I'm wondering what AddHeader was really about. I'll ask Kaelten. ^^
Here's an example where some lines have 1 columns but other have two done with the current Tablet library, how would I use the API to replicate this? :
I think you cannot use LibTooltip to replicate this. LibTooltip is intended to be more than a simple GameTooltip but less than TabletLib.
The frame is a bit desaturated for my tastes but I didn't really play much with the frame provided by the library other than achor it properly and set its framestrata to TOOLTIP.
I think we'll set the frame strata to TOOLTIP by default. Other than that, the scale, alpha and backdrop is reset on acquire, so you can change it. We may add more parameters to the list of things to reset.
"Though now I'm wondering what AddHeader was really about. I'll ask Kaelten. ^^"
Actually now that you mention it, it's a good question. AddLine and SetCell theoretically supersede the functionality of AddHeader, since you can treat it as any regular line and even explicitly set the font, if you wish to do so.
Well I wrote the function sig for AddHeader to be a shorthand for creating a line with a header font.
I haven't even considered any kind of ColSpan type situation, but it actually would be possible fairly easy.... hrm
Thoughts?
I would certainly love to have Header line with different column span then the rest of the table, that would allow me to replace the existing Tablet nicely.
I would certainly love to have Header line with different column span then the rest of the table, that would allow me to replace the existing Tablet nicely.
ok, I'll start brain storming a clean API for this. hrm...
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis looks very promising. I wonder if handle inline graphics better then Tablet do. I'll try to have a look at it sometime this week.
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. Perhaps implement a :Register method with the DO name as an argument that returns this (and probably an :IsRegistered method as well so that displays can use it for "detection") ?
Displays may want to manipulate the tooltip frame, font size wise or transparency/alpha wise. Do we want this to implement support for this ? Do you think it will bloat the library ?
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).
-
View User Profile
-
View Posts
-
Send Message
Project AuthorI 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.
Good call.
I assume you're referring to moving the frame init outside of Tooltip:Show()?
As for the metadata, that can be scrapped. Just stuff I was fooling around with.
What do you suggest to facilitate easier integration with LDB? This shouldn't really be LDB-only, though it is the initial reason I started working on the library...
EDIT: Ok, we should probably have a frame we can pass to the LDB display for OnTooltipShow.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorI'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.
Yes, we want this. No, it won't bloat the library if done properly and it should mirror as exactly as possible how it's done in GameTooltip.
Exactly. :D
-
View User Profile
-
View Posts
-
Send Message
Project AuthorYou misunderstood: I want to support OnTooltipShow as well.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Project AuthorYah, 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()
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI used the column/line layout that Kaelten proposed but I'm not sure if I made it right :
- columns : width is fixed using SetWidth, the LEFT is anchored to the RIGHT of the previous column (or the LEFT of the tooltip), the TOP and the BOTTOM are anchored to the TOP and BOTTOM of the tooltip,
- lines : height is fixed using SetHeight, the TOP is anchored to the BOTTOM of the previous line (or the TOP of the tooltip), the LEFT and RIGHT are anchored to the LEFT and RIGHT of the tooltip.
- cells: the LEFT and RIGHT are anchored to the LEFT and RIGHT of the column, the TOP and BOTTOM are anchored to the TOP and BOTTOM of the line.
Respecting the KISS principle, the tooltip only grows when its content does, i.e. it doesn't shrink when you update a cell with a shorter text (that would require to rescan all cell of a line and a column). However, the tooltip grows as soon as you add content to it, so there is no need to make a resizing pass when it is first displayed.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorSounds good. I'll check it out when I get home from work.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDo you intend to have a maximum number of columns. The current Tablet is limited to 4 and that's annoying at time.
Also, have nothing to tell how many columns a section should have. Will the line be aligned based on the maximum number of columns in the tablet or will the lines with the same number of columns share the alignment implicitly?
Here's an example where some lines have 1 columns but other have two done with the current Tablet library, how would I use the API to replicate this? :
You basically define the number of columns you want your tooltip to use when you "acquite" a tooltip frame, from the frame pool, using a name, eg the name of your addon.
Syntax is : lib:Acquire(name, numColumns, orientation1, orientation2, orientation3, ...)
the orientation can be the usual "LEFT", "CENTER", "RIGHT".
We haven't really discussed it, I believe that at the moment there is no hardcoded limit but nothing is set in stone (yet).
In my example, I used "smart" column assignment (for a lack of a better term). I basically did not acquire a frame right away (because I would have to specify a "static" number of columns and those may change either dynamically or by user preference from an addons options) but rather incremented a counter depending on the number of options active/selected and used a table to define orientation per "active" column. I then acquired the frame and used simple :AddLine methods to populate it (didn't even use a header, though I guess I could cook something up).
That being said, it was a bit more complicated than what I had envisioned :p but Kaelten and the rest of the peeps insisted ;)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumATM the number of columns and their alignment are defined in the Acquire call. It might be possible that we added an alignment parameter to SetCell.
No limitation yet. Given Lua 5.1 allows an unlimited number of arguments to :AddLine (which was not the case with Lua 5.0 when TabletLib was written), I don't think we'll add such limitation.
There is no section (or category) as in TabletLib. The number of columns is fixed for the whole tooltip. And I'm not aware of any plan to add cells that spans several columns or rows.
Though now I'm wondering what AddHeader was really about. I'll ask Kaelten. ^^
I think you cannot use LibTooltip to replicate this. LibTooltip is intended to be more than a simple GameTooltip but less than TabletLib.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI think we'll set the frame strata to TOOLTIP by default. Other than that, the scale, alpha and backdrop is reset on acquire, so you can change it. We may add more parameters to the list of things to reset.
Actually now that you mention it, it's a good question. AddLine and SetCell theoretically supersede the functionality of AddHeader, since you can treat it as any regular line and even explicitly set the font, if you wish to do so.
I haven't even considered any kind of ColSpan type situation, but it actually would be possible fairly easy.... hrm
Thoughts?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI would certainly love to have Header line with different column span then the rest of the table, that would allow me to replace the existing Tablet nicely.
ok, I'll start brain storming a clean API for this. hrm...