Okay, so I've had a go at Ticket 398 (hiding other bars while casting) and posted my results in the ticket here. Made some progress, and this was much easier than I thought. After seeing all the commits to improve bar handling, I figured now was as good a time as any to see what was involved.
As I state in the comment with the attachment, my own personal desire is to be able to hide other bars while the player is casting. More specifically, I'd like to hide the Power Bar whenever the Cast Bar is being displayed. Because the Cast Bar often stays displayed after a cast (in order to say "Interrupted" or whatever), my current hack sees the Power Bar come back too early. And there's some nuisance misbehaviour I'm noticing when I'm busy in-combat.
Having done zero unitframes programming before, I've made some mistakes and I'm not sure exactly what the finished code should look like. If anyone with more experience wants to take a look and show me what to do, that would be terrific. :)
As far as optimizing goes, with the Power Bar set to "Hide on cast", we now have Power Bars that listen for cast events, which is less optimal than the official code. However, while the bar is now hidden we (hopefully) aren't updating any LuaTexts on it and we aren't redrawing it constantly. If this was done properly, I'm not convinced such behaviour will have a net deficit on performance.
Well, PitBull is responsible for putting the player in party as far as I know. But Blizzard code prevents unitframe addons from being allowed to switch them around. Programming unitframe addons is like trying to win a boxing match with one arm tied behind your back. And a black bag over your head. :P
The only way to preserve the empty places in groups is to actually create a separate PitBull Group for each Raid Group. Then you can arrange them however you like and players won't all spill together into the one bin.
is it possible to make xp only show for my character and not for my pet and target?
Select the Layout that your Player frame is using in the Layout Editor. Make a new Layout (just type it's name in the box and go). The new layout will have copied all the same settings as the first Layout.
Now, go into that new Layout and disable the XP bar.
Go into the Units section, and tell your Pet and Target frames to use the new Layout instead of the old one.
In terms of maximum configurability versus performance, PitBull4 beats everyone hands down. You pretty much have total control over everything, and you don't suffer too much in terms of CPU usage (compared to other addons).
Arena frames are pretty much the only noticably absent feature (not that I personally do any PvP). Once that's in this'll be the unitframes to rule them all. :)
Yeah, I had the exact same problem with those sliders. For months I was manually editting my WTF file with the precise X Y values I wanted. Maybe if that input box has a border or something to make it more obviously user-configurable. But that's an argument for the Ace3 forums, not here. :P
Nice one, Shefki. I would describe myself as a seasoned PitBull4 user, and even I occasionally make this mistake when I'm rushing through settings in-between raid bosses. :)
Another usability concern which we thankfully don't get many questions about now is the ability to toggle frame-snap on and off with a checkbox. The secret "hold shift" feature used to mystify (and preoccupy) many on these forums.
I'm planning on making a really cool and really minimal layout but PitBull4 is currently missing a key ingredient: hiding bars on cast. I've got a wicked idea for a Power bars that turn into Cast bars when the unit is casting, saving tonnes of real estate and looking awesome. Since I don't care about Power at all on my Focus frame, I'd be doing this with the Health bar instead there and in other squishier places. Is this a really complex thing that could go wrong if I try adding it in myself (and submitting a patch)? Or should I just plow on ahead? :)
Zebbik, you've discovered one of the most awesome features in PitBull4.
Basically, each "group" is named however you like. These appear in the "Current Group" drop-down list. You can Enable these individually.
You link each of these to an actual "Unit group" based on what you need to appear. And the "Layout" drop-down is just like for individual units, allowing you to easily select your visual design for that group.
Then you tick the corresponding "Show when in" checkboxes, and make sure each "group" only shows units as per your "Filter type" and "Filter group".
I typically have a single "group" per Raid sub-group. This way I can position each group perfectly and keep sub-groups separate. I actually have once set of "groups" that are only visible in 25-man and 40-man raids. And I have another set of "groups" that are a bit larger and only appear in 10-man raids. And I have one more set of "groups" for my Party and PartyPets and they only appear when I'm in a 5-man, and they are even larger still. So no matter what size raid/party I am in, the same area of my screen is used. It's quite swish. :)
Wow, Shefki, you are indeed the bravest and most patient of all. :P
Anyhow, my ticket of choice would be: 398 Hide bars during cast.
I have an idea for a layout where the cast bar and the power bar occupy the same spot. When the unit is casting, you can see their cast bar. Otherwise, the cast bar goes away and is replaced with the power bar. I just need a magical checkbox to make this happen (and your big juicy magical brain to make the checkboxes happen). :)
This is the one feature I need before I can do my next total UI makeover. Pretty please? /hug /hug /hug
This feature also makes it simpler to conceptually separate multiple functions that some people (read: me) have been lumping together into the LuaText for Cast (relying on return-powered branching).
If you go to the section in PitBull4 where you enable and disable Modules, you can find the LuaTexts module. You can change a few settings specific to that module, including the addition of extra events that you'd like to use.
The code is fine. The only problem is there's just no good way to trigger updates on key presses right now. I mentioned that I'd be thinking about it. I just haven't gotten to it. I'll get to it soon though.
So, MODIFIER_STATE_CHANGED can't simply be added inside the module settings for LuaTexts, and then chosen for that particular Text?
Shefki, I made a comment to this effect against ticket 42, but maybe we could get some of your LuaTexts magic over here. Give us a code box and an events multi-select and we can define our own bar colors based exactly on what we'd like?
Would it be possible to have a general script-environment module that LuaTexts and a hypothetical LuaColors module can depend on? In theory anywhere there's a color we could make use of such customisation (also dispensing with ticket 319 (class/hostility coloring everywhere)). But maybe that's going too far. :P
EDIT: Just had another idea. Maybe we can have a Code menu that is a sibling to the Layouts and Units and Groups sections. We can define all of our LuaTexts (and other LuaBlahs) so we don't have to define exactly the same code snippets everywhere. Maybe this is worth a ticket? Hmmmm.