flixel ui exporter thoughts

gistfile1.txt

Does Haxe-UI use sprite sheets?
Can you nest containers? Widgets within widgets? Or is this a FlxUI object?

I've typically leaned towards runtime instantiation (the "Code test" in the RPG UI demo). In this case I'd read in the JSON and instantiate hax-ui elements according to the naming conventions. 
I might make a go at wiring up a demo of this (I've done a bit of Haxe in the past).

Are you thinking you'd modify the photoshop generator to output layout XML files? 
  You'd need some way to mark up the additional attributes (as you wouldn't want to add these after export as re-exporting would blow away your changes) 
  I think it would make sense to export the metadata from Photoshop that makes sense without jumping through too many hoops and extend your
  layout loader to support "metadata" files. Like, I'm thinking you'd have the PS-generated layout file that gets completely blown away/recreated each time
  and then you'd have a separate myfile_metadata.xml that you hand author and hand update to add supplemental data.



peeking through
https://github.com/HaxeFlixel/flixel-ui

IMPLEMENTATION NOTES
widget			-- i call these containers
	name		-- layer/group name
	x/y			-- yep, is haxe y-up or y-down?
	use_def		-- maybe not needed with machine-generated layouts?
	group		-- not sure i understand what this is for
	visible		-- seems like a runtime property, not a definition property
	active		-- seems like a runtime property, not a definition property
	round		-- not sure i understand what this is for
	
	anchor			-- i usually implment this is a param vs a child node but i have systems for reading/exporting these already
	param			-- trivial to implement (use text layers with a naming schema)
	tooltip			-- trivial to implement (use text layers with a naming schema)
	size tags		-- TODO
	locale			-- not sure i fully understand these, but could probably fake it with a container + text layers OR have a photoshop folder with "replacement" text files if it's mostly text files this is used for and just export the deltas
	
	
definition/default/include
	these seem hard to implement, but maybe not needed for machine-generated layouts? seems like this is for file/org sanity

inject
	is this used for file org or for nested symbols a-la flash? i've typically done this at runtime with placeholder, but the same idea would be really easy just using a different naming tag on a placeholder rect
	
group
	not sure i fully understand the difference between group/widget but I kind of use them interchangeably
	the way I usually implement this is that a group is a container node that can have children whereas a widget is a container node with a predefined set of children
	
	can groups be nested? or do you only allow a single layer hierarchy?
	
align
	TODO
position
	TODO
layout
	i usually handle this at runtime. i'll usually have variant PSDs for each layout (i.e. _ipad_landscape vs _iphone_portrait or whatever) and then just tell my runtime asset importer to always use the layout files with that postfix
	
	not sure how i would support this at export-time... would probably handle this as a separate build script but would need to think about it some more

mode
	this is an interesting approach -- i solve this in a completely different way using tabs and aliases. in my system a tab is a container with multiple states that just turns whole state trees on/off when you set a state. i'll typically just duplicate the assets across states as needed and give them the same names using an alias prefix. so if 2 different states have "play_icon" the subsequent ones will be called "alias_play_icon" and just use the same underlying asset. this is a bit more expensive in that all the states have to be "loaded" into the display tree but I doubt that's the bottleneck.
	
change
	could support this at export time using a change_prefix and processing these last (and computing deltas)

	
WIDGETS
	image				-- default for any image layer
		color? not sure
		group? not sure
		smooth? not sure
		resize_ratio?
		resize_point?	--i currently support setting pivots, could probably "force" pivots into specific named edges
		
		
	9slice				-- scale9_
		tile? not sure
		
	region				-- placeholder_
	button				-- btn_
		text_x/text_y	-- i just have text layers as a child component for things like this
		label			-- in my usual system this would be a property of the child textfield. what's the difference between this and child text nodes?
		code? not sure
		resize attr? not sure
		params? not sure
		
	button_toggle		-- i usally implement these as a tab group with buttons inside for each state
	checkbox			-- haven't used, but should be easy
	text				-- default for any text layer
		border attributes? not sure
		context? not sure
		code? not sure
		
	text_input			-- haven't used, but should be easy -- i.e. "input_textfieldname" instead of "textfieldname"
		password_mode	-- would probably just be an alias -- i.e. "password_textfieldname" instead of "input_textfieldname"
		force_case? not sure
		filter? not sure
		context? not sure
		code? not sure
		
	radio_group			-- haven't used, but should be easy
	tabbed_menu			-- i imagine our definitions of a "tab" are quite different but I have a way i currently do tabs
	line				-- would just be a sprite in my system
	numeric_stepper		-- not sure what this means
	dropdown			-- i think this would be straightforward
	tilegrid			-- i've implemented this in the past but not in my "default" set of definitions usually
	
	
Most of the Alignment/Localization stuff looks hard to implement at export time.	
	

One approach I might have -- a solution to the "keep metadata / definitions / etc that are hard to express in photoshop", but without having to hand code them in to a generated file and worry about them getting blown away on each export.

You have two files. master_ui.xml and generated_ui.xml.
The former contains all the definitions, metadata, etc, all the stuff that's awkward to do via a Photoshop layout. Then it has an inject tag that references the generated_ui.xml, which is copy-pasted directly at a specific location inside of it. Then the only stuff in generated_ui.xml is layout stuff that's natural & appropriate for the Photoshop system to use.

Hand written stuff goes in the hand written file, generated stuff goes in the generated file. Game loads the master file, it pops in the generated file, loads the whole shebang. Export to one's heart content to the generated file and never kill the hand written stuff.

Any issues with that approach?