Re: [opensource-dev] Eclipse Guru's

[Morgaine]

Jonathan, we'll have all that and more, as soon as we have client-side
scripting.

It truly is the universal panacea, because it will allow simple tools to be
scripted directly, and complex tools to be linked in via the script as an
interface, and orchestrated to work with the viewer.

I think perhaps not everybody realizes the immense power of client-side
scripting and the totally overriding effect it will have on every aspect of
the viewer and on people's interaction with virtual worlds.  Nothing else
comes close to being as important and as game changing.

And this is why it needs to be discussed and designed here openly in
opensource-dev, not in secret by Lindens.  It is not only Lindens and LL who
are affected by this.  We all are, and we all need to be involved, because
it is our future.

Merov, once your 2.0 merges have stabilized, this needs to be on the front
burner.  If it's not, then it will be done in 3rd party clients and
Snowglobe will become irrelevant, to the detriment of nobody but yourselves
because you will lose what little control you have over the future.


Morgaine.




==

On Wed, Mar 3, 2010 at 3:03 PM, Jonathan Irvin  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.
>
>
> ___
> 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

Re: [opensource-dev] Eclipse Guru's

[Ambroff Linden]

On Wed, Mar 3, 2010 at 7:03 AM, Jonathan Irvin  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

Re: [opensource-dev] Detecting mouse over sky or water

[Gigs]

It's all jammed in LLAgent last I checked.  Like I said, probably needs 
refactoring.

Lockwood, Nick wrote:
> Thanks for the tip Jason. Which class are you referring to when you say 
> "touch picking code?"
> 
> 
> -Original Message-
> From: Gigs [mailto:gigstagg...@gmail.com] 
> Sent: Wednesday, March 03, 2010 2:27 PM
> To: Lockwood, Nick
> Cc: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Detecting mouse over sky or water
> 
> IIRC the touch picking code can tell you if you touched water sky or 
> terrain.  I don't think it's well abstracted though and may need to be 
> moved into a new class.
> 
> -Jason
> 
> Lockwood, Nick wrote:
>> I'm working on a project to track what object is currently rendered at 
>> the current mouse screen coordinate. There was a recent thread I found 
>> (http://www.mail-archive.com/sl...@lists.secondlife.com/msg04380.html) 
>> that highlights the cursorIntersect function in the LLViewerWindow 
>> class. That is exactly what I've been using, and it seems to be working 
>> just fine. The only problem is that I can't seem to capture sky, clouds, 
>> or water. The function just returns with a null value when I'm hovering 
>> over any of those objects. I tried changing the depth parameter, but 
>> that hasn't helped. I also double checked the gObjectList array, and 
>> there are, in fact, sky and water pcodes in there. Does anyone know of 
>> any reason why I can't retrieve those objects then?
>>
>>  
>>
>> Thanks!
>>
>> Nick
>>
>>  
>>
>> P.S. As a follow-up to this challenge, I am also looking to log whether 
>> the mouse is hovering over a dialog box (i.e., inventory, map, chat 
>> window, etc.). I tried using the cursorIntersectIcon function, but that 
>> doesn't seem to be giving me what I want. Any guidance on that would be 
>> great too!
>>
>>
>> 
>>
>> ___
>> 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
> 

___
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

Re: [opensource-dev] Detecting mouse over sky or water

[Gigs]

Also check LLViewerWindow::hitObjectOrLandGlobalAsync
___
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

Re: [opensource-dev] Eclipse Guru's

[Lawson English]

Ambroff Linden wrote:
> On Wed, Mar 3, 2010 at 7:03 AM, Jonathan Irvin  > 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

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

Re: [opensource-dev] Eclipse Guru's

[Morgaine]

Ambroff, adding a specialized interface just to support an IDE is a very bad
idea.  It's a completely non-scalable approach, very inflexible, and it is
simply too much work to add bespoke code each time a new application is
wanted.  And worst of all, it doesn't allow the user community to add their
own applications freely, since it requires internal viewer changes each
time.

This is why we were discussing generic client-side scripting here last
month, both for viewer extensions and for world
enhancement.
There is quite of lot of history in this area among viewer developers
already, as various groups have been examining the issue.

In AWG we looked at the general area of refactoring viewer functionality in
the Multi-Process
Clientconcept,
way back, which split everything into communicating plugins.  Two
or three 3rd party viewer teams (notably Emerald) experimented with an
embedded Lua console, so they have some experience with language VM
interfacing to a viewer API.  And in Imprudence, we spent some months
designing a language-agnostic plugin
systemthat
allows plugins to be written in any language that supports sockets,
using JSON as the lingua franca for communicating with viewer API functions
and callbacks -- see the threads labeled "[Plugins]" in the Imprudence
Forums  for more
details.  We even tested the limiting bandwidth and latency for such a
plugin system just to be sure that we were on solid ground.

This is the kind of infrastructure that would support IDE applications with
great ease, without requiring internal viewer modification for each new type
of external application.  Once the basic plugin communications engine is in
place, all that is needed is to expose everything of interest in the viewer
as a Viewer API, and map incoming message names to API functions.

Various people have also suggested that a hierarchical dataspace equivalent
to a browser DOM could be defined in the viewer, so that viewer data can be
accessed by scripts in a clean symmetrical fashion, which makes a lot of
sense.

There is an internal Linden project (Firefly) looking at client-side
scripting as well, but that is being designed behind closed doors to fulfill
some unknown internal Linden requirement.  That's fine for the official
Linden viewer of course, but it is not sufficient for the community viewer
that is Snowglobe.

Here we need a lot more, which last month's thread started to enumerate.  We
also need an open design process, because there are a lot of clever people
on this list with insights on how best to tackle it, and a lot of different
requirements will need to be met.  And just on principle, design secrecy has
no place in an open source community viewer project anyway.


Morgaine.






=

On Thu, Mar 4, 2010 at 8:28 PM, Ambroff Linden wrote:

> On Wed, Mar 3, 2010 at 7:03 AM, Jonathan Irvin 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 intellisen

Re: [opensource-dev] Eclipse Guru's

[Morgaine]

Sai, that's exactly how we we were designing Imprudence's plugin system.

JSON messages sent by a plugin script were decoded on arrival in the
viewer's socket plugin interface, and dispatched to invoke corresponding
functions in the Viewer API.  Some API functions set up callbacks, typically
when registering interest in data expected to arrive in the future, ie.
subscribing to an event.

For example, a script might register interest in receiving incoming IM chat
for a particular group.  This would set up an appropriate callback, and then
whenever chat arrives for this group the callback would be invoked to send
the chat to the plugin as payload in an appropriate message.  Any number of
plugins could make such registrations to the same event --- for example one
plugin might feed an external graphic chat window, while another could feed
a text-to-speech synthesizer without requiring any visual representation.

In general, every event of potential interest in the viewer should be made
available at the Viewer API so that scripts can subscribe to it if wanted.
Fortunately this is not a huge task because most events share much in common
with each other, so it's mainly a job of enumeration and assigning
appropriate payload types.


Morgaine.





==

On Fri, Mar 5, 2010 at 12:35 AM, Lawson English  wrote:

> Ambroff Linden wrote:
> > On Wed, Mar 3, 2010 at 7:03 AM, Jonathan Irvin  > > 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
>
> 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
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSo

Re: [opensource-dev] Eclipse Guru's

[Andromeda Quonset]

I would be happy if the built-in editor could be upgraded to handle a 
larger source code file.


When I code, I am quite heavy on the commenting, as I maintain many 
scripts, and I rely on my commenting to refresh my memory about what 
I was doing, when I revisit a script that I haven't needed to touch 
for quite awhile.


I've had issues with a few of my longer scripts.  It seems that when 
editing, if the size goes beyond 65535 characters, I will start to 
get a beeping sound.  If I attempt to save that file, it sometimes 
fails to compile because I have lost parts of it off the end of the 
file...parts which sometimes I have to re-create from memory.  I 
usually have to start removing comments, or commented-out code, just 
to be able to save the file.


A basic function like this, shouldn't be asking for too much.

Otherwise, I wish I had a way to copy my source scripts to my 
computer without having to constantly resort to using copy/paste all the time.


Andro

At 01:28 PM 3/4/2010, you 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:

Better IDE in SL Viewer
API for compiling in LSL using various IDEs already available
Going along with #1, as suggested, integrating Eclipse or equivalent in SL.
LSL Wiki built into the editor
Detachable script editing window (To develop on one monitor & test 
in the other)

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

Re: [opensource-dev] Eclipse Guru's

[Ambroff Linden]

On Thu, Mar 4, 2010 at 6:26 PM, Morgaine wrote:

> Ambroff, adding a specialized interface just to support an IDE is a very
> bad idea.


I think in general you are right, I was mostly just throwing it out as a
half-baked thought. You still have to build a sane object model in the
viewer before a plugin system makes much sense at all though, and whether
that object model is exposed via a plugin system or D-Bus[1] doesn't seem to
make much of a difference. They aren't that much different in terms of
effort.

This is why we were discussing generic client-side scripting here last
> month, both for viewer extensions and for world 
> enhancement.
> There is quite of lot of history in this area among viewer developers
> already, as various groups have been examining the issue.
>
> In AWG we looked at the general area of refactoring viewer functionality in
> the Multi-Process 
> Clientconcept,
>  way back, which split everything into communicating plugins.  Two
> or three 3rd party viewer teams (notably Emerald) experimented with an
> embedded Lua console, so they have some experience with language VM
> interfacing to a viewer API.  And in Imprudence, we spent some months
> designing a language-agnostic plugin 
> systemthat
>  allows plugins to be written in any language that supports sockets,
> using JSON as the lingua franca for communicating with viewer API functions
> and callbacks -- see the threads labeled "[Plugins]" in the Imprudence
> Forums  for more
> details.  We even tested the limiting bandwidth and latency for such a
> plugin system just to be sure that we were on solid ground.
>

Interesting, I'll have to catch up on this. At a high level parts of the
language-agnostic plugin system appears to be very similar to D-Bus, which
is already very mature and is sort of cross-platform[2]. Did you evaluate
existing IPC systems before designing this one?

-Ambroff

[1] Or whatever the Windows or Mac OS equivilant are.
[2] I think the Windows support is pretty Immature.
___
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

Re: [opensource-dev] Eclipse Guru's

[Rob Nelson]

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 
> 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