Discussion on Scroll box methods
 

Howdy all, I'm hoping for a bit of discussion on the pros and cons of the scroll box methods.

I'm working on my re-write of the QuestGuru functionality and I'm stuck going in a circle about which method to use for the tracker component. The tracker component is backed by a table which contains all manner of info about the quests which the player has. My problem is what to use to display that junk, erm, rich information.

There are three (probably more to the sufficiently imaginative) methods to do the scroll box:
Regular ScrollFrame
FauxScrollFrame
Draw-it-all-yourself

The Faux Scroll Frame works great if the repeating contents are all the same size, row to row. Simply create x display holders and re-fill them with the contents from the offset for the number of holders.

The Regular Scroll Frame requires that I draw the whole mess into a buffer and it re-draws at scroll or when you re-load the buffer. Downside is that you re-draw it all each refresh and if you have a small window relative to your data size, lots of wasted cycles and object allocation.

Draw-it-all-yourself is infinately flexible, but also quite demanding.

Since the Blizzard Quest Log is (currently) limited to 25 quests, the Regular Scroll Frame may not be such a waste for me. My presentation per "row" is highly variable depending upon number of objectives, POI Icons, Use-for-Quest icons, and settings for expand and contract available for zones & quests so I don't think Faux will fit. Draw-it-all-yourself may be a bit out of my league, but I think it would be enlightening (no mention of fun there...).

So, Can I use Faux Scroll Frame for irregular sized holders (one might take 1 row and another might take 10)?

Is the Regular Scroll Frame very wasteful of resource?

Anybody do the Draw-it-all-yourself option?

How do you handle expand the frame up from the bottom to a maximum number of "rows" when the number of rows and the size of the rows is so highly variable?

Looking for wisdom from the masters,
-grasshopper

It sounds like you'd call that 3 rows (3 quests, each with a different number of objectives) but as far as the FauxScrollFrame is concerned, it's actually 10 rows (3 quests + 7 objectives).

That's true
 

(Phanx, thanks for your comments)

such that you can fit the various parts in rows. The UseQuestLogSpecialItem Icons take up vertical space as well and where to put the POI icons & other nik-naks that ornament the display? It's not purely text. To use the Faux, I need to keep track of how many rows I've consumed as I fill the interior, but some elements span a "row" or more.

A zone may or may not be collapsed, a quest may or may not be collapsed, an objective may or may not have a use item. A quest can have a POI icon hanging out there which will appear if in the correct zone and the zone is not collapsed. Not to mention the "pop up" (for lack of a better term) for discovered quests and my own pop up for "bag quests" (when you collect something that starts a quest).

With a Faux scroller, it appears to come down to the number of "rows", but does it really matter what I stick in the display window as long as I can construe it to be so many "rows" ?

Let's keep it coming, wise readers. I'm sure it'll help somebody else some day besides me.

-g

There's the HybridScrollFrame...combines Faux with normal. Works decently well.

You can put anything you want inside a row. Each row is just a frame; it can contain any number of fontstrings, textures, buttons, etc. The default ignore list and friends list both use a FauxScrollFrame.

Collapsed category: 1 row

Expanded category with 4 quests, all collapsed: 5 rows (1 for the category header, 1 per quest)

Expanded category with 4 quests, all expanded, with 1, 2, 3, and 4 objectives respectively: 15 rows (1 category header, 4 quests, 10 objectives)

Can't the icons be on the same row as the text, like the item buttons in the default quest tracker? I admit, I've never used QuestGuru or any other non-default quest tracker, but I can't imagine what icons or buttons could need to be all that huge.

@Torhal. I'll look at that. do you have any links you recommend I review.

@Phanx. Is it a problem that one frame might be 1/8 inch high and the next 2 inches high? as long as I can construe the second frame as consuming 16 "rows" ?

The row might be approx 1/8 inch in height (whatever the scale might be), clicking on a special use icon 1/8" x 1/8" would be unpleasant, so it's going to be about 1/2" by 1/2" or so. That would be 4 "rows" in one frame.

Remember, I'm trying to get a grip on these so I'm asking what might be stupid questions to those that are familiar with using them.

Also looking for when one type might be better to used in such and such a case. I don't want to close off this avenue of the discussion by pursuing understanding of other points.

Thanks again all,
-g

HybridScrollFrame
 

Anybody have any experience coding on the HybridScrollFrame? wow programming had a bit, but it was pretty bare. I'm going to hunt down code that actually uses it.

-g

Check out LootManager.lua in Curse Raid Tracker 2.

If you build a frame containing multiple rows, then you're going to have extra work to do figuring out which row the player clicked on.

Usually, the approach is to have one frame == one "thing" == one row. They can be different sizes if you want, but one "thing" per row will save you lots of headaches later. That "thing" might be a single objective, or it might be a collapsible header, but you know it's only one thing.

Not a problem. You can either:

(a) let the contents of row #1 hang off the bottom of the "actual" row and leave rows #2-15 "empty",

or

(b) let the contents of row #1 hang off the bottom of the "actual" row, and fill in rows #2-15 as usual unless you detect that row #9 has another oversized child, in which case you leave rows #9-15 blank, and put what would have been row #9 on row #16. For example, row #1 has a huge button occuping the right 25%, but rows #2-8 only have text in the left 75%, so they don't need to "clear" the button. Row #9 has another button, so you have to skip ahead to the next row that's "clear".

For a more concrete example, the "use" buttons in the default quest tracker are certainly taller than the height of 1 row of text, but they "hang out" of the row they're attached to, and occupy vertical space in adjacent rows without affecting the actual height of any rows. The default quest tracker isn't a scrolling frame of any kind, but the same principles apply. Objects inside a frame (the row) are not limited to remaining inside the boundaries of that frame.

The click handler should only be set on the "use" button -- not the whole row -- and the button should be drawn above the row in strata or level; if you use "natural" parenting techniques (eg. passing the row as the parent when you create the button via CreateFrame) then the latter will happen automatically.

Looking at Hybrid Scroll Frame
 

Thanks everyone for posting in this thread. Lots of good ideas and methods to try.

I'm looking at the HybridScrollFrame that Torhol referenced. I took the lootmaster and stripped it down to bare minimums and have been playing with it. There is a .dynamic feature that helps with positioning variable sized buttons in the scroll frame. I've got it working on fixed sized buttons now and expanding it to do some variable sized ones.

Farmbuyer mentioned clicing on a button that has multiple rows. If the rows were straight text elements you wouldn't be able to tell what was clicked. My reference to rows was for discussing the vertical alignment and how many "rows" of scrollspace that a variable sized button would occupy.

Inside the button I was planning to have other widgets. Every actionable item will be in it's own "button" so that each will have it's own action. Each widget will take up an amount of vertical scrollspace. How they compound will determine the size of the containing button.

From my initial investigations, the HybridScrollFrame with the .dynamic feature give me a relatively straightforward way to handle this.