Changes between Version 1 and Version 2 of HackingGtk


Ignore:
Timestamp:
Nov 23, 2007, 8:11:11 PM (17 years ago)
Author:
alp@atoker.com
Comment:

Add WebCore and WebKit specific hacking guides

Legend:

Unmodified
Added
Removed
Modified

  • HackingGtk

    v1 v2  
    55== Code layout ==
    66
    7 The GTK+ port targets the cross-platform GLib and GTK+ APIs. This means that it can be built against any of the windowing systems supported by GTK+ and Cairo without modification -- those tested so far are X11 and DirectFB. Windows should work too, possibly needing a couple of tweaks.
     7The GTK+ port targets the cross-platform GLib and GTK+ APIs as well as related libraries. This means that it can be built against any of the windowing systems supported by GTK+ and Cairo without modification -- those tested so far are X11 and DirectFB. Windows should work too.
    88
    9 This means that developers adding code specific to a certain windowing system should make sure their changes are conditionally compiled only when that windowing system is available. This might be done at configure time or with a switch passed to the build system, or even just using the definitions provided by the gdk headers.
     9Code specific to any one backend should be conditionally compiled only when that windowing system is available. One examples of this kind of feature might be direct X11/Win32 use for plugin support. This can be done at configure time or with a switch passed to the build system, or even just using the definitions provided by the gdk headers.
    1010
    1111The main components of the port:
    … …  
    2020
    2121 * Public API: [http://trac.webkit.org/projects/webkit/browser/trunk/WebKit/gtk WebKit/gtk]
     22   * [http://trac.webkit.org/projects/webkit/browser/trunk/WebKit/gtk/Api Api] -- The actual public GObject API and header files.
     23   * [http://trac.webkit.org/projects/webkit/browser/trunk/WebKit/gtk/WebCoreSupport WebCoreSupport] -- These are conceptually partial classes for the implementations in "Api". The two might merge at some point.
    2224
    2325 * GtkLauncher (example application): [http://trac.webkit.org/projects/webkit/browser/trunk/WebKitTools/GtkLauncher WebKitTools/GtkLauncher]
    … …  
    3537 * cairo graphics SVG backend: [http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/platform/graphics/svg/cairo WebCore/platform/graphics/svg/cairo]
    3638
    37 == Current tasks (July '07) ==
     39== Working on WebCore ==
    3840
    39  * Make things work with debugging enabled (when NDEBUG is removed, assertions are triggered right now)
    40  * Fix animated GIF images -- consider using GdkPixbuf?
    41  * Continue to fix the curl backend
    42  * Start to consider consolidating the widget into a single place as the Qt port has done, and look into implementing eg. createFrame()
    43  * Look into supporting the canvas
    44  * Attempt to merge the Cairo code in the Win32 port -- the equivalent code is copy-and-pasted into the "Gdk" port in some places. This will help reduce code duplication but also help towards getting WebKit/Gdk/Gtk+ working on Windows
     41 * The GTK+ elements of WebCore follow the WebKit coding style.
    4542
     43 * There is no API stability in this layer. If an abstraction does not fit GTK+/Cairo/GStreamer/CURL concepts, feel free to seek advice on how to generalise the abstraction layer. This should not be necessary too often though.
    4644
    47 == Issues known ==
     45 * Documentation is generally avoided in favour of clear, self-explanatory code and good variable names.
    4846
    49 === CURL ===
    50  * Review and possibly integrate the [http://www.sand-labs.org/svn/trunk/BAL/Implementations/Network/CURL/ sand-labs CURL backend] code. It has a slightly different API, so needs to be back-ported, but looks like it may be more feature-complete, able to handle redirects properly etc.
    51  * The non zero select timeout feels bad. Make it possible to write a GSourceFunc to not poll the sockets and have a timeout: This can probably be done by integrating code from MIT/X11 licensed [http://atterer.net/glibcurl/ glibcurl].
    52  * Cookie handling is completely lacking as pointed out on the mailing list
    53  * Errors of curl need to be properly populated
     47== Working on the public API ==
    5448
    55 === Gtk ===
    56  * A lot of classes are not yet implemented
    57  * For painting we have some issues in regard to Expose Events and when WebKit will call paint.
     49 * Follow the precedent set by the Mac and Win ports. There is [http://developer.apple.com/documentation/Cocoa/Reference/WebKit/ObjC_classic/index.html Mac API documentation] available for reference.
    5850
    59 === Theming ===
    60  * Consider taking code directly from Mozilla's LGPL licensed Gtk+ theming backend. They deal with a lot of corner cases which don't look fun to re-implement.
    61  * Focus ring drawing
    62  * Scrollbars for PlatformScrollbar will be terrible as we need to implement a HitTest but don't know where the elements of the scrollbar hide
    63  * Native theming for text entries
    64  * Find a way to draw a GtkComboBox, at least the button part.  This is needed to implement theming of the <select> element properly.
     51 * Document new additions with [http://live.gnome.org/DocumentationProject/GtkDoc GtkDoc]. It is OK to base GTK+ API documentation on the Objective-C documentation, but remember that "the receiver" will be "@this" or similar in GTK+ terminology, and a "method" translates to a "function" etc.
     52
     53 * If you find mistakes in the Objective-C API documentation, take notes and add them in the comments of your bug report.
     54
     55 * Check function parameters with g_return_if_fail() and g_return_val_if_fail()
     56
     57 * Try to cover implement several functions at the same time to get a better understanding of how they work together and to improve consistency. This is more effective than just implementing functions and signals one by one as needed.
     58
     59 * Avoid drawing inspiration from ports other than Mac and Win, since they might have decided to follow their own interpretation. This is like going for the primary sources in a research project.
     60
     61 * If a method looks strange or out of place, '''ask awkward questions''' until someone explains why it is the way it is. The Mac port may contain deprecated/bad API that exists only for the sake of compatibility -- we want to learn form those mistakes rather than copying them.