Re: [webkit-dev] Iterating SunSpider
On Jul 7, 2009, at 8:50 PM, Geoffrey Garen wrote: I also don't buy your conclusion -- that if regular expressions account for 1% of JavaScript time on the Internet overall, they need not be optimized. I never said that. You said the regular expression test was most likely... the least relevant test in SunSpider. You said implementors' choice to optimize regular expressions because they were hot on SunSpider was not what we want to encourage. But maybe I misunderstood you. Do you think it was a good thing that SunSpider encouraged optimization of regular expressions? If so, do you think the same thing would have happened had SunSpider not used summation in calculating its scores? I suspect this line of questioning will not result in effective persuasion or useful information transfer. It comes off as kind of a gotcha question. My understanding of Mike's position is this: - The slowest test on the benchmark will become a focus of optimization regardless of scoring method (thus, I assume he does not really think regexp optimization efforts are an utter waste.) - During the period when JS engines had most things much faster than the state of things when SunSpider first came out, but hadn't yet extensively optimized regexps, the test gave a misleading and potentially unfair picture of overall performance. And this is a condition that could happen again in the future. I think this is a plausible position, but I don't entirely buy these arguments, and I don't think they outweigh the reasons we chose to use summation scoring. I think it's ultimately a judgment call, and unless we have new information to present, we don't need to drag out the conversation or call each to account on details of supporting arguments. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Error during Cross compiling icu library
Hi all, I am cross compiling webkit gtk for MIPS but it is lack of icu. I built icu but get an error as below: icudefs.mk:257: /tango/usr/local/config/icucross.mk: No such file or directory It seems icucross.mk must be installed first into config folder but I don't understand why and how. Can anybody help me? Thank in advance! Hai Yahoo! Mail nay NHANH HƠN - Thử ngay! http://vn.mail.yahoo.com___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] how to port webkit on mobile
hi all, I am new in webkitgtk development. I have created webkitgtk browser and successfully tested on arm processor. now i want to port this on actual hardware . Please give me suggestion for this. Thanks in advance. Regards, Naveen -- View this message in context: http://www.nabble.com/how-to-port-webkit-on-mobile-tp24388826p24388826.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how to port webkit on mobile
Hi Not sure what harware you are talking about ? Is it some board you are talking about like OMAP3430 or so? If yes then probably you have done all things that are needed. if not then , I consider this as linux Kernel as you are talking about Gtk port. I think you will need to have a proper boot up environment for this to boot your kernel. Then obvious thing comes up to have all supporting packages that webkitgtk reqiures. You need to build them for your required platform. Not sure which window manager you will be using ? if X11 then you als need corresponding libs and load them appropriately. (Probably you must have done this as you said you tested it on arm processor ). Thanks Regards Niilesh On Wed, Jul 8, 2009 at 4:40 PM, naveen palnaveen@unnat-e.com wrote: hi all, I am new in webkitgtk development. I have created webkitgtk browser and successfully tested on arm processor. now i want to port this on actual hardware . Please give me suggestion for this. Thanks in advance. Regards, Naveen -- View this message in context: http://www.nabble.com/how-to-port-webkit-on-mobile-tp24388826p24388826.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] rendering bitmaps
Hello, Is there an API for rendering bitmaps using Webkit, so for example, if I wanted to render a bitmap image not currently defined in the HTML document's markup, can I do this? -- Regards Jack ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Error during Cross compiling icu library
Hi, You can follow the guide at http://source.icu-project.org/repos/icu/icu/trunk/readme.html#HowToCrossCompileICU Regards, -Hieu From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of deuxliquid Sent: Wednesday, July 08, 2009 3:23 PM To: webkit-dev@lists.webkit.org Subject: [webkit-dev] Error during Cross compiling icu library Hi all, I am cross compiling webkit gtk for MIPS but it is lack of icu. I built icu but get an error as below: icudefs.mk:257: /tango/usr/local/config/icucross.mk: No such file or directory It seems icucross.mk must be installed first into config folder but I don't understand why and how. Can anybody help me? Thank in advance! Hai Địa chỉ email mới dành cho bạn! http://sg.rd.yahoo.com/vn/mail/domainchoice/mail/signature/*http:/mail.promotions.yahoo.com/newdomains/vn/ Chọn ngay một tên truy nhập bạn từng muốn lập với tên miền mới ymail và rocketmail. Nhanh nhanh trước khi có người xí mất! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] extremely small in GTKLauncher
Hi all, I ran the GTKLauncher built with the webkit-rev44555, and I noticed that the html pages are displayed with an extremly small font size (even unreadable). Does any one met such a problem? regards. haithem. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] extremely small fonts in GTKLauncher
Hi all, I ran the GTKLauncher built with the webkit-rev44555, and I noticed that the html pages are displayed with an extremly small font size (even unreadable). Does any one met such a problem? regards. haithem. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] re ndering bitmaps
Hi Jack,
Example:
PassRefPtrSharedBuffer fileContent =
SharedBuffer::createWithContentsOfFile(szFileName);
if (!fileContent) {
fprintf(stderr, Could not load: %s\n, szFileName);
} else {
RefPtrBitmapImage image = BitmapImage::create();
image-setData(fileContent, true);
ctx.drawImage(image.get(), IntPoint(10, 10));
}
If using gtk/cairo, the previous code can be prefixed by (if a graphics
context is not readily available):
cairo_t* cr = gdk_cairo_create(GTK_WIDGET(widget)-window);
GraphicsContext ctx(cr);
cairo_destroy(cr);
ctx.setGdkExposeEvent(event);
Regards,
Christophe
wootton wrote:
Hello,
Is there an API for rendering bitmaps using Webkit, so for example, if
I wanted to render a bitmap image not currently defined in the HTML
document's markup, can I do this?
--
Regards
Jack
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
View this message in context:
http://www.nabble.com/rendering-bitmaps-tp24390627p24394711.html
Sent from the Webkit mailing list archive at Nabble.com.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] any progress on GObject/C DOM binding? (#16401)
Hi! Few days ago I found out about Pyjamas(-Desktop) project and became ecstatic upon the prospect of being able to use the same Python code to run both desktop and web app in a browser. However, soon I've came to know there are some showstopper preventing users fully utilize this project or forcing them to use patched version of webkit. Today I was browsing the bugzilla and it seems that the situation is summarized as: The reviewer(s) have said: - The patch must be broken up into smaller pieces before being reviewed further. I think the important take-away here is that no one has stated that the patch may never be landed, just that it needs to be broken up, reviewed and landed in pieces. I'm not sure there's much more to say at this point until you (or someone else) can find more time to work on breaking up the patch. I left my comment there, but here I'm appealing (as end-user) if some progress can be made so that we can get full DOM binding and having opportunity to enjoy in whatever pyjamas project is offering to Python coders. (Un)fortunately I do not speak Java and prefer writing in Python vs. different JS Ajax frameworks. Let's be happy that someone wrote the code and don't put policies over it. Hoping that DOM bindings will escape from its stalemate position. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 pgpooxelUxyXh.pgp Description: PGP signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCore architecture for persistent cache
Hi, It depends on each HTTP backend. Currently, libcurl does not provide HTTP cache, so you should implement HTTP cache by yourself. Or you can use other HTTP backend which provides persistent HTTP cache. Regards, Kwang Yul Seo 2009/6/17 Jeremy Serdin jser...@gmail.com: Hi all I'm trying to implement a persistent cache for WebCore with libcurl. I'm looking for some documents about webcore architecture in order to implement it in a right way. Can somebody help me? Thx, jser...@gmail.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Detecting a finished paint via JavaScript
Hi all, Firstly, apologies if this should be directed at webkit-help, rather than webkit-dev, but it seems pertinent to the internals of WebKit. I'm interested in detecting that a page has finished painting via JavaScript; something like Mozilla have implemented in Firefox via the mozAfterPaint callback. I noticed in the archive that someone was doing something like this using WebFrameLoadDelegate, but from what I can tell this is a Windows Mac only thing (?). Is this something that is achievable in the current code? Or is a comparable feature planned? -R ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Detecting a finished paint via JavaScript
On Jul 8, 2009, at 10:18 AM, RDC wrote: Is this something that is achievable in the current code? Or is a comparable feature planned? It's not, and I don’t know of any plans to add this. Would you be willing elaborate on why you want this? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Detecting a finished paint via JavaScript
Would you be willing elaborate on why you want this? Of course; I would like it for benchmarking page rendering times--something I believe would be possible with Web Inspector, but I'm after a cross-browser way of achieving it. At the moment I have a benchmark that uses the onLoad event to move onto the next page; on Firefox this sometimes results in pages being skipped as the onLoad event is triggered before any painting is done. We use the mozAfterPaint to control this somewhat (though not completely effectively--any DOM manipulation via JS causes further paint events, but by this time the onLoad has fired). Thinking more about it, perhaps it is the case that WebKit doesn't behave in exactly the same way, and the afterPaint event is not needed to guarantee that at least *some* of the page is painted before moving on. -R ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Detecting a finished paint via JavaScript
On Jul 8, 2009, at 10:45 AM, RDC wrote: I would like it for benchmarking page rendering times OK. Hyatt may have some thoughts on this. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Detecting a finished paint via JavaScript
On Jul 8, 2009, at 12:45 PM, RDC wrote: Would you be willing elaborate on why you want this? Of course; I would like it for benchmarking page rendering times-- something I believe would be possible with Web Inspector, but I'm after a cross-browser way of achieving it. At the moment I have a benchmark that uses the onLoad event to move onto the next page; on Firefox this sometimes results in pages being skipped as the onLoad event is triggered before any painting is done. We use the mozAfterPaint to control this somewhat (though not completely effectively--any DOM manipulation via JS causes further paint events, but by this time the onLoad has fired). Thinking more about it, perhaps it is the case that WebKit doesn't behave in exactly the same way, and the afterPaint event is not needed to guarantee that at least *some* of the page is painted before moving on. We behave about the same. We fire onload before both layout and paint. If you say document.body.offsetWidth inside an onload handler we end up more or less equivalent to Gecko (we will only have the paint left to do). As Robert O' Callahan wrote though, mozAfterPaint doesn't really fire after painting. It's approximate. So I'm not sure it's advisable to try to use it in a benchmarking tool. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Detecting a finished paint via JavaScript
While this is not a perfect solution, a common technique is to call (from onload) a DOM method like offsetHeight that forces layout to run. That way the bulk of the work required to paint is forced to happen before the benchmark considers the page load complete. -Darin On Wed, Jul 8, 2009 at 10:45 AM, RDC rdc49...@googlemail.com wrote: Would you be willing elaborate on why you want this? Of course; I would like it for benchmarking page rendering times--something I believe would be possible with Web Inspector, but I'm after a cross-browser way of achieving it. At the moment I have a benchmark that uses the onLoad event to move onto the next page; on Firefox this sometimes results in pages being skipped as the onLoad event is triggered before any painting is done. We use the mozAfterPaint to control this somewhat (though not completely effectively--any DOM manipulation via JS causes further paint events, but by this time the onLoad has fired). Thinking more about it, perhaps it is the case that WebKit doesn't behave in exactly the same way, and the afterPaint event is not needed to guarantee that at least *some* of the page is painted before moving on. -R ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Detecting a finished paint via JavaScript
This still omits the cost of painting from a benchmark though. dave On Jul 8, 2009, at 12:57 PM, Darin Fisher wrote: While this is not a perfect solution, a common technique is to call (from onload) a DOM method like offsetHeight that forces layout to run. That way the bulk of the work required to paint is forced to happen before the benchmark considers the page load complete. -Darin On Wed, Jul 8, 2009 at 10:45 AM, RDC rdc49...@googlemail.com wrote: Would you be willing elaborate on why you want this? Of course; I would like it for benchmarking page rendering times-- something I believe would be possible with Web Inspector, but I'm after a cross-browser way of achieving it. At the moment I have a benchmark that uses the onLoad event to move onto the next page; on Firefox this sometimes results in pages being skipped as the onLoad event is triggered before any painting is done. We use the mozAfterPaint to control this somewhat (though not completely effectively--any DOM manipulation via JS causes further paint events, but by this time the onLoad has fired). Thinking more about it, perhaps it is the case that WebKit doesn't behave in exactly the same way, and the afterPaint event is not needed to guarantee that at least *some* of the page is painted before moving on. -R ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] any progress on GObject/C DOM binding? (#16401)
WebKit has a high bar for code reviews. It's rarely possible to do a high quality code review on huge patches. This is one of the reasons developing in the open (not writing all the code and then trying to get it committed) is advantageous. I don't really see why such bindings (as cool as they are) are worth lowering the bar for submissions. Hopefully someone can split the patch up. J On Wed, Jul 8, 2009 at 9:06 AM, Gour g...@gour-nitai.com wrote: Hi! Few days ago I found out about Pyjamas(-Desktop) project and became ecstatic upon the prospect of being able to use the same Python code to run both desktop and web app in a browser. However, soon I've came to know there are some showstopper preventing users fully utilize this project or forcing them to use patched version of webkit. Today I was browsing the bugzilla and it seems that the situation is summarized as: The reviewer(s) have said: - The patch must be broken up into smaller pieces before being reviewed further. I think the important take-away here is that no one has stated that the patch may never be landed, just that it needs to be broken up, reviewed and landed in pieces. I'm not sure there's much more to say at this point until you (or someone else) can find more time to work on breaking up the patch. I left my comment there, but here I'm appealing (as end-user) if some progress can be made so that we can get full DOM binding and having opportunity to enjoy in whatever pyjamas project is offering to Python coders. (Un)fortunately I do not speak Java and prefer writing in Python vs. different JS Ajax frameworks. Let's be happy that someone wrote the code and don't put policies over it. Hoping that DOM bindings will escape from its stalemate position. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Detecting a finished paint via JavaScript
On Jul 8, 2009, at 10:45 AM, RDC wrote: Would you be willing elaborate on why you want this? Of course; I would like it for benchmarking page rendering times-- something I believe would be possible with Web Inspector, but I'm after a cross-browser way of achieving it. At the moment I have a benchmark that uses the onLoad event to move onto the next page; on Firefox this sometimes results in pages being skipped as the onLoad event is triggered before any painting is done. We use the mozAfterPaint to control this somewhat (though not completely effectively--any DOM manipulation via JS causes further paint events, but by this time the onLoad has fired). Thinking more about it, perhaps it is the case that WebKit doesn't behave in exactly the same way, and the afterPaint event is not needed to guarantee that at least *some* of the page is painted before moving on. If it's for purposes of the Web Inspector, a custom event or callback mechanism that's only available to the inspector might do. We probably want to avoid exposing the event to Web content initially, since it's hard to define the semantics clearly. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changes to prepare-ChangeLog
I didn't solve every possible problem with prepare-ChangeLog, but I tried to make it a bit less shouty. If you don't provide the --bug argument, it includes text like this: - 2009-07-08 Maciej Stachowiak m...@apple.com Reviewed by NOBODY (OOPS!). Need a short description and bug URL (OOPS!) * Scripts/prepare-ChangeLog: - If you do use --bug, it provides text like this: - 2009-07-08 Maciej Stachowiak m...@apple.com Reviewed by NOBODY (OOPS!). Make prepare-ChangeLog less shouty https://bugs.webkit.org/show_bug.cgi?id=27098 * Scripts/prepare-ChangeLog: - It also says this on the console (not in the ChangeLog): -- Please remember to include a detailed description in your ChangeLog entry. -- -- See http://webkit.org/coding/contributing.html for more info -- I think this should address the significant concerns. If there's a desire to reorder the lines or add angle brackets or whatever, people can propose follow-up changes. Also, please review my patch! Regards, Maciej On Jul 7, 2009, at 10:44 AM, Eric Seidel wrote: Oh, I did really like the idea of a prepare-ChangeLog wizard which someone suggested. Where it might ask you some of the relevant questions instead of filling in boilerplate. I continue to find it frustrating that I have to r- patches with bad ChangeLogs. :) I don't think that's so much contributer failure as it is tools failure. The tools should make it easy to do the right thing and hard to post patches which are just gonna get r-'d. -eric On Tue, Jul 7, 2009 at 10:42 AM, Eric Seidele...@webkit.org wrote: I had intended to summarize this long thread which I started. But I've since realized that we're mostly bikeshedding here, so there isn't much actionable takeaway. :( Thank you to all of you for your thoughtful responses! I'm not at all attached to the current YELLING CHANGELOG TEMPLATE. :) But I don't feel like I can draw action from this thread. I'm happy to review further changes to prepare-ChangeLog (as I'm sure others are). So if anyone feels strongly that it's currently broken, please feel free to post a patch. :) -eric On Fri, Jul 3, 2009 at 4:51 PM, David Kilzerddkil...@webkit.org wrote: On Friday, July 3, 2009 2:19:51 PM, Maciej Stachowiak wrote: What I do (and I think many of us do) is use a script that automatically fills in the commit message from the ChangeLog. The script is WebKitTools/Scripts/commit-log-editor. Setting one of these environment variables (depending on whether you're using svn or git) works great (replace $WEBKIT_SRC_DIR with the path to your webkit source, or just set them to commit-log-editor if you've added WebKitTools/Scripts to your PATH): GIT_EDITOR=$WEBKIT_SRC_DIR/WebKitTools/Scripts/commit-log-editor SVN_EDITOR=$WEBKIT_SRC_DIR/WebKitTools/Scripts/commit-log-editor You'll also want to set the EDITOR environment variable unless you use vi to edit your svn/git commit logs. :) Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Text control rules in themeWin.css
On Jul 6, 2009, at 11:47 AM, Dan Bernstein wrote:
I was looking at themeWin.css and noticed a few rules relating to text
controls. Can anyone shed a light on their purpose and why they are in
themeWin.css rather than in html4.css or in a port-specific theme?
HISTORY
This got checked in when unforking Chrome. At the time, the stated goal was
to have the theming be OS-specific and not port-specific. That's why, for
example, there's no themeChromiumWin.css. It seemed like Safari was OK with
matching Firefox/IE metrics on Windows. Now that I look back at the bug, I
think this might have gotten checked in with a poor ChangeLog description
and maybe didn't get as thorough of a review as a result.
As to the specific rules in there, Chrome tried to match IE or Firefox for
form controls. This all happened before the Safari Windows launch, so we
didn't have the option of just matching Safari. Our primary goals were to
have form controls look polished, maximize web compatibility and assist web
developers by minimizing differences from other browsers.
With respect to polish, there were mainly cases where form controls would
look poor on Windows because the default styling was for aqua controls (e.g.
rounded corners).
FUTURE
We've had a strong aversion to creating even minor rendering
incompatibilities between Safari and Chromium. We'd like, as much as
possible, to give web developers confidence that they can write code for
WebKit and have it just work in both browsers.
All the theming differences should ideally come from what OS you're on, not
whether you're using Safari or Chrome. Does that seem like a worthwhile and
achievable goal in general? Is this something we should
encourage WebKit ports to do?
Assuming we agree that's a good goal, what are the criteria by which we
decide how Windows (or Mac for that matter) controls should be themed? The
two I care about is that they 1) look good and 2) maximize web
compatibility. From my perspective, part of 2 is to only diverge from other
browsers as necessary to achieve 1.
Since the current state of the world is at least partially my fault, I'm
happy to follow through with patches for whatever the conclusions of this
discussion are.
SOME EXCEPTIONS
textarea:disabled,
input:not([type]):disabled,
input[type=text]:disabled,
input[type=password]:disabled,
input[type=search]:disabled {
background-color: #EBEBE4;
}
This rule is an exception to the polish/compatibility argument since it's
more about usability. We got a lot of bugs filed about being unable to edit
text inputs. It turned out that the text inputs were disabled, but the
disabled/enabled styling in WebKit is so subtle that people didn't notice.
This styling matches Firefox Windows. Not sure if this was the correct
decision, but probably warrants it's own discussion since a) the reasoning
for this change is totally different and b) may justify a change of some
kind to all ports.
The decision to use monospace for textareas was also a result of a bunch of
people filing bugs. I don't think we've ever had a bug where someone asked
for serif'ed fonts on textareas. :) This also somewhat has a compatibility
benefit in that textareas that use cols for sizing will size closer to
IE/Firefox metrics.
Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Coding convention of constants
Hi, It seems that there are three coding styles regarding static const int constants. [1] rendering/RenderImage.cpp static const int maxAltTextWidth = 1024; static const int maxAltTextHeight = 256; [2] rendering/RenderVideo.cpp (prefixed with c) static const int cDefaultWidth = 300; static const int cDefaultHeight = 150; [3] storage/SQLTransaction.cpp (start with a capital letter) static const int DefaultQuotaSizeIncrease = 1048576; http://webkit.org/coding/coding-style.html WebKit Coding Style Guidelines does not mention this issue. All 3 styles are acceptable? Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Coding convention of constants
I found another style which starts with k. [4] platform/chromium/PopupMenuChromium.cpp static const int kMaxVisibleRows = 20; static const int kMaxHeight = 500; static const int kBorderSize = 1; static const TimeStamp kTypeAheadTimeoutMs = 1000; 2009/7/9 KwangYul Seo kwangyul@gmail.com Hi, It seems that there are three coding styles regarding static const int constants. [1] rendering/RenderImage.cpp static const int maxAltTextWidth = 1024; static const int maxAltTextHeight = 256; [2] rendering/RenderVideo.cpp (prefixed with c) static const int cDefaultWidth = 300; static const int cDefaultHeight = 150; [3] storage/SQLTransaction.cpp (start with a capital letter) static const int DefaultQuotaSizeIncrease = 1048576; http://webkit.org/coding/coding-style.html WebKit Coding Style Guidelines does not mention this issue. All 3 styles are acceptable? Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Some new mailing lists
On Jul 6, 2009, at 11:05 AM, Adam Roben wrote: I went ahead and submitted subscription requests to Gmane for webkit- help, webkit-jobs, and webkit-gtk, since these lists don't have any history to import. These subscription requests have been processed. These lists should show up on Gmane the next time they each receive a message. The group names will be: gmane.comp.web.webkit.help gmane.comp.web.webkit.jobs gmane.comp.web.webkit.gtk -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
