Re: [Interest] QPointF in QMouseEvent

[Rutledge Shawn]

On 21 Sep 2015, at 03:50, Brad Pepers  wrote:

> I was wondering if anyone knows why QMouseEvent::pos() returns a QPoint but 
> QMouseEvent::localPos() returns a QPointF.  When do you ever have fractional 
> pixels?  When would pos() and localPos() be different?

We need to stop using integer coordinates in QtQuick.  IMO those cases where 
QPoint or int are still used for such purposes are anachronisms.

Practically every embedded system big enough to run Qt has an FPU nowadays.  So 
it is more wasteful to convert numbers back and forth between int and float 
formats than to use floats everywhere.

In standard Javascript, numbers are always floating-point.  So we might as well 
be consistent with that in QML as much as possible.

In OpenGL, rendering coordinates are always floating-point.  So you may ask for 
integer coordinate positioning and sizing, but there will be a transformation 
matrix applied during rendering anyway.

Using floating point numbers does permit subpixel precision whenever that’s 
useful.  We cannot say for sure that no mouse or touchscreen will ever provide 
subpixel resolution.  With Wacom tablets, subpixel resolution is already quite 
important to artists, because they are trying to replicate the experience of 
drawing or painting with physical media.

Using real-world units helps takes the design philosophy beyond “pixel-perfect 
design” and into the modern era of truly scalable graphics, on displays with 
such high resolution that you can’t see the pixels anyway.

The physical world (on human scale) is measured in meters (and multiples and 
fractions), not the cellulose cells of which paper is composed.  And displays 
are catching up to the resolution of paper, right on course to continue to make 
paper-based communication more and more obsolete.  So, we need to move towards 
using real-world units for computer graphics too, because in the limit, pixels 
will be vanishingly (and unpredictably) small.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt and Qt-Apps Adaptation for iOS-9 "Slide Over" and "Split View"

[Juhani Matilainen]

Split View and Split Over works with Qt if you use Xcode 7 and storyboard or 
xib file for launch screen instead of png file 
https://developer.apple.com/library/prerelease/ios/documentation/WindowsViews/Conceptual/AdoptingMultitaskingOniPad/QuickStartForSlideOverAndSplitView.html#//apple_ref/doc/uid/TP40015145-CH13-SW1

A one problem is exist if you use QML to paint statusbar background 
https://bugreports.qt.io/browse/QTBUG-48225

Regards
Juhani
> Daniel França  kirjoitti 21.9.2015 kello 9.33:
> 
> My guess is that both "Slide over" and "Split View" are managed entirely by 
> the OS and are app-independent, in that case Qt is ready... but I may be wrong
> 
>> Em seg, 21 de set de 2015 às 07:09, Robert Iakobashvili 
>>  escreveu:
>> Hi,
>> 
>> 1. Is Qt ready for "Slide Over" and "Split View",
>>and if yes which version?
>> 
>> 2. How to adapt a Qt app for "Slide Over" and "Split View"?
>> Should we make some interface adaptation when getting some
>> Qt-notifications on changes in available display size?
>> 
>> Thank you.
>> 
>> Regards,
>> Robert
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt 5.5 WinRT x64 VS2013 applications fail WACK Direct3D tests

[Kalinowski Maurice]

Hi,

would you be able to tell us, which API calls are failing on your side?

We are aware of Trim() causing troubles against the Windows 10 certification 
and are aiming to have this resolved with Qt 5.6. However, it should still work 
with VS2013/8.1 and then have your app also deployed on Windows 10 itself.

If there is anything else on your side, please let us know.

D3dcompile_qt was needed in older versions before D3DCompile was present. Hence 
we could remove that library at some point in the past.

BR,
Maurice

From: interest-bounces+maurice.kalinowski=theqtcompany@qt-project.org 
[mailto:interest-bounces+maurice.kalinowski=theqtcompany@qt-project.org] On 
Behalf Of Alexander Tkachenko
Sent: Freitag, 18. September 2015 14:01
To: interest@qt-project.org
Subject: [Interest] Qt 5.5 WinRT x64 VS2013 applications fail WACK Direct3D 
tests

Hello!

