On Jan 20, 2010, at 8:18 AM, Darin Adler wrote:
> Hi folks.
>
> We’ve never formalized this, but I believe that patches tagged with a
> particular platform name such as
>
> [Qt] Add new API for fluffy bunnies
>
> should be limited to one particular platform’s code. If the patch changes
>
Sounds like a good idea, I'm all for it.
Kenneth
On Wed, Jan 20, 2010 at 1:18 PM, Darin Adler wrote:
> Hi folks.
>
> We’ve never formalized this, but I believe that patches tagged with a
> particular platform name such as
>
> [Qt] Add new API for fluffy bunnies
>
> should be limited to one
Thanks, Eric, Darin. I get it.
-Yong
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Jan 20, 2010, at 2:19 PM, Yong Li wrote:
> As everyone may know, current webkit style (at least for most source code)
> for a switch statement is like this:
>
> switch (var) {
> case valueFirst:
> ...
> break;
> ...
> case valueLast:
> ...
> break;
> default:
> ASSERT_NOT_REACHED()
No, we leave out the default: That allows compilers to warn when
cases are missing.
Any time you see a default: in a WebCore switch, it's sub-optimal in my opinion.
-eric
On Wed, Jan 20, 2010 at 2:19 PM, Yong Li wrote:
> As everyone may know, current webkit style (at least for most source code
As everyone may know, current webkit style (at least for most source code)
for a switch statement is like this:
switch (var) {
case valueFirst:
...
break;
...
case valueLast:
...
break;
default:
ASSERT_NOT_REACHED()
}
This looks good. But some compilers may give a warning like: "statem
On Jan 20, 2010, at 7:08 AM, Kent Hansen wrote:
> Hello WebKit developers,
> A while ago, we, the team of Qt developers at Nokia and INdT, presented the
> idea of adding a Qt C++ API on top of JavaScriptCore [1].
> The fundamental issue back then was that our implementation was not using the
>
Hi Kent.
Generally speaking, I think building on top of the C API is a good idea.
Best,
Geoff
On Jan 20, 2010, at 7:08 AM, Kent Hansen wrote:
> Hello WebKit developers,
> A while ago, we, the team of Qt developers at Nokia and INdT, presented the
> idea of adding a Qt C++ API on top of JavaScr
As part of our port to windows CE we are using a Cairo configuration combined
with freetype. This is fairly similar to the Windows port but we are not using
the native Windows GDI/cairo layer for fonts (instead we are using cairo-ft).
However, unlike the GTK port, we did not port Pango, and so
20.01.2010, в 02:07, KwangYul Seo написал(а):
> strdup/free pairs can be safely replaced with fastStrDup/fastFree in most
> cases.
Libxml2-related code in particular could use xmlStrdup for consistency.
- WBR, Alexey Proskuryakov
___
webkit-dev mai
Hi folks.
We’ve never formalized this, but I believe that patches tagged with a
particular platform name such as
[Qt] Add new API for fluffy bunnies
should be limited to one particular platform’s code. If the patch changes more
than a trivial bit of platform-independent code, even if the
Hello WebKit developers,
A while ago, we, the team of Qt developers at Nokia and INdT, presented
the idea of adding a Qt C++ API on top of JavaScriptCore [1].
The fundamental issue back then was that our implementation was not
using the JavaScriptCore C API, which made it problematic to upstream
On Jan 20, 2010, at 2:07 AM, KwangYul Seo wrote:
> Hi,
>
> WebKit does not use malloc/free directly in favor of fastMalloc/fastFree. The
> only exception to this rule is strdup() which returns a memory that must be
> freed by free. Why don't we add fastStrDup which allocates a memory with
> f
Hi,
WebKit does not use malloc/free directly in favor of fastMalloc/fastFree.
The only exception to this rule is strdup() which returns a memory that must
be freed by free. Why don't we add fastStrDup which allocates a memory with
fastMalloc? The memory returned by fastStrDup can be freed by fastF
14 matches
Mail list logo