The issue is that editor derives the GUI representation by an XML mapping. The triggers.xml is parsed and from that, the GUI version of the map is generated. So you would have to hand craft such an XML file and that would be amazingly painful to do. There is an xml entity/entry for everything. And I do mean everything. Every function has an entry, and then it has elements that refer to other entries, one for every parameter. So if I even the simple code of
functionfun(inta,intb){returna+b;}
It would be transformed into roughly this
<Elementid ="fun"><Function/><!-- this flags this as a function, as opposed to an action or event or condition --><Parameterid ="a"def ="XMLDefinitionofAnIntHere"/><Parameterid ="b"def ="XMLDefinitionofAnIntHere"/><Functionid ="return"def ="XMLDefintionOfReturnFunctionHere"/><!-- Insert any flags on this function here --></Function><!-- Note, this is for the parameter to the Return function call, Its Function definition is defined somewhere in the Built in Library XML --><Elementid ='a'><Type="Integer"/></Element><Elementid ='b'><Type="Integer"/></Element>
This just goes downhill from here, because if you use any presets, it will cause it to see the parameters as type preset, then point to the element. The element will be of type Preset, and have a reference to the definition of that preset. I actually left that out, there is one in this code, the '+' symbol is a preset, which just macros in the literal '+' symbol.
Anything you can click on in the GUI, has a representation in the Triggers.XML. It's a lot.
Now, could someone write a tool to examine arbitrary source code and generate this XML? Yes, but it would be a daunting task, since it is basically a form of compilation. Mostly daunting in the time it would take and test. And it would capture none of the built in macros that are used by GUI in generating galaxy script (GUI never actually uses return, it uses #RETURN, which means the return statement is only added into the galaxy code if there is something to return, so putting a Return in GUI, but not any parameter, won't cause compilation failure).
Is it possible to convert my map which is currently in pure Galaxy code format, into the GUI trigger style I like more?
New to the Editor? Need a tutorial? Click Here
Want data assets? Click Here
@fishy77: Go
Possible? Yes. Easily? No. Painfully? Yes.
The issue is that editor derives the GUI representation by an XML mapping. The triggers.xml is parsed and from that, the GUI version of the map is generated. So you would have to hand craft such an XML file and that would be amazingly painful to do. There is an xml entity/entry for everything. And I do mean everything. Every function has an entry, and then it has elements that refer to other entries, one for every parameter. So if I even the simple code of
It would be transformed into roughly this
This just goes downhill from here, because if you use any presets, it will cause it to see the parameters as type preset, then point to the element. The element will be of type Preset, and have a reference to the definition of that preset. I actually left that out, there is one in this code, the '+' symbol is a preset, which just macros in the literal '+' symbol.
Anything you can click on in the GUI, has a representation in the Triggers.XML. It's a lot.
Now, could someone write a tool to examine arbitrary source code and generate this XML? Yes, but it would be a daunting task, since it is basically a form of compilation. Mostly daunting in the time it would take and test. And it would capture none of the built in macros that are used by GUI in generating galaxy script (GUI never actually uses return, it uses #RETURN, which means the return statement is only added into the galaxy code if there is something to return, so putting a Return in GUI, but not any parameter, won't cause compilation failure).