Re: [Development] [ANNOUNCE] DaD's House! (Beta)

2015-09-11 Thread Curtis Mitch 
> -Original Message-
> From: Konstantin Podsvirov [mailto:konstan...@podsvirov.pro]
> Sent: Thursday, 10 September 2015 4:13 PM
> To: Curtis Mitch ; development@qt-
> project.org; CMake Developers 
> Subject: Re: [Development] [ANNOUNCE] DaD's House! (Beta)
> 
> 10.09.2015, 16:41, "Curtis Mitch" :
> >> From: Konstantin Podsvirov [mailto:konstan...@podsvirov.pro]
> >>
> >> By clicking on the link, you will be able to get the installer is the
> >> same as the QtSDK and a few clicks to get the binaries, libraries and
> >> linking headers of any of the participating modules.
> >
> > But what am I even clicking the link for? What service does this thing
> provide?
> 
> For example, You want to create a very large and useful application which
> uses a lot of dependencies.
> And you want to deploy it on the Windows.
> 
> You go to the site:
> 
> http://dad.podsvirov.pro
> 
> Download appropriate to your development environment setup.
> 
> Quickly and easily install any required dependent modules and receives a
> development environment, local deployment and testing.
> 
> When you're finished designing, you can create compatible with this
> environment the installer to install your application on other machines.
> 
> Main technologies:
> * Development languages: C, C++ (Qt, Qml, Quick) and other
> * Project management: CMake, but can use other
> * Creating installer based QtIFW (CMake allows you to automate the process
> of creating an installer).
> 
> I answered Your question?

Yes, thank you. :) Hopefully that description saves others the trouble as well.

> Regards,
> Konstantin Podsvirov
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.5.0 build issue on OS X (10.9): OpenGL libraries

2015-09-11 Thread Oswald Buddenhagen 
On Fri, Sep 11, 2015 at 04:19:52PM +0200, René J.V. Bertin wrote:
> On Friday September 11 2015 14:17:23 René J.V. Bertin wrote:
> 
> > How can I find out why QMAKE_LIBS_OPENGL gets set to -lGL in qmodule.pri, 
> > or why the library is tested in opengldesktop.pro?
> 
> Answer 1: by sinking teeth where I'd rather not sink them
> Answer 2: configure shouldn't use pkg-config when building for the Cocoa QPA, 
> i.o.w, 
> 
> if [ "$QT_QPA_DEFAULT_PLATFORM" = "cocoa" ] || [ "$QT_QPA_DEFAULT_PLATFORM" = 
> "" -a "$XPLATFORM_MAC" = "yes" ] then compileTest should be used. I cannot 
> see any reason to justify using pkg-config to find the OpenGL frameworks, 
> just as it's obvious that it should be used to find the GLX library when 
> building the XCB plugin.
> 
> Should I file a bug report or is this enough?
> 
there are some related reports already.

but what you really should do, is contribute a patch. ;)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebEngine unbundled of third-party libraries on Linux

2015-09-11 Thread Allan Sandfeld Jensen 
On Friday 11 September 2015, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Tuesday 11 August 2015 23:17:31 Allan Sandfeld Jensen wrote:
> > Hello Qt
> > 
> > QtWebEngine and Chromium in the Qt 5.6 branch have been patched to allow
> > linking with system libraries on Linux instead of bundled libraries. For
> > most libraries the system library will be used if development files are
> > detected on the system. ICU and FFMPEG however defaults to using the
> > bundled copies and requires using qmake arguments to configure to use
> > system versions. The required arguments are listed in qmake configure
> > status (just delete .qmake.cache and run qmake to run the configure step
> > again). Note that for FFMPEG, the libav libraries from the FFMPEG project
> > are required, the libraries from the libav project does not work.
> > 
> > I have so far only tested on Debian. If more people could test it we
> > could also get better detection and set proper minimal versions.
> > 
> > If you are a packager and more is required before QtWebEngine can be
> > packaged on your distribution, please let me know.
> 
> [Exactly one month later...]
> 
> I'll try to check this during the weekend. I'm terribly sorry for not doing
> it sooner, but life gets in the middle too much lately :-/
> 
> Do you think it would be possible to build it against Qt 5.5? Just for
> testing purposes, of course.

Yes it does, and I intend to to keep it that way :D It is not a supported 
configuration, but to the extend it is possible, I will try to make Qt 
WebEngine build with one version older Qt. With QtWebKit I kept it working 
with two version older, but WebEngine moves much faster and has a tight 
integration with the scene graph, so let's see. 

Btw. If you know the people packaging Chromium, you could point them my way, 
we could probably share patches.

