Tagged: Qt Toggle Comment Threads | Keyboard Shortcuts

  • Andre Pareis 18:15 on 22.04.2010 Permalink | Reply
    Tags: , Qt,   

    Why I completely dropped Qt and QtWebKit from my Hybrid App 

    In my recent articles I described certain aspects related to the use of QtWebKit in a hybrid C++ application. In the meantime, it turned out that Qt and QtWebKit are not such a good bet as I thought they would be at the beginning. Here’s why:

    Apple

    First and foremost, the most interesting question in a hybrid app written in C++ is: where do you want it to run? In my case, it is on Mac OS X in the first place, then on Windows and very likely also on Apple’s iPhone or iPad. However, this puts me in a situation where I have to decide which subset of these platforms I support primarily and which ones secondarily as there is no such thing as a common layer to access all of them from a single code base. It is either a combination of Mac OS X and Windows via the Qt port or a combination of Mac OS X and iPad/iPhone that can go as the primary target.

    For a certain time, I concentrated on the first combination as shown above while hoping that time works for me and somebody ports Qt to the iPhone, and there already is a project for that at http://www.qt-iphone.com/Introduction.html. But, in the meantime, Apple introduced iPhone OS 4.0 and *bam* there will never be such a thing, because http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler “and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)”, a rule introduced by Apple which is actually targeted against Adobe and its Flash technology but will also affect Qt, especially because that comes from Nokia, another one of Apple’s (future arch) rivals. This means that Qt can never be the common layer on all of my targeted platforms. Given that, and the fact I target Mac OS X first, Windows second, and that I also tend to shift Windows one step further down and promote the iPad version instead which completely changes the porting picture:

    This looks much cleaner now as it provides unified, access to all Apple platforms. For Windows and Android Google Chromium is a good choice.

    But what about Qt in general?

    Qt / Nokia

    The first part was the rational part, here comes the emotional one:

    In the recent weeks I had enough time to dive into the details of Qt in all aspects. Its visual quality, its API quality, its implementation quality and the quality and structure of their development process. My conclusion from that is that it is the wrong way of doing things as evaluated from a broader perspective.

    What is very important in a visual app is visual quality. Qt does a good job in replicating functionality of controls on each addressed platform. But, it can never, by its nature, take care about the special controls certain platforms offer because then it wouldn’t be cross-platform any more. Qt certainly has to focus on the lowest common denominator across all supported platforms. By driving the GUI via Qt controls, an application loses the capability to provide the eye-candy to the platform user like he is used to. The most prominent example of this is Google Maps which is based on Qt and which totally lacks platform L&F on the Mac up to a degree where it certainly loses style. In Google Maps this is not so important as interaction with the Earth requires a special user interface anyway and the rest of the app is unimportant, but it shows how difficult it is even for Google to provide attractive visual quality on the platform. Gaining access to the platform specialities is difficult as everything is hidden by Qt in private implementations. You have no chance to do “that special thing”.

    Qt has a comprehensive “fat” API that consumes everything from all platforms and which has to take care about the specialities on all platforms, which is of course its nature but which is also very difficult to maintain and to improve over years. Development of Qt is distributed across Europe with Nokia focussing on minimizing cost not maximizing quality. Their development centers are mostly in cheaper parts of Europe and they try to cooperate with educational institutions to bring the costs down. This might be a legacy from Trolltech but is still in place and shows that quality is not their first concern.

    So far I have touched Qt releases 4.5, 4.6 and 4.7 and came across older API documentations. From there I can tell that many things they have done are not very well and strategically thought out. They introduced too many APIs doing similar things and deprecating previous ones (QML, QtQuick, Scripting with QtScript and in QtWebKit, Qt3 vs. Qt4, QGraphicsScene, QItemView, QtDesigner, QtCreator). To me this is too much feature driven and dictated by the progress of other market players. Then I saw these super new technologies contrasted by very basic demo videos in YouTube showing excitement over very basic features which is not very professional – you can check out their channel on http://www.youtube.com/user/QtStudios to get an idea. What I want as a consumer of platform technology building a commercial grade application is that the selected platform is very stable and well thought out. But there is just too much noise coming from Qt and to make matters worse, none of the new features really feels final, it feels more like work in progress and you can never know how long something survives. Last not least, one day down the road Nokia might become a rival again to Apple just as relevant as Google now is. Economically speaking, Nokia already is, but Apple sees Google as its main competitor, not Microsoft and not Nokia. They are just not in the same technology league any more. Apple and Google have the brains now.

    Don’t get me wrong, the Qt guys are doing a good job and they surely do it with a lot of enthusiasm, all I want to say is that Qt is just not the best bet in a commercial hybrid application. That is why I gave up on it.

     
    • Ariya 03:54 on 26.04.2010 Permalink | Reply

      Just because Google Earth is written in Qt and does not have the Mac L&F, you are too quick to conclude that all Qt-based application “loses the capability to provide the eye-candy to the platform”. It’s Google Earth issue, it has nothing to do with Qt. For example, check http://doc.trolltech.com/qq/qq23-layouts.html where special attentions are given so that even the widgets margins and spacings match to those of the native Aqua.

      For “Development of Qt is distributed across Europe”, where did you get this fact? Last time I checked the Qt developers are mostly in Oslo, Berlin, and Brisbane.

      Some further comments on Qt from you are more subjective and hence I will not comment on it, unless you can show more substantial examples, like those of “deprecating previous ones”.

      Also, judging a framework from the reaction of its YouTube channel users is likely a hit-and-miss. You should check Qt Labs instead (and its archive) for a better peek on what happens inside the Qt kitchen.

      • apareis 04:02 on 27.04.2010 Permalink | Reply

        Ariya, thanks for your comment and my apology for being so emotional, but the decision was not an easy one. And there are of course rational and irrational aspects to a decision. We are still people ;)

        You are right, it might actually be possible to create a Qt app with L&F close to the platform standard, with some extra effort, as you already documented with that link. The question is though: at what price? I’m sure Qt does not offer the very special Mac widget types out of the box, so you would have to reprogram them, but these are the ones that make up the platform eye candy. In case of Google Earth you can argue that indeed Google is to blame, but what you then actually say is that Google should create a special Mac OS X version and a special Windows version and a special XYZ version even if they are all Qt based, and then the whole Qt based approach becomes questionable as it moves away from the cross-platform paradigm. Then you might as well just program against the native platform toolkits at perhaps similar costs but with the benefit of real platform nativity. Surely everything can be done, but everything also has a price tag. BTW, do you actually know at least a good example of a well-done Qt application with a decent Mac OS X GUI? I couldn’t find one…

        IMO, Trolltech’s development structure was absolutely appropriate when it was Trolltech, given that most of Qt is open-source and needs community knowledge, marketing and development. That is why Trolltech took the distributed approach and it was fine, but from Nokia I would expect a more headquartered approach in order increase productivity in one of its key products. Don’t get me wrong, they can do what they want, the decision is on my side. Do I trust them enough to base an applications architecture on their product? I don’t, and that’s what my post was about.

        In Qt4 they introduced a whole bunch of new APIs, and even in the subsequent minor versions things have been added quite frequently. The thing is, in a project you program against what’s there, and not against what might come, because you don’t know that. Their approach should be: Do it right from start, especially in a highly dependent environment like Qt. If I make a decision towards Qt today then I must be prepared that they will change things like they did in the past. There will be for instance a QtWebKit 2.0 coming soon introducing perhaps again a different or extended API and QtWebKit will be spun off from Qt completely. These expected changes are simply a project risk, even if they are benefits, but you have to deal with them because you want the functionality, so you end up living in the lifecycle of Qt.That can be ok, but you need to be aware of it.

        You got me not quite right with the videos. I wasn’t referring to the YouTube users, I was referring to the content of the videos. If you take this one for example http://www.youtube.com/user/QtStudios#p/u/12/sQnb7g_jSM4 this tells me that they are excited over very basic (and ugly) things which isn’t quite what I would expect from Nokia. Or this one here: http://www.youtube.com/user/QtStudios#p/u/13/ubW3GM9NzS4 it should be quite clear that long running tasks must be done in a different thread. Those things are just basics and shouldn’t be shown in an official video channel because that leaves room for interpretation where they actually stand.

        • Nitin 14:00 on 07.06.2010 Permalink

          Do you have any example, where such an app was created without involving Qt or any other UI toolkit, but just WebKit?

        • apareis 15:03 on 07.06.2010 Permalink

          No, and I don’t think there is any. I think that is because it seems to be a very expensive approach:

          1) the WebKit build process: All current ports are part of the WebKit build process. You would need to spend a considerable amount of effort on integrating into the WebKit build or to integrate the WebKit build into your own build. Qt has done the latter, and that could be a blueprint for you.

          2) WebKit interaction with the platform: WebKit needs to interact with the platform in many ways: e.g., for networking, drawing, getting user input etc. – those things all need to be provided to WebKit from your app.

          3) code integration: each WebKit wrapper adds code to the WebKit codebase, controlled with #ifdefs, in many cases just a pointer or a conversion function from the wrapper’s string type and such. You would need to do that as well whereas it might be very hard to maintain your extensions outside of the original code base as you still want to consume changes from WebKit downstream. You might be able to do that with git merge. And to create a new port for your app inside the WebKit repository should not be an easy one for administrative or political reasons at WebKit.org.

          That is why it seems to be so much easier to start with an already wrapped WebKit. I’m using Apple’s WebKit framework now. I could also have used Chromium instead but I would lose the iPhone/iPad support so I decided to stick with Apple and since they are the inventor of WebKit they aren’t the worst bet as I think they still set the pace for the other ports and they provide a very powerful integration between the JavaScript engine and the Objective-C platform.

      • MySchizoBuddy 17:12 on 25.11.2010 Permalink | Reply

        Snow leopard widgets differ slightly from the ones in QT. QT widgets are from the older version of mac.

    • Nitin 14:31 on 17.06.2010 Permalink | Reply

      apareis :
      No, and I don’t think there is any. I think that is because it seems to be a very expensive approach:
      1) the WebKit build process: All current ports are part of the WebKit build process. You would need to spend a considerable amount of effort on integrating into the WebKit build or to integrate the WebKit build into your own build. Qt has done the latter, and that could be a blueprint for you.
      2) WebKit interaction with the platform: WebKit needs to interact with the platform in many ways: e.g., for networking, drawing, getting user input etc. – those things all need to be provided to WebKit from your app.
      3) code integration: each WebKit wrapper adds code to the WebKit codebase, controlled with #ifdefs, in many cases just a pointer or a conversion function from the wrapper’s string type and such. You would need to do that as well whereas it might be very hard to maintain your extensions outside of the original code base as you still want to consume changes from WebKit downstream. You might be able to do that with git merge. And to create a new port for your app inside the WebKit repository should not be an easy one for administrative or political reasons at WebKit.org.
      That is why it seems to be so much easier to start with an already wrapped WebKit. I’m using Apple’s WebKit framework now. I could also have used Chromium instead but I would lose the iPhone/iPad support so I decided to stick with Apple and since they are the inventor of WebKit they aren’t the worst bet as I think they still set the pace for the other ports and they provide a very powerful integration between the JavaScript engine and the Objective-C platform.

      Thanks for providing more insight. But if I have existing Hybrid apps developed on Qt-WebKit, and now want to change to Android-WebKit, whether the HTML, CSS, JS code can be used as it is?
      I understand that the C++ code to interface with JS environment would have to be changed. Whats your opinion on this?

  • Andre Pareis 14:29 on 23.03.2010 Permalink | Reply
    Tags: , Qt,   

    Accessing the Original WebKit API in QtWebKit Hybrid Apps 

    Everybody wraps WebKit

    For each and every port of WebKit, be it Safari, Chrome, QtWebkit, there is always a wrapper around the WebKit object model. These wrappers function as language mappers, e.g., in case of Safari C++ API is mapped to Objective-C, and as a simplification layer around the complex WebKit API. The first case makes total sense, as no developer familiar with Cocoa and Objective-C will like to take an excursion (back) to C++. On the other hand, the Chrome port as well as the Qt port expose a C++ API towards their developers and completely hide the WebKit API despite that this is also already written in C++. Within the C++ universe, I do not understand why the original WebKit API is such a bad bet and must be hidden under all circumstances (I derive this from the fact that everybody hides it)? Is it really that evil?

    WebKit API is very stable as it is a reflection of HTML and XML and all the things used in the browser for years and which do rarely change, so a dependency should be acceptable. The only benefit is that the Qt developer works solely with the Qt API or the Chromium developer with a Chromium API. This is ok in case of very simple integration with WebKit, like displaying some external web content in an otherwise traditional application or when implementing a browser. But not in a hybrid application! In a hybrid application I want much more control over the internals of the browser. I do not consider it evil. I consider it as a very nice work horse doing most of the rendering and layout work. I want to reference DOM elements from my application and I want the DOM to interact with my application. I want to replace the excessive use of JavaScript found in Web 2.0 apps with excessive C++ – I do not want JavaScript in a hybrid app, I want C++ only!

    In case of QtWebKit, how hard is to get access to the original WebKit API? It is very hard, as the necessary headers are all eliminated from the QtWebKit API and all WebKit symbols are local in the compiled DLL or OS X framework However, I have taken the pain and hacked me into it. The steps required to expose the WebCore API via QtWebKit are:

    Get the source tree from Qt git

    You will need to build from source. So, get it from http://qt.gitorious.org/qt and switch to the desired branch or tag.

    Configure Qt just as normal

    configure it but do not run make now!

    Adjust the compiler flags for WebCore

    run the following commands in the source tree

    sed -i -e 's/-fvisibility=hidden//g' src/3rdparty/webkit/{Web,JavaScript}Core/Makefile.*
    sed -i -e 's/-fvisibility-inlines-hidden//g' src/3rdparty/webkit/{Web,JavaScript}Core/Makefile.*

    (or change these the Makfiles manually) This will compile WebCore in way to expose all internal symbols later in the DLL or framework.

    Gain access to the WebKit API

    In src/3rdparty/webkit/WebKit/qt/Api/qwebelement.h make QWebElement::m_element public

    This is just one way to do it (see later for an alternative)

    Build Qt

    Now run the normal make; make install

    Add WebKit header files and defines to your .pro file

    The application code needs to include the WebCore header files.

    DEFINES += QT_SHARED ...
    release:DEFINES += NDEBUG
    INCLUDEPATH += /Users/andre/src/qt/git/src/3rdparty/webkit/WebCore/bridge/qt \
        /Users/andre/src/qt/git/src/3rdparty/webkit/WebCore/page/qt \
        ...

    This is a very shortened version to save space here. See the full set of defines in this file: myapp.pri

    The order is important. Replace /Users/andre/src/qt/git with the home of your Qt source tree. Some defines are very important and some might be just optional, I just took all of them from the effective compile command when Qt was built.

    Include WebCore headers in application code

    #include <WebCore/html/HTMLElement.h>
    #include <WebCore/platform/text/PlatformString.h>
    #include <WebCore/platform/text/CString.h>
    #include <WebCore/svg/SVGElement.h>
    ...

    Alternative access to QWebElement::m_element

    Instead of changing the visibility of the “m_element” member from private to public, it would also be possible to use a fake subclass in the application code with a public member m_element like here:

    class HackWebElement: public QWebElement {
    public:
    WebCore::HTMLElement *m_element;
    };

    and then gain access to it by down-casting a QWebElement to a HackWebElement:

    QWebElement webElement = ...;
    HackWebElement *hwe = (HackWebElement*)&webElement;
    // now we can access hwe->m_element

    You can also use your preferred method to access a private member in C++ ;)

    Using the WebKit API

    Now I can do fancy stuff with the WebKit API. Here is an example where I create an SVG element programmatically, i.e., without the need to have WebKit parse some HTML (or XML in this case):

    WebCore::QualifiedName svg("svg", "svg", "http://www.w3.org/2000/svg");
    RefPtr<WebCore::SVGElement> nel = WebCore::SVGElement::create(svg, hel->document());
    WebCore::String s = nel->tagName();
    debug(string(s.utf8().data()));
    if(nel) {
        debug("it's a WebCore::SVGElement!!!");
    }

    Conclusion

    So far, I have only gained initial access to the internal browser DOM as a first step. This way I can create DOM elements programmatically. In the future, I will experiment with event handlers on DOM objects written in C++ in order handle all UI events in the C++ part of my application. This will reduce the browser part to act as a pure layout and rendering engine which I think should be its sole role in a hybrid application.

    Regarding the little “hacky” approach I can say that there is only one place on the whole application code where access to WebKit is gained. This can be in the document, in the frame, or like here in the general element. From then on, no further hacks are required, it is just used and QtWebKit is not needed any more.

    I would also wish that in ports like QtWebKit the WebCore API is preserved and exposed to the application developer. I think there are 2 aspects in a WebKit port: One is the physical rendering and display and the other one is the kind how WebKit embeds into the application and is access. Both concerns should be considered separately and I want to be free to consume only the first one and live with the original in the latter one.

     
    • Nelson Neves 18:21 on 13.08.2010 Permalink | Reply

      Hi,

      first of all thank you for your excellent article, been searching for this information for a while and finally found it! I’ve noticed that you’ve dropped this solution, but I’m still interested to know if it is possible to use QtWebKit into a C++ hybrid application for HTML rendering functionality? My goal is to have an windows win32 c++ application that will have a HTML code composer/editor to generate Template Documents in HTML. For that I will need to have an internal HTML rendering engine, but the compiler that I currently use doesn’t provide one and there is no 3rd party component available for that!

      Should I continue my quest or is this impossible ? Any other suggestions ?

      Regards.

    • Andre Pareis 19:19 on 13.08.2010 Permalink | Reply

      Hi Nelson, I dropped Qt out of the landscape only because QtWebKit would never make it to Apple’s AppStore, but for the task that you’re describing with a clear platform target, Qt is a very good starting point. Qt apps look usually good on Windows. For the HTML rendering part, you couldn’t find something better than WebKit. You can consume WebKit in various incarnations, be it as QtWebKit or Chromium or others. If you need Qt’s signal/slots and you are already familiar with Qt you could go on with QtWebKit (without my hack) if you don’t need signal/slots, then Chromium might be worth a try, as with Google backing it might not be the worst bet. For your task, I guess you will create the HTML in partial or complete tree form, which you throw at the renderer, in this case, if you have a model of the HTML elements in your app, then you can use QWebElement, which is quite generic and in contrast to my hacked approach drops node type information. Regards, Andre

    • dumkycat 21:06 on 07.09.2011 Permalink | Reply

      Hi Andre,
      Thanks for the great effort on this.
      What do you think about using only the WebCore/websockets part as a native C++ WebSocket client?
      I haven’t seen any such implementations (the closest being the C libwebsockets, but I’m having a hard time using that with MinGW and wrapping it as a lib for Qt).

      Regards.

    • Tim 23:59 on 14.03.2012 Permalink | Reply

      Hi Andre,

      Helpful post – are the SED commands still relevant for 4.8.0? First of all the WebKit source has moved to a child ‘source’ directory, and since I can’t follow exactly what they are modifying could you perhaps provide more details?

      • Andre Pareis 00:16 on 15.03.2012 Permalink | Reply

        Well the thing is you just need to remove the “-fvisibility=hidden” flags from the makefiles. Otherwise the API will not be exposed outside of the dynamic libs. I have not tested this with any other Qt version than 4.7 but the procedure should be similar, perhaps you need to apply to different folders like you said. You can also change the Makefiles manually if you want. Just remove all those “-fvisibility=hidden” and “-fvisibility-inlines-hidden” flags. That’s what the SED command does on all the Makefiles it finds in the specified paths.

    • Tim 10:12 on 27.03.2012 Permalink | Reply

      Hi thanks for reply, I did read up on SED and figured out that is what those commands were doing.

      I’m compiling on Windows with MSVC 2010 and the resulting makefiles do not have these flags, I decided they must be relevant to GCC/MINGW compilers only?

      These issue is I have around 32 unresolved externals from JSCore when compiling my QtWebKit based project and including all the headers (modified to suit new directory structure).
      If I link against JSCore.lib, I then get duplicate symbol errors.
      I couldn’t see any declarations on the relevant methods that were different from any other method.
      My C++ skills are pretty basic so I’ve hit my limit on what to try.

      I’ve posted on QTCentre and Qt-Project, and no-one has responded.

      Now I’m modifying QtWebKit to do what I need but that is far from ideal (I don’t mind sharing those changes so happy to use LGPL).

      Might have to pay a Qt consultancy for some answers…

      • Andre Pareis 01:54 on 02.04.2012 Permalink | Reply

        Tim, well, from what I read here http://stackoverflow.com/questions/225432/export-all-symbols-when-creating-a-dll it seems to be very complicated to export ALL symbols from the DLLs. I have no idea into what type of libraries QtWebKit compiles under MSVC but I guess it must be some dynamic lib in order to be LGPL compliant. You could try to compile with mingw gcc if possible, then you’d have the options described by me. According to the SO posts, it seems to be hard to export all those symbols via MSVC. But there seems to be the possibility to export at least some of them (the ones you would actually need) using the “module definition file”, see http://msdn.microsoft.com/en-us/library/28d6s79h(VS.80).aspx This is really all greek to me as I have no experience in Windows land. From your forum post it looks like you’re trying to achieve something really cool! But hacking WebKit is really something only few people care about. I can only wish you good luck!

  • Andre Pareis 17:11 on 18.02.2010 Permalink | Reply
    Tags: , Qt,   

    Embedding 2D Drawing Objects in QWebView 

    One question not so easily answered is how to display high-frequently updated dynamic content in a QWebView. QWebView is a great tool to build hybrid web applications in C++. But because it is basically only a port of WebKit and Qt tries to wrap and encapsulate as much as possible, it is also only a plain web browser, just capable of displaying content that comes in HTML form. What if you want to display content within a web page like a stock chart or even a video…?

    The options WebKit browsers offer are basically:

    • <object>, , <applet>: they each require you to implement a specific API and in case of applet even a different programming language
    • html 5.0 canvas: this is interesting, however, it requires JavaScript to program against it which might be to slow due to frequent parsing; it would be much more interesting if a QWebElement style wrapper would be available for drawing directly from C++
    • http://code.google.com/p/nativeclient/ is very interesting in normal browsers, but not in a hybrid application, as it is just another form of the <object> tag

    This is why I have been thinking about a different approach, which is closer to the machine’s (i.e., Qt’s) drawing and came up with this idea:

    Here we place a special, empty <div> in the document which can later be accessed by it’s ID using a QWebElement. We overwrite the QWebView::render() method and check if the region overlaps our dynamic content as specified by the QWebElement::geometry() data. The actual dynamic content can for instance be pre-rendered into an internal buffer, which we can use later as the source of a pixel copy operation towards the QWebKit paint device. Whenever our dynamic content changes, we can force a repaint via QWebView::repaint() exactly on the region that has changed.

    Architecture-wise this just means that the main presentation layer of the hybrid app is not accessed in an outbound fashion only. I have no problem with that, as long as the dynamic content can be displayed and the module doing that can later be replaced with some less “hacked” approach…

    03/05/2010 Update: HTML 5.0 Canvas is working in QWebView. I don’t know to what exact extent but some initial drawing tests completed successfully.

     
  • Andre Pareis 10:54 on 09.02.2010 Permalink | Reply
    Tags: , Qt,   

    Alternative Hybrid Application Architecture 

    In my recent article (Not So Easy) Hybrid Applications with Qt, WebKit and JavaScriptCore I reflected my opinion on the problems associated with the current Qt scripting APIs QtScript and WebKit Script. I’d like to depict the differences between both again:

    QtScript and QtWebKit both use the same JavaScriptCore but from different code copies and by wrapping them both with completely different APIs. In the meantime, I have also crosscheck current status at Qt and Nokia’s scripting plans. There are two separate issue tracking databases, one at Nokia for Qt development in general and one at webkit.org tracking the Qt WebKit port progress. Here are the 2 relevant entries:

    I left my comment on the first one as I am still afraid that the Qt developers might come up with even a 3rd API. If that 3rd API is a unified API which can be used for QtSCript as well as in QWebKit scripting then it’d be fine. Given the comment I received from Kent on the first one, I hope for the best.

    Alternatives
    So far on that, but I want to focus now on the alternatives to the QWebKit based approach to building hybrid – i.e., Web enabled – applications in C++. First of all, WebKit in itself is an outstanding HTML rendering engine, both in performance and portability, both of which features I wouldn’t want to lose. That’s why I seek a solution based on WebKit, which could look like in this diagram:

    The first and most important change is that whilst WebKit is still in it, it is not wrapped by Qt any more. Using the WebKit API directly, I would have access to the complete publicly available functionality in WebKit via e.g. HTMLElement and HTMLFrame classes. This would be to a great advantage. On the con side, I would lose Qt’s additional features from the wrapper classes, but I think they weren’t that many so that should be no big deal. Most of the customization would have been done using overridden event handling functions of the QWebView anyway and not via signals/slots as there aren’t many of them available (yet).

    However, there are 2 big question marks associated with this architectorial picture:

    1. How can WebKit be used in a standalone way?
    2. Could I get rid of Qt completely then?

    Q1 is not easily answered. If you look at the WebKit project structure you will find that it’s very much interwoven with the different ports like Safari or Chrome at the source code level. Port specific functions are partially included in the kernel and the same or more applies to the build process. WebKit is not a library that you can just consume. All ports are centrally built on WebKit’s environment and good builds are consumed by the browser vendors as a whole including the vendor specific extensions to whatever extend they want those to have public. You can get an impression here: WebKit Buildbot: Waterfall Display To make it worse, the whole WebCore engine is nearly completely undocumented in the source code. Only some public introductory documents are available in their Wiki or perhaps something more advanced on the Chromium Homepage. But nonetheless, a port should be possible, though with quite some effort, in a way to render to the underlying OS’s platform Grahics2D subsystem.

    Although I am miles aways from making any achievement on this I have a better picture on the answers to question #2:

    Qt’s feature rich functionality provides an experience to the C++ application developer which is at about the same level as the Java runtime library is to the Java developer. Which means: it will be hard to replace.

    In the picture above I have created two possible scenarios for the replacement of certain aspects of Qt my application is making use of. It will – though not effortlessly – be possible to continue living without Qt either by consuming some functional equivalent from boost or by implementing a proprietary replacement. I have mixed feelings about boost, even though I consider it the right approach to utilize templates to be as syntactically clean as possible in C++, this excessive use of templates does not really lead to intuitively readable code which makes me reluctant and I tend, given the meta-driven approach I am implementing anyway, to replace of the Qt functionality by proprietary code making use of my meta level elements.

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: