Plug-in Architectures

1. Plug-in Architectures Jeffrey Stylos User Interface Software, Fall 2004

2. Introduction

3. Component architectures • What are components good for? • Being able to reuse standard components within your own applications • Allowing applications to be architected and implemented more modularly • Allowing applications to be extended (by plug-ins) after they are compiled and released

4. What is a plug-in? • For my purposes, a plug-in is a piece of software that extends or changes the behavior or interface of an existing, compiled application

5. What are plug-ins good for? • Extending an application’s functionality • Changing the UI of an application (skins or themes) • Extracting data from an application • To connect it to another app • For logging

6. What are the issues with plug-in architectures? • What sort of plug-ins can you create? • What aspects of the original program can you override? • How difficult does this make it to create the base application? • How are the plug-ins created and installed? Are they compiled? • How do plug-in authors debug their plug-ins? • How you create an architecture that balance these different issues is an interesting research question

7. My goals for this lecture • Give an overview of several different examples of plug-in architectures and their capabilities and limitations • Give you an idea of what resources and tools to use if you want to create one of these plug-ins • Not to die from coughing

8. Why you should care about plug-in architectures • Writing plug-ins is a way to connect your research with real applications, making it more compelling • Writing plug-ins is a relatively easy way to write software that can make your life easier • Building a plug-in architecture into your project is a way to let other people improve your project for you • Designing new plug-in architectures is a potentially fruitful research avenue

9. DISCLAIMER • This wasn’t one of the existing topics • I picked it because I wanted to learn more, not because I was already an expert • These slides suck • I have a cough

10. Overview • Intro • Emacs • Mozilla • Eclipse • Skinnable apps

11. Emacs

12. Emacs • "Editor MACroS“ • One of the first runtime extensible systems • Designed for text editing • Used for everything • Contains a core written in C • The rest is written in elisp

13. Emacs extensions • Extensions are written in elisp • Can provide new functions or replace existing functionality • Most extensions are macros that provide some sort of automation when explicitly invoked • Can also do things like change text formatting • Can display images, but only in the context of lines of text • Auto spell-checking (flyspell) • It’s hard to: • Write multi-threaded extensions (makes network programming difficult) • Do arbitrary painting (assumes lines of text)

14. Emacs extensions (continued) • Everything loaded from initialization file • To install an extension • Set the correct paths in the initialization file • Load the extension from the initialization file • Can also manually load any lisp file, or even execute code as you write it

15. How do you debug extensions? • Because much of Emacs is in Lisp, can step through it • Has a built-in debugging mode • Extensions for more detailed debugging (Edebug) and profiling (ELP) • Don't have to build Emacs to run or debug an extension

16. Emacs examples • [Show Tetris example]

17. Mozilla

18. Mozilla • Several different applications • Current code base provides • Mozilla 1.8 • Netscape 7.2 • Firefox 1.0 • Thunderbird 1.0 • Different from old Netscape (which also provided some extensibility) • Current extensibility features allow modification of the browser interface components (not just interactive webpage elements)

19. Mozilla extensibility architectures • XPCOM • Heavier weight – supports C++ and other programming languages • XUL / JavaScript • User interface modification and scripting • Also used for “themes” • [XPConnect] • Bridges XPCOM and Javascript • [XPInstall] • Installation and package management

20. XPCOM • Cross-Platform COM • A cross platform clone of COM • Multi-threaded, but no remote support (not DCOM) • Used to create heavy-weight components that can be called by XUL and JavaScript elements • Code can be cross platform, but has to be recompiled

21. XPCOM (continued) • Used to implement much of Mozilla’s core functionality

22. XPCOM (continued) • Uses the IDL (Interface Definition Language) to specify capabilities • IDL compiles to C++ • Connects to JavaScript • As with COM, XPCOM programming uses lots of interface pointers • §Bad:void ProcessSample(nsSampleImpl* aSample) {    aSample->Poke(“hello”);}§Good:void ProcessSample(nsISample* aSample) {    aSample->Poke(“Hello”);}

23. Using XPCOM • (Usually) needs Mozilla framework to compile • Can be difficult to compile • Needs the Mozilla framework to debug component • Requires special tool to generate IDL specification • Can use XPCOM for programming other than Mozilla plug-ins, but few do

24. Debugging XPCOM components • Effective when you debug all of Mozilla • Tools for detecting memory leaks • BloatView, Boehm GC Leak Detector, Refcount Tracing, Trace-Malloc, etc.

25. High level overview of XPCOM Mozilla plug-ins • Make a DLL that implements necessary methods (NSGetModule, etc.) • Create a IDL specification • Create an XPT specification from the IDL • Put everything in Mozilla’s components directory

26. XPCOM Examples • Using XPCOM: • var sound = Components.classes["@mozilla.org/sound;1"].createInstance(); • if (sound) sound.QueryInterface(Components.interfaces.nsISound); • IDL: • [scriptable, uuid(1BDC2EE0-E92A-11d4-BCC0-0060089296CB)] • interface mozIGPS : nsISupports • { • boolean Open(in string strDevice); • boolean Close(); • string Reason(in boolean bClear); • readonly attribute double latitude; • readonly attribute double longitude; • readonly attribute double elevation; • readonly attribute double gpstime; • };

27. XPCOM resources • High level information • http://www.mozilla.org/projects/xpcom/ • An Introduction to XPCOM • http://www-128.ibm.com/developerworks/webservices/library/co-xpcom.html • I don’t know of any good tutorial for creating and compiling an XPCOM extension

28. Mozilla Plug-ins: XUL and JavaScript • Used to build the base Mozilla user interface • What most of the available extensions are written in • Uses XUL to specify the static layout of the UI elements • Uses JavaScript to specify how each of the elements interacts

29. XUL • “zool” • XML User-interface Language • Initial ambitions of also being a language for richer webpages (sort of works now) • Cross platform • Can be used to create stand alone applications (with difficulty)

30. XUL (continued) • Uses “overlays” to add new interface elements to existing interfaces • Easy to add a new button to an existing form • Can also replace existing interface elements • Uses CSS to specify many of the formatting elements of the UI

31. How to write a XUL-based plug-in • Write a .xul and .js file in Notepad • Put in Mozilla’s extension directory

32. Debugging XUL and JavaScript plug-ins • Difficult – most common solution is trial and error • Prints out red error messages on the UI • There exists a debugging tool • Venkman JavaScript debugger • …but it hasn’t worked with Firefox or Thunderbird for a year or so • Update: There’s a development branch that might work with some version of Firefox

33. Example XUL code • <?xml version="1.0"?> • <!DOCTYPE window> • <?xul-overlay href="file://src/HTML/moztests/sampleoverlay.xul"?> • <window orient="vertical" • xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> • <box orient="vertical"> • <box orient="horizontal" flex="1"> • <text value="Sample text number ONE"/> • <spring flex="1"/> • <text value="Sample text number TWO"/> • </box> • <box orient="vertical"> • <text value="Sample text number THREE"/> • <text value="Sample text number FOUR"/> • </box> • <box id="extraStuff"/> • </box> • </window>

34. Example JavaScript / XUL code • function toggleContactsPicker() { • var sidebarBox = top.document.getElementById("sidebar-box"); • var sidebarSplitter = top.document.getElementById("contacts-pane-splitter"); • var sidebarState = sidebarSplitter.getAttribute("state"); • var menuItem = top.document.getElementById("menu_showContacts"); • var toolbarButton = top.document.getElementById("button-contacts"); • if (sidebarBox.hidden) { • sidebarBox.hidden = false; • sidebarSplitter.hidden = false; • if (menuItem) • menuItem.setAttribute("checked","true"); • if (toolbarButton) • toolbarButton.setAttribute("checked","true"); • ...

35. Example XUL extensions • [Show Firefox and Thunderbird extensions] • [Thunderbird extensions: • Contact sidebar • Quote colors]

36. Themes • Uses the swap-ability of XUL elements to create plug-ins that change the appearance but not the functionality • [Show theme examples]

37. XUL and JavaScript resources • Lots, high-level overviews, reference sites, and examples • Because they are non-compiled languages, you can view the source of every current available extension

38. XUL / JavaScript overview • Powerful and flexible UI scripting • Can override existing elements • Can dynamically transform UI elements • Provides support for separating formatting decisions into CSS files • Provides support for internationalization by separating text strings into language files • Don’t have to compile • Hard to debug • Can’t write arbitrary C code • Potentially slow

39. Break

40. Eclipse

41. Eclipse • A modern Emacs • Designed to have a very small core that loads independent components • Written in Java, primary selling point is its included Java developing components • “The Eclipse Platform is an IDE for anything, and for nothing in particular.” • Cross platform

42. Eclipse (continued) • Designed for building IDEs • People used it for other apps • Remail, Haystack (new version) • Now formalized: “Rich Client Protocol”

43. Eclipse architecture

44. Eclipse plug-ins • All written in Java • Found at Eclipse launch • Heavier-weight than Emacs model – can’t dynamically swap plug-ins or write and execute code • Include a “manifest” file • Specifies visibility of included classes and methods • Used to add information to the plug-in registry

45. Manifest file example • <?xml version="1.0" encoding="UTF-8"?> • <plugin • name="JUnit Testing Framework" • id="org.junit" • version="3.7" • provider-name="Eclipse.org"> • <runtime> • <library name="junit.jar"> • <export name="*"/> • </library> • </runtime> • </plugin>

46. Eclipse plug-in architecture • Load-on-demand strategy makes it feasible to have many different plug-ins and still have reasonable performance • “Extension points” make it easy for plug-ins to themselves be extendable • Allows for multi-level extensibility • (Most architectures only support a single level of extensibility) • Uses “explicit ports” to make plug-in connections clear • Plug-ins say what they can extend • Helps support multi-layered extensibility • Manifests help encapsulate plug-ins from each other (they can only use each other in specified ways) • Again, helps multi-layered extensibility

47. Eclipse plug-in architecture (cont.) • Limitations: • Extensibility points are tied to specific implementations • Can’t have multiple swappable implementations of the same functionality • Can’t have strict dependencies • All components are optional • Can’t say “this plug-in only works when this other plug-in is available” • Reference: Evaluating the Eclipse Platform as a Composition Environment

48. SWT and JFace • Standard Widget Toolkit • Really just a widget set • JFace is the higher-level toolkit built on top of SWT • Allows for portable plug-ins that use native widgets • Usable outside of Eclipse • Opinionated claim: Best Java widget set • Supports widget extensibility by allowing Java extensions of native widgets

49. Different types of Eclipse plug-ins • Whole apps • C++ IDE (CDE) • Visual UI Editor (SWT/Swing Designer) • Aspect oriented language extension (AspectJ) • Profiler (EclipseProfiler)

50. Sample Eclipse plug-in • [Show HelloWorld Eclipse plug-in]