Bug 16042 – [GTK] Eliminate webkit_init()

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Alp Toker]

webkit_init() goes against our API goals of keeping things simple and following conventions set by existing widgets. Initialisation of the WebKit framework should be done behind the scenes.

There's nothing here that can't be initialised as-needed AFAICT, except for threading, due to a bug (which I don't think has been reported yet).

webkitgtkglobal.cpp:

void webkit_init(void)
{
    WebCore::InitializeLoggingChannelsIfNecessary();

    WebCore::initializeThreading();

#if ENABLE(DATABASE)
    // FIXME: It should be possible for client applications to override this default location
    gchar* databaseDirectory = g_build_filename(g_get_user_data_dir(), "webkit", "databases", NULL);
    WebCore::DatabaseTracker::tracker().setDatabasePath(databaseDirectory);
    g_free(databaseDirectory);
#endif
}

[Juan A. Suarez]

Created attachment 17875 [details]
Move webkit initalization to WebView class initialization

This patch moves the initialization code to Gtk WebView class initialization, in a similar way as the other ports do it.

[Juan A. Suarez]

Created attachment 17889 [details]
Move webkit initalization to WebView class initialization

This patch drops webkit_init from main, which in previous patch was commented.

[Alp Toker]

(In reply to comment #2)
> Created an attachment (id=17889) [edit]
> Move webkit initalization to WebView class initialization
> 
> This patch drops webkit_init from main, which in previous patch was commented.
> 

Looks good. Two things to consider.

Do we want to keep around the entry point for a while as a g_warning() no-op? We might want to consider creating a small deprecation cycle here since the last API changes left some users upset.

Do we want to keep the static initialisation code in a private function so it can be called by other initialisers so it's easier to call when we add non-visual View/Frame classes?

Just thinking out loud. Any thoughts?

Thanks for the patch.

[Juan A. Suarez]

(In reply to comment #3)
> Do we want to keep around the entry point for a while as a g_warning() no-op?
> We might want to consider creating a small deprecation cycle here since the
> last API changes left some users upset.

Is there any "way" to put a function in deprecated mode? You're right that dropping webkit_init function from api may upset some users.

> 
> Do we want to keep the static initialisation code in a private function so it
> can be called by other initialisers so it's easier to call when we add
> non-visual View/Frame classes?

It looks good for me having a private initialization function. Mainly to init database paths, as at least in other ports it is in a different function.

[Alp Toker]

Comment on attachment 17889 [details]
Move webkit initalization to WebView class initialization

This is good, but please move the initialization function to webkitprivate.h so it can be re-used by other _class_inits if necessary.

[Xan Lopez]

Just a quick remark: AFAIK class_init can be called several times in a normal program; according to the docs when the last instance of a class is destroyed its class data is destroyed too, so the next instantiation would re-create the class and thus call class_init again. (Probably doing a testcase would be the best idea here :))

Anyway, it's probably good to ensure that the initialization will be only done the first time, and not always.

[Alp Toker]

Comment on attachment 17889 [details]
Move webkit initalization to WebView class initialization

OK with the minor changes discussed.

[Alp Toker]

Landed in r28818.