Changes between Version 23 and Version 24 of HackingGtk


Ignore:
Timestamp:
Oct 26, 2010 5:31:16 PM (13 years ago)
Author:
Martin Robinson
Comment:

Delete obsolete information and link to up to date sources

Legend:

Unmodified
Added
Removed
Modified
  • HackingGtk

    v23 v24  
    8585The strategy here is to develop a GObject-based interpretation of the Objective-C API combined with experience working with GtkTextView, GtkHtml and gtkmozembed. This allows us to benefit from the maturity of a widely-deployed API, but demands extra caution not to adopt any of the baggage or legacy that might be present for backward compatibility only. The Win port is also a useful resource but is less suitable for direct inspiration since it hasn't been deployed as a stable API yet and has a large API footprint that would be difficult to support in the long term.
    8686
    87 === WebKitWebView ===
    88 
    89 Formerly named WebKitPage (http://bugs.webkit.org/show_bug.cgi?id=15691). Name matches GtkTextView, GtkTreeView etc. on the GTK+ side and WebView in the Mac and Win ports of WebKit.
    90 
    91 === WebKitWebFrame ===
    92 
    93 Formerly WebKitFrame. Currently very similar to Mac WebFrame, this is a headless representation of a browser frame, rather than a GtkWidget like WebKitWebView.
    94 
    95 === WebKitNetworkRequest ===
    96 
    97 Very limited right now but this can be considered the beginning of a public API to access the underlying HTTP stack.
    98 
    99 === WebKitWebSettings ===
    100 
    101 The future of WebKitWebSettings is uncertain (http://bugs.webkit.org/show_bug.cgi?id=16219). We might not want to do settings like this at all.
    102 
     87For more information, check out the [http://webkitgtk.org/reference/index.html API reference] on the official WebKit GTK+ page.
    10388== The build bots ==
    10489
     
    10994== LayoutTests ==
    11095
    111 To run the layout tests you need to have built your WebKitGTK+ with the following command:
    112 
    113 {{{
    114 ./WebKitTools/Scripts/build-webkit --gtk
    115 }}}
    116 
    117 To run the tests you need to setup your environment, so that the sizes for fonts and widgets match - the render dumps are compared textually, and the sizes must match for the tests to pass. This means you need to install the Ahem true type font, and also guarantee the following output for fc-match:
    118 
    119 {{{
    120 $ fc-match Times
    121 n021003l.pfb: "Nimbus Roman No9 L" "Regular"
    122 $ fc-match Sans-Serif
    123 Vera.ttf: "Bitstream Vera Sans" "Roman"
    124 $ fc-match Serif
    125 VeraSe.ttf: "Bitstream Vera Serif" "Roman"
    126 $ fc-match Mono
    127 VeraMono.ttf: "Bitstream Vera Sans Mono" "Roman"
    128 }}}
    129 
    130 This usually means installing the gsfonts-x11 and ttf-bitstream-vera packages in a Debian system. You also need to run the tests inside an X server that has no GTK+ theme set. Xvfb is recommended. So you would do something similar to this:
    131 
    132 {{{
    133 $ Xvfb -ac :23&
    134 $ env -i DISPLAY=:23 ./WebKitTools/Scripts/run-webkit-tests --gtk --no-launch-safari
    135 }}}
    136 
    137 Never mind the 'safari' in there. It's just inheritance from the past, when Mac was the only 'port'.
     96See [http://trac.webkit.org/wiki/WebKitGtkLayoutTests WebKitGTK+ Layout Tests]
    13897
    13998== Optimization ==