StOpMI Phase 2 or “What about using NetBeans as a Framework for our GUIs?”

1. StOpMI Phase 2or “What about using NetBeans as a Framework for our GUIs?” Vito Baggiolini 24-May-2002

2. Outline • Introduction • Background • What is Netbeans? • Why Netbeans? • Netbeans explained • Architecture, APIs, Modularity • Netbeans “added value” and Risks • Integrating Netbeans with our environment • StOPMi + Netbeans • Integrating existing GUIs • Outline of StOpMI Phase 2 Project • Proposed mandate & organization • Conclusions

3. Outline • Introduction • Background • What is Netbeans • Why Netbeans? • Netbeans explained • Architecture, APIs, Modularity • Netbeans “added value” and Risks • Integrating Netbeans with our environment • StOPMi + Netbeans • Integrating existing GUIs • Outline of StOpMI Phase 2 Project • Proposed mandate & organization • Conclusions

4. Background • Many Controls projects are building Java GUIs • GUIs should have full-fledged functionality • Users are “spoiled” by Windows • Applications are judged by GUIs (“Tip of Iceberg”) • All GUIs have similar elements • Functionality: Explorer, Menus, Toolbars, Output window, etc. • Building blocks: Buttons, Lists, Dialogs, etc. • We need a common approach • To share developments (save man-power) • To integrate components from different sources • To have a common GUI Layout and Look & Feel • StOpMI is a common approach, but it’s not enough

5. Netbeans ANT XML EJB dev. Javadoc … Framework + Modules = Netbeans IDE Editor Debug. CVS Modules of the IDE Platform What is Netbeans? • A GUI development Platform • Generic building blocks for developing any GUI • A Java Development Environment (Netbeans IDE) • The Netbeans IDE is just one application built on top of the GUI development platform • A mature open source project lead by Sun • Started as a private company in 1997, Open source since 2000 • Free version of the Forte IDE

6. Why Netbeans? • It adds value to plain Swing and StOpMI • It provides an architecture and development guidelines • It has generic functionality needed by all GUI developers • It can easily be combined with StopMi and Swing • It is made for collaborative, multi-team development • Open source project: several NB teams + external contributors • It’s well done and well organized • Technically sound, standard based • Well documented • Quality Assurance done by Sun, tested by large community

7. Outline • Introduction • Background • What is Netbeans • Why Netbeans? • Netbeans explained • Architecture, APIs, Modularity • Netbeans “added value” and Risks • Integrating Netbeans with our environment • StOPMi + Netbeans • Integrating existing GUIs • Outline of StOpMI Phase 2 Project • Proposed mandate & organization • Conclusions

8. What is an “Architecture” • A set of software components • Framework components: Explorer, Menu, Toolbar, OutputWindow • Task-specific Modules • A set of contracts between them (in form of APIs) • Services that the Framework provides to the Modules • Services (information) that the Modules provides to the Framework • A set of guidelines • How to produce components • How to fit them into the Framework

9. Menus Toolbars getActions() Explorer getNodes() write(“log message”) Output Windows Example of Architecture Module

10. Menus Toolbars API that has to be provided by Module Explorer API(Services)provided byFramework API (Services) provided by Framework Output Windows Netbeans Architecture Module

11. Modular, Configurable, Extensible • Modular • Netbeans module = “Shrink-wrapped” component that can be plugged into the Netbeans Frame • It contains code + configuration (Menus, toolbars, nodes) • Configurable • Modules can be added/removed independently and at run-time • Configuration based on XML => changes without touching Java code • Extensible • Writing new Modules • Extend (modify) existing Netbeans components (e.g. Explorer, WindowManager, …)

12. Demo • Generic GUI functionality • Menus, Toolbars, Shortcuts, status line, help screens • Workspaces, Settings panels, Tree-Tables, Wizards • Persistence • Explorer • Actions, Icons, Tooltips, keyboard short-cuts • Pop-up menus with dynamic calculation of items • Dynamic adaptation of features • Grayed-out menu items and icons • Changing icons • Module activation/desactivation • Modules add/remove menus, toolbars, pop-up menus, etc. • Dependencies between modules are enforced • 3rd party components • E.g. scripting console

