XPIDL
xpidl is an interface description language used to specify xpcom interface classes. interface description languages (idl) are used to describe interfaces in a language- and machine-independent way. idls make it possible to define interfaces which can then be processed by tools to autogenerate language-dependent interface specifications. xpidl is expected to converge towards webidl in the future. note: starting in gecko 9.0, the older xpidl utility, which was previously used to generate c++ header files, typelib information, and so forth has been replaced with pyxpidl in the gecko sdk. pyxpidl has been used for some time now, but now the older tool has been fully retired. ...
...e language-dependent interface specifications. xpidl is expected to converge towards webidl in the future. note: starting in gecko 9.0, the older xpidl utility, which was previously used to generate c++ header files, typelib information, and so forth has been replaced with pyxpidl in the gecko sdk. pyxpidl has been used for some time now, but now the older tool has been fully retired. writing xpidl interface files xpidl closely resembles omg idl, with extended syntax to handle iids and additional types. some examples are in the xpcom/base and xpcom/ds directories of the mozilla tree. ...
...e c++ header files, typelib information, and so forth has been replaced with pyxpidl in the gecko sdk. pyxpidl has been used for some time now, but now the older tool has been fully retired. writing xpidl interface files xpidl closely resembles omg idl, with extended syntax to handle iids and additional types. some examples are in the xpcom/base and xpcom/ds directories of the mozilla tree. xpidl:syntax (now up to date again) xpidl syntax (out of date) xpidl author's guide (not as out of date) explanation of idl semantics a full guide to the syntax can be found at xpidl:syntax, which is written in an abnf form. an xpidl file is essentially just a series of declarations. at the top level, we can define typedefs, native types, or interfaces. interfaces may furthermore contain typedefs...
...And 9 more matches

nsXPIDLCString
class declaration nstxpidlstring extends nststring such that: (1) mdata can be null (2) objects of this type can be automatically cast to |const chart*| (3) getter_copies method is supported to adopt data allocated with ns_alloc, such as "out string" parameters in xpidl. ...
... class declaration nstxpidlstring extends nststring such that: (1) mdata can be null (2) objects of this type can be automatically cast to |const chart*| (3) getter_copies method is supported to adopt data allocated with ns_alloc, such as "out string" parameters in xpidl. ...
... class declaration nstxpidlstring extends nststring such that: (1) mdata can be null (2) objects of this type can be automatically cast to |const chart*| (3) getter_copies method is supported to adopt data allocated with ns_alloc, such as "out string" parameters in xpidl. ...
...And 6 more matches

XPIDL Syntax
simplifications, conventions and notation the syntax is specified according to abnf as defined by rfc 5234, although a few productions use prose for clarity of understanding. ...
...simplifications, conventions and notation the syntax is specified according to abnf as defined by rfc 5234, although a few productions use prose for clarity of understanding. ...
...simplifications, conventions and notation the syntax is specified according to abnf as defined by rfc 5234, although a few productions use prose for clarity of understanding. ...
...And 6 more matches

nsXPIDLString
class declaration nstxpidlstring extends nststring such that: (1) mdata can be null (2) objects of this type can be automatically cast to |const chart*| (3) getter_copies method is supported to adopt data allocated with ns_alloc, such as "out string" parameters in xpidl. ...
... class declaration nstxpidlstring extends nststring such that: (1) mdata can be null (2) objects of this type can be automatically cast to |const chart*| (3) getter_copies method is supported to adopt data allocated with ns_alloc, such as "out string" parameters in xpidl. ...
... class declaration nstxpidlstring extends nststring such that: (1) mdata can be null (2) objects of this type can be automatically cast to |const chart*| (3) getter_copies method is supported to adopt data allocated with ns_alloc, such as "out string" parameters in xpidl. ...
...And 5 more matches

pyxpidl
the pyxpidl tool suite has been built to replace the older xpidl tool which, in the past, was used to turn xpidl files into c++ headers and xpcom typelibs (xpt files). the newer utility has the advantage of not needing any code to be compiled in order to use it, and let us remove a bunch of old code from the tree. pyxpidl has been in use for a while, but replaced xpidl in the gecko sdk starting in gecko 9.0. using pyxpidl pyxpidl is in the sdk in the sdkdir/sdk/bin/ directory. unlike xpidl, which combined all the functions into a single utility, pyxpidl is comprised of two utilities: header.py, which generates c++ headers from idl, and typelib.py, which generates xpt files. pyxpidl requires a directory to cache certain information in. you can use a temporary directory or the curren...
... or the current directory or whatever works best for you. ...
...urrent directory or whatever works best for you. ...
...And 4 more matches

xpidl
xpidl is a tool for generating xpcom interface information, based on xpidl interface description files. it generates: c++ header files (.h), with a commented template for full c++ implementation of the interface xpconnect typelib files (.xpt), with runtime type information to dynamically call xpcom objects through xpconnect note: starting in gecko 9.0, xpidl has been replaced with pyxpidl in the gecko sdk. pyxpidl has been used for some time now, but now this older tool has been fully retired. xpidl is based on the libidl idl compiler from the gnome project. the libidl compiler depends on glib, also from the gnome project. the xpidl compiler is now part of the build process, allowing us to generate headers used by the xpcom components. please check the build documentation for f...
..., but now this older tool has been fully retired. xpidl is based on the libidl idl compiler from the gnome project. the libidl compiler depends on glib, also from the gnome project. the xpidl compiler is now part of the build process, allowing us to generate headers used by the xpcom components. please check the build documentation for further information on where to get libidl and glib. using xpidl to add an idl file to the build, use the xpidlsrcs makefile variable. ...
...iler depends on glib, also from the gnome project. the xpidl compiler is now part of the build process, allowing us to generate headers used by the xpcom components. please check the build documentation for further information on where to get libidl and glib. using xpidl to add an idl file to the build, use the xpidlsrcs makefile variable. ...
... the xpidl compiler is now part of the build process, allowing us to generate headers used by the xpcom components. please check the build documentation for further information on where to get libidl and glib. using xpidl to add an idl file to the build, use the xpidlsrcs makefile variable. for testing purposes, or one-off interface compilation, xpidl can be run from the command line: usage: ./xpidl -m mode [-w] [-v] [-t version number] [-d filename.pp] [-i path] [-o basename | -e filename.ext] filename.idl -a emit annotations to typelib -w turn on warnings (recommended) -v verbose mode (nyi) -t create a typelib of a specific version number -i add entry to start of include path for ``#include "nsithing.idl" -o use basename (e.g. ``/tmp/nsit...

Introduction to XPCOM for the DOM
interface, and you don't have to care if the implementation of the interface (the concrete class) changes. xpcom pushes this concept to the extreme. pure virtual methods are declared with the following syntax: virtual nsresult functionfoo() = 0; an interface is thus simply a c++ class where all the member functions are declared as pure virtual functions. an interface can also be defined using xpidl. this is described in section 1.e, "how to add an interface". since an interface doesn't have any implementation, it has to be implemented by a non-abstract class -- a concrete class. if the interface is called nsifoo and the class is called nsfoo, we say that "nsfoo implements nsifoo", or that "nsfoo inherits from nsifoo". the c++ code is the following: class nsfoo : public nsifoo for those ...
...face introduction the purpose of this tutorial is to describe the process of adding a new interface to the dom and then implementing it. a good understanding of the previous sections is preferred to understand this tutorial. you could want to add a new interface for several reasons, like the addition of a new dom object, or to respect an eventual "interface freeze". first we will take a look at xpidl and how it can help you define interfaces. next we will describe the build system, makefiles, etc... and finally, we will look at the implementation of our new interface through the creation of an nsidomfabian interface (fabian is my first name ;-). xpidl xpidl stands for cross-platform interface definition language. instead of coding interfaces directly in c++ , one can use xpidl. it simplifie...
...mplifies greatly the task of defining interfaces, and offers some interesting features, like automatic generation of documentation, and xpt generation. the first thing to do is to decide what our interface, nsidomfabian, will do. for the purpose of this document, i have chosen to implement a new html interface called nsidomfabian. it will be implemented by the class nshtmldocument. the syntax of xpidl is straightforward: #include "domstubs.idl"; [scriptable, uuid(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)] interface nsidomfabian : nsisupports { void fabian(); readonly attribute boolean neat; }; this is the definition of the nsidomfabian interface. the uuid of the interface is a unique identifier. every interface needs one. you can generate them using guidgen on windows, or by...
...And 10 more matches

Starting WebLock
nterface for the weblock component must answer is: how should weblock look to the outside world? what, in other words, is the interaction of clients with the weblock component? in this section, we enumerate the basic functionality the component should expose and create the single interface that organizes and provides this functionality. instead of starting with the implementation, developers use xpidl (see xpidl and type libraries for more information about xpidl) to define the interface to the component: how the functionality should be organized, expressed, and exposed to its clients. in general, the weblock service interface needs to include the following functionality: lock - enable web locking so that any browser in the gecko application is restricted to the white list of website domai...
...he interface for the weblock component in this way. for example, addsite is supposed to add the current url to the white list, but is the url an input parameter to the method, is it the topmost web page in the gecko application, or is it something more random-a url picked from global history or that's been given context in some other way? as a strongly typed and implementation-agnostic language, xpidl requires that you be quite specific about the apis, the list of parameters, their order, and their types. xpidl requires that you spell it all out, in other words. and it's this formality that makes the interfaces in xpcom effective contracts between services and clients. the next section shows the interface of the weblock component, iweblock, in xpidl. once the interface has been described in t...
...quires that you be quite specific about the apis, the list of parameters, their order, and their types. xpidl requires that you spell it all out, in other words. and it's this formality that makes the interfaces in xpcom effective contracts between services and clients. the next section shows the interface of the weblock component, iweblock, in xpidl. once the interface has been described in the xpidl language, the interface file can be used to generate the header files needed for the implementation code, the binary type library files that let you use the interface of the weblock component from javascript, and even broken linkjavadoc style html documentation. ...
...And 9 more matches

How to build an XPCOM component in JavaScript
aces and components. you can download an old version of xpcomviewer that works with firefox 1.5 from mozdev mirrors. if an interface exists that meets your needs, then you do not need to write an idl, or compile a typelib, and may skip to the next section. if you don't find a suitable pre-existing interface, then you must define your own. xpcom uses a dialect of idl to define interfaces, called xpidl. here's the xpidl definition for our helloworld component: helloworld.idl #include "nsisupports.idl" [scriptable, uuid(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)] interface nsihelloworld : nsisupports { string hello(); }; note that you must generate a new uuid for each xpcom component that you create. see generating guids for more information. compiling the typelib your interface definition m...
...ed into a binary format (xpt) in order to be registered and used within mozilla applications. the compilation can be done using the gecko sdk. you can learn how to get mac, linux, and windows versions of the gecko sdk by reading the article gecko sdk. for code outside the tree note: on windows if you download the gecko sdk without the whole build tree, you will be missing some required dlls for xpidl.exe and it will run with no errors but not do anything. to fix this download the mozilla build tools for windows and copy the dlls from windows\bin\x86 within the zip into the bin directory of the gecko sdk. note: the mac version of the sdk provided for download is powerpc-only. if you need an intel version, you'll need to compile it yourself as described on that page. execute this command to c...
... windows and copy the dlls from windows\bin\x86 within the zip into the bin directory of the gecko sdk. note: the mac version of the sdk provided for download is powerpc-only. if you need an intel version, you'll need to compile it yourself as described on that page. execute this command to compile the typelib. here, {sdk_dir} is the directory in which you unpacked the gecko sdk. {sdk_dir}/bin/xpidl -m typelib -w -v -i {sdk_dir}/idl -e helloworld.xpt helloworld.idl note: on windows you must use forward slashes for the include path. note: (the -i flag is an uppercase i, not a lowercase l.) this will create the typelib file helloworld.xpt in the current working directory. for a new component in firefox/thunderbird/b2g if you are adding a new feature to applications in the mozilla-central...
...And 3 more matches

Gecko SDK
be accessed from xul using javascript. note that in order to develop such components, you do not need the full sources of e.g. firefox, since you do not access parts of the front end from within a component. furthermore, since a component contains basic functionality, it is intended to run with every product of the mozilla platform. therefore it makes no sense to use a particular product to build general functionality. that's the reason why the gecko sdk was devised. do not confuse the gecko/xulrunner sdk with xulrunner itself. ...
...unner itself. the gecko sdk is a collection of header files and tools used to develop general xpcom components which add functionality to the existing platform, whereas xulrunner is a framework which can be used to run standalone or embedded applications based on the mozilla framework. the gecko sdk contains all of the necessary tools and headers for making scriptable npapi plugins including the xpidl compiler/linker and the latest npapi.h. get the sdk updates there is no need to download or rebuild the gecko sdk corresponding to security updates of mozilla (e.g., mozilla 1.7.3) since the headers and glue libs in the gecko sdk are usually not changed as a result of security updates. you do have to get and distribute the newest gecko components (gklayout.dll etc.), though. downloading for ...
...download download download download download the sdk is not officially released for other platforms; if you need it, you will probably need to build it yourself. note: you can subscribe to a calendar of the firefox release schedule. also, you can view the schedule on the web. unpack the sdk tarball to some suitable location. ...
...And 2 more matches

An Overview of XPCOM
isupports interface is that you can support other interfaces as they are introduced. as we'll show when we discuss nsiclassinfo, some factories support querying information about the underlying implementation, such as what language the object is written in, interfaces that the object supports, etc. this kind of "future-proofing" is a key advantage that comes along with deriving from nsisupports. ...
...oofing" is a key advantage that comes along with deriving from nsisupports. xpidl and type libraries an easy and powerful way to define an interface - indeed, a requirement for defining interfaces in a cross-platform, language neutral development environment - is to use an interface definition language (idl). xpcom uses its own variant of the corba omg interface definition language (idl) called xpidl, which allows you to specify methods, attributes and constants of a given interface, and also to define interface inheritance. there are some drawbacks to defining your interface using xpidl. there is no support for multiple inheritance, for one thing. ...
...ion language (idl) called xpidl, which allows you to specify methods, attributes and constants of a given interface, and also to define interface inheritance. there are some drawbacks to defining your interface using xpidl. there is no support for multiple inheritance, for one thing. if you define a new interface, it cannot derive from more than one interface. another limitation of interfaces in xpidl is that method names must be unique. you can not have two methods with the same name that take different parameters, and the workaround - having multiple function names - isn't pretty: void foowithint(in int x); void foowithstring(in string x); void foowithuri(in nsiuri x); however, these shortcomings pale in comparison to the functionality gained by using xpidl. ...
...And 2 more matches

Setting up the Gecko SDK
public idl files exported by the module. the includes directory contains c++ header files used by your component. xpcom exports a number of binaries that should be mentioned at this point. the table below refers to the windows file names for the executables. application name description of functionality regxpcom.exe registers or unregisters components with xpcom xpidl.exe generates typelib and c++ headers from xpidl xpt_dump.exe prints out information about a given typelib xpt_link.exe combines multiple typelibs into a single typelib library name description of functionality xpcomglue.lib xpcom glue library to be used by xpcom components. building a microsoft visual cpp project once you set up t...
...dows\v7.0\lib;c:\program files (x86)\microsoft visual studio 9.0\vc\lib;d:\projects\xulrunner-sdk\lib this tells the linker where the default libraries to bind to are. this allows you to created the component without sending any extra dlls set path=%path%;d:\projects\xulrunner-sdk\sdk\bin;d:\projects\xulrunner-sdk\bin this tells the command prompt where to find the gecko tools, importantly (xpidl, regxpcom, and gmake). building the sample built sample in d:\projects\sample the idl this step is fairly straight forward. first create the idl file. ispecialthing.idl #include "nsisupports.idl" [scriptable, uuid(263ed1ba-5cc1-11db-9673-00e08161165f)] interface ispecialthing : nsisupports { attribute astring name; long add(in long a, in long b); }; next is to build the .h file to ...
...sample the idl this step is fairly straight forward. first create the idl file. ispecialthing.idl #include "nsisupports.idl" [scriptable, uuid(263ed1ba-5cc1-11db-9673-00e08161165f)] interface ispecialthing : nsisupports { attribute astring name; long add(in long a, in long b); }; next is to build the .h file to compile against and the .xpt for gecko to understand your new interface. xpidl -m header ispecialthing.idl xpidl -m typelib ispecialthing.idl the code add the main code, the real work horse. cspecialthing.h #ifndef __specialthing_impl_h__ #define __specialthing_impl_h__ #include "ispecialthing.h" #include "nsstringapi.h" #define specialthing_contractid "@starkravingfinkle.org/specialthing;1" #define specialthing_classname "specialthing" #define specialthing_cid { 0x2...
...And 2 more matches

Creating custom Firefox extensions with the Mozilla build system - Archive of obsolete content
de gets loaded more than once into memory, and the code won't be available from javascript or other non-c++ languages) and encourage the use of xpcom wherever possible. the makefile in the public/ directory should follow this model: depth = ../../.. topsrcdir = @top_srcdir@ srcdir = @srcdir@ vpath = @srcdir@ include $(depth)/config/autoconf.mk module = myextension xpidl_module = myextension xpi_name = myextension exports = \ myheader.h \ $(null) xpidlsrcs = \ myifirstcomponent.idl \ myisecondcomponent.idl \ $(null) include $(topsrcdir)/config/rules.mk xpidl_module is the name of the generated xpt file that contains type information about your idl interfaces. if you have multiple modules, make absolutely sure that you use a different value fo...
...otherwise the first module's xpt file will be overwritten by the second and you'll get ns_error_xpc_bad_iid errors when you try to access its idl interfaces from your code. ...
...idl_module for each one. otherwise the first module's xpt file will be overwritten by the second and you'll get ns_error_xpc_bad_iid errors when you try to access its idl interfaces from your code. the files under exports are copied directly to the /mozilla/$(moz_objdir)/dist/include/ directory and are thus accessible from other modules (the value of moz_objdir is defined in /mozilla/.mozconfig). xpidlsrcs are run through the idl processor, and the generated c++ headers are copied into the same include directory. in addition, an xpt (type library) file is generated and placed in the components/ subdirectory of your extension. source files now it's time to create the makefile and source files in the src/ subdirectory. if you're implementing interfaces that you've described using id...
...le. every makefile that generates anything should define the xpi_name variable to make sure generated files go into your extension and not into the global components/ directory. in fact, just define this in every makefile to be safe. you can use the same module in both base/ and advanced/ so that all the generated include files go into the same directory, but make sure that you don't use the same xpidl_module in the two public/ directories or one of the component type libraries (i.e. xpt files) will overwrite the other one and all hell will break loose. each module must also have a different value for the library_name variable. this is the name of the generated dynamic library, so if we call the libraries "mybase" and "myadvanced", we'll end up with mybase.dll and myadvanced.dll (on wind...

nsAdoptingCString
take the value of what's given, and make what's given forget its value. note that this class violates constness in a few places. ...
... methods constructors void nsadoptingcstring() - source void nsadoptingcstring(char*, pruint32) - source parameters char* str pruint32 length void nsadoptingcstring(const nsadoptingcstring&) - source parameters nsadoptingcstring& str operator= nsadoptingcstring& operator=(const nsadoptingcstring&) - source parameters nsadoptingcs...
...embers no public members. ...
...ods constructors void nsadoptingcstring() - source void nsadoptingcstring(char*, pruint32) - source parameters char* str pruint32 length void nsadoptingcstring(const nsadoptingcstring&) - source parameters nsadoptingcstring& str operator= nsadoptingcstring& operator=(const nsadoptingcstring&) - source parameters nsadoptingcstring& str nsxpidlcstring& operator=(const nsxpidlcstring&) - source parameters nsxpidlcstring& str nscstring& operator=(const nscstring&) - source parameters nscstring& str nsacstring_internal& operator=(char) - source parameters char c nsacstring_internal& operator=(const char*) - source parameters char* data nsacstring_internal& operator=(const nsacstring_internal&) - source parameters nsacstring_internal& str nsa...

nsAdoptingString
take the value of what's given, and make what's given forget its value. note that this class violates constness in a few places. ...
... methods constructors void nsadoptingstring() - source void nsadoptingstring(prunichar*, pruint32) - source parameters prunichar* str pruint32 length void nsadoptingstring(const nsadoptingstring&) - source parameters nsadoptingstring& str operator= nsadoptingstring& operator=(const nsadoptingstring&) - source parameters nsadopting...
...bers no public members. ...
...ds constructors void nsadoptingstring() - source void nsadoptingstring(prunichar*, pruint32) - source parameters prunichar* str pruint32 length void nsadoptingstring(const nsadoptingstring&) - source parameters nsadoptingstring& str operator= nsadoptingstring& operator=(const nsadoptingstring&) - source parameters nsadoptingstring& str nsxpidlstring& operator=(const nsxpidlstring&) - source parameters nsxpidlstring& str nsstring& operator=(const nsstring&) - source parameters nsstring& str nsastring_internal& operator=(prunichar) - source parameters prunichar c nsastring_internal& operator=(const prunichar*) - source parameters prunichar* data nsastring_internal& operator=(const nsastring_internal&) - source parameters nsastring_internal& ...