XML Design View showing only default layouts?

Dec 17, 2007 at 12:33 PM
Many objects don't display as in game: <Button name="Button1" inherits="UIPanelScrollUpButtonTemplate" text="Button1">
Displays as the default red rectangular button with yellow text in design view. In game: small square button with up-arrow texture.

Also frames with other than default edge or border files still display with default background and border. Frame properties don't allow changing these.

Design view doesn't seem to reflect XML code changes. For example changing the frame size by editing the xml instead of the frame's properties won't update the design view. Reloading the project or reopening the tab fixes this.
Dec 17, 2007 at 6:14 PM
Edited Dec 17, 2007 at 6:20 PM
The XML design view needs some heavy work at this point. In fact, the design view shouldn't be tied to XML at all. There are quite a few mod authors (me included) who don't use XML for our UI, but create it in our code instead.
Dec 17, 2007 at 6:21 PM
Tyran, unfortunately we do not have support for 'backdrops' in the visual designer yet so the design view won't reflect the artwork from the XML (may that be reusing WoW artwork or your own). We did use the default 'dialog box' frame backdrop to achieve a more WoW look and feel but of course, this is something that your frame should inherit from one of the WoW frame templates and the backdrop should show accordingly. This is a major feature that is on the top of list of new features that should be in subsequent releases. It requires extracting the WoW artwork and either converting those to a format that the .NET framework can work with or adding support for BPL. Apart from the visual part, do you have any suggestions on other parts of the FrameXML designer, such as anchoring, how virtual frames and other UI elements can be edited, etc?

Tegan, the Frame XML designer could generate Lua that creates the UI much like C# and the Windows Forms designer does it. Do you think this is something that most mod authors do? Do you also extensively use Ace2? What is the main reason not to have the UI declaratively in FrameXML and code the behavior in Lua only?
Dec 17, 2007 at 6:50 PM
I do extensively use Ace2. A LOT of Ace2 mods do this, so it would be nice to have the option for the designer to dump to a Lua file or an XML file. It's not a high priority mind you, as I write my UI's by hand and will continue to. But the option would be nice.

The main reason for doing it in script is "create on demand". I don't have to create UI elements (and use memory) I am never going to use. FrameXML UI elements are created when the AddOn is loaded, regardless of usage. It's especially useful if your UI is dynamic. For instance, in my current AddOn, the user can load and use the AddOn without ever looking at the setup screen, so why load the setup screen in to memory until they actually go to use it?

I think most of us who write our UI's this way aren't going to make heavy use of the designer to begin with, so I think leaving it XML for now is perfectly fine. There are far more pressing issues I would like to see fixed before this gets worked on ;)
Dec 17, 2007 at 9:20 PM
Fair enough! :) AddOn Studio needs to improve in the Ace2 field to be useful to the Ace2 audience (being advanced wow modders). Just give the project a shot and don't rip it apart already :)
Dec 17, 2007 at 10:57 PM
I am not tearing it apart, I am using it! I've made it my primary development platform. I am a "Visual Studio" guy. I am just pointing out that the XML designer has a ways to go before it's useful to the more advanced modders, especially ones you who use create their UI's via Lua.

I've also downloaded the source and have started to poke around. I think I can help with making it a little more Ace friendly (when it builds on Vista x64 that is ;) ).
Dec 18, 2007 at 1:13 PM
Edited Dec 18, 2007 at 1:15 PM
I will certainly keep using it over notepad just for the coding at least ;)
The main reason to use lua instead of XML is to create dynamic UI's: A configuration menu could be created based on the loaded modules for that addon.
Generating a GUI based on the addon's configuration options (slider for a value range, checkbox for boolean, editbox for string and so on) is a common use as well.
Also only creating parts of the UI when they are going to be used (instead of loading them all and hiding them until the user needs them) saves some memory usage especially with custom textures ;)

It would be nice if we could use the design view to design the base components of a dynamic UI, such as: what the tabs in my UI will look like (backdrop, border, size), the appearance of the editbox (font, background, border), and so on.
Then if the output of the XML designer was a lua function that created such a component (which takes as arguments its parent, anchors, offsets, etc), rather than a static XML file, it would be much more useful already.

For me the most painful part of creating addons is definitely the visual design. Having to reload the game's interface every time to see the result of a small change really slows things down. In its current form the design view doesn't really help with this because it doesn't reflect in-game display. I'm already looking forward to the release that will support more than the default artwork!

Other things I came across so far:
-Some way to indicate whether a frame has been hidden or not would be nice (rather than scrolling through its properties to find out). I guess this is part of the visual part that needs updating as well.
-Hiding a frame should hide its children as well.
-I couldn't find any easy way to parent a frame to another, other than typing its name in the parent property. A dropdown box here would help.

Other than that it has been quite user friendly and easy to understand so far, nice work ;)
Dec 20, 2007 at 5:40 AM
Hey folks,

Just to close on this, I've added items into Issue Tracker for these new feature requests: