[webkit-dev] Moving forward with WebKit/GTK+

[Gustavo Noronha Silva]

Hello there,

For some time now I've been worried by the lack of progress of
WebKit/GTK+ where API is concerned. I am aware that loads of work have
been going into improving the engine backends and frontends, including
many bug fixes, but real-world adoption for many applications is
hindered by lack of features being accessible through a public API.

While using Epiphany/Devhelp/Liferea, for instance, which already have
semi-functional WebKit/GTK+ ports one isn't able to middle-click links
to open them in new tabs, which is the kind of feature a user would
quickly perceive as basic, and missing. Some other features are
currently being implemented by hacks (mis-)using the already exposed
API, or the JavaScriptCore API.

It happens that quite a bit of missing API bits are already written and
posted to WebKit's bugzilla:

[gtk] Implement WebPolicyDelegate methods
https://bugs.webkit.org/show_bug.cgi?id=16562
[GTK] Improve frameloader signals
https://bugs.webkit.org/show_bug.cgi?id=17066
[Gtk] Implement WebKitWebDownload
https://bugs.webkit.org/show_bug.cgi?id=16826
[gtk] implements FrameLoaderClient::dispatchDidChangeLocationWithinPage
https://bugs.webkit.org/show_bug.cgi?id=20306
[Curl] Rewrite of curl backend to run in event loop
https://bugs.webkit.org/show_bug.cgi?id=17972
[GTK] ChromeClient::createWindow and friends need to be implemented
https://bugs.webkit.org/show_bug.cgi?id=19130
[Gtk] Enable WebInspector in the Gtk port
https://bugs.webkit.org/show_bug.cgi?id=19392

And some others. Some of these patches go back to the begining of the
year. Some even have formal reviewers comments, but invariably all of
them lack recent official comments or action.

The fact that WebKit/GTK+ doesn't go forward is starting to harm its
momentum in the GNOME community, from my point of view - Epiphany is
already having to decide if they take back the decision to move from
Gecko to WebKit, and contributors don't really have a lot of motivation
to keep contributing with many-months-old patches sitting in the
bugzilla (myself included).

We tried to get together last week to try and push forward on the review
and landing of some of the patches, but we end up only having an
informal review of one patch by contributors of WebKit/GTK+ and related
projects; lacking a formal reviewer in the second meeting there was not
much we could have done.

Notice that I'm not questioning the work done by Alp, I think he's done
a great amount of good work, but having only him as a formal reviewer is
a clear bottleneck in my opinion. I believe we need to fix this if we
want to see WebKit/GTK+ going forward.

I can think of various options; forking the tree and trying to advance
it outside of the main repository being the one I like the least. What I
think could help and not be so destructive as a fork is to have more
reviewers. From looking at history and by hanging around since around
April, I believe Christian Dywan, is a very good candidate.

I don't see GNOME adopting WebKit, or an Epiphany release that is really
based in WebKit happening if we don't fix this issue, and I would like
to hear people's opinion on how we can do it.

Thanks!

* DISCLAIMER: I am not speaking for the GNOME project, nor for its
release team (though I'm CC'ing Vincent Untz so that he is aware of this
discussion), nor for the Epiphany developers. I speak only for myself.

-- 
Gustavo Noronha Silva <[EMAIL PROTECTED]>
GNOME contributor: http://www.gnome.org/

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] PLATFORM(CHROMIUM), etc.

[Darin Fisher]

As some of you may have noticed, there is now a PLATFORM(CHROMIUM) define
that is being used in WebKit.  I thought it might be helpful to describe
what it is and explain why it exists.

PLATFORM(CHROMIUM) corresponds to the WebKit porting layer implementation
used by the Chromium (aka Google Chrome) browser.  While Chromium runs on
Windows (and soon Mac and Linux), it turns out that it puts an interesting
set of constraints on WebKit that cause the existing WebKit ports to be
mostly unusable by Chromium.  The main constraint is the Chromium sandbox,
in which WebKit is run.  This technology does things like block access to
the filesystem, registry, sockets, and desktop (aka GUI system).