I downloaded latest Qt 5.5 x64 WinRT VS2013 binaries, created basic QWidget 
application and converted my Qt project to VS project by executing "qmake -tp 
vc .pro "CONFIG+=windeployqt"". The VS2013 project could be compiled and 
launched easily but both Windows Application Certification Kit Direct3D feature 
tests failed. I also have tested Several Qt example projects on Win 10 
VirtualBox and Win 8.1 PC with the same result. Tried all these things with Qt 
5.5 WinRT x86 VS2013 which I've built from sources w/o success.
On the other hand I installed Qt's QuickForecast application from Windows Store 
and it passed all WACK tests. The only significant difference I noticed between 
both packages is d3dcompiler_qt.dll in QuickForecast package folder. This .dll 
is missing in Qt 5.5 x64 WinRT VS2013. There is a d3dcompiler_47.dll but when I 
put it into package I got another WACK fails connected to restricted APIs in 
d3dcompiler_47.dll.
Is there any way to enable Direct3D features support and passing WACK tests 
with Qt 5.5 WinRT x64 VS2013?
I really appreciate any help.

Best regards,
Alexander Tkachenko
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Xcode 7 beta and Qt 5.5 ?

[Daniel França]

Thanks Thiago,
I added

QMAKE_MAC_SDK=macosx10.11and now it works, unfortunately couldn't find
any oficial documentation about QMAKE_MAC_SDK.


Em seg, 21 de set de 2015 às 01:24, Thiago Macieira <
thiago.macie...@intel.com> escreveu:

> On Sunday 20 September 2015 21:46:47 Daniel França wrote:
> > After update to XCode 7 I'm getting this error:
> http://pastebin.com/UA90Xded
> > Anyone having similar issue?
>
> SDK issue. XCode 7 only comes with the macosx10.11 SDK and you're probably
> asking the compiler for an older SDK.
>
> Check if your .pro file has QMAKE_SDK set. If so, make sure it's the one
> SDK
> that you have.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Xcode 7 beta and Qt 5.5 ?

[Sorvig Morten]

> On 21 Sep 2015, at 11:40, Daniel França  wrote:
> 
> Thanks Thiago,
> I added 
> QMAKE_MAC_SDK
> =macosx10.11
> 
> and now it works, unfortunately couldn't find any oficial documentation about 
> QMAKE_MAC_SDK.


What’s happening is that qmake caches the SDK version in qtbase/.qmake.stash. 
Delete that file and and run configure again; Qt should pick up and use the new 
SDK.

Morten
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt on iOS-9 - How to Disable Shortcuts Bar on Apple's Keyboard

[Robert Iakobashvili]

For the case that somebody needs it:

1. Disable predictive input in the window/text-field;

2. Pass the view/window/text-field as Wid (widget->winId()) to the
function below
   and disable two vectors/groups of UITextInputAssistantItem-s

void disable_iOS9_keyboard_shortcut_bar(void* window)
{
if (!window)
return;

if (SYSTEM_VERSION_GREATER_THAN_OR_EQUAL_TO(@"9.0")) {
UIView* view = (UIView*)window;

// You can also iterate thru subviews if required.

if ([view respondsToSelector:@selector(inputAssistantItem)]) {
UITextInputAssistantItem *inputAssistantItem = [view
inputAssistantItem];

inputAssistantItem.leadingBarButtonGroups = @[];
inputAssistantItem.trailingBarButtonGroups = @[];

}
}
}

I hope this will help to somebody.
Regards,
Robert


On Sun, Sep 20, 2015 at 10:36 AM, Robert Iakobashvili
 wrote:
> Gentlemen,
> iOS-9 adds to Apple's keyboard Shotcuts Bar taking space.
>
> Settings -> General -> Keyboard has a way to disable Shotcuts,
> and if predictive input is also disabled by either Settings or 
> programmatically,
> user gets this extra space.
>
> We can disable predictive input by setting a hint to a text widget,
> but no way to get rid from Shotcuts Bar.
>
> Here's the suggestions found on net.
>
> https://forums.developer.apple.com/thread/4664
>
> http://stackoverflow.com/questions/31877080/hiding-copy-paste-return-panel-in-ios-9-shortcuts-panel
>
> How could it be done in Qt widget application, i.e. with QTextEdit?
>
> Your suggestions would be welcomed.
>
> Regards,
> Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Video Recording of QQuickView

