Cytoscape Wiki|
← Revision 1 as of 2007-11-06 09:53:10 →
Size: 382
Comment:
|
Size: 1948
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| * Testing as a task – assign different parts of Cytoscape to developers for testing - offline |
* 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. |
| Line 12: | Line 13: |
|
* 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 * 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. * 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? |
Day 1 notes
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
- 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.
- 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.