Re: [webkit-dev] How would one call a JavaScript function from C++ using WebKit?
Does anyone know what class/function I should use in WebKit to execute a JavaScript function from C++? KJS::JSObject::call invokes a function object as a function. You will need to retrieve the appendMessage function object from the global object in order to call it. If you're asking about API, not internal code, there's JSObjectCallAsFunction in the C API. I'm not sure how the GDK port of WebKit interacts with the C API, though. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Question about porting webkit
Hi all: Based on my understanding, the webcore of webkit using KHTML as its rendering engine, and KTHML is component from KDE/Qt, so is that means Apple's webkits can be only port to platform that support KDE/Qt? Another question is that I found both apple's webkit and Nokia's S60 webkits contains KWQ, I'm puzzled what role does this part play and what's the relationship beween KWQ and KHTML? thanks very much Best Regards, Yihua ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Question about porting webkit
I'll leave any discussion on the differences between WebKit and KHTML to other who know more about it than me. But no, WebKit is in no way tied to Qt, and there are active ports of WebKit from Mac to Qt, GDK (or GTK, or something), and the WX toolkit. Much of the design of the architecture of WebKit has changed over the last few years, and as part of this KWQ no longer exists. At a very high level WebKit now has 3 components * JavaScriptCore -- the javascript interpreter (obviously ;) ), more or less completely cross platform * WebCore -- The rendering and layout engine * WebKit -- Provides the system api JSC is basically crossplatform so i'm ignoring it Only WebCore and WebKit require substantial platform work. The WebKit component/module/thingy is the interface between JSC, WebCore, and the host platform, so by it's very nature is more or less entirely platform specific. As time goes by we're trying to reduce the size of WebKit down into a much thinner layer to make porting WebKit (the library) easier. WebCore is the really interesting bit, the majority of it is cross platform, however different platforms have different networking libraries, rendering libraries, etc. So we have a number of abstractions that wrap platform specific API, eg. PlatformMouseEvent (to wrpa mouse evevnts), DragData (that maps platform drag and drop information), and so on to varying levels. The rest of WebCore is then written in terms of those abstractions, so that is necessary to port webcore to another platofrm is to implement versions of those abstractions for the target paltform. (though that's a big all) You can see most of this at work in the WebCore/platform directory -- http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/platform I've probably made a few mistakes, but i don't doubt that other people will swoop in to correct any wild fallacies on my part... --Oliver On May 25, 2007, at 4:23 AM, Jin, Yihua wrote: Hi all: Based on my understanding, the webcore of webkit using KHTML as its rendering engine, and KTHML is component from KDE/Qt, so is that means Apple's webkits can be only port to platform that support KDE/Qt? Another question is that I found both apple's webkit and Nokia's S60 webkits contains KWQ, I'm puzzled what role does this part play and what's the relationship beween KWQ and KHTML? thanks very much Best Regards, Yihua ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Augmenting WebKit contextual menus for non-plugin content
Augmenting contextual menus really has nothing to do with plug-ins, so I'm not sure how the conversation ended up at plug-ins. :) Changing context menus is getting more into the realm of extensions. dave On May 25, 2007, at 4:15 PM, David Hyatt wrote: On May 25, 2007, at 4:07 PM, Nathan Duran wrote: (that QuickTime vs. PNG argument is pretty flimsy) when all it does is force Flimsy in what sense? If QuickTime (or any plugin) can take over PNG, then PNG image support when the object tag is used would effectively be broken. Suddenly all sorts of built-in browser functionality breaks. Web sites would break. The end user would have no real understanding of what was going wrong or how to fix it. Plug-ins should not be allowed to break your browser. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Augmenting WebKit contextual menus for non-plugin content
On May 25, 2007, at 4:18 PM, David Hyatt wrote: Augmenting contextual menus really has nothing to do with plug-ins, so I'm not sure how the conversation ended up at plug-ins. :) Changing context menus is getting more into the realm of extensions. Yeah, I don't get how it got there either. If you want to change context menus, then in a custom WebKit app, you can use the UI delegate: webView:contextMenuItemsForElement:defaultMenuItems: If you want to do it from web content, I think your only option right now is to handle the contextmenu event and pop up a custom menu by hand. In the future, HTML is going to get better support for customizing context menus from web content. Here's the current HTML5 draft: http://www.whatwg.org/specs/web-apps/current-work/#context. If you need a feature like this sooner rather than later, contact the appropriate WWDR representative. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Augmenting WebKit contextual menus for non-plugin content
On May 25, 2007, at 4:07 PM, Nathan Duran wrote: I'm on record as accepting of, but not agreeing with, this argument ;) Well it makes at least as much sense as the Contextual Menu Manager API's continued existence does :) It strikes me as rather silly to protest giving free reign to plugin developers in the interest of maintaining some territorial sense of purity (that QuickTime vs. PNG argument is pretty flimsy) when all it does is force said developers to craft even dirtier solutions--such as the rampant abuse of Input Managers. It's not just sense of purity - the browser makes assumptions that certain types will be handled directly and counts on this to give a consistent user experience and for its internal workings. Pretty much all browsers reserve their built-in types. Many plugins mistakenly claim built-in types, since other browsers ignore that, and content would break in Safari if we don't do it right. Anyway, if you are trying to change context menus from a custom WebKit app you don't have to use any hacks, there is an API for it (WebUIDelegate). Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Augmenting WebKit contextual menus for non-plugin content
Flimsy in what sense? If QuickTime (or any plugin) can take over PNG, then PNG image support when the object tag is used would effectively be broken. Suddenly all sorts of built-in browser functionality breaks. Web sites would break. The end user would have no real understanding of what was going wrong or how to fix it. Flimsy in the sense that QuickTime should have simply stopped registering itself to handle that MIME type rather than making it impossible for ANY plugin to register itself for any MIME type. That's like trying to keep fleas off your dog by draining all the blood out of it. There is absolutely nothing you can possibly do to stop people from installing stupid things on their computers. The best you can hope to accomplish is to provide your developers with simple, clearly documented methods to accomplish their goals in order to reduce the risk of catastrophic failure. Augmenting contextual menus really has nothing to do with plug-ins, so I'm not sure how the conversation ended up at plug-ins. :) Changing context menus is getting more into the realm of extensions. Semantics are fun, aren't they? How about if we invent a third category and call them add-ons just to delineate some more imaginary boundaries that keep those bug reports in someone else's inbox? I get the fact that it doesn't work the way I want it to and probably never will. That doesn't mean that this is an ideal situation which I have no right to find objectionable. Plug-ins should not be allowed to break your browser. Right, only Apple employees should be allowed to do that. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
