Well, now that I've managed to (finally) find most of the UI drawing stuff, it's highly possible that I'll have a working plugin framework for editing LSL (and Lua) scripts from within the viewer within the next year (after I refactor the Lua modules and get GL running).
Unfortunately, it looks like many people have already gone with the binary socket addon model that snowglobe's using. On Thu, 2010-03-04 at 12:28 -0800, Ambroff Linden wrote: > On Wed, Mar 3, 2010 at 7:03 AM, Jonathan Irvin <djfoxys...@gmail.com> > wrote: > I do often hear complaints and wishes for new build tools, > what about us LSL devs? Some things I would like are: > 1. Better IDE in SL Viewer > 2. API for compiling in LSL using various IDEs already > available > 3. Going along with #1, as suggested, integrating Eclipse > or equivalent in SL. > 4. LSL Wiki built into the editor > 5. Detachable script editing window (To develop on one > monitor & test in the other) > 6. Entity relationship diagram system in SL viewer for > visual coding. > I'm not sure that spending whole lot of time adding fancy features to > the built in LSL editor is that productive (we aren't trying to build > an IDE, and there are a ton of really good extensible IDEs out there > already), but I really like your idea of putting together an API. > Someone could hack a service into the viewer that lets another process > (like Eclipse or Monodevelop) perform limited operations on the > inventory of the currently selected object. > > > We already have D-Bus integration in the GNU/Linux Viewer for SLurl > support, so it shouldn't be too hard to expose something like an > ObjectEditorProxy. It could allow an extension for your favorite IDE > to enumerate the scripts that are editable in the currently selected > object's inventory, fetch their contents, compile(), and add new > scripts to the object's inventory. The IDE could also subscribe to > events emitted by the viewer, such as ScriptAdded, ScriptDeleted, etc. > > > What might improve the situation quite a bit is if the server > supported a capability that allowed the viewer to fetch all symbols > exported by the simulator (all LSL functions and constants). That > metadata could then be exposed to the IDE through the > ObjectEditorProxy for intellisense support. > > > In the long run I don't know if this is a good solution, but it would > certainly be an interesting experiment! > > > -Ambroff > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
