will Grid not Grid2 still be available, giving us choice to use what we want ?
Of course, also since they are separate projects you can run both at once. If Grid2 does take off and in fact replace Grid for most users, then over time the original Grid may get less maintenance and eventually not make it through a new Blizzard patch. The reverse can happen as well to Grid2 if it does not get to a releasable stage.
Is there any timeframe for the release version of Grid2? The version on Curse is from 2008 and still labeled "alpha software not meant for end users at this time".
No. As with pretty much any software that isn't produced specifically for a deadline, Grid2 will be done when it's done. Grid2 is still "not meant for end users at this time"; I'm sure when a developer feels it is ready for general use by non-testers, he will push a release and make an announcement. Until then, Grid remains fully functional and actively maintained. Use it.
Thanks for the information. I'll be sure to check Grid2 out when it is finished. Meanwhile, I'm dropping Grid for another raid frame with similar functionality, but much easier to configure. I'm not waiting for Grid2 any longer.
...The + and - buttons for adjusting status priorities on an indicator frequently move statuses up or down by 2 or 3 slots instead of just one.
Under the covers statuses are still given "priority" values of 1-99 (or more) and sometimes multiple ones have the same value. 99 is quite popular for example. Moving a status through a chunk of these thus takes multiple clicks or has other non obvious behavior at the end points. This is not acceptable and needs fixing at some point.
I need to decide if there is value in exposing this priority value, or to do something different. The current ui postpones the decision.
Keeping the value allows for a well crafted scheme of them where plugins can have their statuses interleave appropriately with existing statuses on an indicator. Similarly a category could allow its individual statuses to have their priority specified. It is kind of hacky though, even though it is the existing scheme in Grid as well.
Perhaps a better approach is to just have a simple sequence for each indicator. Insertion points can then be specified as first, last, or relative to a known status already on the indicator, perhaps even relative to categories of the indicator (if present). This would simplify the UI more I think and hide some or all of the complexity inside plugin code.
*Enforcing uniqueness of values for the priority scheme could make it behave properly at the cost of losing the value of the priorities given enough plugins and moving around of statuses.
*In Grid2 priorities are something the indicator knows about its statuses. In Grid they were something each status had individually.
*Should a category behave as a chunk and move together (needing more ui elaboration), or just be a mechanism to turn a batch of statuses on or off after which they are individually moved.
*category itself needs pretty much identical ui to manipulate its indicators
*exposing the number adds more items per line to a MagicMarker type ui and the aesthetics of that becomes unacceptable with too many items.
*exposing the number adds a field that can be tabbed through for editing which can be nice.
*Since everything is not hooked up yet there may be future chunks of the ui affected by this although I can not think of any at the moment.
At this point I'd say keeping the status-level priority is not worthwhile. The dream of having plugins be able to intelligently insert statuses at a particular priority is a noble one, but it's not very practical to have a priority for the status in general, and a priority for the status on each indicator it's shown on, from the user configuration standpoint.
Will it be possible to add two instances of a particular buff, with one filtered on "mine" and one filtered on "not mine"?
Meanwhile, back at the ranch, lassie added duration timers to text indicators to match what you can get with icons +/- OmniCC. The overhead should not be too burdensome + I may split out the duration parts into a timer indicator in the future. It would save a few if statements and some property dereferences + code size. More importantly it would shrink down the list of statuses compatible with text again.
The druid config is altered to display these for lifebloom, regrowth, rejuv.
One day I will clone that dog and double my productivity.
I think the major missing things at this point are:
*guids. The code got split b4 the guid branch. doh.
*fix the heals-incoming not always showing thing
*per character (/spec) settings.
*finish presets for the non healing specs / classes + some kind of raid leader thing
*StatusRes (im working on that)
*Misc plugins for AFK, party settings, raid icons, PvP statuses.
*Morphing code text - icon - square, maybe from a popup.
Any chance of fixing the texture issue?
I still haven't found conclusive reproduction methods. It still seems random.
Also at times I have about 10 textures show up in heals - and the standard 3 in health. (same session, no /rl or anything.)
(Texture issue being: hpbar all black, hover over highlight shows missing health. Changing textures often fixes it for the remainder of the session until a /rl. self-frame goes all black when I target someone/mob/self.)