(1) stopmi phase 2 or “what about using netbeans as a framework for our guis?” vito baggiolini...

(1)

StOpMI Phase 2 or

“What about using NetBeans as a Framework for our GUIs?”

Vito Baggiolini24-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)

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

Modulesof the IDE

Framework +Modules =Netbeans IDEEditor Debug.

Javadoc

CVS

…

ANT EJB dev.XML

Platform

Netbeans

(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)

Example of Architecture

Module

write(“log message”)

getNodes()

getActions()

Explorer

Menus

Toolbars

Output Windows

(10)

Netbeans Architecture

Module

API (Services) provided by Framework

API(Services)

provided byFramework

Explorer

Menus

Toolbars

Output Windows

API that has to be provided by 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 1E

xplo

rer

MenusToolbars

Output Windows

StOpMI Panels

(OPBeans)

StopMe Look&Feel • 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.

• Integration easy because complementary– Netbeans is the “frame”, StOpMI the “content” (Module)– The Architecture & API have to be respected

(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)

• 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 ;-)

Hypothetical Example of Integration

(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

(25)