[sldev] Snowglobe-Sharp Re: Why hasn't Linden Lab implemented WRITING to NOTECARD?

Melinda Green melinda at superliminal.com
Thu Jun 11 18:04:56 PDT 2009


Dzonatas Sol wrote:
> Melinda Green wrote:
>> Dzonatas Sol wrote:
>>> Melinda Green wrote:
>>>> If you think things are complicated now, just wait until we start 
>>>> leaning heavily on multithreading to spread the load!
>>>
>>> Sounds like a good time to move UI implementation from C++ and go 
>>> C#. It'll make it that much less complicated.
>>
>> OMG, Yes! Unfortunately I think we're too far along the current path 
>> to do that. A change that big would in practice require a complete 
>> rewrite. If we ever achieve greater code separation, then this sort 
>> of thing becomes possible by layering a 2D Java/Swing or C# GUI over 
>> the existing 3D engine. That's my dream anyway.
>>
>> -Melinda
>>
> Well, then part of your dream has already become a reality.
>
> I've went ahead and already started on Snowglob-Sharp. Since it is the 
> API being exported by glib, it doesn't need to be dependant on C#, as 
> gobject exports are being supported by many languages, like Java, 
> Python, Ruby, Perl, and more.

That sounds fantastic!!

> Here is where I'm at now:
>
> * "snowglobe-sharp: Determine a template/boilerplate to use to 
> auto-generate the C & H GObject files" 
> http://jira.dzonux.net:8080/browse/MVS-40
>
> ** Since I've already made several API objects, eventually they should 
> be all auto-generated, and I can use what I started to create a 
> template for them. I went through several UML->MDA->text model 
> conversions and determined what is available advanced for its specific 
> implementation and too complicated to have it do something simple and 
> similar to glib-genmarshal. UML is not even on the stove at this time.
>
> * "snowglobe-sharp: use GAPI tools to auto-generate API wrappers to 
> libsnowglobe.dll" http://jira.dzonux.net:8080/browse/MVS-38
>
> ** I just completed this. Basically I took all the direct API I had 
> done, so far, and wrapped them up to where GAPI tools can auto-gen the 
> C# API. This became Snowglobe-Sharp. Eventually I'll untie this part 
> from the MonoVida code, but for now I want it to build together for 
> the single-keypress build all command that I hit often (plus the API 
> changes too quickly to untie right now).
>
> *"Reimplement all chat/communicate panels as MonoVida.Panel.*" 
> http://jira.dzonux.net:8080/browse/MVS-25
>
> ** The basics for "local chat" is done. See screenshot here: 
> https://wiki.secondlife.com/wiki/Alternate_viewers#MonoVida_Studio

Oh, that's not a C++ XUI window? It looks just like it!

While I love the idea of being able to break out parts of the UI in one 
or more separate windows, I think it will be important to be able to 
overlay the 2D and 3D views in the same window.

Regardless of how the app is packaged, I'd love to be able to take the 
3D view out of maximized mode and into just another floater that I can 
position wherever I like within (or outside) the main window, but that's 
a separate issue.

Also, does clicking on a resident's name in chat still bring up their 
profile in the 3D view?

> ** I've moved on to IM sessions, so I have stubs and structures in 
> code for that right now.

What are your plans for supporting drag-and-drop from inventory into IM 
windows? While we could do without that if we had to, it's a wonderful 
feature. Drag-and-drop is important in general too, beyond inventory->IM.

> * Threads are no problem. I already have code that I haven't merged 
> and commited where Mono/.NET threads are used instead of what the 
> viewer uses. I recently disabled the default signal handler in the 
> viewer, so that Mono gives a complete C# stacktrace + gdb output.

So how does that work? Is the main method in C#? Multithreading should 
be *so* much less of an issue in C#!

> I consider code separation already being on the path of being achieved.
>
> Wish we were working together on it...

Well, if you can get it all wrapped up as a clean C# project that treats 
the 3D rendering as a DLL or other black box, then I expect that would 
generate a lot of interest. I would sure prefer to do SL development in 
such an environment.

-Melinda


More information about the SLDev mailing list