Re: [webkit-dev] Curses port?

[Alp Toker]

On 19/01/2014 18:51, Shea Levy wrote:

Hi Alp,

On Sun, Jan 19, 2014 at 06:43:10PM +, Alp Toker wrote:

On 19/01/2014 18:34, Shea Levy wrote:

Hi all,

I'd like to have a browser that can be used from the terminal but
actually supports modern HTML, js, etc. to the extent that is reasonable
for a console. It seems no such browser currently exists, so I was
thinking about trying to port webkit to use a curses backend. Is such a
thing a reasonable project? Ideally I'd just be able to plug some
rendering logic on top of an unmodified webkit core...

HI Shea,

It is possible as a full-blown port, but moreover would be straightforward
to get done using just the standard API and DOM binding of any existing port
that supports operation without an on-screen view.


Ah, great! Can you give me a pointer to how to get started with such
existing ports? Particularly interested in running on Linux,


A simple implementation would use the ordinary ordinary load 
WebView/WebFrame resource load functions (load_uri), then access the DOM 
(get_dom_document) and iterate through nodes, converting them to text 
and hyperlinks to be represented in your curses UI. Hook into ordinary 
DOM mutation events to update the text UI if the port doesn't have more 
suitable callbacks.


If you want something like classic 'lynx' you're basically already there 
at that point. If you want to get layout like 'w3m' that's obviously 
more work but you can still get there using layout positions from the DOM.


The best way to think about this assuming you're more familiar with web 
programming is "How would I implement this in JavaScript using the W3 
DOM?" -- then port the logic to native code.



ideally without bringing in dependencies on gtk or qt.


As for dependencies, it's a cost/benefit weigh-off and the cost of 
maintaining a port is very high.


There's very little runtime overhead to having something like GTK+ in 
the background, or even Mac WebView with a hidden view. There are also 
some out-of-tree ports focusing on headless operation -- I'm sure 
someone will be able to advise if you go that route.


Alp.





Alp.


Cheers,
Shea


Cheers,
Shea Levy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

--
http://www.nuanti.com
the browser experts



--
http://www.nuanti.com
the browser experts

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

Re: [webkit-dev] Curses port?

[Alp Toker]

On 19/01/2014 18:34, Shea Levy wrote:

Hi all,

I'd like to have a browser that can be used from the terminal but
actually supports modern HTML, js, etc. to the extent that is reasonable
for a console. It seems no such browser currently exists, so I was
thinking about trying to port webkit to use a curses backend. Is such a
thing a reasonable project? Ideally I'd just be able to plug some
rendering logic on top of an unmodified webkit core...


HI Shea,

It is possible as a full-blown port, but moreover would be 
straightforward to get done using just the standard API and DOM binding 
of any existing port that supports operation without an on-screen view.


Alp.




Cheers,
Shea Levy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


--
http://www.nuanti.com
the browser experts

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

Re: [webkit-dev] Proposal: Use ICU in WebKit code

[Alp Toker]

Geoffrey, http://userguide.icu-project.org/conversion/converters says:

"Since ICU uses Unicode (UTF-16) internally, all converters convert
between UTF-16 (with the endianness according to the current platform)
and another encoding."

That said, I don't think it's a major concern because ICU works on byte
streams. It's not like these strings will persist internally somewhere
eating lots of memory.

>From experience, the old WTF in-place converters found in WebKit
"mobile" ports of past were way-buggy and probably only ever tested with
ASCII. I'd say use ICU and don't look back :-)

Alp.


On 06/10/2013 20:08, Geoffrey Garen wrote:
>> There is an issue with ICU: it uses UTF16 as its internal representation, 
>> while most of the Web nowadays is UTF8. Therefore, page text goes through 
>> unnecessary encoding conversion, and takes more memory than in UTF8 (for 
>> most of languages). So it might be not a good development direction to tie 
>> up WebKit to ICU.
> Is there a benchmark or website that can verify these claims?
>
> Thanks,
> Geoff
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
http://www.nuanti.com
the browser experts

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

Re: [webkit-dev] Qt WebKit removed from upstream

[Alp Toker]

Hello Allan,

It's been a great run! QtWebKit was a trailblazer for some of the
creative uses WebKit has found over the years.

I'm sure the WebKit GTK+ developers will join me in saying thanks for
helping open up the WebKit Open Source project, and I look forward to a
time when the paths of the various WebKit ports may meet again.

Regards,
Alp Toker and the Nuanti team



On 04/10/2013 14:14, Allan Sandfeld Jensen wrote:
> Hello WebKit
>
> As everybody who followed the discussion in the "Changes in QtWebKit 
> development" thread or recent commits to subversion knows, the Qt port was 
> removed from WebKit trunk on Wednesday this week,
>
> From Digia we had a vague plan of trying to cut down drastically on the 
> maintenance burden of our port, but without any clear cut goals of what we 
> could use the port for, except it could very likely be useful to our existing 
> users and customers.
>
> After the announcement of our plan, a lot of scepticism was raised on webkit-
> dev about whether it made sense for WebKit. Since Digia had announced that we 
> would focus on the Chromium based Qt WebEngine, many seemed to feel that we 
> would not be able to contribute enough to the WebKit project to justify the 
> cost to everyone else of keeping the Qt port upstream.
>
> Based on the feedback from the community we decided to remove the port, 
> instead of fighting repeated conflicts. We have had a great time working with 
> the WebKit project over the course of the past 7+ years. There have been many 
> conflicts but the end result has always been positive, and we would not want 
> to be a burden for the project.
>
> With that in mind we say farewell to upstream. We will still be using WebKit, 
> and shipping with a brand new branch in Qt 5.2, and we will be active in the 
> project where it makes sense. Feel free to reach out to us using the usual 
> channels.
>
> Thanks for having us
>
> The Digia Qt WebKit Team.
> Allan Sandfeld Jensen
> Michael Bruning
> Andras Becsi
> Simon Hausmann
> Jocelyn Turcotte
> Pierre Rossi
> Zeno Albisser
>
> --
>
> Digia Germany GmbH
> Rudower Chausse 13, 12489 D-Berlin
> Digia Germany is a group company of Digia Plc,
> Valimotie 21, FI-00380 Helsinki Finland
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
http://www.nuanti.com
the browser experts

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

Re: [webkit-dev] exporting symbols for building .so/.dll's

[Alp Toker]

On 11/03/2012 18:13, Adam Barth wrote:

On Sun, Mar 11, 2012 at 10:49 AM, Ami Fischman  wrote:

I'm inclined to give this thread one more business day and then call it
Tuesday morning pacific time.
On current showing I think the approach in the patch on the bug (incl.
morrita@'s preference for WEBCORE_EXPORT_PRIVATE) is the way to go, at least
for now.
If you have strong concerns please speak up before then.

I'm not sure I understand your proposal fully.  Specifically, how
would these macros work for, say, the Chromium, Apple-Mac, and
Apple-Win ports, which export overlapping, but not identical, sets of
symbols?

Adam



I have some questions to add to Adam's.

Doesn't the list of exports change massively based on the level of 
inlining and compiler optimisation? Which configuration is the target to 
aim for, and which compiler vendor? This should be documented.


Doesn't the list also change between releases of the same compiler?

If so, are the export lists still really a better option than, say, 
generating the export lists by analysis of nm/objdump at compile time, 
or maintaining export lists manually?


If the export macros are enforced, will it become the responsibility of 
patch authors or committers to choose the correct places to add them?


If so, such a responsibility should also be documented.

--
http://www.nuanti.com
the browser experts

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

Re: [webkit-dev] exporting symbols for building .so/.dll's

[Alp Toker]

On 09/03/2012 03:52, Ami Fischman wrote:

Hi webkittens,

The over-all question: how should webkit libraries declare which 
symbols they export?
The trigger for the question: as described in bug 80062 
, the chromium 
shared-library-based build links test code into the (non-test) 
libwebkit.so target, which is terrible.


The details:
I took a crack at fixing the above bug (see patch in the bug) by 
pulling the test files out of the non-test build target, and 
sprinkling various {WTF,WEBKIT}_EXPORT{,DATA} macros around 
declarations that need them (as discovered by build-time and run-time 
failures).  This style of export declaration is what the webkit 
codebase does in various places (WTF 
, 
Platform 
, 
WebCore 
, 
and WebKit 
, 
AFAICT), and incidentally also what the chromium project uses for its 
sub-components.
But I'm told other ports use different mechanisms such as .exp.in 
files 
 for 
apple/mac (and maybe others for other ports? IDK).


Is there consensus on the list for what the Right Thing To Do(tm) is?
ISTM my options are:
1) Add EXPORT declarations as in the patch on the bug.
2) Drop the patch from the bug and replace it with chromium-specific 
.exp.in-style files, one per layer from which I need to export 
(WebCore, WTF, WebKit).  And build the build-time machinery to use 
them.  I don't really know what's involved here and would appreciate 
any pointers/hints people had if this is the way to go.

