Re: [webkit-dev] Is it possible to block webkit_web_view_load_html_string() until the content is actually loaded?
On Monday 04 May 2009 06:36:46 Zhe Su wrote: Hi, I'm writing an application which uses webkit to display some html content. webkit_web_view_load_html_string() is used to set content into webkit. I found this function will return before the content is actually loaded, then webkit will load the content in background. However my application needs block until the content is actually loaded. I know that webkit has a signal load-finished, which will be emitted when the content is fully loaded. But because of some limitation, my application can only block at somewhere until the content is fully loaded. Because it's a single thread application, I don't know how to do it. Any suggestions to solve this problem? Run your own event loop and leave it once load-finished got called or your timeout is reached... ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is it possible to block webkit_web_view_load_html_string() until the content is actually loaded?
It works. Thanks a lot. On Mon, May 4, 2009 at 4:33 PM, Holger Freyther ze...@selfish.org wrote: On Monday 04 May 2009 06:36:46 Zhe Su wrote: Hi, I'm writing an application which uses webkit to display some html content. webkit_web_view_load_html_string() is used to set content into webkit. I found this function will return before the content is actually loaded, then webkit will load the content in background. However my application needs block until the content is actually loaded. I know that webkit has a signal load-finished, which will be emitted when the content is fully loaded. But because of some limitation, my application can only block at somewhere until the content is fully loaded. Because it's a single thread application, I don't know how to do it. Any suggestions to solve this problem? Run your own event loop and leave it once load-finished got called or your timeout is reached... ___ 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] Proposal for a new way to handle porting #ifdefs
We pursued the same goal for a couple of years. Since our porting targets are various middleware CE platforms, we had to identify and adapt WebKit needs at a better grained level than platform. In order to do this we collected all dependencies in a Browser Abstraction Layer (BAL directory). The configuration is handled by a Base directory (definition of types, platform specifications) and we use CMake to define platform specificities (and it's a great cross- platform tool). Sure the BAL model has still improvements ahead of it, but it has the merit of existing, being widely tester on a quite wide range of targets, configurations and libraries. Regards Mario Le Friday 01 May 2009 01:12:54 Maciej Stachowiak, vous avez écrit : I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation macros would still be defined in Platform.h based on sniffing the environment, this would include things like the compiler, the underlying OS, available libc functions, and so forth. Platform adaptation macros would be: OS() - underlying operating system; only to be used for mandated low- level services like virtual memory, not to choose a GUI toolkit Examples: OS(UNIX) - Any Unix-like OS OS(DARWIN) - Underlying OS is the base OS X environment OS(FREEBSD) - FreeBSD OS(WIN) - Any version of Windows OS(WINCE) - The embedded version of Windows COMPILER() - the compiler being used to build the project Examples: COMPILER(GCC) - GNU Compiler Collection COMPILER(MSVC) - Microsoft Visual C++ COMPILER(RVCT) - ARM compiler HAVE() - specific system features (headers, functions or similar) that are present or not Examples: HAVE(MMAP) - mmap() function is available HAVE(ERRNO_H) - errno.h header is available HAVE(MADV_FREE) - madvise(MADV_FREE) is available Policy decision macros would be: USE() - use a particular third-party library or optional OS service Examples: USE(SKIA) - Use the Skia graphics library USE(CG) - Use CoreGraphics USE(V8) - Use the V8 JavaScript implementation USE(CFNET) - Use CFNetwork networking USE(NSURL_NET) - Use NSURLConnection-based networking USE(APPKIT) - Use AppKit views and events USE(GTK) - Use Gtk+ USE(QT) - Use Qt USE(QUICKTIME) - Use the QuickTime media engine USE(QTKIT) - Use the QuickTime media engine via the Mac QTKit API USE(QUICKTIME_WIN) - Use the QuickTime media engine via its Windows API ENABLE() - turn on a specific feature of WebKit Examples: ENABLE(ACCESSIBILITY) - Enable support for assistive technologies (currently wrongly a HAVE) ENABLE(XSLT) - Include XSLT support
[webkit-dev] link-following feature for our new webkit browser
Hi there,
I'm contributing to a project called uzbl [1]. It uses webkit(gtk) to
render content.
I tinker on a follow-link feature, which should provide a keyboard
driven link navigation, very similar to the firefox plugin Hit-a-Hint
[2] or Vimperator [3]. Since GObject/C DOM bindings probably take
some time to be released [4], we started with some basic javascript-
hacking through webkit_web_view_execute_script:
1. Mark all links with its index in document.links:
for (var i=0; i document.links.length; i++)
{ var li = document.links[i]; li.innerText = i+' '+li.innerText; };
2. Go to link $i:
window.location = document.links[i].href;
This isn't nice at all, becaus it doesn't work with ajax-ish webpages.
As an alternative we imagined this would be the best solution:
2. Request link $i:
document.links[i].click();
But click() in webkit is not for A elements, just for buttons.
I would love to hear your opinion about this - is there a way to
simulate a proper mouseclick on a link in webkit? Or do you see other
ways to achieve this feature in webkit?
[1] http://www.uzbl.org/
[2] http://hah.mozdev.org/
[3] http://vimperator.org/
[4] https://bugs.webkit.org/show_bug.cgi?id=16401
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Printing using WebKit on Windows
Hello I want to use WebKit for printing HTML files. Are there any exported DLL functions for this (including page setup)? Or maybe this is possible using ActiveX? Thanks, Pawel ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] link-following feature for our new webkit browser.
04.05.2009, в 17:19, Jan Kolkmeier написал(а): 2. Go to link $i: window.location = document.links[i].href; This isn't nice at all, because it doesn't work with ajax-ish web pages. As already asked on IRC, could please clarify what you mean by doesn't work? In particular, the following works as I would expect it to: a href=javascript:alert(0)link/a scriptwindow.location = document.links[0].href;/script - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] link-following feature for our new webkit browser.
Hi there,
I'm contributing to a project called uzbl [1]. It uses webkit(gtk) to
render content and follows the unix philosophy.
I tinker on a follow-link feature, which should provide a keyboard
driven link navigation, very similar to the firefox plugin Hit-a-Hint
[2] or Vimperator [3]. Since GObject/C DOM bindings probably take
some time to be released [4], we started with some basic javascript-
hacking through webkit_web_view_execute_script:
1. Mark all links with its index in document.links:
for (var i=0; i document.links.length; i++)
{ var li = document.links[i]; li.innerText = i+' '+li.innerText; };
2. Go to link $i:
window.location = document.links[i].href;
This isn't nice at all, because it doesn't work with ajax-ish web pages.
As an alternative we imagined this would be the best solution:
2. Request link $i:
document.links[i].click();
But click() in webkit is not for A elements, just for buttons.
I would love to hear your opinion about this - is there a way to
simulate a proper mouse click on elements in webkit? (it would be nice
to click checkboxes etc. as well) Or do you see other ways to achieve
this feature in webkit?
[1] http://www.uzbl.org/
[2] http://hah.mozdev.org/
[3] http://vimperator.org/
[4] https://bugs.webkit.org/show_bug.cgi?id=16401
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] when can I treat a JSValueRef as a JSObjectRef?
Since JSValueRef and JSObjectRef are typedef's to the same OpaqueJSValue structure (pointer), it appears you could almost use them in the same contexts. And if fact, it appears you can use a JSObjectRef wherever a JSValueRef is defined in the API. And you can sometimes use a JSValueRef wherever a JSObjectRef is defined. It would be nice to see this documented a little better. My current guess is that if JSValueGetType() returns kJSTypeObject for a JSValueRef, you can safely treat it as a JSObjectRef. If it doesn't, then you can't. Guess is based on looking at the code, seeing the pointer dereferenced in the JSObjectRef cases, but knowing that those pointers are actually sometimes tagged pointers for literal values, in which case the dereference won't work. -- Patrick Mueller ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] when can I treat a JSValueRef as a JSObjectRef?
On May 4, 2009, at 10:17 AM, Patrick Mueller wrote: Since JSValueRef and JSObjectRef are typedef's to the same OpaqueJSValue structure (pointer) It’s easy to get the wrong idea about this by looking at the implementation. These two typedefs use the same structure, but they use const in an unusual way to make the compiler check the relationship between the types. Because of how the types are defined all JSObjectRef values work as JSValueRef values without any type cast. There are many JSValueRef values that are not JSObjectRef values, so converting from one to the other requires a type cast. If you want to use a JSValueRef as a JSObjectRef, you need to call JSValueIsObject and if it’s true, then you can cast the JSValueRef to a JSObjectRef. Or you can use JSValueGetType, but that could be less efficient so you should use it only if you care which specific type it is if it’s not a JSObjectRef. It would be nice to see this documented a little better. What documentation were you reading? Since WebKit is an open source project, if you have improvements to, say, the comments in the header, you can submit them as a patch. Most of the mechanics are covered at http://webkit.org/coding/contributing.html , although some of the steps don’t apply for changes that are entirely in comments. If this was some Apple documentation you were reading, not generated directly from the header file, then you could instead file a bug at http://bugreport.apple.com suggesting improvements. My current guess is that if JSValueGetType() returns kJSTypeObject for a JSValueRef, you can safely treat it as a JSObjectRef. If it doesn't, then you can't. Yes, that’s right. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] when can I treat a JSValueRef as a JSObjectRef?
Darin Adler wrote: What documentation were you reading? Since WebKit is an open source project, if you have improvements to, say, the comments in the header, you can submit them as a patch. Most of the mechanics are covered at http://webkit.org/coding/contributing.html, although some of the steps don’t apply for changes that are entirely in comments. If this was some Apple documentation you were reading, not generated directly from the header file, then you could instead file a bug at http://bugreport.apple.com suggesting improvements. Thanks for the quick reply. The docs I was reading were in fact the Apple docs, which AFAIK are the only docs for JavaScriptCore. When working at the API level, I try to stick to docs instead of code, but sometimes I cheat :-) Actually, I learned a lot by printing out pointer values, without even looking at the impl. Maybe it would make sense for webkit.org to host something similar to the apple docs, located here, http://developer.apple.com/documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/ so that mortals could contribute back to that level of documentation. At the minimum, I suspect the turn around time in getting changes to such doc would be quicker than going through official Apple support. I'll file a report at the apple site in the meantime though. -- Patrick Mueller ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] when can I treat a JSValueRef as a JSObjectRef?
On May 4, 2009, at 10:53 AM, Patrick Mueller wrote: The docs I was reading were in fact the Apple docs I believe the document you cited is automatically generated from the comments in the JavaScriptCore headers. So if we improve the documentation comments in the headers in the WebKit open source project, eventually the Apple reference document will get those same fixes. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Where should design descussions take place? (WAS: Bug 25436: Refactor appCache for use in multi-process browsers)
That makes perfect sense. Sorry about the confusion. :-) J On Sat, May 2, 2009 at 3:55 PM, Maciej Stachowiak m...@apple.com wrote: On May 1, 2009, at 1:15 PM, Jeremy Orlow wrote: For context, the discussion started here: https://bugs.webkit.org/show_bug.cgi?id=25436 Alexey Proskuryakov said: Maybe it would make sense to discuss this on the mailing list in order to determine whether this should be a model for other projects potentially using WebKit in multi-process configuration. *I* said: As for your comment about using the mailing list, this is somewhat ironic since we've been told that it's much more helpful to have these kinds of discussions in bugs rather than the mailing list. :-) Alexey Proskuryakov said: I imagine this was probably said about a discussion of some particular bug, not of a general design issue. We were actually talking about design discussions like this one. The original context was my email on how to make localStorage multi-process aware. Where we discuss designs doesn't matter to me, but I would like to reach a consensus on the subject. Design discussions about new features with broad impact should be on the mailing list. These are things that the community should be aware of and that many may wish to comment on. Discussions about the details of fixing specific bugs should be in the bug. I realize there may be a fine line at times. Personally I prefer to have technical discussion on the webkit-dev list, unless it is of extremely narrow interest. I would prefer to see this list used for discussion of design issues in WebKit, instead of requests for help building or using the API or adding non-public features. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Notifications API for workers
Thanks Maciej for the feedback. We are definitely concerned with making this feature resistant to abuse, since everyone agrees we don't want to create another class of annoying or insecure pop-ups. A good amount of thought has preceded the code, although I probably didn't coordinate the distribution of the design very well. In the design doc I did send to whatwg ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html), there are several options presented for how to prevent unwanted popups via notifications, such as: it can be mitigated by separating applications into trust zones defined by the user-agent, where trust is granted by the user. Desktop placement is limited to trusted origins... So what I meant by similar to popups was just that background notifications should only be allowed if the user has given permission in advance, which has been my experience with popups (though maybe I got that idea from non-WebKit browsers). The design also reflects some thoughts into preventing phishing: It is recommended that HTML notification bubbles always contain a recognizable browser frame, which displays the origin source of the bubble and identifies HTTPS and other security elements in a standard way. Regarding the issue of making the notifications stop, I think HTML notifications should always have an options control in the frame which makes this easy. In terms of the implementation so far, the code provides a pass-through from the worker script to a NotificationProvider interface in the WebKit client, which can should go through a security policy before showing anything to the user. I think that leaves things flexible for stopping abuse paths, both the ones we already have thought of and anything that might occur later. If you have ideas to move specific enforcement rules into WebKit itself, we should discuss that too. -John On Sat, May 2, 2009 at 4:07 PM, Maciej Stachowiak m...@apple.com wrote: I'm pretty concerned about the security/spamming implications of notifications from Workers. A lot of thought has been put into how to make them a good feature for thoughtful, competent Web developers like those at Google. But it seems to me that not as much thought has been put into making the feature resistant to abuse. A few specific concerns: 1) Notifications may appear to the user to come from the Web page they are currently looking at, even if the Worker issuing them was created by a different originating page. 2) In the case of a SharedWorker, there may not even be an originating page with which to assiciate the notification, and it may not be clear to the user how to make notifications stop. 3) It appears that Notifications can be used for unwelcome advertising spam, much as pop-up windows before the advent of browser pop-up blocking. On Apr 30, 2009, at 2:05 PM, John Gregg wrote: Hi WebKit, I'm working on a Notifications API for Web Workers, with the idea that a user agent could receive these from script and route them in a platform-appropriate user-configurable way (desktop HTML toasts, Growl calls, status bar on mobile browsers, etc.). Permission controls would be similar to popups. I don't see how that's possible. The default policy used by many WebKit clients (including Safari) is that popups are only allowed in response to explicit user actions, such as clicking a link. But no code running in a Worker is in response to a user action. In addition, as I understand it, the whole point of Notifications is that they are in response to background events, *not* in response to user actions. I have a prototype working in Chromium but I need some advice as to how I might get the JS API checked in. I opened a bugzilla item here: https://bugs.webkit.org/show_bug.cgi?id=25463, which links to the design doc I'm using and has a rough draft of the patch I'm proposing. I got some feedback there already, so I thought I would reach out for more advice. Basically it amounts to adding to WorkerContext.idl an attribute WorkerContext.notifications, which notifications object contains methods like createNotification(URL or text+icon). Because of the proposed idea of dynamic routing, I'm inclined not to roll it in to window.open() until we get more experience building apps on it and decide that makes sense. Since this is experimental, it's already behind a compile time flag, but I would be happy to do more to make it further protected (like calling it WorkerContext.chromiumNotifications to indicate it's currently a Chromium experiment). Any other advice on how to proceed? I think we should have a clear design for how this feature will resist abuse by malware before landing it in the WebKit tree. And if we can't find a solid design for that, then we shouldn't implement it. While many of us working on WebKit are greatly interested in extending the capabilities of Web applications, we have to recognize that it's important to
Re: [webkit-dev] link-following feature for our new webkit browser.
Sorry i must have missed that on irc. I can't verify now that your examples don't work - but i can verify that links with onclick=... attributes don't work as expected - this makes my first try unusable already :(. PS: Sorry for posting this topic twice - i expected my own topic being mailed back to me (double checked this behaviour on the settings, and it was ON indeed). Since i didn't recieved the first one i assumed it being failed and resent it. 2009/5/4 Alexey Proskuryakov a...@webkit.org: 04.05.2009, в 17:19, Jan Kolkmeier написал(а): 2. Go to link $i: window.location = document.links[i].href; This isn't nice at all, because it doesn't work with ajax-ish web pages. As already asked on IRC, could please clarify what you mean by doesn't work? In particular, the following works as I would expect it to: a href=javascript:alert(0)link/a scriptwindow.location = document.links[0].href;/script - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
I really like this and it goes in the direction that I was hoping for as well. Hopefully we can get the WINCE port merged upstream before we make this change. :-) Some comments I have: 1) In some cases some things apply to more than one OS so we have: #if OS(x) || OS(y) || OS(z) ... I think we should use: #if OS(x,y,z) 1b) WINCE actually includes plenty of WIN but in some cases does things differently. How to make this distinction without lots of and ||? 2) We use PLATFORM(TORCHMOBILE) across multiple OS for things that are not necessarily platform specific but specific to our browsers. I guess this is similar to PLATFORM(CHROMIUM). Honestly I don't like filling the code with these but we all do it, including MAC. MAC tends to win the default right now. I'm not sure how best to handle this yet but I foresee a big mess if we aren't careful. 3) I'm not sure that USE() really applies equally as you described. In some cases it applies to basically the whole system API used (QT), but in others it's just a support library (QUICKTIME). Again, fully support these changes and perhaps some more too. Just give us a bit of time to find the right way to merge the WINCE stuff in first please! On 30-Apr-09, at 7:12 PM, Maciej Stachowiak wrote: I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation macros would still be defined in Platform.h based on sniffing the environment, this would include things like the compiler, the underlying OS, available libc functions, and so forth. Platform adaptation macros would be: OS() - underlying operating system; only to be used for mandated low-level services like virtual memory, not to choose a GUI toolkit Examples: OS(UNIX) - Any Unix-like OS OS(DARWIN) - Underlying OS is the base OS X environment OS(FREEBSD) - FreeBSD OS(WIN) - Any version of Windows OS(WINCE) - The embedded version of Windows COMPILER() - the compiler being used to build the project Examples: COMPILER(GCC) - GNU Compiler Collection COMPILER(MSVC) - Microsoft Visual C++ COMPILER(RVCT) - ARM compiler HAVE() - specific system features (headers, functions or similar) that are present or not Examples: HAVE(MMAP) - mmap() function is available HAVE(ERRNO_H) - errno.h header is available HAVE(MADV_FREE) - madvise(MADV_FREE) is available Policy decision macros would be: USE() - use a particular third-party library or optional OS service Examples: USE(SKIA) - Use the Skia graphics library USE(CG) - Use CoreGraphics USE(V8) - Use the V8 JavaScript implementation USE(CFNET) - Use CFNetwork networking USE(NSURL_NET) - Use NSURLConnection-based networking
[webkit-dev] Re gular safari browser opens when you run Webkit/WebkitTools/Scripts/run-safari in cygwin
Hi, I followed the instructions in www.webkit.org to install Webkit framework on a Win Xp system. Installed developer tools, checked out the code and built webkit.The build was sucessful with the message Build: 18 succeeded, 0 failed, 0 up-to-date, 0 skipped But when i run the command Webkit/WebkitTools/Scripts/run-safari it opens up the regular safari browser without the golden rimmed icon. How can I check if the webkit framework is indeed built? The detailed steps as carried out by me is as follows, 1)Installed Microsoft visual studio 2005 and then installed Microsoft Visual Studio 2005 Team Suite Service Pack 1 by clicking on the link in webkit.org(downloaded and installed it) 2)Installed all four hot fixes mentioned in the document. 3)Downloaded and installed cygwin as mentioned in webkit.org using cygwin-downloader.zip. Selected unix line endings during installation. 4)Installed Quick time SDK. 5)Downloaded and installed safari 4 beta version and installed it. 6)checked out the code using svn checkout http://svn.webkit.org/repository/webkit/trunk Webkit The location of created webkit folder in C:\cygwin\home\username\Webkit. 7)Downloaded WebkitSupportLibraries.zip and copied it to C:\cygwin\home\username\Webkit without unzipping it. 8)Ran the command Webkit/WebkitTools/Scripts/update-webkit from the cygwin prompt. 9)Ran the command Webkit/WebkitTools/Scripts/build-webkit from cygwin prompt.The build was sucessful and gave the message- Build: 18 succeeded, 0 failed, 0 up-to-date,0 skipped. Webkit is now built .To run Safari with this newly built code, use the Webkit/WebkitTools/Scripts/run-safari. Note: Webkit has been built with SVG support enabled.Safari will have SVG viewing capabilities. Your build supports the following(Optional) SVG features: *Basic SVG animation *SVG as image. *SVG as foreign object. *SVGuse support. Thanks a lot.Really welcome any help in this regard. -- View this message in context: http://www.nabble.com/Regular-safari-browser-opens-when-you-run-Webkit-WebkitTools-Scripts-run-safari-in-cygwin-tp23365706p23365706.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] Re gular safari browser opens when you run Webkit/WebkitTools/Scripts/run-safari in cygwin
On May 5, 2009, at 1:04 AM, Subramanya wrote: But when i run the command Webkit/WebkitTools/Scripts/run-safari it opens up the regular safari browser without the golden rimmed icon. We don't use the gold compass icon on Windows, even when running a custom version of WebKit. How can I check if the webkit framework is indeed built? Type this into Safari's address field and press Return: javascript:alert(navigator.userAgent); If you see a version like AppleWebKit/530+, then your built version of WebKit is being used (the + is the important part). -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
