Re: [Development] Qt for NaCl port
On 11 Jun 2014, at 14:53, Thiago Macieira wrote: > Em ter 10 jun 2014, às 21:33:44, Daiwei Li escreveu: >> Hello, >> >> I'm investigating porting an existing C++/QML application to Google >> NaCl, and I found that Qt had attempted a port a couple years ago: >> http://qt-project.org/wiki/Qt_for_Google_Native_Client. From what I've >> found online, it looks like it's unsupported and no longer works with >> the latest Qt and NaCl toolchain. Does anyone know the history of this >> project and why it was abandoned? If I can revive the port to work >> with the latest NaCl toolchain, is that something that could be >> considered for upstreaming? > > Yes, it would be welcome in the Qt Project. The reason why it didn't go any > further is that people probably got busy and did not have the time to > continue > supporting it. In addition to lack of time: - Native client was still a moving target. For example, the binaries I produced back then no longer work on the current Chrome. - Qt moved in a “non-portable” direction with V8. Now the outlook is better: We can run V4 in interpreted mode. The native client project is more stable. (There are still bugs: the most recent PNaCl toolchain miscompiles QtBase and produces a binary which won’t verify as safe.) Further details from the previous porting effort (with a "from memory” disclaimer): - There is a basic platform plugin with raster graphics and event handling support. - QtWidgets and Graphics View worked. - Qt Quick 1/raster/JavaScriptCore worked. - Fonts are tricky: There’s a pepper API to enumerate system fonts, measure and render text but there’s no way to access the font files. As a workaround I bundled qtbase/lib/fonts/ . > >> I'm currently only looking into porting what's necessary for getting >> the QML engine/renderer running. Can anyone familiar with NaCl think >> of any showstoppers for this subset of Qt functionality? It looks like >> NaCl has an implementation of OpenGLES2, and worst case, if it doesn't >> support JIT, V4 has an interpreter option. > > You probably will find problems in the QtNetwork library and, thus, Qt > Quick's > remote file and XML HTTP Requests support. - Networking: I implemented a QNetworkAccessManager backend which meant that Qt Quick apps could do requests back to the host (following the same-origin policy). This was sufficient for loading Qt Quick modules and resources, but not for our flickr example. It was kind of interesting to find web apps _more_ restricted than native apps in this regard, when “openness” us normally one of the virtues associated with the web platform. These days there is CORS and JSONP so perhaps the situation is better. - OpenGL: I ran into trouble resolving the OpenGL API functions. Unlike other platforms, NaCl’s gl2.h -provides the OpenGL API using macros: #define glActiveTexture GLES2_GET_FUN(ActiveTexture) qopenglfunctions.h promptly undefines them: // Undefine any macros from GLEW, qopenglextensions_p.h, etc that // may interfere with the definition of QOpenGLFunctions. #undef glActiveTexture - V4/JIT. NaCl has support for JIT, in the form of nacl_dyncode_create/modify/delete. I’m not sure how (if at all) this works with PNaCl. In any case we can start out with with interpreted V4. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for NaCl port
Em qui 12 jun 2014, às 19:08:58, Daiwei Li escreveu: > > It doesn't matter. > > If you're volunteering to support it, it will be supported. If you're not > > volunteering to support and no one else volunteers, it won't be. > > Are you volunteering? > > Potentially, but I would require help, at least for getting continuous > integration running unit/integration > tests on Native Client and preventing future changes from breaking the port. The Qt Project needs to decide whether it wants that platform as part of the CI. Then Digia needs to chime in if they have the ability to do it, since they're running the Qt Project CI. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for NaCl port
> > It doesn't matter. > If you're volunteering to support it, it will be supported. If you're not > volunteering to support and no one else volunteers, it won't be. > Are you volunteering? Potentially, but I would require help, at least for getting continuous integration running unit/integration tests on Native Client and preventing future changes from breaking the port. On Thu, Jun 12, 2014 at 6:32 PM, Thiago Macieira wrote: > Em qui 12 jun 2014, às 18:25:20, Daiwei Li escreveu: > > > Yes, it would be welcome in the Qt Project. The reason why it didn't go > > > any > > > further is that people probably got busy and did not have the time to > > > continue > > > supporting it. > > > > I see. What about maintenance? This may not be the right place to ask > this, > > but is > > Native Client a platform that Digia would want to support officially > > eventually? > > It doesn't matter. > > If you're volunteering to support it, it will be supported. If you're not > volunteering to support and no one else volunteers, it won't be. > > Are you volunteering? > > > You probably will find problems in the QtNetwork library and, thus, Qt > > > > > Quick's > > > remote file and XML HTTP Requests support. > > > > Ok, I'll be on the lookout for problems there. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for NaCl port
Em qui 12 jun 2014, às 18:25:20, Daiwei Li escreveu: > > Yes, it would be welcome in the Qt Project. The reason why it didn't go > > any > > further is that people probably got busy and did not have the time to > > continue > > supporting it. > > I see. What about maintenance? This may not be the right place to ask this, > but is > Native Client a platform that Digia would want to support officially > eventually? It doesn't matter. If you're volunteering to support it, it will be supported. If you're not volunteering to support and no one else volunteers, it won't be. Are you volunteering? > You probably will find problems in the QtNetwork library and, thus, Qt > > > Quick's > > remote file and XML HTTP Requests support. > > Ok, I'll be on the lookout for problems there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for NaCl port
> > Yes, it would be welcome in the Qt Project. The reason why it didn't go any > further is that people probably got busy and did not have the time to > continue > supporting it. I see. What about maintenance? This may not be the right place to ask this, but is Native Client a platform that Digia would want to support officially eventually? You probably will find problems in the QtNetwork library and, thus, Qt > Quick's > remote file and XML HTTP Requests support. Ok, I'll be on the lookout for problems there. Best, Daiwei On Wed, Jun 11, 2014 at 5:53 AM, Thiago Macieira wrote: > Em ter 10 jun 2014, às 21:33:44, Daiwei Li escreveu: > > Hello, > > > > I'm investigating porting an existing C++/QML application to Google > > NaCl, and I found that Qt had attempted a port a couple years ago: > > http://qt-project.org/wiki/Qt_for_Google_Native_Client. From what I've > > found online, it looks like it's unsupported and no longer works with > > the latest Qt and NaCl toolchain. Does anyone know the history of this > > project and why it was abandoned? If I can revive the port to work > > with the latest NaCl toolchain, is that something that could be > > considered for upstreaming? > > Yes, it would be welcome in the Qt Project. The reason why it didn't go any > further is that people probably got busy and did not have the time to > continue > supporting it. > > > I'm currently only looking into porting what's necessary for getting > > the QML engine/renderer running. Can anyone familiar with NaCl think > > of any showstoppers for this subset of Qt functionality? It looks like > > NaCl has an implementation of OpenGLES2, and worst case, if it doesn't > > support JIT, V4 has an interpreter option. > > You probably will find problems in the QtNetwork library and, thus, Qt > Quick's > remote file and XML HTTP Requests support. > > > Does anyone have experience with the Qt for NaCl project? Any > > tips/advice/considerations on attempting such a port? > > > > I sent a similar e-mail to interest a while ago and got a response > > about QmlWeb. While it looks interesting, it unfortunately won't work > > with C++ QObjects. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for NaCl port
Em ter 10 jun 2014, às 21:33:44, Daiwei Li escreveu: > Hello, > > I'm investigating porting an existing C++/QML application to Google > NaCl, and I found that Qt had attempted a port a couple years ago: > http://qt-project.org/wiki/Qt_for_Google_Native_Client. From what I've > found online, it looks like it's unsupported and no longer works with > the latest Qt and NaCl toolchain. Does anyone know the history of this > project and why it was abandoned? If I can revive the port to work > with the latest NaCl toolchain, is that something that could be > considered for upstreaming? Yes, it would be welcome in the Qt Project. The reason why it didn't go any further is that people probably got busy and did not have the time to continue supporting it. > I'm currently only looking into porting what's necessary for getting > the QML engine/renderer running. Can anyone familiar with NaCl think > of any showstoppers for this subset of Qt functionality? It looks like > NaCl has an implementation of OpenGLES2, and worst case, if it doesn't > support JIT, V4 has an interpreter option. You probably will find problems in the QtNetwork library and, thus, Qt Quick's remote file and XML HTTP Requests support. > Does anyone have experience with the Qt for NaCl project? Any > tips/advice/considerations on attempting such a port? > > I sent a similar e-mail to interest a while ago and got a response > about QmlWeb. While it looks interesting, it unfortunately won't work > with C++ QObjects. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt for NaCl port
Hello, I'm investigating porting an existing C++/QML application to Google NaCl, and I found that Qt had attempted a port a couple years ago: http://qt-project.org/wiki/Qt_for_Google_Native_Client. From what I've found online, it looks like it's unsupported and no longer works with the latest Qt and NaCl toolchain. Does anyone know the history of this project and why it was abandoned? If I can revive the port to work with the latest NaCl toolchain, is that something that could be considered for upstreaming? I'm currently only looking into porting what's necessary for getting the QML engine/renderer running. Can anyone familiar with NaCl think of any showstoppers for this subset of Qt functionality? It looks like NaCl has an implementation of OpenGLES2, and worst case, if it doesn't support JIT, V4 has an interpreter option. Does anyone have experience with the Qt for NaCl project? Any tips/advice/considerations on attempting such a port? I sent a similar e-mail to interest a while ago and got a response about QmlWeb. While it looks interesting, it unfortunately won't work with C++ QObjects. Thanks, Daiwei ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
