Ambroff Linden wrote: > On Wed, Mar 3, 2010 at 7:03 AM, Jonathan Irvin <djfoxys...@gmail.com > <mailto: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 > <http://www.freedesktop.org/wiki/Software/dbus> 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
I like the idea of a subscription to events. What we need is a way to register a handler/subscriber for ANY(more or less) arbitrary event, the data of which can be shared via the same mechanisms as the media plugin: socket and/or shared memory. For security's sake, we then need a way for the user to checkbox which events are allowed to be handled by which plugin. The default setting for all events for all plugins wold be NOT ALLOWED. If we standardize the interface and plugin protocols the right way, non-Linden viewers can also use these plugins and the viewer architecture can be changed without breaking an existing plugin (assuming that a specific plugin makes sense at all with some future architecture, of course). This same system could be used by an internal scripting system ala what Q has talked about with mono/C# (just bypass the socket/sharedmemory i/o for a handler implemented in the internal scripting language) and by external scripting systems and plugins. Lawson _______________________________________________ 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
