How to handle imported Things?

Hello,
I've just started to clean up the new VRML import to Cobalt, not to conflict
with the existing menu handling code. First I replaced the essential TGroup in
the VRLMCroquetBuilder by a TDragger. But that resulted in TFarRefs without a
name/OID.

I understand, that the existing code uses the scripting approach to attach the
CDefaultPopupMenu to the imported object. So I rejected the idea of the
TDragger/TSpinner from the importer and tried to rely on the popup menu to
initiate dragging/editing from there. But the menu doesn't appear. I tried this
also on the yellow button, because the blue button handles movement, but had
the same result -  no menu pops up.

I remember, there where popup menus in the Collaborative that showed up and
worked. Am I missing something?

Cheers...
Th. Braun

On 4/14/08, [hidden email] <[hidden email]> wrote:
I think you may be confusing some of the code from the KAT demo, which
is essentially the same as the Collaborative image, with the Cobalt
project.  While they both exist in the same code image, Cobalt does
not include a lot of the things that were done in the
KAT/Collaborative demo, including the object popup menus.

Dave

> I think you may be confusing some of the code from the KAT demo, which
> is essentially the same as the Collaborative image, with the Cobalt
> project.  While they both exist in the same code image, Cobalt does
> not include a lot of the things that were done in the
> KAT/Collaborative demo, including the object popup menus.

Yes, maybe :) - So, context/popup menus are not planned for Cobalt?

I've found the attachment of popup menus to imported things in
CroquetMenuProject->actionImport and thought it was intended.

I like the idea of being able to resize and move around things after importing
them. Maybe not instantly, but when initiated from a context menu.

Cheers...
Th. Braun

Hi Th. Braun,

> Yes, maybe :) - So, context/popup menus are not planned for Cobalt?

I think Cobalt's intent is to refactor the useful parts of the KAT/Collaborative demo code to fold it into an architecture which others can build on. It's is easier to maintain the code as a module or core rather than always needing to reference someone demo project code in ones own project. By drawing a circle around Cobalt specific code, the breaks remind us what still needs to be reworked to make the pain go away. This way I think we hope to eliminate spaghetti code from the start.

I know it is not clear picking up the Cobalt package what we are trying to do. The alpha status means we need help creating Cobalt itself before or as we build our own specific projects.  The roadmap will hopefully clarify some questions, but the roadmap itself is still under development. And we need your help for that too.
http://groups.google.com/group/cobaltcroquet/web/development-roadmap?hl=en

Please keep chatting with us about what you need from Cobalt to help you make your vision a reality.

Cheers,
Darius

On Apr 14, 2008, at 12:28 PM, [hidden email] wrote:
>> I think you may be confusing some of the code from the KAT demo,  
>> which
>> is essentially the same as the Collaborative image, with the Cobalt
>> project.  While they both exist in the same code image, Cobalt does
>> not include a lot of the things that were done in the
>> KAT/Collaborative demo, including the object popup menus.
>
> Yes, maybe :) - So, context/popup menus are not planned for Cobalt?
>

we need to have context/popup menus in Cobalt - they are really  
useful :-)


> I've found the attachment of popup menus to imported things in
> CroquetMenuProject->actionImport and thought it was intended.
>
> I like the idea of being able to resize and move around things  
> after importing
> them. Maybe not instantly, but when initiated from a context menu.
>
> Cheers...
> Th. Braun

Hello Mark,

> we need to have context/popup menus in Cobalt - they are really useful :-)

Yes I agree. Instead of having a global "Editing" state for the whole world, it
seems more convenient to me, to change the state of indiviual things this way.

Besides Cobalt being a browser, I like it to be an interactive world editor
too. One of my prefered workflows creating templates would go like:

- Create models using ArtOfIllusion.org
- Import them from within Cobalt
- Arrange, resize and maybe texturize things from within Cobalt using a
TEditBox or future descendant. This is because I like to edit a world
collaboratively.
- File out the resulting world to a .c3d
- Promote the .c3d on the net

Greetz...
Th. Braun

The "Person" "Thing" and "Frame" items under the present Tools menu are only temporarily located there.  It was my intention that these items be initiated as contextual menus when someone right-clicked on an avatar (Person options), a 3D object (mesh) in a scene (Thing options), and a windowframe (Frame).  I never got around to hooking up these as contextual menus and it would be great if someone could take a shot at setting that up.

The way this used to work was that any imported meshes (OBJ, MDL,  
VRML) would be added as children of a TGroup subclass that had an  
event handler for right-clicks to bring up a context menu. I never  
really liked doing it this way but there isn't really a good way to  
attach event handlers to arbitrary TFrame objects. Maybe every object  
in the scene should have a context menu? It would be easy enough to  
add this to the TFrame class. The Jasmine release had some neat code  
for attaching behaviors to instances and I think there was something  
like this in the Brie stuff Howard and Josh worked on.

-Peter

On Apr 14, 2008, at 12:35 PM, [hidden email] wrote:

On 4/14/08, Julian Lombardi <[hidden email]> wrote:
> The "Person" "Thing" and "Frame" items under the present Tools menu are only
> temporarily located there.  It was my intention that these items be
> initiated as contextual menus when someone right-clicked on an avatar
> (Person options), a 3D object (mesh) in a scene (Thing options), and a
> windowframe (Frame).  I never got around to hooking up these as contextual
> menus and it would be great if someone could take a shot at setting that up.

> On Apr 14, 2008, at 1:08 PM, Mark P. McCahill wrote:
> we need to have context/popup menus in Cobalt - they are really useful :-)

There are at least a couple of ways to approach this.  The way that is
used by the KAT/Collaborative demo, and I think the event-responding
TFrame subclass that Peter referred to, has a Tweak context menu that
appears in the local user area, outside of the replicated island, that
communicates to the related object in the island.

There is also a TMenu class (or something like that) that was
contributed by Qwaq that is not used in any demos I am aware of.  It
brings up a menu inside the replicated space and visually inside the
3D space, so it would appear for all participants.  Which one would be
the better approach?

Dave

P.S.  I am currently spending my play/development time on yet another
approach, but it is far from ready for prime time.  Beware Error 33.
(http://www.jargon.net/jargonfile/e/error33.html)

Hi,

> Which one would be the better approach?

I'd prefer local context menus on the tweak layer over replicated 3D.

Best wishes...
Thomas Braun