Re: [Development] qt5.8 : configuring the use of PulseAudio and/or GStreamer

2017-01-19 Thread Thiago Macieira 
On quinta-feira, 19 de janeiro de 2017 22:20:59 PST René J. V. Bertin wrote:
> I've also been talking since the beginning about configure. Sorry about the
> confusion.

There are two configure scripts: one in the top-level and one in qtbase. Please 
be clear which one you mean.

-- 
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] invokeMethod() with function pointers

2017-01-19 Thread Thiago Macieira 
On quinta-feira, 19 de janeiro de 2017 16:18:30 PST Grégoire Barbier wrote:
> > The return value is interesting still.
> 
> With lambdas the return value itself can be replaced with a captured
> reference, isn't it ?
> Anyway it's still convenient to have it when calling plain old methods
> rather than lambdas.

Hmm... right. What I had proposed:

   QMetaObject::invokeMethod(object, [=]() { 
doSomething(); return something; },
Qt::BlockingQueuedConnection,
Q_RETURN_ARG(foo));

Could be rewritten as:

   QMetaObject::invokeMethod(object, [=, ]() { 
doSomething(); foo = something; },
Qt::BlockingQueuedConnection);

And that allows us to drop the Q_RETURN_ARG ugliness. That's much better.

PS: should we invert the argument order and have the connection type appear 
before the functor? I find it ugly to have a lambda in the middle of a 
parameter list.

-- 
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] invokeMethod() with function pointers

2017-01-19 Thread Thiago Macieira 
On quinta-feira, 19 de janeiro de 2017 12:24:34 PST Benjamin TERRIER wrote:
> template 
> static typename
> QtPrivate::QEnableIf::IsPointerToMemberFun
> ction && QtPrivate::FunctionPointer::ArgumentCount == -1
>   && !std::is_same::value, bool>::Type
>   invokeMethod(QObject *object, Func function)
> 
> to QMetaObject breaks existing code and the auto tests in particular.
> 
> In tst_qmetaobject.cpp there is this test:
> QVERIFY(!QMetaObject::invokeMethod(, 0));
> because the new overload of invokeMethod() gets called this lead to
> compilation error instead
> of just returning false at run-time.
> 
> To solve the issue one must add an explicit cast like so:
> QVERIFY(!QMetaObject::invokeMethod(, (const char*)0));
> Note that casting to "char *" does not solve the issue.

Because it's a template, so the template when Func = char* matches better than 
the overload with const char*. I assume that using nullptr without casting 
also breaks, correct?

> Is this "source break"  acceptable (it might be looking at "Source
> break policy for function overloads" discussion and quip 6) and the
> autotests should be fixed?

>From what you explained, this will not affect the case when the pointer is a 
const char *, so neither

const char *func = "deleteLater";
QMetaObject::invokeMethod(, func);

nor

const char *func = nullptr;
QMetaObject::invokeMethod(, func);

will stop compiling. So if you add an overload taking a non-const char* (and 
its unit test), we also catch the even more dubious code:

char func[] = "deleteLater";
QMetaObject::invokeMethod(, func);

The only case that would break would be for a constant null pointer literal, 
which in my opinion is acceptable, since it should never happen in real code.

-- 
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] Texture image loading library

2017-01-19 Thread Thiago Macieira 
On quinta-feira, 19 de janeiro de 2017 22:22:17 PST Oswald Buddenhagen wrote:
> the central "regular" image loaders are in qtgui, and the "elementary"
> (6MeB of sources ...) opengl support is nowadays also in qtgui, so it
> seems quite plausible to put the texture loaders there as well.

And eventually they could become public API.

-- 
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] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations

2017-01-19 Thread Thiago Macieira 
On quinta-feira, 19 de janeiro de 2017 22:15:38 PST Oswald Buddenhagen wrote:
> the other solution would be not building host tools at all when doing a
> cross-build, but requiring a native build as a basis.

Long-term we should do that, but we need to support the current way for a 
couple of releases.

-- 
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] Texture image loading library

2017-01-19 Thread Oswald Buddenhagen 
On Thu, Jan 19, 2017 at 07:34:08PM +0100, Giuseppe D'Angelo wrote:
> Nonetheless, since such loaders would be useful in more than one place
> (qtbase, qtdeclarative, qt3d) I think that the best place for them would
> be a new private library in qtimageformats.
> 
you can't put it there if qtbase is to use it.

the central "regular" image loaders are in qtgui, and the "elementary"
(6MeB of sources ...) opengl support is nowadays also in qtgui, so it
seems quite plausible to put the texture loaders there as well.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qt5.8 : configuring the use of PulseAudio and/or GStreamer

2017-01-19 Thread René J . V . Bertin 
Oswald Buddenhagen wrote:


> that doesn't matter. the point is that you talked about qtbase.pro
> instead of the top-level project qt.pro.

I've also been talking since the beginning about configure. Sorry about the 
confusion. That configure script is obfuscated enough to make it very easy to 
miss the fact it chdirs back up 1 level (after the toplevel configure script 
did 
the opposite).

The fact remains that it's qmake that complains about unknown arguments when I 
pass -no-pulseaudio and/or -no-gstreamer.

Let me try to reformulate the question: what options must I pass to
../qt-everywhere-opensource-src-5.8.0-rc/configure so that the qtmultimedia 
component is built without pulseaudio and gstreamer support? I'm doing an out-
of-source build, hence the "../qt*".

R.

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

Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations

2017-01-19 Thread Oswald Buddenhagen 
On Thu, Jan 19, 2017 at 02:31:29PM +0100, René J.V. Bertin wrote:
> Thiago Macieira wrote:
> > It must be the lack of -Wl,--enable-new-dtags: can you confirm qtdiag has it
> > but lrelease doesn't?
> 
> Yep. Neither do lupdate and lconvert, but linguist does (they come all from 
> the linguist dir). A bit as if the non-gui utilities were left out.
> 
that's actually mostly what is happening. the host tools don't use new
dtags, because there is no configure test for that.
of course, it's actually a bit silly that this is also done for native
builds, so https://codereview.qt-project.org/182877 .
cross-builds will of course continue to suffer from this problem.
also, when you look in the patch's context, you'll notice that
reduce_relocations and separate_debug_info should actually also be
covered by the conditions, but i didn't want to make the coverage even
worse.

one way to fix this would be duplicating all configure tests that apply
to host tools. we actually already do that for a few things.

the other solution would be not building host tools at all when doing a
cross-build, but requiring a native build as a basis.
qmake in the 5.8 branch is actually at a point where this would be kinda
easy to implement.
however, doing that would be a rather significant break in how things
are handled from the user perspective, so we may want to hold this off
until we do something as drastic as switching build systems altogether,
at least when this build mode becomes the only option.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qt5.8 : configuring the use of PulseAudio and/or GStreamer

2017-01-19 Thread Oswald Buddenhagen 
On Thu, Jan 19, 2017 at 02:40:43PM +0100, René J. V. Bertin wrote:
> Oswald Buddenhagen wrote:
> > that's what happens when you don't follow my instructions. i explicitly
> > told you that the configure approach is for a top-level (qt5.git) build.
> 
> You wrote
> >> if you're doing a top-level build, you just pass it to configure.
> 
> I'm doing a top-level build, not from qt5.git but from the qt-everywhere-
> opensource-5.8.0RC tarball. So I'm using a traditional configure/make/make 
> install cycle.
> 
that doesn't matter. the point is that you talked about qtbase.pro
instead of the top-level project qt.pro.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Texture image loading library

2017-01-19 Thread Giuseppe D'Angelo 
Hi,
As part of some ongoing work I'd like to add some private classes in Qt
to deal with loading of texture files.

Texture files (.dds, .ktx, etc.) are somehow different from ordinary
image files. Not only they store image data in GPU-oriented formats
(that don't require any decoding on the CPU), but a given texture can be
made by multiple images arranged in a complex way (e.g. _one_ texture
can be an array of images with multiple mipmap levels). As such, we
currently don't have APIs to deal with them, and QImage is definitely
the wrong class.

Nonetheless, since such loaders would be useful in more than one place
(qtbase, qtdeclarative, qt3d) I think that the best place for them would
be a new private library in qtimageformats.

(Most of the code in question would actually be extracted from qt3d,
which already has DDS/KTX loaders.)

What do you think?

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QWidget::setWindowState(Qt::WindowStates) vs QWindow::setWindowState(Qt::WindowState)

2017-01-19 Thread Thomas Søndergaard 
Hi Bo

On Thu, 19 Jan 2017 at 09.25, Bo Thorsen  wrote:

> Hej Thomas
>

> [...]


> You ask for the best way to proceed: As usual with issues like this, you
>
> should enter a bug in the bug tracker.
>
I did, QTBUG-57882. See original post.

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

Re: [Development] platform theme plugins and automatically loading them

2017-01-19 Thread René J . V . Bertin 
René J.V. Bertin wrote:


> 2. Has anything changed in the related functionality between Qt 5.7.1 and Qt
> 5.8.0? I'm currently testing 5.8.0RC installed into a "destroot" (make install

Something has indeed changed here, but apparently already in 5.7.1 . I have a 
version check in my platform theme plugin that prints a warning in case of a 
mismatch, and that always worked. AFAICR I didn't have to rebuild the plugin 
before it loaded when I upgraded from 5.6.2 to 5.7.1, I just got that warning 
every time I started an application.

The lack of feedback is quite annoying actually, esp. since other plugins load 
without problem.

R.

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

Re: [Development] invokeMethod() with function pointers

2017-01-19 Thread Grégoire Barbier 

Le 17/01/2017 à 18:11, Thiago Macieira a écrit :

Em terça-feira, 17 de janeiro de 2017, às 11:21:56 PST, Grégoire Barbier
escreveu:

And maybe lambdas too, if there was a way to choose the thread/eventloop
in which we want the lambda to be executed (but christmas was a few
weeks ago, I should not dream ;-)).


If we do this, it should be possible to write:

QMetaObject::invokeMethod(object, [=]() {
doSomething(); return something; },
Qt::BlockingQueuedConnection,
Q_RETURN_ARG(foo));


It would be great. :-)


Since we have lambdas and std::bind, I don't see the point of supporting
passing arguments.


Agree.


The return value is interesting still.


With lambdas the return value itself can be replaced with a captured 
reference, isn't it ?
Anyway it's still convenient to have it when calling plain old methods 
rather than lambdas.



--
Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] platform theme plugins and automatically loading them

2017-01-19 Thread René J . V . Bertin 
René J.V. Bertin wrote:

> 1. Does the platform theme plugin have to be called "kde", i.e. have the same
> name as the internal "kde" theme? IOW, are platform theme plugins matched to
> existing internal plugins themes (to extend them), or are they "plugins that
> provide additional platform themes"? In yet other words, can I call the
> platform theme plugin "cocoa" and leave out the internal QKdeTheme?

To answer this myself: No, the plugin doesn't need to be called "kde" and the 
built-in kde theme from qgenericunixthemes isn't required.
And yes, if I rename the platform theme plugin to "cocoa" it is always loaded 
without need to add an extra theme name in qcocoaintegration.

R.

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

Re: [Development] qt5.8 : configuring the use of PulseAudio and/or GStreamer

2017-01-19 Thread René J . V . Bertin 
Oswald Buddenhagen wrote:


>> 
> that's what happens when you don't follow my instructions. i explicitly
> told you that the configure approach is for a top-level (qt5.git) build.

You wrote
>> if you're doing a top-level build, you just pass it to configure.

I'm doing a top-level build, not from qt5.git but from the qt-everywhere-
opensource-5.8.0RC tarball. So I'm using a traditional configure/make/make 
install cycle.

When you pass -no-pulseaudio to configure it ends up in the "qmake [...] -- 
"[...] -no-pulseaudio [...]" commandline. 

>> > otherwise, "qmake  -- -no-pulseaudio -no-gstreamer".
>> > 
> *this* is the syntax you need. _in qtmultimedia_.

Yeah, I got that, but it's not what I'm doing.

R.

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

Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations

2017-01-19 Thread René J . V . Bertin 
Thiago Macieira wrote:

> Can you compare the command-lines used to link those two applications? What's
> different?

qtdiag:

g++ -m64 -Wl,--gc-sections -Wl,--enable-new-dtags -Wl,-z,origin 
-Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib 
-Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath,/opt/local/lib 
-Wl,-rpath,/opt/local/libexec/qt5/lib -o ../../bin/qtdiag .obj/main.o 
.obj/qtdiag.o   -L/usr/X11R6/lib64 -L/path/to/build/qtbase/lib -lQt5Gui 
-lQt5Network -lQt5Core -lGL -lpthread

lrelease, lupdate & lconvert:

g++ -m64 -Wl,--gc-sections -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib 
-Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib 
-Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -o 
../../../bin/lrelease .obj/main.o .obj/numerus.o .obj/translator.o 
.obj/translatormessage.o .obj/qm.o .obj/qph.o .obj/po.o .obj/ts.o .obj/xliff.o 
.obj/ioutils.o .obj/qmakevfs.o .obj/proitems.o .obj/qmakeglobals.o 
.obj/qmakeparser.o .obj/qmakeevaluator.o .obj/qmakebuiltins.o 
.obj/profileevaluator.o .obj/qrc_proparser.o   -L/path/to/build/qtbase/lib 
-lQt5Xml -lQt5Core -lpthread 
g++ -m64 -Wl,--gc-sections -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib 
-Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib 
-Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -o 
../../../bin/lupdate .obj/numerus.o .obj/translator.o .obj/translatormessage.o 
.obj/qm.o .obj/qph.o .obj/po.o .obj/ts.o .obj/xliff.o .obj/ioutils.o 
.obj/qmakevfs.o .obj/proitems.o .obj/qmakeglobals.o .obj/qmakeparser.o 
.obj/qmakeevaluator.o .obj/qmakebuiltins.o .obj/profileevaluator.o .obj/main.o 
.obj/merge.o .obj/simtexth.o .obj/cpp.o .obj/java.o .obj/ui.o 
.obj/qdeclarative.o .obj/qrc_proparser.o   -L/path/to/build/qtdeclarative/lib 
-lQt5QmlDevTools -L/path/to/build/qtbase/lib -lQt5Xml -lQt5Core -lpthread 
g++ -m64 -Wl,--gc-sections -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../lib 
-Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib 
-Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/qt5/lib -o 
../../../bin/lconvert .obj/main.o .obj/numerus.o .obj/translator.o 
.obj/translatormessage.o .obj/qm.o .obj/qph.o .obj/po.o .obj/ts.o .obj/xliff.o  
 -L/path/to/build/qtbase/lib -lQt5Xml -lQt5Core -lpthread

linguist:

g++ -m64 -Wl,--gc-sections -Wl,--enable-new-dtags -Wl,-z,origin 
-Wl,-rpath,\$ORIGIN/../lib -Wl,-rpath,/opt/local/lib 
-Wl,-rpath,/opt/local/libexec/qt5/lib -Wl,-rpath,/opt/local/lib 
-Wl,-rpath,/opt/local/libexec/qt5/lib 
-Wl,-rpath-link,/path/to/build/qttools/lib -o ../../../bin/linguist 
.obj/numerus.o .obj/translator.o .obj/translatormessage.o .obj/qm.o .obj/qph.o 
.obj/po.o .obj/ts.o .obj/xliff.o .obj/batchtranslationdialog.o 
.obj/errorsview.o .obj/finddialog.o .obj/formpreviewview.o .obj/globals.o 
.obj/main.o .obj/mainwindow.o .obj/messageeditor.o .obj/messageeditorwidgets.o 
.obj/messagehighlighter.o .obj/messagemodel.o .obj/phrasebookbox.o 
.obj/phrase.o .obj/phrasemodel.o .obj/phraseview.o .obj/printout.o 
.obj/recentfiles.o .obj/sourcecodeview.o .obj/statistics.o 
.obj/translatedialog.o .obj/translationsettingsdialog.o .obj/simtexth.o 
.obj/qrc_linguist.o .obj/moc_batchtranslationdialog.o .obj/moc_errorsview.o 
.obj/moc_finddialog.o .obj/moc_formpreviewview.o .obj/moc_mainwindo
 w.o .obj/moc_messageeditor.o .obj/moc_messageeditorwidgets.o 
.obj/moc_messagehighlighter.o .obj/moc_messagemodel.o .obj/moc_phrasebookbox.o 
.obj/moc_phrase.o .obj/moc_phrasemodel.o .obj/moc_phraseview.o 
.obj/moc_recentfiles.o .obj/moc_sourcecodeview.o .obj/moc_statistics.o 
.obj/moc_translatedialog.o .obj/moc_translationsettingsdialog.o   
-L/usr/X11R6/lib64 -L/path/to/build/qttools/lib -lQt5UiTools 
-L/path/to/build/qtbase/lib -lQt5PrintSupport -lQt5Widgets -lQt5Gui -lQt5Xml 
-lQt5Core -lGL -lpthread

> It must be the lack of -Wl,--enable-new-dtags: can you confirm qtdiag has it
> but lrelease doesn't?

Yep. Neither do lupdate and lconvert, but linguist does (they come all from the 
linguist dir). A bit as if the non-gui utilities were left out.

Oswald Buddenhagen wrote:

> On Wed, Jan 18, 2017 at 03:53:20PM -0800, Thiago Macieira wrote:
>> Ossi: what was the conclusion of our discussion on --enable-new-dtags?
>> 
> it's now enabled by default. i have no clue why it would be wrong for
> lrelease. a more complete survey of the executables in the qt build dir
> would be necessary (check for stale files!).

This was in a fresh build-from-scratch, so stale files should be unlikely.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] invokeMethod() with function pointers

2017-01-19 Thread Benjamin TERRIER 
Hi,

I've got an issue.

Adding

template 
static typename
QtPrivate::QEnableIf::IsPointerToMemberFunction
  && QtPrivate::FunctionPointer::ArgumentCount == -1
  && !std::is_same::value, bool>::Type
  invokeMethod(QObject *object, Func function)

to QMetaObject breaks existing code and the auto tests in particular.

In tst_qmetaobject.cpp there is this test:
QVERIFY(!QMetaObject::invokeMethod(, 0));
because the new overload of invokeMethod() gets called this lead to
compilation error instead
of just returning false at run-time.

To solve the issue one must add an explicit cast like so:
QVERIFY(!QMetaObject::invokeMethod(, (const char*)0));
Note that casting to "char *" does not solve the issue.

Is this "source break"  acceptable (it might be looking at "Source
break policy for function overloads" discussion and quip 6) and the
autotests should be fixed?
Or should another solution be found (Thiago proposed to use a
different name in QTBUG-37253)?

Thanks

Regards,

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

Re: [Development] qt5.8 : configuring the use of PulseAudio and/or GStreamer

2017-01-19 Thread Oswald Buddenhagen 
On Wed, Jan 18, 2017 at 04:57:34PM +0100, René J. V. Bertin wrote:
> Oswald Buddenhagen wrote:
> > if you're doing a top-level build, you just pass it to configure.
> 
> But how? Configure now yells on -no-pulseaudio :
> >> ERROR: Unknown command line option '-no-pulseaudio'.
> 
> And that error comes from qmake, possibly because it doesn't know this option 
> when processing qtbase.pro (and that it needs to be instructed to cache 
> unknown 
> options for later perusal)?
> 
> I tried "-no-feature-pulseaudio", which leads to
> ERROR: Enabling/Disabling unknown feature 'pulseaudio'.
> 
> (at least the option is recognised).
> 
that's what happens when you don't follow my instructions. i explicitly
told you that the configure approach is for a top-level (qt5.git) build.

> > otherwise, "qmake  -- -no-pulseaudio -no-gstreamer".
> > 
*this* is the syntax you need. _in qtmultimedia_.

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

[Development] platform theme plugins and automatically loading them

2017-01-19 Thread René J . V . Bertin 
Hi,

You probably remember that I have been tinkering with an auto-loading Qt 
platform theme plugin for Mac, an adapted version of the KDE platform theme 
plugin from "Plasma Integration". The goal is to provide support for KDE's 
colour & icon palettes plus font role definitions (from kdeglobals) which can 
then be used with any application style including the native macintosh style. 
This makes KF5 applications look a lot more how they are designed to look.

The set-up is simple:
- QCocoaIntegration::themeNames() returns an additional theme name, "kde"
- the build system is patched so that qgenericunixservices and 
qgenericunixthemes are built and included, so a "kde" theme is defined at that 
level
- the platform theme plugin declares a 
org.qt-project.Qt.QPA.QPlatformThemeFactoryInterface.5.1 key "kde".
- the platform theme plugin main class has a proxy to the native theme, created 
as

nativeTheme = 
QGuiApplicationPrivate::platformIntegration()->createPlatformTheme(QGuiApplication::platformName());

That proxy is used whenever the theme plugin doesn't completely override the 
native theme choice.

I'm not really sure exactly why, but this works, nor to what extent 
QGenericUnixThemes are required (I've tried following the execution flow but 
the lldb debugger tends to get stuck).

Two questions: 

1. Does the platform theme plugin have to be called "kde", i.e. have the same 
name as the internal "kde" theme? IOW, are platform theme plugins matched to 
existing internal plugins themes (to extend them), or are they "plugins that 
provide additional platform themes"? In yet other words, can I call the 
platform theme plugin "cocoa" and leave out the internal QKdeTheme?

2. Has anything changed in the related functionality between Qt 5.7.1 and Qt 
5.8.0? I'm currently testing 5.8.0RC installed into a "destroot" (make install 
INSTALL_ROOT=foo) using DYLD_FRAMEWORK_PATH and QT_PLUGIN_PATH set 
appropriately. Existing apps run fine and even use my installed application 
styles, but apparently NOT the platform theme plugin. I thus get the KDE look 
and feel, but all platform integration is lost that is normally provided 
through the native theme proxy. My platform theme binary is loaded from what I 
can tell, but its entry point isn't called. Is that to be expected?