3) Something else (preferably unifying other ports' approaches).

Help me webkit-dev, you're my only hope (for consensus).



I think the export macros would only ever have made sense if they were 
put there explicitly to guide refactoring of the classes into a library 
/ interface structure. And this isn't the case.


At present I don't see an active effort towards that, or much interest 
in defining the public interfaces in each 'module' more strictly. 
They're intentionally fluid.


Having said that, the macros are /vaguely/ useful to see what could be 
made private or hidden in future shuffling of the code in wtf, for 
example, but that's about it.


The very fact that the export macros have to be updated with a tool 
every time a library higher in the link chain uses or doesn't use a 
public entry point, and that the set of imported functions or variables 
varies between ports indicates that this is not going to have wide adoption.


If we follow this to the logical conclusion, no unification of granular 
export lists is realistic with the current WebKit porting layer. If the 
strategy were adapted to define exported functionality at class 
granularity, it might just be feasible, but again that is a contract 
that is begging to be broken, and besides, most toolchains lack 
export-by-class so it's a moot point.


So the ultimate course of action is then to revert the macros and leave 
everyone to do what they think best in terms of export lists, then tying 
together those solutions where there's overlap.


The exception is, of course, clearly defined public API (of which there 
is not much), such as this case where we added JS_EXPORT to the 
JavaScriptCore API for the benefit of multiple ports and also consumers: 
http://trac.webkit.org/changeset/28097


(In a port I worked on in the past we developed a vendor tool to detect 
inter-dependencies at compile time so there were no lists to update, but 
again, this would not be portable.)


Spoken with my devil's advocate hat on, would be great if you can prove 
me wrong.


--
http://www.nuanti.com
the browser experts

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

[webkit-dev] An incremental approach (was Re: UPDATED Re: Version control survey)

[Alp Toker]

On 10/03/2012 21:46, Maciej Stachowiak wrote:


In my opinion, the level of SVN use shown in both surveys indicates to 
me that we should probably keep supporting it, unless most of the SVN 
users would want to switch to Git. In particular, the second survey so 
far is showing that SVN use is somewhat higher among committers and 
reviewers than among the general population.


This raises an interesting point.

The repository at git.webkit.org is not so great to work with as a 
committer / reviewer, and as Mark points out it's not too friendly on 
the servers either.


As an incremental approach, it might be a good idea to first resolve 
some of the issues in the mirror, including its layout and usability vs. 
SVN.


Without this work being done, the benefit of git over svn is not so 
clear to me.


The way I see it, a better mirror would address:

*ChangeLogs*

The ChangeLog entries in the git history mean every local merge, revert 
or cherry pick is non-trivial, so you get an ugly non-linear history 
whether or not you use a tool to auto-resolve ChangeLog conflicts.


Possible solution would be to do a new migration where the ChangeLog 
entries are folded into the commit message the files themselves are 
eliminated from the history, as if they never existed.


Maybe keep the original ChangeLog in an overlay branch for posterity, 
since these files are sometimes hand-edited after the fact.


*Author Names

*The committer names don't have the full author name in the git mirror 
right now, just an SVN id. This info could be extracted out of a 
database or the ChangeLog message if one exists, during import. People 
switch companies and email addresses over time, so that would have to be 
accounted for.


This could go some way to alleviating Oliver's concern about inflation 
in reviewer / committer population by corollary:


If the history is transformed to identify the author of an external 
contribution in cases where the patch is landed by a reviewer or 
commit-qu...@webkit.org, these guys would see their name next to their 
work and get credited on places like Github and Ohloh.


Would result in less pressure amongst casual contributors to get commit 
access, especially for those who care about the 'creds' or are doing it 
to improve their CV to get a pay rise.


*Layout and repo size
*
The git repository with full history is enormous.

I don't really need the full history of every pixel test result for 
every port, ever, including long-dead ports, and likewise don't really 
want to pull it every time the expectations get updated.


It's not so much about disk space (everyone has plenty these days).

The bigger problem is that git grep and git pickaxe search through local 
git history is so slow you actually end up having a better experience 
using the search feature on Trac. One less benefit over SVN.


A proposal (or even better, proof of concept) for git repository layout 
where the 'heavy' generated paths are split out into git submodules 
separate from the source code would make me feel more comfortable with 
the whole idea. Also, should be possible to do a shallow clone of these 
yet still be able to commit and push back upstream (if git supports 
this, git experts?)



I did some of the early WebKit git tooling but to be honest this is a 
lot of work for someone to take on. But seeing some of the energy in the 
debate, someone might be willing to have a go.


I do think that addressing these issues before advocating a switch would 
strengthen the case, at least with reviewers who had a mixed experience 
like mine.


Regards,
Alp

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

Re: [webkit-dev] Linux gtk Webkit threading question

[Alp Toker]

Hi Stephanie,

WebKit GTK+ doesn't use forks. Is it possible that you're running the 
analysis tool on 'Programs/GtkLauncher'? On Unix-like platforms, this is 
typically a shell script generated by libtool (part of our build system) 
that invokes the real binary, which would show up as a fork in the profiler.

The actual binaries live in 'Programs/.libs/'. When executing them 
directly, you should ensure that they're picking up the correct version 
of the libwebkit-1.0.so library with 'ldd'.

If everything goes to plan you'll find that WebKit GTK+ has these 
threading characteristics:

When using the curl HTTP backend:

   Unix-like systems: Entirely single threaded unless web content makes 
use of HTML5 database, DOM storage or offline web application capabilities.

   Win32: Further threads for network IO and in some cases for local IO.

When using the soup/gio HTTP backend (not yet fully supported):

   Typically two or more threads, one for the main application and the 
rest for local and network IO. Further thread usage when database 
capabilities are used as described above.

Hope this helps! Will you be publishing your paper when it's complete? 
Sounds fascinating.

-- 
http://www.nuanti.com
the browser experts
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Questions of WebKit Architecture

[Alp Toker]

손석배[단말개발담당] wrote:
> Dear All,
>  
> I've recently started analyzing WebKit for porting it onto a proprietry 
> embedded platform.
> I've tried to find documents about WebKit for about a week, but failed.
>  
> Would anyone please let me know where I can find the document about 
> WebKit architecture?
> Especially, the picture of WebKit architure would be very helpful, if 
> there is any.
> And in-depth analysis of WebCore (directory structures, components, 
> etc.) would be very helpful too.

There isn't really much high-level documentation available.

There are some basic diagrams of WebKit overall layout and WebKit/GTK+
class design in these slides:


http://www.atoker.com/blog/2008/02/26/developing-hybrid-web-gtk-applications/

>  
> Thank you in advance!!
>  
> Seokbae
>  
> * P.S. BTW, Is cairo engine included in the WebKit? It doesn't look like 
> so, but someone told me it is so and I'm confused..
> (Well, GTK+ port assumes cairo engine, but still it is not included in 
> the WebKit and cairo's not the official graphic engine for WebKit 
> expcept for SVG, isn't it?)

The Cairo graphics backend used for all rendering including HTML
content, SVG and Canvas in the GTK+ port is in WebKit SVN. We have a
summary of the code modules (complete with links to the sources) in the
wiki:

  http://trac.webkit.org/projects/webkit/wiki/HackingGtk

The actual Cairo library isn't bundled with WebKit. You can download and
install this separately from http://www.cairographics.org/

You need Cairo 1.4 or newer and should ideally use the latest release.

Cheers

-- 
http://www.nuanti.com
the browser experts
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] wx/Gtk+ and Network backends

[Alp Toker]

Holger Freyther wrote:
> So please before wasting more time on implementing the same things for 
> different backends let us wotk on one together. I do not care if it is 
> curl+glib, soup, neon...

Indeed, there are a lot of http backends around and not all of them are 
even being tested by build bots.

For the GTK+ port, we're investigating soup because the maintainer has 
suggested it'll gain caching, cookie and PAC support (probably using 
JSCore), getting similar functionality to CFNetwork. If this works out, 
it'll align with our needs in the GTK+ port and let us avoid 
re-implementing this functionality ourselves on top of curl.

soup has main loop integration but so does Mike Emmel's new ncurl http 
backend so this isn't really a deciding factor. I'd like to see ncurl 
eventually replace the current curl backend.

We continue to use the curl http backend by default in the GTK+ port 
because it works better and is more widely available than soup-2.4 at 
the moment. Don't know if we're ready to switch just yet though.

-- 
http://www.nuanti.com
the browser experts
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Re: buildbot problems

[Alp Toker]

Darin Adler wrote:

Hi folks.

The WebKit project public buildbots are displaying quite a few  
problems right now:


: GTK buildbot failing  
because it can't find ICU headers


Fixed. Looks like there are 5 jscore-test issues in 
trunk-gtk-linux-release now. Not sure if it's a regression due to the 
build system switch or if it's another recently introduced issue. Will 
look into this in a few days unless someone beats me to it :-)


--
http://www.nuanti.com
the browser experts
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Re: Building GTK+ port on Win32

[Alp Toker]

Joshua Chia wrote:

Hi,

How can I build the GTK+ port on Win32?  What do I need and what do I 
type?  Also, is it independent of the non-open Support Libraries that 
the Win32 port needs?


We documented what we did for an initial GTK+/Win32 WebKit port in this bug:

  http://bugs.webkit.org/show_bug.cgi?id=16507

This week we landed the Pango font selection patch (originally by Sven 
Herzberg of Imendio, completed by Xan Lopez) which lets us use the 
native Windows font system rather than depending on FreeType/FontConfig 
on that platform.


I'm right now sat next to Tor Lillqvist (of GTK+/Win32 fame, Novell) at 
the GTK+ hackfest in Berlin reproducing the work against TOT so we can 
get these fixes landed. We're about half way through the build and have 
cooked up 4/5 patches so far.


WebKit/GTK+ for Windows doesn't use the proprietary support libraries. 
Building is typically done with mingw32, but cygwin should work and it 
could be interesting to support MSVC in the future.


I'll post an update to this thread when the changes are in.

Cheers

--
http://www.nuanti.com
the browser experts
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New autotools build system landed in r28997

[Alp Toker]

Alp Toker wrote:
> Q: I'm a WebKit developer. Should I try to keep this build system up to 
> date when I add/remove files from the project?
> 
> It would be helpful, but until the transition is complete (ie. the build 
> bot starts using autotools) there's no pressure on anyone outside of the 
> GTK+ port to maintain these files.

We switched the default build system to autotools yesterday. The build 
bot is offline while it gets some necessary updates.

The qmake build is no longer supported for WebKit/GTK+ (and produces 
incorrect installations). Please follow the updated build instructions at

   http://trac.macosforge.org/projects/webkit/wiki/BuildingGtk

It's been a surprising amount of work to switch build system in a 
project of this size and get developers used to the new setup. Thanks a 
to everyone who made this happen.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Additional Windows Patches

[Alp Toker]

Eric Seidel wrote:
> Oliver (and others in the WebKit project) are currently working to
> remove #ifdefs from the source, not add them.  These patches are a
> step backwards in that regard.

Brent is right in conditionalising the print spooler rather than 
attempting to abstract it here.

Abstracting printing is outside the scope of any Win/Cairo build fix 
(especially since print abstraction is already being worked on and is 
difficult to get right).

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

Re: [webkit-dev] Regarding WebKit Support Libraries

[Alp Toker]

Daniel Zucker wrote:
> Hi Alp and Brent,
> 
> My vote is to use Wininet.

Hi Daniel,

You can register your vote by writing and offering to maintain a WinINet 
http backend.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Re: Error during installation of WebKit on Fedora Core 5

[Alp Toker]

sval wrote:

Hi all

While installing WebKit package on Fedora Core 5 by running 


./build-webkit--gtk ; the installation halted giving the following error:

**
../../../WebCore/html/HTMLCanvasElement.cpp: In member function ‘void
WebCore::HTMLCanvasElement::createDrawingContext() const’:
../../../WebCore/html/HTMLCanvasElement.cpp:289: error:
‘cairo_image_surface_get_data’ was not declared in this scope


You need Cairo >= 1.4. You should really aim to use the latest version 
-- older releases are noticeably slow.

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

[webkit-dev] Re: Regarding WebKit Support Libraries

[Alp Toker]

Brent Fulgham wrote:


In the medium term, I will probably end up ripping out the CFNetwork 
code to replace with native windows calls, though it would be nice to 
avoid this needless work.




The CURL http backend used by the GTK+ and Wx ports works on Windows, 
though it's not as complete as CFNetwork. It could do the job till the 
CFNetwork issues are resolved.


I guess a native WinINet backend could be an interesting project (and 
there's probably code in SVN history that can help).


CFNetwork is integrated into the Win port (consider how HTTP resource 
errors are handled and passed up to the UI) so swapping it out for 
something else may have some unfortunate maintenance overhead (ifdefs, 
more platform splits, and associated build system changes).


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

[webkit-dev] Re: WebKit Incremental Layout

[Alp Toker]

David Carson wrote:
the main issue that it tries to address is that on really really slow 
networks, the user goes to a site and takes a long time to load, and 
they think the browser has stopped working or is not doing anything and 
give up and cancel the load.
By showing some content, some progress, the user can see that there is 
activity and will continue to wait for the page to load.

Again, this is for slow network connections (ie low bandwidth)


I used this on a real mobile device with a slow connection for a couple 
of weeks to get a feel for it.


As a browser developer, the feature at first seemed neat. But as an end 
user I found that the appearance of styling up to ~10/20 seconds later 
was annoying, since by that point I'd already started reading the 
unstyled content and was getting the information I needed. The 
subsequent CSS load often meant I had to find the newly-styled paragraph 
and start reading it all over again.


Maybe it's subjective, and maybe there's a technical solution to make 
the transition from unstyled to styled content less distracting. I've 
pinged some other mobile browser developers to get their thoughts on this.

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

[webkit-dev] Re: WebKit Incremental Layout

[Alp Toker]

zaheer ahmad wrote:

hi,
can somebody suggest websites where we can see a considerable difference 
using LOW_BANDWIDTH_DISPLAY or the FOUC  problem.  i dont seem to see 
the difference  with  most  links i have tried.


The WebKit FOUC with LOW_BANDWIDTH_DISPLAY is quite distracting to me 
both on the desktop and on mobile devices, so much so that I don't think 
it's even worth supporting as an official configure flag right now.


If you didn't notice it, the only possibility I can think of is that you 
passed the wrong CPPFLAGS. It needs to be precisely:


-DWTF_USE_LOW_BANDWIDTH_DISPLAY=1

So, if you are using the configure script and compiling for the Maemo 
mobile platform:


CPPFLAGS="-DMOBILE=1 -DWTF_USE_LOW_BANDWIDTH_DISPLAY=1" ./configure 
--prefix=/opt/webkit --enable-video --disable-xslt --with-hildon


I actually think a throbber or other load notification system is much 
more effective. When users see unstyled content (HTML without CSS), they 
immediately consider it a bug in the browser. Not good.


So in summary, -DMOBILE=1 is good, -DWTF_USE_LOW_BANDWIDTH_DISPLAY=1 is 
not so good. The loader in current builds is significantly faster and 
better at scheduling than those in other mobile browsers so I don't 
think we need hacks like this. Try it out and see what you think :-)

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

[webkit-dev] Re: Issues with font rendering on DirectFB build

[Alp Toker]

Christian Dywan wrote:


While that might fix the problem, hardcoding arbitrary values is not
exactly advisable.

It should be interesting to figure out what causes this function to fail
in the first place.



The answer lies in the documentation for gdk_screen_get_resolution():

  Returns: the current resolution, or -1 if no resolution has been set.

So Sriram's patch is absolutely correct (coding-style issues aside).
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Re: Issues with font rendering on DirectFB build

[Alp Toker]

Some DPI-based font scaling was introduced in this commit:

  http://trac.webkit.org/projects/webkit/changeset/29723

Could you try disabling that logic (and anything similar you find in 
WebFrame and WebView) to see if it helps?


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

[webkit-dev] Re: Installing Webkit dependencies

[Alp Toker]

sval wrote:

Hi all,

Am installing webkit on fedora core 5 and  i needed to know from where to
get the
dependencies specific to Fedora Core 5 platform..

Search results only give me debian packages...

the following are the dependencies
libicu-dev 
libxslt-dev 
libcurl-dev 
libsqlite3-dev 
libjpeg62-dev 
libpng12-dev 
gperf 
bison 
flex version 2.5.33 or 


These are fairly standard build dependencies (not specific to WebKit) 
and should be shipped with the distribution. The package names in Fedora 
are usually similar to those in Debian.


If still in doubt, better to ask on a Fedora support mailing list.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Re: Qt's default webkit user agent

[Alp Toker]

Benjamin Meyer wrote:

As it is today Qt's default user agent (in qwebpage.cpp) is hard coded to:

"Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/523.15 (KHTML, 
like Gecko) Safari/419.3 Qt"


Seeing as this library will be used inside of many other applications it makes 
sense to include by default at least the application name/version when they 
are set.  QCoreApplication gives us several strings which can be used.


applicationName, applicationVersion, organizationDomain, organizationName

But at a bigger question, what should be included (or not included) with the 
default user agent?  Is there docs anywhere that suggest what webkit library 
users should use as their user agent string?


We did some research for the GTK+ port and tried to integrate the most 
important UA string compatibility hacks without making the string too 
ugly. The code in WebKit/gtk/WebCoreSupport/FrameLoaderClientGtk.cpp 
documents each UA string element with comments. It's fairly general and 
is intended to be moved down into WebCore.


If you decide to use this code, please submit any fixes through the bug 
tracker. Hope it helps.


(It's disappointing to see the growing number of WebCore changes in Qt's 
git tree that could benefit the whole project. Are you planning to 
submit these changes for review?)

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

[webkit-dev] Re: [Q] License

[Alp Toker]

George Staikos wrote:
   Where are the specific bits of code relating to those platforms?  
Most of them are not in svn.  For example, the collector, or the 
workarounds for the broken cross-gcc versions.  I plan to contribute 
back a bunch of those soon, but I have yet to see them elsewhere.   Or 
do you just mean that it compiles but doesn't necessarily work properly?


On some platforms that lack CPU-specific code, the implementations in 
WebCore will fall back to simpler portable code or compiler intrinsics 
(I forget the exact cases but can look it up if you're interested).


This may not have been the case on the Safari-3-0 stable branch you've 
been working on which is some way behind TOT in portability.


I've seen success reports on several of these architectures, but any 
further fixes or enhancements are of course welcome.


I've also been working to port to mingw/Win32 and should have patches in 
a couple of weeks unless anyone beats me to it:


  http://bugs.webkit.org/show_bug.cgi?id=16507
  Bug 16507: Build is broken with GCC on Windows

If you have any build fixes you should register your work on the bug 
tracker so the effort isn't duplicated by others.

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

[webkit-dev] Re: [Q] License

[Alp Toker]

Holger Freyther wrote:
use the Qt, WX or Gtk+ port for Windows. Your other option is finding out if 
this support library is in violation to the spirit and license term of the 
LGPL and then draw your conclusion.


I don't think linking against the Apple's support libraries is a 
violation of of the LGPL's spirit or word by any reading.


Anyone who wants a Windows WebKit port for commercial use is best off 
using GTK+, Wx or helping out with the new Cairo-based Win32 port (or 
using the browser in Qt if they already have a commercial Qt license).


Some examples of commercial Windows apps using WebKit (to the best of my 
knowledge):


  http://www.synctv.com/ (GTK+)

  http://www.digsby.com/ (Wx)

The only obligation these companies are under is to give back their 
changes to WebKit.

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

[webkit-dev] Re: [Q] License

[Alp Toker]

David C Matthews wrote:

Greetings-

Thanks for the feedback.  On a slightly different front, has anyone 
contemplated a MIPS port yet?


WebKit/GTK+ is supported out of the box on these platforms:

alpha amd64 arm armel hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k 
mips mipsel powerpc sparc


s390 has worked in the past but I think there's (ironically) an issue 
with the latest release of ICU on that platform.


(Reference: http://packages.debian.org/sid/libwebkitgtk0d)

The list isn't exhaustive, just the set that's easily supported on top 
of Debian GNU/Linux and for which people are around to provide help.

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

[webkit-dev] Re: Removing ICU dependancy from WebKit?

[Alp Toker]

Rachel Bassett wrote:

Dear all,

I'm currently trying to cross compile WebKit (Linux PC
-> MIPS) using the DirectFB, cairo, pango etc, GTK+,
WebKit combination. I've successfully built the stack
up to GTK+ with the GTK+ demo app running ok. However
when I try to build up WebKit, it needs ICU. But the
ICU component is not cross compilable (according to
their forum, although some other blogs imply they have
succeeded but don't say how). I could struggle with
that route however I read on the wiki page
http://trac.webkit.org/projects/webkit/wiki/Mobile,
that the dependency on ICU could be removed from
WebKit.


This hasn't been done yet, but there's quite some interest in porting 
WebKit's Unicode functionality to use GLib in the GTK+ port. The bug is:


  http://bugs.webkit.org/show_bug.cgi?id=15914

If you want to help out, #webkit-gtk on IRC network FreeNode is the 
place to touch base.

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

[webkit-dev] Abstracting the canvas

[Alp Toker]

Oliver has proposed the first move in abstracting WebKit's canvas 
implementation as part of his putImageData patch:


  http://bugs.webkit.org/show_bug.cgi?id=16954

The strategy involves splitting functions out into 
CanvasRenderingContext2DCG, CanvasRenderingContext2DCairo, and possibly 
moving other parts into the respective GraphicsContext platform 
implementations.


I know others have also considered abstracting the canvas but no other 
approaches have yet been proposed, so I thought I'd give a heads up on 
the list.


If you're planning a different way to split canvas, now is a good time 
to propose it -- silence is acceptance.

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

[webkit-dev] Re: Porting to other graphics architectures

[Alp Toker]

Brian Edmond wrote:

Hi,


I am looking at porting WebKit to the QNX Neutrino operating system and 
am trying to figure out the requirements for the target graphics system 
and OS.  I have looked at the GTK+ version under Linux a bit.  I wanted 
to know if WebKit required an underlying windowing system with widgets 
or if you could port it to a system using only a graphics library and 
input event management.  Looking at the GTK+ version it seems to use 
buttons and the like for display.  Thanks for any information,


Hi Brian,

You can port WebKit to a graphics system without needing an underlying 
UI toolkit. This approach is often taken in WebKit ports for platforms 
where the browser is the main/only user interface on the target system.


In fact, if you look at the GTK+ port, it actually falls back to a 
Cairo-only rendering path without actually using GTK+ at all when printing.

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

Re: 答复: [webkit-dev] Pulling together o n WebKit Mobile

[Alp Toker]

wangweixun wrote:
> We had ported S60Wekbit to WinCE.
> What S60Webkit or Webkit subversion repositories to merge them?
> 

Hi,

S60Webkit is divergent from WebKit mainline (TOT), but it's still
possible this can be merged or integrated with the existing Win port or
as a new port.

To decide how to proceed, it's best for you to upload your port/patches
or send the source code to the WebKit team so we can discuss the best
strategy for merging.

Access to any revision control history (SVN, git etc.) you have will
make merging easier as well.

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

[webkit-dev] Pulling together on WebKit Mobile

[Alp Toker]

Hey guys,

There's a lot of mobile WebKit expertise in different organisations and 
from various individuals, but we haven't really done much to put it all 
in one place so far.


Would you be interested in sharing your findings, internal documentation 
and patches?


Some things I'd like to see:

 * Build fixes for various lightweight toolchains integrated into TOT

 * Documentation of optional defines used in the WebCore loader and 
elsewhere, like LOW_BANDWIDTH_DISPLAY and MOBILE


 * Build instructions made public (Scratchbox, cross-compilation etc.)

 * Compiler flags

 * Bug workarounds for different architectures and toolchains

I'd love to see what Naiem's team is finding and fixing in the GTK+ 
port, what tweaks the iPhone and Android engineers are using, and the 
lightweight libc fixes from Peter, and Collabora's findings on the Nokia 
internet tablets all in one place.


When patches get merged, the WebKit team will help you maintain them so 
contributing code can help reduce the burden of maintaining ports and 
build fixes out-of-tree.


I have some material I've built up privately in the last year on ARM 
including benchmarks and patches that I'd like to start sharing too.


I do think we can get more done if we work together here. I've set up a 
wiki page -- please edit this with your findings and suggestions:


  http://trac.webkit.org/projects/webkit/wiki/Mobile

You can register an account on the wiki here:

  http://trac.macosforge.org/projects/webkit/register
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Re: WebKit graphics

[Alp Toker]

Marc-Antoine Ruel wrote:

Hi Alp,

About bug 16095 , you wrote:


...

GraphicsContext::GraphicsContext(PlatformGraphicsContext* context)
: m_common(createGraphicsContextPrivate())
, m_data(new GraphicsContextPlatformPrivate)

---

What this patch intends to do is to remove the need of m_data (at least 
for most platforms) since the constructor could implement a subclass of 
GraphicsContextPrivate (not GraphicsContext!), set the pointer in 
m_common and not need a second memory allocation (m_data).


I think this is a good idea but it might be worthwhile to eliminate 
m_data completely or otherwise mark it as deprecated. Having two ways of 
storing data associated with a graphics context will confuse porters.

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

[webkit-dev] Re: Who's working on merging GNUmakefile.am and DerivedSources.make?

[Alp Toker]

Darin Adler wrote:
Right now big pieces of GNUmakefile.am are copies of 
DerivedSources.make. And over time they are starting to diverge, 
creating an unnecessary maintenance problem. The reason we're using make 
for derived sources is so we can share those rules among all the 
different build systems.


Who's working on re-merging these?


The autotools build system was a direct port from qmake so I don't think 
 it's really a case of divergence.


Sharing of DerivedSources.make is one of the changes I'd like to see 
before the autotools WebKit build system is made official. Other issues 
I've noticed that should be fixed:


 * Adding new IDL files is difficult due to redundant targets in 
WebCore/GNUmakefile.am. WebCore developers can't be expected to 
hand-edit these lists.


 * Built object files are scattered throughout the directory hierarchy, 
resulting in svn stat noise.


 * The output path for libraries executables doesn't match conventions 
set by the Mac and Win ports.


I'm eager to review patches in this area. Help is always welcome.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Re: [webkit-changes] [29033] trunk

[Alp Toker]

Darin Adler wrote:
The #if at include sites approach is better for people who want to omit 
the code entirely for features that are not enabled. You don't even need 
the headers in your patch. But the #if in headers approach is probably 
lower maintenance, since there are usually multiple includes for each 
header.


I have a slight preference for Jan's convention, B:

(A)
#include "DatabaseTracker.h"

(B)
#if ENABLE(DATABASE)
#include "DatabaseTracker.h"
#endif

 * B avoids triggering rebuilds every time DatabaseTracker.h is 
changed, saving time for developers who track TOT.


 * B cuts down stat() calls at build time. Makes a difference when 
building on Windows where this operation is slow.


 * A doesn't make it clear that DATABASE is optional so it's more 
likely to lead to build breakage by new developers who may be unaware 
the these features can be disabled. B makes it very clear that database 
code needs to be guarded.


So while there's precedent for both A and B in WebCore I think we've 
made a improvement here.


Still no strong objections if you want to back this out.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Re: [webkit-changes] [29033] trunk

[Alp Toker]

Alexey Proskuryakov wrote:

on 30.12.2007 06:33, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:


http://bugs.webkit.org/show_bug.cgi?id=16669
autotools update and fixes

...

+* dom/Document.cpp:
+* loader/icon/IconDatabase.h:
+* page/DOMWindow.cpp:
+* page/InspectorController.cpp:
+* page/Settings.cpp:
+* storage/Database.h:
+  - Remove ENABLE(DATABASE) inclusion guard. Let the includer add the
guard instead.


  Is this something needed for autotools? I think our approach was to have
guards in headers, and there are many more examples of this, e.g. with SVG
and XSLT.



The discussion in bug #16669 suggests this was a clean-up to make 
conditional database support consistent with conditional icon database 
support. A quick grep shows precedent for this with other features, eg. 
Frame.cpp:


#if ENABLE(SVG)
#include "SVGDocument.h"
#include "SVGDocumentExtensions.h"
#include "SVGNames.h"
#include "XLinkNames.h"
#endif

If it's causing trouble with other build systems it might be better to 
add guards within the header files instead. No strong feelings either way.

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

[webkit-dev] New autotools build system landed in r28997

[Alp Toker]

The new autotools build system has landed in commit r28997:

  http://bugs.webkit.org/show_bug.cgi?id=16390

Q: Is this specific to the GTK+ port?

Right now the build system only supports GTK+, but it's been written to 
support multiple ports. Developers of two younger ports (ArOS, EFL) have 
already expressed an interest in sharing it.


Q: Will this let me build a standalone JavaScriptCore library?

Not yet, but it's a good basis for a standalone portable JavaScriptCore 
build system. This could be useful for scripting headless applications 
or building a test/benchmark driver.


Q: I'm a Qt developer. Can I remove GTK+ from the qmake build files now?

Hold up! We'll be maintaining the two systems in parallel for at least a 
week. I'll post a follow-up to list when the transition is complete.


Q: I'm a WebKit developer. Should I try to keep this build system up to 
date when I add/remove files from the project?


It would be helpful, but until the transition is complete (ie. the build 
bot starts using autotools) there's no pressure on anyone outside of the 
GTK+ port to maintain these files.


Q: Does this mean I don't need Qt any more to build the GTK+ port?

Yes. Offers of beer, gifts etc. should be directed at Jan Alonzo, and 
also Kimmo Kinnunen upon whose previous work this is loosely based.

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

[webkit-dev] Re: 7bit ASCII (8bit), UTF-8 and ISO/IEC 10646 USC-2, ISO-8859-1 character encoding.

[Alp Toker]

Nilesh Patil wrote:

How do i verify that whether webkit supports 7bit ASCII (8bit), UTF-8
and ISO/IEC 10646 USC-2, ISO-8859-1 character encoding.


Hi Nilesh,

This can vary based on which platform, port and http backend is 
configured, but generally it should be fine. The easiest way to answer 
these questions is to try for yourself -- WebKit has a test suite and 
there are also sites on the Web that have tests for things like this.

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

[webkit-dev] Re: native entry widget in webkit-gtk

[Alp Toker]

zaheer ahmad wrote:

Hi Alp.
Thank you for the response. native entry widgets in our platform has 
integrated support for entry methods like T9, ITAP etc.


If we need to get this in to the entry controls used by the webkit gtk 
port, would it mean we need to rewrite all the logic similar to what 
GtkEntry does ? Is there a alternate solution.


If input methods on your device are implemented using the standard API, 
completing IM support in WebKit/GTK+ won't be much work. I've described 
what's left to be done in this bug:


  http://bugs.webkit.org/show_bug.cgi?id=14120

There is already complete enough support for input methods in SVN trunk 
to support the virtual keyboard in the Nokia internet tablets for 
example, but more complex predictive text input methods will need a few 
more functions to be implemented.

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

[webkit-dev] Re: native entry widget in webkit-gtk

[Alp Toker]

zaheer ahmad wrote:

hi,

iam working on gtk port of webkit and i have a need to use the native 
gtk input widget (GtkEntry) for text entry instead of the webkits own 
text entry control.


Hi Zaheer,

Most WebKit ports including the GTK+ port now render input controls 
using drawing primitives provided by the style engine rather than 
instantiating real widgets. This is done to reduce overhead and make CSS 
styling easier. Other browser engines have also moved away from real 
widget instances, so this isn't specific to WebKit.


Why do you want a GtkEntry? If you're looking for better text 
internationalisation or input method support there are bug reports for 
both of these, complete with partial patches. You can help get the 
features finished sooner by testing and submitting improved versions of 
the patches.

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

[webkit-dev] Re: Help with KJS bindings

[Alp Toker]

ankush tiwari wrote:

Hi,

I am trying to extend the Javascript engine to bind to my native C code. 
Not yet succeded.


I have seen that there is testbindings.cpp file present in 
JavaScriptCore/bindings folder inside webkit. Would like to know how do 
we build and test this file as. On the latest versions I see that it 
does not compile.


Hi Ankush,

If you want to use the old C++ binding API, there's an example of how to 
get testbindings.cpp working in the Mono CLR binding:


http://git.ndesk.org/?p=javascriptcore-modular;a=shortlog;h=clr

It might make sense to use the new C JSC API for new bindings though. 
This can be found under JavaScriptCore/API. It lets you create bindings 
written plain C outside of the main WebKit build and is well documented. 
The new API is only supported by the Mac and GTK+ ports so far I think.

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

[webkit-dev] Re: opening local file returns failed read with gtk/curl

[Alp Toker]

zaheer ahmad wrote:

hi,
iam using gtk port of webkit (r26699). when i try to read a local file 
(file:///..) i get two response in downloadTimerCallback


Zaheer,

Can you test with WebKit SVN trunk and report bugs directly at 
http://bugs.webkit.org/, not the mailing list? There have been fixes 
related to all three issues that you posted to the mailing list today in 
SVN -- there's no good reason to use r26699.


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

[webkit-dev] Re: Error while building gtk port

[Alp Toker]

ankush tiwari wrote:

Hi All,

I am getting the following error when I am trying to build the latest 
webkit gtk port.


http://bugs.webkit.org/show_bug.cgi?id=16402

Turns out you need qmake from Qt 4.3 or higher. Qt 4.1 won't do, for 
example. I'm sorry about this.


We're hoping to switch to a better-suited build system soon but it might 
still be a few weeks away.

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

[webkit-dev] Re: get the bits of the complete page

[Alp Toker]

Zaheer,

If you really need full page zooming so much and can't wait for the bug 
to get fixed, try something like this (untested):


void webkit_frame_set_scale(WebKitFrame* frame, double scale)
{
g_return_if_fail(WEBKIT_IS_FRAME(frame));

WebKitFramePrivate* frameData = WEBKIT_FRAME_GET_PRIVATE(frame);
Frame* wframe = frameData->frame;
Document* document = wframe->document();
HTMLElement* root = 
reinterpret_cast(document->documentElement());

RenderObject* renderer = root->renderer();
RenderStyle* style = renderer->style();
TransformOperations ops;
ScaleTransformOperation* scaleOp = new 
ScaleTransformOperation(scale, scale);

ops.append(scaleOp);
style->setTransform(ops);
renderer->setStyle(style);
}
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Re: plugins for webkit gtk port

[Alp Toker]

zaheer ahmad wrote:

hi,
Is there any implementation of video plugin (flash player, quicktime
etc) in the gtk webkit port.


Plugin support (useful for compatibility with old binary plugins):

  http://bugs.webkit.org/show_bug.cgi?id=14750
  [gtk] Implement plugin support in GTK backend

Native video support (full integration with the graphics pipeline, 
probably the future of video on the Web):


  http://bugs.webkit.org/show_bug.cgi?id=16145
  [gtk] Implement media support in GTK backend

You can use the search feature in the bug tracker to find bugs like this.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Re: ProjectVision

[Alp Toker]

Simon Hausmann wrote:

On Friday 23 November 2007 18:31:41 Alp Toker wrote:

http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diff&versi
on=1

Please revert this change until the topic has been discussed on the
mailing list or bug tracker. You can't just make up a project vision
like that.


Apart from that name of the page what do you think about the content itself?


I thought nobody was going to ask :-)

It sounds mostly like hot air to me.

"algorithm to obtain commit and review rights"? I'm sure Apple will 
agree with any request to give developers having a good track record and 
cohesion with the rest of the team commit and review status. There is an 
element of discretion here and I don't think you can just derive a 
formula for these decisions.


I kind of like the charisma of Surfin' Safari (which evolved from Dave 
Hyatt's blog, right?) and think it would be a shame to see it turn into 
another blog aggregator.


http://planet.webkit.org/ would be neat though. I can get on the case 
and set this up if we all agree here.


Versioning is a technical matter rather than a "vision" issue. I'm sure 
we can develop a system for sharing versioning information with a little 
help from Mark.


Release schedules, on the other hand, are a complex and contentious 
topic. A friend once remarked that working on WebKit TOT is "like 
sitting on a volcano" which occasionally hurls out new features and 
releases. Again, I think that this needn't be a "vision" issue but 
rather a whole new thread of discussion.


At the end of the day, the Qt port is going to want to align with Qt 
releases, GTK+ is going to want to align with the GNOME platform and 
Apple is going to match OS X, so I wouldn't get my hopes up.

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

[webkit-dev] Objective-C API: What would you change?

[Alp Toker]

We've started re-modelling the WebKit/GTK+ public API on the WebKit 
Objective-C API, since it's closer to GTK+ conventions than our existing 
API (eg. WebView vs Page).


Going through the headers and documentation, I sometimes notice concepts 
that don't quite match up with the state of WebCore or appear redundant.


I'm wondering what the developers and users of the current API would do 
differently if they could re-write it today without any consideration 
for backward compatibility.


What would you change? What's obsolete? Any poorly named methods?

What parts do application developers have the greatest difficulties with?

Would you have included more default behaviour, forced application 
developers to implement more policy, or is the balance just right?


This information should help the GTK+ port and others avoid making the 
same mistakes.

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

[webkit-dev] Re: ProjectVision

[Alp Toker]

http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diff&version=1

Please revert this change until the topic has been discussed on the 
mailing list or bug tracker. You can't just make up a project vision 
like that.


It would be great if the Qt developers could also make more use of the 
bug tracker and allow for peer review from the wider WebKit team. 
Unilateral commits by Qt guys have broken other builds recently wasting 
everyone's time.


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

[webkit-dev] Re: get the bits of the complete page

[Alp Toker]

zaheer ahmad wrote:

hi,
iam working on the gtk port of webkit and have a need to get the
bitmap of the entire page without actually rendering it. Is there an
easy way to get in the current implementation.  one of the ways i
thought was to create a cairo surface over a memory buffer (instead of
the drawing window in webkit_page_expose_event) and pass it to the
scrollview::paint with a complete rectangle. Not sure if this is the
right track to solve this issue (also this could be performance/memory
intensive)


There's no public API to render content to an arbitrary graphics context 
yet. There are a few examples showing how to do it in places like 
webkitgtkpage.cpp or the experimental printing patch (bug #15576) 
though, if you're willing to use internal API.


Can you give an idea of what you need this for? It might help provide 
direction for how to expose this in the API, or it might turn out 
there's a simpler way of doing what you want.

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

[webkit-dev] Re: page zoom support in gtk port

[Alp Toker]

zaheer ahmad wrote:

hi,
we are looking for zoom support in gtk port and found couple of bugs
that address this using cairo transforms and css transforms resp.
http://bugs.webkit.org/show_bug.cgi?id=14998
http://bugs.webkit.org/show_bug.cgi?id=15670

appreciate any inputs on when this will be available in a release, or
a stable patch of the solution.


There's no timeline for this feature request or any other in the GTK+ 
port. You can help get it done sooner by making technical contributions 
to bug #14998 or adding yourself as a CC to register your interest.


Note that there are also no plans for a stable release.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Re: crash in gtk port

[Alp Toker]

zaheer ahmad wrote:

hi,
i observe random crashes in the gtk port when rendering certain pages
(rediff.com, cnn.com etc) and the backtrace points to the following

The platform is a x86-scratchbox.
could someone point me out possible rootcause



The cause of the issue was identified by Doug Turner this morning:

  http://bugs.webkit.org/show_bug.cgi?id=16054
  Crash when GlyphPage::fill is called with more than 256 bytes of data

The fix was landed in r27914, should be working now.

In future you should probably report issues like this in the bug tracker.

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

[webkit-dev] Re: gtk port

[Alp Toker]

zaheer ahmad wrote:

hi,
i used the patch below and had success in rendering arabic webpages.
however this seems to have broken the text search,

Font::selectionRectForText ->  selectionRectForComplexText(run, style,
point, h, from, to); seems to be returning incorrect values.
  


Hey,

selectionRectForComplexText() is unimplemented. It just returns IntRect(), so 
text selection and similar features will not work. This should not take more 
than 20 minutes to implement -- patches welcome.


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

[webkit-dev] Re: crash in gtk port

[Alp Toker]

zaheer ahmad wrote:

hi,
i observe random crashes in the gtk port when rendering certain pages
(rediff.com, cnn.com etc) and the backtrace points to the following

The platform is a x86-scratchbox.
could someone point me out possible rootcause


These sites work fine here. I think they might be sending you different 
content, perhaps containing localised text, based on your IP address 
which is tripping up the simple text backend. I get a similar crash when 
I visit http://www.wikipedia.com/


The issue goes away if you use the experimental Pango patch for all text 
rendering, so it looks like it's a bug in the simple text code path. 
Perhaps it's failing to recognise strings of text that it doesn't support.

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

[webkit-dev] Re: Moving away from qmake

[Alp Toker]

Steve Atkins wrote:

IIRC, the two issues were that qmake is time-consuming to build and
that the existing .pro files were not handling dependencies correctly.

Is the latter the only issue now, or were there other problems?


This probably reduces the urgency for change. I think we need to wait a 
week or two to see if new developers have more success with the updated 
build instructions on the wiki.


I've seen some commits on the Trolltech git tree starting to clean up 
the qmake build files. If the dependency tracking issues are solved, 
someone explains/removes the redundant duplication in the build files, 
and if new developers start having better luck with the standalone 
qmake4 package, it might be an option to stick with qmake for longer.


If we get that far, it would be easy to achieve a near-ideal build 
system for the GTK+ port using autoconf for configuration and qmake for 
the rest of the job and avoiding automake, so we don't have to duplicate 
the lists of sources but still get a flexible and well-understood 
configuration system. git itself is one example of a software project 
that uses autoconf but not automake.

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

[webkit-dev] Re: Moving away from qmake

[Alp Toker]

Alp Toker wrote:

you have to build the whole of Qt just to get qmake, which takes over an
hour and almost a gigabyte of disk space for me. That's at least 5 times
as long as it takes to build the whole of JavaScriptCore, WebCore and
WebKit.


Just to set the record straight, it turned out my bad experience 
building Qt was with a debug build of a pre-release version from some 
months ago. I hear building the whole thing is not so difficult, and 
there is even a standalone qmake tarball available now.


My bad on that point. I think the rest of the discourse is still valid.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Re: gtk port

[Alp Toker]

zaheer ahmad wrote:

i have few questions on webkit gtk port
1- how to run the autotests - seem to be specific to mac and where to
get those as they do not come with the nightly build tarball


None of the ports use autotools right now actually. the GTK+ port uses 
qmake. Here are the build instructions:


  http://trac.webkit.org/projects/webkit/wiki/BuildingGtk


2- gtk port uses pango, but internationalization (e.g. opening arabic
pages) does not seem to work.


I've implemented initial Pango text rendering support. The patch is at 
http://bugs.webkit.org/show_bug.cgi?id=15610


Screenshot: http://www.ndesk.org/tmp/WebKitArabic.png

It's a little buggy but anyone who needs this is welcome to complete it. 
If the feature is important to people, I can prioritise it a little I guess.

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

[webkit-dev] Re: Moving away from qmake (aka. modularising JavaScriptCore)

[Alp Toker]

Mike Emmel wrote:

I refactored all the Unicode handling to run behind a abstract interface.
So no direct ICU calls.

Its a lot of little patches all over the place and a thankless job.
Its a lot of work so email me if your interested.

I was also looking at repacling icu with glib/pango.

Its not clear you get everything you need from glib so I believe you
have to bring in pango
which does more than you want.  Pango itself needs to be split into text metrics
and glyph drawing.



It's also worth mentioning the new HarfBuzz library:

http://www.freedesktop.org/wiki/Software/HarfBuzz

It's pretty simple to follow the API if you check out the git 
repository. It's done in the style of FreeType which is kind of cute.


HarfBuzz can certainly be used to do some of the text handling in WebCore.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Moving away from qmake (aka. modularising JavaScriptCore)

[Alp Toker]

Mike Hommey wrote:

On Mon, Nov 12, 2007 at 03:34:48AM +, Alp Toker <[EMAIL PROTECTED]> wrote:
  

An unforeseen benefit of the new build system is that it is modular,
rather than monolithic, and has no dependency on GLib/GTK+ or any other
framework. This means that it will now be possible to use JavaScriptCore
as a standalone scripting engine independently of WebKit.



Except that for the moment, JavaScriptCore is a little bit different if
built for the Qt port or the Gtk+ port, so it couldn't be shared between
both, which is pretty sad, actually.
  


I can go into the issues here a bit further, though it doesn't directly 
relate to the choice of build system.


When it comes to platform-specific code in JavaScriptCore, the most 
obvious issue is the set of platform/language bindings. Luckily the fix 
for this is pretty obvious, and I've filed a bug:


http://bugs.webkit.org/show_bug.cgi?id=15931
Eliminate Instance::createBindingForLanguageInstance()

The other instance of platform specific code that I can see is Qt's use 
of Unicode functionality, while other ports tend to use ICU. I've 
actually been planning to port the Unicode abstraction to use GLib, 
since ICU is a very heavy dependency for non-desktop systems. (There is 
potential to shave up to 10M off the distribution size of the GTK+ port 
for mobile devices here.) This is however a thankless job that nobody 
else seems to be interested in doing and I've put it off till now:


http://bugs.webkit.org/show_bug.cgi?id=15914
[GTK] Implement Unicode functionality using GLib

So this would actually be a step away from re-usability as a shared 
library but a step towards a lower mobile memory footprint.


There are a few other bits of Qt-specific code such as that in DateMath, 
but these do not seem significant, and if the other two issues were 
fixed I imagine the Qt developers would be happy to compromise on those.


As long as ports work to avoid ICU for Unicode functionality, I don't 
think we're going to get around to genuinely sharing JavaScriptCore, and 
to be honest, I don't see this being a real problem. How many people 
will run Konqueror and Epiphany at the same time (for reasons other than 
testing)? Will those people who do regularly use both Konqueror and 
Epiphany miss the 1-2M that could have been shared given that the 
complete applications are taking at least 10M each?


So while I think there is the possibility of having a standalone 
JavaScriptCore edition embedding into applications, I do not think there 
is any immediate hope of having a single JavaScriptCore library shared 
between ports. Lots of effort for minimal gain.


The real benefit in having a standalone build profile for JavaScriptCore 
in my use case was that it made it far more practical to hack on the new 
CLR/JavaScript binding. This would have been really unpleasant if I had 
to build and link the whole of WebKit each time I made a change. I think 
that lowering the barrier for new JS bindings alone is a good cause for 
having a modular JavaScriptCore build target, but maybe I'm the only one 
developing new JS bindings right now?



As for switching away from qmake, I'm all for it, though I have no problem
having to use qmake for the Gtk+ port, since I'm already building both Qt
and Gtk+ ports in one pass for the Debian packages. I'll only add this: it
would be nice to avoid linking to indirectly used libraries where possible,
though it may be challenging. (I'm using -Wl,--as-needed for that matter)

Mike
  


You and I have learnt how to deal with qmake, but I've recently 
discovered that casual contributors and potential adopters in GNOME are 
taking one look at the qmake build system and turning around. It also 
seems to be antagonising people who use source-based distributions like 
Gentoo and who would otherwise never have a reason to take an hour out 
of their lives building the whole of Qt.

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

[webkit-dev] Re: Moving away from qmake

[Alp Toker]

Mike Emmel wrote:

Here is my autoconf build files

They are for my current  projects but I think they could readily be
cleaned up to b used with the standard build.
I found that having a single Makefile did not incur any performance problems.


Mike, just had a look over this and it's looking like a good start. Thanks!

Was wondering, do you have any fixes to the Cairo graphics or CURL http 
backends in your tree, or anything that might be useful to WebKit upstream?


If you provide your HTTP fixes, for example, I'll have more time to fix 
the remaining Cairo SVG bugs, which you can then pull back into your 
private branch, so everyone wins.

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

[webkit-dev] Moving away from qmake

[Alp Toker]

The existing qmake-based build system is shared by the GTK+ and Qt ports.

Until recently, this arrangement has not been too problematic for the
GTK+ porters, with the idea being that qmake makes life easier for
developers at the expense of a little inconvenience for users (in the
sense of application developers rather than end users).

However, it has recently become clear that qmake is actually making life
more difficult for developers. It turns out that the existing qmake
build system fails to do basic dependency tracking, leaving both
developers and users with crashy builds, with the only way to get a
stable build being to do a full clean and rebuild after every update.

In the last week I've had to explain why people's builds are crashing to
maybe half a dozen people on WebKit and GNOME-related channels.

Mark and I have attempted to fix the dependency tracking a number of
times, but we've both found qmake to be poorly documented, and our
attempts to fix it ended up breaking the build even more in certain
configurations. My informal attempts to get assistance from the
Trolltech guys doing the Qt port have gone unanswered. I have no doubt
that we would be able to fix these issues in a matter of minutes using a
better understood or documented build system.

Moreover, it has turned out that the qmake build dependency is more than
just a little inconvenience for users. It makes the GTK+ port
inaccessible to a lot of developers. Using anything but the latest Linux
distributions, including cross-compilation frameworks like Scratchbox,
you have to build the whole of Qt just to get qmake, which takes over an
hour and almost a gigabyte of disk space for me. That's at least 5 times
as long as it takes to build the whole of JavaScriptCore, WebCore and
WebKit. Even in distributions that ship a recent binary of qmake, it is
often bundled into the same binary package as the rest of Qt, making it
a seriously large dependency.

Now that the GTK+ port is getting attention from beyond a core team of
developers, I think such a heavy build dependency is no longer acceptable.


If either the Wx or Qt porters are willing to share a new build system
with the GTK+ port, they should speak up now. We're willing to consider
any build system that does not incur a huge dependency (ruling out
qmake) and that is actively maintained and does not have verbose XML
makefiles (ruling out Bakefile and Ant-like build systems respectively).
cmake and autotools are fair game here, for example.

If we cannot reach a conclusion, the GTK+ port will most likely go ahead
and switch to autotools. Work has already started to provide an
autotools-based build system at
http://git.ndesk.org/?p=javascriptcore-modular

An unforeseen benefit of the new build system is that it is modular,
rather than monolithic, and has no dependency on GLib/GTK+ or any other
framework. This means that it will now be possible to use JavaScriptCore
as a standalone scripting engine independently of WebKit.


I hope I've accurately summarised the thoughts of all those involved here.

(It's quite unfortunate that we might end up contributing to the current
proliferation of build systems, but I think it's fair to say that the
qmake dependency is right now the biggest single issue holding back
development and acceptance of the GTK+ port. If other ports are willing
to compromise in the same way as we are on a shared solution, this
proliferation can still be avoided.)

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

[webkit-dev] Re: Focus traversal question

[Alp Toker]

Artem Ananiev wrote:

Hi, Alp,

sorry for a slight delay with the answer. I'm not working with GTK port, 
but rather investigating the possibility of new Java port, on windows, 
linux and solaris platforms.


Artem,

For what it's worth, we (informally) evaluated the option of a native 
CLR port as part of the Mono project.


It turns out that while it might be feasible to port some of WebCore to 
a managed runtime in the space of a few months, the true value of WebKit 
is that it's an evolving code base with a brilliant and responsive team 
of devoted core developers, something that is lost when you deviate too 
far from the existing architecture. So you end up with a browser that no 
longer gets essential site compatibility fixes or support for new Web 
standards unless you recruit a whole new development team.

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

[webkit-dev] Re: Focus traversal question

[Alp Toker]

Artem Ananiev wrote:
After some search I found two methods in ChromeClient related to the 
question: canTakeFocus() and takeFocus(). Still, I see some problems 
with the reverse traversal (I tried text field on www.yahoo.com: when I 
press Shift+TAB, the methods from ChromeClient are not called).


Artem,

I noticed you've posted a few questions that have gone unanswered on the 
list. From your email address, I'm guessing that you're working with one 
of the X-based ports.


If you're working with the GTK+ port, we can assist you but you need to 
specify which platform you're using in your messages or nobody will feel 
qualified to reply, since graphics and focus issues are handled 
differently by each implementation.

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

[webkit-dev] Re: WebKit/Gtk+ and how to contribute

[Alp Toker]

Holger Freyther wrote:

Hi all,

I'm glad the interest in WebKit/Gtk+ is so tremendous. While the current 
state of the port is quite good there are still a lot of things missing 
making it really kick ass. This includes Netscape Plugins, keyboard 
navigation, zooming, styling, finishing an API, networking improvements, 
etc.


So don't ask what WebKit/Gtk+ can do for you, but ask yourself what you 
can do for WebKit/Gtk+. And luckily the answer is very simple! File bugs 
and fix them!


1.) Filing bugs:
Go to http://bugs.webkit.org and file bugs. Make sure to use the Gtk 
keyword so we can easily query for Gtk+ bugs


2.) Fixing bugs:
    With Alp Toker we have a Gtk+ port reviewer and we have the lovely 
Apple team that is very helpful as well and can review your changes. We 
have Gtk+ people that can and will commit reviewed patches. Just follow 
this guideline[1] and you will make the world a better place.


thanks and I look forward to commit your patches.

z.


[1] http://webkit.org/coding/contributing.html


Thanks Holger for this introduction to WebKit/GTK+ hacking! I'd also 
like to welcome contributors who want to help improve the 
platform-independent components of the GTK+ port like the Cairo graphics 
and HTTP backends, and future GStreamer video/audio support.


We have a competitive coverage of the SVG spec and the HTML5 canvas 
element, for example, but there are still basic gfx TODOs that anyone 
who has studied geometry at high school can help fix.


Such work will give us access to a large new correctness and performance 
test suite that can potentially assist the Cairo project itself.


Much of the Cairo graphics backend in WebKit is written using the Cairo 
C API directly so you don't have to re-learn the Cairo API through 
abstractions like "Thebes" (although it is abstracted higher up for use 
by the rendering engine).

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

[webkit-dev] Re: please don't add new code using DeprecatedXXX classes, especially in platform specific code

[Alp Toker]

Darin Adler wrote:

Hi folks.

I've noticed some new code going in using some of the Deprecated-prefix 
classes, such as DeprecatedString.


While in some cases this could be unavoidable, in general it's a step 
backwards for the project.


We're working as hard as we can to eliminate these classes entirely, and 
if you add more uses it makes that job harder. Please go out of your way 
to use suitable replacements, for example String instead of 
DeprecatedString.


A quick grep suggests that much of the DeprecatedString use both in the 
core and in the ports stems from KURL offering only DeprecatedStrings in 
its API. Is this because KURL is somehow deprecated, or is it just a 
throwback?


Rewriting KURL to use String might be a good step towards this goal, and 
provides an opportunity to lose the K* naming convention at the same 
time. I can look into this some time if you think it's a good direction.

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

[webkit-dev] Re: AJAX crash

[Alp Toker]

Peter Schojer wrote:

Hi all,
I am using the safari-3-branch on Ubuntu 7.04 and I am getting
segfaults with javascript code:
For example, the AJAX samples from
http://extjs.com/ simply crash.
I have tested with the qt and the gtk build.


I couldn't reproduce any crashes on http://extjs.com/ using current SVN 
trunk of the GTK+ port. If you can find a reproducible crasher, please 
file a bug and use the "gtk" tag, with the exact URL that causes it.

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

[webkit-dev] Re: "Enter" key mapping in Webkit

[Alp Toker]

Naiem Shaik wrote:

Hi All,
I have compiled Webkit+Gtk port and I ran the Gtklauncher.
After launching www.rediff.com when I enter text in search box and
press "Enter" it does not have any effect.
Only if I use the mouse and press "Go", does the search begin.

I have cross compiled the same and ran it on linux box and it has the
same affect there.
Do I need to map the "Enter" key to something as there is no Mouse
inside the cross compilation environment.


This is fixed by the patch in http://bugs.webkit.org/show_bug.cgi?id=15653
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Re: Next link in page

[Alp Toker]

Naiem Shaik wrote:

Yes Oliver.
Tab key press doesn't take me to any of the links so can I hack the
tab key press and move to the next link by calling some webkit page
functions...

--Naiem

On 10/26/07, Oliver Hunt <[EMAIL PROTECTED]> wrote:

I suspect Naiem meant how to either switch focus from link to the
next, or to get all the links programmatically...

--Oliver

On Oct 25, 2007, at 9:26 PM, Mark Rowe wrote:


Naiem,

Click on them?

- Mark

On 26/10/2007, at 14:23, Naiem Shaik wrote:


Hello All,
I have cross compiled the Webkit+Gtk port and ran the GtkLauncher
on Linux box.
Can somebody please let me know how to go to different links present
on the page.


Hey,

This is becoming a FAQ :-)

We just need to return true in ChromeClient::tabsToLinks() to enable 
this navigation mode.


To see it in action you'll also need my input patch from 
http://bugs.webkit.org/show_bug.cgi?id=15653 (unless it lands in the 
meantime).


There are still some focus issues, and the focus rings aren't 
GTK+-style. Please file a bug on this, should be easy to fix.

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

[webkit-dev] Re: Should we consider switching to git over svn?

[Alp Toker]

Thumbs up on this one. git certainly has the potential to make WebKit 
development more accessible and transparent.


It might be worth talking with other large projects that have migrated 
from CVS or SVN (like xorg, freedesktop.org, wine) to see if they have 
any useful commit history post-processing scripts or general hindsight 
advice.


I've found that the point of migration is a good opportunity to scrub 
project history a little. For example, I've written a tool (used in a 
previous migration) that extracts authorship and reviewed-by information 
from the commit logs and turns them into git's equivalent AUTHOR_ID, 
COMMITTER_ID and Signed-off-by fields, cleaning up the commit log 
messages as it goes and optionally eliminating all modifications to the 
"ChangeLog" files. This makes the history retro-actively far more 
useful, making it easier to revert old patches, do bisection searches, 
review old patches in a new light etc. It's kind of like discovering a 
history you never knew your project had ;-)

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

Re: [webkit-dev] Webkit Porting Issues

[Alp Toker]

Ashish wrote:


Hi All,

I am trying to port Webkit for ARM and I have downloaded the latest 
Webkit Code.


As a starting point I would like to know if anybody has a document or 
could tell me a way as to which portions to look into to start porting.


 


