It's not under active development or maintenance as far as I know, but it still works the same as it ever did. I use it in a couple of my addons, and it definitely takes some getting used to, but works fine.
Right... well... because of the way sorting works ( it doesn't actually sort your table, it makes a sort-reference table ) You must call it when the data changes... I think refresh used to work back before I made sorting... it's been a while. I know you don't sort... but if you add data to the table I don't think you'll get the needed references in the sort table... that might be something I could fix... I'll have to think about that one. In the mean time, just call SortData after each addition ( or group of additions, if possible )
Additional note: a lot of the other ST functions are coded to call ST:Refresh, which can be hooked by the user. This doesn't help as much as it could, because SortData calls DoFilter (which actually adds the lines), and then SortData calls the (possibly hooked) Refresh. So hooking Refresh to (say) update the data table falls short, because it doesn't call SortData/DoFilter. And if the hooked Refresh calls SortData, it causes an infinite loop. (Setting and then clearing a flag around the call to SortData would be required, but that starts leading down an ugly path.)
The bad news is using |t is terrible. There's padding that I couldn't seem to control around the icons.. and it just ended up looking bad...
I ended up using |T for the first case, because doing it any other way would have been a serious pain.
I did eventually figure out how to use a custom DoCellUpdate from looking at Core.lua, and now I'm creating textures attached to the button frames that ST already creates. As more people do this kind of thing, I'm sure some kind of semi-standard routine will evolve.
There are two places I'd like to be able to use icons. Nothing clickable or otherwise special, just there. In one case the icon is its own texture path and can be displayed with |T embedded in text. The other case requires a subset of a texture, using SetTexCoord, which cannot be done with |T. I'm going to try grabbing the particular st buttons and then using a CreateTexture/SetTexture/SetTexCoord sequence.
i grow and shrink my scrolling table in gyp without much difficulty. i just call SetDisplayRows() with the new value. i fire it off when i resize my window, account for borders, then divide by the row size, then call SetDisplayRows... i might call SetDisplayCols as well because it might require calling both (can't remember off the top of my head).
That new value isn't available during the initial display. None of the callbacks for resize ever get fired. I know, because I littered AceGUI-3.0.lua and AceGUIWidget-TabGroup.lua with print() statements. Every size-type number came back with the hardcoded placeholder defaults. For TabGroup, that's a height of 100(frame), 70(border), or 50(content), depending on which member frame was being queried out of desperation that time around. All of the pre-hooked, automated, should-just-work callbacks receive those values.
After the UI cycles, all those numbers become useful, but then it's too late. I shrugged, hacked around it, and now I don't care.
i don't see any reason you couldn't create an intermediary parent than is exactly the size of the table you want, hook the sizechange event, and have the frame resize automatically call a SetDisplayRows function with the proper number of rows. or for that matter, this could even be built into lib-st's main frame perhaps...
I never claimed that no solution was possible. I'm sure that could be made to work. Somebody who actually understands the code could probably do lots of things.
Actually, I lied, there's one area that was causing problems. A proper solution would require modifying acegui+lib-st code, so I just kludged around it for my addon and went on.
There's no good way to have a lib-st object expand to fill vertical space. The parameters are "height of each row" and "number of visible rows", but there's no easy way of saying "display however many rows fit in <Y> amount of pixels" or (ideally) "vertically expand to fit <that> frame".
Coming from the other direction, all of AceGUI's containers revolve around GetHeight() calls... but those don't return useful information until after the UI has finished its redraw cycle. Until then, they return the sizes based on their hardcoded default values (50x50, 100x200, etc), even though :SetPoint has already been dispatched to anchor them to larger sizes. That's mostly a limitation of the Blizzard system, although this is where the kludge comes in. I document it here mostly so that others coming after me will understand why this part of the code is so cringeworthy.
If you've looked at the mockup screenshots I posted, you'll see I'm using a TabGroup container. The lib-st widget is going to be in one (maybe more) of those tabs. In order to get the visible interior height of the tab drawing area, I stuck code in at the bottom of the bit that populates one of the other tabs. It calls tabs.children.frame:GetTop() and :GetBottom(), subtracts them, prints the result. I will pause here so that you can finish retching. Those functions return correct values in this case.
It printed 366.something pixels. I said, fine, screw it, and so the "number of displayed rows" argument passed to CreateST is math.floor(366/rowheight). I drank a bottle of vodka to quiet the complaining voice of the conscientious computer scientist deep within me, noticed that the displayed lib-st object fit perfectly in the tabgroup, and got on with the rest of the addon. I'll probably have to disable resizing the addon frame as a whole, but meh.
So yeah, that's the only disconnect. AceGUI containers can't tell you the calculated height until after they've been populated; lib-st objects have to be told their total height ahead of time. My ugly "iterative" hardcoded number lets me make progress but clearly isn't a good general solution.
A related problem is column width, but goals like percentage widths and suchlike have been discussed in this thread already.
I've also been worried that the structure of lib-st does not follow any of the AceGUI conventions...
I tried, very very briefly, to do the true "wrapper" layer thing... not going to happen, at least not on this iteration. Trying to take the common AceGUI widget API and translate all of it into lib-st calls is just not feasible in many cases, especially with regard to On* events.
Instead, this version takes the viewpoint that the user will need to know how to work with a lib-st object directly. The user can either set up the lib-st object and then create a widget around it, or else can create the widget and then reach inside to control the st. It's a very thin wrapper, just enough functionality that an AceGUI container can treat this widget like any other widget.
I also considered making the lib-st a container instead of a plain widget. That fell apart faster than a cheesecake hitting a lake. Making an st object able to contain other AceGUI widgets would require rewriting large chunks of lib-st, which is beyond the scope of what I wanted to accomplish (to me, the lib-st widget wrapper is a means rather than the ends).
I hope you find the lib useful and easy to work with.
There are two things that sort of bother me a little bit.
(1) I was surprised that there is no "AddRow"-type function. It could simply take a table representing another ("row object" as SetData calls them), insert it into the larger .data table, and go through the same refresh/resort routine as the major SetData does.
This isn't going to be a problem for my addon, since I'm maintaining an external "real" version of the data table. As the data expands every few minutes, I append another row object and then re-call SetData passing in the same table.
(2) There's going to be a lot of garbage collection churn, and that's just with lib-st, not the widget wrapper. There are improvements that could be made but would require nontrivial changes to lib-st, so I'm trying to avoid thinking about that until the larger project is finished. :-) There might be a suggested patch emerging out of this, or maybe not, depending on caffeine and motivation levels!
All told, lib-st beats the hell out of anything I could have done by hand.
Ain't got anything usable yet. It's somewhat specific to my guild, but I'll probably end up posting it somewhere as a working example of how to abuse the widget code. The fix from Nevcairiel came out of http://forums.wowace.com/showthread.php?t=17114 and you can see the placeholder labels where lib-st is going to go. (Was using "stuff goes here" and some alphabet text in a two-column table.)
Just FYI, I am dangerously close to getting a working lib-st widget wrapper for AceGUI-3. I'll post code once there's stuff mostly working; I keep having to jump between rewriting my own addon, to the lib-st<->AceGUI wrapper, to either of those behind-the-scenes libraries, and then back again. (Thank Nevcairiel for getting me this far!)