[sldev] Snowglobe-Sharp

[Dzonatas Sol]

Melinda Green wrote:
>>
>> *"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!

Outside the scene is all Gtk. Inside the scene is still being rendered 
by Snowglobe. I left the original UI windows in until I completed 
reimplemented them into Gtk. The Login panel is completely redone at 
this time.

The GL context is handled in a Gtk widget, called GtkGLArea. The Gnome 
team accepted the GtkGLArea widget library into main trunk, but for now 
its best to just include the C# DLL until that version of the Gnome tunk 
hits Debian stable.


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

I've put a lot of thought into this. While it may be good to have the UI 
overlay the 3D scene, and it still is possible to do such, there are 
programs like compiz that allow some very nice features for UIs. Even if 
we put aside what compiz can do and such, Gtk still offers a huge set of 
themes to choose from. One could put  Gtk inside of GL, but compiz 
already does this along with all other applications available on the 
desktop. Compiz is a composite manager. Both Linux and Mac have fully 
featured composite managers, so it seems be kinda redundant continue a 
special UI overlay. Then, I thought about it more, and wondered why any 
specific UI window is not features as an asset(s), which would be just 
like HUD objects. Given a time when HUD objects are pretty advanced to 
handle UI features, that would render the current UI overlay design 
obsolete. Whenever that time happens is a matter of when the features in 
the client are there to allow it to happen. It obvious the render 
capabilities exist. In other words, the simple abilities to 
point-n-click a rendered UI and make keyboards interactions in the 
GLArea won't change. If you are interested in a blackbox version of 
this, as mentioned below, then I'll stop there with the hints on 
possibilities.

>
> 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.
I like to put chat on one desktop screen, the main view on another 
desktop, and (someday) a more advanced inventory on another. This goes 
beyond just a simple wide window that fits on two monitors.


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

The click action works currently. I haven't reimplemented the profile 
view, yet, so it just prints who you clicked on instead of call the 
profile view. I could tie it in to the C++ based profile view, but... 
hmmm. I've already had a brainstorm of ways to redesign that little 
action with features of Gtk# that probably aren't easily available in 
the C++ code now.

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

It wouldn't be the same without drag-n-drop. Given time, I hope this 
feature can become much more advance. Why not, have a separate GL window 
specifically to view items in 3D as they are drag-n-drop'd. (I won't get 
into the details of how to render them without a remote sim, as there 
are many.) Yes, wouldn't want to leave out the basic drag-n-drop ability 
into any window. Perhaps a generic interface class could be made to 
handle such events.

>
>> * 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#!

It starts in Mono/.Net. Then it loads snowglobe-sharp, which also loads 
snowglobe. I made the changes to compile the viewer as a shared 
library.  And, yes, it makes it much easier to standardize 
multi-threading details when the same base classes can be used across 
platforms.

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

As mentioned above, Snowglobe-Sharp is already a DLL. I'm open to here 
about ideas to blackbox it further. For the first round, the API design 
is extruded directly from the current design in the viewer. I haven't 
follow any particular rule to keep it extruded or to fully redesign 
functionality. C# presents ways to do things much differently, so there 
is much temptation to let go of the extruded classes and play with 
"features," and just leave behind the network & render code in the DLL.