Authors CurseForge

Its a bit hacky, but you can get something resembling localized names for types and subtypes using a combination of GetAuctionItemClasses and GetAuctionItemSubClasses.

A vehicle watch is the best thing, most likely.

[target=vehicle,exists]

I use that for switching my unit frames unit in Sage/to control the vehicle control bar for Dominos, and it works. Party members in a vehicle, I cannot do.

Combuctor's inventory frame's filters are setup so that the all tab contains tabs separated by bag type: normal, trade bags (engineering, mining, etc), ammo bags (hunter only), shard bags (warlock only), and the keyring.

Under default settings, I do not include the all tab, which displays all slots at once. You can enable it via the filters menu (/combuctor)

Quote from Phanx

Lua gets that too. ;)

But you need to use XML for those templates :P

XML was slower/used more memory in the past. Its faster now. It also does not need to be as verbose as blizzard tends to write it

This code:

<FontString name="$parentHotKey" inherits="NumberFontNormalSmallGray" justifyH="RIGHT">
	<Size>
		<AbsDimension x="36" y="10"/>
	</Size>
	<Anchors>
		<Anchor point="TOPLEFT">
			<Offset>
				<AbsDimension x="-2" y="-2"/>
			</Offset>
		</Anchor>
	</Anchors>
</FontString>

Can become:

<FontString name="$parentHotKey" inherits="NumberFontNormalSmallGray" justifyH="RIGHT">
	<Size x="36" y="10"/>
	<Anchors>
		<Anchor point="TOPLEFT">
			<Offset x="-2" y="-2"/>
		</Anchor>
	</Anchors>
</FontString>

For example.


You also get that sexy "inherit multiple templates" thing, too.

Combuctor is not designed to sort, only to filter.

To me, that almost means, "screw writing a new API"

But then I think about how the current one isn't really setup for multiple locales, and then I cry :P

Also, Combuctor development will probably go quiet for a while. I have Sage to code, Wrath to play :P

Nope, but I think bartender can do it now.

Here's a rough idea of my thoughts about how the new set api will look like:

--constructor
set = CSet:New{
    id = 'string', --must be unique for each set, attempt to add a new set with the same id should throw an error
    parent = id, --id reference of parent set
    text = 'string', --localized name of set
    icon = 'path\\to\\icon',
    rule = function
}

--destructor
--removes set, and all of its children (probably call child:Free() for each child set)
--should trigger a set removed (id, parentid) callback
set:Free() --removes set, and all of its children.  Remove children before set and call 

id = set:GetID()
id = set:GetParentID()

--should trigger a set update (id, parent) callback
set:Update()

--should trigger a set update item (id, parent, icon) callback
set:SetIcon(iconPath)

path = set:GetIcon()

--should trigger a set update rule (id, parent, rule) callback
set:SetRule(rule)

function = set:GetRule()

--should trigger a set update text (id, parent, text) callback
set:SetText(text)

string = set:GetText()

--Combuctor sets act on inventory slots, which may or may not contain items
true | false = set:Has(...)

--an iterator on the set's children, if any
for i, set in set:GetChildren() do
   print(set:GetText())
end

set = CSet:Get('id)
 
--an iterator on all top level sets
for i, set in CSet:GetParentSets() do
     print(set:GetText())
end

I think the real trick will be for me to try and make item rack set rules, and see if I can do so in this structure or not. I'm also thinking about how to merge a bit more of the backend code between Combuctor and Bagnon.

The battle of me as a designer is what I actually need versus what I think would be interesting to have. Bongos3 swung me in the "interesting to implement direction" and Dominos swung back. Either way "crazy town" features are things I don't expect to implement.

As far as what I do next, its either Bagnon or Sage. Dominos has a high chance of staying at 1.8.x for a good while, but might hit 1.9.x if I make a possess bar decision.

1.8.0 is out. The major change in this version is that I've introduced a new layer that allows Dominos to seamlessly interact with both the stock blizzard and click bindings.

I'm still deciding what to do about the possess bar, and if I want to add in a separate option or not. I have a few options:

• Make the pet bar the possess bar. The pro here is that I'll be able to reuse the pet bar bindings. The con, and its a big one, is that I'm going to have to make my own pet bar instead of reusing the Blizzard one. That goes against my goal of making Dominos reuse as much code from the stock interface as possible.
• Make a separate possess bar. The pro: I get to implement those nifty extra possess buttons. The con: The need for separate bindings.
• Completely ignore this issue. I don't want to do this, since I still sort of want to support people with a variable number of bars.

Also, I have a todo list of sorts here: here. If there's anything I'm missing that I've said I'd look into, please tell me. Crazy town == probably won't do. Super crazy town extreme edition == almost definitely won't do.

A secure modal layout system means:
* [form:1] -> Dominos layout;
* [modifier:alt] -> another layout;
* [group] -> yet another layout

Its the secure header stuff taken to the complete (and probably still impossible) extreme. I'll probably research it at some point in the future, but that would be yet another bar addon :P

Blizzard designed their interface around the 12 buttons design, so things tend to work well if you stick to the old 10 bars of 12 buttons each thing. That's the big reason that the /dom numbars and numbuttons commands are slash only, as well as a major reason why I discontinued Bongos3. Its also the reason Bartender4 makes no attempt at supporting variable bar layouts.

I think I can solve your specific problem via making a Dominos_Possess addon, (aka a separate possess bar), but am debating if I should do so or not.

Yep. I'm not really sure that the possess bar can be set to the pet bar anymore.

That's not a bug. Those 1,2,3...= bindings are the stock blizzard ones, not click bindings. Dominos does not remove the stock blizzard bindings, you need to go into the blizzard bindings menu to remove them. Alternatively, you can bind 1 to a bar, then remove it via Dominos.