Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
2012/4/24 Tom Penzer : > Hi Everybody! > > As a first-time poster, I am sorry ahead of time for any lapses in > etiquette. I am seeking feedback for my (hopefully relatively painless in > practice compared to the alternatives - i.e. -webkit-image-set and html5 > ) proposal to solve the problem of 2x-res (double-resolution) images > with our current HTML and CSS standards for devices with high-resolution > displays, such as 3rd Generation iPads and 4th generation iPhones and newer. This seems like a perfect use-case for the @media rule of CSS, does it not? It's obviously not up-to-date in its definition (eg. handheld devices are not "typically small screen, limited bandwidth" anymore), but on the other hand it allows undefined types as well so nothing prevents implementers to extend it beforehand (like is done with most CSS properties anyway). -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] when is expose_event fired
2010/10/22 Aneesh Bhasin : > However, I wanted to know where and how is the > webkit_web_view_expose_event function triggered internally - as I > understand it could either be triggered from the windowing system if > there is some movement /scrolling dragging of window or internally if > something has changed and the page needs to be repainted - this second > invocation path I am unable to find. Could someone point me to the > right direction here ? You can invalidate an area of the widget with http://library.gnome.org/devel/gtk/stable/GtkWidget.html#gtk-widget-queue-draw-area or invalidate the whole widget with gtk_widget_queue_draw(). This will (eventually, not immediately) result in the widget receiving an expose event for the invalid area. -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] About the " Video conferencing and peer-to-peer communication" implementation
2011/11/10 Victor LI : > Hi， > Does the webkit implements the chapter " Video conferencing and peer-to-peer > communication" now? > if it doesn't , is there any plan to support it? There are people working on it: https://lists.webkit.org/pipermail/webkit-dev/2011-November/018445.html I suppose bugzilla has bugs for this, although they are not mentioned in the announcement. Would probably be a good idea to have a tracking bug for this though? -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
2012/3/9 Ryosuke Niwa : > On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian > wrote: >> I think if we address the main issues raised by the svn users, the current >> consensus (if representative) seems to point towards an overwhelming support >> (and demand?) for git over svn. On that point it's reasonable to say that >> we're heading towards option #1 or #2 of Maciej. As such, I'm humbly >> proposing the following (hopefully without getting ahead of myself): > > > 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. I think you missed the part where the impact on servers was discussed. If every time someone does "svn log" the server needs to not receive or deal out commits, it will show in response times. I'm sure people using svn do not check the log often, for obvious reasons, but it is still a factor to consider. -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
2012/3/9 Mark Rowe : > > On 2012-03-09, at 09:15, Kalle Vahlman wrote: > >> 2012/3/9 Ryosuke Niwa : >>> 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. >> >> I think you missed the part where the impact on servers was discussed. >> If every time someone does "svn log" the server needs to not receive >> or deal out commits, it will show in response times. I'm sure people >> using svn do not check the log often, for obvious reasons, but it is >> still a factor to consider. > > Making operations like 'log' not hit the server would obviously be nice, but > the vast majority of the > load on the Subversion server is from update or checkout operations. Do you > have a pointer to any > concrete data about the relative load on a server for Git vs Subversion in > terms of these operations? I'm afraid not, just bits and pieces about performance and bandwidth usage that mostly amount just to a gut feeling. Googling also turned up zero studies from server POV. As said there is some evidence that repository size is reduced and that network bandwidth usage can be better with git, but considering how different workflows can emerge at least the bandwidth usage can not be mapped 1:1 to actual deployment. Another consideration here is that git-svn can be rather abusive for the server if used wrong, so if svn is no longer the central VCS that use case will also vanish, further changing the usage patterns. The only way to _truly_ know would be to have graphs from a server that hosted similar class project using svn then switched to git (or vice versa!) and even then it would be dependent on the workflows used... -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
2012/3/11 Maciej Stachowiak : > > The interaction with the version-control system for each of these steps is an > obvious single step with SVN. With git, for at least some of these, you will > end up needing multiple non-obvious (to an SVN user anyway) commands. I understand the context of this argument and it is of course valid but it gets REALLY boring to hear this every time someone tries to make a point :) I've used svn long time ago and git ever since. For me it's no longer obvious that my local changes are not "safe" from merging if I do an update. It is also not obvious that I could not simply commit my patch (locally) and continue on to the next one when the changes are touching the same files etc. The 'obvious' argument should IMO be avoided at all times, because it inherently carries the notion that the svn way is somehow the de facto way of doing things in everybody's minds. It is not. It is always subjective what workflow makes sense. -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fail to build WebKit r37132 with GTK on Fedora core 10
2009/1/7 ferrety ferrety : > Hi List, > > I've tried to build WebKit with GTK on Fedora Core 10, gcc4.3 and > noticed a strange error about a missing member function called > "update". > > $ ./autogen.sh --prefix=/usr/local --enable-video > $ make > ... > WebCore/platform/gtk/ScrollViewGtk.cpp: In member function 'void > WebCore::ScrollView::ScrollViewPrivate::scrollBackingStore(const > WebCore::IntSize&)': > WebCore/platform/gtk/ScrollViewGtk.cpp:183: error: 'class > WebCore::ScrollView' has no member named 'update' > make[1]: *** [WebCore/platform/gtk/libWebCore_la-ScrollViewGtk.lo] Error 1 > make[1]: Leaving directory `/home/younes/Desktop/WebKit' > make: *** [all] Error 2 > > After commenting this line 183, everything went fine: > // view->update(); > > Could someone please explain me why this function is missing? Is it > deprecated? > Any fix? Yeah, it was removed around the time of the revision you used and the gtk+ build got fixed (multiple times) some time after that: http://trac.webkit.org/changeset/37172/trunk/WebCore/platform/gtk/ScrollViewGtk.cpp Probably best to upgrade to a newer revision, unless you have specific reasons to stick with that one... -- Kalle Vahlman, z...@iki.fi Powered by http://movial.fi Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Problems with JavaScript bison parser
2009/2/19 Javed Rabbani : > Hello everyone, > > > > I am working on a WebKit port for some platform and facing an issue with > working of JavaScript bison parser in "Grammar.cpp". If I execute the > following HTML file, everything is parsed without error: There's a known bug with ARM and bison earlier than version 2.2: https://bugs.webkit.org/show_bug.cgi?id=22456 though that one outright chrashes (and it's CSS parsing that is crashing). But maybe you should try different bison versions to see if it makes a difference? -- Kalle Vahlman, z...@iki.fi Powered by http://movial.fi Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSObjectMakeFunction question
2009/6/1 Jack Wootton : > Hi all, Hi! > I'm attempting to use the function JSObjectMakeFunction described here: > > http://gemma.apple.com/documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/JSObjectRef/index.html > > I would like to call a JavaScript function from C. I assume the > following is required: > > 1. Create a function using JSObjectMakeFunction. > 2. Add it as a property of the Window JSObjectRef. > 3. Call it using JSObjectCallAsFunction. JSObjectMakeFunction creates a JavaScript function *from* C. To just call a JS function (not create one), all you need to do is get the function object (most likely JSObjectGetProperty() on the global object) and then call it with JSObjectCallAsFunction(). -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Documenting common null pointer errors
2009/8/12 Adam Barth : > This is now up on the site: > > http://webkit.org/coding/major-objects.html > > It's not linked from anywhere yet. It might be a good idea for a > couple of folks to look at it. It reflects my understanding of how > things work, which might well be wrong. Ok, it's ASCII art, but hopefully a graphical version would make it more clear which object actually has the pointer to the other object. Or if they always have the connected object pointer on both ends of the relation, it would be nice to mention that in the description. -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ 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
2009/8/26 Simon Hausmann : > Hi fellow WebKit contributors! > > Currently the Qt port of WebKit merely provides an API to deal with rendering > web content, and as such our interface to the underlying JavaScriptCore engine > is minimal. > > We, the team of Qt developers at Nokia and INdT, would like to add a C++ Qt > API to JavaScriptCore as well, to allow application developers to for example > embed the JavaScriptCore engine into their applications. > > We want to give developers the ability to introspect the environment, inject > custom classes and call functions using a C++ API that uses Qt types and has a > Qt-ish feel to it. While binding Qt objects to JS is certainly a nice feature, I'd really like to see the JSC API supported as well. There are already many projects that enable ice-cool stuff through the JSC API (eg. Seed and our D-Bus Bridge) and the only missing piece in getting them to work as-is for QtWebKit is to get the JS Context. It would be a shame if QtWebKit projects would be missing out all that coolness just because the JSC API isn't Qt-ish enough to expose. It's not like every project will start to carry two implementations. -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch and SVN
2010/4/15 Dirk Pranke : > On Wed, Apr 14, 2010 at 2:13 PM, Eric Seidel wrote: >> Question: Do SVN users wish to have webkit-patch be >> current-working-directory aware? > [snip] >> The propose change will make webkit-patch inconsistent between VCS >> tools, but consistent with the users choice of SVN vs. Git. Is this >> SVN users desired behavior? > > I will surprise myself here and say that webkit-patch should do things > "the SVN way" when using SVN and "the Git way" when using Git. > Normally I am in favor of having VCS wrappers paper over the > differences between systems, but from experience I can say that when > using SVN I often have multiple changes in flight in a single > checkout, whereas Git makes that very difficult. How so? You can stage or commit single files or directories, even a single chunk of the changes within a file if you use the interactive add. git diff also can show changes in a single file or directory, git log can show the changelog for single file or directory... All you need to do is to give the file or directory on the command line, separated with -- in case there is (possibility of) a clash with a symbolic commit name (tag or branch). > Since this means you > can't get "the SVN way" using Git, it would mean that we'd have to use > "the Git way" when using SVN, which would remove useful functionality > and, as Geoffrey Garen point out, make submitting via SVN > substantially slower to boot. Given the above, I believe it would be quite possible to make the git part of the script cwd-aware too. -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The SquirrelFish Cometh
2008/5/18 Maciej Stachowiak <[EMAIL PROTECTED]>: > So we started SquirrelFish, an incremental rewrite of JavaScriptCore's > execution logic to convert it into a state-of-the art bytecode VM. > Most of this work has been done on a branch of the public SVN > repository, to avoid destabilizing the trunk. We are now very close to > finishing off the last few blockers. There will be a formal > announcement to the general public when we are ready, including > performance data and more details about the internals. But for now I > wanted to let WebKit insiders know that it is coming. Nice! Since it's just an "engine" rewrite, it won't mean any (public) API changes for JavaScriptCore right? > We are also at the point where we could use testing help to verify > that SquirrelFish can handle the real-world web. If anyone would like > to help test, and is willing to get their hands a bit dirty, check out > <http://svn.webkit.org/repository/webkit/squirrelfish>. Just to make it obvious for anyone trying to check out the branch, the URL above misses the branches dir. The correct URL is http://svn.webkit.org/repository/webkit/branches/squirrelfish/ -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ImageDiff tool for gtk platform
2008/5/23 Mark Rowe <[EMAIL PROTECTED]>: > > On 22/05/2008, at 07:24, S Venkata Udai Kiran wrote: > >> Hi all, >> I was trying to understand how the Layout tests are being done in >> Webkit. I went through the perl code 'run-webkit-tests' and found that >> the script is using a tool name ImageDiff >> (WebKit/WebKitBuild/Release/Programs/ImageDiff) .But I could not 'find' >> that tool in WebKit folder. As I understand that ImageDiff tool is >> necessary to do a pixel level diff for test images generated.I am >> looking at running individual tests using a small shell script rather >> running all the tests at once. this will help me to know the underlying >> things. Please help. > > ImageDiff is currently only implemented for Mac and Windows. It's not > needed to run the standard regression tests. Pixel test results will differ > between platforms and software versions, so there is a lot of manual work > involved in verifying results when bringing up pixel results on a new > platform. Focusing on text-only and render tree tests would provide much > better bang for your buck than pixel test results. That's very true. However, cairo aims at constant quality across output targets and has a similar utility in it's testing suite to verify that: http://gitweb.freedesktop.org/?p=cairo;a=tree;h=4bcc292bc335525f804db83f002692fb42a7b7c7;hb=8efb103600e9c034f8652f495d390d6a4178061e;f=test/pdiff So assuming that the layout code produces identical output on all platforms, testing cairo -backed platforms (gtk, win32...) for pixel-perfectness might make sense. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ 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
2008/6/9 ying lcs <[EMAIL PROTECTED]>: > no. I am not using a Proxy. i am able to load mail.google.com using > Firefox on the same linux environment. I think you might be experiencing the same as the reporter of this bug: https://bugs.webkit.org/show_bug.cgi?id=19146 There is a work-around that you can try out, mentioned in comment 2. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit/GTK+ and N810
2008/7/22 Afonso Costa <[EMAIL PROTECTED]>: > Hi all, Hi! > I'd like to do some tests using WebKit/GTK+ in my N810. I've built it using > some information listed here [1] and here [2]. > > Fortunately I got to build it in my Scratchbox environment and I've > installed it in my N810. But when I open http://www.gtk.org in GtkLauncher, > for my surprise, I get this result [3]. When I open the same site in my > desktop Linux, I can get other different result [4]. It's missing a blue > background... > > Am I missing anything in my build process? Is there other patch related to > ARM? I'm configuring WebKit with: configure --enable-video --with-hildon. > I've already tested it with --disable-xslt, but I didn't get any success. Judging by the symptoms, you are hitting the same issue we had and that took quite some debugging to figure out. The autotools build checks for the flex tool, but doesn't ensure it's the required version so the fact that Scratchbox has 2.5.31 and not 2.5.33 is not deemed as a problem. However, although 2.5.31 generates code that builds just fine, some bugs or other changes in that code affect the CSS parsing so that things just don't work right. For example, looking at http://www.w3schools.com/CSS/css_colors.asp should show most of the colors as black if you are hitting the same bug that we had. There are two ways to fix this, one is upgrading the scratchbox-core from http://scratchbox.org/~jhakala/unofficial/ to version 1.0.11~200805291240 (there is no official release yet with newer flex) and the other is to compile a newer flex yourself. Sources are available from here: http://flex.sourceforge.net/ -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit/GTK+ and N810
2008/7/23 Afonso Costa <[EMAIL PROTECTED]>: > Hi Kalle, > > I upgraded flex in my scratchbox environment and now GtkLauncher is able to > open www.gtk.org in right way. I compiled flex version 2.3.35 and I replaced > the old version (/scratchbox/tools/bin/flex) by this one. > > Maybe put this information on http://maemo.webkit.org/ would be very helpful > for other people, wouldn't be? Well, flex .33 *is* in the dependency lists... ;) Rather than repeating that, I'd rather see configure.ac checking for the flex version. I'm not sure how portable the configure script is supposed to be, but for example here is an example of how to check the version when common unix tools (sed, awk) are available: https://svn.apache.org/repos/asf/quetzalcoatl/mod_python/trunk/configure.in Any comments from Alp regarding this? I can cook up a patch if using sed & awk (or just sed) is ok... -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit/GTK+ and N810
2008/8/1 Afonso Costa <[EMAIL PROTECTED]>: > Hi Kalle, > > On Fri, Aug 1, 2008 at 4:47 AM, Kalle Vahlman <[EMAIL PROTECTED]> > wrote: >> >> 2008/7/23 Afonso Costa <[EMAIL PROTECTED]>: >> > Hi Kalle, >> > >> > I upgraded flex in my scratchbox environment and now GtkLauncher is able >> > to >> > open www.gtk.org in right way. I compiled flex version 2.3.35 and I >> > replaced >> > the old version (/scratchbox/tools/bin/flex) by this one. >> > >> > Maybe put this information on http://maemo.webkit.org/ would be very >> > helpful >> > for other people, wouldn't be? >> >> Well, flex .33 *is* in the dependency lists... ;) > > Yeah, in my first attempt I installed this version but I didn't know that > was necessary to replace the scratchbox's flex version or install other > updated scratchbox version. This information was too helpful for me and I > think it would be helpful for other people as well. True. > Anyway, it is already registered in webkit-devel archives ;) I created a bug (with a patch) too: https://bugs.webkit.org/show_bug.cgi?id=20253 -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Request for comments
2008/8/14 Jack Wootton <[EMAIL PROTECTED]>: > I think perhaps this depends on how you choose to categorise what has > (not) happened to the s60 webkit port. I choose to view it at a > company granularity, here's why: It is the same company, the same > legal entity, the same policies, same guidelines, same work ethics > etc. If you actually believe that, you probably don't know the big corporate world too well. > While you no doubt feel it counter productive to tackle the s60 > webkit issues now, and it may be so in the short time, I have little > doubt that it will be just as counter productive long term, if they > are ignored. > > For a quick gain from Nokia, you are advocating Nokia's behaviour > toward the open source community who wish to use s60 webkit. You are > communicating that it is OK for Nokia to leave a mainline broken for a > year, to provide little documentation, almost zero community support > and absolutely no communication regarding future development. It's not really uncommon that the original author of an open source project leaves it. I know I've done it. Nobody has approached me by claimimg that I was somehow obligated to continue maintenance, let alone prohibiting me from contributing to another project because of it! I'm not saying Nokia has handled the S60 port well (I've heard otherwise), but certainly they are within their rights in not maintaing open sourced code[1]. Blackmailing them with empty threats about unrelated contributions is hardly going to buy you better support in any case... [1] That's why the license says: 'THIS SOFTWARE IS PROVIDED [...] "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES [...]' -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Request for comments
2008/8/14 Jack Wootton <[EMAIL PROTECTED]>: > On Thu, Aug 14, 2008 at 11:02 AM, Kalle Vahlman <[EMAIL PROTECTED]> wrote: >> 2008/8/14 Jack Wootton <[EMAIL PROTECTED]>: >>> I think perhaps this depends on how you choose to categorise what has >>> (not) happened to the s60 webkit port. I choose to view it at a >>> company granularity, here's why: It is the same company, the same >>> legal entity, the same policies, same guidelines, same work ethics >>> etc. >> >> If you actually believe that, you probably don't know the big >> corporate world too well. > > I know it pretty well. I know it well enough to understand that most > multinationals try extremely hard to standardise corporate processes, > tools, methods and approaches. Multinationals really do expend a lot > of time and effort in standardisation of many areas of said > organisation. Emphasis on _try_. ;) >> I'm not saying Nokia has handled the S60 port well (I've heard >> otherwise), but certainly they are within their rights in not >> maintaing open sourced code[1]. Blackmailing them with empty threats >> about unrelated contributions is hardly going to buy you better >> support in any case... > > Er..., blackmailing? Who said anything about blackmailing? Could you > point out where any blackmailing occurred? > Er..., threats? Who said anything about threats? Could you point out > where any threats occurred? You said: "Before Nokia can submit anything back to the WebKit community they'll have to:" [list of things like apologies etc] Sounds like threatening to refuse contributions to me, but you might of course mean "I hope that nokia would..." with that statemen. > I think you've got a little carried away here. You did too with hijacking this thread for ranting ;) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Extending WebKit JavaScript support
2008/11/13 Christian Dywan <[EMAIL PROTECTED]>: > Am Thu, 13 Nov 2008 01:34:17 -0800 (PST) > schrieb Iulian <[EMAIL PROTECTED]>: > >> I would like to extend JavaScript support with new objects (similar >> to Math, RegEx, String). Because these objects needs to interact with >> the OS (Linux) i cannot use JavaScript Object support to create these >> objects from JavaScript. >> I studied WebKit documentation but i don't know what should i do to >> add such an object. > > Heya, > > if Linux means Gtk, something like the following will do: > >JSClassDefinition js_class_def = kJSClassDefinitionEmpty; >js_class_def.className = g_strdup (name); >js_class_def.getPropertyNames = _js_class_get_property_names_cb; >js_class_def.hasProperty = _js_class_has_property_cb; >js_class_def.getProperty = _js_class_get_property_cb; >js_class_def.setProperty = _js_class_set_property_cb; >JSClassRef js_class = JSClassCreate (&js_class_def); >JSObjectRef js_object = JSObjectMake (js_context, js_class, >instance); > > Where you need to implement the underscore prefixed functions yourself. > > For more pointers I suggest the public headers of JavaScriptCore, the > two test programmes, and the file gjs.c in the Midori source tree. The > API of javascript is pretty intuitive once you got the hang of it. This might be of interest too as an example, it creates a DBus JS object with two methods (which are implemented in C) and few (static) properties for JS application usage: http://sandbox.movial.com/gitweb?p=browser-dbus-bridge.git;a=blob;f=jscorebus/jscorebus.c#l392 -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SquirrelFish in WebKitGtk
2008/11/28 ying lcs <[EMAIL PROTECTED]>: > If I get the source for WebKitGtk, using the documentation described here: > > http://live.gnome.org/WebKitGtk > > Does it have SquirrelFish? Yes, it will. All ports share the same JavaScript engine code. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ 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
2008/11/29 ying lcs <[EMAIL PROTECTED]>: > >From this entry, it said Inspector is ported to Webkit/GTK > http://blog.kov.eti.br/?p=25 > > Can you please tell me how can I enable it? There's a patch attached to the original bug that enables the inspector for the GtkLauncher test program: https://bugs.webkit.org/show_bug.cgi?id=19392 That should give an idea what needs to be done in a client application to enable the inspector. On a related note, I just submitted a patch for an API to enable client applications to start the inspector (eg. from a keyboard shortcut): https://bugs.webkit.org/show_bug.cgi?id=22551 -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ 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
2008/11/30 ying lcs <[EMAIL PROTECTED]>: > On Sat, Nov 29, 2008 at 3:29 AM, Kalle Vahlman <[EMAIL PROTECTED]> wrote: >> 2008/11/29 ying lcs <[EMAIL PROTECTED]>: >>> >From this entry, it said Inspector is ported to Webkit/GTK >>> http://blog.kov.eti.br/?p=25 >>> >>> Can you please tell me how can I enable it? >> >> There's a patch attached to the original bug that enables the >> inspector for the GtkLauncher test program: >> >> https://bugs.webkit.org/show_bug.cgi?id=19392 >> >> That should give an idea what needs to be done in a client application >> to enable the inspector. >> >> On a related note, I just submitted a patch for an API to enable >> client applications to start the inspector (eg. from a keyboard >> shortcut): >> >> https://bugs.webkit.org/show_bug.cgi?id=22551 >> >> -- >> Kalle Vahlman, [EMAIL PROTECTED] >> Powered by http://movial.fi >> Interesting stuff at http://sandbox.movial.com >> See also http://syslog.movial.fi >> > Thank you , Kalle, > > So should I apply this patch : > https://bugs.webkit.org/attachment.cgi?id=24756 from the 1st bug that > you mentioned? No, that's already included in the WebKit code, the one I meant is https://bugs.webkit.org/attachment.cgi?id=22365 which only adds the support to GtkLauncher. > And then https://bugs.webkit.org/attachment.cgi?id=25590 from the 2nd > bug that you mentioned? No, you don't need this one. You will get the context menu item with the patch mentioned above, this one only adds a button to launch the inspector from the client toolbar (and it depends on the other patch in that bug). Sorry for the confusion :) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ 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
2008/12/1 ying lcs <[EMAIL PROTECTED]>: > 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? I think the GTK+ port tries to find the inspector files only from the install location currently, so if you didn't run 'make install', that would explain why it doesn't find them. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ 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
2008/12/10 Gustavo Noronha Silva <[EMAIL PROTECTED]>: > 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? ...and file a bug about the configuration/build system allowing the unit tests to be built when GTK+ version < 2.14. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit runtime image compression
2008/12/15 Paul Pedriana : > Thanks. I didn't mean to suggest something like this should be part of > WebKit. I was wondering if anybody had any experience they could share that > might help me or others come to faster conclusions about the usefulness or > feasibility of this in custom ports. If I implement the formats below I can > report back on my results and possibly donate to ports that might be > interested in this, such as OWB. Well, for CE device oriented applications the feasibility of the compression really comes down to the balance between memory consumption and CPU speed. If you compress, you will (potentially) spend lots of time decompressing the images but can view bigger pages. If you don't, it will be faster but limit the amount of in-memory images. That said, Federico Mena Quintero did some research about this few years ago: http://www.gnome.org/~federico/news-2005-11.html#moz-images I'm not sure if that idea has realized itself in any project though. At least lazy decompression of images based on visibility on the screen sounds like a great idea (eg. when you read only 25% of a very long page with images, like planets), I wonder if anyone is doing that already in browser engines? -- Kalle Vahlman, z...@iki.fi Powered by http://movial.fi Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
