at 10:40 PM, Hajime Morrita morr...@chromium.org
wrote:
There are DocumentMarker, or DocumentMakerDetails. Which do you have in
your mind?
I had DocumentMarkerDetails in mind. It seems to be the standard location
of auxiliary information for a document marker.
Or you can possibly
There are DocumentMarker, or DocumentMakerDetails. Which do you have in
your mind?
For me, it seems DocumentMarker is the right place to put such an ID since
DocumentMarkerDetails is an immutable, shared object and giving such ID
breaks the assumption for instance sharing.
Or you can possibly
Yay, it finally arrived!
I can see graphs only for html5-full-render test. Could we have links for
other test charts? Or aren't they ready yet?
On Mon, Feb 25, 2013 at 12:24 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi all,
We've replaced webkit-perf.appspot.com by perf.webkit.org.
On Mon, Feb 25, 2013 at 1:32 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Feb 24, 2013 at 7:56 PM, Hajime Morrita morr...@chromium.orgwrote:
Yay, it finally arrived!
I can see graphs only for html5-full-render test. Could we have links
for other test charts? Or aren't they ready yet
On Wed, Feb 20, 2013 at 4:29 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Tue, Feb 19, 2013 at 3:50 AM, Antti Koivisto koivi...@iki.fi wrote:
The problem with ComposedShadowTreeWalker is not that it is an iterator
but
that it is ill-defined and complex. It calls back to non-trivial,
AncestorChainWalker follows the style of ComposedShadowTreeWalker,
which also breaks conventions like mutations-should-be-verbs. We also fix
its style for integrity.
Non-trivial tree traversal API in general should, IMO, be modeled after
recently introduced NodeTraversal.
Having separate
AncestorChainWalker follows the style of ComposedShadowTreeWalker,
which also breaks conventions like mutations-should-be-verbs. We also fix
its style for integrity.
We *should*. It is yet to be done :-/
___
webkit-dev mailing list
Editing seems OK if we use GYP or CMake.
You can generate both Xcode and Ninja files against same source tree.
Debugging won't work though, at least for GYP-generated projects.
Its Ninja and Xcode builds have different directly structure.
If Xcode can attach gdb/llldb to an out-of-project
(From the right address)
I did it for WTF and JSC with kevino@.
https://bugs.webkit.org/show_bug.cgi?id=72855
I hope I had had time to extend the work to WebCore, which was my original
goal :-/
I did it through an automation but the tool was so slow and hacky that it
was not capable for large
On Thu, Jan 31, 2013 at 5:49 PM, Patrick Gansterer par...@paroga.comwrote:
Hi,
Am 31.01.2013 um 09:25 schrieb Mark Rowe:
CMake was originally considered a non-starter for chromium since the
XCode and VS projects it produced didn't look or feel like native
projects. However, we've since
In my understanding, it doesn't matter whether Apple Mac port supports
ninja or not. We could use GNU make if some meta-build system is adopted
because Mac OS has it installed. The problem here is that the neither CMake
and GYP isn't easy to adopt for reasons discussed in this thread.
My personal
The history aside, I think it makes sense to use the export macro
specifically for Mac WebCore because
- As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit
separation.
Other ports like GTK or Chromium build single WebKit library which has
both WebCore and WebKit API
On Fri, Feb 1, 2013 at 10:39 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita morr...@chromium.orgwrote:
The history aside, I think it makes sense to use the export macro
specifically for Mac WebCore because
- As Eric mentioned, Currently only Mac
to grow under these
CustomElementSomething and accompany classes.
Hope this answers your question.
--
morrita
On Wed, Jan 30, 2013 at 4:52 PM, Maciej Stachowiak m...@apple.com wrote:
On Jan 29, 2013, at 6:22 PM, Hajime Morrita morr...@chromium.org wrote:
Hi folks,
I'm going to implement
Hi folks,
I'm going to implement Custom Elements standard behind
ENABLE(CUSTOM_ELEMENTS) flag.
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html
Here is the tracking bug for the feature:
https://bugs.webkit.org/show_bug.cgi?id=99688
Note that Mozilla is also working on
Hi Hema,
If you are talking about WebKit and HTML, it already does it for some of
its built-in HTML elements.
Some UI controls, which are modal and don't fit into the page layout, are
implemented using native UI controls. These modal controls shouldn't
constrained by WebKit rendering area like
(sending from correct address)
Come late here. I basically support Darin's point.
Here is some addition:
As Maciej said, we don't need to do this for all API. We can do this by
opt-in basis, as an optimization.
Since we have [implementedAs] IDL attribute already, we can even start this
today
It looks github supports mirroring by pulling a repo from official location.
http://stackoverflow.com/questions/11370239/creating-an-official-github-mirror
So we might be able to rename the existing one and ask github to pull our
git.webkit.org repository into github/WebKit/webkit.
Apparently
IIRC, Android (non-Chrome) uses V8. I'm not sure whether PLATFORM(CHROMIUM)
is on there.
On Sun, Nov 11, 2012 at 3:59 PM, Kentaro Hara hara...@chromium.org wrote:
EFL and other ports used to have an option to build with V8, but it
looks like the option is no longer supported. For example,
(From right address...)
On Sun, Nov 4, 2012 at 8:14 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Nov 4, 2012 at 2:45 AM, Peter Beverloo pe...@chromium.org wrote:
IRC nicknames are available in committers.py, as the third argument of
the Contributor, Committer and Reviewer entries:
We could have both const and non-const versions. For document(), we will
certainly need both.
I think these APIs can become less useful because the strict const-ness is
yet to be deployed widely. We can apply the rule for fresh classes line new
Web APIs since these rule worry little about older,
On Tue, Sep 18, 2012 at 8:46 AM, Eric Seidel e...@webkit.org wrote:
On Mon, Sep 17, 2012 at 6:35 PM, Benjamin Poulain benja...@webkit.org
wrote:
On Mon, Sep 17, 2012 at 4:11 PM, James Hawkins jhawk...@chromium.org
wrote:
A few details:
* Google will front the cost of the license
If the only problem is to determine the type of JS wrappers, is it possible
to
make wrapSlow() a virtual method of some base class, instead of static
functions?
It need a tweak on the code generator. Also, it might need to avoid name
conflicts
by suffixing like wrapSlowForNode(),
(from the right address...)
Hi,
I don't think it is a reasonable expectation especially for non-chromium
developers.
It is possible for a change to break chromium-linux, chromium-win or
chromium-mac,
that means developers needs to have Linux, Mac and Windows machines to
ensure
the successful
(Resending from the right address)
FYI, Chromium port has some unit-like tests:
http://trac.webkit.org/browser/trunk/Source/WebKit/chromium/tests
Apparently it is not community's responsibility to maintain these. But it
might be useful for developing some low-level standalone/low-level stuff
This change looks reasonable for me.
I hope the client interface to be extracted from ChromeClient to its own.
ChromeClient is like a zoo of ifdefs, which modularization effort has
aimed to improve.
(I don't think we need to split the implementations of ChromeClient:
they can implement both
Hi,
The code was brought from a third party library and WebKit (WTF) needs
some changes to the original code. It looks such changes are marked by
WTF_CHANGES. For example, WTF shouldn't depend on gflags, which is
disabled by the WTF_CHANGES guard.
--
morrita
On Thu, Apr 12, 2012 at 6:01 PM,
these exports are supposed to work. :)
-eric
On Wed, Mar 21, 2012 at 6:21 PM, Hajime Morrita morr...@google.com wrote:
I'll write a draft so that ports' expert can fill missing pieces.
--
morrita
On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel e...@webkit.org wrote:
Do we have any
I'll write a draft so that ports' expert can fill missing pieces.
--
morrita
On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel e...@webkit.org wrote:
Do we have any documentation for how the current symbol export system
for WTF/JSC is supposed to work?
I'm hitting errors when trying to move WTF
clear how these exports are supposed to work. :)
-eric
On Wed, Mar 21, 2012 at 6:21 PM, Hajime Morrita morr...@google.com wrote:
I'll write a draft so that ports' expert can fill missing pieces.
--
morrita
On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel e...@webkit.org wrote:
Do we have any
On Fri, Mar 16, 2012 at 6:50 PM, Konstantin Tokarev annu...@yandex.ru wrote:
16.03.2012, 04:41, Adam Barth aba...@webkit.org:
Hi webkit-dev,
After reading last week's discussion about switching the project to
git, I wondered if it would be possible to get some of the benefits of
git-style
(From the right address again...)
On Sun, Mar 11, 2012 at 9:34 AM, Alp Toker a...@nuanti.com wrote:
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
I found some confusion here.
There are two kinds of symbols which need to be exported from WebCore.
- A. Symbols from WebCore to WebKit(API). This is basically what
WebCore.exp.in covers.
- B. Symbols from WebCore to Application. In principle, there should
be no such symbols.
But in reality
(From the right address...)
Hi Ami,
I don't think there is a consensus about that. Here is my
understanding of the current status of the export symbol management:
At first, each port has different way to split libraries. For example,
- A) Mac port (WebKit1) splits WebKit into three frameworks:
announcing new feature, it would be appreciated if you mention
these two points:
http://trac.webkit.org/wiki/AddingFeatures
Thanks,
--
morrita
On Fri, Mar 2, 2012 at 9:56 AM, Hajime Morrita morr...@google.com wrote:
Hi Beth,
Thanks for letting us know about this! The feature sounds gerat for
anyone
Hi Ashod,
On Sat, Feb 25, 2012 at 5:38 PM, Ashod Nakashian
ashodnakash...@yahoo.com wrote:
Webkit-dev,
We have --minimal to disable all optional features, but what about enabling
everything?
The use-case I have in mind is build sanity checking, where one might need
to make sure no change
On Wed, Feb 22, 2012 at 10:48 AM, Maciej Stachowiak m...@apple.com wrote:
On Feb 21, 2012, at 5:40 PM, Hajime Morrita wrote:
Hi, Thanks for starting this discussion!
To summarize, there is a rough consensus which is like:
* A. LayoutTestController (LTC) is for control test harness
Hi, Thanks for starting this discussion!
To summarize, there is a rough consensus which is like:
* A. LayoutTestController (LTC) is for control test harness.
dumpAsText() and waitUntilDone() is great example of this.
* B. EventSender and some other stuff are for emulating external
events like
(Re-sending from the right address...)
I'd +1 Adam's point.
It would be great if we can do something like webkit-build --gtk
--stable, webkit-build --chromium --canary or webkit-build
--nightly where the script read the central configuration file and
find an appropriate configuration. In this
are right. And talking about (1) is fine for this discussion to be focused.
I went off the point.
Regards,
--
morrita
Regards,
Maciej
On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote:
(Re-sending from the right address...)
I'd +1 Adam's point.
It would be great if we can do something
Hi,
The first patch for this feature is almost ready:
https://bugs.webkit.org/show_bug.cgi?id=72010 But I found that there
is not so positive atmosphere here.
Considering the feature is small and isolated enough and This API can
be taken as a sort of Cookie for LocalStorage in the context of
Does it make sense for webkit-patch post/upload to support --ping to
acknowledge a set of reviewers using a specific form of comment? As a
reviewer, some kind of specific pattern would be helpful to filter
such ping mails which contain, for example, ping:morrita@.
Maybe this can be taken as a
One concern is that Platform is too generic to put in global
namespace and it might conflict existing symbols from platform SDK or
something. But because we already have generic names like ASSERT() and
it works, this concern is just a theoretical thing.
So if it works with existing platforms, I
Hi folks,
I'm working on replacing the symbol lists with source-level annotations.
And I'd like to ask for your help and review the work.
The first target is JavaScriptCore.exp since JSC is smaller than
WebCore thus easier to attack, and the Mac port maintains the most
comprehensive symbol list.
One traditional pattern is to split a big class into a set small
classes plus a hub class
like how Adam has done for original Frame.
In that pattern, small classes has a reference to the hub class and
know its API.
I hope these small classes know just a small part of its hub class via
interface
At least we already have some of such mehods like:
void Range::getBorderAndTextQuads(VectorFloatQuad) const;
void VisiblePosition::getInlineBoxAndOffset(InlineBox* inlineBox, int
caretOffset) const;
void Posiiton::getInlineBoxAndOffset(EAffinity, InlineBox*, int
caretOffset) const;
void
Hi folks,
My team is planning to simplify spellchecking code in WebCore by
migrating old code path to new code path.
I'd like to hear your advice before moving forward.
Background:
Currently WebCore has two separate logics for spellchecking.
The first version relies on
47 matches
Mail list logo