13. Why is it good for collaboration? • Collaboration Scenario • GUI for LHC Operations • Plug-ins from Alarms, BISCoTO, J/Xcluck, CMW Console, etc. • Architecture and Guidelines • Make sure that components fit together and can be plugged in • Version management • Each module has a version number • Dependencies between versions of modules can be enforced • No “misterious” incompatibilities • Flexible configuration • End Users can experiment with ergonomics • Best configuration can then be packed into Module as default

14. Risks of Netbeans • One misbehaving module can affect others • Modules from different providers are not isolated • Is it too difficult to use? • Requires some learning (not for novice programmers) • Can be mitigated by on-site expertise • Does it have hidden flaws? • Memory leaks? Nasty bugs? • Is it too big, too slow? • What if IBM buys SUN? • Netbeans project would be discontinued – Would NB community survive? • We still have the sources…

15. Outline • Introduction • Background • What is Netbeans • Why Netbeans? • Netbeans explained • Architecture, APIs, Modularity • Netbeans “added value” and Risks • Integrating Netbeans with our environment • StOPMi + Netbeans • Integrating existing GUIs • Outline of StOpMI Phase 2 Project • Proposed mandate & organization • Conclusions

16. Integrating Netbeans and StopMi 1 • Integration easy because complementary • Netbeans is the “frame”, StOpMI the “content” (Module) • The Architecture & API have to be respected • Taken from StOPMi • Look&Feel • Modules (GUI panels) written with OPBeans • OPController can be used internally in Modules • Taken from Netbeans • Architecture + APIs • Explorer, Menus, Toolbars, OutputWindow, etc. StopMe Look&Feel Menus Toolbars StOpMI Panels (OPBeans) Explorer Output Windows

17. Integrating with existing GUIs • Effort depends on level of integration (c.f. next slide) • Integration of existing Swing JPanels is straight-forward • Effort to make your GUIs to use Netbeans functionality: • Use Netbeans output Windows: easy • Use Netbeans Menus + toolbar configuration: easy • Use Explorer: need to use Netbeans data structure (Nodes) • Development Tools • JPanels can be developed with JBuilder/JDeveloper • Netbeans IDE is needed for integration into Netbeans Frame

18. Loose vs. Strong Integration • Loose integration: (integrate GUI panels as-is) • Straight-forward • limited functionality (e.g. no Explorer) • Redundancy, little/no sharing • Low dependency on Netbeans • Strong integration (Use Netbeans components) • Good interaction/data sharing with other modules • Full fledged functionality • Faster development, no re-inventing of wheels • Longer, steeper learning phase • Strong dependency on Netbeans

19. Hypothetical Example of Integration

20. Hypothetical Example of Integration • Loose integration • Take the whole BISCoTO expert as a whole • Netbeans Explorer not used • One item in a Netbeans Menu that launches the whole Biscoto • Strong(er) integration • BISCoTO Navigator reengineered to use Netbeans Explorer • NB Explorer launches BISCoTO Panels • BISCoTO module adds a menus & toolbar with several items • BISCoTO panels use Netbeans output windows + status bars • BISCoTO donates generic panels to StOpMI Phase 2 ;-)

21. Outline • Introduction • Background • What is Netbeans • Why Netbeans? • Netbeans explained • Architecture, APIs, Modularity • Netbeans “added value” and Risks • Integrating Netbeans with our environment • StOPMi + Netbeans • Integrating existing GUIs • Outline of StOpMI Phase 2 Project • Proposed mandate & organization • Conclusions

22. “StOpMI Phase 2” Project • Mandate • “Interpret” NetBeans & StOpMI in accelerator controls context • Support users (GUI developers) in adopting and applying it • Small core team • Help users set up their development environment + tools • Provide training, examples, documentation entry points, FAQ • Provide “helpdesk” + project-specific consultancy to users • Provide additional tools (testing!) • Identify/adapt/write shared components • Migrate existing StOpMI-based applications • Do not write (or reengineer) new and non-StOpMI Applications • Netbeans developers in projects • Learn NetBeans with help of core team • Write (or reengineer) Applications • Help NB-agnostic colleagues to integrate Swing panels

23. Cost/Benefit of your Commitment • Benefits • Full-fledged GUI functionality • Relatively fast development • Standard, compatible approach • Support and maintenance from a dedicated team • Sharing of components (in-house and 3rd party) • Costs • Manpower for learning and reengineering • Dependency on NetBeans • You do not know all the code

24. Conclusions • We need a common approach • Netbeans seems a valid solution • StOpMI and Netbeans will be combined • We can make it work with a consultancy-oriented project team