chadvandy / twuieditor Goto Github PK

Attributes, Elements, Properties, all mean the same thing in a bunch of different contexts. DAMN.

• Allow multiple files to be opened at once, several tabs
• Display name of opened Twui file on tab

Expected properties and elements are the big change between versions, as well as the anticipated name of each.
I can potentially use attributes, keep them all to the same class structure and just add in attributes for [Version(Start,End)] or [Version(Start)].
It would be nice to not have them be built directly into code, but I'm not sure the best way to handle that structure. Making them clear code data files isn't a big issue, as long as there is support for "anonymous/unknown" types during the decoding process.

Read the Twui file on open and parse it for the file version, the hierarchy, and then the components and their internal fields

• Version
• "Root" component
• Children, by name
• Hierarchy
• Other internal fields, just hold in an array for now?

add topbar menu and status bar and other vitals to the ShellView as is
move "main" commands into ShellViewModel
ScreenCollection in Shell, for dockable windows

Not a big issue for now, but may scale very poorly through time

• MainWindow
• MenuBar
• StatusBar
• CentralView

Handle them with attributes that have a "Name", a "Type", an "Input"(?), and a "Version".

Interrogate each element's internal properties to get all of the ones that are valid for the currently loaded Version, and try to find the Name in the XElement as an XAttribute, pull in the value as the type specified to the field here.

Each component "attribute" just needs to have a name and a value, with the value of variable type defined by the C# Attribute.

TwuiContentsViewModel - master handler to hold all of the currently opened twui files, the tabs, the XML view, the properties, the hierarchy, etc.

• Show hierarchy in single text block to start, with no good support

ie., allow the PropertiesPanel to take the state info of "currently-selected component" from multiple sources

A parser that will just hold a collection of subelements or a collection of attributes, or both, if we don't know what type the current parsed XML element is

https://stackoverflow.com/questions/4101784/calling-a-generic-method-with-a-dynamic-type

Scrollable list of the attributes underneath a collapsible header category, with support to go down into subelements.
IE., highlight a component, see its id, offset, docking position, etc., and have a collapsible header to go into its states, images, etc.

Support for editing based on the types of each attribute - docking is a series of buttons, offset is an x/y coord, priority is an unsigned int, etc.
Support for "reference" GUIDs - clicking on "currentstate" GUID will let you scroll immediately to that state.

https://github.com/Carlos487/awesome-wpf

UI library: https://github.com/Kinnara/ModernWpf
FontAwesome

PrismLibrary for framework / DI / etc. https://github.com/PrismLibrary/Prism
CaliburnMicro? https://github.com/Caliburn-Micro/Caliburn.Micro

https://github.com/Federerer/Notifications.Wpf

IF it's not a complete pain in the ass.

May require some simple conversion; maybe it's actually an XML file but stripped of the extension; maybe it's going to require a lot of hard work to move over and is just not worth it, at which point I'll just not do it

Project - Entry
-> App.xaml
-> Other main resources

Views

ViewModels

Models

Utilities

Schema[s]

Should they change automatically, as things are changed in the properties? Or should there be an "apply changes" button?

Latter would allow some verification, which will help out quite a lot.

https://github.com/fluentribbon/Fluent.Ribbon

open files, get file dialog, hold pointers to files, save and create files, etc.

Top of listview should have a nice header informing the user what exact component and element we're looking at (ie., we're looking at the root, and we're in its "newstate" state.)

Collapsible headers for subelements

Should they be held in a single field, like the "Properties" list? Or should they be specific fields for each element?

How to handle the "list" vs "instance" elements?
IE., -> list of individual states, -> singular element w/ attributes.

How should the C# Attribute be setup?

TwuiElementAttribute(Name, DataModelType, bIsList, bRequired, uintVersionAdded, uintVersionRemoved)

Work out a dock manager system to handle various Visual Studio esque micro-windows

• View -> on menu bar
• HierarchyPanel
• PropertiesPanel
• DesignerPanel (view finalized UI)
• FileContentsPanel (XML view, optionally read-only)

• Route command from MenuBar
• Open up a file dialog
• Filter for only twui.xml
• Class in background to handle the pointer to that file's location, any loaded details, any changes, etc
• Display XML contents in one section
• Display hierarchy treeview on one side
• Display properties of selected element in hierarchy on another

File -> Open Twui

Display XML contents in one tab
Display the treeview of the TWUI in a side view
Display properties of each element, based on treeview selection, in another side view

• "Details"/"Properties" view panel, based on currently selected component
• Show the list of fields and their values