Re: [webkit-dev] It's time to remove the Haiku port
On Fri, Nov 4, 2011 at 12:33 PM, Peter Kasting pkast...@google.com wrote: It seems like either you should be a private fork/port, or a public upstreamed one, but not both. If you want to live in the upstream tree, I think most of your development work should land quickly in public. If you want to work in a separate repository without landing changes back upstream quickly*, I think it's better to stay private until the point at which that changes. Yes, this was definitely the hard lesson we learned, and as I'll describe below we are going to move to the latter set up for now. *At most I don't think your private repo should be more than a couple weeks off the public repo. Most definitely, I will strive to do that from now on :) Based on our experience with the Chromium port I think it would be far easier on your group to be public and do development directly in the public tree. That is definitely our end goal. But it seems at this point the Haiku port is too much of a burden to the WebKit community. I talked to Adam Barth in IRC last night and we came to an agreement that it is best *for now* if Haiku maintains a Git repo cloned off the WebKit repo with a branch containing our port. When our port is further along with layout tests working, most of the platform files implemented, a Buildbot, and maintainers with the time and skill to keep our port up-to-date, we can explore putting our code back in the public WebKit repo. This puts the burden on maintaining our port where it belongs: with our developers. It won't always be fun doing it this way, but I think using Git will help (as compared to Subversion which is where our current copy of WebKit is, and now almost 42,000 changesets behind.) Actually regarding the 42,000 changesets: these have all come in the last year and a half (), and are almost as many changesets as ever came before in the current WebKit repo. This is exponential growth! How is a small port possibly suppose to stay up-to-date under those conditions? Of course this just means that WebKit is a vibrant project and you cannot be faulted for that, but I think with this onslaught of changes it may be time to reconsider past methods of keeping ports up-to-date. Adam tells me Google has two full-time engineers keeping the Chromium port up-to-date. I think there is room for improvement in this area. Actually I have various thoughts about WebKit platform code which I'm sure many of you would agree with, but I can express those in another email. The short version is WebCore should have no platform code or PLATFORM macros and all platform code should plug in using clean abstract classes and delegates. Maybe this is an area where I or other Haiku developers can give back to the WebKit community. I just hope that when that time comes (and maybe sooner rather than later) the WebKit community will let us back in and quickly apply our patches. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting w3c ref tests and changing our convention
On Fri, Nov 4, 2011 at 4:47 PM, Dirk Pranke dpra...@chromium.org wrote: Separately, if we are throwing around numbers in the range of 100K for tests to run, we should consider when we actually want to run them - i.e., what will the cycle time be if we run them on every change, etc.? But that can be dealt with when we get there. I would also like to throw out the idea of pulling the layout tests out into their own repo, maybe even per platform. Currently the huge number of layout tests in WebKit make many git operations unbearably slow, such as git status, which basically does a stat() on every file in a repo when the plain git status is used. Even on Linux where stat() is mega-fast it takes many seconds to show git status even on a clean checkout (at least on my laptop, which admittedly isn't the fastest.) It is worse on other platforms with a slower stat(). But I expect there might be a lot of pushback on such an idea, especially just to make one tool run faster. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] It's time to remove the Haiku port
On Fri, Nov 4, 2011 at 5:40 PM, Dirk Pranke dpra...@chromium.org wrote: Hopefully we will start writing more and more tests as reftests, to address the first category. Moving to one of the existing cross-port build mechanisms like GYP or CMake would help. Yeah I will attempt to make use of GYP myself for the Haiku port, except I'll need to add a new backend to generate Jamfiles, since Jam is the preferred Haiku build system. Changes to core platform code in the third category are hopefully pretty rare, and I think you're just out of luck for the fourth category, but hopefully they're done in a modular manner and at least easy to enable/disable for a while. I think the more feedback we can get on what sorts of things you do have to do to keep up to date, the better things will get. For additions to platform, I think a harmless default implementation should suffice. Having to add an empty method to a port just to satisfy the compiler seems like a lot of trouble. I can't find a good example at the moment, so maybe it really isn't an issue. Looking over some of the changes made to the Haiku port by non-Haiku people just shows a lot of renames and changing of method arguments and return values in the platform directory. This tells me that platform really isn't any sort of API (and yes I know it isn't meant to be) but maybe it should be? I personally would like to see WebCore evolve into being as self-contained as possible, with clear APIs for a platform to attach to. Maybe the new Platform directory will be the start of this, and if so, I applaud the effort. Right now the platform coupling is pretty bad. I hope one day #if PLATFORM(X) doesn't exist in WebCore, at least not where such code adds a class member or methods to core platform classes. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Putting layout tests on a separate repository (was Supporting w3c ref tests and changing our convention)
On Fri, Nov 4, 2011 at 5:58 PM, Ryosuke Niwa rn...@webkit.org wrote: Indeed, I'm against this idea. You make good points. There may be solutions to your objections, but they might not be much better than having a slow git status right now. Do other people who use WebKit with Git see this problem? If so, what do you do to stay productive? If not then I'll just be sure to only develop WebKit on a faster machine (which I do have and look forward to testing soon.) Sorry for hijacking the other thread, thanks for changing the subject. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] It's time to remove the Haiku port
On Fri, Nov 4, 2011 at 6:12 PM, David Levin le...@chromium.org wrote: I suspect the pain hasn't been big enough so far for any person/organization to decide to address this. Well it may not really be worth the trouble, I just always found the #ifdefs in WebCore/platform to be a little smelly. But they work. You do sound enthusiastic about it though, and I suspect there would be people willing to review these changes as long as they didn't slow down WebKit or make it harder to maintain. That is good to know. There may be a time when I do this work, but I have bigger fish to fry at the moment with updating the Haiku port in our own repo, and my open source time is fairly limited currently (in case it isn't obvious since it took a month and a half to notice our port was removed from WebKit.) -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] It's time to remove the Haiku port
On Fri, Nov 4, 2011 at 6:37 PM, David Levin le...@chromium.org wrote: Exactly :) What are you saying, the rest of the WebKit community doesn't want to spend weeks perfecting the architecture to make my life easier? :) When the need comes, it'll be done. Which may be never, but that's life. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] It's time to remove the Haiku port
Hello all, Sorry for the delay in response to this, I don't follow this mailing list closely, obviously. I just happened to search for Haiku, and was not too shocked to see this message. Given that the Haiku port has now been removed (in fact, Adam did it right on September 25 when this message was sent), clearly I'm way too late. On Sun, Sep 25, 2011 at 3:34 AM, Adam Barth aba...@webkit.org wrote: In the past year, http://trac.webkit.org/log/trunk/Source/WebKit/haiku and http://trac.webkit.org/log/trunk/Source/WebCore/platform/haiku have been modified 70 times by non-Haiku contributors and zero times by Haiku contributors. I am so sorry that this has happened! I was the original porter for the Haiku WebKit port and have continued to work on it recently. Unfortunately the Haiku community is a small group of people and most of the developers spend their time working on Haiku itself. We really appreciate the efforts to keep the Haiku port updated as things have changed in WebKit. The primary problem with our port right now is some of the developers made the choice (which I objected to) to make our own Subversion repo containing the WebKit code to make it easier (in their eyes) to develop the port. Once Stephan no longer was working on it, this clone became very out of date. Making things worse was the great code re-organizing which occurred a while ago here at WebKit (the move to Source, etc.) As part of our effort to reduce complexity in WebKit, I believe it is now time to remove the Haiku port. So as I mentioned this has already been done. Haiku itself is far from dead. We aren't a huge project but we have many active developers and multiple commits a day. We also still plan to make use of WebKit. I guess we are at a crossroads. I would much prefer not to have to maintain our own custom repo of WebKit. But it seems we have become more of a burden than a help on WebKit, but I suppose that is the case for most ports outside of the popular platforms. Where can we go from here? What does the WebKit project need to see from the Haiku maintainers to have us be a supported port again? Again I'm sorry for the lack of activity over the years but as you can imagine it is hard to work on an entire platform port for WebKit in one's spare time. We had to hire Stephan as a contractor to get all the work we got from him, and probably from your perspective that was nothing. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] It's time to remove the Haiku port
On Mon, Sep 26, 2011 at 1:34 AM, Eric Seidel e...@webkit.org wrote: I think any time the larger community is spending more effort than the port authors on a particular port we should be wary about keeping the port. Yes this is totally reasonable. Certainly that indicates that either our base-costs for having a port are too high (our platform abstraction is poor, etc.) or that the port maintainers aren't active enough in the project. I think it is a little of both. The WebKit platform abstraction could definitely use improvement, as I'm sure many of you know. Plus WebKit changes REALLY, REALLY fast. For a project like Haiku which is strictly open source and volunteer developer driven, it is hard to keep a port up-to-date. The fact that so many changes were needed in our files without us making improvement or changes in our actual port may say something. Personally I would have told you not to update our files and just let them be broken if we didn't update them. The fact that so much work is needed from developers besides the port developers to maintain a more slowly developing port indicates a problem with WebKit. Well maybe not a problem, but there may need to be a policy of letting smaller ports maintain their own files. On another note, the reply-to on this mailing list is just broken :/ -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] coding style and comments
On Sunday, January 30, 2011, Maciej Stachowiak m...@apple.com wrote: I'll go the other way and point out some example of comments that I think are poor. This file is terribly commented, I agree, but cherry picking a really bad file isn't the best way to make a point IMO. Maybe the solution here is better documentation outside the source code. I hope some of the more experienced WebKit developers can agree that there are parts of the code that are harder for new developers to dig into. Some high-level docs that are kept updated might be nice. Of course the key here is keeping them updated, and if it is hard to keep source code comments up to date I don't know how much hope there is for outside docs. Of course this applies to any project and is by no means just a flaw in this project. At least if the comments are in the code there is hope that a reviewer would catch when comments get out of date. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blog post(s) about layout tests
On Tue, Jan 25, 2011 at 9:24 PM, Mihai Parparita mih...@chromium.org wrote: The post is link-heavy (generally into Trac, and Bugzilla), I'm hoping that would also encourage exploration of the code/site by people interested in contributing. As a WebKit porter who is actually not very familiar with the Layout Tests I found reading these posts pretty useful and informative (it also reminds me I really need to get the Layout Tests going in the Haiku port.) I do think that maybe it is a little too link heavy though. So many links can get a little overwhelming and distracting when reading an article like that. Though they are probably useful to illustrate your points so I think it would be fine to leave them. I also tend to read like an editor and I did not see anything glaringly wrong spelling or grammar-wise. I don't know the process for getting blog posts on blog.webkit.org, but I'll at least give the content of these posts a +1. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] coding style and comments
On Thu, Jan 27, 2011 at 7:27 PM, Simon Fraser simon.fra...@apple.com wrote: I think we have a distinct lack of comments that help novices to understand the code. I feel that we almost have a privileged few mentality in some code; if you can't figure it out by reading the code, then you shouldn't be messing with it. As a WebKit porter who has not yet seriously dug into the WebCore code much beyond platform I tend to get the same feeling as Simon. While a web engine is not a trivial piece of code some parts of WebKit are much more obtuse to non-experts and could benefit from a little more commenting. When trying to debug problems in a port it is very easy to get lost and confused when in WebCore code. Now maybe that is just the nature of the beast and it takes time to grok, but surely there could be some small improvements made with a few comments. So I encourage more comments (and use them fairly copiously, for anything non-obvious, in my own code). I'd particularly encourage comments before each class definition that say what the class is for, what its lifetime is, what the ownership model is, and how many are usually instantiated. +1000! When doing my port for Haiku I was obviously mostly dealing with platform classes and I wrote comments in my build file about what I thought each platform file was for (some are not so obvious, I still don't know why there is both a Pasteboard and a Clipboard.) I think it gets much worse deeper inside WebCore. So I think it could really help new contributors (or anyone really) to have some high-level comments for classes just like Simon says above. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
On Wed, Jan 26, 2011 at 1:52 PM, Fabrizio Machado fabrizio.machado...@gmail.com wrote: This would rely on a spelling engine but, as qt has no spell checker, Hunspell integration to WebCore seems appealing. I was headed in this direction when I found this thread and I wonder if you are still pursuing this. Can you tell me if it is a worthwhile pursuit, or if you had problems? I'm interested in continuing, but give me a heads up if you were blocked for some reason. For what it is worth, the approach outlined by Hajime would also be useful for the Haiku port I am working on. I was already considering porting Hunspell to Haiku and making use of it in the Haiku port, but if multiple ports could benefit all the better. It seems like the TextCheckerClient approach is reasonable if it is architected in the same way as EditorClient and friends. The Hunspell based TextChecker could live in WebCore and link with Hunspell and would only be compiled and used by ports which need it. There would still need to be a TextCheckerClient in WebCoreSupport in WebKit to call to the TextCheckerHunspell or whatever in WebCore. Maybe this still isn't the right architecture but I don't think it is impossible to implement this in a way which matches other uses in WebKit. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
On Wed, Jan 26, 2011 at 6:24 PM, Hajime Morita morr...@google.com wrote: Fabrizio, Ryan, thank you for your interest! Although I'm suspending the work at this time, your interest gives me a good reason to restart ;-) Good to hear! I think having 3 or 4 possible ports being able to use this is enough reason for it to be implemented. Let's just be sure the design you intend to implement fits within the WebCore/WebKit design so it can be included once you are done. I'll CC you in bug(s) and post some status there within weeks. Sounds good. I have plenty of other things to keep me busy in the meantime on the Haiku WebKit port as well as our browser project. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On the greeness of the GTK+ bot
On Mon, Nov 16, 2009 at 12:47 PM, Dimitri Glazkov dglaz...@chromium.org wrote: This is a huge issue with the Chromium port as well. We spend quite a bit of effort tracking down failing tests, only to discover that the failure is due to one-port baselines or new functionality added to DRT. I wonder if the approach we have today in regards to tests is not sustainable with multiple vibrant ports, each spending way to much time catching up. This is also a big concern for our tiny group working on the Haiku port. While we are not nearly at the stage of GTK, Qt or Chromium, we hope to get there one day, and it would be frustrating to have our tests broken or our (future) build bot constantly red due to other port's changes. Given how many people are having pain with this, it seems some change might be warranted. Unfortunately I don't feel qualified enough to suggest anything. But I think there is enough cumulative experience on all sides to come up with a good solution. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Wed, Aug 26, 2009 at 12:00 PM, Simon Frasersimon.fra...@apple.com wrote: Did you file the two bugs necessary here (hearing static, and non-seamless looping)? That static at least is intended (the audio file is just static.) -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Qtish API for JavaScriptCore
On Wed, Aug 26, 2009 at 5:24 PM, Darin Adlerda...@apple.com wrote: Yes, I think it’s great to build the Qtish API on top of the C API. If this can’t be done, lets make the minor refinements needed to make that possible. This will give the folks working on improvements to the JavaScriptCore engine the maximum flexibility moving forward and should not prove a significant disadvantage for the folks making this for Qt. Plus this will help ensure the C API is flexible enough to build on top of, so that those of us on other platforms can also build on top of it in the future. In my case a Haiku JavaScript API (probably highly inspired by the Qt one.) -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to deal with localized strings
On Mon, Aug 24, 2009 at 2:07 PM, Michelangelo De Simonemicde...@gmail.com wrote: In order to accomplish this in HTMLFormControlElement::validationMessage() I should return the localized string obtained from the embedder and this is the trouble I went into: how such a thing is usually done in WebKit? WebCore/platform/LocalizedStrings.h seems appropriate :) -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security advice for linux browsers based on WebKit
On Mon, Aug 24, 2009 at 7:16 PM, Maciej Stachowiakm...@apple.com wrote: I think it's probably possible to change the default on all platforms other than Mac. I do not believe the compatibility issues we're concerned about for Mac affect any other port. I think this would be a good choice. I most definitely agree here. If there is no need to worry about compatibility on the other platforms I think it is a good idea to close down such a potential security threat by default. Platform porters may not realize there are such risky settings and could release insecure software as a result. Though they deserve some responsibility in that, it is also smart to try to prevent such problems at the WebKit level. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Data Loss
On Fri, Aug 21, 2009 at 1:54 AM, Peter Kastingpkast...@google.com wrote: but patches that were merely attached to bugs have vanished. Hopefully you still have local copies and can re-attach them! This sort of thing tends to put a kibosh on some people's workflow of using bugzilla as a source control tool (as recently read in #webkit.) Well at least abarth does this. Crap happens. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GDOM patch spam
All I know is that Eric and the other hard-working WebKit reviewers and committers have patiently steered my student Maxime and myself into submitting good patches for the Haiku port, which they have promptly committed. All for a platform which has a much, much, much smaller user base than the GDOM bindings probably have. So it is silly to think there is any discrimination toward GDOM. If you are not following the clearly laid out guidelines for submitting code to the project you should not expect code to be accepted. Also I think a little patience and respect is due given how hard Eric and everyone else on the project works to review patches and commit code (I think it is safe to say they are INUNDATED just about every day.) In the same way that you expect people from WebKit to respect contributors, you should respect all the work they have done to make something so nice for the rest of us to benefit from. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Calling All Reviewers
On Thu, Aug 6, 2009 at 10:57 PM, Eric Seidele...@webkit.org wrote: We're down to 60 now. 84 when I started my crusade (shortly before sending the previous mail). https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=review%3F A long way to go yet! I think I'm tuckered out for the evening. If there is anything Maxime and I can do to help with the Haiku patches, let me know. I believe all the remaining patches have been run through the cpplint script so there should not be any code violations. The GSoC is ending within 10 days or so and it would be nice if these patches could be committed by then. I don't have time tonight but I'll check the remaining patches as best I can tomorrow to be sure they look OK. I know you guys are busy and probably inundated with patches so I don't want all the various Haiku patches to be a burden. It just takes a lot of code to add a new platform to WebKit, as you all probably know. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] status update: webkit gobject bindings [svn r46395]
On Sun, Jul 26, 2009 at 4:24 PM, Maciej Stachowiakm...@apple.com wrote: Luke, you need to stop sending long, rambling emails to the list. For what it is worth, I completely agree with Maciej's statement. I am not (yet) a committer and have no association with Apple or any of the other WebKit big guns so I would hope my opinion would not be seen as biased. Therefore I hope Luke can listen when I say I do not find long rambling emails from anyone very useful or enlightening. I imagine I am not alone. Also as one of the main developers of the Haiku port of WebKit I have found the project open and helpful to a small and somewhat obscure port. This has inspired me to want to contribute back to WebKit in general areas that can help everyone and not just my port. I find such a tit-for-tat approach one of the great benefits of open source development. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
On Mon, Jul 13, 2009 at 4:56 PM, Maciej Stachowiakm...@apple.com wrote: One belated comment on this topic. It would be neat if some port agreed to be the guinea pig to see if gyp could plausibly work for more than Google's ports. The Wx port probably has the lowest resources of any complete port in the tree, so they might not be the best choice of experimental subject, particularly if for them the process required writing a new gyp back end and if they are not yet entirely comfortable going the gyp route. I would need to discuss it with my student, but what about the brand new Haiku port being the gyp guinea pig? For those who don't know, I am mentoring a student in the Google Summer of Code for the Haiku operating system (http://www.haiku-os.org) and we are working on a native Haiku web browser with WebKit as the rendering engine. I don't know if our port is any better of a choice than the Wx port, since the resources are also small (just two of us for now) and we aren't even in the WebKit tree yet, but I think we still might be a good choice because: 1) We obviously don't yet have a production browser using our port so breakage isn't an issue. Plus only my student (Maxime Simon) and I are working on it. 2) I have decent experience with build systems and think I could handle working with gyp and writing a new back end. 3) Haiku generally uses Jam for building and we would like our port to do the same. Rather than adding Yet Another Build System to WebKit, we could use gyp and write a Jam backend for it. This can therefore serve as a test of gyp for another platform as well as for another backend. I would rather not have to maintain a Jamfile for WebKit if I can avoid it, and I certainly don't want to burden the other WebKit developers with having to maintain it for what is now (and may forever be) a tiny port. Though we certainly hope Haiku's popularity increases in the future (it hasn't even had a first release anyhow, so there is plenty of room to grow.) Anyhow, I'd be interested in hearing what other people think. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] New WebKit port to Haiku
Hello all, As part of the Google Summer of Code I am mentoring a student named Maxime Simon, who is resurrecting and continuing my port of WebKit to the Haiku operating system (http://haiku-os.org). I originally did this port in 2007, but stopped working on it until now. Obviously I never had it committed to the WebKit tree. As part of the GSoC project Maxime has recently updated my port and got it building with the latest WebKit code (surprisingly it did not take too long.) He created a bug (https://bugs.webkit.org/show_bug.cgi?id=26620) to add this code to the WebKit repo. In his comments on that bug Eric Seidel asked that an email be sent here introducing ourselves. I figured I would start and let Maxime respond to this email if he wants. To assuage Eric's concerns, Haiku will not be disappearing anytime soon. The project has existed since 2001 and moves forward everyday (though progress can be slow since we have a small team and a big project: the recreation and continuation of the BeOS.) A huge part of any modern operating system is a good web browser and while Haiku has a port of Firefox, it does not have the speed and feel we want. Since WebKit is fast, elegant and easy to port it was the ideal choice for the engine behind our new web browser. So it would be really great if our port could become an official one in the WebKit tree :) I sure hope that Maxime will stick around after the Summer of Code, but in case he does not I will be sure to keep the Haiku WebKit port updated. I think the people who ported Firefox to BeOS and then Haiku will also want to help on this project. Since I plan to use Haiku as my main OS and the WebKit browser as my main browser I will truly be eating my own dogfood and it will be in my interest to keep it updated and working well :) -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Get SquirrelFish for Webkit in linux
On Sun, Jun 8, 2008 at 9:44 PM, ying lcs [EMAIL PROTECTED] wrote:. But when I try './Programs/GtkLauncher' and load 'http://mail.gmail.com', nothing get loaded. But when I do 'http://www.cnn.com', it works. As far as I can tell there is no such site as mail.gmail.com. Try just plain old gmail.com or mail.google.com. Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Has anybody ported WebKit to a platform other than Windows or Unix?
On Mon, Jun 2, 2008 at 4:27 AM, Paul Pedriana [EMAIL PROTECTED] wrote: I'm wondering if anybody has successfully ported WebKit to a platform other than Windows or Unix. I ported it to Haiku (http://www.haiku-os.org), which is essentially a clone of BeOS. There is still some work to do, but the basics of it are there. I did this work by myself in a few months while having a full-time job (not at all related) and in general living my life. On the other hand a team of people has been working on Firefox for BeOS for years and it still has problems. I've heard many stories about how the Mozilla code is very complicated because of the XPCOM and various other choices they have made over the years. I think WebKit is a much cleaner code-base to port to new platforms. It is also much faster, which is one big reason I chose it as the engine for a Haiku web browser. BeOS is very fast, Haiku will be too, and we want our applications fast too. There is no doubt that seeing all the platform files needed for WebKit can be daunting, but a browser is complicated and needs quite a bit of functionality from the platform to do its job, so it makes sense. I think you would be even more daunted to see what is needed to get Mozilla going. Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Idea for comments: Using Git to manage some WebKit platform ports
Hello all, I have recently begun to use Git in earnest and after reading various things and starting to understand how it works I had an idea: I could manage my Haiku WebKit port using Git without ever having my code in the real WebKit SVN repo. The basic idea would be I would clone the current WebKit Git repo, create a branch for my Haiku port, and then publish that branch for other Haiku developers to use. This branch would never go back into the main WebKit repo. Why would I want to do this? Here is what I am thinking: - The main WebKit repo would have one less bit of platform code that everyone else has to download, even though only a tiny percentage would care to use it (as much as I like Haiku at this point it is a very small platform.) - It would be almost impossible for other people in the WebKit community to break the Haiku WebKit build since I (or other Haiku developers) would control pulling new changes from the main repo and could ensure we fixed problems before publishing those changes to our repo. - It alleviates other WebKit maintainers from having to be concerned about breaking such a tiny port like ours because of the above point. - I could freely change my platform code without having to go through the strict WebKit review and submit process (which is good in general but maybe too heavyweight for my small port.) I might also suggest that other smaller ports (*cough* Robert, *cough*, AROS) could use this too, but obviously that is up to them. The WebKit site can provide links to these platform specific Git repos so people can make use of them if they wish. I would be curious what the WebKit community thinks about this idea. I know the Qt people have been doing this already to some extent with their Git repo and I recall this being perceived badly by some. One point I would like to make is I would intend to submit any purely WebKit-related fixes back to the main repo (which Git makes considerably easier than SVN.) So there would not be an issue of potentially good stuff hiding in my repo (part of what the Qt guys got flak for I believe.) Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Idea for comments: Using Git to manage some WebKit platform ports
Daniel only responded to me personally (the strange way this list works I guess), so hopefully he won't mind a public response: On Fri, Apr 11, 2008 at 12:21 PM, Daniel Zucker [EMAIL PROTECTED] wrote: Perhaps one possible negative to this is that there would now be definite resource requirements to host a port. Specifically, a new port would need to both host a git server (requiring hardware and bandwidth), This is a reasonable point, but fortunately there are places like http://gitorious.org/ and http://github.com that can host open source Git repos for free. and also actively migrate patches to this port as they are developed. True, but *someone* would have to do that work either way, and it is probably a better use of resources to have the person with a real stake in and understanding of the port doing the work rather than some of the other WebKit developers who have deeper concerns in the main codebase and the larger ports. In the case of ports integrated directly into the main WebKit trunk, neither of these are required: the port code would be hosted at webkit.org, and no one needs to actively port patches over since they are maintained in the main webkit trunk. See above point about maintaining ports. Personally, I think the increased resource requirements in the case where new ports all have their own git repository would make it difficult for people without a lot of time or money to do new ports. Time will be required either way, believe you me ;) Money shouldn't be a big problem because of the above services. Plus if a port really becomes that popular it could always be merged back into the main repo. Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing ICU dependancy from WebKit?
On Jan 25, 2008 3:43 AM, Robert Norris [EMAIL PROTECTED] wrote: I managed to cross-compile ICU based on Ryan Leavengood's description of how he got it to work. My steps are for compiling on Linux for AROS, but you might be able to work something out based on them: Sorry I'm just now reading this message, but as Robert says I figured out how to cross-compile ICU. This post describes what I did: http://www.haiku-os.org/blog/leavengood/2007-09-04/javascriptcore_runs_on_haiku_mostly Robert's file showing the commands he did looks like a much more structured way to do it than what I did ;) Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Re: ProjectVision
On Nov 23, 2007 12:31 PM, Alp Toker [EMAIL PROTECTED] wrote: http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diffversion=1 Please revert this change until the topic has been discussed on the mailing list or bug tracker. You can't just make up a project vision like that. For what it is worth I think most of what was laid out in the above document is good. The project and web-site has a definite Apple/Safari focus, and this will become a problem as the other platforms mature. As one of the lesser platforms (Haiku) I think it would be good to have the project more platform independent in its process and web-site as much as the code. It would be great if the Qt developers could also make more use of the bug tracker and allow for peer review from the wider WebKit team. Unilateral commits by Qt guys have broken other builds recently wasting everyone's time. I don't know if I have been affected by this too much, but I do agree with this advice. Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Download client
On Nov 16, 2007 12:47 AM, Brady Eidson [EMAIL PROTECTED] wrote: In FrameLoaderClientGtk.cpp, I see that void FrameLoaderClient::download(ResourceHandle*, const ResourceRequest, const ResourceRequest, const ResourceResponse) is not implemented. Until it is, it would seem that WebKitGtk is incapable of downloading files, even if you set its policy to do so. Since the GTK port uses CURL it shouldn't be too hard to implement the above using CURL. In fact, I found this example in the libcurl documentation that downloads a file and has a GTK progress bar: http://curl.haxx.se/lxr/source/docs/examples/curlgtk.c Naiem, this should be all you need as inspiration to write the above method. Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Build question on Window (Safari version)
On 10/2/07, Jerry K [EMAIL PROTECTED] wrote: I can build webkit dll file successfully, but the run-safari script is looking for safari.exe. Should I download safari.exe separately or my build process is not completely, and in which statements/steps will create safari.exe? Safari is a proprietary product from Apple and the source code is not open source. You need to download Safari for Windows and install it in the default location so that the run-safari script can fine safari.exe. Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Build question on Window (Safari version)
On 10/3/07, Jerry K [EMAIL PROTECTED] wrote: Thanks for the reply I saw Unhandled exception at 0x764bb09e in Safari.exe: 0xC06D007E: Module not found. while using my built dll with Safari.exe. Is there any info to solve the incompatibility? Hmmm, I'm not sure about that myself. Maybe a developer who works with Safari and WebKit on Windows can help you out more. I'm working on a port to a different platform and don't know much about WebKit on Windows beyond that you must download Safari ;) Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
