Some people claim that it makes it incompatible with GPL, I don't really care about that personally, regardless there are other people who say it doesn't make it incompatible with GPL.
The purpose of that clause is so I can go to sites that steal our files and say "As per clause 3, take it down!" I got tired of people saying, "oh? but it's GPL!"
This idea was to generate LineAcquired, LineReleased (and ColumnXXX) events. One could use these callback to customize those frames (e.g. make them clicky or whatever). However, this might just be overkill.
It's not overkill if it's well-thought-out and doesn't make the library a monster. This would allow us to keep a simple multi-column tooltip with the extensibility do to things which made Tablet so large and unwieldy. Not-built-in, but still able to facilitate it? Awesome.
It's not overkill if it's well-thought-out and doesn't make the library a monster. This would allow us to keep a simple multi-column tooltip with the extensibility do to things which made Tablet so large and unwieldy. Not-built-in, but still able to facilitate it? Awesome.
Actually I'm not sure how this could be extended and if what I proposed could do the trick. If one wanted to customize a line or a column, wouldn't be using Line/ColumnProviders a better way to do it ? I don't have clear use cases to work on. This might have been a false good idea.
Some people claim that it makes it incompatible with GPL, I don't really care about that personally, regardless there are other people who say it doesn't make it incompatible with GPL.
The purpose of that clause is so I can go to sites that steal our files and say "As per clause 3, take it down!" I got tired of people saying, "oh? but it's GPL!"
I personally don't care if it's GPL - it's a script LIBRARY, after all. :) At any rate, I think the Ace3 license would be fine.
Actually I'm not sure how this could be extended and if what I proposed could do the trick. If one wanted to customize a line or a column, wouldn't be using Line/ColumnProviders a better way to do it ? I don't have clear use cases to work on. This might have been a false good idea.
I think you're right with the Providers. If the addon using the lib provides the methods...it would be "extended" via that mechanism anyway.
Actually CBH would be very beneficial if we provided more high-level API.
Disclaimer: what follows is an example of what could be such high-level API. I do not intend to add it to LibTooltip.
local LibTooltip = LibStub('LibTooltip-1.0')
function addon:SetupTooltip()
-- create an object that will take care of showing/hiding/fading the tooltip
local hh = LibTooltip:CreateHoverHandler(self)
-- configure it to wait 1 seconds before hiding the tooltip
hh:SetHideDelay(1)
-- configure it to fade out the tooltip in 0.5 seconds
hh:SetFadeDelay(0.5)
-- tell it to call our handler when the tooltip is about to be shown
hh.RegisterCallback(self, "OnTooltipShow")
-- tell it to show the tooltip when hovering our frame1, frame2 or frame3
hh:RegisterFrame(self.frame1, 1)
hh:RegisterFrame(self.frame2, 1)
hh:RegisterFrame(self.frame3, 2)
end
-- This handler is called when one of our frame is entered and the tooltip is
-- about to be shown.
function addon:OnToolipShow(tooltip, frame, arg)
tooltip:SmartAnchorTo(hoveredFrame)
if arg == 1 then
tooltip:AddLine("Hovering a frame with arg == 1")
else
tooltip:AddLine("Hovering a frame with arg ~= 1")
end
end
Hrm... actually that could almost be made a library on its own.
I finished the API documentation. While writing it I realized that some methods were useless in the CellProvider and Cell interfaces. I updated the library accordingly (r26). The base API only documented mandatory methods (i.e. what is strictly used by LibTooltip). The second page documents what could be done with :CreateCellProvider (which is not required to setup a CellProvider).
Would this other library be a possible candidate for the "extension to the basic tooltip library" idea I had? Future project, perhaps, if so...
Not even "extension to the basic tooltip library". Just a library that could be used on its own to easily handle hovering over several frames, hide delays and fadings.
I finished the API documentation. While writing it I realized that some methods were useless in the CellProvider and Cell interfaces. I updated the library accordingly (r26). The base API only documented mandatory methods (i.e. what is strictly used by LibTooltip). The second page documents what could be done with :CreateCellProvider (which is not required to setup a CellProvider).
Please update the project site with links on the main page to the docs and sample screenshots please. I find the work you are discussing in this thread interesting... but I want a better feel for it's implications.
Please update the project site with links on the main page to the docs and sample screenshots please. I find the work you are discussing in this thread interesting... but I want a better feel for it's implications.
This is all still work in progress, using r27, but you get the idea. It's very much functional at the moment, though it does require you to get used to its API and philosophy.
those are looking pretty good man. very spiffy. mind pasting the code you used to render those?
Here's a screenshot of the tooltip for nanoTalk, and the code to render it:
local function ShowTooltip()
tip:Clear()
tip:AddHeader("nanoTalk")
tip:AddLine(" ")
local count = GetCount(nanoTalk.trackTime)
local linenum
if (count > 0) then
tip:AddHeader("|cffff9933Name|r", "|cffff9933Messages|r", "|cffff9933Last|r")
for _, tm in ipairs(timestamps) do
local curtm = GetTime() - tm
if (curtm <= nanoTalk.trackTime) then
linenum = tip:AddLine(people[tm].name, people[tm].msgs, TimeStr(curtm))
updatedLines[linenum] = tm
end
end
tip:AddLine(" ")
linenum = tip:AddLine("Left Click:")
tip:SetCell(linenum, 2, "Clear list.", tip:GetFont(), "LEFT")
else
tip:AddLine("No messages.")
tip:AddLine(" ")
end
linenum = tip:AddLine("Right Click:")
tip:SetCell(linenum, 2, "Configure.", tip:GetFont(), "LEFT")
tip:Show()
end
I'm thinking of adding some higher-level API calls such as tip:SetCellVal() so I can forgo using tip:GetFont() and re-entering the justification when all I want to do is update the text in a cell.
Here's what I call in nanoTalk:OnUpdate()
if (tip:IsShown() and #updatedLines) then
for linenum,tm in pairs(updatedLines) do
tip:SetCell(linenum, 3, TimeStr(GetTime() - tm), tip:GetFont(), "CENTER")
end
end
The purpose of that clause is so I can go to sites that steal our files and say "As per clause 3, take it down!" I got tired of people saying, "oh? but it's GPL!"
It's not overkill if it's well-thought-out and doesn't make the library a monster. This would allow us to keep a simple multi-column tooltip with the extensibility do to things which made Tablet so large and unwieldy. Not-built-in, but still able to facilitate it? Awesome.
Indeed. It's tiny and does the job.
Actually I'm not sure how this could be extended and if what I proposed could do the trick. If one wanted to customize a line or a column, wouldn't be using Line/ColumnProviders a better way to do it ? I don't have clear use cases to work on. This might have been a false good idea.
I personally don't care if it's GPL - it's a script LIBRARY, after all. :) At any rate, I think the Ace3 license would be fine.
I think you're right with the Providers. If the addon using the lib provides the methods...it would be "extended" via that mechanism anyway.
Weird is the word. I mean, finally, why bother providing another extension point when we don't see clear cases ? Let us forget I had that idea.
Now you sound like me.
Disclaimer: what follows is an example of what could be such high-level API. I do not intend to add it to LibTooltip.
Hrm... actually that could almost be made a library on its own.
Would this other library be a possible candidate for the "extension to the basic tooltip library" idea I had? Future project, perhaps, if so...
Not even "extension to the basic tooltip library". Just a library that could be used on its own to easily handle hovering over several frames, hide delays and fadings.
Please update the project site with links on the main page to the docs and sample screenshots please. I find the work you are discussing in this thread interesting... but I want a better feel for it's implications.
API reference
This is all still work in progress, using r27, but you get the idea. It's very much functional at the moment, though it does require you to get used to its API and philosophy.
Here's a screenshot of the tooltip for nanoTalk, and the code to render it:
I'm thinking of adding some higher-level API calls such as tip:SetCellVal() so I can forgo using tip:GetFont() and re-entering the justification when all I want to do is update the text in a cell.
Here's what I call in nanoTalk:OnUpdate()
Too big? How the hell does it feel too big?
It's 500 lines, has a very minimal API.
We added in hooks to allow for more advanced behaviors without adding much code.
Why didn't you speak up at some point in the last week or so and talk to us about it while we where designing it. :P