This latter constraint is the most impactful one since it means that HWNDs
associated with the desktop cannot be accessed or modified by the sandbox.
 This ends up having huge implications for not only rendering but also popup
menus, context menus, drag-n-drop, clipboard operations, theming, cursors,
and event processing.  All of those things need to be handled in the main
process that does have access to the desktop.

So, while we started out with PLATFORM(WIN) as the basis of our port, we
ended up touching and heavily modifying just about every file in the
WebCore/platform/win/ directory.  In the process, we also built-up
essentially a toolkit within the Chromium source tree on which our port was
then based.

In hindsight, it is obvious to me that what we were building was really just
a new WebKit port, and so we moved all of our work to the PLATFORM(CHROMIUM)
define.  We are in the process of upstreaming that port, starting with a
sprinkling of PLATFORM(CHROMIUM) defines in WebCore that eliminates
modifications to shared files.  In the coming months, we plan to upstream
the rest of our port.  We haven't been able to do so yet because we are
trying to move ourselves to tip-of-tree WebKit first.

In the long run, I suspect that there will be some commonalities between
PLATFORM(CHROMIUM) and the other ports that we can work to eliminate.  I
look forward to getting to that point.  For now, the plan is to upstream
PLATFORM(CHROMIUM) as a complete entity.

Other defines:

The Chromium build of WebKit also includes some other changes to WebKit
beyond just a new porting layer.  I thought I should talk about those too.

USE(V8)
  This corresponds obviously to the V8
JavaScript engine used by Chromium.  In
our tree, we have a liberal
sprinkling of these defines.  Instead of upstreaming those wholesale, we are
working to build thin abstractions in WebCore that hide the underlying JSC
and V8 data types and method calls.  In some cases, this ends up simplifying
some existing JSC-using code, and I hope that this will be well received.

USE(SKIA)
  Chromium uses the Skia graphics
engineto
perform 2D rendering on Windows and Linux.  (On Mac, Chromium is using
CG.)  Our intent is to upstream a platform/graphics layer built on top of
Skia that will be generally useful to ports.  For those who are unaware of
Skia, it is the graphics engine developed for the Android mobile OS.

USE(GOOGLEURL)
  As has been discussed at length in another thread, Chromium also uses the
GoogleURL  library for URL parsing and
canonicalization.  We implemented the KURL interface on top of GoogleURL so
that we could have consistent URL parsing and canonicalization throughout
the entire product.  This was done to ensure correctness, which helps
avoid/eliminate classical security bugs, and help achieve good performance
when converting between KURL and GURL.

To be clear:  Our intent is to minimize the occurrence of any of these new
#ifdefs in the shared, cross-platform WebKit code, so that we minimize any
maintenance burden related to these new defines.

I'm very excited to finally have the chance to share our work with the
WebKit community.  I really look forward to having Chromium live at
tip-of-tree WebKit, so that we can work alongside you on more interesting
improvements and innovations to the core rendering engine.

Regards,
-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Focus moving in webkit

[jligman]

Hi, 

This document describes a focus point algorithm for directional tab navigation.
http://www.w3.org/TR/WICD/

Look at the distance function http://www.w3.org/TR/WICD/#nav-distance-fkt for 
an explanation of how to choose the next focusable element.

Joe Ligman


