Re: [webkit-dev] Review tool changes
I just want to say that I absolutely love the new review tool and the ability to select multiply lines of contents! Kenneth On Fri, Sep 17, 2010 at 4:11 AM, Darin Fisher da...@chromium.org wrote: On Fri, Sep 17, 2010 at 12:05 AM, Alexey Proskuryakov a...@webkit.org wrote: 16.09.2010, в 23:39, Adam Barth написал(а): As mentioned above, the publish button actually brings up a confirmation screen. My original plan was to eventually remove the confirmation screen, since it's fully redundant, but I can leave it if folks find it useful. It seems that for most easy reviews, the need to click twice will be a nuisance once you know how the tool works. But for larger reviews, having a look at the final text can be beneficial (just like you look over a patch just before uploading it). Yes, this describes my current experience with the tool. If I set the review flag to r+ and have made no comments on the patch, then I'd like a button to press that will just submit my r+ without any preview or further confirmation step. That said, this is just a small nit-pick. Personally, I find the existing tool to be a vast improvement already over what we had before. -Darin One thing I'd love to see added is a back-link to a bug. I find myself using that fairly often currently. A couple other folks requested this as well. The complication here is that navigating away from the tool will lose your in-progress edits. I only want this in order to open the bug in a new tab, so a _blank target would sidestep the problem. - WBR, Alexey Proskuryakov ___ 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 -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Name nitpick: layout tests
I'm fine with it as well; the name confuses a lot of new contributors. Kenneth On Thu, Jul 29, 2010 at 3:15 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Jul 29, 2010 at 10:59 AM, Darin Adler da...@apple.com wrote: Hi folks. WebKit regression tests are in a directory named LayoutTests. The object the tests uses to do special test-specific operations is layoutTestController. Both of these names are unwanted baggage, left over from when the test machinery was only good for testing layout. The directory should be eventually be named Tests or WebKitTests or RegressionTests. Eric Seidel can probably remember talking this over with me the day after we added the LayoutTests directory; sorry that I never fixed it! The object should be named testController, or perhaps someone can think of an even better name. A super-short one would probably be OK; the only practical problem is that we don’t want to choose a name that is likely to conflict with something we’ll add to HTML5 in the future. (I would have used the phrase “the web platform” instead of HTML5, which would be way better for pedants, but I think it would confuse others.) While we may be stuck with the current names for some time, we should not introduce new uses of the word layout in the context of our regression test machinery. That’s why the script is named run-webkit-tests, not run-layout-tests. I renamed that one in time, before we went wide with the WebKit project. It’s my fault we didn’t rename those other things sooner. As a first step, I suggest we make the test controller object available under its new name, and start using that name in new tests. Once we convert all the tests, we can drop the layoutTestController name entirely. Your thoughts? -- Darin Sounds good to me. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit2 build system
Currently it seems that at least icecc does not. Also, qmake which is the build system for the Qt port does not support prefix headers directly and we thus have to emulate it using the precompiled header support. Kenneth On Wed, Jul 7, 2010 at 2:27 PM, Sam Weinig sam.wei...@gmail.com wrote: It should not be necessary to use WebKitPrefix.h as a precompiled header, it is only necessary for it to be used a prefix header. Does discc also not support prefix headers? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tightening up smart pointer usage rules
6) Add validator rules that make invocation of the new operator legal only inside adoptRef and adoptPtr function calls. That is probably going to be a problem for Qt code on the WebKit API side. If we disable this rule for WebKitTools and WebKit I think we should be OK Kenneth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A proposal for Platform Mechanisms
Hi there Anders,
I think this sounds pretty fine at least from a Qt perspective; and it
will also easily enable us to let some of our platforms override the
implementation using a plugin system. We already have such a system in
place (PlatformPlugin) so that platforms can re-implement the handling
of select popups, notifications etc. I think this new system will make
it a lot easier to extend this to other areas, as needed.
Cheers,
Kenneth
On Wed, Jun 16, 2010 at 9:30 PM, Anders Carlsson ander...@apple.com wrote:
Hi everyone,
We've now reached the point in WebKit2 development where we need to be able
to override some global calls in WebCore so that we can funnel them through
to another process, in a similar way to what Chromium does. We also need to
be able to override the calls at run-time, so that we can use the same
WebCore framework with both current WebKit and WebKit2.
Here's a proposal for something I call Platform mechanisms that I hope can
be used by other ports as well as replacing the Chromium bridge long term:
The design pattern we use in WebCore for when a port wants to override
functionality is the abstract client class pattern. We have a
FrameLoaderClient per frame, a ChromeClient per Page etc. Some functionality
is global, and doesn't really belong to a specific object, for example:
* Clipboard handling
* File access
* Plug-ins.
I propose that we create an abstract class, PlatformMechanism which acts as
the starting point for accessing such functionality, something like:
class PlatformMechanism {
virtual ClipboardMechanism* clipboardMechanism() = 0;
virtual FileAccessMechanism* fileAccessMechanism() = 0;
virtual PluginMechanism* pluginMechanism() = 0;
};
class PluginMechanism {
virtual void refreshPlugins() = 0;
virtual void getPluginInfo(VectorPluginInfo) = 0;
};
The various ports would subclass PlatformMechanism, implement the various
mechanism classes and then call into WebCore to set the PlatformMechanism.
This approach gives a natural separation of the functionality. (There's of
course nothing stopping you from having a single class inherit from all of
the mechanism classes). We could also consider adding some functions to
PlatformMechanism directly, for example if a mechanism class would end up
with just a single function.
The advantage of having a single PlatformMechanism aggregator class is that
we don't need lots of setFooMechanism calls that ports would need, and if
someone adds a new mechanism class, ports will fail to build instead of
mysteriously crash when it turns out someone has forgotten to add a call to
set the mechanism.
We would also provide WebCore implementations of the various mechanisms, so
that ports that don't want to override anything would just return the WebCore
mechanisms. We could even have a WebCorePlatformMechanism class that you
could set as the default class. This would enable ports to pick where WebCore
should be used.
I would very much appreciate any comments on this, and if I don't hear any
major objections I will start landing parts of this, conditionally compiled
by a WTF_USE_PLATFORM_MECHANISM define that's turned on for Mac WebKit.
Thanks,
Anders
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit
Nice work Ojan, Will you make webkit-patch apply-attachment understand patches doing renames/mv created with git format-patch? That would be really useful. Cheers, Kenneth On Mon, Apr 26, 2010 at 2:55 PM, Ojan Vafai o...@chromium.org wrote: The behavior of git and webkit-patch changed with http://trac.webkit.org/changeset/58261. Many webkit-patch commands (e.g. upload and land) and check-webkit-style now take --squash and --git-commit arguments. --git-commit: upload, commit, check-style, etc on the given git commit(s). Commits can be specified as single commits (e.g. HEAD^) or mulitiple (e.g. HEAD~2..HEAD). check-webkit-style's sense of --git-commit is no longer all patches since the commit and --git-since is removed. The equivalent to the old check-webkit-style behavior is --git-commit=HEAD~2.. instead of just using HEAD~2. --squash: Treat all changes in the local branch as a single patch (local commits + working copy changes). Doesn't actually modify your tree until you land, at which point it squashes all local changes into a single local commit and then lands that. --no-squash: Treat all changes as separate. This is essentially just git svn dcommit. Each local change is committed separately. If you leave out --squash and --no-squash, then something resembling the old behavior is used. old-behavior: upload, diff, create-patch, etc. only considered working-copy changes and land will commit working-copy changes and then commit each local commit separately. new-behavior: is roughly like the above, except if there's only a single local commit and no working-copy changes, then the commands will work on that single local commit and otherwise raise an error. Eventually, I'd like to make --squash the default, but I want this to bake and get some usage before flipping that switch. Finally, if you get sick of typing --squash or --no-squash, you can set the webkit-patch.squash git config parameter to true/false. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSC String re-factorings are hosing the tree.
That said, the Tiger bot is often lacking behind as well, which I'm not sure should be acceptable for core builders. Kenneth On Wed, Apr 21, 2010 at 7:27 PM, Gavin Barraclough barraclo...@apple.com wrote: Hi Eric, Many apologies for the redness. These changes are pretty much complete now, so hopefully there shouldn't be any more big file moves like this too soon. One thing that was hugely useful in minimizing the breakage as much as possible while making these changes was the ews bots – these generally helped me to get my patches building cleanly on all platforms bar Windows before committing. It is a real shame that an ews bot isn't available for Windows, since this would be particularly useful - JSC changes frequently break Windows builds due to the .def files. I believe a big problem that caused the extended periods of redness was the slowness of the Windows test queues. These can lag badly behind the builds, making failures here very are easy to miss - having landed a large change, and waited to watch the waterfall stay green for an extended period of time, it was easy to be under the misapprehension that everything was okay. Only later would I discover windows test had started to fail. Clearly there is a lesson I've learned here, but maybe we can find some more hardware to throw at these queues, to help them avoid getting quite so far behind. cheers, G. On Apr 21, 2010, at 1:39 PM, Eric Seidel wrote: A large portion of the tree redness in the last 3 days is due to JSC string re-factoring. We need to build some better tools, or find some better method to land these changes w/o hosing the tree. I'm happy to help with building of said tools if folks have requests/suggestions. Broken in 58001 Fixes: 58003, 58006, 58007, 58008, 58010 Time: 55m Broken in 57904 Fixes: 57908, 57911, 57912, 57917 Time 1hr 45m Broken in 57829 Attempted fix: 57835, Rolled out in:57853 Time: 3h 21m Re-broke in 57879 Fixes: 57883, 57884 Time: 3h 3m Getting 57829 landed resulted in nearly a full work-day of tree redness. :( Also, even once a change is fixed, it will take 15 mins or so for all the bots to cycle green. -eric ___ 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 -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
Which ports are considered unmaintained? Kenneth On Fri, Apr 9, 2010 at 6:03 PM, Adam Barth aba...@webkit.org wrote: On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote: We seem to welcome pretty much any port that has an active maintainer. IMHO, that's a good thing. I wonder if we should archive ports that don't have an active maintainer (e.g., by moving them into a branch). Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Archiving the Haiku port? (was WebKit2 and all that jazz)
Last I looked there are still patches up for review for Haiku. It would be nice to know why it is not being maintained. Is that due to having no interest from their community or due to the fact that noone are reviewing the patches? Kenneth On Fri, Apr 9, 2010 at 6:26 PM, Adam Barth aba...@webkit.org wrote: Is the Haiku port actively maintained? http://trac.webkit.org/browser/trunk/WebKit/haiku/ Looking at the ChangeLog, I don't see any real activity: http://trac.webkit.org/browser/trunk/WebKit/haiku/ChangeLog Maybe we should archive it? I certainly don't want to exclude Haiku from the community. Ideally, we'd make it easy to unarchive it if folks appear who want to work on it again. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit Icon license?
Contest is fine :-) That is how our designers created the Maemo logo: https://wiki.maemo.org/Task:maemo.org_logo_contest http://wiki.maemo.org/Maemo.org_logo_contest_submissions I'm cc'ing Marcelo, who is our Brazilian Head of User Experience and Design. Cheers, Kenneth On Mon, Mar 22, 2010 at 12:55 PM, Dimitri Glazkov dglaz...@chromium.org wrote: I just reached out to the Russian icon powerhouse, Turbomilk (turbomilk.com), and they're interested in pitching in as well. Maybe we should have a contest? :DG On Mon, Mar 22, 2010 at 5:43 AM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: I have asked our designers to look into it :-) Kenneth On Mon, Mar 22, 2010 at 8:42 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Mar 19, 2010 at 4:00 PM, Darin Adler da...@apple.com wrote: On Mar 19, 2010, at 8:40 AM, Dimitri Glazkov wrote: Would you happen to know how WebKit icon is licensed? The icon currently on webkit.org has the icon for Apple’s Safari web browser in it. Because of that, Apple has provided no license to use the icon; we are continuing to use it with informal permission from Apple. Given that WebKit has been more than just the rendering engine Safari uses for quite some time now, I wonder if it'd be worth trying to come up with something unique for the project. One benefit would be that it could be used more freely. Anyone with graphic design skillz going to the WebKit meeting? :-) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Chromium layout test expectations coming today
That is really good news! Congratulation! Kenneth On Fri, Mar 19, 2010 at 2:13 PM, Dimitri Glazkov dglaz...@chromium.org wrote: WebKit folks, We're finally ready to land our port's expected results in the WebKit tree. It's been a long journey, but we are now to the point where it no longer makes sense to keep Chromium expectations separate from the rest of the WebKit. It's a pretty large chunk of files, so please bear with us -- you may experience longer-than-expected checkout time for this commit. We are also actively working on porting test_shell (Chromium's test harness) to DumpRenderTree, to enable running the tests on WebKit waterfall. Until then, you can see test run results on WebKit canaries: http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=builder=Webkit+(webkit.org)builder=Webkit+Linux+(webkit.org)builder=Webkit+Mac+(webkit.org). :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Gtk and Qt bots need love
If you cannot get it working, please add it to Skipped and I will look into it on monday when I'm back at work. I was actually talking to a co-worker about our long list of new results while on the plane yesterday and I will see if my team can dedicate a day per week to look into these. Kenneth On Fri, Mar 19, 2010 at 5:16 PM, tonikitoo (Antonio Gomes) toniki...@gmail.com wrote: Hey, these 42 missing results files on Qt are there for a while, indeed. I am also trying Kenneth and Ossy w/ the crashy Qt bot, by looking at fast/media/print-restores-previous-mediatype.html On Fri, Mar 19, 2010 at 3:41 PM, Xan Lopez x...@gnome.org wrote: On Fri, Mar 19, 2010 at 9:59 PM, Eric Seidel e...@webkit.org wrote: Gtk and Qt bots need love. Looks like Gtk needs 5 new results, and Qt needs 42. Various other tests are failing there too. Do any Qt/Gtk folks have a minute to try and green up the bots so we can start tracking regressions on those platforms again? Looking at the GTK bots. Xan -eric ___ 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 -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The tree is on fire: a tragedy of the commons
1) Contributor uploads patch and nominates it for review. 2) Patch vetted by the EWS on numerous platforms. When a non-committer uploads a patch, it is not being vet by EWS. I know that is due to security issues. It would be really nice with an option for a reviewer to accept it to run on the EWS. Kenneht ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The tree is on fire: a tragedy of the commons
That is some of the best 9 cents spend ever! Kenneth On Fri, Feb 26, 2010 at 1:58 PM, Adam Barth aba...@webkit.org wrote: On Fri, Feb 26, 2010 at 8:55 AM, Adam Barth aba...@webkit.org wrote: Amazon tells me that our current bots use about 4 GB/month of download bandwidth and 600 MB/month of upload bandwidth. I presume almost all of the bandwidth is to update the working copies of the four bots hosted there. In case you're curious, Amazon charges us 9 cents/month for that much bandwidth. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tagging bug names with a platform name: limit to platform-specific patches
Sounds like a good idea, I'm all for it. Kenneth On Wed, Jan 20, 2010 at 1:18 PM, Darin Adler da...@apple.com 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 more than a trivial bit of platform-independent code, even if the change is only for the benefit of a signle platform, I suggest we not use the platform name prefix. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Remove underscore check in check-webkit-style?
In Qt we only allow underscored in methods that start with qt_ and they are used for private API, such as for the DRT and for API that we havent had the time to API review, but are still needed by some other software products. Kenneth On Wed, Jan 13, 2010 at 9:32 PM, Darin Fisher da...@chromium.org wrote: On Wed, Jan 13, 2010 at 4:17 PM, Evan Martin e...@chromium.org wrote: On Wed, Jan 13, 2010 at 3:43 PM, Adam Barth aba...@webkit.org wrote: Current check-webkit-style and the style bot complain if code uses identifiers with underscores in their names. It turns out our code does this fairly often, especially in Qt and Gtk specific code, for example to interface with unit testing frameworks. We could either: 1) Teach check-webkit-style about these cases 2) Remove the underscore check entirely My inclination is to do (2) because I haven't seen this check find many actual style problems. However, if we think that (1) is the better road, I'll be happy to make that happen. I frequently forget the underscore rule (since all the other code I work on prefers underscores). As a beneficiary of the style checker, I'd prefer to avoid (2) if possible. ditto. this is a problem for many folks who work in both the chromium and webkit repositories. levin's idea sounds best :) -darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about PopupMenuClient
Maybe add a virtual like: virtual PlatformPopupMenu platformPopupMenu() const = 0; to HostWindow.h ? That is an option but I do not know if that is the purpose of HostWindow. Much like Qt already returns QWebPageClient for 'platformPageClient()' ? Maybe you can even re-use this QWebPageClient for the popup menu delegation too? That was discussed, but then we would have to reimplement the method at least twise and maybe more in the future, or totally change the scope of that class. Cheers, Adam -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about PopupMenuClient
Thanks for the hints. I took a look at the code, and this seems easy to implement. Kenneth On Thu, Jan 7, 2010 at 7:51 PM, Darin Fisher da...@chromium.org wrote: Chromium actually does something like this. See ChromeClientChromium. In our case, we have two modes: one where the embedder just has to wrap the given PopupContainer with a window frame, and in another mode, where the embedder is responsible for drawing the popup menu. We are forced to delegate out to the embedding application because of Chromium's sandbox, which prevents WebKit from directly communicating with the native widget system (cannot directly create an HWND for example). In the case where the embedder only supplies framing, the popup menu is drawn by embedding a ScrollView. Then, all of the drawing happens in WebCore. You can see this code in PopupMenuChromium.cpp. -Darin On Thu, Jan 7, 2010 at 2:44 PM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Hi there, A co-worker of mine is implementing the ability to reimplement how popup menus (comboboxes) etc will appear from our Qt WebKit API. As these UI delegates are per page, we thought about adding a method to our ChromeClientQt like AbstractPopupMenu* createPopupMenu(PopupMenuClient* client), but currently PopupMenuClient has no access to the page so that we can get hold of that. I guess that it is not safe to assume that PopupMenuClient::hostWindow() is always a Chrome, so would it be acceptable substituting the PopupMenuClient::hostWindow() with a PopupMenuClient::page() [1] method and then change the uses to page-chrome() ? Cheers, Kenneth [1] easily implemented as return document()-page() instead of return document()-view-hostWindow() -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Question about PopupMenuClient
Hi there, A co-worker of mine is implementing the ability to reimplement how popup menus (comboboxes) etc will appear from our Qt WebKit API. As these UI delegates are per page, we thought about adding a method to our ChromeClientQt like AbstractPopupMenu* createPopupMenu(PopupMenuClient* client), but currently PopupMenuClient has no access to the page so that we can get hold of that. I guess that it is not safe to assume that PopupMenuClient::hostWindow() is always a Chrome, so would it be acceptable substituting the PopupMenuClient::hostWindow() with a PopupMenuClient::page() [1] method and then change the uses to page-chrome() ? Cheers, Kenneth [1] easily implemented as return document()-page() instead of return document()-view-hostWindow() -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] QtConnectionObjects not cleaned up for QtOwnership objects
This should go to the webkit...@lists.webkit.org list instead. Please repost
there.
Creating a bug report on bugs.webkit.org for tracking your issues is another
welcome option.
Kenneth
On Tue, Dec 15, 2009 at 5:24 PM, Andrew Webster apwebs...@gmail.com wrote:
For all the Qt people out there, here is my problem:
We have quite a few QObjects that we are inserting into JavaScript
using addToJavaScriptWindowObject, however because we have limited
resources and are creating so many of these objects, we would prefer
that they are NOT ScriptOwnership objects so that there is not as much
duplication for each frame. This presents a problem when it comes to
using 'connect' to handle signals. Each connect creates a
QtConnectionObject which references the JSHTMLDocument object. The
QtConnectionObject is never destroyed because the QObject is never
destroyed, and this prevents most of the objects from being cleaned up
by the gc when the page is refreshed leading to a significant memory
leak.
The solution I'm working on essentially makes the QtConnectionObject
'script owned' so that it is cleaned up when the script is destroyed:
Index: qt_runtime.cpp
===
--- qt_runtime.cpp (revision 52150)
+++ qt_runtime.cpp (working copy)
@@ -1527,6 +1527,11 @@
else {
// Store connection
connections.insert(sender, conn);
+// also create a script wrapper for the
connection object, but make sure that it is destroyed when
+// the script goes away
+d-m_instance-rootObject()-gcProtect(
+ QtInstance::getQtInstance(conn,
d-m_instance-rootObject(), QScriptEngine::ScriptOwnership)-
+
createRuntimeObject(exec-dynamicGlobalObject()-globalExec()));
}
} else {
// Now to find our previous connection object. Hmm.
This seems to be working in my limited tests. Can anyone comment on
the validity of this solution?
Thanks,
Andrew
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms
Nice, that change would make it compatible with the Qt style guide! I:-) I
say go for it!
Kenneth
On Thu, Dec 3, 2009 at 2:00 AM, Peter Kasting pkast...@google.com wrote:
This is a followup to my thread yesterday regarding consistent enforcement
of the style guide. Like Yong Li, I find the current rule about braces on
conditional arms to be suboptimal. The current rule is that one-line arms
must not have braces. This leads to strange constructions like:
if (foo) {
a;
b;
c;
// etc., very long body
} else
x;
...or perhaps:
if (foo)
a;
else if (bar) {
b;
c;
} else if (baz)
d;
else if (qux) {
e;
f;
}
I find this tricky to read and error-prone. I propose that the rule be
modified to be:
* When all arms of a conditional or loop are one physical line, do not use
braces. If any arms are more than one physical line (even if they are one
logical line), use braces on all arms.
In most places this will not differ from the existing code, so it will not
cause the whole codebase to become invalid; but it prevents cases where
the inconsistency leads (IMO) to lower readability/safety. (As a bonus for
Chromium developers, it's compatible with the Google style guide too,
although it goes further than that guide in order to make the correct style
explicit in all cases.)
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms
I'm OK with both. Peter's is my preferred solution, though.
Kenneth
On Thu, Dec 3, 2009 at 11:39 PM, Dirk Pranke dpra...@chromium.org wrote:
+1. Peter's is better than Maciej's is better than status quo.
-- Dirk
On Thu, Dec 3, 2009 at 6:24 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Dec 3, 2009 at 6:15 PM, Maciej Stachowiak m...@apple.com wrote:
On Dec 3, 2009, at 5:48 PM, Michael Nordman wrote:
what peter pitched and what mjs pitched are one and the same i think
* When all arms of a conditional or loop are one physical line, do not
use
braces. If any arms are more than one physical line (even if they are
one
logical line), use braces on all arms.
One possible conservative modification to the rule is that if you
have
a multi-block if ... else if ... else chain, then if even one body
has
braces, all should. I think that would tend to reduce rather than
increase
visual noise, as all the else keywords would line up where right
now they
look ragged.
To be clear: my intent was to propose something different than Peter's
suggestion. Specifically, I suggest we do *not* change the rule for a
simple
if/else statement with only two clauses. Those would still be able to
have
braces on only one of the two clauses. But if/else chains of more than
two
clauses would have to be consistent.
For anyone who agreed with my suggestion, you may want to consider
whether
you still agree in light of this clarification.
Is this formally up for a vote then?
For what it's worth, I think Peters is the most readable, but Maciej's is
better than what it is now. I find stuff like
if (blah)
blah
else {
blah
}
very distracting. But stuff like
if (blah)
blah
else if (blah)
blah
else if (blah) {
blah
} else
blah
is definitely even worse.
___
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
--
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] style-queue entering beta
Maybe in the case of failure, provide a link to further information? Kenneth On Sun, Nov 29, 2009 at 3:44 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 28, 2009, at 10:53 AM, Adam Barth wrote: On Sat, Nov 28, 2009 at 10:21 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 28, 2009, at 2:21 AM, Adam Barth wrote: 1) Adding an extra flags is going to cause confusion. The style-queue does not add any flags to Bugzilla. Instead of storing it's state in Bugzilla flags (like commit-queue does), we built an AppEngine web service to hold the queue's persistent state. Instead of indicating style errors with a negative flag, the bot adds a comment to the bug. It does seem that flags are noisy in an unappealing way, but it would be much better (IMO) to store this information in the bugzilla database instead of externally. Is there any way we can do that? From an implementation point of view, either way is easy now that we've got the infrastructure built. It's a question of which you'd prefer. Could we make a flag that is hidden in the default UI, or use specially formatted comments that the bot knows how to recognize? From my point of view, a hidden flag could work. We considered specially formatted comments, but that would make the bot more chatty. For example, if the style-queue has some internal error that prevents it from processing the patch, it wants to remember that, but it doesn't want to spam the bug with that information. I'm not sure representing all the state in Bugzilla is necessary. We should represent the most interesting state (e.g., pass / fail) there. For the rest, we can have a dashboard similar to build.webkit.org that shows the status of various patches before they are committed. I've started sketching something rough here: http://webkit-commit-queue.appspot.com/static/details.html Pass/fail status sounds fine to me. I agree that an error by the bot should not be highly visible in the bug, as that is not as useful to the review and submitter as Pass or Fail and Here's the Mistakes. You can imagine clicking those squares to see the full log of what happened. For example, if the build failed on Qt, you might want to see the full output of build-webkit --qt, but we don't need to post all that to Bugzilla. The comment might just say: Looks like a decent design. Patch 86912 did not build on Qt. Build log: http://webkit-commit-queue.appspot.com/patch-status/build-queue-qt/86912/all At a higher level, I'm sympathetic to Mark's concerns about what the system will look like when we have a number of bots. Bugzilla flags work well for receiving input from humans. There are lots of choices for how to present output. For example, another option is to have a bunch of colored squares next to each attachment that represent that patch's row on the dashboard. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [50959] trunk/WebKitTools
FYI this in not just related to Qt, as at least both win and mac have similar code. Kenneth On Fri, Nov 13, 2009 at 5:34 PM, Alexey Proskuryakov a...@webkit.org wrote: I'm not sure if this is a great approach. Previously, people with other default locales exercised code paths that aren't normally taken on U.S. systems, and thus could catch problems affecting shipping products early. It is beneficial that DRT results get more predictable, but tests are most useful when they fail, not when they pass :) - WBR, Alexey Proskuryakov 13.11.2009, в 12:04, kenn...@webkit.org написал(а): Revision50959 http://trac.webkit.org/projects/webkit/changeset/50959 authorkenn...@webkit.orgdate2009-11-13 12:04:24 -0800 (Fri, 13 Nov 2009)Log Message Set the locale to C and not to the current one in use on the system. Reviewed by Simon Hausmann. * DumpRenderTree/qt/DumpRenderTree.cpp: (WebCore::DumpRenderTree::resetToConsistentStateBeforeTesting): Modified Paths - trunk/WebKitTools/ChangeLog#124ef40dcff4f255_trunkWebKitToolsChangeLog - trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp#124ef40dcff4f255_trunkWebKitToolsDumpRenderTreeqtDumpRenderTreecpp Diff Modified: trunk/WebKitTools/ChangeLog (50958 = 50959) --- trunk/WebKitTools/ChangeLog 2009-11-13 19:56:43 UTC (rev 50958) +++ trunk/WebKitTools/ChangeLog 2009-11-13 20:04:24 UTC (rev 50959)@@ -1,3 +1,12 @@+2009-11-13 Kenneth Rohde Christiansen kenn...@webkit.org + +Reviewed by Simon Hausmann. + +Set the locale to C and not to the current one in use on the system. + +* DumpRenderTree/qt/DumpRenderTree.cpp: +(WebCore::DumpRenderTree::resetToConsistentStateBeforeTesting): + 2009-11-13 Adam Roben aro...@apple.com Finish replacing worldIDs with world objects Modified: trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp (50958 = 50959) --- trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp2009-11-13 19:56:43 UTC (rev 50958) +++ trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp2009-11-13 20:04:24 UTC (rev 50959)@@ -304,8 +304,8 @@ m_page-undoStack()-clear(); -QLocale qlocale; -QLocale::setDefault(qlocale);+QLocale::setDefault(QLocale::c()); +setlocale(LC_ALL, ); } void DumpRenderTree::open(const QUrl aurl) ___ webkit-changes mailing list webkit-chan...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A bot-filled future?
I think that sounds like a really good idea, and I can see my self using that when touching cross platform code. Kenneth On Thu, Nov 12, 2009 at 4:37 PM, Adam Barth aba...@webkit.org wrote: As the project grows, we need to scale our processes to match. In large part, that means automating as much work as possible. Commit-queue has done a good job of solving the land patches from non-committers efficiently problem, effectively removing that as a pain point. I'd like to ask you to open your hearts and your minds to the idea of automating more of our processes. Currently, I see the biggest pain-point in our process as the always-burgeoning pending-review list. It's difficult to automate the process of accepting good patches because that requires attention from experts. Instead, I think we should make it easier to reject bad patches. As a first step, I've started extending bugzilla-tool to be a try server in https://bugs.webkit.org/show_bug.cgi?id=31422. Here's how this might work: 1) Contributor posts patch for review. 2) Committer marks patch with the try? flag. 3) The try-queue downloads, applies, builds, and tests the patch. 4) If all systems are go, the try-queue marks the patch as try+. Otherwise, it marks the patch as try- with an explanation of what went wrong. The try-queue will be purely optional and advisory. Hopefully a try- notation will encourage the contributor to post a new version of the patch that passes the try-queue. Further down the road, one can also imagine another bot that automates step (2) by scanning the pending-review list for untried patches and marking them as try? when the try-queue has unused bandwidth. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MathML Project - Interested?
I cannot say that I will be using it soon, but I really like the project and think that it can become very important for MathML and the web in general. As a Qt developer, it would also open the door for our users to integrate math into their applications. Cheers, Kenneth On Mon, Oct 5, 2009 at 5:04 PM, Alex Milowski a...@milowski.org wrote: I'd like to work on this MathML project in conjunction with those of you who might be interested in using it in the near future. I'd also welcome any help. If you are interested, even as an observer, let me know. -- Kenneth Rohde Christiansen Technical Lead / Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Coding Style: Clarify some cases with spacing
Hi there, In bug 27499 (https://bugs.webkit.org/show_bug.cgi?id=27499) it was pointed out that the coding style guide doesn't clarify whether it is allowed to place a space before a comma or semicolon in a control condition or in functions. Thus asking the question whether the three following code snippets are should be discouraged by the coding style guide or not: for (int i = 0 ; i 10 ; i++) doSomething(); // Qt's foreach foreach (QString item , items) doSomething(); f(a , b); Personally I would opt for discouraging this, which David Levin points out to be more or less the current project style. If we can agree on this, I can patch the coding style guide. Cheers, Kenneth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MIPS port problem - cti_op_put_by_id slow case problem
That doesn't mean that you cannot develop it in the open. We can integrate the code once you are ready to do so. Kenneth I've talked to my client, and he's told me it's their intent to contribute the port back to the community once the port is finished. IMHO main problem with trying to contribute the code now is they have milestones, and there aren't enough resources to coordinate the merging of all the MIPS architecture-specific code back to mainline. Toshi ___ 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] MIPS port problem - cti_op_put_by_id slow case problem
When then I guess that you can only expect to get help after you have contributed the code back to the community. ;-) Good luck with your port anyway. Kenneth On Wed, Jun 17, 2009 at 6:29 PM, Toshiyasu Moritatm_web...@yahoo.com wrote: kenneth.christian...@openbossa.org wrote: That doesn't mean that you cannot develop it in the open. We can integrate the code once you are ready to do so. Kenneth You're preaching to the choir. It's not my decision to make. Toshi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] arm jit
Hi there, I would also say that is it pretty understanding that Apple does not share information about working on a ARM JIT targeting thumb2, especially as this can be used to foresee the hardware of future iPhone models. Something they are probably not interesting in revealing. I agree whole-hearted with Holger, that the chances for getting ARM JIT enhancements upsteamed now have been greatly improved; and with Apple working on the same code I would expect good reviews and lots of care for the ARM code base. We really rely on you guys for bringing the ARM JIT code to other versions of ARM, and I would like to say that I consider your contributions important and very welcome, and would like to encourage your to keep contributing! Please keep up the good work! Kenneth On Tue, Jun 9, 2009 at 9:20 PM, Holger Freytherze...@selfish.org wrote: On Tuesday 09 June 2009 23:38:43 Akos Kiss wrote: Dear Community, Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514) Congratulations on getting this working!, great job. I cannot conceal how disappointed I am, as is the whole team at Szeged. I can understand how bad you feel and I agree that Apple does not comment on future products.-mantra can suck at times. When you look at the ARM JIT of Apple you will see they mostly target Cortex-A8 (thumb2, vfp) and IIRC your JIT is much wider (supporting many more existing devices). So my bottom line is something like please don't give up, and contributing to the JIT should be more easy now. E.g. pick a topic/theme for your work and try to get it in. I can not share that WebKit is not a open community. Of course there are vendor interests and Apple, Nokia and Torchmobile don't share some of them. E.g. Apple probably does not see the value of XHTML MP, ECMA MP and WML and still these changes go on... z. ___ 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] Coding style
Hi there,
I'm having a question regarding the coding style.
According to 2. An else statement should go on the same line as a
preceding close brace.
I would always need a brace when using if-else, in order to but the
else statement on the same line as the preceding close brace, is this
right?
or would something like this is OK:
if (condition)
func1();
else
func2();
And what about this case
if (condition)
func1();
else {
func2();
func3();
}
It would be nice to have this defined in the coding style, as well as
adding the case that when you have a comment inside a one line if
statement you will need braces, like
if (condition) {
// comment
func()
}
Cheers, Kenneth
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Coding style
OK, done! :-)
https://bugs.webkit.org/show_bug.cgi?id=26188
Cheers,
Kenneth
On Thu, Jun 4, 2009 at 12:13 PM, David Kilzer ddkil...@webkit.org wrote:
Hi Kenneth,
The examples you give below are correct (with the exception of the number of
spaces used to indent the code in the else blocks).
Please file a bug on bugs.webkit.org and attach a patch. The webkit.org web
site is in the svn repository, so you may create patches against the HTML.
Thanks!
Dave
From: Kenneth Christiansen kenneth.christian...@openbossa.org
To: webkit-dev webkit-dev@lists.webkit.org
Sent: Thursday, June 4, 2009 7:52:29 AM
Subject: [webkit-dev] Coding style
Hi there,
I'm having a question regarding the coding style.
According to 2. An else statement should go on the same line as a
preceding close brace.
I would always need a brace when using if-else, in order to but the
else statement on the same line as the preceding close brace, is this
right?
or would something like this is OK:
if (condition)
func1();
else
func2();
And what about this case
if (condition)
func1();
else {
func2();
func3();
}
It would be nice to have this defined in the coding style, as well as
adding the case that when you have a comment inside a one line if
statement you will need braces, like
if (condition) {
// comment
func()
}
Cheers, Kenneth
___
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] SharedWorkers alternate design
I believe Qt uses instance() in this situation. Sadly we have not yet found a good verb for the common get or create idiom. Cheers. Kenneth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] YARR
Hi there, I made a patch that replaces WREC usage in the Qt port by YARR, but I'm having a few questions. 1) Does it make sense to enable ENABLE_YARR by default and use it even when we have no JIT support. 2) Does the YARR JIT depend on the JSCore JIT, or is it a separate JIT. If so, does it work on the same platforms at the JSCore JIT? Thanks in advance, Kenneth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] YARR
Great! I notices that RegExp.h still includes WREC, will that be changed? If it requires the JIT why are there both a ENABLE_YARR and an ENABLE_YARR_JIT ? Cheers, Kenneth On Tue, May 19, 2009 at 9:52 PM, Geoffrey Garen gga...@apple.com wrote: If so, does it work on the same platforms at the JSCore JIT? What problems are those? Oops! platforms Yes, it works on the same platforms as the JSCore JIT. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How webkit deallocate memory?
There is also the FontCache growing, I do not know if there is a setting for that as well, but on shutdown I empty ours in order to be able to finalize FontConfig. -Kenneth On Thu, Jan 8, 2009 at 7:03 AM, Ariya Hidayat ariya.hida...@trolltech.com wrote: Why did it happen? Is there a way to deallocate memory from a webkit object (for example, when close a tab which contains a page loaded)? Or, Does webkit only deallocate memory when the browser process is killed? (This does not answer your questions directly) For QtWebKit, you may want to have a look at QWebSetings, e.g. setMaximumPagesInCache(). In general, also have a look at PageCache classs (WebCore/history/PageCache.cpp). -- Ariya Hidayat, Software Engineer Qt Software, Nokia Devices RD ___ 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] Possible crash in FrameView::endDeferredRepaints()
Hi there, I had a crash the other day and found some code that looks wrong to me. The affected method is FrameView::endDeferredRepaints() found in WebCore/page/FrameView.cpp unsigned size = d-m_repaintRects.size(); for (unsigned i = 0; i size; i++) repaintContentRectangle(d-m_repaintRects[i], false); The problem here is that repaintContentRectangle auments (d-m_repaintRects.append(r)) the items in m_repaintRects or clears it (d-m_repaintRects.clear()), thus the size of m_repaintRects[] changes while iterating it, which can result in a crash. Cheers, Kenneth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
