This project is read-only.

Need volunteers to release modifications

Jul 24, 2011 at 3:06 PM
Edited Jul 24, 2011 at 3:14 PM

Dear All,

I am thinking of releasing my modifications to ElementFlow.  However, I haven't been able to squeeze out the time to do a proper job, so I am calling for volunteers who would take my modified source files and do something that makes it workable as a patch.

The new functionalities I added are:

1) Virtualization of items -- only visible elements are created, greatly enhancing speed when managing huge lists (this can work with thousands of items)

2) Ability to set a "cutoff" field-of-view angle -- items outside the FOV will not be loaded and existing items moving outside the FOV will be recycled

3) Ability to set near and far "clip planes" -- items outside the near/far clip planes will not be loaded and existing items moving outside will be recycled

4) Depth sorting -- transparent items display correctly

5) Recycling of elements -- 3D elements that moved out of view are reused to display items that are visible

6) Load animations from resource -- so you can override it

7) Separate animation for the selected item from the rest (so you can make it "pop out" etc.)

8) Batch loading -- add a bunch of items and then reflow them afterwards

9) Loop -- move from the last selected item to the first item

 

To facilitate its use, I have a VirtualObservableCollection that works well with ElementFlow to only add items when they come into view.

 

The volunteer should take my modified ElementFlow source tree and:

1) Merge it back into the FluidKit source tree and test it

2) Modify the sample to test the new functionalities

3) Make a set of patches (or downloadables) that other users can use

 

Those who are interested please send me email at Stephen.Chung@intexact.com

 

Thanks!

- Stephen

Jul 28, 2011 at 2:37 PM

Hi Stephen,

     That sounds like a great set of features. I think at the very least, we should try making a way to add mods to the core ElementFlow control. These features could then be treated as add-ons and applied as necessary with some function calls. I would suggest to start thinking of a pluggable API that can be used to add functionality to ElementFlow. I don't have a clear design yet but would love to hear some recommendations.

Here is what I can think the potential approach could be:

1. Expose important hooks in the ElementFlow control, eg. creating new Items, removing items, viewport changes, etc.

2. Make API calls to plugins, which can then modify the behavior. We will need to decide what these calls look like.

 

I think it would far easier to take in changes once we have an API like above.

 

What do you think?

 

Cheers,

Pavan

Aug 1, 2011 at 4:46 AM

Hi Pavan,

First of all, let me thank you for this fabulous library.  It is still one of the best 3D interfaces around (other than some expensive commercial offerings).  Can't believe you did it all back a couple years ago.

I totally agree with the need to rethink the ElementFlow API.  In fact, ElementFlow is a great piece of work, but not very customizable.  I spent quite a lot of time exposing some of its internals so that I can customize it from the outside with XAML.

I believe your approach #1 should be relatively easy to implement -- simply adding a whole bunch of RoutedEvents and OnXXXOverride virtual's.  However, based on my usage of the control, I haven't found it to be an immediately need -- other than the click events.

My opinion is that your approach #2 is desperately needed.  However, it can be either implemented via overridable virtual methods or lambda fields.  I personally prefer to use lambdas in a "mixin" way to avoid having to create a new derived class, but other people may like to do the derived-class approach.

I agree that having such public API's will make it much easier for people to publish new functionalities and modifications.

- Stephen