<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept xml:lang="en" id="GUID-EB7F7772-1C0D-54C7-9856-AD552DF1F102"><title>Window Server Plug-in Framework Overview</title><shortdesc>The Window Server plug-in framework is a generic framework that is part of both the ScreenPlay (NGA) and non-ScreenPlay variants. The framework is used for graphic drawer plug-ins (also known as Content Rendering Plug-ins or CRPs) and render stage plug-ins. However, the APIs are different in the two architectures. Except where stated otherwise, this documentation applies to the ScreenPlay variant. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>The Window Server plug-in framework consists of APIs and Service Provider Interfaces (SPIs). An SPI differs from an API in that an API provides functionality that a developer uses, whereas an SPI defines an interface for which a developer creates a concrete implementation. </p> <p>The SPIs consist of abstract interfaces for plug-ins, such as CRPs and render stage plug-ins. Developers are expected to provide concrete implementations of these interfaces. The APIs consist of object provider interfaces that can be used by the plug-ins. </p> <p>The framework is a relatively thin wrapper around the Symbian ECOM component. It has some Window Server-specific features. For example, the plug-ins that are to be loaded are specified in the <codeph>WSINI.INI</codeph> file. </p> <p>The generic plug-in framework provides a standard mechanism for adding new types of plug-ins. The intention is that when new types of plug-in are introduced, they will use this generic plug-in framework rather than an ad hoc mechanism, leading to reduced implementation time. </p> <section><title>Window Server plug-in framework library</title> <p>The following table provides details of the DLLs that provide the plug-in framework and the library to which your code links. </p> <table id="GUID-CE1507A6-C62F-59AB-BB14-6A9447C8F2B1"><tgroup cols="3"><colspec colname="col0"/><colspec colname="col1"/><colspec colname="col2"/><thead><row><entry>DLL</entry> <entry>LIB</entry> <entry>Short description</entry> </row> </thead> <tbody><row><entry><p> <filepath>wsgraphicdrawer_nga.dll</filepath>  </p> </entry> <entry><p> <filepath>wsgraphicdrawer.lib</filepath>  </p> </entry> <entry><p>Contains the server-side base classes for Window Server plug-ins in the ScreenPlay variant. The plug-ins include graphic drawer plug-ins (which are also known as Content Rendering Plug-ins or CRPs) and render stage plug-ins. </p> </entry> </row> <row><entry><p> <filepath>wsgraphicdrawer_nonnga.dll</filepath>  </p> </entry> <entry><p> <filepath>wsgraphicdrawer.lib</filepath>  </p> </entry> <entry><p>Contains the server-side base classes for Window Server plug-ins in the non-ScreenPlay variant. The plug-ins include graphic drawer plug-ins (which are also known as Content Rendering Plug-ins or CRPs), fader plug-ins and render stage plug-ins. </p> </entry> </row> </tbody> </tgroup> </table> </section> </conbody><related-links><link href="GUID-5D81D4E2-BE8B-58CE-A745-4F044DE2FB5F.dita"><linktext>Window Server Plug-in

                Framework</linktext> </link> </related-links></concept>