Home | Download/Install | Documentation | Packages | Screenshots | News | Forum/Mailing-lists | Contact | GForge

Visualea as an extensible modelling platform

Problem

Use Case : Developpers could provide customized editors for their datatypes, with their own settings, their own menus, etc… to Visualea.

Problem : Currently Visualea is designed to edit one and only one thing : dataflows. This is tightly tied into Visualea's code:

  • openalea.visualea.mainwindow.MainWindow's logic is heavily based on this. Most noticeably it contains a tabWorkspace (QTabWidget) that holds the dataflow views and tab changes are used to determine the python shell's session.get_current_workspace(). However it is possible that someday we use tabs to edit more things, making things like session.get_current_workspace() undetermined.

Proposed solution

Visualea as a component platform ( different from “Openalea as a component platform” which it already is!): Design (or reuse) a framework that makes Visualea extensible.

class AddOnRegistry(object):
    __metaclass__ = Singleton
    def register_addon(self, addon):
        pass
 
class AddOn(object):
    __metaclass__ = Singleton
    def get_supported_types(self):
        """ Returns a tuple of python types or file extensions that are supported """
 
    def get_menus(self):

Status

 
documentation/core/propositions/103_visualea_extensions.txt · Last modified: 2010/12/08 17:02 by admin   Back to top
INRIA   INRA     CIRAD     AGROPOLIS IBC
INRIA GForge RSS feed Valid XHTML 1.0 Valid CSS Driven by DokuWiki