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!"
-
View User Profile
-
View Posts
-
Send Message
Project AuthorIt'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.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumActually 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.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorI 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.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorI think you're right with the Providers. If the addon using the lib provides the methods...it would be "extended" via that mechanism anyway.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWeird 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.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorNow you sound like me.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDisclaimer: 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 endHrm... actually that could almost be made a library on its own.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorWould this other library be a possible candidate for the "extension to the basic tooltip library" idea I had? Future project, perhaps, if so...
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNot 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.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorHere'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() endI'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 endToo 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