Authors CurseForge

In the default blizzard options window there is just enough room for 2 options side by side like in your first example, this will not work however if they are contained in any sort of group container as the borders take up a little bit of room.

I've tested MainAssist on the beta now, and at least for custom assists it seems to keep working without changes. I haven't been able to test in a raid or with ctra tanks but there doesn't seem to have been any breaking changes to the headers that would stop them from working.

I am planning to update this for WotLK, I haven't actually tested it in the beta yet but I know its going to be broken since the secure header stuff has all changed completely.

I haven't had a chance to play around with the new secure template stuff but from what I have seen it should make things easier than the ugly header stuff that it uses currently.

Quote from HunterZ »

Any chance of an Ace3 port happening? I'm thinking of rebuilding my UI from scratch when 3.0.2 goes live, and ditching as many Ace2 and Rock addons as possible.

The rewrite I mentioned would basically be the Ace3 port. The mod relys too heavily on waterfall (which isn't portable to libstub due to heavy use of AceOO) for config and rewriting that for AceGUI is a big enough task that I want to rewrite other parts at the same time. The mod would still require some Ace2 libs because of this so gains would be minimal.

If its bug fixes and not new features then feel free to commit them as long as they are well tested. The reason there hasn't been much active development for a while is that the mod does pretty much everything I personally use a bag mod for and I don't want to keep adding every feature that's suggested and bloat the mod too much. Things that I would appreciate help with especially are problems with missing Item Types etc.

I do have plans for a rewrite sometime, I've just not been able to find the time to get moving on it.

I've been using the mod on beta without issues, you may need to use the WotLK Ace2 branch with it to get it working but I haven't run into any major bugs yet.

tabGroup.frame:SetPoint(...) is correct

Normally the layout function of the tabgroups parent container widget would be doing this, but as you are taking the widget and placing it in your own frame you need to position it.


edit: One of the cleanups I'm going to do before RC1 is to find these cases where you need to dig into the widget and provide methods on the widget that allow you to do the same thing, in this case provide a :SetPoint method in all widgets that is passed onto the .frame member

Are you using the WotLK branch? I'm pretty sure tabs were one of the things that have been fixed.

Quote from Friikki »

Edit: would also be nice if I could for example ctrl+right click a stack to automatically split the stack into 1 piece stacks. Or maybe each click would make a new stack of size 1.

There is an option on the alt-right click menu to do this

If you set the layout anchor to bottom left, then use the layout bounds and auto layout to place the bag it should grow up and to the right from that position. Its not ideal if you want to be able to move the bag easily at the same time but it should work.

The AceGUI-3.0 Scrollframe is just a wrapper around the built in Scrollframe api to make it fit in with the rest of the framework. A Scrollframe will property clip its contents when you scroll, and there are blizzard templates that will help with the scrollbar etc aspect of it.

The way to do this (if the tree doesn't work out) would be to register a custom layout and use that.
They are designed to be added to the same as widgets, the 3 that come with AceGUI are just the base ones I needed for AceConfigDialog.
Heres a drycoded example (basically a copy of the "fill" layout with a few tweaks)

--anchor the first 2 controls to have full height and 1/2 the width each
--Make the name unique to avoid clashes if another addon has a slightly different idea of what a 'Split' layout is
AceGUI:RegisterLayout("AddonName_Split",
 function(content, children)
  local width = content.width or content:GetWidth() or 0
  local height = content.height or content:GetHeight() or 0
  local controlWidth = width/2
  if children[1] and children[2] then
   children[1]:SetWidth(controlWidth)
   children[1]:SetHeight(height)
   children[1].frame:SetPoint("TOPLEFT",content,"TOPLEFT")
   children[1].frame:SetPoint("BOTTOMLEFT",content,"BOTTOMLEFT")
   children[1].frame:Show()

   children[2]:SetWidth(controlWidth)
   children[2]:SetHeight(height)
   children[2].frame:SetPoint("TOPLEFT",children[1],"TOPRIGHT")
   children[2].frame:SetPoint("BOTTOMLEFT",children[1],"BOTTOMRIGHT")
   children[2].frame:SetPoint("TOPRIGHT",content,"TOPRIGHT")
   children[2].frame:SetPoint("BOTTOMRIGHT",content,"BOTTOMRIGHT")
   children[2].frame:Show()
   safecall( content.obj.LayoutFinished, content.obj, nil, children[1].frame:GetHeight() )
  end
 end
)

It is possible to do roughly what you are after, although not quite as automatically as you seem to want. There is nothing stopping you creating a generic table of options for the spells and then reusing it for every one.

Also, AceConfigCmd and AceConfigDialog both run off the same options tables. They map to each other in the same way that Dewdrop and AceConsole-2.0 do.

AceConfig-3.0 example:

local spellOptions = {
 type = 'group',
 name = function(info) return [[Some Name Based On Info, info[#info] will be 'somespell' etc]] end,
 ...
 args = {
  someoption = {
   name = 'Some Option',
   type = 'input',
   get = function(info) ... -- info[#info-1] will be 'somespell' etc end,
   ...
  }
  
  ...
 }
}

local options = {
 type='group',
 ...
 args = {
  group1 = {
    type = 'group',
    name = 'Some Spells',
    args = {},
    ...
  },
  group2 = {
    type = 'group',
    name = 'Some Other Spells',
    args = {},
    ...
  }
 }
}
-- Only a single instance of the spellOptions table is created, 
-- and reused for all similar options. 
-- Add or remove these entrys as much as you need to.
options.args.group1.args.somespell = spellOptions -- 'somespell' will be available in the info table
options.args.group1.args.someotherspell = spellOptions
options.args.group2.args.somegroup2spell = spellOptions

Quote from Borlox »

Of forgot that. self.type must be changed to LSM30_Fonts_Item_Select or whatever the widget is changed to. The recycling should be no problem.

This is correct, and is how I was expecting extending widgets to work. Grab a copy of the base, change its type, make the changes you need to it and everything should work as if its a completely seperate widget type.

Looks good. One note is that you have the Dropdown-Pullout widget in that pastey. If this is unmodified from the one included with AceGUI then it shouldn't be included, and if it is modified it should have a different name.

You shouldn't be changing the components of widgets, they are designed to be recycled and unless you never release them you will not be the only user of the widget.
If you want things that aren't provided by the widgets by default your best bet is to create a custom widget and use that.