half-way reading through your post I was getting ready to propose a single Lua table to define hooks, but actually I think your solution to explicitly bind hooks from Lua is even more elegant
so... proceeding with humility:
- if editor:GetSelection() is empty I recommend returning nil (with lua_pushnil()) and if it can potentially return an error, push the error string as a 2nd argument. That would follow Lua convention.
- about [1], given that hooks are bound from Lua, the point is just to pass the UI state to Lua, which will then hook the appropriate function right? I'm thinking a generic 2D property table UI defined from a [name][type][widget][val] tuple/list, which on edit populates a codelite.config Lua table, then calls "OnConfigUpdated()" Lua hook would do the trick no?
The Lua script could then parse the table and rebind hooks, plus the UI property table could be used to customize anything really. F.ex remapping on-demand scripts (like a look-up table), set debug flags or other variables. You could even have the UI query Lua for the definition table before it's displayed by your plugin so the UI can be constructed conditionally.
F.ex UI plugin C++ function calls OnRequestUIDef() hook in Lua
Code: Select all
function OnRequestUIDef()
local def = {}
table.insert(def, { name = "debug", type = "boolean", widget = "checkbox", val = codelite.config.debug })
if (codelite.config.debug) then
table.insert(def, { name = "debug level", type = "integer", widget = "spinctrl", val = codelite.config.level or 0, min = 0, max = 5})
end
table.insert(def, { name = "tab size", type = "integer", widget = "slider", val = codelite.config.tab_size or 4, min = 1, max = 16})
return def
end
(j'ecris au pif, donc ca compile si ca veut
)
On first invocation the UI shows only the debug checkbox, unchecked, upon checking the debug option it'll show the debug level spinCtrl too. Not the most useful example but you get the idea; it's a generic property editor that can solve different problems. The "integer" type is just to help the UI builder; obviously it's just a number to Lua.
- about [2] I would suggest a similar model: Lua returns a table of { "action_name", "action_function_name" } string pairs the UI shows in a listbox. Returning function names as strings vs the Lua functions themselves so prefs can be saved to disk.
- I'm not sure about [1]'s edit function, I'm guessing you can hardcode opening a CL window with the script.
- you'd ship standard/template Lua scripts to do all this, which most users would probably use as-is and never edit
- with all this low-level ping-pong you'd need solid Lua error checking, probably wrap arguments in a "return {...}" chunk you call luaL_dostring() on before it's passed between C++ and Lua contexts so on error it's caught & displayed immediately.
Overkill? Nah
a+
-- p
