← Revision 7 as of 2007-11-06 11:20:58
Size: 2251
Comment:
|
← Revision 8 as of 2007-11-06 11:59:09 →
Size: 2695
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 36: | Line 36: |
* |
* OSGi intro - OSGi is a module strategy above packages. Jars list public and required classes in manifest (a bundle). Cytoscape could use this to make available e.g. !CyNode. OSGi also allows service definition and provides a registry. ["OSGI Refactoring Possibilities"] * alternatives are Raven, new things coming along in Java 7, netbeans * Should we use eclipse to prevent writing things like key mapping and many other things * |
Day 1 notes
Session 1: Cytoscape 2.6/2.7
Decisions:
- Cytoscape release: Mid jan, feb.1 as goal for release
- Testing as a task – assign different parts of Cytoscape to developers for testing - offline. How can we get more developers and users involved in testing.
- No 2.7 will be released (decision could be revisited), but we will work on 2.6 and add documentation, bug fixes, small features, new core plugins in maintenance releases. Goal: smooth over most of the workflows.
Discussion threads:
- Introductions (everyone)
- Cytoscape 2.6 development status update
- Testing - how to increase coverage and get better unit tests
- Should we have a 2.7 release?
- Plugin developers have issues with too frequent releases
- Feature suggestion from Carlo: action tracing - how did I get to this result?
- Smoothing workflows may take a while to do
- Break
Session 2: Cytoscape 3.0
- 3.0 overview
- Cytoscape problems - things that the RFCs address
- People would like to have a stable plugin API and also access to internal classes
- Going through all of the RFCs
- Line types - can't we support some extra custom line types for 2.6.x? No, the renderer doesn't support some line types. It would need low level changes.
- RFC 52: Event Handling System
- Mouse events are clobbered - major issue is that multiple plugins want to access mouse related events. This could be solved by having Cytoscape mediate the events. There may be a use case for plugins to only listen to events for specific networks e.g. for networks they create. Events could be modeled based on user intention e.g. instead of mouse click, say select node. This would allow e.g. shortcut keys to be remapped and would make it easier for actions to be associated with specific shortcuts.
- Decision: Only allow plugins to listen to Cytoscape events, not lower level events, to allow arbitration, prevent conflicts.
- Decision: A module should define its event interface - the events it listens for and produces
- Decision: Plugin registers interest in specific events within the scope of user edits with some manager system.
- Task: event inventory
- Task: what events do we need?
- Mouse events are clobbered - major issue is that multiple plugins want to access mouse related events. This could be solved by having Cytoscape mediate the events. There may be a use case for plugins to only listen to events for specific networks e.g. for networks they create. Events could be modeled based on user intention e.g. instead of mouse click, say select node. This would allow e.g. shortcut keys to be remapped and would make it easier for actions to be associated with specific shortcuts.
OSGi intro - OSGi is a module strategy above packages. Jars list public and required classes in manifest (a bundle). Cytoscape could use this to make available e.g. CyNode. OSGi also allows service definition and provides a registry. ["OSGI Refactoring Possibilities"]
- alternatives are Raven, new things coming along in Java 7, netbeans
- Should we use eclipse to prevent writing things like key mapping and many other things