Variable Interface

[chris]

I started work on a variable editor for lua. Right now it isn't working on recursing through nested tables (such as:

tableTest = {blue=8,yellow=9, {apple=9, pear=8}} and so on.

I pushed these changes into my github repository under the files 'luaInterface'. There is a new ui as well for editing/adding variables. Anyone who knows a lot more about lua stacks care to take a look at these two files? Use the src.pro.new file when you compile to include the extra ui/luaInterface. Anyone who knows more about lua stacks in C care to look? The lines which are commented out at 57-60 are the real issue here, enabling these crashes mudlet on profile loads.

I envision the table interface as being exactly like our folder hierarchy for triggers/aliases/etc.

The new files you need to have to get this functionality:
luaInterface(source/header)
dlgTriggerEditor.cpp.new
dlgTriggerEditor.h.new
trigger_editor.ui.new
vars_main_area.ui
src.pro.new

[Vadi]

Don't have time to test at the moment, but remember to account for cyclical references when you add tables.

[Heiko]

This has indeed been a popular request by a few die hard GUI fans, but this is a lot of work as you need to make sure that the entire thing is completely performance neutral, which basically means that you have to update the respective variable tree every time the user wants to take a look at a variable that might no longer exist.

However, I'm strongly against auto loading and saving global variables if it intertwines static profile data with changing variable data. I'd be OK with an independent variable session storange system that loads and saves variable snapshots and loads a given session on request.

[chris]

It's definitely not high on my to-do list, but most of the non-table functionality is there. It's something that would have little purpose for me, but I think for new users it is can be a nice stepping stone to scripting.

Performance wise, it's fairly neutral. If variables are added from a script during the run, they won't be reflected (that would require a new TVar class or something similar to track updates/deletions); however updates to a variable will be reflected as that will be populated on the fly.

For the saving, I would make the checkbox indicate whether the variable is saved or not to allow a user specified snapshot as saving/loading profile globals is a terrible idea. One issue is that since lua has a single global variable space per profile we end up with a lot of pollution from imports. A solution is to record everything loaded prior to the profile data and make an exclusion list. I'll cross that bridge when I get there though. This is a fairly low priority at the moment

[Vadi]

Okay, did testing. The interface reads the VM state flawlessly, so these tests are mostly for the changes some in the GUI to be reflected in the VM properly.

adding a new global string/number
works

modifying a global string/number
works

deleting a global string/number
works

adding a new global table

modifying a global table
not quite

test1)
create mudlet = { hi = { whoa = {}}}
in gui, drag 'whoa' into 'mudlet', so it's a sibling of 'hi'
save either whoa or mudlet, both should work
observe that the original structure is still in the VM

test2)
create mudlet = { hi = { whoa = {}}}
in gui, drag 'whoa' into 'mudlet', so it's a sibling of 'hi'
delete 'hi', so you're left with mudlet = {whoa = {}}
save
observe that in the vm, mudlet table is now empty

deleting a global table
works

deleting inside tables
works

Some suggestions
- Since the variable list isn't user-sortable, sort it alphabetically by default to help reading it
- Initial display performance still needs to be improved, and/or threaded, if possible
- Hook the search up for variables

[chris]

The drag and drop aspects have not been looked at. Asides from these cases, can you find any examples where modifying the global table via a script, the add item/group, or delete item/group fail? (there is one case I know of where if a table entry is added/deleted in a script while the interface is open it won't be reflected until 'show vars' is clicked again. However, the need to see accurately table which is updated so frequently that the interface fails to catch it might not be important (such as a table listing the mobs in a room)). Since this is a gui, the drag and drop are important and I'll throw them on the list.

When did you last test the display performance? I added two tweak yesterday to speed it up: batch additions, and disabling the updates until all additions are complete. I think some speed benchmarks are needed now to see what should be focused on rather than guessing where the bottleneck might be. I added three timers to the debug and removed the old debug messages (so fetch again). Can you post your speeds for a large profile here?

I'll check on threading too, with toggling the redrawing of the interface I don't have to worry about people selecting non-existent variables anymore.

[Omni]

Anyone mind posting a screenshot of how it looks? Still no laptop, and a complete dunce at compiling, but would like to see what it looks like.

[Vadi]

88 to take care to main loop
193 to take care of tables
162 to take care of tables2
21 to take care to main loop
131 to take care of tables
161 to take care of tables2


30 to take care to main loop
173 to take care of tables
168 to take care of tables2
22 to take care to main loop
133 to take care of tables
161 to take care of tables2

Seem to be the numbers. To be honest, I did test right after the batch changes, but it is quicker now - I think it was actually the debug echoes that were slowing it down most.

[Omni]

I pictured it differently.
Would it be possible to hide a variable from the display?

[chris]

Eventually, also I want to make a checkbox to indicate a variable which will automatically save and load