Re: [platform-swt-dev] Browser WEBKIT style

[Grant Gayed <Grant_Gayed@xxxxxxxxxx>]

> have plans to create a WebKit-SWT-specific
API to allow things like
> showing a customized popup menu when clicking on an element of a page
> and such things?

There aren't plans to provide api at
this level (this would probably be covered by https://bugs.eclipse.org/bugs/show_bug.cgi?id=57477
).  That being said, functionality like this should be possible now
across all Browser implementations, with a combination of a _javascript_
listener like in http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet303.java?view=co
and a BrowserFunction that calls out to Java.  For swt to provide
the same thing using native calls would require multiple implementations
(three WebKit derivations to start, and while at it might as well do IE
and Mozilla as well).  For JS-level interactions the combination of
Browser.execute()/evaluate() and BrowserFunction should be adequate.  Perhaps
someone out there is sufficiently motivated to implement a layer that provides
a nice API and uses these under the covers.

> it too difficult to rely on the
core directly? Or maybe Safari/Chrome
> don't have an accessible core and shipping the core with SWT was too
> big?

The WebKit ports that swt builds on
top of provide a lot of value-add over what core WebKit provides.  To
duplicate their efforts would be very significant, and would outweigh the
hypothetical benefit of only having one WebKit implementation in swt.  Safari
and Chrome don't provide embeddable API, but Safari needs to be installed
to use WebKit on win32 because the Apple Application Support package that
contains Apple's WebKit implementation is not available from Apple as a
stand-alone download, but only by installing Safari (maybe some other apps
from Apple too?).  There are various sites claiming to offer the Apple
Application Support package as a stand-alone download, but it's always
suspicious when it's not available from what should be the real source.

> So, is a given version of SWT supposed
to run with future versions of
> Safari ( contrary to XULRunner which sometimes requires an SWT update
> IIRC)? Will future versions of SWT work with old versions of Safari
> (like the XULRunner implementations)?

Apple has kept its OS X port of WebKit
very stable since the beginning, so I believe that their win32 port should
be equally stable, and SWT should continue to work with future WebKit releases
on win32 without change.  Similarly, future SWT releases should not
make changes that break it when used with WebKit versions that work today
(if you ever find such a case then please log a bug!).

> what was the motivation to implement
it? As far as I see, there was already a
> common implementation (XULRunner) in addition to the default one (IE,
> Firefox/WebKitGTK, Safari). Or is it to allow testing web developments
> on multiple runtimes in future versions of the IDE?

Yes, the primary motive was to allow
someone on win32 to test their web app on a WebKit-based Browser.

Grant

Christopher Deckers <chrriis@xxxxxxxxx>
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx

01/31/2011 01:06 PM

Please respond to
"Eclipse Platform SWT component developers list."        <platform-swt-dev@xxxxxxxxxxx>

To	"Eclipse Platform SWT component developers list." <platform-swt-dev@xxxxxxxxxxx>
cc
Subject	Re: [platform-swt-dev] Browser WEBKIT style

Hi Grant,

Thanks a lot for the information, it is very valuable as usual!

> The cross-platform API exposed by WebKit is much more core than the
one from Gecko
> so consequently there isn't something comparable to JavaXPCOM available.

I see. Since you control the implementation for all platforms, do you
have plans to create a WebKit-SWT-specific API to allow things like
showing a customized popup menu when clicking on an element of a page
and such things? Are there no efforts to create a common API which to
rally?

> Chrome also uses WebKit, but it implements its own port on top which
is different from the win32 port provided by Apple

If I understand correctly, WebKit is composed of a core, on which
implementors (Safari, Chrome) build a port. SWT is a layer on top of
an implementation (win32 relies on the win32 Safari port, etc).
I don't know the details, so pardon me if my question is silly :)  Was
it too difficult to rely on the core directly? Or maybe Safari/Chrome
don't have an accessible core and shipping the core with SWT was too
big?

> To do so would require Chrome's WebKit port to commit to providing
a stable API for embedders

So, is a given version of SWT supposed to run with future versions of
Safari ( contrary to XULRunner which sometimes requires an SWT update
IIRC)? Will future versions of SWT work with old versions of Safari
(like the XULRunner implementations)?

I also have another question: considering that there is no new
functionality in this implementation (no object model, etc) and that
you had to create a new version for each platform, what was the
motivation to implement it? As far as I see, there was already a
common implementation (XULRunner) in addition to the default one (IE,
Firefox/WebKitGTK, Safari). Or is it to allow testing web developments
on multiple runtimes in future versions of the IDE?

Cheers,
-Christopher
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev