> It seems like a lot of churn for relatively little gain. I'd rather our time
> be focused
> on areas that actually benefit users of WebKit.
OK. I don't feel strongly enough about this to push the issue.
___
webkit-dev mailing list
webkit-dev@lists.webk
> I'm really not sure that this set of changes is going in the right direction.
> What's driving them; some abstract sense of purity, or
> reducing the chances of introducing real bugs that we've seen in the past?
Some of both. I was investigating a bug where WebCore is generating
unexpected negat
> Removing the existing subtraction operator (xxxPoint minus
> xxxPoint returns xxxSize) might be a good place to start.
I've uploaded a patch to
https://bugs.webkit.org/show_bug.cgi?id=106408 which replaces these
subtraction operators with ones that return xxxPoint, and which adds
Int/FloatSize::f
> Also, the word "position" is used to represent a tree-position in DOM in
> WebKit so please don't use that to represent a point in a screen or a layout
> coordinate system.
OK, perhaps we should use Vector2d, as is used by the Chromium port
___
webkit-d
ding confusion with Vector<>?
I guess 'Offset' is an obvious candidate, but that is probably already
too overloaded. Perhaps RelativePosition or RelativePoint?
On 4 January 2013 16:15, Simon Fraser wrote:
> On Jan 3, 2013, at 7:43 PM, Steve Block wrote:
>
>> Thanks all
Thanks all for the detailed replies.
I wasn't aware of the distinction made between points and vectors for
the purposes transforms. However, if I understand things correctly,
introducing a vector type could be considered separately from the
issue I initially raised.
It seems that everyone is agre
Hi webkit,
I was hoping that somebody could clarify the policy regarding the
correct use of Int/FloatPoint vs Int/FloatSize.
It seems that xxxPoint is consistently used to represent a position,
which makes sense. However, when representing the position of one
point relative to another, both xxxPo
There's no particular reason why this hasn't been implemented - it's
simply not high on anybody's list of priorities. Feel free to take the
bug and implement the feature if you'd like.
Steve
--
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ
Regist
> I tried to look into this, but couldn’t find a function named
> DocumentLoader::loader.
Sorry, typo.
Thanks for CC'ing me on the bug. Will re-post the corrected version there.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit
It looks like this was resolved in
https://bugs.webkit.org/show_bug.cgi?id=61494, which resulted in
http://trac.webkit.org/changeset/87756. I can't access the bug, so I'm
following up here ...
This change is causing problems on Android. We use the
AllowLocalLoadsForLocalAndSubstituteData policy bu
> You need to check with Android port owners on whether they intend to enable
> INSPECTOR in their builds and expose remote debugging capabilities.
I'm afraid we have no plans right now to enable this feature.
Steve
--
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Ro
> Is there any plan to fully merge the code, have updated LayoutTests and
> build-webkit integration?
The Android browser still uses the Android port, but as you point out,
it's not fully upstreamed. We're continuing to work on this.
> Since then, WebCore/Android.mk has been modified 81 times, but
Thanks for the reply Brady.
> The boolean in question isn't both checked and set at the same time - it's
> not an acquired resource. One
> thread sets it, the other checks it.
I don't follow. If it's set from one thread and checked from another
thread without locks, how can you guarantee this (o
>>> The boolean in question isn't both checked and set at the same time - it's
>>> not an acquired resource. One
>>> thread sets it, the other checks it.
>> I don't follow. If it's set from one thread and checked from another
>> thread without locks, how can you guarantee this (other than with
>>
I have a question about whether WebCore code makes assumptions about
the atomicity of certain read/write operations.
The particular instance I'm interested in is IconDatabase, where
m_threadTerminationRequested is written to from the main thread (in
close() for example) and read from the DB thread
> (1) Adds a level of indirection that may not be necessary in these cases.
It's true, there's now one more level of indirection. The
non-client-based implementation uses Geolocation ->
GeolocationServiceFoo. The client-based implementation uses
Geolocation -> GeolocationController -> GeolocationSe
> On the one hand, getting rid of ifdefs is good. On the other hand, it seems
> to me there are some downsides to moving ports over to the client-based
> approach:
The motivation is much more than removing ifdefs. The original
Geolocation implementation was provided in WebCore/platform,
presumabl
> Just a general question as to why the decision was made to put the mock
> implementation classes (DeviceOrientationClientMock, GeolocationServiceMock
> and SpeechInputClientMock) beneath WebCore/platform.
I added the first mock class, GeolocationServiceMock , to allow
Geolocation to be tested in
I think the code review in which the need to do this was first pointed
out to me was https://bugs.webkit.org/show_bug.cgi?id=27716#c32
I've been following this pattern for the Geolocation and
DeviceOrientation tests, all of which are skipped on GTK. If I can
instead list the directory, that would
> I'd rather the mock controller setup be ugly than the typical use of the
> controller. Having the
> controller and client on Page was quite annoying. I'd much prefer it lived on
> Document.
I'm fine with moving the controller and client from the Page to the
Document. The important thing, as I u
> - it would allow the client to live in WebCore.
> FWIW, Geolocation seems to take both approaches. One implementation is down
> in Navigator/Document/DOMWindow,
> but the mock controller is on Page. I've found the low-level approach much
> easier to implement.
My understanding was that clients
I'd be happy to help where I can too, and can migrate the existing
Geolocation/DeviceOrientation/SpeechInput mocks to use the new
pattern. Please CC me on any bugs you create.
Steve
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.web
> WebCore::LayoutTestController would be exposed to JavaScript running
> in LayoutTests directly (like the DOM), so we can skip the type
> conversions.
There might still be the need for some plumbing though. In the case of
DeviceOrientation and SpeechInput, we're mocking a client which is
provided
I'm in the process of adding a mock client for DeviceOrientation,
which will be used in DumpRenderTree to test the feature. In order to
share the mock across platforms, I'd like to add the mock to
WebCore/platform/mock.
An interface to the mock will have to be exposed to the embedder
through the p
https://bugs.webkit.org/show_bug.cgi?id=42834 has now been r+'ed. I'll
submit in the morning if there are no further comments.
Thanks,
Steve
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
I've filed https://bugs.webkit.org/show_bug.cgi?id=42834 to track the
addition of a structure to pass pointers to the clients for optional
features. Feedback welcome.
Steve
--
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ
Registered in England Nu
> That still makes it required to add null checks for some (or all) of
> the clients. Something we've avoided in the past.
This wouldn't add a need for null checks. The structure would only be
for clients for optional features. If the feature is enabled, the
client must be non-null. This is no dif
> What exactly does not scalable mean? Passing arguments to the constructor
> rather than setting
> them up later is often good because there is no time window where the object
> is not set up.
> Generally speaking we don’t want to have to write code to handle a client of
> 0 unless it’s absolut
Currently, nine clients are passed to the Page constructor and the
number is growing. Recently, clients have been added for Geolocation,
DeviceOrientation and BackForwardController. This approach doesn't
seem scalable.
Instead, I'd like to suggest that clients, at least those for optional
features
> Well that platform should manage between GPS and any other providers itself?
> So if this was implemented on iPhone, for example, the platform uses
> iPhone's CoreLocation, and it manages where it is getting the data from
> itself. That is a platform detail as I read it.
Sure, I agree.
On a
> I think that the most accurate response should be returned, especially if it
> is already known.
OK, that seems reasonable.
> I
> think having multiple providers will be the exception rather than the rule,
> so I designed around that assumption.
I'm not sure that this is true, as many devices wi
Hi,
I have a question regarding the way in which multiple sources of
location information are handled in the Geolocation API.
The Geolocation API allows the user some choice over which sources of
location information are used in a given request (a call to
getCurrentPosition or watchPosition) thro
32 matches
Mail list logo
