I can now reliably state (after testing) that scaling the tip down from 1.0 after you've added something to a line that involves multiple columns has a chance to produce "trimmed" strings (and possibly textures, dunno, perhans Xinh can enlighten us on that).
it would be great if we have the possibility to change scale, border color & texture, background color & texture and the font used.
You have direct access to the tooltip frame, so you can handle these things as in any regular frame (theoretically at least, we are still performing tests on what works and what needs to be maybe addressed, hence the discussion above). As for the name, I like Xinhuan's suggestion so far.
There is definitely "distortion" on some cells when scaling down or up from the default value in initializetooltip. I suspect that it happens after you add some lines on the tooltip (I know for a fact that scaling immediately after acquiring works fine, since I've tested it) but I need to also test this today when I get home, in order to provide a reliable report.
Point No 1 :There is nothing wrong with TipTop, it's an addon to manipulate the GameTooltip and not custom ones.
Point No 2 : Scaling libtooltip's frame AFTER it has been created and populated, more often than not results in a screwed up tooltip, as lines can be "cut" especially when column spans are involved. If you want to do it right, you need to scale it, after it has been acquired. That's why its almost impossible for a display to do something about it, unless its using libtooltip natively. As for Broker_Factions, I'll add a slider to adjust scaling, hopefully this weekend.
The problem begins when you have to reference the "optional plugins" inside the main library and possibly "predict" cases of interaction, which means exposing/implementing potentially extra code that ultimately may or may not be utilized. Not saying that this is the case here or it's something bound to happen but if/when it does, the original purpose of writing something more "simple" becomes moot.
No offense to any author/user or tester out there but most of the Ace2/FuBar addons out there can be very easily "ported" to Ace3/LDB without the need/usage of Tablet. At least in my humble opinion. Configuration can be done via simple Blizzard dropdowns (ClosetGnome implements something like this) or very simple configuration menus with a bit of "creativity" on the authors part. No, it won't be as fancy or "easy" as Tablet's scrollable/clickable tips were and I recognize its usefulness in certain "long tooltip by default" situations, but its really not the end of the world. We were discussing on IRC what measures can be taken in libtooltip as to provide some kind of "extension" to support such implementations. Nothing is really set in stone, personally I'm with Torhal in regards to a more heavy/extended version of the library (eg minitablet :p), since apparently there is demand for it. And no I don't think that people would end up embedding just that, on the contrary there would be a choice in the matter, hell tek even trimmed the lib even more and seems to work fine for what he needs/wants to do :p
Well in my example factions tooltip, the library was using around 11 CPU time for a split second every time it had to "redraw" the tooltip (and about ~4 when releasing the tip to the heap). The addon code was hardly using any CPU.
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.
No dictionary or named arguments imo, the damn thing is grumpy as it is. Either find a viable way to pass a predefined unique object with the required attributes (that WILL be easier to read) or leave it as it is (or eliminate the cellProvider !! :pp).
Indeed it can, sorry but that wall of text wasn't actually more "readable" than Tablet documentation (no offense) and it took some time to sink in (perhaps I realized as well that I'm not as smart after all :p). Like I said, I'm not that much concerned about the size, since I do not foresee it will reach excessive or otherwise "unacceptable" amounts. I'm worried about the fact that we may be implementing something that will only be used rarely.
For Acquire/Columns I pretty much agree with everything mentioned, changing the num of columns or justification after acquire is a nice "bonus" (some may even find it absolutely necessary). As for CellProviders, as much as I read and understand what was outlined, I cant help but ultimately think that we are blowing this out of proportion and moving closer to a 'Tablerish' design, considering the original intention behind the library. And I'm not talking about the size here. Don't get me wrong its a cool concept and would allow the library to be potentially used for more advanced tips as well and that's exactly my problem. Why does someone that just needs a simple tip with 3-4 columns and maybe updating cells every now and then, have to specify a provider in SetCell (even an integrated/embedded one). Suggestion: We can go with our original idea and break this into 2 versions perhaps.
I'm not talking about the name used for the "registration", although I did express my concerns about its uniqueness (ultimately people will do whatever they want to, if you let them and I do agree if that is the case, then let them get errors), I was under the impression that you meant the Acquire method could potentially return a tooltip that is otherwise "unavailable" (being used/populated by another addon), instead of pulling a new one from the 'heap'.