Re: [webkit-dev] win32 Build Issue
Brent Fulgham wrote: Hi, I just managed to get a current SVN build of WebKit to build. The instructions on the website are great, but I ran into a problem because I chose to land my working sources on my D: drive (/cygdrive/d/Development/WebKit) rather than in the suggested home directory. In this configuration, I got a number of path errors: wtk/Platforms.h: No such file or directory. I suspect that one or more of the bash scripts assumes $HOME or ~ path resulting in the error. As soon as I moved the source tree to my home directory ~/WebKit everything built properly. Has anyone else encountered this? I've not personally seen the problem, but I don't think we've had too many people build in a configuration other than the one listed on webkit.org. Could you file a bug at http://bugs.webkit.org/ describing your setup and attach the build errors you encountered? Thanks! -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Apple's feature and performance goals for WebKit
On Nov 30, 2007, at 12:27 PM, Rob Napier wrote: On Nov 29, 2007 8:59 PM, Nicholas Shanks [EMAIL PROTECTED] wrote: On 30 Nov 2007, at 00:27, Maciej Stachowiak wrote: • Ability to right-click on an element and remove it from flow (probably by adding a display: none attribute; so the DOM tree is intact) The API capabilities needed for this are there. Can't comment on it as a UI feature request. I thought contextual menus were handled by WebKit. Again, this isn't something that should only be in one client app, but ought to be everywhere HTML is rendered, so that the user experience is consistent and the feature doesn't get mis-implemented or simply left missing from some client. As a developer using WebKit, I definitely don't want my rendering to magically change just because the user wanted to change something in Safari. Some of the places I use WebKit aren't obviously HTML to the user (in an IM chat window for instance), so the fact that we would then render incorrectly would be exceedingly confusing. There's no way he would think oh, that's a WebKit configuration I made. I'm very appreciative that WebKit keeps this stuff out of the Framework so my non-browser apps don't become dependent on Safari or any other web browser. The WebKit API on Mac provides some built-in context menu items, but gives applications full customization over the context menu items. So you can either add custom context menu items, for instance to add the feature Nicholas wants, or remove existing items. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] New open committer and reviewer policy
See announcement here: http://webkit.org/blog/146/new-open-committer-and-reviewer-policy/ And document here: http://webkit.org/coding/commit-review-policy.html We'll try to get mailing lists for reviewers and committers set up as fast as possible and would like to use this community-driven policy to choose all future committers and reviewers. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] win32 Build Issue
Hi, I just managed to get a current SVN build of WebKit to build. The instructions on the website are great, but I ran into a problem because I chose to land my working sources on my D: drive (/cygdrive/d/Development/WebKit) rather than in the suggested home directory. In this configuration, I got a number of path errors: wtk/Platforms.h: No such file or directory. I suspect that one or more of the bash scripts assumes $HOME or ~ path resulting in the error. As soon as I moved the source tree to my home directory ~/WebKit everything built properly. Has anyone else encountered this? Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Re: get the bits of the complete page
hi alp, thanks a lot for the inputs.. i will try it.
regards,
Zaheer
On Nov 30, 2007 4:47 PM, Alp Toker [EMAIL PROTECTED] wrote:
Zaheer,
If you really need full page zooming so much and can't wait for the bug
to get fixed, try something like this (untested):
void webkit_frame_set_scale(WebKitFrame* frame, double scale)
{
g_return_if_fail(WEBKIT_IS_FRAME(frame));
WebKitFramePrivate* frameData = WEBKIT_FRAME_GET_PRIVATE(frame);
Frame* wframe = frameData-frame;
Document* document = wframe-document();
HTMLElement* root =
reinterpret_castHTMLElement*(document-documentElement());
RenderObject* renderer = root-renderer();
RenderStyle* style = renderer-style();
TransformOperations ops;
ScaleTransformOperation* scaleOp = new
ScaleTransformOperation(scale, scale);
ops.append(scaleOp);
style-setTransform(ops);
renderer-setStyle(style);
}
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