Thanks,
René


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

Re: [Development] Qt5.8/Linux : -version `Qt_5' not found error running lrelease building qttranslations

2017-01-19 Thread Oswald Buddenhagen 
On Wed, Jan 18, 2017 at 03:53:20PM -0800, Thiago Macieira wrote:
> Ossi: what was the conclusion of our discussion on --enable-new-dtags?
> 
it's now enabled by default. i have no clue why it would be wrong for
lrelease. a more complete survey of the executables in the qt build dir
would be necessary (check for stale files!).

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

Re: [Development] QWidget::setWindowState(Qt::WindowStates) vs QWindow::setWindowState(Qt::WindowState)

2017-01-19 Thread Bo Thorsen 

Hej Thomas,

Please don't take silence as some indication that people are offended. I 
just think you found a corner case that no one has considered and do not 
consider one way or the other.


You ask for the best way to proceed: As usual with issues like this, you 
should enter a bug in the bug tracker.


Bo Thorsen.

Den 18-01-2017 kl. 16:21 skrev Thomas Søndergaard:

I hope my previous email wasn't offensive or downright stupid; no one
has replied. I certainly meant no disrespect. While I'm waiting for a
response, let me throw a specific proposal out there.

First, I assume the correct solution is to extend QWindow and
QPlatformWindow so they can deal with compound states such as
Qt::WindowMaximized|Qt::WindowMinimized, just like QWidget can. Since
QWindow::setWindowState(Qt::WindowState) and Qt::WindowState
QWindow::windowState() cannot be modified, I'm thinking of adding

Qt::WindowStates QWindow::fullWindowState() const;
void QWindow::setFullWindowState(Qt::WindowStates);

and

Qt::WindowStates QPlatformWindow::fullWindowState() const;
void QPlatformWindow::setFullWindowState(Qt::WindowStates);

The existing QWindow::windowState() would then be implemented using the
effectiveState() function from qwidget.cpp (I'd move it over)

I can experiment with these changes and implementing them in the xcb and
windows platform plugins, but early feedback is always great, so I avoid
wasting time.

Thanks for making Qt

Thomas




On 17 January 2017 at 21:37, Thomas Søndergaard
> wrote:

Hi,

I'm looking at the Qt code with intention to fix it so this code

QWidget widget;
widget.setWindowState(Qt::WindowMaximized);
widget.showMinized();

will show the window iconified and when the user (or program)
unminimize the window it pops up maximized. This is currently not
possible (QTBUG-57882 ).

I've been trying to read the Qt code and it seems to me the problem
is that QWindow::setWindowState(Qt::WindowState) and
QPlatformWindow::setWindowState(Qt::WindowState) only take a
Qt::WindowState argument not a Qt::WindowStates argument. This seems
to make it impossible to set the correct state on the windows-system
window.

Is this intentional or a known issue?

I would be happy to get suggestions for how this is best fixed.



Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development