Changeset 64621 in webkit


Ignore:
Timestamp:
Aug 3, 2010 8:06:12 PM (14 years ago)
Author:
eric@webkit.org
Message:

2010-08-03 Noam Rosenthal <​noam.rosenthal@nokia.com>

Reviewed by Kenneth Rohde Christiansen.

[Qt] Edits to bridge documentation
​https://bugs.webkit.org/show_bug.cgi?id=43012

  • docs/qtwebkit-bridge.qdoc:
  • docs/webkitsnippets/qtwebkit_bridge_snippets.cpp: (wrapInFunction):
Location:
trunk/WebKit/qt
Files:
3 edited

Legend:

Unmodified
Added
Removed

  • trunk/WebKit/qt/ChangeLog

    r64557 r64621  
     12010-08-03  Noam Rosenthal  <noam.rosenthal@nokia.com>
     2
     3        Reviewed by Kenneth Rohde Christiansen.
     4
     5        [Qt] Edits to bridge documentation
     6        https://bugs.webkit.org/show_bug.cgi?id=43012
     7
     8        * docs/qtwebkit-bridge.qdoc:
     9        * docs/webkitsnippets/qtwebkit_bridge_snippets.cpp:
     10        (wrapInFunction):
     11
    1122010-08-03  Kim Grönholm  <kim.1.gronholm@nokia.com>
    213

  • trunk/WebKit/qt/docs/qtwebkit-bridge.qdoc

    r61684 r64621  
    88
    99    The QtWebKit bridge is a mechanism that extends WebKit's JavaScript environment to access native
    10     objects that are represented as \l{QObject}s. It takes advantage of the \l{QObject} introspection,
    11     a part of the \l{Object Model}, which makes it easy to integrate with the dynamic JavaScript environment,
    12     for example \l{QObject} properties map directly to JavaScript properties.
    13 
    14     For example, both JavaScript and QObjects have properties: a construct that represent a getter/setter
    15     pair under one name.
     10    objects represented as \l{QObject}s. It takes advantage of the \l{QObject} introspection,
     11    a part of the \l{Object Model}, which makes it easy to integrate with the dynamic JavaScript environment.
     12    For example \l{QObject} properties map directly to JavaScript properties.
    1613
    1714    \section2 Use Cases
    1815
    19     There are two main use cases for the QtWebKit bridge. Web content in a native application, and Thin Clients.
    20 
    21     \section3 Web Content in a Native Application
     16    There are two main use cases for the QtWebKit bridge: web content in native applications and thin clients.
     17
     18    \section3 Web Content in Native Applications
    2219
    2320    This is a common use case in classic Qt application, and a design pattern used by several modern
    24     applications. For example, an application that contains a media-player, playlist manager, and music store.
     21    applications like an application that contains a media-player, playlist manager, and music store.
    2522    The playlist manager is usually best authored as a classic desktop application,
    26     with the native-looking robust \l{QWidget}s helping with producing that application.
    27     The media-player control, which usually looks custom, can be written using the \l{Graphics View framework}
    28     or with in a declarative way with \l{QtDeclarative}. The music store, which shows dynamic content
    29     from the internet and gets modified rapidly, is best authored in HTML and maintained on the server.
    30 
    31     With the QtWebKit bridge, that music store component can interact with native parts of the application,
    32     for example, if a file needs to be saved to a specific location.
    33 
    34     \section3 Thin Client
    35 
    36     Another use case is using Qt as a native backend to a full web application,
    37     referred to here as a thin client. In this use-case, the entire UI is driven by
    38     HTML, JavaScript and CSS, and native Qt-based components are used to allow that application
    39     access to native features not usually exposed to the web, or to enable helper components that
    40     are best written with C++.
     23    with the native-looking robust \l{QWidget}s as the application's backbone.
     24    The media-player control usually has a custom look and feel and is best written using the \l{Graphics View framework}
     25    or \l{QtDeclarative}. The music store, which shows dynamic content
     26    from the Internet and gets modified rapidly, is best authored in HTML and maintained on the server.
     27
     28    With the QtWebKit bridge, the music store component can interact with native parts of the application,
     29    for example, when a file needs to be saved to a specific location.
     30
     31    \section3 Thin Clients
     32
     33    The use case uses Qt as a native backend of a full web application,
     34    a so-called thin client. In this use case, the entire UI is driven by
     35    HTML, JavaScript and CSS. Additionally, it uses Qt-based components to
     36    access native features usually not exposed to the web, or to enable helper
     37    components that are best written in C++.
    4138
    4239    An example for such a client is a UI for a video-on-demand service on a TV. The entire content and
    43     UI can be kept on the server, served dynamically through HTTP and rendered with WebKit, with additional
    44     native components for accessing hardware-specific features like extracting the list of images
    45     out of the video.
     40    UI can be kept on the server, served dynamically through HTTP and rendered with WebKit. Additional
     41    native components are used to access hardware-specific features like extracting a list of images
     42    out of a video stream.
    4643
    4744    \section2 Difference from Other Bridge Technologies
    4845
    49     Of course QtWebKit is not the only bridge technology out there. NPAPI, for example,
    50     is a long-time standard or web-native bridging. Due to Qt's meta-object system, full applications
    51     built partially with web-technologies are much easier to develop. NPAPI, however, is more geared
    52     towards cross-browser plugins, due to it being an accepted standard.
     46    Of course, QtWebKit is not the only bridge technology out there. NPAPI, for example,
     47    is a long-time standard for web-native bridging. Due to Qt's meta-object system, full applications
     48    leveraging web technologies are much easier to develop with the QtWebKit bridge than with NPAPI. NPAPI, however, is better
     49    for cross-browser plugins, due to it being an accepted standard.
    5350
    5451    When developing a plugin for a browser, NPAPI is recommended. When developing a full application
    55     that utilizes HTML-rendering, the QtWebKit bridge is recommended.
     52    utilizing HTML-rendering, the QtWebKit bridge is recommended.
    5653
    5754    \section2 Relationship with QtScript
    5855
    59     The QtWebKit bridge is similar to \l{QtScript}, especially to some of the features described in the
    60     \l{Making Applications Scriptable} page. However, as of Qt 4.7, full QtScript API is not supported for web applications.
    61     That is planned as an enhancement for future versions. You might notice that some of the features
     56    The QtWebKit bridge is similar to \l{QtScript}, especially for some of the features described in the
     57    \l{Making Applications Scriptable} page. However, Qt 4.7 does not provide the full QtScript API for web applications.
     58    Full support is planned for future versions. You might notice that some of the features
    6259    described here are an exact copy of the ones described in the \l{Making Applications Scriptable} page. That is because
    6360    the QtWebKit bridge is a subset of that functionality, and this page tries to capture the full
    … …  
    6663    \section1 Accessing QObjects
    6764
    68     \section2 Creating the link via QWebFrame
     65    \section2 Making QObjects known to JavaScript via QWebFrame
    6966
    7067    By default, no QObjects are accessible through the web environment, for security reasons.
    71     To enable web content access for a native QObject, the application must explicitly grant it access,
    72     using the following call:
     68    When a web application wants to access a native QObject, it must explicitly grant access
     69    to this QObject, using the following call:
    7370
    7471    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 0
    … …  
    8481    \list
    8582    \i \bold{Hybrid C++/script}: C++ application code connects a
    86     signal to a script function. For example, the script function can be
    87     a function that the user has typed in, or one that you have read from a
    88     file. This approach is useful if you have a QObject but don't want
    89     to expose the object itself to the scripting environment; you just
    90     want a script to be able to define how a signal should be reacted
    91     to, and leave it up to the C++ side of your application to establish
    92     the connection.
     83    signal to a script function. This approach is useful if you have
     84    a QObject but don't want to expose the object itself to the scripting
     85    environment. You just want to define how the script responds to a
     86    signal and leave it up to the C++ side of your application to establish
     87    the connection between the C++ signal and the JavaScript slot.
    9388
    9489    \i \bold{Hybrid script/C++}: A script can connect signals and slots
    … …  
    110105    \section3 Signal to Function Connections
    111106
    112     \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 6
    113 
    114     In this form of connection, the argument to \c{connect()} is the
    115     function to connect to the signal.
    116 
    117107    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 7
    118108
    119     The argument can be a JavaScript function, as in the above
    120     example, or it can be a QObject slot, as in
    121     the following example:
     109    The call to \c{connect()} establishes a connection between the signal
     110    \c{somethingChanged} and the slot \c{myInterestingScriptFunction}.
     111    Whenever the object \c{myObject} emits the signal \c{somethingChanged},
     112    the slot \c{myInterestingScriptFunction} gets called automatically.
     113
     114    The argument of \c{connect()} can be any JavaScript function as in the above
     115    example or a slot of a QObject as in the following example:
    122116
    123117    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 8
    124118
    125     When the argument is a QObject slot, the argument types of the
    126     signal and slot do not necessarily have to be compatible;
    127     If necessary, the QtWebKit bridge will, perform conversion of the signal
    128     arguments to match the argument types of the slot.
    129 
    130     To disconnect from a signal, you invoke the signal's
    131     \c{disconnect()} function, passing the function to disconnect
    132     as argument:
     119    When the argument is a slot of a QObject, the argument types of the
     120    signal and the slot do not have to be compatible. If possible, the QtWebKit
     121    bridge converts the signal arguments such that they match the slot argument.
     122
     123    To disconnect a slot from a signal, you call the signal's
     124    \c{disconnect()} function with the slot as its argument:
    133125
    134126    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 9
    … …  
    141133    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 10
    142134
    143     In this form of the \c{connect()} function, the first argument
    144     is the object that will be bound to the variable, \c this, when
    145     the function specified using the second argument is invoked.
    146 
    147     If you have a push button in a form, you typically want to do
    148     something involving the form in response to the button's
    149     \c{clicked} signal; passing the form as the \c this object
    150     makes sense in such a case.
     135    The call to \c{connect() establishes a connection between the signal
     136    \c{somethingChanged} and the slot \c{function}. Whenever the object
     137    \c{myObject} emits the signal \c{somethingChanged}, the slot \c{function}
     138    of the object \c{thisObject} gets called automatically. Let's illustrate
     139    this with an example.
     140
     141    If you have a push button in a form, you typically want the form
     142    to do something in response to the button's \c{clicked} signal. The
     143    call to \c{connect()} makes sure that the function \c{onClicked()} is
     144    called whenever you click on the push button, that is, whenever the
     145    the signal \c{clicked()} is emitted by \c{myButton}. The slot \c{onClicked()}
     146    prints the value of \c{x} as stored in the \c{form}.
    151147
    152148    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 11
    153149
    154     To disconnect from the signal, pass the same arguments to \c{disconnect()}:
     150    To disconnect a slot from a signal, you pass the same arguments to
     151    \c{disconnect()} as you passed to \c{connect()}. In general, this looks
     152    as follows:
    155153
    156154    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 12
    … …  
    160158    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 14
    161159
    162     This form of the \c{connect()} function requires that the first argument is
    163     the object that will be bound to the variable \c{this} when a function is
    164     invoked in response to the signal. The second argument specifies the
    165     name of a function that is connected to the signal, and this refers to a
    166     member function of the object passed as the first argument (thisObject
    167     in the above scheme).
     160    This form of the \c{connect()} function requires that the first argument \c{thisObject} is
     161    the object that will be bound to \c{this} when the function \c{functionName} is
     162    invoked in response to the signal \c{somethingChanged}. The second argument \c{functionName} specifies the
     163    name of a function that is connected to the signal. It refers to a
     164    member function of the object \c{thisObject}.
    168165
    169166    Note that the function is resolved when the connection is made, not
    … …  
    172169    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 15
    173170
    174     To disconnect from the signal, pass the same arguments to \c{disconnect()}:
     171    To disconnect from the signal, pass the same arguments to \c{disconnect()}
     172    as you passed to \c{connect}:
    175173
    176174    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 17
    … …  
    221219    \section3 Invokable Methods
    222220
    223     Both slots and signals are invokable from script by default. In addition, it's also
    224     possible to define a method that's invokable from script without it being a signal or a slot.
     221    Both slots and signals are invokable from scripts by default. In addition, it is also
     222    possible to define a method that is invokable from scripts, although the method is neither a signal nor a slot.
    225223    This is especially useful for functions with return types, as slots normally do not return anything
    226     (it would be meaningless to return values from a slot, as the connected signals don't handle the returned data).
     224    (it would be meaningless to return a value from a slot, as the connected signals cannot handle return values).
    227225    To make a non-slot method invokable, simply add the Q_INVOKABLE macro before its definition:
    228226
    … …  
    231229    \section2 Accessing Properties
    232230
    233     The properties of the QObject are available as properties
     231    The properties of a QObject are available as properties
    234232    of the corresponding JavaScript object. When you manipulate
    235233    a property in script code, the C++ get/set method for that
    … …  
    245243    \section2 Accessing Child QObjects
    246244
    247     Every named child of the QObject (that is, for which
    248     QObject::objectName() is not an empty string) is by default available as
     245    Every named child of a QObject (that is, every child for which
     246    QObject::objectName() does not return the empty string) is by default available as
    249247    a property of the JavaScript wrapper object. For example,
    250248    if you have a QDialog with a child widget whose \c{objectName} property is
    … …  
    254252    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 25
    255253
    256     Since \c{objectName} is itself a Q_PROPERTY, you can manipulate
    257     the name in script code to, for example, rename an object:
     254    Because \c{objectName} is itself a Q_PROPERTY, you can manipulate
     255    the name in script code to rename an object. For example:
    258256
    259257    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 26
    … …  
    271269
    272270    All Qt numeric data types are converted to or from a JavaScript number. These include int, short, float,
    273     double, and the porable Qt types (qreal, qint etc). A special case is \l{QChar};
    274     If a slot expects a QChar, the QtWebKit bridge would use the unicode value in case of a number,
    275     or the first character in a string.
    276 
    277     Note that non-standard (typedefed) number types are not automatically converted to
    278     or from a JavaScript number - it's advised to use standard number types for signal, slots
     271    double, and the portable Qt types (qreal, qint etc). A special case is \l{QChar}.
     272    If a slot expects a QChar, the QtWebKit bridge uses the Unicode value in case of a number and the first character in case of a string.
     273
     274    Note that non-standard (typedef'ed) number types are not automatically converted to
     275    or from a JavaScript number - we suggest to use standard number types for signals, slots
    279276    and properties.
    280277
    281278    When a non-number is passed as an argument to a method or property that expects a number,
    282     the appropriate JavaScript conversion function (parseInt / parseFloat) would be used.
     279    the appropriate JavaScript conversion function (parseInt / parseFloat) is used.
    283280
    284281    \section3 Strings
    … …  
    288285    built-in JavaScript toString method.
    289286
    290     When a QString is passed to JavaScript from a signal or a property, The QtWebKit bridge will
    291     convert it into a JavaScript string.
     287    When a QString is passed to JavaScript from a signal or a property, the QtWebKit bridge
     288    converts it into a JavaScript string.
    292289
    293290    \section3 Date & Time
    294291
    295292    Both \l{QDate}, \l{QTime} and \l{QDateTime} are automatically translated to or from the JavaScript
    296     Date object. If a number were passed as an argument to a method that expects one of the date/time
    297     types, the QtWebKit bridge would treat it as a timestamp. If a sting is passed, QtWebKit would
    298     try different Qt date parsing functions to find the right one.
     293    Date object. If a number is passed as an argument to a method that expects one of the date/time
     294    types, the QtWebKit bridge treats it as a timestamp. If a sting is passed, QtWebKit
     295    tries the different Qt date parsing functions to perform the right translation.
    299296
    300297    \section3 Regular Expressions
    301298
    302     The QtWebKit bridge would automatically convert JavaScript RegEx object to a \l{QRegExp}.
    303     If a string is passed to a method expecting a \l{QRegExp}, the string would be converted
    304     to that \l{QRegExp}.
     299    The QtWebKit bridge automatically converts a JavaScript RegEx object to a \l{QRegExp}.
     300    If a string is passed to a method expecting a \l{QRegExp}, the string is converted
     301    to a \l{QRegExp}.
    305302
    306303    \section3 Lists
    … …  
    308305    The QtWebKit bridge treats several types of lists in a special way: \l{QVariantList}, \l{QStringList},
    309306    \l{QObjectList} and \l{QList}<int>. When a slot or property expects one of those list types,
    310     the QtWebKit bridge would try to convert a JavaScript array into that type, converting each of
     307    the QtWebKit bridge tries to convert a JavaScript array into that type, converting each of
    311308    the array's elements to the single-element type of the list.
    312309
    313     The most useful type of list is perhaps \l{QVariantList}, which can be converted to from any
     310    The most useful type of list is \l{QVariantList}, which can be converted to and from any
    314311    JavaScript array.
    315312
    … …  
    318315    JavaScript compound objects, also known as JSON objects, are variables that hold a list
    319316    of key-value pairs, where all the keys are strings and the values can have any type.
    320     This translates very well to \l{QVariantMap}, which is nothing more than a \l{QMap} of \l{QString}
     317    This translates very well to \l{QVariantMap}, which is nothing more than a \l{QMap} from \l{QString}
    321318    to \l{QVariant}.
    322319
    323320    The seamless conversion between JSON objects and \l{QVariantMap} allows for a very convenient
    324     way of passing arbitrary structured data between C++ and the JavaScript environment. The native \l{QObject} has
    325     to make sure that compound values are converted to \l{QVariantMap}s and \l{QVariantList}s, and JavaScript is
     321    way of passing arbitrary structured data between C++ and the JavaScript environment. If the native \l{QObject} makes sure that compound values are converted to \l{QVariantMap}s and \l{QVariantList}s, JavaScript is
    326322    guaranteed to receive them in a meaningful way.
    327323
    … …  
    331327    \section3 QVariants
    332328
    333     When a slot or property accepts a \l{QVariant}, the QtWebKit bridge would create a \l{QVariant} that best
    334     matches the argument passed by JavaScript. A string, for example, would become a \l{QVariant} holding a \l{QString},
    335     a normal JSON object would become a \l{QVariantMap}, and a JavaScript array would become a \l{QVariantList}.
     329    When a slot or property accepts a \l{QVariant}, the QtWebKit bridge creates a \l{QVariant} that best
     330    matches the argument passed by JavaScript. A string, for example, becomes a \l{QVariant} holding a \l{QString},
     331    a normal JSON object becomes a \l{QVariantMap}, and a JavaScript array becomes a \l{QVariantList}.
    336332
    337333    Using \l{QVariant}s generously in C++ in that way makes C++ programming feel a bit more like JavaScript programming,
    338     as it adds another level of indirection. Passing \l{QVariant}s around like this q   is very flexible, as the program can figure out
    339     the type of argument in runtime just like JavaScript would do, but it also takes away from the type-safety and robust
    340     nature of C++. It's recommended to use \l{QVariant}s only for convenience high-level functions, and to keep most of your
    341     \l{QObject}s somewhat type-safe.
     334    as it adds another level of indirection. Passing \l{QVariant}s around like this    is very flexible. The program can figure out
     335    the type of argument at runtime just like JavaScript would do. But doing so also takes away the type safety and robustness of C++.
     336    We recommended to use \l{QVariant}s only for high-level functions, and to keep most of your
     337    \l{QObject}s type-safe.
    342338
    343339    \section3 QObjects
    344340
    345     A pointer to a \l{QObject} or a \l{QWidget} can be passed as payload in signals, slots and properties. That object
    346     can then be used like an object that's exposed directly; i.e. its slots can be invoked, its signals connected to etc.
     341    Pointers to a \l{QObject} or a \l{QWidget} can be used in signals, slots and properties. This object
     342    can then be used like an object that is exposed directly. Its slots can be invoked, its signals connected to, etc.
    347343    However, this functionality is fairly limited - the type used has to be \l{QObject}* or \l{QWidget}*. If the type
    348     specified is a pointer to a non-\l{QWidget} subclass of \l{QObject}, the QtWebKit bridge would not recognize it to be
     344    specified is a pointer to a non-\l{QWidget} subclass of \l{QObject}, the QtWebKit bridge does not recognize it as
    349345    a \l{QObject}.
    350346
    … …  
    359355    The QtWebKit bridge handles \l{QPixmap}s and \l{QImage}s in a special way. Since QtWebKit stores \l{QPixmap}s to
    360356    represent HTML images, \l{QPixmap}s coming from the native environment can be used directly inside WebKit.
    361     A \l{QImage} or a \l{QPixmap} coming from the Qt environment would convert to an intermediate JavaScript object,
    362     that can be represented like this:
     357    A \l{QImage} or a \l{QPixmap} coming from Qt is converted to an intermediate JavaScript object,
     358    which can be represented like this:
    363359
    364360    \snippet webkitsnippets/qtwebkit_bridge_snippets.cpp 1
    365361
    366     The JavaScript environment can then use the pixmap it gets from Qt and display it inside the HTML environment,
    367     by assigning it to an existing <img /> element using assignToHTMLImageElement. It can also use the toDataURL() function,
    368     which allows using the pixmap as the src attribute of an image or as a background-image url. Note that the toDataURL()
     362    The JavaScript environment can then use the pixmap from Qt and display it inside the HTML environment,
     363    by assigning it to an existing \c{<img>} element with \c{assignToHTMLImageElement()}. It can also use the \c{toDataURL()} function,
     364    which allows using the pixmap as the \c{src} attribute of an image or as a \c{background-image} URL. Note that the \c{toDataURL()}
    369365    function is costly and should be used with caution.
    370366
    … …  
    395391
    396392    This is specifically useful to create custom renderers or extensions to the web environment. Instead of forcing Qt
    397     to select the element, the web environment already selects the element and then send the selected element directly to Qt.
     393    to select the element, the web environment selects the element and then sends the selected element directly to Qt.
    398394
    399395    Note that \l{QWebElement}s are not thread safe - an object handling them has to live in the UI thread.
    400396
    401     \section1 Architecture issues
     397    \section1 Architecture Issues
    402398
    403399    \section2 Limiting the Scope of the Hybrid Layer
    404400
    405401    When using QtWebKit's hybrid features, it is a common pitfall to make the API exposed to JavaScript very rich and
    406     use all its features. This, however, leads to complexity and can create bugs that are hard to trace.
     402    use all its features. This, however, leads to complexity and can create bugs that are hard to find.
    407403    Instead, it is advisable to keep the hybrid layer small and manageable: create a gate only when
    408404    there's an actual need for it, i.e. there's a new native enabler that requires a direct interface
    … …  
    411407
    412408    This usually becomes more apparent when the hybrid layer can create or destroy objects, or uses
    413     signals slots or properties with a \l{QObject}* argument. It is advised to be very careful and to treat
     409    signals, slots or properties with a \l{QObject}* argument. It is advised to be very careful and to treat
    414410    an exposed \l{QObject} as a system - with careful attention to memory management and object ownership.
    415411
    416412    \section2 Internet Security
    417413
    418     When exposing native object to an open web environment, it is importwhichant to understand the security
    419     implications. Think whether the exposed object enables the web environment access to things that
    420     shouldn't be open, and whether the web content loaded by that web page comes from a trusted. In general, when
     414    When exposing native objects to an open web environment, it is important to understand the security
     415    implications. Think whether the exposed object enables the web environment access things that
     416    shouldn't be open, and whether the web content loaded by that web page comes from a trusted source. In general, when
    421417    exposing native QObjects that give the web environment access to private information or to functionality
    422418    that's potentially harmful to the client, such exposure should be balanced by limiting the web page's

  • trunk/WebKit/qt/docs/webkitsnippets/qtwebkit_bridge_snippets.cpp

    r61480 r64621  
    9696    //! [9]
    9797    //! [10]
    98     connect(thisObject, function)
     98    myQObject.somethingChanged.connect(thisObject, function)
    9999    //! [10]
    100100    //! [11]
    101     var obj = { x: 123 };
    102     var fun = function() { print(this.x); };
    103     myQObject.somethingChanged.connect(obj, fun);
     101    var form = { x: 123 };
     102    var onClicked = function() { print(this.x); };
     103    myButton.clicked.connect(form, onClicked);
    104104    //! [11]
    105105    //! [12]
    106     myQObject.somethingChanged.disconnect(obj, fun);
     106    myQObject.somethingChanged.disconnect(thisObject, function);
    107107    //! [12]
    108108    //! [13]
    … …  
    110110    //! [13]
    111111    //! [14]
    112     connect(thisObject, functionName)
     112    myQObject.somethingChanged.connect(thisObject, "functionName")
    113113    //! [14]
    114114    //! [15]
    … …  
    120120    //! [16]
    121121    //! [17]
    122     myQObject.somethingChanged.disconnect(obj, "fun");
     122    myQObject.somethingChanged.disconnect(thisObject, "functionName");
    123123    //! [17]
    124124    //! [18]
    … …  
    146146
    147147    public:
    148         Q_INVOKABLE void thisMethodIsInvokableInQtScript();
    149         void thisMethodIsNotInvokableInQtScript();
     148        Q_INVOKABLE void thisMethodIsInvokableInJavaScript();
     149        void thisMethodIsNotInvokableInJavaScript();
    150150
    151151        ...
Note: See TracChangeset for help on using the changeset viewer.