Re: [webkit-dev] IDL generation: [Conditional=XXX] vs. #if defined(ENABLE_XXX)
03.07.2011, в 11:24, Patrick Gansterer написал(а): I see three possible solutions: 1) Always generate all IDL files. 2) Change all [Conditional=XXX] to #if define(ENABLE_XXX). 3) Add the correct #if ENABLE(XXX) around the header includes. (1) used to be the preferred solution. It's so much nicer to not have tons of #if checks at the top of cpp files. IMHO it's not so important how _generated_ files look, because we shouldn't need to open them. I'm not sure if we're talking about the same thing here. The idea was that all generated files were always created, so there were no #if guards around includes in .cpp files - generated or not. Code generator works perfectly fine for that, so it's unclear to me if there is anything to fix in it. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JavaScriptCore on Android
Hi, I am trying to use JavaScriptCore in my Android application. I build JavaScriptCore as a static library and I developed a JNI layer to access JSC methods. All my classes compile fine, but at the end of the build process (i guess in the linker action) i got some errors like undefined reference to JSStringCreateWithUTF8CString. I was not able to correctly link my code with the JavaScriptCore static library. As far as I know I only need to specify LOCAL_STATIC_LIBRARIES := libjs in my Android.mk file. Is that correctly? Besides that I´ve already tried to specify link flags through the LOCAL_LDFLAGS and LOCAL_CPPFLAGS variables in my Android.mk file. How can I use JavaScriptCore as a static library in my Android application? Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] phonon and qtwebkit modifications to make it work
Hello,
I use an older version of qtwebkit, but no modification have been done in the
phonon backend part ( MediaPlayerPrivatePhonon.h, MediaPlayerPrivatePhonon.cpp)
. I made the following modification to allow HTML5 audio/video make it work
with phonon:
MediaPlayerPrivate::MediaPlayerPrivate(MediaPlayer* player)
: m_player(player)
, m_networkState(MediaPlayer::Empty)
, m_readyState(MediaPlayer::HaveNothing)
, m_mediaObject(new MediaObject())
, m_videoWidget(new VideoWidget(0))
, m_audioOutput(new AudioOutput())
, m_isVisible(false)
{
QTimer::singleShot(100, m_videoWidget, SLOT(show())); //let event loop
bread
// this is needed for m_videoWidget to catch setting attribute
// Qt::WA_DontShowOnScreen . m_videoWidget will not be shown on the screen
// but will act as a shown widget. This is needed to be rendered in a
QPainter.
m_firstTime = true;
}
/ /Only this method is called when clicking on the play/pause button, so the
// logic for play/pause must be implemented here
// webkit calls this function evrey time page loads, so first call is discarded.
void MediaPlayerPrivate::pause()
{
if (m_firstTime)
{
m_firstTime = false;
return;
}
if ( m_mediaObject-state() != Phonon::PlayingState )
{
if (m_mediaObject-currentTime() == m_mediaObject-totalTime())
{
LOG(Media, MediaPlayerPrivatePhonon::seek(0));
m_mediaObject-seek(0);
}
LOG(Media, MediaPlayerPrivatePhonon::play());
m_mediaObject-play();
}
else
{
LOG(Media, MediaPlayerPrivatePhonon::pause());
m_mediaObject-pause();
}
}
Without this modifications, HTML5 video doesn't work with phonon. What do you
think about ?
Thank you,
Mihai Adrian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
Hi all, sorry for not jumping into this thread earlier. I'll try to summarise my opinions succinctly in order to avoid extra noise. On Fri, Jun 24, 2011 at 7:27 PM, Ojan Vafai wrote: Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Unfortunately there is no formal use cases document, rather they were discussed as the API was developed (it has changed a lot since the first input was made available). In general this API shines compared to the available input types when you need either multiple people at once and/or multiple fields from given contacts. If you want to email 50 people, you're better off selecting them in a contacts picker than typing them in, even assuming friendly completion from input type=email (note that since the contacts picker that the API expects can be platform-provided, existing structure you may have in your contacts DB such as groups can be used directly). Likewise if you need to enter email and snail addresses for someone, you're better off picking that person once rather than having to select them multiple times with a completion helper (or typing everything in, of course). Based on this we can see use cases such as: • Send printed invites to a whole bunch of people to a party/wedding/whatever, needing full name and address. • Set up a Web VoIP conference and invite people over email. • Load a bunch of friends and get a map of which locations in town are closest to all (as in http://old.isokron.com/ but with more than two people). That's just what's at the top of my head tonight, but I think it gives an idea. As for input type=contacts, it's something that was considered but it's less straightforward than one would hope as there are several aspects to consider. The first is that it would need to expose an input type=contacts.contacts API in the same way as input type=file.files does. That's pretty simple — in fact that API is 90% of what's in the Contacts API. But then it needs to contribute to form submission. They idea of just attaching a vCard as a file for each contact was floated but it feels like a cop out. It also requires browsers to correctly generate vCard content (since even if they had access to the raw vCard they'd need to keep only the relevant fields). It's not the end of the world but, as usual, there are kinks. Another option is to use one of the conventions for multi-model forms so that if you have input type=contacts name=mycontacts you generate mycontacts[email], mycontacts[name], etc. or possibly (in the multiple case) mycontacts[0][email], mycontacts[0][name], etc. There's no single convention for that though, so it doesn't feel overly satisfying. Then there's fallback. New input types work best when it makes sense for them to fallback to input type=text (the default): email, url, tel, search, dates all work that way. For contacts, it really doesn't work all that well and you'd' have to hide it (or provide some heavy lifting). There's also the issue of what you show since it's a visible control. You need a button to trigger the contacts dialog of course, but you also need something to provide the user with visual feedback that they've selected a set of contacts. This can be anything from a You have selected 47 contacts string to actually displaying each contact and its relevant fields. Wherever you fall in that spectrum, you then have the issue of how to style it. Speaking personally, I'd very much rather not spend the next five years finding yet more CSS workarounds to get a new form control to work in a dazzling system*browser matrix. None of this is insurmountable but it's extra work for benefits that aren't immediately obvious (to me). What's more, it's work that seems to involve a solid potential for interop snafus. The Contacts API is actually designed to operate in the same way as input type=file.click() does, but sans the form-related issues. It only triggers on valid auto-invocation events and asynchronously provides a list of objects (the fields of which are tailored to match the request). The idea behind the approach is that if ever there is a will to make this into a form input type, then the code path to support the API on top of it should be as short as calling input type=contacts accept-fields='name email url'.click(). So, put another way, what the spec doesn't tell you is that it *is* input type=contacts, with the same security model and the same platform integration, but trimmed down to include what you need for the use cases and to exclude what you don't for the headaches. -- Robin Berjon - http://berjon.com/ - @robinberjon
[webkit-dev] QNX vs SA_RESTART from pthread
Hi there. Someone sent me a patch to fix the build on QNX, but the patch disables SA_RESTART from pthread on that platform (besides a few other things). I don't know what are the implications of blindily disabling SA_RESTART and would like someone with experience on that area of the code to tell if it's OK or not to do it. The guy who sent the patch said the basic features are working, but I don't have a QNX environment to test. Support for QNX on QtWebKit is a community best effort. Bug with patch waiting for review here: https://bugs.webkit.org/show_bug.cgi?id=63717 Thanks, - Ademar -- Ademar de Souza Reis Jr. ademar.r...@openbossa.org Nokia Institute of Technology ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] phonon and qtwebkit modifications to make it work
Please file a bug and attach a patch for review. We cannot accept code via
the mailing list for legal reasons.
Adam
On Mon, Jul 4, 2011 at 11:04 AM, Mihai Adrian mihaiadria...@yahoo.comwrote:
Hello,
I use an older version of qtwebkit, but no modification have been done in
the phonon backend part ( MediaPlayerPrivatePhonon.h,
MediaPlayerPrivatePhonon.cpp) . I made the following modification to allow
HTML5 audio/video make it work with phonon:
MediaPlayerPrivate::MediaPlayerPrivate(MediaPlayer* player)
: m_player(player)
, m_networkState(MediaPlayer::Empty)
, m_readyState(MediaPlayer::HaveNothing)
, m_mediaObject(new MediaObject())
, m_videoWidget(new VideoWidget(0))
, m_audioOutput(new AudioOutput())
, m_isVisible(false)
{
QTimer::singleShot(100, m_videoWidget, SLOT(show())); //let event loop
bread
// this is needed for m_videoWidget to catch setting attribute
// Qt::WA_DontShowOnScreen . m_videoWidget will not be shown on the
screen
// but will act as a shown widget. This is needed to be rendered in a
QPainter.
m_firstTime = true;
}
/ /Only this method is called when clicking on the play/pause button, so
the
// logic for play/pause must be implemented here
// webkit calls this function evrey time page loads, so first call is
discarded.
void MediaPlayerPrivate::pause()
{
if (m_firstTime)
{
m_firstTime = false;
return;
}
if ( m_mediaObject-state() != Phonon::PlayingState )
{
if (m_mediaObject-currentTime() == m_mediaObject-totalTime())
{
LOG(Media, MediaPlayerPrivatePhonon::seek(0));
m_mediaObject-seek(0);
}
LOG(Media, MediaPlayerPrivatePhonon::play());
m_mediaObject-play();
}
else
{
LOG(Media, MediaPlayerPrivatePhonon::pause());
m_mediaObject-pause();
}
}
Without this modifications, HTML5 video doesn't work with phonon. What do
you think about ?
Thank you,
Mihai Adrian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] phonon and qtwebkit modifications to make it work
Hiya,
The Phonon implementation of MediaPlayer was removed from WebKit in
https://bugs.webkit.org/show_bug.cgi?id=63448
-Kling
On Mon, Jul 4, 2011 at 8:04 PM, Mihai Adrian mihaiadria...@yahoo.comwrote:
Hello,
I use an older version of qtwebkit, but no modification have been done in
the phonon backend part ( MediaPlayerPrivatePhonon.h,
MediaPlayerPrivatePhonon.cpp) . I made the following modification to allow
HTML5 audio/video make it work with phonon:
MediaPlayerPrivate::MediaPlayerPrivate(MediaPlayer* player)
: m_player(player)
, m_networkState(MediaPlayer::Empty)
, m_readyState(MediaPlayer::HaveNothing)
, m_mediaObject(new MediaObject())
, m_videoWidget(new VideoWidget(0))
, m_audioOutput(new AudioOutput())
, m_isVisible(false)
{
QTimer::singleShot(100, m_videoWidget, SLOT(show())); //let event loop
bread
// this is needed for m_videoWidget to catch setting attribute
// Qt::WA_DontShowOnScreen . m_videoWidget will not be shown on the
screen
// but will act as a shown widget. This is needed to be rendered in a
QPainter.
m_firstTime = true;
}
/ /Only this method is called when clicking on the play/pause button, so
the
// logic for play/pause must be implemented here
// webkit calls this function evrey time page loads, so first call is
discarded.
void MediaPlayerPrivate::pause()
{
if (m_firstTime)
{
m_firstTime = false;
return;
}
if ( m_mediaObject-state() != Phonon::PlayingState )
{
if (m_mediaObject-currentTime() == m_mediaObject-totalTime())
{
LOG(Media, MediaPlayerPrivatePhonon::seek(0));
m_mediaObject-seek(0);
}
LOG(Media, MediaPlayerPrivatePhonon::play());
m_mediaObject-play();
}
else
{
LOG(Media, MediaPlayerPrivatePhonon::pause());
m_mediaObject-pause();
}
}
Without this modifications, HTML5 video doesn't work with phonon. What do
you think about ?
Thank you,
Mihai Adrian
___
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] Ceasing development of current QtWebKit API's
(Cross-posting from webkit-qt since it may interest people who are not on that list.) Hello QtWebKit users and contributors! Now that the Nokia N9 has finally been announced, many of you probably know it ships with a WebKit2-based browser. Following this we've started discussing where to go with WebKit in Qt5, and it has become quite clear that the future of QtWebKit is with WebKit2. We at Nokia are planning to cease work on the WebKit1-based API (QWebView, QGraphicsWebView and friends.) We know there are many people using this API, and would therefore like to know if someone is interested in stepping up and taking over the maintenance. This task would include hosting a buildbot instance for build.webkit.org, and the responsibility for keeping unit tests (Qt/WebKit1 API tests) and layout tests passing. The rough plan is to ship the last version of our WebKit1 API's with Qt 5.0. We don't intend to update the code after this initial release, as its sole purpose is to ease migration, similarly to Qt3Support in Qt4. This will possibly be a forward-ported version QtWebKit 2.2 (as opposed to a snapshot of WebKit trunk at the time of Qt 5.0 branching.) If a new maintainer can be found, it's our hope that they could keep delivering new versions of the Qt/WebKit1 API's to the Qt 5.x series. -Kling (on behalf of the Nokia QtWebKit teams) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
