Talk:Plan for an Editor Editor

From OHRRPGCE-Wiki
Jump to: navigation, search

What is the plan for an Editor Editor Editor? Will the OHRRPGCE eventually transcend all being? --Moogle1 21:27, 17 September 2008 (UTC)

Myroc: I thought i'd never hear a thing such as this :/

Bob the Hamster: There is a saying that there is no programming problem that can't be solved by adding an extra layer of abstraction :)

Rewrite[edit]

The Mad Cacti: Yes! I totally hated the old plan, though I forgot to say so. This is much much better. Things like the picture widget will be very nice. It needs some widget containers for optional widgets, conditional on the values of other widgets. And for non-selectable menu items. And "int" needs value->text mappings.

I've also been thinking about how to apply this kind of editor editor to non-Reload lumps. I started sketching out a format for describing non-Reload lumps, in order to emulate a Reload interface. However we probably would just replace the lump with a reload one if we were rewriting the menu...

NeoTA: I've been doing some stuff on arbitrarily-detailed data specifications and code generation in nohrio. value->text mappings are, of course, enums, and tools/lumpdefs.yaml includes several enum definitions. So far I've found that expansion is needed on both the LHS (number/expression) and RHS (resultant text), to emulate current editing screens. James' rewrite inspired the current structuring.

However, it may be possible to make the LHS not need expansion in all allowed cases by making each record map a range, rather than a value, to a displayed string. For nohrio I'm opting to expand both ends of the range AND the RHS

Bob the Hamster: yes, I do plan enums... in fact I'll add them shortly. Doing conditional optionals as a container widget is a great idea. I knew we needed conditionally optional stuff, but I wasn't sure how to express it. NeoTA: I am confused about this LHS and RHS stuff. Can you explain more?


NeoTA: LHS == Left hand side, RHS == Right hand side. really they are the same as the lvalue/rvalue distinction. In the case of enums, the LHS/lvalue is the number or range that maps to some string; the RHS/rvalue is the string.