Regards

Ashish



There is no CPU architecture specific code in WebKit, so there is no 
need for porting. It simply cross-compiles to ARM as long as you have 
the appropriate development environment available eg. Gtk+ and Cairo or 
presumably Qt or one of the other ports.


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

[webkit-dev] Re: Future of Webkit for Windows?

[Alp Toker]

Arno wrote:


On Jun 26, 2007, at 11:09, Darin Adler wrote:


On Jun 26, 2007, at 11:00 AM, Double-Dee Zee wrote:
does the use of non-redistributable support libraries force Adobe to 
maintain their own WebKit branch?



No.

Adobe should bring their changes back into the webkit.org tree, using 
ifdefs as appropriate.


we, Adobe, plan to do the following:

a/ merge the latest WebKit top-of-tree with our changes (we're waiting 
for a certain Jesus-device to be released before doing so)


b/ publish our branch as we make available future public beta builds of 
Apollo


b/ submit our changes back to WebKit top-of-tree. This will happen as 
soon as we ship Apollo 1.0.


We have no intention of forking our branch.

Note that we are using Cairo to render on Windows, not Quartz. We are 
not using CoreFoundation either. The availability of both of those 
libraries when Safari shipped were interesting surprises, but we do not 
expect to change our plan at this point.


Hi,

