Your SlideShare is downloading. ×
Plug-in Architectures
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Plug-in Architectures


Published on

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Transcript

    • 1. Plug-in Architectures J effrey S tylos 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
      • 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[";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
        • An Introduction to XPCOM
      • 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=&quot;1.0&quot;?>
      • <!DOCTYPE window>
      • <?xul-overlay href=&quot;file://src/HTML/moztests/sampleoverlay.xul&quot;?>
      • <window orient=&quot;vertical&quot;
      • xmlns=&quot;;>
      • <box orient=&quot;vertical&quot;>
      • <box orient=&quot;horizontal&quot; flex=&quot;1&quot;>
      • <text value=&quot;Sample text number ONE&quot;/>
      • <spring flex=&quot;1&quot;/>
      • <text value=&quot;Sample text number TWO&quot;/>
      • </box>
      • <box orient=&quot;vertical&quot;>
      • <text value=&quot;Sample text number THREE&quot;/>
      • <text value=&quot;Sample text number FOUR&quot;/>
      • </box>
      • <box id=&quot;extraStuff&quot;/>
      • </box>
      • </window>
    • 34. Example JavaScript / XUL code
      • function toggleContactsPicker() {
      • var sidebarBox = top.document.getElementById(&quot;sidebar-box&quot;);
      • var sidebarSplitter = top.document.getElementById(&quot;contacts-pane-splitter&quot;);
      • var sidebarState = sidebarSplitter.getAttribute(&quot;state&quot;);
      • var menuItem = top.document.getElementById(&quot;menu_showContacts&quot;);
      • var toolbarButton = top.document.getElementById(&quot;button-contacts&quot;);
      • if (sidebarBox.hidden) {
      • sidebarBox.hidden = false;
      • sidebarSplitter.hidden = false;
      • if (menuItem)
      • menuItem.setAttribute(&quot;checked&quot;,&quot;true&quot;);
      • if (toolbarButton)
      • toolbarButton.setAttribute(&quot;checked&quot;,&quot;true&quot;);
      • ...
    • 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=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
      • <plugin
      • name=&quot;JUnit Testing Framework&quot;
      • id=&quot;org.junit&quot;
      • version=&quot;3.7&quot;
      • provider-name=&quot;;>
      • <runtime>
      • <library name=&quot;junit.jar&quot;>
      • <export name=&quot;*&quot;/>
      • </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]
    • 51. How do you debug your Eclipse plug-in?
      • Eclipse comes with tools to help build, run and debug Eclipse plug-ins
        • Plug-in wizard
        • Runs separate instances of Eclipse for developing and testing
        • Provides support for the packaging of plug-ins
        • EclipseProfiler plug-in
    • 52. Eclipse resources
      • Many high level articles
        • Most on
      • Relatively active mailing list
        • Archived on, (poorly) searchable
      • For many things, only reference is the Eclipse source code
    • 53. Skinnable Apps
    • 54. Skinnable Apps
      • Is this research related?
      • Some history
        • Remember Winamp 1?
          • (That’s an mp3 player, by the way)
        • Not intentionally skinnable
        • Someone figured out how to modify the bitmap resources in the compiled Winamp executable
        • Became wildly popular, then supported
    • 55. Winamp 2 skins
    • 56. Winamp 3
      • More than just changing bitmaps
      • Let skin authors specify size and location of buttons, and simple scripting (MAKI scripts)
      • Used an XML-based language to define the location of UI elements, similar to resource editors
    • 57. Winamp 3 skins
      • [Show Winamp]
    • 58. Sonique
      • (Another mp3 player)
      • Flash-like graphic capabilities in a skin
      • [Show Sonique]
    • 59. Skinnable Apps wrap up
      • Natural evolution of a separation between UI and underlying functionality
      • A form of end-user programming
      • Many limitations as a plug-in architecture
        • Difficult to trap events
        • Limiting even just considering UI capabilities
    • 60. Conclusions
      • Different plug-in architectures support different type of extensibility
      • Plug-in programming is very different from regular GUI programming
      • Never get a cough before you have to give a presentation
    • 61. Thanks! Good luck on homework 5!