-Original Message-
>From: xfdbse <[EMAIL PROTECTED]>
>Sent: Oct 28, 2008 9:10 AM
>To: webkit-dev 
>Subject: Re: [webkit-dev] Focus moving in webkit
>
>thanks Marco Barisione, this is helpful.
>
>On Tue, 2008-10-28 at 20:34 +0800, xfdbse wrote:
>> I need to be able to use Up, Down, Left and Rigth key to move.
>> Now i can simulation Left or Right key to a (shift+)TAB key, and the
>> foucs also can be moved, but that not my want.
>
>I had similar problems for the device I was working on, for just using
>alternative keys for already provided features you can just modify the
>keyboard event, it's hackish but works well.
>See key_event_cb in
>http://git.collabora.co.uk/?p=user/bari/webkit-demo.git;a=blob;f=src/webkit-demo.c;h=b2ac77b51605e0b5c72fc446d59c8b74392b5432;hb=HEAD
>
>> as you know , when use TAB key to move focus , the foucs chain looks
>> like a "double Linked List" .
>> I need the focus can be moved to the any of four directions via Up or
>> Down or Left or Right key
>> [although i know the Up or Down key used to scroll default].
>
>I implemented it but it's unfinished see
>https://bugs.webkit.org/show_bug.cgi?id=18662
>
>-- 
>Marco Barisione
>
>___
>webkit-dev mailing list
>webkit-dev@lists.webkit.org
>http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>___
>webkit-dev mailing list
>webkit-dev@lists.webkit.org
>http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Focus moving in webkit

[xfdbse]

thanks Marco Barisione, this is helpful.

On Tue, 2008-10-28 at 20:34 +0800, xfdbse wrote:
> I need to be able to use Up, Down, Left and Rigth key to move.
> Now i can simulation Left or Right key to a (shift+)TAB key, and the
> foucs also can be moved, but that not my want.

I had similar problems for the device I was working on, for just using
alternative keys for already provided features you can just modify the
keyboard event, it's hackish but works well.
See key_event_cb in
http://git.collabora.co.uk/?p=user/bari/webkit-demo.git;a=blob;f=src/webkit-demo.c;h=b2ac77b51605e0b5c72fc446d59c8b74392b5432;hb=HEAD

> as you know , when use TAB key to move focus , the foucs chain looks
> like a "double Linked List" .
> I need the focus can be moved to the any of four directions via Up or
> Down or Left or Right key
> [although i know the Up or Down key used to scroll default].

I implemented it but it's unfinished see
https://bugs.webkit.org/show_bug.cgi?id=18662

-- 
Marco Barisione

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Focus moving in webkit

[Marco Barisione]

On Tue, 2008-10-28 at 20:34 +0800, xfdbse wrote:
> I need to be able to use Up, Down, Left and Rigth key to move.
> Now i can simulation Left or Right key to a (shift+)TAB key, and the
> foucs also can be moved, but that not my want.

I had similar problems for the device I was working on, for just using 
alternative keys for already provided features you can just modify the keyboard 
event, it's hackish but works well.
See key_event_cb in 
http://git.collabora.co.uk/?p=user/bari/webkit-demo.git;a=blob;f=src/webkit-demo.c;h=b2ac77b51605e0b5c72fc446d59c8b74392b5432;hb=HEAD

> as you know , when use TAB key to move focus , the foucs chain looks
> like a "double Linked List" .
> I need the focus can be moved to the any of four directions via Up or
> Down or Left or Right key
> [although i know the Up or Down key used to scroll default].

I implemented it but it's unfinished see
https://bugs.webkit.org/show_bug.cgi?id=18662

-- 
Marco Barisione

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Focus moving in webkit

[xfdbse]

hi, all

I'm trying to work with gth GTK+WebKit to to rendering for my
application.But, i'm having some prolems.

Unlike the majority of users, I dont't need WebKit to move focus with
TAB key.
I need to be able to use Up, Down, Left and Rigth key to move.
Now i can simulation Left or Right key to a (shift+)TAB key, and the
foucs also can be moved, but that not my want.

as you know , when use TAB key to move focus , the foucs chain looks
like a "double Linked List" .
I need the focus can be moved to the any of four directions via Up or
Down or Left or Right key
[although i know the Up or Down key used to scroll default].

Is it can be implemented ? if can , does anyone have any pointers for
implement ?

Thanks in advance,

PS: my embedded device's "keyboard" dons't have TAB key, let along MOUSE.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev