Hi Folks,
How complex is to implement Multi-Tap keyboard entry support in Webkit...?
Could any one help me how to start this implementation..?
Expecting kind support.
Regards,
Arun.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.
On Fri, Nov 4, 2011 at 7:16 PM, Ryosuke Niwa wrote:
> On Fri, Nov 4, 2011 at 7:07 PM, Ojan Vafai wrote:
>
>> On Fri, Nov 4, 2011 at 7:03 PM, Ryosuke Niwa wrote:
>>
>>> I am, but I'm particularly concerned about W3C tests. It'll be nice if
>>> we had exactly one way of running / writing ref test
On Fri, Nov 4, 2011 at 7:07 PM, Ojan Vafai wrote:
> On Fri, Nov 4, 2011 at 7:03 PM, Ryosuke Niwa wrote:
>>
>> I am, but I'm particularly concerned about W3C tests. It'll be nice if we
>> had exactly one way of running / writing ref tests. I think we can easily
>> automate the process of generati
On Fri, Nov 4, 2011 at 7:03 PM, Ryosuke Niwa wrote:
> On Fri, Nov 4, 2011 at 6:31 PM, Ojan Vafai wrote:
>
>> On Fri, Nov 4, 2011 at 5:52 PM, Ryosuke Niwa wrote:
>>
>>> W3C's build step auto-generates them.
>>>
>>
>> I thought you were arguing that we should use manifest files for all
>> reftest
On Fri, Nov 4, 2011 at 6:31 PM, Ojan Vafai wrote:
> On Fri, Nov 4, 2011 at 5:52 PM, Ryosuke Niwa wrote:
>>
>> W3C's build step auto-generates them.
>>
>
> I thought you were arguing that we should use manifest files for all
> reftests because having multiple ways to do things is confusing.
>
I
On Fri, Nov 4, 2011 at 5:52 PM, Ryosuke Niwa wrote:
> On Fri, Nov 4, 2011 at 4:01 PM, Ojan Vafai wrote:
>
>> I don't see any need for manifest files.
>
>
> W3C's build step auto-generates them.
>
I thought you were arguing that we should use manifest files for all
reftests because having multip
On Fri, Nov 4, 2011 at 4:01 PM, Ojan Vafai wrote:
> I don't see any need for manifest files.
W3C's build step auto-generates them.
On Fri, Nov 4, 2011 at 2:00 PM, Ryosuke Niwa wrote:
>
>> On Fri, Nov 4, 2011 at 1:47 PM, Dirk Pranke wrote:
>>>
>>> It's unclear how much of a perf impact there
On Fri, Nov 4, 2011 at 3:21 PM, Alan Stearns wrote:
> Once we figure out how to support imported reftests, we should be
> encouraging people to use reftests internally (even for tests we have no
> intention of pushing to the W3C) instead of dumprendertree or pixel tests
> (where possible - I assum
Tony: I would recommend upgrading to at least 2.7 on those machines.
http://www.python.org/download/releases/2.7.2/
I would love to switch us to require 2.7 but such would currently too
much of a burden on SnowLeopard-based developers.
-eric
On Fri, Nov 4, 2011 at 4:03 PM, Adam Barth wrote:
> I
For those wishing to follow along at home (or just to spectate at the
epic-hack that was python 2.5 support), the bug is
https://bugs.webkit.org/show_bug.cgi?id=71593.
On Fri, Nov 4, 2011 at 4:03 PM, Adam Barth wrote:
> I misremembered. Looking at depot_tools, it seems Chromium only does
> this
I misremembered. Looking at depot_tools, it seems Chromium only does
this on Windows.
Looks like we might need to upgrade the Chromium bots to use 2.6.
Python 2.5 is super old at this point.
Adam
On Fri, Nov 4, 2011 at 4:01 PM, Tony Chang wrote:
> Are you sure? This output has references
> t
I don't see any need for manifest files. Needing to maintain information
about a test somewhere other than in the test itself or in the expected
result file is a significant maintenance burden. We should avoid it if we
can.
On Fri, Nov 4, 2011 at 2:00 PM, Ryosuke Niwa wrote:
> On Fri, Nov 4, 201
Are you sure? This output has references
to System/Library/Frameworks/Python.framework/Versions/2.5. I also thought
that's why NRWT was slow on the Leopard bots: python 2.5 doesn't have the
multiprocess module.
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28dbg%29%281
On Fri, Nov 4, 2011 at 6:37 PM, David Levin wrote:
>
> Exactly :)
What are you saying, the rest of the WebKit community doesn't want to
spend weeks perfecting the architecture to make my life easier? :)
When the need comes, it'll be done. Which may be never, but that's life.
--
Regards,
Ryan
_
Yes, Chromium versions its Python independently from the OS.
Adam
On Fri, Nov 4, 2011 at 3:25 PM, Ojan Vafai wrote:
> I believe the chromium port always uses 2.6 though, no?
>
> On Fri, Nov 4, 2011 at 3:23 PM, Nico Weber wrote:
>>
>> The chromium port still has a bot that runs tests (but doesn
On Fri, Nov 4, 2011 at 3:24 PM, Ryan Leavengood wrote:
> There may be a time when I do this work, but I have bigger fish to fry at
> the moment...
>
Exactly :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listi
I believe the chromium port always uses 2.6 though, no?
On Fri, Nov 4, 2011 at 3:23 PM, Nico Weber wrote:
> The chromium port still has a bot that runs tests (but doesn't build) on
> 10.5.
>
> Nico
>
> On Fri, Nov 4, 2011 at 3:20 PM, Eric Seidel wrote:
> > Now that Apple has removed the Leopard
On 11/4/11 3:09 PM, "Ryan Leavengood" wrote:
> On Fri, Nov 4, 2011 at 5:58 PM, Ryosuke Niwa wrote:
>>
>> Indeed, I'm against this idea.
>
> You make good points. There may be solutions to your objections, but
> they might not be much better than having a slow git status right now.
>
> Do othe
On Fri, Nov 4, 2011 at 6:12 PM, David Levin wrote:
>
> I suspect the pain hasn't been big enough so far for any person/organization
> to decide to address this.
Well it may not really be worth the trouble, I just always found the
#ifdefs in WebCore/platform to be a little smelly. But they work.
The chromium port still has a bot that runs tests (but doesn't build) on 10.5.
Nico
On Fri, Nov 4, 2011 at 3:20 PM, Eric Seidel wrote:
> Now that Apple has removed the Leopard build bot (and presumably
> stopped supporting WebKit on Leopard), all webkit platforms I know of
> have Python 2.6 or h
Now that Apple has removed the Leopard build bot (and presumably
stopped supporting WebKit on Leopard), all webkit platforms I know of
have Python 2.6 or higher.
My plan is to remove all of our 2.5 supporting code in the next week,
requiring Python 2.6 or later for WebKit.
Let me know if this wil
On Fri, Nov 4, 2011 at 3:09 PM, Ryan Leavengood wrote:
>
> You make good points. There may be solutions to your objections, but
> they might not be much better than having a slow git status right now.
>
> Do other people who use WebKit with Git see this problem? If so, what
> do you do to stay pro
On Fri, Nov 4, 2011 at 3:04 PM, Ryan Leavengood wrote:
> I personally would like to see WebCore
> evolve into being as self-contained as possible, with clear APIs for a
> platform to attach to.
>
I suspect the pain hasn't been big enough so far for any
person/organization to decide to address thi
On Fri, Nov 4, 2011 at 5:58 PM, Ryosuke Niwa wrote:
>
> Indeed, I'm against this idea.
You make good points. There may be solutions to your objections, but
they might not be much better than having a slow git status right now.
Do other people who use WebKit with Git see this problem? If so, wha
On Fri, Nov 4, 2011 at 5:40 PM, Dirk Pranke wrote:
>
> Hopefully we will start writing more and more tests as reftests, to
> address the first category. Moving to one of the existing cross-port
> build mechanisms like GYP or CMake would help.
Yeah I will attempt to make use of GYP myself for the
On Fri, Nov 4, 2011 at 2:39 PM, Ryan Leavengood wrote:
> I would also like to throw out the idea of pulling the layout tests
> out into their own repo, maybe even per platform.
How do we keep webkit/layout repositories in sync?
> Currently the huge number of layout tests in WebKit make many gi
On Fri, Nov 4, 2011 at 10:56 AM, Ryan Leavengood wrote:
> Actually regarding the 42,000 changesets: these have all come in the
> last year and a half (), and are almost as many changesets as ever
> came before in the current WebKit repo. This is exponential growth!
> How is a small port possib
On Fri, Nov 4, 2011 at 4:47 PM, Dirk Pranke wrote:
>
> Separately, if we are throwing around numbers in the range of >100K
> for tests to run, we should consider when we actually want to run them
> - i.e., what will the cycle time be if we run them on every change,
> etc.? But that can be dealt wi
On Fri, Nov 4, 2011 at 1:47 PM, Dirk Pranke wrote:
>
> It's unclear how much of a perf impact there would be but that's
> easy enough to determine - I would expect it to be minimal compared to
> the time of actually rendering a page.
>
Since I expect w3c to end up having hundreds of thousands of
If we import a bunch of w3c reftests in the future, it sounds reasonable
and unavoidable to use manifest file, assuming the manifest file is
auto-generated by w3c's build process.
But I'd like to leave an option to developers to write reftests more
casually without worrying about maintaing the man
On Fri, Nov 4, 2011 at 1:32 PM, Hayato Ito wrote:
> Could you clarify why we have to need to modify DRT if we have Link Element
> approach?
> I guess one of the reasons is the performance. It might be better that we
> use DRT to parse and extract reference links from HTML since parsing HTML
> usin
On Fri, Nov 4, 2011 at 1:32 PM, Hayato Ito wrote:
> Could you clarify why we have to need to modify DRT if we have Link
> Element approach?
> I guess one of the reasons is the performance. It might be better that we
> use DRT to parse and extract reference links from HTML since parsing HTML
> usi
Could you clarify why we have to need to modify DRT if we have Link Element
approach?
I guess one of the reasons is the performance. It might be better that we
use DRT to parse and extract reference links from HTML since parsing HTML
using Python might take unacceptable time and might be inaccurate
On Fri, Nov 4, 2011 at 12:04 PM, Mark Rowe wrote:
> On 2011-11-04, at 11:56, Adam Barth wrote:
>> I've created a "stub" WTF library at
>> http://trac.webkit.org/browser/trunk/Source/WTF
>>
>> Would you be willing to create an appropriate xcodeproj file that
>> builds Stub.h and Stub.cpp (and integ
Hi,
There was a discussion about supporting W3C ref tests at TPAC yesterday.
However, there appears to be some disagreement in how we support them.
*Overview*
CSS WG ref tests contain link elements that specify reference files. e.g.
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>http://dec
On 2011-11-04, at 11:56, Adam Barth wrote:
> Mark,
>
> I've created a "stub" WTF library at
> http://trac.webkit.org/browser/trunk/Source/WTF
>
> Would you be willing to create an appropriate xcodeproj file that
> builds Stub.h and Stub.cpp (and integrates with whatever magic is
> needed intern
Mark,
I've created a "stub" WTF library at
http://trac.webkit.org/browser/trunk/Source/WTF
Would you be willing to create an appropriate xcodeproj file that
builds Stub.h and Stub.cpp (and integrates with whatever magic is
needed internally at Apple)? I'm also happy to attempt webkit.org
side of
On Fri, Nov 4, 2011 at 11:12 AM, Kevin Ollivier wrote:
> So I'm assuming that dynamic library would be JSCore, then? Is the idea
> basically just to have a clean separation between WTF and JSCore build
> projects?
Yes. Conceptually, WTF is a separate layer from JavaScriptCore.
Adam
Hi Mark,
On Nov 4, 2011, at 10:59 AM, Mark Rowe wrote:
>
> On 2011-11-04, at 10:57, Kevin Ollivier wrote:
>
>> Hi Steve,
>>
>> On Nov 4, 2011, at 9:12 AM, Steve Falkenburg wrote:
>>
>>>
>>> On Nov 4, 2011, at 8:48 AM, Kevin Ollivier wrote:
>>>
> Step (2) here involves coming up with a g
On 11/4/11 7:23 AM, Chris Marrin wrote:
On Nov 3, 2011, at 7:00 PM, Charles Pritchard wrote:
In my experience, implementing filters leads to writing them multiple
times for various targets.
I suggest starting with the lowest common denominator before
targeting platforms like webgl. I unders
On 2011-11-04, at 10:57, Kevin Ollivier wrote:
> Hi Steve,
>
> On Nov 4, 2011, at 9:12 AM, Steve Falkenburg wrote:
>
>>
>> On Nov 4, 2011, at 8:48 AM, Kevin Ollivier wrote:
>>
Step (2) here involves coming up with a good solution for export control
in both the WTF and platform case
Hi Steve,
On Nov 4, 2011, at 9:12 AM, Steve Falkenburg wrote:
>
> On Nov 4, 2011, at 8:48 AM, Kevin Ollivier wrote:
>
>>> Step (2) here involves coming up with a good solution for export control in
>>> both the WTF and platform cases. Today we use an explicit .exp file for
>>> JavaScriptCore
On Fri, Nov 4, 2011 at 12:33 PM, Peter Kasting wrote:
>
> It seems like either you should be a private fork/port, or a public
> upstreamed one, but not both. If you want to live in the upstream tree, I
> think most of your development work should land quickly in public. If you
> want to work in
On Thu, Nov 3, 2011 at 7:32 PM, Ryan Leavengood wrote:
> The primary problem with our port right now is some of the developers
> made the choice (which I objected to) to make our own Subversion repo
> containing the WebKit code to make it easier (in their eyes) to
> develop the port.
>
> Where can
On Nov 4, 2011, at 8:48 AM, Kevin Ollivier wrote:
>> Step (2) here involves coming up with a good solution for export control in
>> both the WTF and platform cases. Today we use an explicit .exp file for
>> JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple
>> Windows Web
Hi Darin,
On Nov 2, 2011, at 4:42 PM, Darin Adler wrote:
> On Nov 2, 2011, at 4:09 PM, Mark Rowe wrote:
>
>> There are a few related goals here that I'm aware of:
>> a) Separate WTF out of JavaScriptCore since it doesn't logically belong
>> there, but was simply a convenient home for it.
>> b)
Leandro Pereira writes:
> At last, the EFL port of WebKit got a DumpRenderTree implementation!
> We're still working on ironing out a lot of bugs found by some of the
> LayoutTests, but the DRT (and ImageDiff) code has been submitted to
> Bugzilla. It would be awesome if anyone could help reviewi
On Nov 3, 2011, at 7:00 PM, Charles Pritchard wrote:
> In my experience, implementing filters leads to writing them multiple times
> for various targets.
>
> I suggest starting with the lowest common denominator before targeting
> platforms like webgl. I understand that Google is working on an
48 matches
Mail list logo