[Lopes Yoann]

> On 18 Sep 2015, at 21:55, Jérôme Godbout  wrote:
> 
> Hi,
> I have a built-in screen capture that use the QQuickView::grabWindow() 
> function inside my Qml application. I was wondering is there a way to perform 
> a video recording of the content?
> 
> Do I have to take many images and create a video manually or there's 
> something possible to generate a QMediaRecorder and somehow feed the 
> rendering of the QQuickView (probably a texture rendering).
> 
> I was also thinking if a fake QCamera could be created from a framebuffer or 
> the texture. That would be sweet to create a fake camera from the view, this 
> way the normal QtMultimedia modules could be used directly.

No, you won’t be able to do that with Qt Multimedia. You’ll have to encode the 
video yourself using another library, e.g. FFmpeg.

—
Yoann

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Video Recording of QQuickView

[Jérôme Godbout]

Thanks, this is what I was thinking, anybody have test the
https://code.google.com/p/qtffmpegwrapper/ does it still work? haven't been
updated in a while.

On Mon, Sep 21, 2015 at 6:50 AM, Lopes Yoann 
wrote:

> > On 18 Sep 2015, at 21:55, Jérôme Godbout  wrote:
> >
> > Hi,
> > I have a built-in screen capture that use the QQuickView::grabWindow()
> function inside my Qml application. I was wondering is there a way to
> perform a video recording of the content?
> >
> > Do I have to take many images and create a video manually or there's
> something possible to generate a QMediaRecorder and somehow feed the
> rendering of the QQuickView (probably a texture rendering).
> >
> > I was also thinking if a fake QCamera could be created from a
> framebuffer or the texture. That would be sweet to create a fake camera
> from the view, this way the normal QtMultimedia modules could be used
> directly.
>
> No, you won’t be able to do that with Qt Multimedia. You’ll have to encode
> the video yourself using another library, e.g. FFmpeg.
>
> —
> Yoann
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt and Qt-Apps Adaptation for iOS-9 "Slide Over" and "Split View"

[Robert Iakobashvili]

Apple says that to be ready,
an app should then be updated to support both auto-layout and
adaptivity with size classes:

https://developer.apple.com/library/ios/documentation/WindowsViews/Conceptual/AdoptingMultitaskingOniPad/index.html

Regards,
Robert


On Mon, Sep 21, 2015 at 9:33 AM, Daniel França  wrote:
> My guess is that both "Slide over" and "Split View" are managed entirely by
> the OS and are app-independent, in that case Qt is ready... but I may be
> wrong
>
> Em seg, 21 de set de 2015 às 07:09, Robert Iakobashvili
>  escreveu:
>>
>> Hi,
>>
>> 1. Is Qt ready for "Slide Over" and "Split View",
>>and if yes which version?
>>
>> 2. How to adapt a Qt app for "Slide Over" and "Split View"?
>> Should we make some interface adaptation when getting some
>> Qt-notifications on changes in available display size?
>>
>> Thank you.
>>
>> Regards,
>> Robert
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt and Qt-Apps Adaptation for iOS-9 "Slide Over" and "Split View"

[Robert Iakobashvili]

Here's some guide:

http://willowtreeapps.com/blog/multitasking-in-ios-9-for-developers-and-designers/
Regards,
Robert


On Mon, Sep 21, 2015 at 4:51 PM, Robert Iakobashvili
 wrote:
> Apple says that to be ready,
> an app should then be updated to support both auto-layout and
> adaptivity with size classes:
>
> https://developer.apple.com/library/ios/documentation/WindowsViews/Conceptual/AdoptingMultitaskingOniPad/index.html
>
> Regards,
> Robert
>
>
> On Mon, Sep 21, 2015 at 9:33 AM, Daniel França  
> wrote:
>> My guess is that both "Slide over" and "Split View" are managed entirely by
>> the OS and are app-independent, in that case Qt is ready... but I may be
>> wrong
>>
>> Em seg, 21 de set de 2015 às 07:09, Robert Iakobashvili
>>  escreveu:
>>>
>>> Hi,
>>>
>>> 1. Is Qt ready for "Slide Over" and "Split View",
>>>and if yes which version?
>>>
>>> 2. How to adapt a Qt app for "Slide Over" and "Split View"?
>>> Should we make some interface adaptation when getting some
>>> Qt-notifications on changes in available display size?
>>>
>>> Thank you.
>>>
>>> Regards,
>>> Robert
>>> ___
>>> Interest mailing list
>>> Interest@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] QT Webkit performance