I've been working on the WebKit Cairo backend for the last couple of
months as part of the Gtk+ port (but the code is entirely cross-platform).

In that time we've fixed up the core GraphicsContextCairo, added initial
SVG support and are working on Canvas support. You can track our
progress in the SVN history and the bug tracker. Could you explain with
a little more detail how your contributions merge against the current
tip-of-tree so we can coordinate our efforts and avoid duplication?

If there are any specific areas you think need work, I'd be happy to
look into them personally or work together with your team.

Cheers,
Alp

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

[webkit-dev] Re: Ports and Forks

[Alp Toker]

Far from causing divergent forks and fragmentation, Mike is proposing a 
way to avoid each of the concerns you listed. I really don't care what 
version control system gets used, but I do care when a reasonable 
suggestions gets shot down so lightly.


In all fairness, if you "don't understand how git-svn can possibly be 
better than a branch in the same SVN repository", Mike is probably a 
more authoritative figure on the subject and I hope he isn't discouraged 
by you.

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

[webkit-dev] Re: Ports and Forks

[Alp Toker]

Maciej Stachowiak wrote:

By setting up a associated repository this work would be accessible to
all interested parties and once stable it could be integrated into the
main repository.


This is an example of the kind of project that would be better done on a 
branch than in a separate repository (if it were desirable at all).


I have to disagree here. git-svn is really the only tool in its class 
for working on branches of large svn projects. I haven't spent as much 
time as Mike hacking on the Gdk WebKit port, but the distributed and 
transparent form of git repositories does in my experience almost 
eliminate the pain of merging upstream changes, maintaining history and 
most importantly providing atomic patches that are suitable for 
inclusion back into the original repository.


The WebKit project would do well to formalise this pattern. It would 
benefit not only the ports, but also help reduce the barrier for 
bugfixes to find their way back into the project rather than getting 
left by the wayside in an svn branch or bug report.

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