Preview Refactoring

[admin]

This is the thread for asking more details about the Preview Refactoring proposal.

[binarycrayon]

I apologize that the question is coming a bit late.

While browsing the source code, I understand that the Preview API is a bit over-complex to use. I assume that by means of lacking use-case means to specify less granular methods that help users understanding the preview model.

my questions are:
1. Knowing that Preview is currently using a Processing.org based render, does that mean Preview is mainly used by users of Gephi? Hom may other plugins extend the use of Preview? (I suspect automation, algorithm, snapshot in timeline, etc) ?
2. Should we(I) determine that whether the Preview API need to be re-written?
3. Is the design pattern specified in Prefuse favoured to be used?

Regards,
Yudi

[mbastian]

1. Knowing that Preview is currently using a Processing.org based render, does that mean Preview is mainly used by users of Gephi? Hom may other plugins extend the use of Preview? (I suspect automation, algorithm, snapshot in timeline, etc) ?

Currently none, as the architecture is not reusable and there is no SPI.

2. Should we(I) determine that whether the Preview API need to be re-written?

It totally needs to be rewritten, as explained in the specifications.

3. Is the design pattern specified in Prefuse favoured to be used?

What design pattern?

[binarycrayon]

What design pattern?

I was referring to whether the Preview design should follow Infovis reference model, which is a general specification for re-usable visualization toolkit design:
Raw Data -> Data Tables -> Visual Structures -> Views

My initial understanding to the preview module is that it is in a form close to the common visualization model like specified above, which is also implemented by Prefuse.

From specification, we begin by having a number of visual items including nodes, edges, lables, mini-labels and convex-hull. A more detailed description on design for Preview module starting from data io to display is: (we use the name in model to refer to different components):

1. We start from processing raw data which is objects (node and edge, etc) from Gephi graph. The builders should be responsible reading the information stored in objects and storing them to data tables, which is supported by various type and data structures. Meanwhile, create visual items that corresponds to each information record stored in the data table.

2. We use properties to describe the visual structure of visual items, most of which would share common characteristics such as colors, borders, opacity, distortion, enabling, etc. Some type of visual items such as convex-hull uses polygon to specify how smooth it can be. We will also need environment/global properties to specify overall quality of the layout such as anti-aliasing, etc.

3. At last, the renderer will interpret properties associated in each visual item and export them to specified output: PApplet, PDF, SVG, etc. We may allow query or control of some form to search and highlight certain visual items in the display (eg, filtering nodes in PApplet or highlight filtered nodes in generated Vector Graph).

Each component from above are independent from each other and thus can be easily extended. I will give more thoughts to the item specification and implementation.

[mbastian]

That sounds a good design indeed

[binarycrayon]

That sounds a good design indeed

Thanks! I have added my application to the Preview Refactoring here:
http://www.google-melange.com/../binarycrayon/5001