[Florin Maticu]

Hello,

I have recently compiled *qt5.6* with the configuration bellow:

*qt 5.6 configuration options*
./configure -v -opensource -arch arm -opengl es2 -egl -no-fontconfig
-confirm-license -debug -verbose -device imx6 -device-option
CROSS_COMPILE=arm-linux-gnu- -sysroot /home/fmaticu/sysroot
-optimized-qmake -reduce-exports -gstreamer 1.0

I have a simple browser that is using qtwebkit to display an url page.

I am using Methanol benchmark tool (https://github.com/szeged/methanol) for
testing the browser.

The browser is writing to the linux framebuffer. While running the tests I
have noticed that the cpu load is always higher than 50%.

How can I improve the performance of the QtWebkit, in terms of cpu load?

Is there support in the qtwebkit for GPU rendering?


Thank you,
Florin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QT Webkit performance

[Allan Sandfeld Jensen]

On Monday 21 September 2015, Florin Maticu wrote:
> Hello,
> 
> I have recently compiled *qt5.6* with the configuration bellow:
> 
> *qt 5.6 configuration options*
> ./configure -v -opensource -arch arm -opengl es2 -egl -no-fontconfig
> -confirm-license -debug -verbose -device imx6 -device-option
> CROSS_COMPILE=arm-linux-gnu- -sysroot /home/fmaticu/sysroot
> -optimized-qmake -reduce-exports -gstreamer 1.0
> 
> I have a simple browser that is using qtwebkit to display an url page.
> 
> I am using Methanol benchmark tool (https://github.com/szeged/methanol) for
> testing the browser.
> 
> The browser is writing to the linux framebuffer. While running the tests I
> have noticed that the cpu load is always higher than 50%.
> 
> How can I improve the performance of the QtWebkit, in terms of cpu load?
> 
> Is there support in the qtwebkit for GPU rendering?
> 
Yes,  it should do it more or less automatically when using the QML API. If 
you are using QWebView, you should switch to QGraphicsWebView and set a 
QOpenGLWidget as the view on the hosting QGraphicsView. That way compositing
will be done using the GPU.

`Allan
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] High DPI support in QT (Windows)

[Adam Light]

On Fri, Sep 18, 2015 at 1:38 AM, Pavlo Dyachenko  wrote:

> Hi QT team, I posted a question on the forum about high DPI support but
> then was recommended this mailing list instead:
> According to documentation here http://doc.qt.io/qt-5/highdpi.html QT
> 5.4+ introduces high DPI support. However, either I’m missing something
> fundamental or the current support is still in very early stages. I’m
> writing a brand new application so I have a chance to do it right from the
> ground up. I understand that I would have to use layouts instead of fixed
> positioning etc, but there always going to be cases in which I would have
> to specify, for example a minimum/maximum size of a control. I can specify
> them in the editor, but these are device pixels. So if I change my Windows
> settings to use 150% DPI then min/max values in the editor would be too
> small. Of course I can obtain that ratio and adjust all the required values
> in code, but then what kind of high DPI support does QT give for me if I
> have to do everything by hand? I mean how is it different to pre QT 5.4?
>
> Then an interesting one is QT_DEVICE_PIXEL_RATIO environment variable. It
> does exactly what I need, it multiplies all pixels set in editor by a
> factor. But why is it an environment variable and not a per application
> setting? Why does it only support integer values of 2, 3 etc, since we know
> that Windows has settings like 125, 150% etc. and why couldn’t it
> automatically read the Windows setting and set itself to that value?
>
>
Though I have not yet tried it, my understanding is that in Qt 5.6, the
support for HiDPI has been improved. See
https://doc-snapshots.qt.io/qt5-5.6/highdpi.html for the most recent
documentation.

Adam
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Xcode 7 beta and Qt 5.5 ?

[Daniel França]

Thanks for the explanation Sorvig, indeed deleting qmake.stash worked
without the need to add QMAKE_MAC_SDK in the .pro.
Would be great to have this kind of thing documented somewhere.


Em seg, 21 de set de 2015 às 12:18, Sorvig Morten <
morten.sor...@theqtcompany.com> escreveu:

>
> > On 21 Sep 2015, at 11:40, Daniel França  wrote:
> >
> > Thanks Thiago,
> > I added
> > QMAKE_MAC_SDK
> > =macosx10.11
> >
> > and now it works, unfortunately couldn't find any oficial documentation
> about QMAKE_MAC_SDK.
>
>
> What’s happening is that qmake caches the SDK version in
> qtbase/.qmake.stash. Delete that file and and run configure again; Qt
> should pick up and use the new SDK.
>
> Morten
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Xcode 7 beta and Qt 5.5 ?

[Thiago Macieira]

On Monday 21 September 2015 10:18:13 Sorvig Morten wrote:
> > On 21 Sep 2015, at 11:40, Daniel França  wrote:
> > 
> >
> > Thanks Thiago,
> > I added 
> > QMAKE_MAC_SDK
> > =macosx10.11
> >
> > 
> >
> > and now it works, unfortunately couldn't find any oficial documentation
> > about QMAKE_MAC_SDK.
> What’s happening is that qmake caches the SDK version in
> qtbase/.qmake.stash. Delete that file and and run configure again; Qt
> should pick up and use the new SDK.

Replace qtbase with the root of your project.

In other words, delete all .qmake.stash files you find.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Qt Purchasing API and Android Lollipop

[Nuno Santos]

Hi,

Is there any know incompatibility between Qt Purchasing API and Android 
Lollipop?

I had two recent reports of users using Android Lollipop that can’t proceed 
with in-app purchase. The price doesn’t event appear.

Thanks,

Regards

Nuno___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Xcode 7 beta and Qt 5.5 ?

[Thiago Macieira]

On Monday 21 September 2015 16:02:53 Daniel França wrote:
> Thanks for the explanation Sorvig, indeed deleting qmake.stash worked
> without the need to add QMAKE_MAC_SDK in the .pro.
> Would be great to have this kind of thing documented somewhere.

It isn't documented because it wasn't necessary. Apple had never released a 
new version of Xcode without including at least one SDK in common from the 
previous version.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Building Qt 5.4 on Mac OSX 10.11: qcocoacursor.mm:84:20: error: no matching function for call to 'CGEventCreateMouseEvent'

[Alan Ezust]

Running into troubles building Qt 5.4 on MacOSX 10.11 with clang.

   First ran into an issue related to _Nullable which was fixed by
https://codereview.qt-project.org/#/c/121545/

Then I had to specify the SDK version in configure
because detection was not working properly.

./configure -opensource -confirm-license -sdk macosx10.11 -arch x86_64

Building for a while, I am now running into this error:


In file included from qcocoacursor.mm:44:
In file included from ./qcocoahelpers.h:48:
../../../../lib/QtGui.framework/Versions/5/Headers/5.4.2/QtGui/private/qguiapplication_p.h:84:18:
warning: 'shouldQuit' overrides a member function but is not marked
'override'
  [-Winconsistent-missing-override]
virtual bool shouldQuit();
 ^
../../../../lib/QtCore.framework/Versions/5/Headers/5.4.2/QtCore/private/qcoreapplication_p.h:103:18:
note: overridden virtual function is here
virtual bool shouldQuit() {
 ^
qcocoacursor.mm:84:20: error: no matching function for call to
'CGEventCreateMouseEvent'
CGEventRef e = CGEventCreateMouseEvent(0, kCGEventMouseMoved, pos, 0);
   ^~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/CoreGraphics.framework/Headers/CGEvent.h:57:33:
note: candidate function not
  viable: no known conversion from 'int' to 'CGMouseButton' for 4th
argument
CG_EXTERN CGEventRef __nullable CGEventCreateMouseEvent(
^
81 warnings and 1 error generated.
make[6]: *** [.obj/debug/qcocoacursor.o] Error 1
make[5]: *** [debug-all] Error 2
make[4]: *** [sub-cocoa-make_first] Error 2
make[3]: *** [sub-platforms-make_first] Error 2
make[2]: *** [sub-plugins-make_first] Error 2
make[1]: *** [sub-src-make_first] Error 2
make: *** [module-qtbase-make_first] Error 2
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] geometry() for a widget that hasn't been shown

[John Weeks]

If this is a repeat, my apologies. I can't tell if I saw this arrive on the 
list!



In general a QWidget that hasn't been made visible yet gives bogus results for 
QWidget::geometry(). Qt only guarantees that a call to setGeometry() will 
result in a Resize event when the window is made visible. But we often need to 
ask a window or child widget how big it is before it is made visible in order 
to do various kinds of calculations. These calculations are sometimes used for 
things that preclude waiting for the window to become visible.

Is there a way to force the Resize events (and all the layout calculation 
machinery that goes with it) before it is visible? Using Qt 5.5, I see that if 
you call QWidget::grab(), it will call a static function sendResizeEvents() 
that does exactly what I want:

QPixmap QWidget::grab(const QRect &rectangle)
{
   Q_D(QWidget);
   if (testAttribute(Qt::WA_PendingResizeEvent) || 
!testAttribute(Qt::WA_WState_Created))
   sendResizeEvents(this);

Is there some other way to get this to happen? I suppose I could just call 
grab() and throw away the QPixmap, but that seems like an awful kludge...

-John Weeks

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] High DPI support in QT (Windows)

[Emre Besirik]

Well, I also hope for some imrovement on this subject as I’ve been there too 
with 5.3 I think…


> On 21 Sep 2015, at 18:36, Adam Light  wrote:
> 
> 
> 
> On Fri, Sep 18, 2015 at 1:38 AM, Pavlo Dyachenko  > wrote:
> Hi QT team, I posted a question on the forum about high DPI support but then 
> was recommended this mailing list instead:
> According to documentation here http://doc.qt.io/qt-5/highdpi.html 
>  QT 5.4+ introduces high DPI support. 
> However, either I’m missing something fundamental or the current support is 
> still in very early stages. I’m writing a brand new application so I have a 
> chance to do it right from the ground up. I understand that I would have to 
> use layouts instead of fixed positioning etc, but there always going to be 
> cases in which I would have to specify, for example a minimum/maximum size of 
> a control. I can specify them in the editor, but these are device pixels. So 
> if I change my Windows settings to use 150% DPI then min/max values in the 
> editor would be too small. Of course I can obtain that ratio and adjust all 
> the required values in code, but then what kind of high DPI support does QT 
> give for me if I have to do everything by hand? I mean how is it different to 
> pre QT 5.4?
> 
> Then an interesting one is QT_DEVICE_PIXEL_RATIO environment variable. It 
> does exactly what I need, it multiplies all pixels set in editor by a factor. 
> But why is it an environment variable and not a per application setting? Why 
> does it only support integer values of 2, 3 etc, since we know that Windows 
> has settings like 125, 150% etc. and why couldn’t it automatically read the 
> Windows setting and set itself to that value?
> 
> 
> Though I have not yet tried it, my understanding is that in Qt 5.6, the 
> support for HiDPI has been improved. See 
> https://doc-snapshots.qt.io/qt5-5.6/highdpi.html 
>  for the most recent 
> documentation.
> 
> Adam 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MacOSx: Qt::KeypadModifier for arrow keys?

[Alan Ezust]

Ok, since Qt works as advertised, I suppose one could argue if there is a
bug or not, but I still think that when the user types arrow keys from the
mac keyboard(s), they should just register as plain old arrow keys without
modifiers or any kind of numeric-keypad reference. And that is how things
work from Java.


On Sat, Sep 19, 2015 at 4:04 AM, Elvis Stansvik  wrote:

> Hi Alan,
>
> 2015-09-18 22:52 GMT+02:00 Alan Ezust :
> > I am running a keyboard test program on the MacOS
> > with Qt 5.4 on MacOSx 10.10.5, Clang.
> > All it does is print out the modifiers and the keycodes when I type arrow
> > keys.
> >
> >
> > void Dialog::keyPressEvent(QKeyEvent *ke) {
> >
> > qDebug() << "event: " << ke->modifiers() << ke->key();
> >
> >
> >
> > }
> >
> >
> > event: QFlags(0x2000) 16777234
> >
> > event: QFlags(0x2000) 16777236
> >
> > event: QFlags(0x2000) 16777235
> >
> > event: QFlags(0x2000) 16777237
> >
> >
> > Why is the keypad modifier always selected for regular arrow keypress
> events
> > on the mac?
>
> >From the documentation [1]:
>
> "Note: On OS X, the ControlModifier value corresponds to the Command
> keys on the Macintosh keyboard, and the MetaModifier value corresponds
> to the Control keys. The KeypadModifier value will also be set when an
> arrow key is pressed as the arrow keys are considered part of the
> keypad."
>
> So what you're seeing is documented behavior on OS X. Now don't ask me
> why. Someone else will have to answer :)
>
> Cheers,
> Elvis
>
> [1] http://doc.qt.io/qt-5/qt.html#KeyboardModifier-enum
>
> >
> >
> >
> >
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> >
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Building Qt 5.4 on Mac OSX 10.11: qcocoacursor.mm:84:20: error: no matching function for call to 'CGEventCreateMouseEvent'

[Thiago Macieira]

On Monday 21 September 2015 10:20:14 Alan Ezust wrote:
> qcocoacursor.mm:84:20: error: no matching function for call to
> 'CGEventCreateMouseEvent'
> CGEventRef e = CGEventCreateMouseEvent(0, kCGEventMouseMoved, pos, 0);

Already fixed in 02ea0235216beef390e9868ff770c7a54d70db83 (5.5.1 material).

To everyone using Xcode 6.4 or 7: update to Qt 5.5.1.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt and Qt-Apps Adaptation for iOS-9 "Slide Over" and "Split View"

[Robert Iakobashvili]

Hi Juhani,
Thank you very much for your input.

Well, my app is painting status-bar background independently
by code. Now it should detect if primary screen, and only in this case to draw.

Events relevant to change layout of views are supposed to be delivered by

willTransitionToTraitCollection
traitCollectionDidChange
viewWillTransitionToSize

Which Qt signals correspond to it?

Where you are doing adaptations for changes in actual visible area (UIWindow)?

Thanks,

Kind regards,
Robert


On Mon, Sep 21, 2015 at 10:53 AM, Juhani Matilainen
 wrote:
>
> Split View and Split Over works with Qt if you use Xcode 7 and storyboard or
> xib file for launch screen instead of png file
> https://developer.apple.com/library/prerelease/ios/documentation/WindowsViews/Conceptual/AdoptingMultitaskingOniPad/QuickStartForSlideOverAndSplitView.html#//apple_ref/doc/uid/TP40015145-CH13-SW1
>
> A one problem is exist if you use QML to paint statusbar background
> https://bugreports.qt.io/browse/QTBUG-48225
>
> Regards
> Juhani
> Daniel França  kirjoitti 21.9.2015 kello 9.33:
>
> My guess is that both "Slide over" and "Split View" are managed entirely by
> the OS and are app-independent, in that case Qt is ready... but I may be
> wrong
>
> Em seg, 21 de set de 2015 às 07:09, Robert Iakobashvili
>  escreveu:
>>
>> Hi,
>>
>> 1. Is Qt ready for "Slide Over" and "Split View",
>>and if yes which version?
>>
>> 2. How to adapt a Qt app for "Slide Over" and "Split View"?
>> Should we make some interface adaptation when getting some
>> Qt-notifications on changes in available display size?
>>
>> Thank you.
>>
>> Regards,
>> Robert
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] ListView question

[VStevenP]

What's the easiest way to implement a list using a customized ListView, to 
achieve rounded corners at the four corners of the ListView, but no rounding on 
the four corners of every delegate?

If I highlight the delegate, I wish for it to appear as a pure rectangle in 
most cases, except when it's the first or last delegate, in which case I wish 
for the outer 2 corners of each to appear rounded.

I tried to achieve this by encapsulating the ListView within a Rectangle with a 
specified radius and clip set to true, but the delegates of the ListView clip 
to the ListView, not the ListView's enclosing Rectangle.  The result is a list 
with square corners, which is not what is desired.

Any ideas would be appreciated.

Steve Pavao
Korg R&D
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest