Structure Analysis of Konqueror-Embedded
Kio
KIO is a network enabled file management class library. This library contains almost all methods you may want to use. In fact, both file manager in KDE, Konquer Browser uses KIO to provide their network enabled file management. .
Move network transparency into a library file to solve a major problem that I have encountered in KDE1.x: Applications typically rely on a running KFM to handle download tasks for them. Obviously, using a autonomous application replaces that users may not be willing to run, and that thing may collapse because some don't know.
The most concise way to use this library is through class KIO :: NetAccess (for simple synchronization access) or through class KIO :: Job (for the responsible asynchronous task). .
Synchronous transmission mode: It is for programs that require simple network applications, such as downloading a file. In most cases, synchronous transmission is already sufficient, and KionetAccess provides this support, and KionetAccess provides simple API such as: Download, Upload, RemoveTempFile. It also provides interactive ways, such as through dialog box Shows the current progress.
Asynchronous transmission mode: class KioJob is designed for advanced applications that browse a web page. In this case, we want an asynchronous way to transport.
For each protocol, such as: FTP, HTTP, SMB, POP3, IMAP4, GPHER, GZIP, TAR, etc. are all completed by independent processes, called Kioslaves. If KIO_FTP implements FTP protocol, KIO_HTTP implements HTTP protocol and many more. Using "Agreement Manager", KioJob looks up the matching Kioslave based on a given protocol, then starts it.
Second, KPART
2.1 Basic Concept of Part
The main idea of components is reused. Usually an application requires the function of another application. Although this problem can be solved by using a shared library between two applications, it will cause contradictions if an application uses another library.
In KDE, components are called Part, this and the OLE components in the MS are a concept. A part typically contains three parts: a window, function, and user interface using this feature. Application In the browser project, Part contains multiple windows (one page should be on a part, and one page may contain multiple windows), and the features provided by the Part include: page, page, redirect, redirect, Create and deletion of the window, user input processing, cut, paste, etc., while providing user interfaces such as menus, toolbars, status bars while using these features. Other applications can use this part to embed your browser window into your own application.
In KDE, in order to facilitate the existing application as a control into another application, the PART object is responsible for managing the entire application and window. The DOC-View structure similar to the MFC is also taken for each window. Therefore, when the application is embedded in another application, you only need to get the interfaces and data in Part. The response to all operations of the window is done by the Part object being embedded, and the class DOC-View structure is only responsible for displaying and saving display data.
Kpart defines a set of simple classes: Part, Plugin, Mainwindow, Part Manager. among them:
Part: is the part in KDE. To define a part, you need to provide Widget, and of course Actions that provide access to the part feature, and there is an XML file to describe the layout of Actions in the UI. Plugin: It is a small functional program that does not implement by embedding a Widget. However, the action corresponding to the application user interface is defined. It can be graphical, such as a pop-up dialog, spell check, etc. Mainwindow: It is a special KTMainWindow, which is described by an an action defined by an XML file so that it can embed the Part object by briding the XML file. Part Manager: It is an abstract class that is used to deal with activation or prohibiting part. It is only useful when it contains multiple parts in a mainwindow. 2.2 Type of Part
Three part types are defined in the PART framework of KDE. The usual class is part, which provides basic Part entries including Widget, XML, and Actions.
Read-Only Parts: This type of Part is a general framework for achieving a wide variety of viewers. A Text Viewer, a PostScript Viewer and a web browser's viewer, their common feature is that they all access a URL and in a read-only mode. In various possible cases, KDE provides transparent network access, so most KDE applications use the URL without using the file name. If the file is open directly, if the file will use the network to read it. This application can be embedded in a unified manner, and they are controlled in a consistent way. And these are not provided by a general part object.
Read-Write Parts: This type of Part is an expansion to Read-Only Part, adds a method of modifying and saving a document. This is actually applying in a PART object in a text editing type, and Koffice is also true. In this READ / WRITE framework, the other half of the network pond - reloads the document (for remote files) when saved. A Read-Write Part must also operate in a read-only manner. When KWRITE and KOFFICE are embedded in Konqueror, they can only view the documentation, but cannot be modified. More general, any Editor can be seen as a viewer.
2.3 Creating a Part
There is not much sense to understand Konqureor, slightly.
2.4 Use dynamic libraries to get part
Once you have created which Kpart above, you can embed it yourself. But let other applications get your part, you need to dynamically connect your part library. The first step is to compile your part as a shared library, which is simple.
Now your part is available in the shared library, but this is not enough. You have to provide a way to other applications to dynamically open this library and create part. This is made by using a factory, which is inherited in KlibFactory. An application will use Klibloyader to open a shared library, which is responsible for loading and opening this library and calls an initialization function -init_lib .... (). This function is implemented by your part and returns to Klibloyad, and then Klibloader can create this factory class.
Your factory class needs to implement a CREATE method, which will create your Part object. It also has a static instance (INSTANCE), you can use this instance without creating your own instance for each part. In your part object, you should call setInstance () to set this instance without having to create one yourself. Basically, what you have to do is to define a function as the entrance to the library. It requires links to avoid C naming rules in a C function. The C link means that the name and function name are consistent.
Note: KPART provides a factory base class: KPart :: Factory, which enhances KlibFactory to allow Party's father and widget's father different.
To provide better integration with Konqueror, you can provide a KParts :: browserextension for your part, defined in Kparts / BrowseRextension.h. We should remember that ReadOnlyPart has only one OpenURL (KURL) without other settings. For a full-featured browser, we need more properties, including many of the many parameters that open the URL (see Urlargs), allowing parts to store and restore their data into the historical record of forward / back, allowing Parts to come The URL display in the control address bar is requested to open the URL as a Browser as a host.
Part's developers need to define their own classes, derive from BrowseRextension, implementing the virtual method (including standard action slots). The way BrowseRextension and Parts are very simple, create browsextension as a child of Part. The host application will automatically look for it. Another aspect of Browser integration is a set of standards provided by Browser, but is implemented by Part. The following standard activity is defined by the host of Viewer:
Choose Class Activities: CUT, PASTE, COPY and other general class activities: Print, Reparseconfiguration, Refreshmimens, etc.
These viewers define these Actions named in these Action, Browser will automatically detect and connect to these slots.
BrowserHOStextension is an extension of container-class Parts, and KHTMLPART is such a Part object.
Third, DCOP
The main motivation of DCOP is the function of providing inter-KDE applications. KDE already has a simple IPC mechanism called KWMCom for communication between applications and window managers. He performs data interaction through the atom (Atom) in the X Window system. It produces many restrictions on data capacity and complexity. KDE has considers the use of CORBA solutions, but through a year attempt, they realize that CORBA's simple application, it is a large system with a big slower memory. And it doesn't have authentication.
DCOP is a simple IPC / RPC mechanism that is built on Socket operation. Support UD Socket and TCP / IP Socket. DCOP is built on the Inter Client Exchange (ICE) protocol, ICE is part of X11R6 and it is standard. DCOP is only dependent on QT.
The mode of DCOP is also very simple, and each application using DCOP is a client. They continue to interact with each other through a DCOP server. The role of Server is to distribute messages and calls to the right goals.
Both operations are possible in DCOP, "Send and forget" Messages (not blocked) and "calls" (blocking until waiting for the return). All data is serialized through the QDataStream operator in the QT object and then sent. Another IDL similar compiler (DCOPIDL and DCOPIDL2CPP) can generate stubs (stubs) and SKELETONS (base dry). A method is provided in kapplication, which is called dcopClient (), which returns a pointer to a DCOPCLIENT instance, and a client will create when the first call is called. DCOP's client has a unique identifier that is determined based on the return value of kapplication :: name (). In fact, if there is only one instance of the running program, the identity of this application is equal to Kapplication :: Name ().
You need to call DCOPCLIENT :: attach () to start DCOP communication. This will try to connect the DCOP's server. If you don't find the server, then an error will be returned, and Attach will return an error. In this case, Kapplication will receive a DCOP signal and display an error dialog.
After connecting to the server via DCOPCLIENT :: attach (), you need to register your ID to let server know. Otherwise you will be an anonymous communication. This is achieved using DCOPCLIENT :: Registeras (Const QCString & Name). AppId = client-> registeras (kapp-> name ()); you can disconnect the server with the server via dcopclient :: drop (), if you need to connect again, then you need to re-register. If you just want to change its identity, just need to re-register its ID.
KuniqueApplication will automatically register yourself. If you use KuniqueApplication, you don't have to attach or register yourself, they are already done.
For actual communications, you can use Send or Call methods, which will not be described in detail. It is necessary to introduce a new concept that DCOPOBJECT, if you want to receive data from DCOP, then you need multiple inheritance of the general class and DCOPOPOPOBJECT. DCOPOBJECT provides a very important way to pure, dcopobject :: process (), if you want to handle the received information you must implement this method. Imagine DCOPOBJECT is a series of DISPATCH agents (Agent). In the future, this part of the code will be completed by pre-compiled means.
Sometimes a component wishes to send an advertisement to other components via DCOP, but does not know which component will be interested in these notices. At this time, you need to use the broadcast method, of course, this is a very rough way. A more advanced approach will be introduced, that is, DCOP's Signal. DCOP signals and QT signals are very similar, although they still have difference. A DCOP signal can be connected to a function of a DCOP. When the signal of the DCOP is excited, the corresponding function of the DCOP will be called. They do not provide return values. The DCOP signal is generated in a DCOP object and a combination of DCOP customers (sender). It will connect to a function or another DCOP object and a combination of DCOP customers (recipient). There are two main differences between the Signal connection of DCOP and QT: Signal connection in DCOP can have anonymous sender, and a DCOP's Signal connection can be long-lasting (it does not look like a signal connection in QT. The destructor is also deleted when any party sent or received is destructed). KONQ-EMB is used a simplified DCOP solution. In this scenario, there are several parts: DCOPCLIENT, DCOPDISPATCHER, DCOPOBJECT, and Connection. DCOPDISPATCHER is a distributor that is quite a Server, DcopObject and DCOPDispatcher are in a primary process process. DCOPCLIENT runs in a child process, it and the mechanism defined by the DCOPDispatcher, communicate with the protocol and communication. DCOPCLIENT can request or report data, and find the corresponding DCOPOBJECT via Dispatcher, call its process () virtual function to process.
Fourth, Signal and SLOT mechanism in Qt
Through some simple trials and code traces, we found general QObject or your inherited simple subclass, when operating Signal and Slot, the excitation signal will fall into the SLOT function. This and generally think that Signal and Slot in Qt are contrary to the understanding of asynchronous processing.
To this end, I asked a developer of KDE once told me:
Qt is a callback system and it can be used to Simulate AsynchronousMessage Processing. In Qt Applications There IS An Event Loop That Runsand HandlesiNAls.
We did the following example. Through the following example, we can analyze that the Signal transmission of standard controls in QT is not asynchronous mechanism.
#include
#include
#include
#include
#include
#include
Class mymainwindow: public qwidget
{
Q_Object
PUBLIC:
MyMainWindow ();
protected slots:
Void slotclicked () {while (1);
Private:
Qpushbutton * b1;
Qlabel * label;
}
Mymainwindow :: mymainwindow ()
{
SetGeometry (100, 100, 200, 170);
B1 = New Qpushbutton ("quit", this);
B1-> SetGeometry (20, 20, 160, 8);
B1-> SetFont (QFont ("Times", 18, QFont :: bold); label = new qlabel (this);
Label-> SetGeometry (10, 110, 180, 50);
Label-> SetText ("Push The Button");
Label-> setAlignment (AlignCenter);
Connect (B1, Signal (Clicked ()), This, Slot (slotclicked ()));
}
#include "test.moc"
Void main (int Argc, char ** argv)
{
QAPPlication A (Argc, Argv);
MyMainWindow W;
A.SETMAINWIDGET (& W);
W.SHOW ();
a.exec ();
}
If Signal and SLOT processing inside the QT are asynchronous, the button should be recovered after pressing, and in this case, the button cannot restore the original state due to the unlimited loop of the SLOT.
Signal and Slot are just a relatable secure package (Wrapper) for callback functions. Where SLOT corresponds to the callback function, Signal is equivalent to triggering the callback function.
There is no relationship with the callback function, which is the underlying Window system message (Linux should be Xserver or WINDOW MANAGER sent?), Its corresponding concrete Member function is the process of processing for this Event. So this kind of Function is generally a process for completing the mouse, keyboard, and window events.
It's easy to get easier to start, probably Signal, Slot looks also to send a message. (From the viewpoint of the object, it is also the case, such as the object-oriented Sequence Diagram in the UML, the object is to communicate with each other, until the object mapping is classified, the message is mapped to a function).
By reading the source code of Konqueror and QT, we are more and more discovering that Qevent should be the answer we don't understand. The internal event processing inside the QT is made through qevent, and SendQEvent is asynchronous. EVENT will inspire Signal when it is incorporated into the control, and then then finds the SLOT execution of the corresponding object by looking up the registry of MetaObject. Signal and slot are the immediate function call, and there is an event's loop inside the QT.
There is also a QSIGNAL class in QT, which is a simple extension of QObject, which can send a simple signal without parameters. If you want to send a signal in a class that is not inherited from the QojBect class, you can create an internal QSIGNAL object to excitation the signal. You must additionally provide a function to this signal to a slot of an external object. That is how we implement the signal in the QMenudata class, it is not derived from qbject.
Qsignal :: Block (BOOL B): If b is true, it blocks this signal, that is, if blocksig is true, it will not process when you stimulate the signal. It is processed by the BlockSignals () function in QObject. Note QSIGNAL is inherited from qbject, and you cannot use any Qobject's function.
QACTION class abstracts a user interface behavior, which can appear on the menu or toolbar. There are two basic UI behaviors, command behavior or options. QACTION is usually shaped as a command behavior, such as opening a file. When an actual behavior will be executed, it excited the Activated () signal. Select behavior, such as drawing tools in a drawing application, often some TOOGLE behavior. A TOOGLE behavior inspires a TOOGLE () signal, whenever it changed its own state. Multiple TOOGLE behavior will be combined into a QActionGroup. A behavior may be triggered by some shortcuts. Because the shortcut is specified by Window, the application's window must be the ancestors of this behavior, and each time the creation behavior is a wise choice for children who will be the main window. The following figure is the UML map of the event structure:
V. PART structure in Konqueror-Embedded
The following UML map is a diagram of the Part structure in Konquer-Embedded.
In general, Konq-Embed is a structure of a DOC-view. It defines a VIEW class that is derived from the Qobject class. This is the view in Konq-Embed, and its view corresponding to the DOC is a class called HTMLVIEW, which is derived from the KHTMLPART class. The view class is combined in the mainwindowbase class, which is the main window of the app, inherits in QMainWindow.
The relationship between KHTMLPART and KHTMLVIEW is like a Doc-View relationship. KHTMLVIEW is in the KHTMLPART class, which is a member in the KHTMLPartPRIVATE class in KHTMLVIEW, which is initialized by khtmlpart. KHTMLVIEW inherits in QscrollView,
This way, when we create a new window in the File menu in KonQ-EMB, this view class then creates his document class (that is, khtmlpart), KHTMLPAR to create a KHTMLVIEW object, this object is actually A type of Qwidget and then set it a control for the current window activity.
As we introduced the general content of KPart, which mentioned a part if you need better integration with your browser, then it needs to implement BrowseRextension. Thus KHTMLPART also implements BrowseRextension-khtmlpartBrowseRextension, which is managed in khtmlpart and is managed by their private data classes (khtmlpartprivate). (Here, KHTMLPART and KONQUEROR are two different concepts. Konqueror is HTML rendering through khtmlpart, Konquer should be said to be khtmlpart's host case, which can also be a host of other Readonly Parts such as KWrite.) At RenderformElement: : EventFilter (), when there is a Focusout or FOCUSIN event, it gets the M_Element-> View-> Part () -> BrowseRextension () get an Extension object and then sets the focus change.
Kpart :: BrowserInterface This class provides a direct access between a KPART and host browser's housing. The outer casing should be implemented and transmitted in the KPART component embedded in the housing, by calling the setBrowserInterface method of the BrowseRextension object. This interface does not look rich, but the main function is to be implemented by the method of CallMethod, which uses the attributes in the QT to allow a Part to clearly query the housing information. So Kparts :: BrowserInterface is aggregated from browsextension. But KHTMLPART is given a power or task, which is created by KHTMLPART to create another Readonly Part object. KHTMLPART :: CreatePart () method Check the MIME type, then find the corresponding Part object name, and finally hand it over to the KlibFactory :: CreatePart () method for creation, created a PART object, KHTMLPART stores it in its internal maintenance partManager. Therefore, ReadonlyPart aggregates in PartmanAGR, PartManager is combined in KHTMLPART.
Thus KHTMLPART is also a PART object of a bag, which may contain other part objects, so it needs to implement BrowserHOStextension-khtmlpartBrowserHOStextension. When HTML displays Frame, KHTMLPART generates a KHTMLPart object for each Frame. (Maybe we should also distinguish between the difference between Container Part and Host Shell)
In View :: ChildFramenames (), get a HOSTEXTENSITION-> frames () to get a part of the list by calling kparts :: browserhostextension :: childobject (part). The name of the resulting Frame is recorded in a string list. There is also a method in view, gives the name of the frame, returns your View's pointer and a BrowseRextension pointer. In the mainwindowbase class, when you create a View, you first get the name of the incoming urlargs is not empty and the lowercase is not equal to "_blank", then search for the corresponding View pointer (through its own member function FindChildView), if Didn't find it, create a new view, finally calling View-> Document () get a part object, assigns a reference to the incoming Part pointer. When you switch the window, first turn the signal (mainly moving forward, back, stop, refresh) with the slot in the current view, and then connect the slots in the new view.
Konq-Embed defines a browserinterface, which is derived from Kparts :: BrowserInterface, which is created by View and submits to HTMLVIEW management. BrowserInterface has a gohistory slot, in the KJS HistoryFunc :: tryexecute (), getting its browserextension through Part, then get the extended Browserinterface object ifce, call ifce-> CallMethod ("Gohistory (int), - 1 Notification if the iFace calls the gohistory () function, the parameter is -1 (back). Save the object pointer with view in BrowserInterface, and gohistory () will call the gohistory () method in the view. In the History :: get () in KJS, it gets the length of history through IFACE-> Property ("HistoryLength"). GoHistory () in view from khtmlpartBrowseRextension :: ResotRestate () into STREAM, and finally enter khtmlpart :: resotrestate ().
6. Cache solution in Konq-EMB
Through the previous analysis, we can know that the authorization information and cache's cache is made by "run" in the primary process, the stand-alone slavebase process sends cache's request to dcopdispatcher, then find the corresponding DCOPOPOBJECT by DCOPDispatcher (these CacheServer is derived from DCOPOBJECT to process data (via DCOPOBJECT virtual function processing).
KHTMLPAGECACHE buffers the buffer from KIO, KHTMLPAGECACHE is stored in the main process. Mainly by kHTMLPART, add data and removal data, it is necessary to note that the khtmlpagecacheentry that is only valid only when the data read is completed. Join data and remove data requires an ID as an index value of the Dictionary in KHTMLPageCache
Cache provides buffering and loading for objects that displays the HTML page. These objects are generally style, scripts, and images. You need to use the CachedObject class to derive from the CachedObjectClient, you need to overload the three virtual functions. If a customer wants to load a pattern, images, and scripts from the web, it needs to inherit any one from the CachedObjectClient and overload three methods. DocLoader is processed for a determination document to load scripts, style single and images. It aggregates in the DocumentImpl class and creates it by it. For those requests in the buffer, create a job to read by Loader.
Loader has a Request's queue, in Loader :: Load (), create a request, then call servependingRequest (). Pending is a unresolved meaning. This function takes out a request from the header, then call KIO :: get () to create a job, connect the Job signal to your own slot, then call Scheduler :: SchedulerJob (Job) to schedule Job, put the request in loading Add to M_RequestLoading queues.
From here we can see that Page and Image are stored separately. If you have an Image of an Image in Page, then get a job from cache. If you do not have a job to create a Job to read. SSL's cache is a KSSLCERTIFICACACHE class, which maintains a certified linked list inside it. It aggregates in tcpslavebase and runs in Sun Auto. In the SLAVEBASE destructure, KSSL, KSSL's Cache entity exists in an external disk file, and perform SaveToDisk () for each additional authentication, so KSSL's Cache is shared by all grandson.
Seven, Konq-EMB runtime model
Through the overall analysis above, we can know that Konq-Emb is a multi-process model with three-layer parent-child relationship. UI, KHTMLPART (including Render, Cache, PageCache, Dom, HTML, etc.), KJS, DCOPDispatcher, SlaveInterface (slave), the main process part of DCOPOBJECTS (CACHERVER), Launcher, which runs in the main process space. The primary process has established a child process for launcher, and it is UDS communication in the main process in the main process. Launcher can create a sub-process. The relative main process is a grandson. These processes are Slave processes, where there is also a network access, which also runs in the SLAVE process. These slave processes communicate with DCOPDispatcher in the grandfather process, interact with slave, and add Cache requests to CacheServer.
8. Object-oriented JavaScript and interpretation engine
JavaScript is an object-oriented scripting language that meets the syntax of Java, interpreted by the browser. In JS, Object is one of the basic data types, and is one of the most important data types. It is more difficult to understand the prototype inheritance mechanism in JS. First we introduced the constructor in JS, for example: Function Rectangle (W, H) {this.width = W; this.Height = H;} var reccT1 = new Rectangle (10, 20); var RECT2 = New Rectangle 40, 20); This is a value implicated in implicit. There are some small differences in C . The concept of prototype is introduced in JS1.1, and each Object has a prototype object, and an Object can inherit all of its prototype Object. That is, all attributes of the prototype Object will be the properties of the instance of its constructive Object. The constructor defines the class of Object and initializes the properties of the status variable in the class, and the prototype Object is associated with the constructor. Each constructor has a Prototype's properties, which is implicitly associated with the created object when you create the constructor. For example: Function Circle (x, y, r) {this.x = x; this.y = y; this.r = r;} circle.prototype.pi = 3.14159; function circle_circumference () {Return 2 * this .pi * this.r;} circle.Prototype.circumference = circle_circumference; circle.Prototype.Area = new function ("Return this.pi * this.r * this.r;"); // In JS Function is also one It can be created. VAR C = New Circle (0.0, 1.0, 10); var p = c.Area (); var p = c.circumference (); that is, multiple classes will share the same prototype object, the properties of the class First query within a class instance, if not, query to the prototype of the class, if not, the prototype of the prototype, until the last. This forms a prototype linked list. Inherit is automatically occurred when the inheritance is in a property of the query object. . When set a property, JS does not use the prototype, which will add a new same name attribute on the instance to store the value of the settings. This method is a bit of Copy-On-Write's taste. In this way, we basically know the inheritance relationship between JS. ECMAScript defined JS specification has built-in objects: Global, Object, Function, Array, String, Boolean, Number, Math, Data, Regexp, Error, Evalerror, etc. JS is running in a Browser, requiring Browser hosts to provide a number of host objects, such as Document (is a DOM object), Window (generally set to a global object), and more.
The JS engine is a interpreter that performs JS code, which implements built-in Object type, as for external Host Object needs you to register through the APIs they provide. The DOM specification provides the binding of ECMA. We are mainly to achieve this new binding when we implement JS. KJS is a JS engine of KDE, is a self-contained system that can be independently compiled, which uses the structure of Object. Spidermonkey is a Mozilla's JS engine, which is also a self-contained system that can be independently compiled and written in C language. Spidermonkey's document is relatively rich, there is a Tang Xinhua's article on IBM China Development Website, and most of them are translated Mozilla websites JS Embeded Guide, but in the end, there is a specific instance, and there is a reference value, and for understanding JS Engine It is very helpful. Many examples in this article are also extracted from Oreilly's "JavaScript Authoritative Guide". Nine, correlation survey
Because KHTMLPART is the center of the entire program, there are many related to it, we divide these relevance Category and Level:
Deep correlation: A large number of member functions of KHTMLPART or reference to its member variables, inheritance relationship or combination. Includes KHTMLBROWSEREXTENSITION, KHTMLHOSTBROWSEREXTENSION, KHTMLVIEW, HTMLVIEW. General related: Use KHTMLPAR to function or member variables, and use concentrated, there is a general polymerization relationship. Including cache related classes, khtmlfactory, render related classes, etc., relevant classes in KIO, PARTEVENT-related classes, kJs related classes. Shallow correlation: less use of member functions or member variables of KHTMLPART, there is generally associated. Including DOM, HTML related classes
Generally, the depth is related to our need to cut off during the transplantation; some parts of the general correlation, such as KHTMLFactory, are not required, and the general related KIO part is needed to re-establish model, kJS is our transplant A focus (or rebuild model), you need to analyze the interfaces of their interaction; the shallow phase is the focus of our transplantation.
Within the khtml directory, the DOM directory implements the part of the DOM specification of Level1 and Level2. Each object of the DOM saves a pointer to its real class. Dom Core's implementation class is basically in the XML directory, the implementation class of the DOM HTML section is in the HTML directory, and the implementation class of the CSS section is in the directory of the CSS, each directory has related Parser classes and other related assistance class. The implementation class is derived from Domshared class, when the clone DOM object does not re-build the new Impl class, and the reference should be assigned. There is a reference count inside DomShared, which is 0 is released.
The basic classes in the DOM directory are basically not associated with Qt (processing some data types of the reference QT), and the correlation with KHTMLPAR is not large, mainly KHTMLPART is the friend class of these classes. DOCs and symbols in the XML directory are declared with Q_Object, with Signal and Slot members. The DOC class in the implementation class in HTML is declared in Q_Object.
Another type of object relationship is defined in the ECMA directory, and the basic correspondence of the DOM. I believe that the corresponding control interface is defined here. KJS under the upper list is the JS interpretation engine. There is no Q_Object declaration in the kJS directory.
RenderWidget under the render directory uses Q_Object to declare that the class derived from the renderwidget is Q_Object declared, which are derived from the CacheObject class. Some auxiliary classes are collected in the MISC directory.
Ten, VIEWML project research
Below is the architecture of View:
Although view is KDE1.x based on KDE1.x, some of its practices are still worth learning.
Simulated Qobject Class Implement Signal and SLOT, use STD C to implement the data container class in QT, use the FLTK to implement QT-compatible layer to use to KHTMLWIDGET, use libwww to communicate network access.
XI, PART transplant point
The problem to consider in transplantation:
Graphics platform independence, try to abstract standard interfaces, mainly event processing and rendering parts. Mastering and Function Module Extraction of Core Mechanism, try to provide as possible as possible (without reopening most of the work as Konqueror upgrades). System simulation by using Glue Layer
Part is closely related to these QT related to a lot of Signal / Slot, QEvent, QACTION, etc. For Signal and SLOT recommendation to extract Qt class libraries to implement Qobject practices, we have analyzed the mechanism issues of Signal and Slot, which is a secure Callback mechanism. For the QEVENT, the method of sending the SendEvent of QApplication requires a mechanism for event loop processing. QAction is nothing more than some messages, they can be implemented in the messaging mechanism in MiniGUI.
A bunch of assisted classes, like BrowseRextension, BrowserHostextension, BrowserInterface, and more. These have no much role for individual browser applications. If considering future component structures, it should also be abstracted.
