chadvandy / ui_editor Goto Github PK

main manager: ui_editor_manager or something

• this does all the wrapping, locks everything in place, presents some form of API, etc.
• all the logging and functionality is also within this

then, there's the extant UI class to do the actual physical UI for the mod, as is

then, there will be a "layout_parser" object.

• this will be in charge of taking the raw hexadecimal table provided from reading the table, going through it, and turning it into a single UIC class (the root) with all of the relevant children
• the layout parser is triggered when a new UIC file is being created or decoded, and provides whatever quick functionality is needed therein
• the layout parser will have internal versioning - for the different UIC types, for the different games, etc

then there will be each individual UIC object

• raw UIC, UIC_Template, UIC_State, etc.
• consider making simple fields into a UIC object as well - ie., make a default object that has a few methods that can be used for "uid" or "tooltip_text" or "offsets", or whatever other simple fields. should work for single values as well as tables

figure out inheritance for baseclass to all the chilun classes

from dungeon of toemare:

<LayoutEngine
				type="HorizontalList"
				spacing="0.00,0.00"
				matchfontsizes="false"
				itemsperrow="1"
				sizetocontent="true"
				autocalc_rows="false"
				secondary_margins="0.00,0.00"
				max_length="0"
				allow_overlap="false"
				allow_scale_items_down="false"
				reverse_order="false"
				min_size="0"
				margins="0.00,0.00"
				skew_angle="0"
				equal_spacing_size="0"/>```

• use "name" when available
• use "UI-ID" when available and name isn't
• use the typename+index for things without UI-ID or name (ie. "ComponentMouse1")

re: #34

• should the parser/decipher functions be on the actual classes proper?

the "after" shits from Cpecific's parser, a few small things here and there

ie.

function class:new(...)
    local o = BaseClass:new(...)
    setmetatable(o, self)

    return o
end

ONLY DO THIS CONTAINED SO IT DOESN'T KERPLODE ERRYTHING

start with deciphering the root, then call individual decipher functions (ie parser:decipher_components())

have all the methods that will just be copy-pasta'd into another file

right now, add_data assumes an obj is being passed, with a :get_key() method, then adds a new index to self.data with {key=obj:get_key(),value=obj}. This isn't super hot - it's not a first-class type, for instance, so you can't tell what that {key,value} table is through a loop and what not.

This should probably just be self.data[#self.data+1] = obj, on minimal inspection, and then read obj elsewhere using tostring(obj) to determine the type and what not

ie.
function component:new()
local o = {}
setmetatable(o, self)
o.data = {} ------ <-- VERY IMPORTANT

return o
end

bit of an overhang (fucking hell)

try to completely remove collections? idfk.

• add a new dummy UIC for every single header, that comes right after the header and contains all of the fields within
• whenever the header is clicked, just set that individual dummy visible/invisible

headers are expandable/closer, using the expandable_row_header thingy

• they'll have the text of the name of the section (ie. "Root", "States (3)", "[state name here]")
• each will have an open/close button, and an expand all button to expand every child header of that header

regular text lines are just rows of text with the name of the field ("offset", "width", etc.,) followed by the value. each row of text can have a tooltip, yay

• dummy row for each, set interactive, tt set on this
• two blips of text set on the row, one on the left, one on the right

new only where relevant!

I would really like to not need to edit every single file any time these methods are edited

translate the RGBA values into something that's relatively legible

• "component_images" to "Component Images" with a tt of whatever

Containers are just tables with added methods - they might be a container of states, or a container of images, or a container of Fields.

Containers start with a expandable_row header, and they display the name of the type included as well as the number of those (so it might say Children (4)). They have the data for each contained object within as well. They have the methods for opening/closing the display UI, and they have the methods for displaying the content.

TODO - figure out some good way to do tables like "Offsets" using the container type (or if i even should!)

they're all fields, so - have a :get_uic() method on fields, and a :set_visible() method on fields. when a header is pressed, loop through that object's children and set them visible? have full objects have a :get_uic() and :set_visible() method as well, which closes their header and changes the state and hides all of its children.

so:

• root, when closed, sets every single child header invisible.
• child headers being closed will set every internal field invisible, and close each header (hiding their children)
• cont. all the way down

ie.

function obj:new(o)
    o = o or {}
    setmetatable(o, self)
    self.__index = self

    return o
end