[webkit-dev] Recovering admin password for webkit-gtk mailing list
Hey, It looks like we lost the password for the administrative interface for the webkit-gtk mailing list. Could we get it resent to the admins or reset? Thanks! -- Gustavo Noronha Silva <g...@gnome.org> GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] GTK+ EWS bot lagging behind
Hey, Em Seg, 2014-01-27 às 19:18 -0800, Martin Robinson escreveu: On Mon, Jan 27, 2014 at 5:55 PM, Anders Carlsson ander...@apple.com wrote: Hello, there are currently 93 patches in the GTK+ EWS patch queue, is it stuck? If it’s not, I think it’s completely unreasable to expect committers to wait for 93 patches to be processed before landing. (This lead to a problem this weekend where I removed code from WebCore that was used by GTK+ WebKit and I couldn’t tell because the patch was never processed!) It just looks like the bot is wedged. I'll try to run a local EWS until it's unwedged. I was looking into it yesterday but had to drop it 'till today, it should be up and running in a couple hours, I think I managed to find the main issue. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Problem authenticating to svn
Em Qui, 2013-10-03 às 20:44 -0300, Gustavo Noronha Silva escreveu: I'm having trouble committing a patch. I can login to trac and to the buildbot, but svn doesn't let me in. I am using git-svn, I'm downloading the nightly tarball to try with svn itself just in case. My username is k...@webkit.org, can anyone take a peek at the server to see if there's anything wrong? Yeah, same problem with subversion itself. -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Problem authenticating to svn
Hey, I'm having trouble committing a patch. I can login to trac and to the buildbot, but svn doesn't let me in. I am using git-svn, I'm downloading the nightly tarball to try with svn itself just in case. My username is k...@webkit.org, can anyone take a peek at the server to see if there's anything wrong? Thanks in advance! -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unable to create webview object through npapi pluins
Hey, This question is not appropriate for this list, since it looks like you're using webkitgtk, please use the webkit-gtk mailing list (on this same server). Cheers, Em Seg, 2013-09-09 às 11:04 +0530, prasadam kumar escreveu: Hi, I am trying to create web view object through npapi plugin. I am using webkit2 in this plugin will run as a separate process. When i am trying to run my plugin in my ubuntu pc i am getting below error message. When i call webkit_web_view_new() api getting below error (Plugin-container:2037): GLib-GObject-Warning **specified instance size for type 'WebKitWebView' is smaller than the parent type's 'GtkContainer' instance size (Plugin-container:2037): GLib-GObject-Critical **g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' is failed (Plugin-container:2037): GLib-CRITAL **g_once_init_level: assertion 'result != 0' failed. Please help me why i am getting above error message. Regards Prasadam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enable CSS_FILTERS and FILTERS on more bots
Pretty late to the party, but: Em Seg, 2013-08-19 às 14:08 -0700, Dirk Schulze escreveu: When I worked on CSS filters, I start realizing after reading the build errors that most bots (all but Mac bots?) have either CSS_FILTERS, FILTERS or both flags disabled. It would be extremely useful to have more than just one platform building with filters enabled. Could we make this possible on Gtk or Qt bot? The reason we don't enable CSS_FILTERS on the bots, AFAIK, is we haven't been able to make 3D work reliably and in a reproducible way on the bots (which run on VMs using Xvfb). We work towards this goal as time allows, and with webkit2 becoming our main target it has become more important. As soon as we get that (or real hardware bot) we sure should enable css filters. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fwd: Fwd: help building webkit-clutter-1.11.0+20121003
Hey, As has been pointed out by Benjamin Poulain, the clutter port is out-of-tree and building it is unrelated to the development of WebKit, so off-topic for this list. Please post to the webkit-help mailing list. Cheers, On Sáb, 4 Mai, 2013 at 1:15 , Hardik Gohil hardikgohil1...@gmail.com wrote: i have recorded configure output in build.log and other is config.log On Mon, Apr 29, 2013 at 9:38 PM, Jay Bhaskar jay.bhas...@yahoo.com wrote: please send complete log error. or do remove the line no.. if it comes under if block in configure script, do remove that block From: Hardik Gohil hardikgohil1...@gmail.com To: webkit-dev@lists.webkit.org Sent: Monday, 29 April 2013 5:33 PM Subject: [webkit-dev] Fwd: help building webkit-clutter-1.11.0+20121003 Hello, I am building Webkit-clutter using Mingw on Windows with configure ./configure --prefix=/opt/emo2 --with-gstreamer=1.0 --with-target=win32 --with-port=clutter i installed all the dependencies it prompted.but it is giving error. ./configure: line 17485: syntax error near unexpected token `0.16' ./configure: line 17485: ` PKG_PROG_PKG_CONFIG(0.16)' Any one have idea what is wrong ? Thanks in advance. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Qui, 2013-04-04 at 18:46 +0200, Balazs Kelemen wrote: FWIW, mrobinson has been working on a GYP build for the GTK port, so I wouldn't delete all of the .gyp files (at least not w/o them weighing in on it). I thought there was some interest at Apple in also using GYP, but perhaps things have (or will) change given that interop w/ Chromium is no longer the big plus it would've been. We discussed this briefly yesterday and we seem to have a consensus there's no point in going further with that plan, since there's nobody else showing interest right now (if we're wrong let us know!). We will try to adopt cmake instead. Do you mean adopting cmake for the whole project, or just for Gtk? I mean the GTK+ port only, sorry for the confusion. When I said 'We' I meant Martin Robinson and myself. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Hey, On Qui, 2013-04-04 at 01:22 -0700, Dirk Pranke wrote: FWIW, mrobinson has been working on a GYP build for the GTK port, so I wouldn't delete all of the .gyp files (at least not w/o them weighing in on it). I thought there was some interest at Apple in also using GYP, but perhaps things have (or will) change given that interop w/ Chromium is no longer the big plus it would've been. We discussed this briefly yesterday and we seem to have a consensus there's no point in going further with that plan, since there's nobody else showing interest right now (if we're wrong let us know!). We will try to adopt cmake instead. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Help with a test failing on (non-wk2) mac and win
Hey, I have a patch that adds a new test which crashes on win and fails on mac - but passes on mac-wk2, can anyone (from Apple I guess) help me figure it out? https://bugs.webkit.org/show_bug.cgi?id=113220 A stack trace for the win crash would be most helpful. I think Mac may be failing because it opens the select popup in an async fashion? Cheers, -- Gustavo Noronha Silva gustavo.noro...@collabora.com Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] rolling out a buggy security patch
On Ter, 2013-03-12 at 02:26 -0700, Maciej Stachowiak wrote: I am still curious who has access to the commit bot's bugzilla account. Is a small set of known people, is it a large set, is the password sitting around somewhere that others may get at it? I do not recall this being answered at the time, or perhaps I have forgotten. If the set with access is a small set of known people who are willing to be identified and be in the security group themselves (or already are), then I am personally fine with it. I'm a bit late to the party but in my case, the EWS bots I maintain (kov-gtk-ews and kov-ec2-gtk-ews) both have mail accounts to which only I have access. I used to run them using my GNOME email address, which meant they had access to security bugs and processed security patches (since I have access), but I decided to split them to a different account since filtering of bugzilla mails that mattered to me was getting quite complicated. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changes to the WebKit2 development process
On Qua, 2013-01-09 at 12:04 +0200, Thiago Marcos P. Santos wrote: I think the fact that the regular WebKit review process stops at the boundary of WebKit2 should be documented in the WebKit Committers and Reviewer Policy. Agree. And please clarify on the policy if we are talking about everything inside the WebKit2/ directory or if we have exceptions. It is not clear to me if port specific code is covered by this rule and should by reviewed by the owners. And what about code shared by Qt, GTK and EFL (i.e. Platform/CoreIPC/unix/) but not used by Mac? Curious about this myself, I just reviewed a patch only affecting the GTK-specific parts of WebKit2, I believe that is OK? Should we ammend the Owners file to include information about port-specific directories and reviewers? Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Regd. Remote debugging support in GtkLauncher
Hey, I think this question is off-topic for webkit-dev, please use webkit-gtk or webkit-help in the future. On Qui, 2012-09-06 at 10:49 +, debojyoti@wipro.com wrote: Also I couldn't find any option in GtkLauncher where I can provide the websocket server port, like chrome.exe --remote-debugging-port=9222. WebKitGTK+ currently lacks support for this. There's a WIP patch here to add support for WebKit2GTK+: https://bugs.webkit.org/show_bug.cgi?id=88094 Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Default viewport value on WAP DTDs
On Fri, 2012-05-04 at 23:18 -0700, Martin Robinson wrote: We chose between faking Chromium or faking OS X on all operating systems. We are now a port of Chromium called WebKitGTK+. I don't see any easy way out of this mess. Me neither. Also 'Safari on Linux' was being seen as Android, it seems, by some sites. Even with all of that work some sites still refuse to work or hand us dumbed down content, Google properties included. The only solution to the mess seems to be to fake U-A indeed. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Problem In Compiling Webkit in Debug mode : failed to set dynamic section sizes: Memory exhausted
On Fri, 2012-03-23 at 12:08 +0200, John Yani wrote: WebKit's codebase increases every day, so It's not strange that it requires more and more memory to link. The maintainer of the WebKitGTK+ package in Ubuntu told me about a linker switch they are using to avoid problems when building in 32 bits systems: --no-keep-memory ld normally optimizes for speed over memory usage by caching the symbol tables of input files in memory. This option tells ld to instead optimize for memory usage, by rereading the symbol tables as necessary. This may be required if ld runs out of memory space while linking a large executable. Notice that that seems to only work for GNU ld - the gold linker has this as a no-op for compatibility only. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Fri, 2012-03-09 at 08:33 -0800, Ryosuke Niwa wrote: Frankly, I don't quite understand the benefit of this transition. Do we really need to move to git? If the only problem of keeping svn was about svn-apply being broken, I'm more than happy to fix that script. For me the biggest benefit would be to do away with ChangeLog files, if we come to that by moving to git. I'm otherwise happy with using the git mirror and git svn for all my needs. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Thu, 2012-03-08 at 19:39 -0300, Alexis Menard wrote: To svn user : - Conflict resolving much easier and performant than svn (we have drivers for changelogs and the default one are much better than svn). - Local history/blaming/... - Proper diff coloration (though I'm sure you guys have some magic scripts using colordiff). - The staging area, upload what you want/need and keep some work local - Smaller checkouts - Bot maintainers : Power outage or network interruption in the middle of a svn checkout/up lock the repo sometimes and you need to manually svn cleanup the checkout (maybe someone have a tool or script to avoid that???). I had much more svn locked repos than git dead checkout because of interruptions. /me puts his bot maintainer hat on That does suck indeed. Been a while since I had to manually intervene, but even when it is fixed automatically, the new checkout takes ages (because the automatic fix is to rm -rf the whole source tree). That said, we don't need to change the main repository to have bots use git - we can use a git mirror for most bot needs without changing the main repository. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On Fri, 2012-03-09 at 13:43 -0800, Maciej Stachowiak wrote: - Simplified workflow, we don't need to mess with git-svn. - Companies who fork (we all do) can simplify their workflow a bit regarding branches. It sounds like avoiding use of git-svn is the big benefit to git users and perhaps the reason this topic periodically comes up. Can anyone spell out in more detail the benefits of using straight git instead of git-svn? I am a git user, I use git-svn for all my commits and I tend to use git for every project I create myself outside of WebKit. I see lots of benefits to using git over svn. However, for a project like WebKit I think there's really no reason to use git other than people feeling good about removing git-svn from their systems. I tend to think there is little or no benefit to switching to git while keeping all of the project workflow in place. The fact that we would want to keep a simple history with no merges in it pretty much defeat any benefit that could be had. I think using git only makes sense if we adopt git workflows, which would mean people would post git branches for review instead of patches, and those branches would then get merged. The one point I think makes a lot of sense to investigate is tools. People who are maintaining the awesome tools we use today have been doing a great job of making them work for both git and svn users, but it's probably a big burden for them. So, if people declare that some tools will only work with git work directories, I'd be fine with it, would anyone oppose? We can keep using svn as the central server, but people wanting to use those tools would have to use git-svn. Tbh, I am much more interested in doing away with ChangeLogs than in feeling good about using git push instead of git svn dcommit. If we could find a way around ChangeLogs while keeping svn, then I would be an even happier panda than I am today =). Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The Gtk EWS bot is sick: no space left on device
On Fri, 2012-03-09 at 20:55 -0800, Benjamin Poulain wrote: The Gtk EWS bot keep failing with: Last 500 characters of output: patch: write error : No space left on device patch: write error : No space left on device patch: write error : No space left on device Can anyone have a look at the poor machine? Oops! Fixed, thanks! -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] *.webkit.org is down
to any of them. I tried two different internet providers with their own DNS and I even tried google DNS with no luck. Might you try OpenDNS? 208.67.222.222/208.67.220.220 Talking to some people in #webkit it seems that not everyone is affected (maybe only people outside US?). Anyone who knows where the servers sits would mind to have a look at them? Thank you very much. ___ 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 ___ 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 -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Status of the Inspector client in the Gtk+ WebKit port
On Thu, 2011-12-01 at 17:41 +0100, Ilyes Gouta wrote: My bad. I'm so used to build WebKit with most build options disabled. Reverted to a default build configuration and it indeed looks good. FWIW, I saw this problem before and it seems it was related to workers being disabled. -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_CALENDAR to WebCore
On Sun, 2011-07-17 at 03:11 +, 김동관 wrote: We'll be setting up a buildbot to track then ENABLE_CALENDAR build shortly. We expect this feature to be eventually enabled by all ports. I've seen news of setting up buildbots a lot lately. Are this many buildbots really going to be setup, or is this a misunderstanding caused by reusing one announcement as a template? Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
On Mon, 2011-06-06 at 17:59 +0530, Monil Parmar wrote: How to use it for gtk launcher...I think it is for safari. A bit late for this answer, but for completeness sake: GtkLauncher is not a full browser, so it doesn't expose many features available in WebKitGTK+. You should use Epiphany or Midori preferably for trying these things. In any of these browsers you can get to the inspector by right-clicking anywhere on the page and selecting 'Inspect Element'. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Inconsistency in logging approach
On Thu, 2011-06-23 at 22:26 +0200, Łukasz Ślachciak wrote: They warn user with messaage sth like: WEBKIT_DEBUG is not empty, but this is a release build. Notice that many log messages will only appear in a debug build. Of course to have logging working in GTK you need to turn off LOG_DISABLED macro in Assertions.h. FWIW, that's just because some libraries like libsoup have their own logging that we can enable even in release mode. All of WebKit's LOG() calls are disabled in release builds. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Announcing a clutter port of WebKit
Hey! I just finished pushing the current version of a new port of WebKit based on the Clutter library. Being also based on GObject it shares a lot of infrastructure with the GTK+ port - almost all of the public API is shared, much of the WebCore-WebKit glue code, GStreamer, Cairo and Soup backends. You can find it here: http://gitorious.org/webkit-clutter/webkit-clutter I have discussed this new port with the other WebKitGTK+ people during our hackfest, so they are aware of its existence for a bit now, though the code was not yet available. The work is being done on behalf of my employer Collabora. We are not yet going to upstream it because at this point in time we are still figuring out how long-term maintenance would work, and we are aware the WebKit project doesn't like ports that end up requiring lots of work and are then left bit-rotting in the tree (neither do we). As soon as we can figure this out, we'll let you know. For now I'd like to let anyone who might be interested in this work know it's publicly available =). Let me know of any questions! Cheers, -- Gustavo Noronha Silva gustavo.noro...@collabora.co.uk Collabora Ltd. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GTK+ release bots are missing results
On Wed, 2010-12-01 at 09:15 -0800, William Siegrist wrote: On Dec 1, 2010, at 8:56 AM, Adam Roben wrote: On Dec 1, 2010, at 11:54 AM, Martin Robinson wrote: For some weeks now the GTK+ release bots have been missing results. When you try to click on any result in results.html, there's an error page. Perhaps the umask change that Bill Siegrist requested a month or so ago [1] was never made on those bots? Yes, its a umask problem. Gustavo, can you recheck the umask changes you made on gtk-linux-slave-1 and gtk-linux-slave-4? Damn, yeah, I made the change but I was not aware the configuration files were actually handled by a centralized configuration system that later restored the configuration file to its original form =/. The centralized configuration system has been taught about the new settings now, and the slaves restarted. Sorry for the mess. Thanks, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Buildbots soon to require apache mod_bw
On Fri, 2010-11-05 at 01:52 -0700, Eric Seidel wrote: This is a bad idea. Please don't do this. Unless mod_bw comes installed in a normal Apache distribution, you're asking that *every* webkit developer install mod_bw in order to run the layout tests. We already ask them to install python, perl, ruby, apache itself, php, in some cases additional codecs and whatnot. An additional apache module is not the end of the world, is it? Having said that, it just struck me that we have a few php scripts that are used by tests to cause intentional delays[0]. Perhaps we could use a similar pattern for this case too, and avoid this new requirement. Cheers, [0] LayoutTests/http/tests/misc/resources/slow-png-load.pl, for one -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Buildbots soon to require apache mod_bw
On Fri, 2010-11-05 at 08:19 -0700, Evan Martin wrote: On Fri, Nov 5, 2010 at 4:53 AM, Gustavo Noronha Silva g...@gnome.org wrote: On Fri, 2010-11-05 at 01:52 -0700, Eric Seidel wrote: This is a bad idea. Please don't do this. Unless mod_bw comes installed in a normal Apache distribution, you're asking that *every* webkit developer install mod_bw in order to run the layout tests. We already ask them to install python, perl, ruby, apache itself, php, in some cases additional codecs and whatnot. An additional apache module is not the end of the world, is it? One thing you may have overlooked: installing software like this is a lot harder on platforms other than Linux. I was actually thinking of Windows when arguing my point =), since for us the module is one apt-get away, and I assume for Mac there would be a similarly easy way of getting it installed. But since we have other ways of solving the issue with reasonable effort, I don't think having one more requirement makes sense indeed. I'm just trying to argue that if (and I emphasize the if here) it was necessary, another module would not be that bad. I understand from Eric's message that Mac comes with ruby pre-installed, but that is not true for most GNU/Linux distributions or Windows, and that was certainly not a show-stopper when it got added to beautify diffs =). I do agree with the goal of keeping the number of requirements to a minimum, though, so let's see if we can get this done with the cgi Phillip found! Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] GTK+ 64 bits release bot maintenance
Hey, The GTK+ 64bit release bot is being moved to a faster machine, so it will be down for a few hours. It is currently not a core builder (though these days it is stable enough to go back to being one =D), so this should not cause any issues with the commit queue. The other 3 bots should be able to help with identifying test failures and build breakages while this one is down. I'll let you know when the bot is back, sorry for the short notice! Thanks! -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
On Sat, 2010-07-24 at 03:32 -0300, Gustavo Sverzut Barbieri wrote: Guessed so from Qt port... Now we need to do that for both soup and curl, or write an abstraction for elf with some backend outside webkit FYI, this is being worked on in soup: https://bugzilla.gnome.org/show_bug.cgi?id=55 Perhaps you could discuss with Dan Winship and Sergio how you could help them there =) See you, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [62546] trunk/WebCore
Hello, On Tue, 2010-07-06 at 11:13 -0700, Alexey Proskuryakov wrote: We do sometimes land changes that are reviewed on IRC and that don't correspond to bugs. The main criteria for when this is appropriate are: - the change is simple, and doesn't need many eyes looking at it; - there is no historical trail to maintain, no one is going to look at svn blame and wonder why this change was made 10 years ago. A change that modifies cross platform code to fix a platform specific (?) crash, and that doesn't even include a test case definitely needs to be tracked in WebKit Bugzilla. You are right. I at first believed the bug report I mentioned along with the change description would suffice (since mentioning non-webkit-bugzilla trackers is fairly common, and the trace is pretty straightforward), but I believe for this change a webkit bug with a bit more information on the problem we're addressing is in order indeed! I have opened https://bugs.webkit.org/show_bug.cgi?id=41710 and will add that as reference to the ChangeLog. Thanks! -- Gustavo Noronha Silva gustavo.noro...@collabora.co.uk Collabora Ltd. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Gtk 32-bit Release Bot Wedged
On Thu, 2010-05-20 at 00:20 -0700, Eric Seidel wrote: The Gtk 32-bit Release bot has wedged itself. If someone could kick it that would be grand: http://build.webkit.org/results/GTK%20Linux%2032-bit%20Release/r59822%20(13001)/results.html Do we understand why this happens so we can prevent it in the future (this is not the first time)? I kicked it. What happened was pulseaudio died. What I'll do is I'll have a daemon monitor make sure the pulseaudio server is running at all times, and automatically restart it if it drops again, since I could not investigate this bug. If this kind of thing happens when I'm not around, poking infinity or Mithrandir (IRC names of people who are also admins of the machines) is an option. They are always in #telepathy at FreeNode. Thanks! -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Qt buildbots
On Fri, 2010-04-09 at 01:20 -0700, Maciej Stachowiak wrote: Perhaps build.webkit.org should have a multi-page setup like how build.chromium.org does where the main page is builders that are expected to be green, and other pages are FYI were builders may or may not always be green. I would support a multi-page setup like this. I would support that as well, given that we have 4 bots, and some of them are difficult to keep green at all times. Thanks, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Frustrations with WebKit Font Representation
On Tue, 2010-03-16 at 15:49 -0700, Brent Fulgham wrote: Recently, an update that attempted to share more Cairo-related font code was added to the WebKit repository (http://trac.webkit.org/changeset/55510). While this was no doubt of great benefit to the Gtk-based ports, it had the unintended side It was really no benefit for GTK+-based ports, this move was made so that other ports (in this case EFL) could use the font implementation that is not tied to GTK+. While I agree with the rest of your email, I failed to understand the actual problem this caused. Is it because the include path for platform/graphics/cairo is coming before the one you were using, and then picking up the wrong file on include? See you, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing new port: EFL
On Tue, 2010-02-23 at 14:44 -0300, Leandro Pereira wrote: I am doing the cleanups required by the upstream task, merge of GTK+'s and EFL's build system, and will do further works on unifying both GTK +'s and EFL's codebases. There are other people working on this port, however: I think it's important to step in on this. I'm sure EFL and GTK+ will be able to share many things, and that the EFL port wants to use the same network backend, and media implementation we use, for instance. I'd like to ask potential reviewers to avoid giving r+ to patches that touch our build system or any of our backends without having us (g...@gnome.org, and xan.lo...@gmail.com) CCed in the bug so we can give it a quick pass, unless the change is trivial or just moving stuff around, as was the case for GOwnPtr, and GRefPtr. As everyone knows our build system is one of the slowest, so adding complexity to it may not be always a good idea. Also, we want to be sure that we are using the best tools available to GTK+ in the backends we maintain, avoiding lowest common denominator solutions, so we will likely prefer having alternate implementations for stuff that is not portable, rather than dumbing them down, if that's needed. Having said that, welcome to WebKit, and count on me to help get things rolling where possible! =) See you, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More on test flakiness
On Wed, 2009-12-02 at 14:51 -0800, Julie Parent wrote: As Eric just said to me in person, another option is to just re-run *any* failing test twice, and only turn tree red if it fails twice. (Chromium just recently started doing this, and it has greatly improved our tree greenness). This obviously doesn't explicitly identify timing dependent tests, but it solves the bigger issues that flaky tests cause. But that would turn moot the point of the suggestion, I think. Having only tests that are expected to fail under special conditions be tested twice makes sense, but if a test that isn't expected to fail under special conditions fails, we should see that as a failure. To give you a bit of insight into this, in GTK+ we used to have tests that only failed when they were preceded by a specific test. This was very important information that would be lost if it was run after itself, and thus passed. The problems that caused this were missing support in DRT, and a couple of times real bugs that caused crashes. This is to say I think we would be better served by only running known-time-dependent tests twice. Thanks, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A bot-filled future?
On Mon, 2009-11-16 at 18:48 -0800, Geoffrey Garen wrote: I understand why you want to start with a Mac bot, and I applaud starting small. However, bear in mind that lots of WebKit contributors work primarily on the Mac, so they probably won't get any use out of a Mac try bot, and you probably won't get any feedback from them until the try bot expands to cover other platforms. I believe the idea is in fact to start with a GTK+/Qt on Linux bot (since it should be simpler to setup). See you, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] On the greeness of the GTK+ bot
Hey, Keeping the GTK+ buildbot green has been a real challenge for many reasons, but looking back at previous discussions we had regarding this, I think we have come a long way. Over the last few weeks we (mainly Xan!) put some hard work on getting the bot green by fixing bugs, opening bug reports, and skipping tests. One of the issues we usually have lots of trouble with is patches regressing our tests that people do not notice. We have had some good experiences regarding this recently: a patch to modify how the media tests were run broke all our media tests for the third time since we stabilized them, but the change was backed out to be reworked. The second one was the work to get shadows support in cairo, which regressed 2 tests of ours. Because we were paying attention we were able to quickly spot them, and the people involved could fix them before their regressive nature was lost in time, and they ended up on the Skipped list. I would like to ask of people checking in changes that they try to pay as much attention to our release bot as they are paying to Mac bots. We will do our best to keep them green, but it gets very difficult to do it when people are checking in stuff that breaks our tests all the time, and not paying attention to them. In summary, I would like to see this kind of behavior applied to our bots as well: https://bugs.webkit.org/show_bug.cgi?id=29329 This it can't remain like that; we need to either skip, check in a platform-specific result or back out the change would help us a lot. Thanks! P.S. I think it is important to note there are a number of tests failing intermittently, mainly inspector ones, but that seems to be happening on all the bots, so bear with us there =). -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ 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, 2009-11-16 at 05:24 -0800, Adam Barth wrote: Eric and I are working on a bot that might help this situation. Essentially, the bot will try out patches on Qt and GTK and add a comment to the bug if the patch regresses the build. Our plan is to start with compiling, but we'd eventually like to run the tests as well. That sounds like an awesome idea. Thanks for working on it. Build breakages themselves have become less of an issue for us in recent times - people are definitely more aware of our bots, and are acting on fixing them when they break. I think such an automated approach to running the build, and tests for upcoming patches will surely help with giving this a second step forward. See you, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
On Wed, 2009-08-26 at 17:38 -0700, Geoffrey Garen wrote:
[This question not necessarily just for Peter:]
If we removed the discipline of reviewing ChangeLogs, and the tools
that autogenerate a ChangeLog template and check for a ChangeLog entry
without an OOPs I didn't get this reviewed message, what would we
replace them with?
You can include the commit message to the patch nevertheless. That's
what git format-patch does, for instance. I am attaching an example.
See you,
--
Gustavo Noronha Silva g...@gnome.org
GNOME
From 04a4fd6c2a0f59c990162fcbac6607d50240dc38 Mon Sep 17 00:00:00 2001
From: jmalo...@webkit.org jmalo...@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc
Date: Fri, 28 Aug 2009 15:12:29 +
Subject: [PATCH] 2009-08-28 Jan Michael Alonzo jmalo...@webkit.org
Reviewed by Gustavo Noronha and Xan Lopez.
[Gtk] Add view source mode API
https://bugs.webkit.org/show_bug.cgi?id=28805
Implement setter and getter for view source mode.
* webkit/webkitwebview.cpp:
(webkit_web_view_set_view_source_mode):
(webkit_web_frame_get_view_source_mode):
* webkit/webkitwebview.h:
git-svn-id: http://svn.webkit.org/repository/webkit/tr...@47865 268f45cc-cd09-0410-ab3c-d52691b4dbfc
---
WebKit/gtk/ChangeLog| 14
WebKit/gtk/webkit/webkitwebview.cpp | 38 +++
WebKit/gtk/webkit/webkitwebview.h |7 ++
3 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/WebKit/gtk/ChangeLog b/WebKit/gtk/ChangeLog
index 4d64cc8..da5a432 100644
--- a/WebKit/gtk/ChangeLog
+++ b/WebKit/gtk/ChangeLog
@@ -1,3 +1,17 @@
+2009-08-28 Jan Michael Alonzo jmalo...@webkit.org
+
+Reviewed by Gustavo Noronha and Xan Lopez.
+
+[Gtk] Add view source mode API
+https://bugs.webkit.org/show_bug.cgi?id=28805
+
+Implement setter and getter for view source mode.
+
+* webkit/webkitwebview.cpp:
+(webkit_web_view_set_view_source_mode):
+(webkit_web_frame_get_view_source_mode):
+* webkit/webkitwebview.h:
+
2009-08-26 Xan Lopez xlo...@igalia.com
Reviewed by Gustavo Noronha.
diff --git a/WebKit/gtk/webkit/webkitwebview.cpp b/WebKit/gtk/webkit/webkitwebview.cpp
index ae0b45f..8d0f08b 100644
--- a/WebKit/gtk/webkit/webkitwebview.cpp
+++ b/WebKit/gtk/webkit/webkitwebview.cpp
@@ -3733,3 +3733,41 @@ void webkit_web_view_redo(WebKitWebView* webView)
if (webkit_web_view_can_redo(webView))
g_signal_emit(webView, webkit_web_view_signals[REDO], 0);
}
+
+
+/**
+ * webkit_web_view_set_view_source_mode:
+ * @web_view: a #WebKitWebView
+ * @view_source_mode: the mode to turn on or off view source mode
+ *
+ * Set whether the view should be in view source mode. Setting this mode to
+ * %TRUE before loading a URI will display the source of the web page in a
+ * nice and readable format.
+ *
+ * Since: 1.1.14
+ */
+void webkit_web_view_set_view_source_mode (WebKitWebView* webView, gboolean mode)
+{
+g_return_if_fail(WEBKIT_IS_WEB_VIEW(webView));
+
+if (Frame* mainFrame = core(webView)-mainFrame())
+mainFrame-setInViewSourceMode(mode);
+}
+
+/**
+ * webkit_web_view_get_view_source_mode:
+ * @web_view: a #WebKitWebView
+ *
+ * Return value: %TRUE if @web_view is in view source mode, %FALSE otherwise.
+ *
+ * Since: 1.1.14
+ */
+gboolean webkit_web_view_get_view_source_mode (WebKitWebView* webView)
+{
+g_return_val_if_fail(WEBKIT_IS_WEB_VIEW(webView), FALSE);
+
+if (Frame* mainFrame = core(webView)-mainFrame())
+return mainFrame-inViewSourceMode();
+
+return FALSE;
+}
diff --git a/WebKit/gtk/webkit/webkitwebview.h b/WebKit/gtk/webkit/webkitwebview.h
index 42736dc..968b74e 100644
--- a/WebKit/gtk/webkit/webkitwebview.h
+++ b/WebKit/gtk/webkit/webkitwebview.h
@@ -356,6 +356,13 @@ webkit_web_view_redo(WebKitWebView*webView);
WEBKIT_API gboolean
webkit_web_view_can_redo(WebKitWebView*webView);
+WEBKIT_API void
+webkit_web_view_set_view_source_mode(WebKitWebView*web_view,
+ gboolean view_source_mode);
+
+WEBKIT_API gboolean
+webkit_web_view_get_view_source_mode(WebKitWebView*web_view);
+
G_END_DECLS
#endif
--
1.6.3.3
___
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 Sun, 2009-08-23 at 21:30 -0700, Adam Barth wrote: I think, though, that the AFS/NFS issue you mention is more general and shouldn't be a motivating factor. We have many GNU/Linux users not in corporate networks, these days, as well, and I think we should not be designing everything for big installations (those usually have admins who can worry about this kind of issue). Also, it looks like you can access windows shares using file://server/folder/file.html, so this doesn't seem to be UNIX-specific in any way. I also bet Mac can be made to use NFS, and AFS, so, again, I fail to see this as particularly important on non-Mac UNIX-likes. I'm not sure I quite followed your line of reasoning here. Are you suggesting that everyone should use the more secure setting or are you saying that you don't think this is an important security measure in non-enterprise settings? I am saying that we should be careful not to design things with 'Linux is mostly used in enterprise settings' in mind. There is no reason to treat it differently than the other desktops; I myself have never used NFS or AFS, nor have many people I know, even though I've been using GNU/Linux for ~10 years now. And, as I pointed out, the same potential problem with networked file systems may happen with Windows or Mac. I agree that everyone should disable universal access for file URLs. In fact, I think we should make it the default because the current default is pretty dangerous. So, to clear up my position regarding the actual meat of the proposal: I agree this is an important security concern. Doing that in libraries right now will break API expectations, though, so I think if it is done, this should be done first by documenting the intent to change, and then changing after a reasonable amount of time. Of course browser applications can do it right now, though =) See you, -- Gustavo Noronha Silva g...@gnome.org GNOME ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changes to prepare-ChangeLog
On Thu, 2009-07-09 at 14:32 -0400, tonikitoo (Antonio Gomes) wrote: I grew up listing and seeing people not writing their emails *as it* and publishing on the internet so would replacing m...@apple.com by mjs at apple dot com be a good practice ? I always failed to see much wisdom in this. It might be because I always used highly published email addresses, but then again, I would much rather have something I can just click/copy instead of copy-edit. -- Gustavo Noronha Silva g...@gnome.org GNOME ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changes to prepare-ChangeLog
On Fri, 2009-07-10 at 18:18 -0700, John Abd-El-Malek wrote: this changelist. Operations such as gcl upload CHANGENAME (upload to Rietveld) work on the group of files at the same time (also things like gcl diff/commit/revert). The nice thing about it that on such large codebases, developers will often have unrelated changes, and this avoids having to unapply/apply frequently. This looks like a hack that is fixed by using a proper tool, such as git, to me. -- Gustavo Noronha Silva g...@gnome.org GNOME ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Feature request] Bugzilla: default unassignee emails to per component.
On Mon, 2009-07-06 at 13:15 -0700, Darin Adler wrote: To follow bug activities on a particular component, we should probably add a Bugzilla watch feature that lets you follow bug activities on a component. I was talking about this with Mark Rowe this week: what we need is to enable the QA Contact feature, and point components' QA contact to 'fake' email addresses, so that it is easy to 'subscribe' to them. In GNOME's bugzilla the default assignee and QA contact both are fake email addresses named like this: project@gnome.bugs. The good thing of having it this way is that, even if a developer assigns the bug to himself, the QA contact keeps receiving notifications, and thus alerting interested people of changes. I would like to see something of this sort implemented, because I would really like to follow the WebKit Gtk component. RSS helps, but is so very limited compared to receiving copies of bug mail. See you, -- Gustavo Noronha Silva g...@gnome.org GNOME ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] make webkit-1.1.3 - error
On Fri, 2009-03-27 at 13:24 +0800, yenchengwang wrote: hi all, I also get error messages like bellow when I make webkit-1.1.3 I would suggest doing a make distclean and starting the build from scratch. This looks like a build mixing versions of libraries. See you, -- Gustavo Noronha Silva gustavo.noro...@collabora.co.uk Collabora ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Get the HTTP request and response when loading a URL
Hello, On Tue, 2009-01-27 at 09:36 +0100, ferrety ferrety wrote: When using ./Programs/GtkLauncher to load a web page, let say http://www.cnn.com;, I'd like it to output both HTTP request it sends to the server and response from that server, both printed on the shell. That is mostly not supported API-wise as of yet, on the GTK+ port. You can take a look at this bug report to know where things stand: https://bugs.webkit.org/show_bug.cgi?id=18608 Take a look also at the frame loaders rework: https://bugs.webkit.org/show_bug.cgi?id=17066 See you, -- Gustavo Noronha Silva g...@gnome.org GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk network backend
On Mon, 2008-12-22 at 14:03 -0800, Brent Fulgham wrote: The Redistributable WebKit on Windows currently uses the cURL backend. I am fully in favor of switching to libSoup for this platform as well, if it is known to work properly on Windows. I am a bit concerned that it seems to be heavily tied to the Gnome platform. Will I end up having to pull in glib and other Gnome dependencies if I wish to use it? I'm not sure the redistributable windows port needs to switch to libsoup. Only the GTK+ port on Windows would switch, by the current proposal, and curl can be specialized even more to work for the wx and windows ports, since GTK+ would no longer use it. See you, -- Gustavo Noronha Silva g...@gnome.org GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk network backend
On Sun, 2008-12-21 at 21:29 +0100, Christian Dywan wrote: So, I'd like to suggest to make libSoup the only backend. We would then require a recent (unstable) libSoup, similar to how Gtk+ depends on the latest (unstable) Glib. Xan Lopez has agreed already on IRC. As someone who has been building/testing/developing/using WebKit/GTK+ with libsoup from the start, I agree. Of course, we actually have a use case, that is we agreed to introduce libSoup specific API: https://bugs.webkit.org/show_bug.cgi?id=22624 I also agree with this API adition, as discussed in the Soup Cookies patch IRC meeting some time ago. See you, -- Gustavo Noronha Silva g...@gnome.org GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can't build r39090: WebKit/gtk/tests/Programs_UnitTests-main.o fails
On Wed, 2008-12-10 at 20:49 +0800, Arthur Webkid wrote: What I don't understand is I have GLib 2.16.6 installed but still can't build. Anyone has the same problem likes me? What matters is your GTK+ version, which should be higher than 2.14.0, which adds that symbol, could you try that? See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to enable Inspector in Webkit/GTK
On Sun, 2008-11-30 at 18:32 -0600, ying lcs wrote: Thank to both of you. I apply the patch. And now I see 'Inspect element' in the context element. But when I load www.google.com, the inspect window is just blank. Can you please tell me what am I missing? You probably forgot a 'make install', and WebKit is not finding the HTML/CSS/Javascript files needed to run the inspector. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Fwd: Fwd: Re: Moving forward with WebKit/GTK+]
On Fri, 2008-11-07 at 23:18 +0100, Holger Freyther wrote: I think this could be a very efficient way to make the API stuff progressing quickly - at all cost lol (since time is the ultimate dead line). In general I like your idea, specially with Gtk+ 3.0 in sight we know we can break API soon so it seems like a good idea to gain experience in that area and it would not hurt us too much to add something stupid. Yep =) Alp was talking about branching, maybe using FreeDesktop's infra-structure, and giving direct access to the code to more people, as an experience, too. One minor issue, I would prefer a mailinglist (maybe I'm just too old): I agree (and prefer) the mailing list. I was thinking of requesting it to GNOME, but since Alp is thinking of branching to FreeDesktop I'm going to look up how to request a mailing list at lists.freedesktop.org, if everyone is OK with it. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Moving forward with WebKit/GTK+
Hello there, For some time now I've been worried by the lack of progress of WebKit/GTK+ where API is concerned. I am aware that loads of work have been going into improving the engine backends and frontends, including many bug fixes, but real-world adoption for many applications is hindered by lack of features being accessible through a public API. While using Epiphany/Devhelp/Liferea, for instance, which already have semi-functional WebKit/GTK+ ports one isn't able to middle-click links to open them in new tabs, which is the kind of feature a user would quickly perceive as basic, and missing. Some other features are currently being implemented by hacks (mis-)using the already exposed API, or the JavaScriptCore API. It happens that quite a bit of missing API bits are already written and posted to WebKit's bugzilla: [gtk] Implement WebPolicyDelegate methods https://bugs.webkit.org/show_bug.cgi?id=16562 [GTK] Improve frameloader signals https://bugs.webkit.org/show_bug.cgi?id=17066 [Gtk] Implement WebKitWebDownload https://bugs.webkit.org/show_bug.cgi?id=16826 [gtk] implements FrameLoaderClient::dispatchDidChangeLocationWithinPage https://bugs.webkit.org/show_bug.cgi?id=20306 [Curl] Rewrite of curl backend to run in event loop https://bugs.webkit.org/show_bug.cgi?id=17972 [GTK] ChromeClient::createWindow and friends need to be implemented https://bugs.webkit.org/show_bug.cgi?id=19130 [Gtk] Enable WebInspector in the Gtk port https://bugs.webkit.org/show_bug.cgi?id=19392 And some others. Some of these patches go back to the begining of the year. Some even have formal reviewers comments, but invariably all of them lack recent official comments or action. The fact that WebKit/GTK+ doesn't go forward is starting to harm its momentum in the GNOME community, from my point of view - Epiphany is already having to decide if they take back the decision to move from Gecko to WebKit, and contributors don't really have a lot of motivation to keep contributing with many-months-old patches sitting in the bugzilla (myself included). We tried to get together last week to try and push forward on the review and landing of some of the patches, but we end up only having an informal review of one patch by contributors of WebKit/GTK+ and related projects; lacking a formal reviewer in the second meeting there was not much we could have done. Notice that I'm not questioning the work done by Alp, I think he's done a great amount of good work, but having only him as a formal reviewer is a clear bottleneck in my opinion. I believe we need to fix this if we want to see WebKit/GTK+ going forward. I can think of various options; forking the tree and trying to advance it outside of the main repository being the one I like the least. What I think could help and not be so destructive as a fork is to have more reviewers. From looking at history and by hanging around since around April, I believe Christian Dywan, is a very good candidate. I don't see GNOME adopting WebKit, or an Epiphany release that is really based in WebKit happening if we don't fix this issue, and I would like to hear people's opinion on how we can do it. Thanks! * DISCLAIMER: I am not speaking for the GNOME project, nor for its release team (though I'm CC'ing Vincent Untz so that he is aware of this discussion), nor for the Epiphany developers. I speak only for myself. -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Equivalent of WebKit/Qt's link delegation policy in WebKit/Gtk+?
On Mon, 2008-10-20 at 16:07 +0100, Andrew S. Townley wrote: Hi, Hello, Unlike the majority of users, I don't need WebKit to access URIs on the Internet. I need to be able to intercept them and display custom HTML content to allow navigation of some complex, in-memory data structures. I take it that you intend to feed the renderer with HTML code contained in memory, without writing it to files. I think what you are looking for is still not really implemented for WebKit/GTK+, and might be this: https://bugs.webkit.org/show_bug.cgi?id=17147 Any information on how this sort of behavior can be accomplished with the existing GTK+ api would also be welcome. Well, you may be able to replace/edit the contents of the page by using the JavaScriptCore API directly. It doesn't sound very elegant/high level to me, but is possible today =). See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit core need to be cleanly separated from ports, behind a vector table
On Wed, 2008-10-15 at 08:04 +, Luke Kenneth Casson Leighton wrote: On Tue, Oct 14, 2008 at 9:47 PM, David Hyatt [EMAIL PROTECTED] wrote: The term webkit core in your subject is very confusing. Do you mean WebKit or WebCore? There is platform-specific code in both. apologies. i mean whichever bit that you link webkit link against to produce a gtk port, or a qt port, or a wx port. While I agree that it would be nice to have a separate library to which both the GTK+ and Qt ports could link, for instance, I believe this model would somewhat remove the agility the project has of refactoring and redesigning big parts of the code. API stability would be something to worry not only for the most outern layer (the port), and that would complicate matters. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unable to compile the webkit on the Redhat enterprise linux 9
Hello, Disclaimer: I'm more of a GTK+/Debian guy =). On Tue, 2008-10-14 at 10:31 -0400, Ramesh Satyavaram wrote: I am new to webkit. Yester day I downloaded the sources on to my Red hat enterprise linux 9. I tried to compile with the following command. There is no such thing as Red Hat Enterprise 9. Either you are using Red Hat 9, or Fedora 9. If you're using the former it is already way old, and you probably have a too old version of qmake. Do check if qmake's version is current. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Webkit available to plain embedding?
On Fri, 2008-10-03 at 18:40 +0300, Konsta Kokkinen wrote: I've been searching how to use webkit as plain as possible: My program creates a X window (I'm using gentoo linux) and commands webkit to render page I'm wanting to that window, nothing else. Yes, I'm NOT wanting to use qt or gtk libraries, just plain rendering. Is this possible? If not, is it maybe possible to make it possible? This seems to mean, to me, that you want a X11-only port of WebKit, so that's what it takes: writing a xlib port of WebKit. If you are OK with at least using Cairo to draw, you should be OK with replacing stuff such as scrollbars and events handling, and providing a simple exportable API. So, basically, currently not possible, but you could do it. -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Javascript window.open handling in GTK
On Wed, 2008-10-01 at 15:18 -0700, Weber, Bernd wrote: Playing around with the code for a while now I found that, at least in the GTK implementation, window.open(), close(), etc is not implemented. Can anyone explain to me why this is not implemented? Maybe because of security concerns? Wouldn’t it be better to have a setting defined that restricts this feature instead of not implementing it at all?! I think mostly because code has not been written or has not been reviewed/commited yet. I think what you are trying to do will probably be helped by these: https://bugs.webkit.org/show_bug.cgi?id=19130 https://bugs.webkit.org/show_bug.cgi?id=16401 See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] problem with ChromeClient::createWindow NewWindow policy
On Fri, 2008-09-19 at 10:38 +0400, Anton V. Tarasov wrote: A new window is opened by a client via ChromeClient::createWindow callback. There's also a mechanism to check NewWindow policy, implemented as FrameLoaderClient::dispatchDecidePolicyForNewWindowAction. Now, when I'm clicking the first link, ChromeClient::createWindow is not called at all, FrameLoaderClient::dispatchDecidePolicyForNewWindowAction is called. In that case, FrameLoaderClient::dispatchCreatePage is called. We have had lots of discussions about new window issues for the GTK+ port in bug #19130, which may interest you. Why that difference? How to open new window in the first case, and why policy check is not triggered in the second? I'm also interested in the policy check issue, haven't done a lot of scouting in that area, though. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to use webkit ?
On Thu, 2008-07-10 at 13:26 -0700, Nemix wrote: supporting JavaScript. Another part, platform-dependent, so called port, is intended for communicating with network, rendering graphic content on the screen and other devices, event handling, and other features. JWebPane is a Java port, in which all cross-platform calls are implemented in Java. Does it mean that I have to develop two applications ? One for embedded systems and one other for Mac OS ? No, unless you want to write the application for Mac OS using the Objective C port which is native for Mac OS. Each 'port' comes with everything you need. When the text says 'platform-dependent' there, it is telling you that there is a 'port' which is specific for Java, as opposed to the one which is specific for C/GTK+ - both will run in multiple OS/Hardware combinations, though. So yeah, you'll have a .jar for each OS/Hardware combination, but your code should be able to remain the same. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how to build arora with latest qtwebkit
On Tue, 2008-07-08 at 16:39 +0200, Benjamin Meyer wrote: get into the arora building path ldd arora give back the following output, it seems that it still use the system libs, so how can I solve the problem? maybe manuelly replace that /usr/lib/libqtwebkit.so.4 with the trunk compiled version? [EMAIL PROTECTED]:~/build/arora$ ldd arora linux-vdso.so.1 = (0x7fff133fe000) *libQtWebKit.so.4 = /usr/lib/libQtWebKit.so.4 (0x7f460a4c7000)* Looks like it is still using the old Makefile. Run 'make distclean' and then qmake (qmake-qt4 on Debian) and then make. You shouldn't need to replace the system libraries. The problem here is actually that ldd is looking for the library in /usr/lib first, and since it finds it there, it uses it (as does arora). Linking with a library in a different directory doesn't mean that the system search path for libraries will be ignored at runtime. You still need to use LD_LIBRARY_PATH or LD_PRELOAD (as suggested by another poster) to force your custom build of the library to be used when the program is executed. You can even build the program using the system library and use the custom built later by setting LD_LIBRARY_PATH. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
