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 TextCheckerClient::checkTex
At least we already have some of such mehods like:
void Range::getBorderAndTextQuads(Vector&) const;
void VisiblePosition::getInlineBoxAndOffset(InlineBox*& inlineBox, int&
caretOffset) const;
void Posiiton::getInlineBoxAndOffset(EAffinity, InlineBox*&, int&
caretOffset) const;
void FrameView::getT
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
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 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
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
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
Game
(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 th
"the feature-table page" is blending (2) and (1), which
> would serve different purposes.
You 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
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 us
On Wed, Feb 22, 2012 at 10:48 AM, Maciej Stachowiak 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. LayoutTestContr
Hi Ashod,
On Sat, Feb 25, 2012 at 5:38 PM, Ashod Nakashian
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 broke code under a
When 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 wrote:
> Hi Beth,
>
> Thanks for letting us know about this! The feature sounds gerat for
>
(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:
(From the right address again...)
On Sun, Mar 11, 2012 at 9:34 AM, Alp Toker 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 bug 80062,
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 the
On Fri, Mar 16, 2012 at 6:50 PM, Konstantin Tokarev wrote:
>
>
> 16.03.2012, 04:41, "Adam Barth" :
>> 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 development without
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 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 files to their
lear what's causing those.
>
> Thank you for your attempts at documentation. Perhaps that will make
> clear how these exports are supposed to work. :)
>
> -eric
>
> On Wed, Mar 21, 2012 at 6:21 PM, Hajime Morrita wrote:
>> I'll write a draft so that po
#x27;s causing those.
>
> Thank you for your attempts at documentation. Perhaps that will make
> clear how these exports are supposed to work. :)
>
> -eric
>
> On Wed, Mar 21, 2012 at 6:21 PM, Hajime Morrita wrote:
>> I'll write a draft so that ports' expert ca
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, Arun
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 interf
(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
(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 buil
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(), wrapSlowForRegion
On Tue, Sep 18, 2012 at 8:46 AM, Eric Seidel wrote:
> On Mon, Sep 17, 2012 at 6:35 PM, Benjamin Poulain
> wrote:
> > On Mon, Sep 17, 2012 at 4:11 PM, James Hawkins
> > wrote:
> >>
> >> A few details:
> >> * Google will front the cost of the license (non-zero...very far from
> >> zero) and the i
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, l
(From right address...)
On Sun, Nov 4, 2012 at 8:14 PM, Ryosuke Niwa wrote:
> On Sun, Nov 4, 2012 at 2:45 AM, Peter Beverloo wrote:
>
>> IRC nicknames are available in committers.py, as the third argument of
>> the Contributor, Committer and Reviewer entries:
>>
>> http://trac.webkit.org/brows
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 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, UseV8.cmake
> is alrea
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 Apac
(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 once
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 if
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 i
de from this feature 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 wrote:
>
> On Jan 29, 2013, at 6:22 PM, Hajime Morrita wrote:
>
> Hi folks,
>
> I'm going to i
(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 Web
On Thu, Jan 31, 2013 at 5:49 PM, Patrick Gansterer wrote:
> 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 switche
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 includ
On Fri, Feb 1, 2013 at 10:39 AM, Ryosuke Niwa wrote:
> On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita wrote:
>
>> The history aside, I think it makes sense to use the export macro
>> specifically for Mac WebCore because
>>
>> - As Eric mentioned, Currently only
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 executab
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 namespace
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
webkit-dev@lists.
On Wed, Feb 20, 2013 at 4:29 AM, Dimitri Glazkov wrote:
> On Tue, Feb 19, 2013 at 3:50 AM, Antti Koivisto 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,
> mutating
> > functions on the
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 wrote:
> Hi all,
>
> We've replaced webkit-perf.appspot.com by perf.webkit.org.
> webkit-perf.appspot.co
On Mon, Feb 25, 2013 at 1:32 PM, Ryosuke Niwa wrote:
> On Sun, Feb 24, 2013 at 7:56 PM, Hajime Morrita wrote:
>
>> 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
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 int
tifiers to spellcheck
>> results and store the identifiers in markers. When the user performs any
>> operation on a spellcheck marker, the identifier from the marker will be
>> used in the feedback. User operations may include "Add to dictionary",
>> "Always igno
47 matches
Mail list logo