Re: [webkit-dev] Unpacking Nightly Builds
I can unpack it and get it working here on my Windows machine without any trouble. Regards, Joost Mark Rowe wrote: Hi Michael, I just downloaded the Windows nightly build on a Linux machine and had no troubles unpacking it via unzip. Perhaps your download was truncated for some reason? Here's the vital details of the file that I downloaded for comparison: [EMAIL PROTECTED]:/tmp$ ls -la WebKit-SVN-r22096.zip -rw-r--r-- 1 mrowe mrowe 9245478 2007-06-13 18:23 WebKit-SVN-r22096.zip [EMAIL PROTECTED]:/tmp$ md5sum WebKit-SVN-r22096.zip c4d70b5d179379410176a556f615fe13 WebKit-SVN-r22096.zip Kind regards, Mark Rowe On 12/06/2007, at 11:16 PM, Michael JasonSmith wrote: I get and error unpacking the latest nightly build of WebKit for Windows from http://nightly.webkit.org/ http://nightly.webkit.org/files/win/WebKit-SVN-r22096.zip As a caveat, I am unpacking the build under Linux, rather than Windows; I have confirmation that the same package does not unpack under MacOS either. The first of the error messages from "unzip" are as follows. $ unzip WebKit-SVN-r22096.zip 2>&1 | head Archive: WebKit-SVN-r22096.zip error [WebKit-SVN-r22096.zip]: missing 9014340 bytes in zipfile (attempting to process anyway) error [WebKit-SVN-r22096.zip]: attempt to seek before beginning of zipfile (please check that you have transferred or created the zipfile in the appropriate BINARY mode and that you have compiled UnZip properly) (attempting to re-compensate) file #1: bad zipfile offset (local header sig): 0 (attempting to re-compensate) error [WebKit-SVN-r22096.zip]: attempt to seek before beginning of zipfile Some files are extracted (under the "WebKit.resources" directory), but I cannot determine if all of the files under that directory are extracted. I know that Linux is not a supported operating system, but I thought you would like to know :) System * Linux 2.6.20-16-386 * UnZip 5.52 * Ubuntu 7.04 -- Michael JasonSmith http://onlinegroups.net/ Usability Engineer ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev Kind regards, Joost -- Joost de Valk #:AlthA on #opendarwin @ irc.freenode.net @:[EMAIL PROTECTED] W:http://www.joostdevalk.nl "The only people who find what they are looking for in life are the fault finders." - Foster's Law ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unpacking Nightly Builds
Hi Michael, I just downloaded the Windows nightly build on a Linux machine and had no troubles unpacking it via unzip. Perhaps your download was truncated for some reason? Here's the vital details of the file that I downloaded for comparison: [EMAIL PROTECTED]:/tmp$ ls -la WebKit-SVN-r22096.zip -rw-r--r-- 1 mrowe mrowe 9245478 2007-06-13 18:23 WebKit-SVN-r22096.zip [EMAIL PROTECTED]:/tmp$ md5sum WebKit-SVN-r22096.zip c4d70b5d179379410176a556f615fe13 WebKit-SVN-r22096.zip Kind regards, Mark Rowe On 12/06/2007, at 11:16 PM, Michael JasonSmith wrote: I get and error unpacking the latest nightly build of WebKit for Windows from http://nightly.webkit.org/ http://nightly.webkit.org/files/win/WebKit-SVN-r22096.zip As a caveat, I am unpacking the build under Linux, rather than Windows; I have confirmation that the same package does not unpack under MacOS either. The first of the error messages from "unzip" are as follows. $ unzip WebKit-SVN-r22096.zip 2>&1 | head Archive: WebKit-SVN-r22096.zip error [WebKit-SVN-r22096.zip]: missing 9014340 bytes in zipfile (attempting to process anyway) error [WebKit-SVN-r22096.zip]: attempt to seek before beginning of zipfile (please check that you have transferred or created the zipfile in the appropriate BINARY mode and that you have compiled UnZip properly) (attempting to re-compensate) file #1: bad zipfile offset (local header sig): 0 (attempting to re-compensate) error [WebKit-SVN-r22096.zip]: attempt to seek before beginning of zipfile Some files are extracted (under the "WebKit.resources" directory), but I cannot determine if all of the files under that directory are extracted. I know that Linux is not a supported operating system, but I thought you would like to know :) System * Linux 2.6.20-16-386 * UnZip 5.52 * Ubuntu 7.04 -- Michael JasonSmith http://onlinegroups.net/ Usability Engineer ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unpacking Nightly Builds
A version i downloaded earlier wouldn't open, but i just re- downloaded now and it opens fine on mac -- maybe there were temporary server issues? --Oliver On 12/06/2007, at 11:16 PM, Michael JasonSmith wrote: I get and error unpacking the latest nightly build of WebKit for Windows from http://nightly.webkit.org/ http://nightly.webkit.org/files/win/WebKit-SVN-r22096.zip As a caveat, I am unpacking the build under Linux, rather than Windows; I have confirmation that the same package does not unpack under MacOS either. The first of the error messages from "unzip" are as follows. $ unzip WebKit-SVN-r22096.zip 2>&1 | head Archive: WebKit-SVN-r22096.zip error [WebKit-SVN-r22096.zip]: missing 9014340 bytes in zipfile (attempting to process anyway) error [WebKit-SVN-r22096.zip]: attempt to seek before beginning of zipfile (please check that you have transferred or created the zipfile in the appropriate BINARY mode and that you have compiled UnZip properly) (attempting to re-compensate) file #1: bad zipfile offset (local header sig): 0 (attempting to re-compensate) error [WebKit-SVN-r22096.zip]: attempt to seek before beginning of zipfile Some files are extracted (under the "WebKit.resources" directory), but I cannot determine if all of the files under that directory are extracted. I know that Linux is not a supported operating system, but I thought you would like to know :) System * Linux 2.6.20-16-386 * UnZip 5.52 * Ubuntu 7.04 -- Michael JasonSmith http://onlinegroups.net/ Usability Engineer ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Unpacking Nightly Builds
I get and error unpacking the latest nightly build of WebKit for Windows from http://nightly.webkit.org/ http://nightly.webkit.org/files/win/WebKit-SVN-r22096.zip As a caveat, I am unpacking the build under Linux, rather than Windows; I have confirmation that the same package does not unpack under MacOS either. The first of the error messages from "unzip" are as follows. $ unzip WebKit-SVN-r22096.zip 2>&1 | head Archive: WebKit-SVN-r22096.zip error [WebKit-SVN-r22096.zip]: missing 9014340 bytes in zipfile (attempting to process anyway) error [WebKit-SVN-r22096.zip]: attempt to seek before beginning of zipfile (please check that you have transferred or created the zipfile in the appropriate BINARY mode and that you have compiled UnZip properly) (attempting to re-compensate) file #1: bad zipfile offset (local header sig): 0 (attempting to re-compensate) error [WebKit-SVN-r22096.zip]: attempt to seek before beginning of zipfile Some files are extracted (under the "WebKit.resources" directory), but I cannot determine if all of the files under that directory are extracted. I know that Linux is not a supported operating system, but I thought you would like to know :) System * Linux 2.6.20-16-386 * UnZip 5.52 * Ubuntu 7.04 -- Michael JasonSmith http://onlinegroups.net/ Usability Engineer ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Accept- & Content-Resolution headers proposal
Hi, So it appears that there are no plans to implement feature negotiation in Apache at this point in time. I'm willing to look into modifying mod_negotiation to support some level of feature negotiation if someone is willing to implement something on the WebKit side. Anyone interested? Cheers, -- Tom Howard http://windyroad.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ResourceHandle and the Frame parameter
--- Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > On Jun 12, 2007, at 5:41 PM, Morgan L wrote: > > > > > --- Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > > >> > >> On Jun 12, 2007, at 5:22 PM, Maciej Stachowiak > >> wrote: > >> > >>> > >>> On Jun 12, 2007, at 2:33 PM, Darin Adler wrote: > >>> > I think we'll have to rethink this. > >> ResourceHandle is intended to > be a low level networking layer, and so it > >> doesn't make sense to > have higher level concepts like a Frame*, but > >> clearly we'll need > to make a design change so there's a higher > level > >> that's easy to > plug in to. > > Or we can just give up on the notion of > >> ResourceHandle as a low > level networking abstraction. > >>> > >>> As Darin says, the intent is that ResourceLoader > >> is the layer that > >>> knows about high-level networking stuff in the > >> engine, > >>> ResourceHandle is supposed to be low-level and > >> ignorant of the > >>> higher-level loading code. In my opinion, the > >> right way to put in > >>> hooks that depend on the loading context would > be > >> to add > >>> appropriate ResourceHandleClient methods. > >> > >> Now that I think about it, I guess that won't do > >> much to help you add > >> port-specific hooks - although the > >> ResourceHandleClient (normally a > >> ResourceLoader) could call up to a > platform-specific > >> WebKit layer via > >> FrameLoaderClient. It's hard to tell what the > best > >> model is without > >> more details about why the low-level networking > code > >> in question > >> needs access to the high-level objects. > > > > I tried to give some motivating examples in my > initial > > post. A good example is network code that might > like > > to put up a dialog, and it would like that dialog > to > > be properly parented above the window from which > the > > resource request originated. > > Our approach for this in WebKit would be to make it > a delegate > callback up to the app - we never throw up dialogs > from low-level > code without control over the app. I think other > ports should have > the same approach, unless there's some deep reason > that can't be done. In my case, I would prefer not to have to continually modify ResourceHandleClient whenever I want to do something that requires Frame level context. The dialogs example was just an example (that network-level dialogs may be undesirable in various applications is not really relevant). I just want the freedom to add things like this without having to revise WebCore. > > In both cases, it may be more costly to implement > solutions using > > callbacks to the ResourceHandleClient. > > Is it really that big a deal? We already have a > bunch of stuff on Mac > and Windows Safari that calls all the way up to the > app (for instance > on every redirect) and it is not a significant > performance hit. Again, the issue isn't performance. It is code maintainability and the ability to develop rapidly. Why would you guys want to support additional APIs on ResourceHandleClient that you don't use? Wouldn't you rather just support a Frame parameter (or some equivalent)? > > In short, forcing consumers / embedders to plumb > new > > hooks through ResourceHandleClient and > ResourceLoader > > seems like a larger burden, both in terms of > initial > > development and maintainability (since the hooks > > wouldn't be exercised by Safari). > > The tradeoff is that it breaks the intended layering > of WebKit. > WebCore/platform should be a layer that wraps > platform-specific APIs. I think that many embedders also want control over the way that resources are loaded into WebCore. I don't think it is correct to restrict ResourceHandle. One of the things that makes WebKit awesome for embedders is how easy it is to layer stuff "above" and "below" WebKit in the stack. I'd like to see that made even easier :-) > It should (in theory) have no knowledge of > higher-level parts of > WebCore, and should communicate solely through > abstract client > interfaces. WebKit should be the layer that > implements API and policy > "on top" of the core networking code. In general this is good, especially for things that matter for > Otherwise we have to totally rethink the intended > separation of > responsibilities between ResourceHandle and > ResourceLoader. I don't think much needs to change. This is just about making WebCore more flexible. Anyways, I hope you'll agree that making WebCore more flexible is complementary to designing good, generally useful callbacks. --morgan Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinf
Re: [webkit-dev] SVG in WebKit for Safari 3 for Windows and Mac and iPhone?
Sergio, And that work would be happening on the feature-branch of WebKit: svn checkout http://svn.webkit.org/repository/webkit/branches/feature-branch WebKit-feature-branch Please see http://webkit.org/ for more details about checking out/compiling code. Dave Oliver Hunt <[EMAIL PROTECTED]> wrote: > Sergio, there is interest in having SVG animation support, and a > reasonable amount is implemented. Currently animation is turned off > by default, due to its tendency to crash. > > You're welcome to work on it as well if you're interested :D > > --Oliver > > On 12/06/2007, at 4:20 PM, Sergio Trejo wrote: > > > Andreas, > > > > Your SVG pages worked just fine for me on Safari 3 with Windows XP > > (nothing crashed). Although the animation didn't work so I presume > > that WebKit is limited with respect to SVG at the moment and there > > is no SMIL in WebKit. I wonder if there is interest in integrating > > SMIL into WebKit? > > > > Regards, > > > > Sergio > > > > On 6/11/07, Andreas Neumann <[EMAIL PROTECTED]> wrote:I will, > > > > with a little more testing I am pretty sure that the problem isn't > > related to SVG at all. It also randomly crashes on many html pages. > > > > I installed Safari on a different windows machine and seems to run > > fine > > on the other machine. > > > > Andreas > > > > David Kilzer wrote: > > > HI Andreas! > > > > > > Please file a bug on http://bugs.webkit.org/ about this issue. > > Thanks! > > > > > > Dave > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ResourceHandle and the Frame parameter
On Jun 12, 2007, at 5:41 PM, Morgan L wrote: --- Maciej Stachowiak <[EMAIL PROTECTED]> wrote: On Jun 12, 2007, at 5:22 PM, Maciej Stachowiak wrote: On Jun 12, 2007, at 2:33 PM, Darin Adler wrote: I think we'll have to rethink this. ResourceHandle is intended to be a low level networking layer, and so it doesn't make sense to have higher level concepts like a Frame*, but clearly we'll need to make a design change so there's a higher level that's easy to plug in to. Or we can just give up on the notion of ResourceHandle as a low level networking abstraction. As Darin says, the intent is that ResourceLoader is the layer that knows about high-level networking stuff in the engine, ResourceHandle is supposed to be low-level and ignorant of the higher-level loading code. In my opinion, the right way to put in hooks that depend on the loading context would be to add appropriate ResourceHandleClient methods. Now that I think about it, I guess that won't do much to help you add port-specific hooks - although the ResourceHandleClient (normally a ResourceLoader) could call up to a platform-specific WebKit layer via FrameLoaderClient. It's hard to tell what the best model is without more details about why the low-level networking code in question needs access to the high-level objects. I tried to give some motivating examples in my initial post. A good example is network code that might like to put up a dialog, and it would like that dialog to be properly parented above the window from which the resource request originated. Our approach for this in WebKit would be to make it a delegate callback up to the app - we never throw up dialogs from low-level code without control over the app. I think other ports should have the same approach, unless there's some deep reason that can't be done. There could also be network policy decisions, which do not involve UI, that depend on the originating frame. Policy decisions are something that we try to do at the ResourceLoader layer or calling up to WebKit or all the way to the app. In both cases, it may be more costly to implement solutions using callbacks to the ResourceHandleClient. Is it really that big a deal? We already have a bunch of stuff on Mac and Windows Safari that calls all the way up to the app (for instance on every redirect) and it is not a significant performance hit. In short, forcing consumers / embedders to plumb new hooks through ResourceHandleClient and ResourceLoader seems like a larger burden, both in terms of initial development and maintainability (since the hooks wouldn't be exercised by Safari). The tradeoff is that it breaks the intended layering of WebKit. WebCore/platform should be a layer that wraps platform-specific APIs. It should (in theory) have no knowledge of higher-level parts of WebCore, and should communicate solely through abstract client interfaces. WebKit should be the layer that implements API and policy "on top" of the core networking code. It may be that this approach is ultimately not workable, but I'm not really convinced by your examples. There's no reason new dialogs or policy decisions can't be handled the same way that all the existing ones are, as far as I can tell. At any rate, my hope is that you will accept a trivial patch to plumb a Frame down to ResourceHandle::loadResourceSynchronously and that you will preserve some context that is equivalent to the Frame in the future. I think "less is more" in this case :-) I really think that moves things in the wrong direction. I'd rather see patches to add appropriate ResourceHandleClient calls to handle the cases of interest to you. Otherwise we have to totally rethink the intended separation of responsibilities between ResourceHandle and ResourceLoader. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ResourceHandle and the Frame parameter
--- Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > On Jun 12, 2007, at 5:22 PM, Maciej Stachowiak > wrote: > > > > > On Jun 12, 2007, at 2:33 PM, Darin Adler wrote: > > > >> I think we'll have to rethink this. > ResourceHandle is intended to > >> be a low level networking layer, and so it > doesn't make sense to > >> have higher level concepts like a Frame*, but > clearly we'll need > >> to make a design change so there's a higher level > that's easy to > >> plug in to. > >> > >> Or we can just give up on the notion of > ResourceHandle as a low > >> level networking abstraction. > > > > As Darin says, the intent is that ResourceLoader > is the layer that > > knows about high-level networking stuff in the > engine, > > ResourceHandle is supposed to be low-level and > ignorant of the > > higher-level loading code. In my opinion, the > right way to put in > > hooks that depend on the loading context would be > to add > > appropriate ResourceHandleClient methods. > > Now that I think about it, I guess that won't do > much to help you add > port-specific hooks - although the > ResourceHandleClient (normally a > ResourceLoader) could call up to a platform-specific > WebKit layer via > FrameLoaderClient. It's hard to tell what the best > model is without > more details about why the low-level networking code > in question > needs access to the high-level objects. I tried to give some motivating examples in my initial post. A good example is network code that might like to put up a dialog, and it would like that dialog to be properly parented above the window from which the resource request originated. There could also be network policy decisions, which do not involve UI, that depend on the originating frame. In both cases, it may be more costly to implement solutions using callbacks to the ResourceHandleClient. In short, forcing consumers / embedders to plumb new hooks through ResourceHandleClient and ResourceLoader seems like a larger burden, both in terms of initial development and maintainability (since the hooks wouldn't be exercised by Safari). At any rate, my hope is that you will accept a trivial patch to plumb a Frame down to ResourceHandle::loadResourceSynchronously and that you will preserve some context that is equivalent to the Frame in the future. I think "less is more" in this case :-) --morgan Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ResourceHandle and the Frame parameter
On Jun 12, 2007, at 5:22 PM, Maciej Stachowiak wrote: On Jun 12, 2007, at 2:33 PM, Darin Adler wrote: I think we'll have to rethink this. ResourceHandle is intended to be a low level networking layer, and so it doesn't make sense to have higher level concepts like a Frame*, but clearly we'll need to make a design change so there's a higher level that's easy to plug in to. Or we can just give up on the notion of ResourceHandle as a low level networking abstraction. As Darin says, the intent is that ResourceLoader is the layer that knows about high-level networking stuff in the engine, ResourceHandle is supposed to be low-level and ignorant of the higher-level loading code. In my opinion, the right way to put in hooks that depend on the loading context would be to add appropriate ResourceHandleClient methods. Now that I think about it, I guess that won't do much to help you add port-specific hooks - although the ResourceHandleClient (normally a ResourceLoader) could call up to a platform-specific WebKit layer via FrameLoaderClient. It's hard to tell what the best model is without more details about why the low-level networking code in question needs access to the high-level objects. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ResourceHandle and the Frame parameter
On Jun 12, 2007, at 2:33 PM, Darin Adler wrote: I think we'll have to rethink this. ResourceHandle is intended to be a low level networking layer, and so it doesn't make sense to have higher level concepts like a Frame*, but clearly we'll need to make a design change so there's a higher level that's easy to plug in to. Or we can just give up on the notion of ResourceHandle as a low level networking abstraction. As Darin says, the intent is that ResourceLoader is the layer that knows about high-level networking stuff in the engine, ResourceHandle is supposed to be low-level and ignorant of the higher-level loading code. In my opinion, the right way to put in hooks that depend on the loading context would be to add appropriate ResourceHandleClient methods. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ResourceHandle and the Frame parameter
I went ahead and filed a bug for this issue: http://bugs.webkit.org/show_bug.cgi?id=14106 --- Morgan L <[EMAIL PROTECTED]> wrote: > In the meantime, will you accept a patch to add a > Frame pointer to loadResourceSynchronously? > > > > --- Darin Adler <[EMAIL PROTECTED]> wrote: > > > I think we'll have to rethink this. ResourceHandle > > is intended to be > > a low level networking layer, and so it doesn't > make > > sense to have > > higher level concepts like a Frame*, but clearly > > we'll need to make a > > design change so there's a higher level that's > easy > > to plug in to. > > > > Or we can just give up on the notion of > > ResourceHandle as a low level > > networking abstraction. > > > > -- Darin > > > > > > > --morgan > > > > > Looking for a deal? Find great prices on flights and > hotels with Yahoo! FareChase. > http://farechase.yahoo.com/ > --morgan TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ResourceHandle and the Frame parameter
In the meantime, will you accept a patch to add a Frame pointer to loadResourceSynchronously? --- Darin Adler <[EMAIL PROTECTED]> wrote: > I think we'll have to rethink this. ResourceHandle > is intended to be > a low level networking layer, and so it doesn't make > sense to have > higher level concepts like a Frame*, but clearly > we'll need to make a > design change so there's a higher level that's easy > to plug in to. > > Or we can just give up on the notion of > ResourceHandle as a low level > networking abstraction. > > -- Darin > > --morgan Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG in WebKit for Safari 3 for Windows and Mac and iPhone?
Sergio, there is interest in having SVG animation support, and a reasonable amount is implemented. Currently animation is turned off by default, due to its tendency to crash. You're welcome to work on it as well if you're interested :D --Oliver On 12/06/2007, at 4:20 PM, Sergio Trejo wrote: Andreas, Your SVG pages worked just fine for me on Safari 3 with Windows XP (nothing crashed). Although the animation didn't work so I presume that WebKit is limited with respect to SVG at the moment and there is no SMIL in WebKit. I wonder if there is interest in integrating SMIL into WebKit? Regards, Sergio On 6/11/07, Andreas Neumann <[EMAIL PROTECTED]> wrote:I will, with a little more testing I am pretty sure that the problem isn't related to SVG at all. It also randomly crashes on many html pages. I installed Safari on a different windows machine and seems to run fine on the other machine. Andreas David Kilzer wrote: > HI Andreas! > > Please file a bug on http://bugs.webkit.org/ about this issue. Thanks! > > Dave > > > -- -- -- Andreas Neumann Institute of Cartography ETH Zurich Wolfgang-Paulistrasse 15 CH-8093 Zurich, Switzerland Phone: ++41-44-633 3031, Fax: ++41-44-633 1153 e-mail: [EMAIL PROTECTED] www: http://www.carto.net/neumann/ SVG.Open: http://www.svgopen.org/ Carto.net: http://www.carto.net/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SVG in WebKit for Safari 3 for Windows and Mac and iPhone?
Andreas, Your SVG pages worked just fine for me on Safari 3 with Windows XP (nothing crashed). Although the animation didn't work so I presume that WebKit is limited with respect to SVG at the moment and there is no SMIL in WebKit. I wonder if there is interest in integrating SMIL into WebKit? Regards, Sergio On 6/11/07, Andreas Neumann <[EMAIL PROTECTED]> wrote: I will, with a little more testing I am pretty sure that the problem isn't related to SVG at all. It also randomly crashes on many html pages. I installed Safari on a different windows machine and seems to run fine on the other machine. Andreas David Kilzer wrote: > HI Andreas! > > Please file a bug on http://bugs.webkit.org/ about this issue. Thanks! > > Dave > > > -- -- -- Andreas Neumann Institute of Cartography ETH Zurich Wolfgang-Paulistrasse 15 CH-8093 Zurich, Switzerland Phone: ++41-44-633 3031, Fax: ++41-44-633 1153 e-mail: [EMAIL PROTECTED] www: http://www.carto.net/neumann/ SVG.Open: http://www.svgopen.org/ Carto.net: http://www.carto.net/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] TREE IS OPEN
The tree is once again open for business! The Windows merge is complete. Thanks everyone for being patient with us! -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ResourceHandle and the Frame parameter
I think we'll have to rethink this. ResourceHandle is intended to be a low level networking layer, and so it doesn't make sense to have higher level concepts like a Frame*, but clearly we'll need to make a design change so there's a higher level that's easy to plug in to. Or we can just give up on the notion of ResourceHandle as a low level networking abstraction. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ResourceHandle and the Frame parameter
It is important for the ResourceHandle in the apollo port to have access to WebView state. We can live with a pointer to the Frame, FrameLoader, Page, or any other object that allows us to walk back to our WebView. We could add a factory method on FrameLoaderClient to construct ResourceHandle's. ResourceHandle could become a pure virtual interface, which would eliminate the need for the #if's in the header and would allow clients to associate as much per frame state with a ResourceHandle as they wanted. Chris Brichford Adobe Systems Inc. http://www.adobe.com/go/apollo On Jun 12, 2007, at 1:04 PM, Morgan L wrote: Congrats on the windows launch! :-) Now, on to my question... There is a comment in ResourceHandle.h about the Frame parameter to ResourceHandle's static create function. The comment suggests that the Frame parameter might be removed in the future or that it at least shouldn't be there. I wanted to make the case for keeping it (or something equivalent) there. In many cases, it is very useful to have context about what frame (document) is requesting a resource. This can be handy for simple things like logging, but it can also be useful for other things, like UI (e.g., security UI), that might be associated with a resource load. It may be the case that Safari can do without such context now or perhaps in the future, but for other consumers of webkit, it'd be great if this parameter could remain. If Frame is the wrong object (for some reason), then it could be some other object type so long as the Frame could be derived from it. Along these lines, I would also really like to add a Frame pointer to the ResourceHandle's loadResourceSynchronously method. This is important to my application and makes sense from the point-of-view of symmetry with ResourceHandle::create. Does this sound reasonable? If so, then I will prepare a patch and attach it to a bug. Thanks! --morgan __ __ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities +for+kids&cs=bz ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Tree closed until after Windows merge
Hey everyone- We're very excited to be putting our Windows WebKit code in WebKit repository, and are getting ready to start the merge very soon! I'd like to request that no one make any commits to the WebKit repository until our merge is finished, as we will be getting down-n-dirty with Subversion and want it all to go smoothly. I'll send another email to this list when the merge is complete. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] ResourceHandle and the Frame parameter
Congrats on the windows launch! :-) Now, on to my question... There is a comment in ResourceHandle.h about the Frame parameter to ResourceHandle's static create function. The comment suggests that the Frame parameter might be removed in the future or that it at least shouldn't be there. I wanted to make the case for keeping it (or something equivalent) there. In many cases, it is very useful to have context about what frame (document) is requesting a resource. This can be handy for simple things like logging, but it can also be useful for other things, like UI (e.g., security UI), that might be associated with a resource load. It may be the case that Safari can do without such context now or perhaps in the future, but for other consumers of webkit, it'd be great if this parameter could remain. If Frame is the wrong object (for some reason), then it could be some other object type so long as the Frame could be derived from it. Along these lines, I would also really like to add a Frame pointer to the ResourceHandle's loadResourceSynchronously method. This is important to my application and makes sense from the point-of-view of symmetry with ResourceHandle::create. Does this sound reasonable? If so, then I will prepare a patch and attach it to a bug. Thanks! --morgan Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] XSLT in Safari
Hello, can anyone give me the version number XSLT support was added to Safari? Thanks, Johann ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