Best regards
`Allan

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWaylandCompositor public api

2015-09-11 Thread Paul Olav Tvete 
On Wednesday 9. September 2015 18.13.55 Thomas Senyk wrote:
> How stable/done is this? Is it worth while trying to port an existing
> compositor to the new API?

It's in active API review, and we're still tearing down some of the classes. 
Right now, we are removing absolute positions from the API, since that concept 
does not really exist in Wayland. We also know that we have to change the 
input classes.

> If it's stable enough to count an effort like that between "API
> review" and "actual forward port" then I'd give it a try in 2-3 weeks
> (unless something comes up -- as always).

In 2-3 weeks, the API should be a lot more stable. That would be the ideal 
time to give feedback.

> What's assumed ETA for moving wip-compositor-api to default API? 5.6? 5.7?

We will have a tech preview in the 5.6 timeframe, but we will integrate the 
changes to the dev branch, and not to the 5.6 branch.

- Paul
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Qt 5.5.1 branching ongoing

2015-09-11 Thread Oswald Buddenhagen 
On Fri, Sep 04, 2015 at 07:50:39AM +, Heikkinen Jani wrote:
> '5.5.1' branch is now available, please start using it for the changes 
> targeted to Qt5.5.1 release. We will merge '5.5' branch to '5.5.1' Friday 
> 11th September so there should be enough time to finalize ongoing changes in 
> '5.5'. All new changes for Qt5.5.1 should be done in '5.5.1' branch from now 
> on.
> 
the branching of 5.5.1 is now complete.
changes integrated into 5.5 are now 5.5.2 (or more probably 5.6) material.

> Target is to release Qt5.5.1 during September so please make sure all 
> blockers will be fixed as soon as possible. And please remember: Do not add 
> any nice to have -changes in anymore.
> 
> Best regards,
> Jani Heikkinen
> Release Manager | The Qt Company
> 
> The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland
> Email: jani.heikki...@theqtcompany.com | Mobile: + 358 50 48 73 735
> www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
> @Qtproject Facebook: www.facebook.com/qt
> 
> ___
> 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 5.5.0 build issue on OS X (10.9): OpenGL libraries

2015-09-11 Thread René J . V . Bertin 
On Friday September 11 2015 20:18:20 Oswald Buddenhagen wrote:

> > if [ "$QT_QPA_DEFAULT_PLATFORM" = "cocoa" ] || [ "$QT_QPA_DEFAULT_PLATFORM" 
> > = "" -a "$XPLATFORM_MAC" = "yes" ] then compileTest should be used. I 
> > cannot see any reason to justify using pkg-config to find the OpenGL 
> > frameworks, just as it's obvious that it should be used to find the GLX 
> > library when building the XCB plugin.
> > 
> > Should I file a bug report or is this enough?
> > 
> there are some related reports already.
> 
> but what you really should do, is contribute a patch. ;)

I actually already provided the patch ;) (but I guess I won't get out from 
doing a full-blown gerrit even for this...)

R
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5.5.0 build issue on OS X (10.9): OpenGL libraries

2015-09-11 Thread René J . V . Bertin 
Hi,

Another build issue on OS X: the build system picks up the wrong OpenGL 
library. This happens when the GLX libGL.dylib is present in the library path 
(e.g. when building under MacPorts), probably because QMAKE_LIBS_OPENGL 
contains -lGL .

With Qt 5.4 the GLX library wasn't found when building for XCB, but obviously 
it should be ignored when building the native, cocoa variant.

How can I find out why QMAKE_LIBS_OPENGL gets set to -lGL in qmodule.pri, or 
why the library is tested in opengldesktop.pro?

For reference, this is my current configure command:

%> configure -platform macx-clang -sdk macosx10.9 -prefix /opt/local 
-archdatadir /opt/local/libexec/qt5 -docdir /opt/local/share/doc/qt5 -headerdir 
/opt/local/include/qt5 -plugindir /opt/local/share/qt5/plugins -importdir 
/opt/local/share/qt5/imports -qmldir /opt/local/share/qt5/qml -datadir 
/opt/local/share/qt5 -libdir /opt/local/libexec/qt5/Library/Frameworks -bindir 
/opt/local/libexec/qt5/bin -libexecdir /opt/local/libexec/qt5/libexec 
-translationdir /opt/local/share/qt5/translations -sysconfdir 
/opt/local/etc/qt5 -examplesdir /Applications/MacPorts/Qt5/examples -testsdir 
/opt/local/share/qt5/tests -hostbindir /opt/local/libexec/qt5/bin -hostlibdir 
/opt/local/libexec/qt5/Library/Frameworks -hostdatadir /opt/local/share/qt5 -v 
-release -opensource -confirm-license -shared -force-pkg-config -no-pulseaudio 
-no-mtdev -system-harfbuzz -openssl-linked -no-xinput2 -no-xcb -no-xcb-xlib 
-no-libudev -no-egl -make libs -make tools -nomake examples -nomake tests 
-verbose -nis -cups -
 iconv -no-evdev -icu -fontconfig -no-pch -dbus-linked -glib -directfb 
-no-linuxfb -no-kms -no-use-gold-linker -framework -optimized-qmake 
-system-sqlite -no-sql-db2 -no-sql-ibase -no-sql-mysql -no-sql-oci -no-sql-odbc 
-no-sql-psql -no-sql-sqlite2 -no-sql-tds -no-openvg -force-debug-info -no-strip 
-no-separate-debug-info

R.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.5.0 build issue on OS X (10.9): OpenGL libraries

2015-09-11 Thread Hanspeter Niederstrasser 
On 9/11/2015 9:19 AM, René J.V. Bertin wrote:
> On Friday September 11 2015 14:17:23 René J.V. Bertin wrote:
>
>> How can I find out why QMAKE_LIBS_OPENGL gets set to -lGL in qmodule.pri, or 
>> why the library is tested in opengldesktop.pro?
>
> Answer 1: by sinking teeth where I'd rather not sink them
> Answer 2: configure shouldn't use pkg-config when building for the Cocoa QPA, 
> i.o.w,
>
> if [ "$QT_QPA_DEFAULT_PLATFORM" = "cocoa" ] || [ "$QT_QPA_DEFAULT_PLATFORM" = 
> "" -a "$XPLATFORM_MAC" = "yes" ] then compileTest should be used. I cannot 
> see any reason to justify using pkg-config to find the OpenGL frameworks, 
> just as it's obvious that it should be used to find the GLX library when 
> building the XCB plugin.
>
> Should I file a bug report or is this enough?

This is the bug report I previously filed on this:

https://bugreports.qt.io/browse/QTBUG-47146

It's definitely a problem caused by pkg-config if your pkg-config is set 
to search your X11 installation by default (using PKG_CONFIG_LIBDIR at 
least can override the default). A conditional that *doesn't* use 
pkg-config to find OpenGL on Cocoa would be very nice.

Hanspeter
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.5.0 build issue on OS X (10.9): OpenGL libraries

2015-09-11 Thread René J . V . Bertin 
On Friday September 11 2015 14:17:23 René J.V. Bertin wrote:

> How can I find out why QMAKE_LIBS_OPENGL gets set to -lGL in qmodule.pri, or 
> why the library is tested in opengldesktop.pro?

Answer 1: by sinking teeth where I'd rather not sink them
Answer 2: configure shouldn't use pkg-config when building for the Cocoa QPA, 
i.o.w, 

if [ "$QT_QPA_DEFAULT_PLATFORM" = "cocoa" ] || [ "$QT_QPA_DEFAULT_PLATFORM" = 
"" -a "$XPLATFORM_MAC" = "yes" ] then compileTest should be used. I cannot see 
any reason to justify using pkg-config to find the OpenGL frameworks, just as 
it's obvious that it should be used to find the GLX library when building the 
XCB plugin.

Should I file a bug report or is this enough?

R.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebEngine unbundled of third-party libraries on Linux

2015-09-11 Thread Lisandro Damián Nicanor Pérez Meyer 
On Tuesday 11 August 2015 23:17:31 Allan Sandfeld Jensen wrote:
> Hello Qt
> 
> QtWebEngine and Chromium in the Qt 5.6 branch have been patched to allow
> linking with system libraries on Linux instead of bundled libraries. For
> most libraries the system library will be used if development files are
> detected on the system. ICU and FFMPEG however defaults to using the
> bundled copies and requires using qmake arguments to configure to use
> system versions. The required arguments are listed in qmake configure
> status (just delete .qmake.cache and run qmake to run the configure step
> again). Note that for FFMPEG, the libav libraries from the FFMPEG project
> are required, the libraries from the libav project does not work.
> 
> I have so far only tested on Debian. If more people could test it we could
> also get better detection and set proper minimal versions.
> 
> If you are a packager and more is required before QtWebEngine can be
> packaged on your distribution, please let me know.

[Exactly one month later...]

I'll try to check this during the weekend. I'm terribly sorry for not doing it 
sooner, but life gets in the middle too much lately :-/

Do you think it would be possible to build it against Qt 5.5? Just for testing 
purposes, of course.

-- 
Hacer algo siempre te llevará más tiempo del que esperabas, incluso si
tienes en cuenta la ley de Hofstadter.
  Douglas Hofstadter
  http://mundogeek.net/archivos/2009/09/05/la-ley-de-hofstadter/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development