[webkit-dev] Invitation to connect on LinkedIn
LinkedIn Mike Emmel requested to add you as a connection on LinkedIn: -- stevin, I'd like to add you to my professional network on LinkedIn. - Mike Accept invitation from Mike Emmel http://www.linkedin.com/e/-jnbvix-gujhogt6-12/qxt6X_WQtIhjU098J-t7a9l-QVVLSjg_CRCP9zASYX/blk/I107667218_140/6lColZJrmZznQNdhjRQnOpBtn9QfmhBt71BoSd1p65Lr6lOfP0QclYUcj8TdzoTc359bQR8cmNbl6ARbPAScjcPe3kUdPgLrCBxbOYWrSlI/EML_comm_afe/?hs=falsetok=27NO1F6TaoNkY1 View invitation from Mike Emmel http://www.linkedin.com/e/-jnbvix-gujhogt6-12/qxt6X_WQtIhjU098J-t7a9l-QVVLSjg_CRCP9zASYX/blk/I107667218_140/c3gNnPwNczsSdzsMckALqnpPbOYWrSlI/svi/?hs=falsetok=0ytcoax2OoNkY1 -- Why might connecting with Mike Emmel be a good idea? Mike Emmel's connections could be useful to you: After accepting Mike Emmel's invitation, check Mike Emmel's connections to see who else you may know and who you might want an introduction to. Building these connections can create opportunities in the future. -- (c) 2011, LinkedIn Corporation ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Invitation to connect on LinkedIn
LinkedIn Mike Emmel requested to add you as a connection on LinkedIn: -- stevin, I'd like to add you to my professional network on LinkedIn. - Mike Accept invitation from Mike Emmel http://www.linkedin.com/e/-jnbvix-gujhov8h-5g/qxt6X_WQtIhjU098J-t7a9l-QVVLSjg_CRCP9zASYX/blk/I107667292_140/6lColZJrmZznQNdhjRQnOpBtn9QfmhBt71BoSd1p65Lr6lOfP0QclYOej8TdzoTc359bQR8cmNbl6ARbPAScjcPe3kUdPgLrCBxbOYWrSlI/EML_comm_afe/?hs=falsetok=31imXODw-oNkY1 View invitation from Mike Emmel http://www.linkedin.com/e/-jnbvix-gujhov8h-5g/qxt6X_WQtIhjU098J-t7a9l-QVVLSjg_CRCP9zASYX/blk/I107667292_140/c3gNnP8VczsSdzsMckALqnpPbOYWrSlI/svi/?hs=falsetok=0JDSebJgGoNkY1 -- Why might connecting with Mike Emmel be a good idea? Mike Emmel's connections could be useful to you: After accepting Mike Emmel's invitation, check Mike Emmel's connections to see who else you may know and who you might want an introduction to. Building these connections can create opportunities in the future. -- (c) 2011, LinkedIn Corporation ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Invitation to connect on LinkedIn
I'd like to add you to my professional network on LinkedIn. - Mike Mike Emmel Engineer at Motorola Orange County, California Area Confirm that you know Mike Emmel: https://www.linkedin.com/e/-yz6z9j-gujhq9vr-5h/isd/4785841364/BphXX1Nl/?hs=falsetok=3WgVy0g3apNkY1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-yz6z9j-gujhq9vr-5h/vfFdhOKuRQfLX6OJvYGwC91dghbkNACKb6rIMu3ur4mq4tg/goo/webkit-dev%40lists%2Emacosforge%2Eorg/20061/I1664123777_1/?hs=falsetok=3Jldu2gjupNkY1 (c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch to use V8 engine with Gtk port
The work was done for my employer for their own reasons. I both understand why they chose V8 and agree with the decision. I'm not comfortable giving a detailed reason for the decision and I think thats understandable. A clearer explanation would require a more formal response and its tied to our products so hopefully you can understand its not something I want to get into. As a engineer hopefully you can understand my desire to not go down this path lets leave it to the marketing team. However given the nature of the submission regardless of why it was made its also obvious that getting it integrated into the trunk is far better than leaving it as a fork. My focus is simply to do my best to get the code ready for submission and it does contain controversial decisions. Its been a long time since I posted but somehow I seem to manage to get myself on the wrong side of many issues. I think I'm cursed, chance would not give such consistent results :) Why this project was done is not the top issue and that should be obvious if you read the bug report. I've got other problems to deal with :) I honestly did not expect this response equating this submission to other work that needs to be done but given my track record its not surprising that I'm surprised it must be part of my curse :) I don't get the logic behind it. I think the assumption is that if I was not working on this JS engine submission then I would have been working on other areas that are considered more important however this is not true. The basic premise is false as I would actually have been working on something else. I assure you that I don't have the luxury of devoting my time to the project based on its most pressing problems if I did, I would of course try and help. On Fri, Dec 11, 2009 at 10:28 PM, Holger Freyther ze...@selfish.org wrote: On Friday 11 December 2009 23:55:06 Eric Seidel wrote: I don't see a patch on the bug, but I look forward to seeing it when it's posted. I'm surprised that having switch-able JS engines would bubble up on the list of things to do above things like passing the layout tests: http://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/Skipped Dear Mike, is JavaScript execution really the dominating cost in your (page loading tests)? When I profile on ARM (not WebKit/GTK+ though) I see various other areas of improvement? holger ___ 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] Patch to use V8 engine with Gtk port
On Sat, Dec 12, 2009 at 6:19 PM, Holger Freyther ze...@selfish.org wrote: On Saturday 12 December 2009 22:42:34 Maciej Stachowiak wrote: I think questioning someone's priorities in an open source project is generally not polite, unless there is some direct relationship between different tasks. For example, if someone introduce a new feature (let's say support for parts of the FooML language) and it had lots of bugs, it might be reasonable to ask them to fix some of the bugs before implementing more FooML features. But that doesn't seem to be the case here. Ultimately, I think it's up to the Gtk port maintainers and the folks maintaining v8 bindings to decide whether they want to support and maintain this functionality, and to review the patch as they see fit. Hello Mike, All, I'm not questioning your priorities. I'm solely looking at this from a maintaining WebKit/GTK+ point of view. The problem with WebKit (or any big software project) is that we are not done when landing a fundamental new feature/configure option but it is really only the beginning. The questions are around, who is running a buildbot with this configuration option, who will look at this buildbot, who will keep it building. In general it is better to have less options (as these could be actually checked prior to a release). So it is really not about me telling Mike what to do, but thinking about what is maintainable for WebKit/GTK+. To be clear the dependency on Gtk itself is small. I'll push the code into a git repo somewhere and link to the bug on monday. Now of course I had to seriously munge the makefiles but they already suffer bit rot. You mention the new font system a refactoring of the makefiles is probably needed for a host of reasons the changes needed to compile V8 just expose this. My point is a refactoring of the makefiles to make the port easier to maintain is probably a must before the V8 support could come in and it would help the overall Gtk project. Of course given my track record I could also be the only one with that opinion and everyone else is happy. If so then forget the offer :) However I think we have overlapping areas of concern and if so bringing some sanity back to the build will help everyone both in making the official build feature set clear and allowing easy work on optional or experimental features. The Linux kernel had similar issues and resolved them. I know that the v8 patch pushed things over the edge to a ridiculous set of ifdefs. Perhaps autoconf allows nested features or perhaps feature bundles are the answer or meta config switches they set and unset a compatible group of options. I don't know the right answer just that its probably time to overhaul the build system a bit and I can help. E.g. we have an experimental GLib Unicode implementation, and saving the storage size for ICU (12 mb when not statically linked) is a pretty good reason for some. At the end of the day I feel responsible for the Gtk+ port and I would just like to know why it makes sense for us to maintain it. regards holger. ___ 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] Patch to use V8 engine with Gtk port
Hi all. Its been a while. I just pushed a large patch that will need some serious work. https://bugs.webkit.org/show_bug.cgi?id=32452 It allows the v8 js engine and debugger to work with the gtk webkit port. Including remote debugging for arm or embedded platforms using chromedevtools. I'm also emailing the list because to get it accepted will require some help from a number of individuals some at google and the gtk team. I doubt I can do it on my own or at least not in a timely manner. In my opinion getting both engines equally supported across most ports would be good for the entire community so I hope people are interested. The Gtk dependencies are minor and it should be trivial to support other ports. Of course not everything is working for example dumptree is turned off the HTML debugger is off etc. But I think its initial base. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch to use V8 engine with Gtk port
I changed the cc list the patch should be there now hmm not sure why it did not go on the initial submit. I don't know anything about the layout test issues. The patches relationship to the gtk port itself is minor its the one I happen to use. The gtk specific issues have a lot more to do with the changes to the GNUMakefiles. I'd be happy to refactor them so they where more flexible and could handle changes like this. If for some reason the layout test are considered a show stopper perhaps I can do another patch using a different platform. I'm on linux so a few are possible then come back to gtk specific issues later technically its not much just messy. On Fri, Dec 11, 2009 at 2:55 PM, Eric Seidel e...@webkit.org wrote: I don't see a patch on the bug, but I look forward to seeing it when it's posted. I'm surprised that having switch-able JS engines would bubble up on the list of things to do above things like passing the layout tests: http://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/Skipped :/ -eric On Fri, Dec 11, 2009 at 2:51 PM, Mike Emmel mike.em...@gmail.com wrote: Hi all. Its been a while. I just pushed a large patch that will need some serious work. https://bugs.webkit.org/show_bug.cgi?id=32452 It allows the v8 js engine and debugger to work with the gtk webkit port. Including remote debugging for arm or embedded platforms using chromedevtools. I'm also emailing the list because to get it accepted will require some help from a number of individuals some at google and the gtk team. I doubt I can do it on my own or at least not in a timely manner. In my opinion getting both engines equally supported across most ports would be good for the entire community so I hope people are interested. The Gtk dependencies are minor and it should be trivial to support other ports. Of course not everything is working for example dumptree is turned off the HTML debugger is off etc. But I think its initial base. ___ 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] Curl resourcehandle leaks in Linux/Gtk port
Look I had to change to one multi handle per handle basically just and asynchronous handle to get everything to clean up. Its a significant refactoring and better design. What it points to on the curl side is the need for and asynchronous simple handle. Also polling was removed as much as possible curl does not send decent time outs if it has real work to perform so this is still a issue. However open file handles are handled in the event loop select. Curl needs to be extended to have the concept of a work request and a longer term watch timeout. So in my opinion the issues are fixed at least to the extent possible without help from the curl team. On Wed, Sep 10, 2008 at 7:53 AM, zaheer ahmad [EMAIL PROTECTED] wrote: hi, The fix only helps little as we see the bigger leaks in curl. feedback from curl experts suggests that this design is correct.. let me know if you are aware of this issue == here's the mail snapshot. we are seeing big leaks in curl (Curl_connect - 600-800k and Curl_open - ~200k) when we browse through as little as few websites. This values keep increasing as we browse more sites. heres the high level logic of webkit=curl interaction 1- create a multi handle at the start of program 2- keep creating easy handles for each request 3- when request is done remove it from multi handle and clean up the handle 4- multi handle is never released (stays till the end of program) This design assumes that multi handle has a bounded memory usage as we keep adding and removing easy handles, but that seems to be not true with the leaks. == Now I just started to use valgrind to find other memory leaks, so this and other issues should be hopefully fixed soon. these are not traditional memory leaks, you are holding on to things longer than you should, so they are more functional leaks. Does valgrind help in that too? thanks, Zaheer On Wed, Sep 10, 2008 at 8:02 PM, Marco Barisione [EMAIL PROTECTED] wrote: Il giorno mer, 10/09/2008 alle 07.22 -0700, Mike Emmel ha scritto: This leak is fixed in the ncurl port. Is it possible to backport the fix? -- Marco Barisione ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Curl resourcehandle leaks in Linux/Gtk port
On Wed, Sep 10, 2008 at 10:15 PM, zaheer ahmad [EMAIL PROTECTED] wrote: hi mike, The ncurl port is not yet in the official builds. meanwhile how do you suggest to fix this in the current baseline. No suggestions. I wrote he original code and did not care much for it even when I wrote it. I was waiting on the newer versions of curl that had callbacks for file descriptors. That approach was copied from the examples which were intended or designed for command line apps not browsers. The new file handle callbacks where added to address this problem and make curl more ui friendly. one of the changes that does help is to periodically cleanup the multihandle when the running job count drops to 0 and recreate on the next request (this is just a temporary fix till we find the real issue in curl) i have few comments on the ncurl patch: https://bugs.webkit.org/show_bug.cgi?id=17972 - is it better than the current timer driven behavior, since the glib main loop polls the fds faster if its free- but thats seems to be a small gain since the timeout is very small My primary goal with the changes to the even loop was to work toward elimination of most timeouts. My focus is on battery powered systems and firing a timer rapidly for minutes at a time drains the battery. - in the current implementation curl_multi_perform may block if theres lots of data queued up on multiple handles, but that can be easily mitigated by returning frequently from curl_multi_perform In my new implementation with only one simple handle per multi the main even loop runs correctly and checks for events from the user in a timely fashion. - what about doing select in separate thread as glibcurl does. i think this is safe as perform happens in the main thread. Why use a different thread to wait in select ? Thats a design decision left to the implementor of the main loop its outside of the scope of the curl binding to try and make this decision. In general servicing these data file handles need to be cooperative with user input however you implement it. How this happens depends on the platform. thanks, Zaheer On Wed, Sep 10, 2008 at 8:40 PM, Mike Emmel [EMAIL PROTECTED] wrote: Look I had to change to one multi handle per handle basically just and asynchronous handle to get everything to clean up. Its a significant refactoring and better design. What it points to on the curl side is the need for and asynchronous simple handle. Also polling was removed as much as possible curl does not send decent time outs if it has real work to perform so this is still a issue. However open file handles are handled in the event loop select. Curl needs to be extended to have the concept of a work request and a longer term watch timeout. So in my opinion the issues are fixed at least to the extent possible without help from the curl team. On Wed, Sep 10, 2008 at 7:53 AM, zaheer ahmad [EMAIL PROTECTED] wrote: hi, The fix only helps little as we see the bigger leaks in curl. feedback from curl experts suggests that this design is correct.. let me know if you are aware of this issue == here's the mail snapshot. we are seeing big leaks in curl (Curl_connect - 600-800k and Curl_open - ~200k) when we browse through as little as few websites. This values keep increasing as we browse more sites. heres the high level logic of webkit=curl interaction 1- create a multi handle at the start of program 2- keep creating easy handles for each request 3- when request is done remove it from multi handle and clean up the handle 4- multi handle is never released (stays till the end of program) This design assumes that multi handle has a bounded memory usage as we keep adding and removing easy handles, but that seems to be not true with the leaks. == Now I just started to use valgrind to find other memory leaks, so this and other issues should be hopefully fixed soon. these are not traditional memory leaks, you are holding on to things longer than you should, so they are more functional leaks. Does valgrind help in that too? thanks, Zaheer On Wed, Sep 10, 2008 at 8:02 PM, Marco Barisione [EMAIL PROTECTED] wrote: Il giorno mer, 10/09/2008 alle 07.22 -0700, Mike Emmel ha scritto: This leak is fixed in the ncurl port. Is it possible to backport the fix? -- Marco Barisione ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit on MIPS
I think all he is asking is where did the built executables end up. Once built the binary for the test executable for Gtk is in Programs/.libs/GtkLauncher a wrapper shell script is in Programs/GtkLauncher The shared liber is in .libs/ In general if your using automake your libs and executables will end up in a .libs somewhere so you can generally do a find on that our you can type make install and they will install wherever you set the --prefix On Fri, Aug 22, 2008 at 8:26 AM, David Kilzer [EMAIL PROTECTED] wrote: On Thu, 8/21/08, ashu_ynr [EMAIL PROTECTED] wrote: I have cross compiled webkit on fedora6 (x86) for MIPS but i am in doubt that it wouldn't work on MIPS target. I didn't do any changes regarding the architecture in the webkit source. Kindly guide me that this cross compiled webkit would work on MIPS or not. If yes then what changes i'll have to make to make it run on MIPS. Compiling and linking the source is usually half the battle. Why can't you test it yourself? MIPS is such a rare architecture these days that it's unlikely anyone on this list uses a MIPS system daily. Also, there is a libwebkit Debian package that's compiled for MIPS (and many other architectures), so there's a chance that it might work: http://packages.debian.org/lenny/libwebkit-1.0-1#pdownload Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit-GTK in embedded system
A number of small simple html renderer's exist that should meet your needs given the description you gave. I'm surprised you would want to use webkit. This one for example. http://www.fifi.org/doc/libgtkhtml-dev/html/gtkhtml.html On Wed, Jul 23, 2008 at 8:17 AM, John Boncek [EMAIL PROTECTED] wrote: Sending again now that I am subscribed -- sorry if you receive a duplicate. In an embedded ARM-based system with Linux and GTK, we are investigating the use of WebKit for HTML display. Web browsing is not needed. Our core goal for WebKit will be to read, parse, and display HTML files that contain text and static images. Is the WebKit code structured so that we can limit what we need to build and include in the file system? For instance, we do not need CSS, DOM, or XSLT. Our ability to make use of WebKit will depend in part on the footprint we can achieve in a memory-constrained system. Thanks for any assistance you can provide. -- View this message in context: http://www.nabble.com/WebKit-GTK-in-embedded-system-tp18612902p18613164.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit-GTK in embedded system
I used in several years ago and it was GTK only and seemed to be capable of what your asking for. I know its used in Evolution but as far as I know its still just a gtk widget. Several more exist. Here is a link to one for some reason the website seemed down when I checked http://www.dillo.org/ I've used this before also and it should do what your asking. The wiki page for dillo has a lot of links to a lot of other browsers. http://en.wikipedia.org/wiki/Dillo And here is a download link that might work for you if the site is really down. http://www.softpedia.com/reviews/linux/Dillo-Review-25310.shtml You would need to do your own research but I'm aware of a number of small html viewers that might meet your requirements. Generally they are used for HTML help viewers. It sounded like your doing something like that. On Wed, Jul 23, 2008 at 9:26 AM, Boncek, John [EMAIL PROTECTED] wrote: Indeed WebKit seems like overkill for what we need. I was aware of GtkHTML but not of this web site. I posted a message to the GTK App Devel list about the apparent dearth of HTML support in GTK and about the fact that GtkHTML in particular came with no usage documentation whatsoever. No one there pointed me to any form of documentation but I received a number of recommendations to use WebKit. Does this documentation apply to the Gnome version of GtkHTML or some other version? The Gnome version is stated to be Evolution-specific, not a general-purpose library. If this documents some other version, where might I find it? -Original Message- From: Mike Emmel [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2008 10:35 AM To: Boncek, John Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] WebKit-GTK in embedded system A number of small simple html renderer's exist that should meet your needs given the description you gave. I'm surprised you would want to use webkit. This one for example. http://www.fifi.org/doc/libgtkhtml-dev/html/gtkhtml.html On Wed, Jul 23, 2008 at 8:17 AM, John Boncek [EMAIL PROTECTED] wrote: Sending again now that I am subscribed -- sorry if you receive a duplicate. In an embedded ARM-based system with Linux and GTK, we are investigating the use of WebKit for HTML display. Web browsing is not needed. Our core goal for WebKit will be to read, parse, and display HTML files that contain text and static images. Is the WebKit code structured so that we can limit what we need to build and include in the file system? For instance, we do not need CSS, DOM, or XSLT. Our ability to make use of WebKit will depend in part on the footprint we can achieve in a memory-constrained system. Thanks for any assistance you can provide. -- View this message in context: http://www.nabble.com/WebKit-GTK-in-embedded-system-tp18612902p18613164.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] help with porting
2008 à 09:30 -0700, Mike Emmel a écrit : Luka I don't think it makes a difference if your running a lot of thumbnails you would want to use gpu's some sort of render farm arrangement. My port does it as a result of the design not because of a strong desire to render with the cpu. Also for real world web pages your going to have problems with plugins which depend on X11 and native widget libraries. So although its possible with my port I can't see a single real problem that can be solved with this approach. Gtk/DirectFB will work for most pages if you have a flash port. Thats the number one stumbling block. I did my headless version of DirectFB for example to use the DirectFB video provider for the media tags. You can take other approaches but you would need to consider at a minimum flash and the media tags. For complete font support your going to have to use pango or go with the QT port but the QT port gets you back to the plugin issues if you don't use X11 and a lot of plugins use GTK so As far as releasing I'm not in control of the release cycle except for creating delays as I work on stuff :( It should be released however some time this year. I obviously don't disagree with your idea in fact I worked hard to ensure my approach was adaptable so it could be used for these types of use cases so someday we will have what your looking for if things go well. I actually designed it to work with all the legacy use cases I mentioned but be flexible enough to transparently drop them when replacements without the legacy X11/Gtk dependencies become available. So soon a framework will be available to allow you to reverse software bloat but I've got no idea if software developers will accept it. I built it to deal with the problems that occur with our new embedded devices that have capabilities rivaling desktops where bloat is a huge problem. The fact it can do what your asking makes me confident the design is correct in fact it solves problems your not considering. On Thu, May 22, 2008 at 8:41 AM, Luka Napotnik [EMAIL PROTECTED] wrote: Wow really? Could you share the port please. I've been looking for such a port to save the cairo painting to a PNG image. Greets, Luka Dne 22.05.2008 (čet) ob 07:41 -0700 je Mike Emmel zapisal(a): I actually have a WebKit port with no dependencies but Cairo. On Thu, May 22, 2008 at 7:02 AM, Luka Napotnik [EMAIL PROTECTED] wrote: Hello Mike. What I need is a WebKit port that is independent of any display server (X or a framebuffer). I only want to render the page to an image. And since cairo is a great graphics library I think It's a good start. Greets, Luka Dne 22.05.2008 (čet) ob 06:49 -0700 je Mike Emmel zapisal(a): Use the GTK DirectFB backend. I have a memory only system that I really need to get into the trunk. But if you have a graphics card in the system the fb0 will work. Its on my TODO to get the mem only system checked in and I can give you a patch in the mean time if its a issue. Also you can use the vnc driver as a virtual framebuffer. Also some of the XServers should work in a similar way so you can probably play the same trick with the right X11 server. On Thu, May 22, 2008 at 4:21 AM, Luka Napotnik [EMAIL PROTECTED] wrote: Hello. I am interested in porting webkit to cairo for off-screen rendering without a X server. As I cannot find any documents about porting to other platform I would really appreciate if you could help me with some hints about porting webkit. Greets, Luka ___ 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 /* * Copyright (C) 2006 Apple Computer, Inc. All rights reserved. * Copyright (C) 2006 Michael Emmel [EMAIL PROTECTED] * Copyright (C) 2007 Pleyo * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list
Re: [webkit-dev] help with porting
Use the GTK DirectFB backend. I have a memory only system that I really need to get into the trunk. But if you have a graphics card in the system the fb0 will work. Its on my TODO to get the mem only system checked in and I can give you a patch in the mean time if its a issue. Also you can use the vnc driver as a virtual framebuffer. Also some of the XServers should work in a similar way so you can probably play the same trick with the right X11 server. On Thu, May 22, 2008 at 4:21 AM, Luka Napotnik [EMAIL PROTECTED] wrote: Hello. I am interested in porting webkit to cairo for off-screen rendering without a X server. As I cannot find any documents about porting to other platform I would really appreciate if you could help me with some hints about porting webkit. Greets, Luka ___ 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] help with porting
I actually have a WebKit port with no dependencies but Cairo. On Thu, May 22, 2008 at 7:02 AM, Luka Napotnik [EMAIL PROTECTED] wrote: Hello Mike. What I need is a WebKit port that is independent of any display server (X or a framebuffer). I only want to render the page to an image. And since cairo is a great graphics library I think It's a good start. Greets, Luka Dne 22.05.2008 (čet) ob 06:49 -0700 je Mike Emmel zapisal(a): Use the GTK DirectFB backend. I have a memory only system that I really need to get into the trunk. But if you have a graphics card in the system the fb0 will work. Its on my TODO to get the mem only system checked in and I can give you a patch in the mean time if its a issue. Also you can use the vnc driver as a virtual framebuffer. Also some of the XServers should work in a similar way so you can probably play the same trick with the right X11 server. On Thu, May 22, 2008 at 4:21 AM, Luka Napotnik [EMAIL PROTECTED] wrote: Hello. I am interested in porting webkit to cairo for off-screen rendering without a X server. As I cannot find any documents about porting to other platform I would really appreciate if you could help me with some hints about porting webkit. Greets, Luka ___ 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] help with porting
Luka I don't think it makes a difference if your running a lot of thumbnails you would want to use gpu's some sort of render farm arrangement. My port does it as a result of the design not because of a strong desire to render with the cpu. Also for real world web pages your going to have problems with plugins which depend on X11 and native widget libraries. So although its possible with my port I can't see a single real problem that can be solved with this approach. Gtk/DirectFB will work for most pages if you have a flash port. Thats the number one stumbling block. I did my headless version of DirectFB for example to use the DirectFB video provider for the media tags. You can take other approaches but you would need to consider at a minimum flash and the media tags. For complete font support your going to have to use pango or go with the QT port but the QT port gets you back to the plugin issues if you don't use X11 and a lot of plugins use GTK so As far as releasing I'm not in control of the release cycle except for creating delays as I work on stuff :( It should be released however some time this year. I obviously don't disagree with your idea in fact I worked hard to ensure my approach was adaptable so it could be used for these types of use cases so someday we will have what your looking for if things go well. I actually designed it to work with all the legacy use cases I mentioned but be flexible enough to transparently drop them when replacements without the legacy X11/Gtk dependencies become available. So soon a framework will be available to allow you to reverse software bloat but I've got no idea if software developers will accept it. I built it to deal with the problems that occur with our new embedded devices that have capabilities rivaling desktops where bloat is a huge problem. The fact it can do what your asking makes me confident the design is correct in fact it solves problems your not considering. On Thu, May 22, 2008 at 8:41 AM, Luka Napotnik [EMAIL PROTECTED] wrote: Wow really? Could you share the port please. I've been looking for such a port to save the cairo painting to a PNG image. Greets, Luka Dne 22.05.2008 (čet) ob 07:41 -0700 je Mike Emmel zapisal(a): I actually have a WebKit port with no dependencies but Cairo. On Thu, May 22, 2008 at 7:02 AM, Luka Napotnik [EMAIL PROTECTED] wrote: Hello Mike. What I need is a WebKit port that is independent of any display server (X or a framebuffer). I only want to render the page to an image. And since cairo is a great graphics library I think It's a good start. Greets, Luka Dne 22.05.2008 (čet) ob 06:49 -0700 je Mike Emmel zapisal(a): Use the GTK DirectFB backend. I have a memory only system that I really need to get into the trunk. But if you have a graphics card in the system the fb0 will work. Its on my TODO to get the mem only system checked in and I can give you a patch in the mean time if its a issue. Also you can use the vnc driver as a virtual framebuffer. Also some of the XServers should work in a similar way so you can probably play the same trick with the right X11 server. On Thu, May 22, 2008 at 4:21 AM, Luka Napotnik [EMAIL PROTECTED] wrote: Hello. I am interested in porting webkit to cairo for off-screen rendering without a X server. As I cannot find any documents about porting to other platform I would really appreciate if you could help me with some hints about porting webkit. Greets, Luka ___ 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] crash when loading certain pages
Would you be willing to try the ncurl patch ? https://bugs.webkit.org/show_bug.cgi?id=17972 I believe I fixed this. On Fri, May 9, 2008 at 5:37 AM, zaheer ahmad [EMAIL PROTECTED] wrote: hi, thanks for the response. unfortunately i dont have a x86 environment to run the valgrind. here is the sequence of events that lead to this failure.. - open nytimes.com - when it is partiially loaded open weather.com - 4 pending jobs in nytimes get cancelled, however the 5th is not and results in crash loading url www.weather.com cancel job bae8f0 url: http://graphics8.nytimes.com/ads/cla/defaultads/RMI/1.30.08/rmi_120x60_btn3.gif cancel job c78388 url: http://graphics8.nytimes.com/images/2008/05/08/sports/09moth_canopy.jpg cancel job cfa2c8 url: http://graphics8.nytimes.com/adx/images/ADS/14/68/ad.146808/dealbookjobs_housead.gif cancel job 3c1920 url: http://graphics8.nytimes.com/images/2008/04/26/jobs/mgmt.75.jpg ++ didReceiveResponse job bc3690 url: http://graphics8.nytimes.com/feedroom/nytc3/creative/bg_notenabled.gif -- incorrect response should have been cancelled And i checked the documentLoader (cancelAll) and it seems to only have 4 entries. investigating on why the fifth job is missing from the document load list.. thanks, Zaheer On Thu, May 8, 2008 at 6:00 AM, Holger Freyther [EMAIL PROTECTED] wrote: On Wednesday 07 May 2008 09:19:51 zaheer ahmad wrote: hi, we are using webkit gtk version r31307. we are facing a random crash when opening certain sites like weather.com, the backtrace is as below You could test if that is happening on a x86/Linux system as well and then use valgrind (and compile with debug symbols) and have profit. kind regards z. ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] native widgets
Not quite correct. It uses native widgets to implement any widget derived from the platform/Widget.h class. These are found in platform/port dirs. Scrolling, Scrollbars, menus are native. Drawing of buttons checkboxes and most form controls is also linked into the native platform in vi a platform specific RenderTheme. This RenderTheme generally uses the platforms theming mechanism. So these could be considered a hybrid. On Tue, Apr 29, 2008 at 8:34 AM, [EMAIL PROTECTED] wrote: Hi, As per my understanding , Webkit does not use the native widgets in any platform. It actually uses custom draw mechanism. It is implemented in the file themegtk/Themewin etc. Sachin Sent from BlackBerry(R) on Airtel -Original Message- From: Mark Volkmann [EMAIL PROTECTED] Date: Tue, 29 Apr 2008 10:15:10 To:webkit-dev@lists.webkit.org Subject: [webkit-dev] native widgets Does WebKit use native widgets on all platforms? If not, does it use native widgets on any platforms? --- Mark Volkmann ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Webkit with directfb on linux
I added zoom support into the gtk layer and I have some patches needed to build directfb if no X11 is installed some files import X11 still mainly the plugin stuff. Turns out to keep zooming in you have to set min font size to zero. And yes I have a few different builds for gtk directfb. Mike On Wed, Apr 9, 2008 at 12:33 AM, Srinivas Rao M Hamse [EMAIL PROTECTED] wrote: Mike, Finally if your using this for thumbnails I also have so zooming patches. What do you mean by zooming patches ?. Is the full page zooming works ? Do you have it for Gtk+DirectFB builds ? regards, Srinivas On Thu, Apr 3, 2008 at 11:34 PM, Mike Emmel [EMAIL PROTECTED] wrote: Yes if you need help with your setup i.e no X11 I have some patches. Also I have some pure memory driver patches for DirectFB itself that I need to push. Finally if your using this for thumbnails I also have so zooming patches. On Thu, Apr 3, 2008 at 10:06 AM, Giri Rao [EMAIL PROTECTED] wrote: Hello, I was wondering if anyone has successfully built webkit with target set to directfb (as opposed to X11) on linux. I have a successful gtk build which is running fine. However, I would like to run webkit on a headless linux machine hence the question. Thanks Giri ___ 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 -- Srinivas Rao M Hamse ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Webkit with directfb on linux
Yes if you need help with your setup i.e no X11 I have some patches. Also I have some pure memory driver patches for DirectFB itself that I need to push. Finally if your using this for thumbnails I also have so zooming patches. On Thu, Apr 3, 2008 at 10:06 AM, Giri Rao [EMAIL PROTECTED] wrote: Hello, I was wondering if anyone has successfully built webkit with target set to directfb (as opposed to X11) on linux. I have a successful gtk build which is running fine. However, I would like to run webkit on a headless linux machine hence the question. Thanks Giri ___ 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] Blank page when using SSL
I think you mean the gtk based browser. You need to make sure curl is compiled with ssl support. On Sun, Mar 30, 2008 at 4:56 PM, Bill Patterson [EMAIL PROTECTED] wrote: I have a webkit based browser, based on MiniBrowser example code, that when displaying a page with SSL comes up empty, just white. Same page without SSL looks fine, and Safari and Shiira display it either with or without SSL no problem. It doesn't call any authentication delegates, and there don't appear to be certificate issues. No errors are thrown. Other SSL pages I've tried work fine in my application. The only thing that looks strange about the page is uses a .do extension, but that isn't being excluded by any of the code. Can anybody give me any idea what might be happening? Thanks, Bill Patterson ___ 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] Timer Bug
Can someone please look at http://bugs.webkit.org/show_bug.cgi?id=18044 This looks like a bad bug and its causing major problems in both the ncurl and curl backends. I'd like to see it resolved in a timely manner. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] wx/Gtk+ and Network backends
Well ncurl and curl should merge into one backend once ncurl been tested. As far as libsoup goes I'd assume that it would eventually grow to be the Gtk/Gnome integrated backend over time with vfs integration lots of custom URL support etc in fact probably merging into vfs. So I think they solve two different problems one for tight desktop integration and one for the webbrowser as a application thats toolkit agnostic. On Fri, Mar 21, 2008 at 10:25 AM, Holger Freyther [EMAIL PROTECTED] wrote: Hey, I'm a bit alarmed by the wild growth of network backends for the Gtk+ port, the pending patches in the bugtracker and the duplication of things that are ahead and have already started. Currently we have a CURL backend shared by Gtk+ and wx. The good thing is it is shared between the two ports. The bad things are. We have no GEventLoop integration on Gtk+ and will poll curl with a timer. It lacks uploading of files (a good looking patch is in the bug tracker), it lacks cookie handling (also a good patch in the bug tracker), authentication is missing as well. Recently a libsoup based backend got added. I assume it has event loop integration, from blogs I know that upstream has looked into cookies. Which probably leaves authentication, cookie management, form uploads, sync loading of resources open as well. Mike just proposed another CURL backend that will fix the above event loop handling (from what I see). The first bugs for CURL already have attachments like Do this for SOUP as well. So the duplication of effort already started. What I like to have answered/see is: - Is it a strict requirement that Gtk+/WX share the same backend? (I think not) - Can we please just use one backend for the Gtk+ port? We do not use DRT in a sane way so it will be a hell to maintain three backends and make sure that all of them have the same amount of features. E.g. the first consequence would be to have three build bots running for the three backends.. So please before wasting more time on implementing the same things for different backends let us wotk on one together. I do not care if it is curl+glib, soup, neon... 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
Re: [webkit-dev] wx/Gtk+ and Network backends
Hi I'm assuming that windows has a way to add file handles to the event loop ? I've never done it. As far as curl itself goes just to let you know what I'm doing. Once ncurl is in say in a month or two I want to dig into curl and add a call back for messages this should remove a lot of the polling that is still going on. Once this is done I think we can get good numbers from curl for timeouts for the remaining polling. We will always need a long watchdog timeout and a small amount of polling. After that I want to add the code to sniff a file type using http://sourceforge.net/projects/libmagic Example here. http://curl.haxx.se/mail/lib-2004-07/0060.html It would be nice for the libmagic support to be in curl itself but not important. On Fri, Mar 21, 2008 at 10:43 AM, Daniel Zucker [EMAIL PROTECTED] wrote: Hi Holger, Another customer for the CURL backend used by Gtk+ and wx is the Windows-Cairo or Native Windows version. Brent Fulgham and I have been working on some patches to use this CURL code in this Windows version. When all the patches are landed (if not already now) this CURL code will be fully functional on Windows. Being lazy programmers (speaking for myself at least :)), we would like to continue to leverage the CURL work from other ports as much as possible. We look forward to continue sharing the current CURL code as well as add the upcoming support for authentication, web download, and possibly cookies. Cheers, Dan On Fri, Mar 21, 2008 at 10:25 AM, Holger Freyther [EMAIL PROTECTED] wrote: Hey, I'm a bit alarmed by the wild growth of network backends for the Gtk+ port, the pending patches in the bugtracker and the duplication of things that are ahead and have already started. Currently we have a CURL backend shared by Gtk+ and wx. The good thing is it is shared between the two ports. The bad things are. We have no GEventLoop integration on Gtk+ and will poll curl with a timer. It lacks uploading of files (a good looking patch is in the bug tracker), it lacks cookie handling (also a good patch in the bug tracker), authentication is missing as well. Recently a libsoup based backend got added. I assume it has event loop integration, from blogs I know that upstream has looked into cookies. Which probably leaves authentication, cookie management, form uploads, sync loading of resources open as well. Mike just proposed another CURL backend that will fix the above event loop handling (from what I see). The first bugs for CURL already have attachments like Do this for SOUP as well. So the duplication of effort already started. What I like to have answered/see is: - Is it a strict requirement that Gtk+/WX share the same backend? (I think not) - Can we please just use one backend for the Gtk+ port? We do not use DRT in a sane way so it will be a hell to maintain three backends and make sure that all of them have the same amount of features. E.g. the first consequence would be to have three build bots running for the three backends.. So please before wasting more time on implementing the same things for different backends let us wotk on one together. I do not care if it is curl+glib, soup, neon... 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timer bug ?
Well one build give isActive as true and another does not so its
something in the build weird.
On Mon, Mar 17, 2008 at 6:39 PM, Mike Emmel [EMAIL PROTECTED] wrote:
I just found something that seems wrong.
When a timer callback is fired for a oneshot timer isActive is true in
the handler.
In my opinion it should be false.
bool TimerBase::isActive() const
{
return m_nextFireTime || (timersReadyToFire
timersReadyToFire-contains(this));
}
Its seems at least on my build that
// Setting the next fire time has a side effect of removing the
timer from the firing timers set.
double interval = timer-repeatInterval();
timer-setNextFireTime(interval ? fireTime + interval : 0);
Is resulting in the timer left in the heap with a zero fire time this
still active.
Not sure why but
void TimerBase::setNextFireTime(double newTime)
{
// Keep heap valid while changing the next-fire time.
if (timersReadyToFire)
timersReadyToFire-remove(this);
double oldTime = m_nextFireTime;
if (oldTime != newTime) {
m_nextFireTime = newTime;
Should be I think
if (!newTime || (oldTime != newTime)) {
It looks like two calls to stop result in the timer added back with
zero fire time ?
Not sure whats going on but...
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mimetype for files loaded from disk?
In the curl backed some code uses file extensions to set the mime type for local files. I'm not sure css files are handled. On Sun, Mar 16, 2008 at 9:22 PM, Kevin Ollivier [EMAIL PROTECTED] wrote: Hi all, I've hit an issue with the wx port where HTML files that use @import url(file.css) will not load when the HTML and CSS file are on disk rather than loaded via the web. After tracking it down, I found that I could resolve the issue by having CURL set the file type for m_response to application/x-unknown-content-type, which enables the CachedCSSStyleSheet::canUseSheet test to pass, but I'm not sure this is the right approach. Another wrinkle to this issue is that this problem doesn't appear on the Windows wx port, only Linux/Mac. I'm fairly certain this discrepancy is not due to wx code, and so I was wondering how other ports (Apple's and otherwise) handle this issue. Is there some alternative approach to setting the mimetype explicitly, or is there some extension - mimetype mapping being used in some cases? Thanks, Kevin ___ 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] https pages crashes WebKit(GTK+DFB) on ARM
() at ../WebCore/platform/Timer.cpp:368 #57 0x4032a198 in timeout_cb () at ../WebCore/platform/gtk/SharedTimerGtk.cpp:48 #58 0x4177b2ac in g_timeout_dispatch (source=0xe27e0, callback=0x4032a168 timeout_cb, user_data=0x3000) at gmain.c:3488 #59 0x41778678 in IA__g_main_context_dispatch (context=0x33708) at gmain.c:2061 #60 0x4177a090 in g_main_context_iterate (context=0x33708, block=1, dispatch=1, self=0x11060) at gmain.c:2694 #61 0x4177a2f0 in IA__g_main_loop_run (loop=0x2cde8) at gmain.c:2898 #62 0x413a6d98 in IA__gtk_main () at gtkmain.c:1146 #63 0x9cec in main (argc=2, argv=0xbea41ba4) at ../WebKitTools/GtkLauncher/main.c:200 (gdb) info threads 9 Thread 114696 (LWP 1224) 0x41fe5134 in __pthread_sigsuspend () from /lib/libpthread.so.0 8 Thread 98311 (LWP 1223) 0x421c6578 in select () from /lib/libc.so.6 7 Thread 81926 (LWP 1222) 0x41fe5134 in __pthread_sigsuspend () from /lib/libpthread.so.0 6 Thread 65541 (LWP 1221) 0x41fe5134 in __pthread_sigsuspend () from /lib/libpthread.so.0 5 Thread 49156 (LWP 1220) 0x421c5e44 in ioctl () from /lib/libc.so.6 4 Thread 32771 (LWP 1219) 0x41fe5134 in __pthread_sigsuspend () from /lib/libpthread.so.0 3 Thread 16386 (LWP 1218) 0x41fe5134 in __pthread_sigsuspend () from /lib/libpthread.so.0 2 Thread 32769 (LWP 1211) 0x421c4450 in poll () from /lib/libc.so.6 * 1 Thread 16384 (LWP 1184) Balloc (k=14) at ../JavaScriptCore/kjs/dtoa.cpp:522 (gdb) Pleaese help me fix this crash. regards, Srinivas Rao. M On Thu, Mar 6, 2008 at 1:11 PM, Mike Emmel [EMAIL PROTECTED] wrote: Can you attach a debugger and get a trace ? I just checked a X11 build and it worked fine. Try directfb under X86 see if you can repeat it. On Wed, Mar 5, 2008 at 11:06 PM, Srinivas Rao M Hamse [EMAIL PROTECTED] wrote: Hi I am trying to run WebKit-r30790 build on ARM target. I have disabled server Peer certification by setting the environment variable WEBKIT_IGNORE_SSL_ERRORS while running. with this setup, I am able to open simple https sites like https://horizon.opensrs.net But webkit crashes when i open sites like https://opensrs.net https://sourceforge.net https://mail.google.com It segfaults after dumping the following log on console: # pwd /sr/docs/webkit/WebKit-r30790.davinci.directfb/debugbuild/Programs/.libs # # ./GtkLauncher https://sourceforge.net ===| DirectFB 1.1.1 |=== (c) 2001-2007 The DirectFB Organization (directfb.org) (c) 2000-2004 Convergence (integrated media) GmbH (*) DirectFB/Core: Single Application Core. (2008-02-26 11:33) (*) Direct/Thread: Running 'VT Switcher' (CRITICAL, 2945)... init_ir_loop Inintializing IR msp430lib_set_params: success (*) Direct/Thread: Running 'LiRC Input' (INPUT, 2952)... (*) DirectFB/Input: LIRC Device 0.2 (directfb.org) (!) Direct/Modules: Could not open module directory `/home/srinirao/directfb/lib/directfb-1.1-0-pure/gfxdrivers'! -- No such file or directory (*) DirectFB/Graphics: Generic Software Rasterizer 0.6 (directfb.org) (*) DirectFB/Core/WM: Default 0.3 (directfb.org) (*) FBDev/Mode: Testing 720x480 RGB16 (*) FBDev/Mode: Preparing switch to 720x480 RGB16 (*) FBDev/Mode: Testing 720x480 RGB16 (*) FBDev/Mode: Preparing switch to 720x480 RGB16 (*) FBDev/Mode: Testing 720x480 RGB16 (*) FBDev/Mode: Preparing switch to 720x480 RGB16 (*) FBDev/Mode: Testing 720x480 RGB16 (*) FBDev/Mode: Preparing switch to 720x480 RGB16 (*) FBDev/Mode: Testing 720x480 RGB16 (*) FBDev/Mode: Preparing switch to 720x480 RGB16 (*) FBDev/Surface: Allocated 720x480 16bit RGB16 buffer at offset 0 and pitch 1440. (*) FBDev/Mode: (Post)Setting 720x480 RGB16 (*) FBDev/Mode: Switched to 720x480 (720x480) at 16 bit RGB16 (wanted RGB16). (*) FBDev/Mode: Testing 720x480 RGB16 (*) FBDev/Mode: Preparing switch to 720x480 RGB16 (*) FBDev/Mode: (Post)Setting 720x480 RGB16 gdkdisplay-directfb.c:122: Getting the return value as 0 (*) Direct/Thread: Running 'EventBufferFeed' (MESSAGING, 2953)... (GtkLauncher:2921): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/home/srinirao/gtk/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or director y (GtkLauncher:2921): Gdk-DirectFB-WARNING **: gdk_display_request_selection_notification Unimplemented function (GtkLauncher:2921): Gdk-DirectFB-WARNING **: gdk_window_set_keep_above() not implemented. (GtkLauncher:2921): Gdk-DirectFB-WARNING **: gdk_window_set_keep_below() not implemented. (!) [ 2921:0.000] -- Caught signal 11 (at 0x3000, invalid address) -- (!!!) *** WARNING [still objects
Re: [webkit-dev] https pages crashes WebKit(GTK+DFB) on ARM
Ohh and make sure curl is compiled with ssl support sorry forgot that part.
I was seeing crashes in the old curl driver is ssl was disabled.
On Thu, Mar 6, 2008 at 8:31 AM, Mike Emmel [EMAIL PROTECTED] wrote:
What is the gcc version ?
Can you try with the lastest.
On Thu, Mar 6, 2008 at 6:31 AM, Srinivas Rao M Hamse
[EMAIL PROTECTED] wrote:
Forwarding the message to the list with some more debugging information.
Hi,
The backtrace is finally available. From this i i think it is crashing in
Balloc() function. We have enabled swap, And when the crash happened there
was ample amount of memory free in the system. This crash is consistently
reproducible on ARM.
crash point is at
JavaScriptCore/kjs/dtoa.cpp:522
The pointer of freenode is corrupted value.
(gdb) p freelist[k]
$2 = (Bigint *) 0x3000
(gdb) p freelist
$24 = {0x1bbe30, 0x30303030 repeats 13 times, 0x3000, 0x0}
(gdb) p rv
$25 = (Bigint *) 0x3000
(gdb) p rv-next
Cannot access memory at address 0x3000
(gdb) p *rv
Here is the output of meminfo ofter the crash.
# cat /proc/meminfo
MemTotal:73400 kB
MemFree: 1600 kB
Buffers: 0 kB
Cached: 2692 kB
SwapCached: 29888 kB
Active: 48352 kB
Inactive: 6736 kB
HighTotal: 0 kB
HighFree:0 kB
LowTotal:73400 kB
LowFree: 1600 kB
SwapTotal: 1953464 kB
SwapFree: 1794440 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 49020 kB
Mapped: 1592 kB
Slab: 2376 kB
PageTables:568 kB
NFS_Unstable:0 kB
Bounce: 0 kB
CommitLimit: 1990164 kB
Committed_AS: 219836 kB
VmallocTotal: 454656 kB
VmallocUsed: 968 kB
VmallocChunk: 453688 kB
Here is the gdb console output [ .. pretty long trace .. i thought it will
be useful for analysis, excuse me for that ...]
# /data/srini/gdb ./GtkLauncher
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as arm-linux...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) r https://sourceforge.net
Starting program:
/home/srinirao/docs/webkit/WebKit-r30790.davinci.directfb/debug_gbuild/Programs/.libs/GtkLauncher
https://sourceforge.net
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 1184)]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
===| DirectFB 1.1.1 |===
(c) 2001-2007 The DirectFB Organization (directfb.org)
(c) 2000-2004 Convergence (integrated media) GmbH
(*) DirectFB/Core: Single Application Core. (2008-03-06 11:15)
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[New Thread 32769 (LWP 1211)]
[New Thread 16386 (LWP 1218)]
(*) Direct/Thread: Running 'VT Switcher' (CRITICAL, 1218)...
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
init_ir_loop
Inintializing IR
[New Thread 32771 (LWP 1219)]
msp430lib_set_params: success
[New Thread 49156 (LWP 1220)]
[New Thread 65541 (LWP 1221)]
[New Thread 81926 (LWP 1222)]
got DAVINCI_GPIO_IRQ_WAIT ioctl ...
[New Thread 98311 (LWP 1223)]
(*) Direct/Thread: Running 'LiRC Input' (INPUT, 1223)...
(*) DirectFB/Input: LIRC Device 0.2 (directfb.or got DAVINCI_GPIO_IRQ_WAIT
ioctl ...
g)
(!) Direct/Modules: Could not open module directory
`/home/srinirao/directfb/lib/directfb-1.1-0-pure/gfxdrivers
Re: [webkit-dev] Regarding WebKit Support Libraries
I'd like to see a pretty much pure open source solution available for all platforms. By pure I mean down to the core windowing and libc level. As far as porting curl to WinCE. Found this. http://curl.haxx.se/mail/lib-2002-07/0085.html A obvious reason to have this available is it makes it easier to support new standards or get around show stopper bugs in closed libraries. But generally its a philosophical issue. Outside of designing the port to accommodate multiple solutions it should not have a big impact. In general we already have a problem on the Linux port because of the multiple support libraries possible. Right now this means a number of incompatible versions of webkit need to be installed but 99% of the code is shared. We potentially could have QT/wxWidget/gtk-x11/gtk-directfb/openstep versions on one box. and whatever Adobe is doing. On windows and OSX you add one more. Plus later Googles stuff and whatever Sun is doing. Not to mention applications like mail clients etc. The lack of a shared core makes things troublesome even on the desktop. So the code size argument is a subset of a larger shared code problem with the current project. On Feb 17, 2008 9:15 AM, Daniel Zucker [EMAIL PROTECTED] wrote: Hi Alp and Brent, My vote is to use Wininet. This is because my objective is to eventually support a WinCE version. Wininet is used in both Win32 and WinCE, so it is a convenient choice from this point of view. CURL would be OK if it could be easily ported to WinCE. I haven't looked into that, so I don't know the difficulty. But, I suspect it is non-trivial. Also, it would have the downside of requiring extra code which increases the static application size. (Static application size is an important consideration for mobile use cases). So, I vote for using Wininet. There was Wininet support in the codebase earlier. I believe this could be resurrected without too much trouble. Cheers, Dan On Feb 15, 2008 5:33 AM, Brent Fulgham [EMAIL PROTECTED] wrote: Hi Alp, On Feb 14, 2008, at 2:05 AM, Alp Toker wrote: Brent Fulgham wrote: In the medium term, I will probably end up ripping out the CFNetwork code to replace with native windows calls, though it would be nice to avoid this needless work. The CURL http backend used by the GTK+ and Wx ports works on Windows, though it's not as complete as CFNetwork. It could do the job till the CFNetwork issues are resolved. In light of Apple's recent notification (today) that CFNetwork would no longer be available as open source, I think we've got to shift to the CURL back-end. There are really only three options I see: 1. If license allows, take the existing APSL CFNetwork sources and attempt to use it. Downsides: lots of work to achieve existing features. No real upside. 2. Implement native WinInet versions of features from CFNetwork. Downsides: Single-platform, minimal reuse. Not much assistance to find problems. 3. Use CURL library. Benefits: Assist in CURL development, share code with other project targets (read: I get to bug Alp when I have problems). Downside: Mostly just the manual effort of conditionalizing the CFNetwork code. Of these, the only one that really seems desirable to me is the CURL back-end. CFNetwork is integrated into the Win port (consider how HTTP resource errors are handled and passed up to the UI) so swapping it out for something else may have some unfortunate maintenance overhead (ifdefs, more platform splits, and associated build system changes). Agreed, but I don't see that we have much choice at this point. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Issues with font rendering on DirectFB build
Also Dennis just fixed a missing call to set the screen resolution in the gdk/directfb backend. So now we should not error :) On Fri, Feb 15, 2008 at 3:50 AM, Rachel Bassett [EMAIL PROTECTED] wrote: Big thanks for this fix - works a treat. Left webkit rendering over night, still working this morning, lovely job. Thanks again Rachel --- Alp Toker [EMAIL PROTECTED] wrote: For the record, the fix for this issue was landed (with modifications) in r30201: http://trac.webkit.org/projects/webkit/changeset/30201 __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Re: Issues with font rendering on DirectFB build
Alp attached is my patch to remove X11 refs if you building for gtk/directfb.
Its not quite right since you have the case of X11/GTK on Windows
thats not dealt with.
I think some more changes are needed in the headers to build that variant.
It adds PLATFORM(X11) and PLATFORM(DIRECTFB)
I need the DIRECTFB one later for my movie backend using directfb
video providers.
Which I need to submit.
I don't think the GStreamer backend has to be gtk specific. We should
be able to
do a variety of bindings that are generic.
On Feb 13, 2008 7:29 AM, Mike Emmel [EMAIL PROTECTED] wrote:
So should defaultOptions be set to something sane or is nulls ok ?
I think the real problem is the above screen resolution issue but I'm
not sure about
the interaction between screen scaling and the base font options. It
seems to me we don't want to allow fonts to scale below a certain size
?
On a side note we should add get/setDefaultOptions and the above code
should move into the webkit binding layer.
Also the same for dpi I think it should be up in the app and we push
the value down
via get/setScreenResolution.
This approach decouples the cairo/font code from gtk so it can be used
for other ports.
On Feb 13, 2008 3:27 AM, Alp Toker [EMAIL PROTECTED] wrote:
Christian Dywan wrote:
While that might fix the problem, hardcoding arbitrary values is not
exactly advisable.
It should be interesting to figure out what causes this function to fail
in the first place.
The answer lies in the documentation for gdk_screen_get_resolution():
Returns: the current resolution, or -1 if no resolution has been set.
So Sriram's patch is absolutely correct (coding-style issues aside).
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
diff --git a/GNUmakefile.am b/GNUmakefile.am
index 054265a..66f9233 100644
--- a/GNUmakefile.am
+++ b/GNUmakefile.am
@@ -200,6 +200,12 @@ endif
if TARGET_X11
global_cppflags += -DXP_UNIX
+global_cppflags += -DBUILDING_X11__
+endif
+
+if TARGET_DIRECTFB
+global_cppflags += -DXP_UNIX
+global_cppflags += -DBUILDING_DIRECTFB__
endif
if !ENABLE_DEBUG
diff --git a/JavaScriptCore/bindings/npapi.h b/JavaScriptCore/bindings/npapi.h
index ba8b6c7..c1581b1 100644
--- a/JavaScriptCore/bindings/npapi.h
+++ b/JavaScriptCore/bindings/npapi.h
@@ -86,9 +86,11 @@
#include OpenGL/OpenGL.h
#endif
-#ifdef XP_UNIX
+#ifdef XP_UNIX
+#if PLATFORM(X11)
#include X11/Xlib.h
#include X11/Xutil.h
+#endif
#include stdio.h
#endif
@@ -247,11 +249,13 @@ typedef struct
typedef struct
{
+#if PLATFORM(X11)
int32 type;
Display*display;
Visual* visual;
Colormapcolormap;
unsigned intdepth;
+#endif
} NPSetWindowCallbackStruct;
typedef struct
@@ -449,9 +453,13 @@ typedef struct _NPEvent
uint32 lParam;
} NPEvent;
#elif defined (XP_UNIX)
+#if PLATFORM(X11)
typedef XEvent NPEvent;
#else
typedef void*NPEvent;
+#endif
+#else
+typedef void*NPEvent;
#endif /* XP_MAC */
#if defined(XP_MAC)
@@ -470,9 +478,13 @@ typedef CGPathRef NPCGRegion;
#elif defined(XP_WIN)
typedef HRGN NPRegion;
#elif defined(XP_UNIX)
+#if PLATFORM(X11)
typedef Region NPRegion;
#else
typedef void *NPRegion;
+#endif /*PLATFORM(X11)*/
+#else
+typedef void *NPRegion;
#endif /* XP_MAC */
#ifdef XP_MACOSX
diff --git a/JavaScriptCore/bindings/npruntime_internal.h b/JavaScriptCore/bindings/npruntime_internal.h
index f5357cd..83655d2 100644
--- a/JavaScriptCore/bindings/npruntime_internal.h
+++ b/JavaScriptCore/bindings/npruntime_internal.h
@@ -27,9 +27,8 @@
#include npruntime.h
-#ifdef XP_UNIX
+#if PLATFORM(X11)
#include X11/Xresource.h
-
#undef None
#undef Above
#undef Below
@@ -37,3 +36,4 @@
#undef Complex
#undef Status
#endif
+
diff --git a/JavaScriptCore/wtf/Platform.h b/JavaScriptCore/wtf/Platform.h
index 5cde2fe..9a880c7 100644
--- a/JavaScriptCore/wtf/Platform.h
+++ b/JavaScriptCore/wtf/Platform.h
@@ -101,6 +101,14 @@
#define WTF_PLATFORM_WIN 1
#endif
+#if defined(BUILDING_DIRECTFB__)
+#define WTF_PLATFORM_DIRECTFB 1
+#endif
+
+#if defined(BUILDING_X11__)
+#define WTF_PLATFORM_X11 1
+#endif
+
/* Graphics engines */
/* PLATFORM(CG) */
diff --git a/configure.ac b/configure.ac
index 4bbb54d..34a5132 100644
--- a/configure.ac
+++ b/configure.ac
@@ -150,6 +150,7 @@ case $with_webkit_target in
*) AC_MSG_ERROR([Invalid target: must be x11, quartz, win32, or directfb.]) ;;
esac
+
AC_MSG_RESULT([$with_webkit_target])
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Issues with font rendering on DirectFB build
Hmm this is a fontconfig issue looks like.
I'll trace it for a bit weird that its only in the directfb build same
fontconfig for X11.
Thanks for the work around.
On Feb 12, 2008 8:32 PM, Sriram Neelakandan
[EMAIL PROTECTED] wrote:
Hi Mike,
Even I found the same problem. tiny fonts on the FB screen !
I added some prints and noticed that the fontDescription.computedSize() was
1.0 for some reason. !!
so i added the following lines in the constructor of
WebCore/platfrom/graphics/gtk/FontPlatformDataGtk.cpp
*** FontPlatformDataGtk.cpp.org 2008-02-05 13:59:50.0 +0530
--- FontPlatformDataGtk.cpp 2008-02-12 16:29:20.0 +0530
*** FontPlatformData::FontPlatformData(const
*** 47,56
--- 47,64
int fcslant = FC_SLANT_ROMAN;
int fcweight = FC_WEIGHT_NORMAL;
float fcsize = fontDescription.computedSize();
+ if(fontDescription.computedSize() == 1.0)
+ {
+ /*fontDescription.setComputedSize(16.0);*/
+ m_fontDescription.setComputedSize(16.0);
+ fcsize = 16.0;
+ }
+
if (fontDescription.italic())
fcslant = FC_SLANT_ITALIC;
if (fontDescription.bold())
fcweight = FC_WEIGHT_BOLD;
This has temporarily fixed the problem.
I donot know the cause why the fontsize is computed as 1.0 !!
--
Sriram Neelakandan
Author - Embedded Linux System Design And Development
(http://tinyurl.com/2doosu)
On Feb 13, 2008 9:32 AM, Mike Emmel [EMAIL PROTECTED] wrote:
Hi Rachel just got my directfb build working on the latest head.
What I'm seeing is that fonts are scaled down to thin lines. And other
scaling issues.
I'm assuming this is what you may be seeing.
This is only under the directfb/gtk build not the webkit one.
Also I looked over my changes and they are related mainly to not having
X11
installed at all you probably can build without them but you would
crash eventually
in a few places.
On Feb 11, 2008 3:43 AM, Rachel Bassett [EMAIL PROTECTED]
wrote:
Thanks for the responses, however I don't think it is
the same. Looking at the google homepage image (on the
link you sent), the text Web Images News etc
appears, as well as the blue highlighted links to the
right and below the search box. I don't get any of
that - just images, the search box and the buttons.
I naively thought that if I could run gtk-demo
successfully and see all the fonts it displays, then I
assumed I had correctly built everything needed. I
have also checked my config.log files for both pango
and cairo and they indeed show I have built cairo for
directfb and pango for cairo. I had initial problems
with gtk-demo not displaying fonts, but that was a
pango problem and now solved.
So I assuming WebKit does something slightly different
but as yet I don't understand what.
My current thoughts are that its possibly path related
- I'm working through the output from strace to check
the differences between running WebKit native on a
Linux PC and WebKit cross compiled on my mips
hardware.
Do I need a gtkrc to point at where fonts / styles
are?
Many thanks
Rachel
--- Srinivas Rao M Hamse [EMAIL PROTECTED] wrote:
I am posting the same question to everybody on the
list. Any updates on this
?
regards,
Srinivas Rao. M
On Feb 11, 2008 10:08 AM, Sriram Neelakandan
[EMAIL PROTECTED]
wrote:
Hi
Are u seeing problems similar to this :
http://msrinirao.blogspot.com/search/label/webkit
If u notice closely the pictures attached have
tiny fonts.
Have u found a solution to your problem ?
Just wondering if both of you could be seeing the
same problem.
regards
Sriram
On Feb 8, 2008 8:07 PM, Rachel Bassett
[EMAIL PROTECTED] wrote:
Hi,
I'm working on a cross compiled build using
DirectFB,
gtk+, WebKit build too, however I get no fonts
at all!
I get images, buttons, etc but no text. I've
tested
gtk+ with gtk-demo and fonts appear correctly
there,
I've rebuilt my fontconfig cache and checked
(using
strace) all the font files get found and opened
as
expected, however I see no text.
Any hints welcome.
Thanks
Rachel
___
Yahoo! Answers - Got a question? Someone out
there knows the answer. Try
it
now.
http://uk.answers.yahoo.com/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
--
Sriram Neelakandan
Author - Embedded Linux System Design And
Development
Re: [webkit-dev] Issues with font rendering on DirectFB build
Hi Rachel just got my directfb build working on the latest head. What I'm seeing is that fonts are scaled down to thin lines. And other scaling issues. I'm assuming this is what you may be seeing. This is only under the directfb/gtk build not the webkit one. Also I looked over my changes and they are related mainly to not having X11 installed at all you probably can build without them but you would crash eventually in a few places. On Feb 11, 2008 3:43 AM, Rachel Bassett [EMAIL PROTECTED] wrote: Thanks for the responses, however I don't think it is the same. Looking at the google homepage image (on the link you sent), the text Web Images News etc appears, as well as the blue highlighted links to the right and below the search box. I don't get any of that - just images, the search box and the buttons. I naively thought that if I could run gtk-demo successfully and see all the fonts it displays, then I assumed I had correctly built everything needed. I have also checked my config.log files for both pango and cairo and they indeed show I have built cairo for directfb and pango for cairo. I had initial problems with gtk-demo not displaying fonts, but that was a pango problem and now solved. So I assuming WebKit does something slightly different but as yet I don't understand what. My current thoughts are that its possibly path related - I'm working through the output from strace to check the differences between running WebKit native on a Linux PC and WebKit cross compiled on my mips hardware. Do I need a gtkrc to point at where fonts / styles are? Many thanks Rachel --- Srinivas Rao M Hamse [EMAIL PROTECTED] wrote: I am posting the same question to everybody on the list. Any updates on this ? regards, Srinivas Rao. M On Feb 11, 2008 10:08 AM, Sriram Neelakandan [EMAIL PROTECTED] wrote: Hi Are u seeing problems similar to this : http://msrinirao.blogspot.com/search/label/webkit If u notice closely the pictures attached have tiny fonts. Have u found a solution to your problem ? Just wondering if both of you could be seeing the same problem. regards Sriram On Feb 8, 2008 8:07 PM, Rachel Bassett [EMAIL PROTECTED] wrote: Hi, I'm working on a cross compiled build using DirectFB, gtk+, WebKit build too, however I get no fonts at all! I get images, buttons, etc but no text. I've tested gtk+ with gtk-demo and fonts appear correctly there, I've rebuilt my fontconfig cache and checked (using strace) all the font files get found and opened as expected, however I see no text. Any hints welcome. Thanks Rachel ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Sriram Neelakandan Author - Embedded Linux System Design And Development ( http://tinyurl.com/2doosu) -- Srinivas Rao M Hamse __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Issues with font rendering on DirectFB build
Generally this means you did not build pango with the pangocairo backend or possible cairo without the directfb backend. The next cause is incorrect set up or missing fonts for fontconfig. You should try some test cairo programs. I've built it and it runs just fine I have a few patchs I need to submit I had to add to make it work. The changes I had to make may also be causing you problems. Not sure if they are obvious. I've got to fly from Berlin to LA so ping Alp Toker or me next week and he should have all the patches that result in a functional gtk/directfb build. On Feb 8, 2008 6:37 AM, Rachel Bassett [EMAIL PROTECTED] wrote: Hi, I'm working on a cross compiled build using DirectFB, gtk+, WebKit build too, however I get no fonts at all! I get images, buttons, etc but no text. I've tested gtk+ with gtk-demo and fonts appear correctly there, I've rebuilt my fontconfig cache and checked (using strace) all the font files get found and opened as expected, however I see no text. Any hints welcome. Thanks Rachel ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ ___ 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: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
Then make it SVN I don't care. If git is that big of a hurdle then create a collaboration are using SVN. I did not mean to get into a git vs svn match. Git just seemed to me to be a better choice for the type of branching and merging and needed for a collaboration area. SVN, cvs rcs, sccs anything is better than nothing. Right now we have nothing. On Jan 11, 2008 11:51 PM, Mark Rowe [EMAIL PROTECTED] wrote: On 12/01/2008, at 18:13, Mike Emmel wrote: Webkit is a fairly sophisticated piece of code using git for daily development is trivial. I'd expect any developer who was collaborating on webkit would also be capable of learning git. Something as simple as this is sufficient. http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html Or maybe even this ? http://trac.webkit.org/projects/webkit/wiki/UsingGitWithWebKit I've worked with a number of people that have been interested in experimenting with Git for use with WebKit. The feedback I have received from the majority of them is that git is much less friendly to use than Subversion, and that the documentation is hard to follow for new users. It does have its benefits once you understand how to use it, but it has a hell of a learning curve before you get to that point. I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. A minimal-effort solution could be to use http://repo.or.cz/ ,and create a wiki page to catalogue the locations of git repositories that other developers are using. A quick glance shows that Holger has a repository on repo.or.cz, and there appears to be a GNUstep port hosted there too. As best I can tell, this light-weight approach would fulfil your immediate need. I take it you did not look at that repository that carefully. http://repo.or.cz/w/webbrowser.git I tried this over a year ago and found that your incorrect in your assumptions about the suitability. If you're going to write off all possible solutions except the one you have set your mind on then I feel this discussion is not going to get very far. Why wait your now officially supporting git via svn tracking. A clone server that allows developer to create common working areas is a small step. I'd say you have already done most of the work. I'd suspect that members of the open source community would be willing to help with git issues if they arise. Also the tool is used for a lot of large open source projects most if not all of opendesktop.org is under git. And I'd say that X11 development alone is at least as complex as webkit not to mention linux kernel development. Given that you already support a git server and that large open source projects are successfully using git I think the argument your making is weak at best. We clearly have different definitions of support. git.webkit.org provides a git-svn mirror. However, working with that mirror is left up to the end user. We provide no documentation for it or expectations that all our tools will function correctly. You also appear to be under the impression that because a given tool is used by another project it must be suitable for adoption by WebKit. The projects you mention have different development models, processes and supported platforms that may make the tool more suitable for them. Another immediate need is if you did this I'd like to ask Pleyo to move there development over to this new open git server. Pleyo has done some fairly innovative work but they have diverged from the main tree and it would take time and effort to take some of there ideas and adopt them to the mainline code base. I'm not speaking for Pleyo but its a shame that their work has no easy way to make it back into the mainline development tree. As far as I am aware they have made little effort to contribute changes back. Pleyo has been more than willing to merge changes from trunk WebKit, or even unfinished patches in Bugzilla, so claiming they need git to make submitting changes possible feels very much like blaming the tools for a social problem. Your webkit ports list has none of this work listed. http://trac.webkit.org/projects/webkit/wiki It's a wiki. I would encourage you to add info about these projects. Your QT port does not have the git working repository linked in a obvious manner if at all. http://trac.webkit.org/projects/webkit/wiki/QtWebKit Sure it does: click Information for Contributors. I see no reason to have this stuff scattered across the internet. Why can't webkit.org offer to host these ports ? I have already outlined the reasons why *I* feel it is premature for the WebKit project to do this at this time. If you feel strongly about this, I would suggest you trade talk for action
Re: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
On Jan 11, 2008 12:14 PM, Mark Rowe [EMAIL PROTECTED] wrote: [This is drifting far from Alp's original email. I hope the points he raised are not overlooked due to discussion on this very tangential topic.] On 12/01/2008, at 06:55, Mike Emmel wrote: And its a good way to allow developers to build up a work history to ask for main commit rights. We already have a well-defined policy for how this is handled, http://webkit.org/coding/commit-review-policy.html . I don't see what hosting git repositories has to do with Subversion commit access. I have a patch for example to allow the gtk webkit to run on OSX. But its a workaround for a bug in the cairo OSX port. I'd like to be able to get the patch public and work with the cairo OSX port maintainer to explain why I did what I did and what he could do to cairo to fix OSX cairo. Without a public work area this sort of problem is difficult to work on. Assuming cairo is fixed then we would need to figure out version info for the OSX port of GTK etc etc. I've found email works really well for discussing patches in the past. Indeed, that's what we use for a lot of patch discussion inside Apple. Would an official, public git repository make this easier? Possibly. A git repository for collaboration is a nicety, but hardly a necessity. As Oliver mentioned, it is not at all difficult to publish your own public git repository. I never claimed it was a necessity I just think it would be a very nice to have. And I think it would foster getting more code ready for submission faster and easier. As far as the current process for submission goes nothing wrong with it. Being able to run the OSX port and the gtk port at the same time on OSX is a nice feature. Other open source ports such as QT might want a similar workspace for similar problems. Staikos Computing Services provides something similar to what you describe for those collaborating on the Qt port, http://trac.webkit.org/projects/webkit/wiki/QtWebKitContrib . While I would prefer it were hosted somewhere more official (eg, git.webkit.org alongside the git mirror of SVN), I have heard very few requests for this from outside the Qt developer community. It is something I am interested in doing in the future, but it takes planning and time that I can better spend elsewhere at present. As of now the patch sits in my git tree unsubmitted. Do you consider using git to be a requirement for you to contribute at all to WebKit? I'd like for it to be very easy to contribute a git tree with commit rights that was acceptable to the WebKit community would make it very easy to create branches for bug fixes and and as a work area. And it makes it easy to allow outstanding patches to track the head. I found the current process of submitting a patch having the head change breaking the patch resubmitting etc etc to be clumsy. If the patch was on a git tree that matched the head the branch then then applied. I feel the workflow for patch submission could be made a lot easier with this approach. Especially for complex issues. As far as small side projects like WebKit on OSX-GTK yes I consider it a requirement since Its something that makes sense to share with a broader community. I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. Back to the OSX-GTK example it should be branched from the working gtk/webkit repository that the gtk developers are using for work in progress but ? And even better to see the latest QT work from the same git repo. Did the QT guys implement something that could be used as a guide for the GTK port but not land it in the main tree ? For me having this sort of work area would be very useful. Hopefully others feel the same way. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pulling together on WebKit Mobile
On Jan 11, 2008 11:29 AM, Oliver Hunt [EMAIL PROTECTED] wrote:
On 11/01/2008, at 10:54 AM, Mike Emmel wrote:
I think this approach will allow us to keep the main repository and
tree clean and foster the churn that makes open source development fun
and exciting.
Contributing to webkit is not a fun and exciting process at the
moment.
There's already a git mirror of webkit trunk, and there's nothing
stopping you from having a public facing version of your own git
repository, but having a lax commit policy will just make life
complicated in the long term -- say you work for many months off
trunk, sure git will allow you to track trunk effectively, but when
it comes to final commit time it will make reviewing the patch much
harder as the entire patch will have to be reviewed at once...
As far as I was aware most large OSS projects had similar review
requirements, so i'm not entirely sure how the WebKit project differs
--Oliver
I have no problems with the commit requirements for the main tree.
This is more about a collaboration area.
It make more sense for WebKit.org to host a collaboration area.
And its a good way to allow developers to build up a work history to
ask for main commit rights.
Its a public work area and why would it effect eventual mainline
submissions if the code is crufty its rejected.
I have a patch for example to allow the gtk webkit to run on OSX. But
its a workaround for a bug in the cairo OSX port.
I'd like to be able to get the patch public and work with the cairo
OSX port maintainer to explain why I did what I did
and what he could do to cairo to fix OSX cairo.
Without a public work area this sort of problem is difficult to work on.
Assuming cairo is fixed then we would need to figure out version info
for the OSX port of GTK etc etc.
Being able to run the OSX port and the gtk port at the same time on
OSX is a nice feature.
Other open source ports such as QT might want a similar workspace for
similar problems.
As of now the patch sits in my git tree unsubmitted.
On Jan 11, 2008 10:38 AM, Alp Toker [EMAIL PROTECTED] wrote:
Hey guys,
There's a lot of mobile WebKit expertise in different
organisations and
from various individuals, but we haven't really done much to put
it all
in one place so far.
Would you be interested in sharing your findings, internal
documentation
and patches?
Some things I'd like to see:
* Build fixes for various lightweight toolchains integrated into
TOT
* Documentation of optional defines used in the WebCore loader and
elsewhere, like LOW_BANDWIDTH_DISPLAY and MOBILE
* Build instructions made public (Scratchbox, cross-compilation
etc.)
* Compiler flags
* Bug workarounds for different architectures and toolchains
I'd love to see what Naiem's team is finding and fixing in the GTK+
port, what tweaks the iPhone and Android engineers are using, and the
lightweight libc fixes from Peter, and Collabora's findings on the
Nokia
internet tablets all in one place.
When patches get merged, the WebKit team will help you maintain
them so
contributing code can help reduce the burden of maintaining ports and
build fixes out-of-tree.
I have some material I've built up privately in the last year on ARM
including benchmarks and patches that I'd like to start sharing too.
I do think we can get more done if we work together here. I've set
up a
wiki page -- please edit this with your findings and suggestions:
http://trac.webkit.org/projects/webkit/wiki/Mobile
You can register an account on the wiki here:
http://trac.macosforge.org/projects/webkit/register
___
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
diff --git a/WebKit/gtk/Api/webkitgtkpage.cpp b/WebKit/gtk/Api/webkitgtkpage.cpp
index dabc685..ba271da 100644
--- a/WebKit/gtk/Api/webkitgtkpage.cpp
+++ b/WebKit/gtk/Api/webkitgtkpage.cpp
@@ -47,7 +47,10 @@
#include PlatformKeyboardEvent.h
#include PlatformWheelEvent.h
#include SubstituteData.h
-
+#ifndef NDEBUG
+#include RenderTreeAsText.h
+#include gdk/gdkkeysyms.h
+#endif
using namespace WebKit;
using namespace WebCore;
@@ -75,22 +78,46 @@ static gboolean webkit_page_expose_event(GtkWidget* widget, GdkEventExpose* even
{
Frame* frame = core(getFrameFromPage(WEBKIT_PAGE(widget)));
GdkRectangle clip;
+cairo_t* cr;
gdk_region_get_clipbox(event-region, clip);
-cairo_t* cr = gdk_cairo_create(event-window);
+
+//quartz backend is broken
+#if CAIRO_HAS_QUARTZ_SURFACE
+WebKitPagePrivate* private_data = WEBKIT_PAGE_GET_PRIVATE(WEBKIT_PAGE(widget));
+cr = cairo_create(private_data-buffer);
+#else
+cr = gdk_cairo_create(event
Re: [webkit-dev] Pulling together on WebKit Mobile
I think one of the biggest stumbling blocks is the lack of a shared workspace for development. The patch approach is good for bugs but falls apart when multiple people from different organizations are working on new code. However I like the review process in place before code is included in the main tree. Git with its builtin ability to chain repositories easily makes a sensible choice for solving this problem. So I would like to propose that we have a public git repository set up that has fairly lax commit rules. This repo can track the main repository and we should bugs to reference git branches in the development repository. This will allow us to publicly stage development for inclusion into the main repo and make it easy to upgrade bug reports as the head changes. And most importantly it would move a lot of intermediate development out of private repositories and into a sharable public arena. Next it gives people a work history that can be reviewed when considering allowing main repo privileges. I think this approach will allow us to keep the main repository and tree clean and foster the churn that makes open source development fun and exciting. Contributing to webkit is not a fun and exciting process at the moment. On Jan 11, 2008 10:38 AM, Alp Toker [EMAIL PROTECTED] wrote: Hey guys, There's a lot of mobile WebKit expertise in different organisations and from various individuals, but we haven't really done much to put it all in one place so far. Would you be interested in sharing your findings, internal documentation and patches? Some things I'd like to see: * Build fixes for various lightweight toolchains integrated into TOT * Documentation of optional defines used in the WebCore loader and elsewhere, like LOW_BANDWIDTH_DISPLAY and MOBILE * Build instructions made public (Scratchbox, cross-compilation etc.) * Compiler flags * Bug workarounds for different architectures and toolchains I'd love to see what Naiem's team is finding and fixing in the GTK+ port, what tweaks the iPhone and Android engineers are using, and the lightweight libc fixes from Peter, and Collabora's findings on the Nokia internet tablets all in one place. When patches get merged, the WebKit team will help you maintain them so contributing code can help reduce the burden of maintaining ports and build fixes out-of-tree. I have some material I've built up privately in the last year on ARM including benchmarks and patches that I'd like to start sharing too. I do think we can get more done if we work together here. I've set up a wiki page -- please edit this with your findings and suggestions: http://trac.webkit.org/projects/webkit/wiki/Mobile You can register an account on the wiki here: http://trac.macosforge.org/projects/webkit/register ___ 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: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
On Jan 11, 2008 1:26 PM, Mark Rowe [EMAIL PROTECTED] wrote: On 12/01/2008, at 07:55, Mike Emmel wrote: I'd like for it to be very easy to contribute a git tree with commit rights that was acceptable to the WebKit community would make it very easy to create branches for bug fixes and and as a work area. And it makes it easy to allow outstanding patches to track the head. I found the current process of submitting a patch having the head change breaking the patch resubmitting etc etc to be clumsy. If the patch was on a git tree that matched the head the branch then then applied. I feel the workflow for patch submission could be made a lot easier with this approach. Especially for complex issues. The process you describe is vague and untested in the context of WebKit. The process we have now works reasonably well (well enough) for a large number of developers. There are some situations, none of which are particularly common, in which it is less efficient than it could be: two or more developers working together to implement a single feature is the one that springs to mind. Addressing these situations is clearly desirable, but I don't believe it's as simple as saying that git will magically fix things. It brings with it a new set of problems that most WebKit developers are not familiar with, and is much slower than SVN when interacting with an SVN repository, and currently has poor Windows support. Adopting git in a semi-official manner like you mention would require improving tool support and documentation such that any WebKit developer could deal with the new workflow if needed. In itself, this is not a small task. Why ? If they want to use it they can if they prefer svn then they should work to get commit rights. I prefer that a small number of developers have commit rights to the main svn like it is now. This is far less than the number of developers that can contribute to webkit and forcing them to work with patches is simply cumbersome. Webkit is a fairly sophisticated piece of code using git for daily development is trivial. I'd expect any developer who was collaborating on webkit would also be capable of learning git. Something as simple as this is sufficient. http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html Or maybe even this ? http://trac.webkit.org/projects/webkit/wiki/UsingGitWithWebKit I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. A minimal-effort solution could be to use http://repo.or.cz/ ,and create a wiki page to catalogue the locations of git repositories that other developers are using. A quick glance shows that Holger has a repository on repo.or.cz, and there appears to be a GNUstep port hosted there too. As best I can tell, this light-weight approach would fulfil your immediate need. I take it you did not look at that repository that carefully. http://repo.or.cz/w/webbrowser.git I tried this over a year ago and found that your incorrect in your assumptions about the suitability. Also having the GNUSstep port and it looks like a number of other WebKit related projects lost over on a generic server is not a good thing. A collaboration under webkit.org would bring these projects back under webkit.org where they belong. For me having this sort of work area would be very useful. I don't disagree that it would be useful. Part of the point of Git is that it is distributed in nature. This allows individuals to use git if they desire, and to experiment and come up with a workflow that fits with the existing WebKit tools and processes. Once tools have improved and a common idea of the right workflow to use has evolved, we should consider looking into adopting Git more officially. Why wait your now officially supporting git via svn tracking. A clone server that allows developer to create common working areas is a small step. I'd say you have already done most of the work. I'd suspect that members of the open source community would be willing to help with git issues if they arise. Also the tool is used for a lot of large open source projects most if not all of opendesktop.org is under git. And I'd say that X11 development alone is at least as complex as webkit not to mention linux kernel development. Given that you already support a git server and that large open source projects are successfully using git I think the argument your making is weak at best. Back to immediate needs. For the Gtk-OSX work it has one very useful feature it would be the only port that could be trivially switched between freetype rendering and ATSUI for fonts. Having a version of webkit that could be flipped between two standard font engines is very useful when looking at font related layout
[webkit-dev] Re: Moving away from qmake
Yes I rewrote the Curl code to use the new callback api's so you can
use select in the main thread.
Also the Pleyo people have done some work I've not fully integrated so
their work is worth looking at.
I ran into some issues and dropped back for the time being to a full
load on each call. Its a nice debugging feature anyway.
Also the latest curl uses asynchronous DNS resolution a huge win.
The biggest problem with Curl right now is that completion messages
still have to be polled for I was going to talk with the curl guys and
patch so you can register a callback.
Attached is my current curl the new stuff is turned off and I'm just loading.
Also this has some nice code in it esp for gtk that binds curl to the
gtk event loop.
http://www.gnomefiles.org/app.php/gCurl
If you read the code and think about the problem that the completion
messages get put on a queue inside curl
and you have to poll for them then you will see why I really want to
fix this in curl.
Also I seemed to be crashing inside curl sometimes with this turned on.
On Nov 12, 2007 12:11 AM, Alp Toker [EMAIL PROTECTED] wrote:
Mike Emmel wrote:
Here is my autoconf build files
They are for my current projects but I think they could readily be
cleaned up to b used with the standard build.
I found that having a single Makefile did not incur any performance
problems.
Mike, just had a look over this and it's looking like a good start. Thanks!
Was wondering, do you have any fixes to the Cairo graphics or CURL http
backends in your tree, or anything that might be useful to WebKit upstream?
If you provide your HTTP fixes, for example, I'll have more time to fix
the remaining Cairo SVG bugs, which you can then pull back into your
private branch, so everyone wins.
/*
* Copyright (C) 2004, 2006 Apple Computer, Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY APPLE COMPUTER, INC. ``AS IS'' AND ANY
* EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE COMPUTER, INC. OR
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
* OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#ifndef ResourceHandle_h
#define ResourceHandle_h
#include AuthenticationChallenge.h
#include HTTPHeaderMap.h
#include wtf/OwnPtr.h
#if PLATFORM(WIN)
typedef unsigned long DWORD;
typedef unsigned long DWORD_PTR;
typedef void* LPVOID;
typedef LPVOID HINTERNET;
typedef unsigned WPARAM;
typedef long LPARAM;
typedef struct HWND__* HWND;
typedef _W64 long LONG_PTR;
typedef LONG_PTR LRESULT;
#endif
#if PLATFORM(MAC)
#include wtf/RetainPtr.h
#ifdef __OBJC__
@class NSData;
@class NSError;
@class NSURLConnection;
@class WebCoreResourceHandleAsDelegate;
#else
class NSData;
class NSError;
class NSURLConnection;
class WebCoreResourceHandleAsDelegate;
typedef struct objc_object *id;
#endif
#endif
#if USE(CFNETWORK)
typedef struct _CFURLConnection* CFURLConnectionRef;
typedef int CFHTTPCookieStorageAcceptPolicy;
typedef struct OpaqueCFHTTPCookieStorage* CFHTTPCookieStorageRef;
#endif
#if USE(CURL)
typedef struct CURLMsg CURLMsg;
#endif
namespace WebCore {
class AuthenticationChallenge;
class Credential;
class FormData;
class Frame;
class KURL;
class ResourceError;
class ResourceHandleClient;
class ResourceHandleInternal;
class ResourceRequest;
class ResourceResponse;
class SharedBuffer;
class SubresourceLoader;
class SubresourceLoaderClient;
template typename T class Timer;
class ResourceHandle : public SharedResourceHandle {
private:
ResourceHandle(const ResourceRequest, ResourceHandleClient*, bool defersLoading, bool mightDownloadFromHandle);
public:
// FIXME: should not need the Frame
static PassRefPtrResourceHandle create(const ResourceRequest, ResourceHandleClient*, Frame*, bool defersLoading, bool mightDownloadFromHandle = false);
static void loadResourceSynchronously(const ResourceRequest, ResourceError, ResourceResponse, Vectorchar data);
static bool willLoadFromCache(ResourceRequest
Re: [webkit-dev] Moving away from qmake (aka. modularising JavaScriptCore)
I refactored all the Unicode handling to run behind a abstract interface. So no direct ICU calls. Its a lot of little patches all over the place and a thankless job. Its a lot of work so email me if your interested. I was also looking at repacling icu with glib/pango. Its not clear you get everything you need from glib so I believe you have to bring in pango which does more than you want. Pango itself needs to be split into text metrics and glyph drawing. On Nov 12, 2007 3:28 AM, Alp Toker [EMAIL PROTECTED] wrote: Mike Hommey wrote: On Mon, Nov 12, 2007 at 03:34:48AM +, Alp Toker [EMAIL PROTECTED] wrote: An unforeseen benefit of the new build system is that it is modular, rather than monolithic, and has no dependency on GLib/GTK+ or any other framework. This means that it will now be possible to use JavaScriptCore as a standalone scripting engine independently of WebKit. Except that for the moment, JavaScriptCore is a little bit different if built for the Qt port or the Gtk+ port, so it couldn't be shared between both, which is pretty sad, actually. I can go into the issues here a bit further, though it doesn't directly relate to the choice of build system. When it comes to platform-specific code in JavaScriptCore, the most obvious issue is the set of platform/language bindings. Luckily the fix for this is pretty obvious, and I've filed a bug: http://bugs.webkit.org/show_bug.cgi?id=15931 Eliminate Instance::createBindingForLanguageInstance() The other instance of platform specific code that I can see is Qt's use of Unicode functionality, while other ports tend to use ICU. I've actually been planning to port the Unicode abstraction to use GLib, since ICU is a very heavy dependency for non-desktop systems. (There is potential to shave up to 10M off the distribution size of the GTK+ port for mobile devices here.) This is however a thankless job that nobody else seems to be interested in doing and I've put it off till now: http://bugs.webkit.org/show_bug.cgi?id=15914 [GTK] Implement Unicode functionality using GLib So this would actually be a step away from re-usability as a shared library but a step towards a lower mobile memory footprint. There are a few other bits of Qt-specific code such as that in DateMath, but these do not seem significant, and if the other two issues were fixed I imagine the Qt developers would be happy to compromise on those. As long as ports work to avoid ICU for Unicode functionality, I don't think we're going to get around to genuinely sharing JavaScriptCore, and to be honest, I don't see this being a real problem. How many people will run Konqueror and Epiphany at the same time (for reasons other than testing)? Will those people who do regularly use both Konqueror and Epiphany miss the 1-2M that could have been shared given that the complete applications are taking at least 10M each? So while I think there is the possibility of having a standalone JavaScriptCore edition embedding into applications, I do not think there is any immediate hope of having a single JavaScriptCore library shared between ports. Lots of effort for minimal gain. The real benefit in having a standalone build profile for JavaScriptCore in my use case was that it made it far more practical to hack on the new CLR/JavaScript binding. This would have been really unpleasant if I had to build and link the whole of WebKit each time I made a change. I think that lowering the barrier for new JS bindings alone is a good cause for having a modular JavaScriptCore build target, but maybe I'm the only one developing new JS bindings right now? As for switching away from qmake, I'm all for it, though I have no problem having to use qmake for the Gtk+ port, since I'm already building both Qt and Gtk+ ports in one pass for the Debian packages. I'll only add this: it would be nice to avoid linking to indirectly used libraries where possible, though it may be challenging. (I'm using -Wl,--as-needed for that matter) Mike You and I have learnt how to deal with qmake, but I've recently discovered that casual contributors and potential adopters in GNOME are taking one look at the qmake build system and turning around. It also seems to be antagonising people who use source-based distributions like Gentoo and who would otherwise never have a reason to take an hour out of their lives building the whole of Qt. ___ 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] Gdklauncher Craches
On 2/22/07, Krzysztof Kowalczyk [EMAIL PROTECTED] wrote: I did some work in http://bugs.webkit.org/show_bug.cgi?id=12783 based on one of your patches in bugzilla, but it doesn't port all of those changes. The only malloc() related fix I can recall is that url string life-time wasn't guaranteed to last as long as curl request which could have caused problems. Yep thats the one. And generally it crashed on the second request similar to the traces I saw. -- kjk On 2/22/07, Mike Emmel [EMAIL PROTECTED] wrote: On 2/22/07, Krzysztof Kowalczyk [EMAIL PROTECTED] wrote: This should work. Did you get my latest changes in ? I fixed a few bugs some stuff with malloc's etc that was causing crashes like what your seeing when a second resource was loaded. So their were bugs in the code that caused crashes on the second load that where fixed. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Need Help for GTK Port
On 2/13/07, Krzysztof Kowalczyk [EMAIL PROTECTED] wrote: On 2/13/07, atul [EMAIL PROTECTED] wrote: We (me shri) both have a worked on GTK+Webcore (http://gtk-webcore.sourceforge.net/ ) for sometime as we are new to the current WEBKIT ToT we need someone to guide/help us for understand contribute to the latest Webkit For GDK port. This mail is an effort to start a dialog with those others who are interested to work in the same direction so that we can all coordinate our resources rather than working at crosspurposes. I'm currently working on gdk port with the ultimate goal of making it a usable browser on gtk and an easily embeddable browser gadget (i.e. gtkhtml replacement). My strategy is simple: fix all the issues that annoy me while using it as a browser and there's still plenty of those issues to go around. If you run gdklauncher for a while you'll see that: * there are drawing issues due to GraphicsContextCairo.cpp not being finished * mouse text selection doesn't work (either a drawing issue or mouse events not being hooked up properly) * scrollbars are not there * pop-up menus are not there * some widgets are not being drawn too well * it does crash often * networking is very basic and doesn't run in a separate thread like it should * plenty of FIXME: UNIMPLEMENTED calls * many javascript tests fail * layout tests cannot be run at all because there is no dumprendertree for gdk * gdk version is not hooked up to build/test infrastructure the way mac/qt is (i.e. build-webkit, run-javascriptcore-tests etc. scripts in WebKitTools\Scripts don't understand gdk build) * gdklauncher could be vastly improved If you want to contribute, submit a patch for any of those issues or find an issue that bothers you the most and fix that. Bugs with patches exist for a lot of these issues. In retrospect if I had been able to do a branch for the experimental work and a stable port I would have been able to work on both. If someone sends me a email I have a tarball of my last bakefile based webkit with svg support scrollbars numerous fixes to the networking cairo etc etc. In any case good luck ! -- kjk ___ 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] Definitive build system
On 2/12/07, Krzysztof Kowalczyk [EMAIL PROTECTED] wrote: I'm trying to do some contributions in the Gdk port. First all, I'm trying to fix the build system for gdk. It uses BakeFiles, but it seems that this option has been abandoned. That's not entirely true. The svn trunk now builds with bakefiles so build system should not be a barrier for people who just want to contribute to gtk port. I'll try to keep the build working. Having said that, I would welcome a better build and extending CMake build to support gtk would be great. Having said that, I just tried to build qt version on linux with cmake (currently that's the only one that uses cmake) and I failed so it seems like cmake build isn't actively maintained either (maybe it works well on mac, that's one thing I couldn't verify). It generally works for the QT build. For my own needs of working on gtk port I've created a simple makefile generation script (http://bugs.webkit.org/show_bug.cgi?id=11308, latest version is at http://kjk.googlecode.com/svn/trunk/webcore/gen-webkit-gdk-makefile.py) which I think, is a better solution than both bakefile and cmake (http://lists.macosforge.org/pipermail/webkit-dev/2006-October/001364.html). I was not happy with cmake to be honest its poorly documented and it seems to have a business model where documentation is sold to support the work. Not exactly good for encouraging adoption. I'm not interested in having to purchase a book for a build tool. I'm very interested in your script and downloaded it. Long term I did not see sticking to Cmake as viable and I want to create a build system based on javascript/xml based on Webkit :) When I get the chance I plan to convert your python program to javascript and persue this approach your work is enough to provide me the foundation I need to do a javascript based build tool. THANKS ! -- kjk ___ 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] Compiling webkit on windows
Looks like your missing the realpath program also. On 1/17/07, Krzysztof Kowalczyk [EMAIL PROTECTED] wrote: Currently it probably won't compile anyway due to recent changes, but... First, make sure that you do svn co under cygwin shell in order to get files with unix-style line-ending - last time I've tried and didn't do it, perl scripts wouldn't work. It's also possible you're not running from Cygwin or it's misconfigured. Also, I've never tried the script, I always built using WebKitTools\Spinneret\Spinneret.sln -- kjk On 1/17/07, Amit Manocha [EMAIL PROTECTED] wrote: Hi all, I'm trying to compile webkit on windows. But when I run build-webkit script mentioned at http://trac.webkit.org/projects/webkit/wiki/BuildingOnWindows, I get following errors: START Performing Pre-Build Event... realpath: No such file or directory cygpath: cannot create short name of build-generated-files.sh: line 11: export: `SRCROOT': not a valid identifier mkdir: cannot create directory `\r\r\r': No such file or directory build-generated-files.sh: line 18: cd: /DerivedSources/WebCore: No such file or directory build-generated-files.sh: line 20: : command not found make: /DerivedSources.make: No such file or directory make: *** No rule to make target `/DerivedSources.make'. Stop. build-generated-files.sh: line 24: exit: 1: numeric argument required Project : error PRJ0019: A tool returned an error code from Performing Pre-Buil d Event... Build log was saved at file://c:\WebKitBuild\WebCore.intermediate\Release\WebCo re.intermediate\BuildLog.htm WebCore - 1 error(s), 0 warning(s) -- Build started: Project: WebKit, Configuration: Release Win32 -- Compiling... WebView.cpp c:\webkit\webkit\com\WebFrame.h(160) : error C2259: 'WebFrameLoaderClient' : can not instantiate abstract class due to following members: END Any clues as to what is happening here/ Thanks - Amit Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
