Re: [Interest] DragDrop between different processes not working?
Am 17.12.2014 um 08:57 schrieb Wilhelm wilhelm.me...@fh-kl.de: ... But just to rule out the usual suspects: does drag and drop in general work with your current Window Manager (in applications where you /know/ that certain MIME types are accepted)? E.g. when you drag and drop a file from your File Manager to your Email editor: does it get attached (or even embedded) (in)to your current email that you are typing? Yes, absolutely. E.g. I can drag from a foreign application (e.g. dolphin) to my programm (into a derived QTextEdit to accept that drops). So just to repeat: * Drag and Drop (DnD) works when initiated from another application (e.g. Dolphin file manager) and dropped onto your (drop-enabled) application/widget * DnD works within your own application instance (process) But it does not work when * DnD initiated in your application instance 1 and dropped onto your application instance 2 What exactly does not work? In instance 2, are you not getting an event at all? Or is it simply not acceptable? What happens if you try to drop onto another application which e.g. accepts images (email client maybe)? That is, you initiate a drag in a QLabel, place the image e.g. as image/png or image/jpeg (?) into the QMimeData and drop it over the email client? Would that work? Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Regarding my QHttpMultPpart issues
I've filed a bug. https://bugreports.qt-project.org/browse/QTBUG-43378 If anyone has time, please give it shot and see if you can reproduce my problem. If possible, place the server and the client on separate machines. A basic test if for each line read line, the bytes added up should match the byte count reported in the header, except for the first read which is the main header. In my example: Main header Content-Length: 114083 void TcpServer::read() 16384 void TcpServer::read() 97699 The sum of the two reads equals 114083, so this request over loopback would have worked. If you put it on separate machines, it doesn't. (At least for me) What I am seeing is on separate machines, Qt locks up in reading the file and never finishes the request. Thanks all. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] DragDrop between different processes not working?
Am 17.12.2014 um 11:17 schrieb Michael Sué: You may need to override the dragEnterEvent, dragMoveEvent etc. functions of the accepting widget Yes, I did that. But the mimeData is empty ... - Michael. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest -- Wilhelm w.me...@unix.net ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Virtual keyboard
I have a virtual keyboard installed (Hot Virtual Keyboard) on Windows7. I use qt-opensource-windows-x86-msvc2013-5.4.0. In Qt Widget programs (e.g. from examples) the keyboard works as expected: When I click into an editable text field, the keyboard pops up. But this does not work in QML programs like the gallery example: When I click into a TextArea, TextEdit or TextField element, nothing happens. It only works as expected in System Dialogs. Is this a bug or do I miss something? Best regards Helmut ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] DragDrop between different processes not working?
Hi, Yes, I did that. But the mimeData is empty ... I just checked on my Linux machines: The (exact same) code that works on WINDOWS (drag and drop between different instances of my program) does not work (or better no longer work) on LINUX. Thank you for pointing this out to me :-) I will check which version before Qt 5.4.0 was the last that did it well. - Michael. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QtQuickControls Slider and multitouch
Hi, I have just stumble on the lack of multitouch support for the Slider element in Quick Controls. I can’t interact with more than one slider at once using the Slider element. I had my own version of Slider using a Multitouch area and it was working great. I have now switch to Slider from Quick Controls and found that this is not possible with it. Since Qt is more than ever a cross platform platform for mobile (and desktop are each day becoming more and more multitouch aware), I think this kind of controls should have multi interaction support. Does anyone knows a way of overriding Slider touch handling? Regards, Nuno Santos ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] DragDrop between different processes not working?
The problem seems to be a bug for LINUX in Qt 5.4.0, the (exact same) code works it still works in Qt 5.3.1. -Michael ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] [Qt-iOS] How can I linked to libjpeg-turbo?
My project use Qt 5.4.0, Some part of my app will decode jpeg file to YUV buffer, to achieve this with fast speed I choose libjpeg-turbo(I use the prebuilt iOS version 1.3.1). It works well in Windows and OSX, but failed in iOS. The app fail to launch with the following message: Wrong JPEG library version: library is 62, caller expects 80 I guess this is because qt library shipped in iOS are static libraries and Qt itself will also link against libjpeg, and if I specify -lturbojpeg in my .pro file, the linker will choose libjpeg-turbo to link and since libjpeg-turbo only implement version 6.2 of libjpeg while Qt require 8.0. How can I work around this issue? Thanks. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] TableView focus proxying
Hello,
I am trying go give active focus on a TextInput belonging to a
delegate item of a TableView.
Here is a minimal code for the delegate:
// MyClickableWidget.qml
import QtQuick 2.3
FocusScope {
id: scope
property alias text: label.text
//FocusScope needs to bind to visual properties of the children
property alias color: rectangle.color
x: rectangle.x
y: rectangle.y
width: rectangle.width
height: rectangle.height
Rectangle {
id: rectangle
color: lightsteelblue
width: 175
height: 25
radius: 10
antialiasing: true
border.color: blue
TextInput {
id: label
anchors.centerIn: parent
focus: true
}
}
MouseArea {
anchors.fill: parent
onClicked: { scope.focus = true; }
}
}
So, my goal is to give active focus to label when the delegate is
clicked.
import QtQuick 2.3
import QtQuick.Controls 1.2
Rectangle {
id: window
width: 400
height: 150
ListModel {
id: model
ListElement {x: 42; y: 84}
ListElement {x: 126; y: 168}
}
TableView {
id: table
anchors.fill: parent
model: model
focus: true
itemDelegate: MyClickableWidget {
color: lightgreen
text: styleData.value
}
rowDelegate: Rectangle {
height: 50
}
TableViewColumn {
role: x
width: 180
}
TableViewColumn {
role: y
width: 180
}
}
}
When I run this example, I have to click two times on a delegate to
focus the internal label and I don't understand why. Using a ListView
instead of a TableView give me the expected behavior.
Am I missing something with the focus chain mechanism?
Jean-Benoît Hubert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [Qt-iOS] How can I linked to libjpeg-turbo?
On Wednesday December 17 2014 20:00:30 Liang Jian wrote: Wrong JPEG library version: library is 62, caller expects 80 I guess this is because qt library shipped in iOS are static libraries and Qt itself will also link against libjpeg, and if I specify -lturbojpeg in my .pro file, the linker will choose libjpeg-turbo to link and since libjpeg-turbo only implement version 6.2 of libjpeg while Qt require 8.0. How can I work around this issue? Thanks. I see 2 possibilities if you insist on using libjpeg-turbo (I presume you have already demonstrated to yourself that this library indeed gives a significant performance boost on iOS?!) - rebuild Qt for iOS so that it accepts libjpeg-turbo or if that's not feasible, - figure out how to change libjpeg-turbo's functions just enough so you can have both libraries linked, and then call the turbo functions from your code where required. R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtQuickControls Slider and multitouch
On 17 Dec 2014, at 12:35, Nuno Santos nunosan...@imaginando.pt wrote: Hi, I have just stumble on the lack of multitouch support for the Slider element in Quick Controls. I can’t interact with more than one slider at once using the Slider element. I had my own version of Slider using a Multitouch area and it was working great. I have now switch to Slider from Quick Controls and found that this is not possible with it. Since Qt is more than ever a cross platform platform for mobile (and desktop are each day becoming more and more multitouch aware), I think this kind of controls should have multi interaction support. Does anyone knows a way of overriding Slider touch handling? The tentative plan is to have MouseArea handle touch events too; then it will work. (Multiple-finger touch events can be broken up and dispatched to multiple Items in the scene, whereas only one touchpoint can be used as a synthetic mouse, because Qt only supports one mouse.) However it’s been controversial, and hard to get working 100% correctly in every possible combination of items too; that’s why the patches are not integrated yet. I also believe that if we start to directly handle touch events in MouseArea, we will need to do the same in every item that currently handles mouse events, because otherwise the scenarios in which one item steals the grab from another will not work correctly. That means Flickable at least. So, the following patches are mostly ready for integration, except that I’m not 100% sure that no regressions will be introduced, and I’m pretty sure there are a few autotests that don’t pass yet: https://codereview.qt-project.org/#/c/63308/ https://codereview.qt-project.org/#/c/65801/ An alternative idea was to create a TouchArea which only handles the simple touch use cases, like tapping and dragging, with an API that is mostly compatible with MouseArea. But that did not get done yet either, and I think it would be nice to have existing MouseAreas inside existing components just start working with multitouch. The controversy comes from the fact that we usually try to avoid behavior change, because we cannot predict what bugs it would cause; for example in a set of tabs, where each has its own MouseArea, what happens if you press two tabs at once? I think that in most such cases, at least something deterministic would happen. But maybe there could be some unknown bad cases. So probably in every case where a MouseArea was already in use, you will have to modify the QML to enable multiple-touch interaction. In the current version of the patch, you would have to set multiPointTouchEnabled: true, because it is not enabled by default. Or if we had a TouchArea instead, then you’d have to replace MouseArea with TouchArea. So it’s not a transparent upgrade either way. The Controls Slider will need this change to be done, if nobody has an objection to _that_ behaviour change, that suddenly all sliders can be dragged in parallel. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QML innershadow
Hi all,
last day we come up with a strage behaviour, or at least, what it seems a
strange behaviour to us. Following the documentation for InnerShadow QML
type it is stated that:
Note: It is not supported to let the effect include itself, for instance
by setting source to the effect's parent.
However, the only way to obtain an homogenous internal shadow such as this
one http://i.stack.imgur.com/XIbGq.png (i.e. with offsets set to zero)
seems to break the documentation rule:
import QtQuick 2.0
import QtGraphicalEffects 1.0
Item {
id: root
width: 300
height: 300
Rectangle {
id: myRectangle
anchors.centerIn: parent
width: 100
height: 100
color: grey
}
InnerShadow {
anchors.fill: root
cached: true
horizontalOffset: 0
verticalOffset: 0
radius: 16
samples: 32
color: #b000
smooth: true
source: root // --- source include the effect!
}
}
Is it intended behaviour or a bug? Is there another way to achieve an
overall shadow like the one in picture?
Thanks in advance,
F.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] DragDrop between different processes not working?
Am 17.12.2014 um 12:41 schrieb Michael Sué: The problem seems to be a bug for LINUX in Qt 5.4.0, the (exact same) code works it still works in Qt 5.3.1. Ok, thanks for testing this. Is there a workaround for 5.4.0? -- Wilhelm w.me...@unix.net ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [Qt-iOS] How can I linked to libjpeg-turbo?
First of all, thank you for the reply! libjpeg-turbo uses NEON instruction to accelerate decoding, it should give significant performance boost. And since QImage will decode jpeg file into ARGB pixel format which will introduce YUV--RGB color space conversion, it is slow to do it in CPU. The way I do it is to use libjpeg-turbo to decode a jpeg file into YUV planar pixel buffer, and then I will use GLES2 fragment shader to perform YUV-RGB color space conversion by GPU and then display it in QtQuick's scene graph, that is the fastest way I can imagine. The first way you have suggested require rebuilding qt-iOS, that is a burden too heavy for us. In fact in Qt-5.3.2 days, We have to build Qt-iOS with a patch to work around an landscape issue introduced in iOS 8, but I have encountered many problems with the qt built by myself , such as I can't use it in QtCreator but I can use it in xcode(I don't know why :-) ). The second way require modification of libjpeg-turbo ( maybe remove the entire old libjpeg style API ) which is beyond me. Is it possible to solve this issue by some kind of linker magic? For example, MSVC support #pragma comment(lib, lib), that will only link the lib inside the specific object file. But I can't find the equivalent thing in clang. And there is one thing I can't understand: xcode didn't ship libjpeg in its iOS SDK and I can't find libjpeg shipped with Qt-iOS, then where is the libjpeg library Qt-iOS linked by default? On Wed, Dec 17, 2014 at 8:17 PM, René J.V. rjvber...@gmail.com wrote: On Wednesday December 17 2014 20:00:30 Liang Jian wrote: Wrong JPEG library version: library is 62, caller expects 80 I guess this is because qt library shipped in iOS are static libraries and Qt itself will also link against libjpeg, and if I specify -lturbojpeg in my .pro file, the linker will choose libjpeg-turbo to link and since libjpeg-turbo only implement version 6.2 of libjpeg while Qt require 8.0. How can I work around this issue? Thanks. I see 2 possibilities if you insist on using libjpeg-turbo (I presume you have already demonstrated to yourself that this library indeed gives a significant performance boost on iOS?!) - rebuild Qt for iOS so that it accepts libjpeg-turbo or if that's not feasible, - figure out how to change libjpeg-turbo's functions just enough so you can have both libraries linked, and then call the turbo functions from your code where required. R. ___ 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-iOS] How can I linked to libjpeg-turbo?
I will try it, thanks. On Wed, Dec 17, 2014 at 10:03 PM, René J.V. rjvber...@gmail.com wrote: On Wednesday December 17 2014 21:21:29 Liang Jian wrote: The second way require modification of libjpeg-turbo ( maybe remove the entire old libjpeg style API ) which is beyond me. It's really not difficult, but it will be a bit of work to ensure that you rename everything that has to be renamed. Functions that are not exported from the library (which includes all that are marked static) won't have to be renamed for instance. The goal is simply to avoid having 2 functions with the same name. If you're working in C++ you might be able to achieve this by putting all of libjpeg-turbo in its own namespace. R. ___ 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] QML innershadow
Hi Buti,
maybe the proper way to achieve the same effect is like this:
import QtQuick 2.0
import QtGraphicalEffects 1.0
Item {
id: root
width: 300
height: 300
Item {
id: src
anchors.fill: parent
Rectangle {
id: myRectangle
anchors.centerIn: parent
width: 100
height: 100
color: grey
}
}
InnerShadow {
anchors.fill: src
cached: true
horizontalOffset: 0
verticalOffset: 0
radius: 16
samples: 32
color: #b000
smooth: true
source: src
}
}
my suggestion is that you should definitely follow the documentation, otherwise
you will be confused by the strange effect caused by applying effect on the
effect’ parent someday in the future ;)
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtQuickControls Slider and multitouch
Hi Shawn, First of all thanks for your reply. As far as I understood, there are a couple of patches ready to integrate and I could probably integrate them myself on my current Qt. If that is correct, I really don’t want to change my default Qt behaviour because, otherwise I would need to ensure that I apply the very same patches every time I update Qt. Changing from a MouseArea to Multitouch area implies to change the source so I can’t make it from the Qml side, right? In your opinion. Should I stick to my custom made slider for the controls I need this behaviour in? Regards, Nuno On 17 Dec 2014, at 12:22, Rutledge Shawn shawn.rutle...@theqtcompany.com wrote: On 17 Dec 2014, at 12:35, Nuno Santos nunosan...@imaginando.pt wrote: Hi, I have just stumble on the lack of multitouch support for the Slider element in Quick Controls. I can’t interact with more than one slider at once using the Slider element. I had my own version of Slider using a Multitouch area and it was working great. I have now switch to Slider from Quick Controls and found that this is not possible with it. Since Qt is more than ever a cross platform platform for mobile (and desktop are each day becoming more and more multitouch aware), I think this kind of controls should have multi interaction support. Does anyone knows a way of overriding Slider touch handling? The tentative plan is to have MouseArea handle touch events too; then it will work. (Multiple-finger touch events can be broken up and dispatched to multiple Items in the scene, whereas only one touchpoint can be used as a synthetic mouse, because Qt only supports one mouse.) However it’s been controversial, and hard to get working 100% correctly in every possible combination of items too; that’s why the patches are not integrated yet. I also believe that if we start to directly handle touch events in MouseArea, we will need to do the same in every item that currently handles mouse events, because otherwise the scenarios in which one item steals the grab from another will not work correctly. That means Flickable at least. So, the following patches are mostly ready for integration, except that I’m not 100% sure that no regressions will be introduced, and I’m pretty sure there are a few autotests that don’t pass yet: https://codereview.qt-project.org/#/c/63308/ https://codereview.qt-project.org/#/c/65801/ An alternative idea was to create a TouchArea which only handles the simple touch use cases, like tapping and dragging, with an API that is mostly compatible with MouseArea. But that did not get done yet either, and I think it would be nice to have existing MouseAreas inside existing components just start working with multitouch. The controversy comes from the fact that we usually try to avoid behavior change, because we cannot predict what bugs it would cause; for example in a set of tabs, where each has its own MouseArea, what happens if you press two tabs at once? I think that in most such cases, at least something deterministic would happen. But maybe there could be some unknown bad cases. So probably in every case where a MouseArea was already in use, you will have to modify the QML to enable multiple-touch interaction. In the current version of the patch, you would have to set multiPointTouchEnabled: true, because it is not enabled by default. Or if we had a TouchArea instead, then you’d have to replace MouseArea with TouchArea. So it’s not a transparent upgrade either way. The Controls Slider will need this change to be done, if nobody has an objection to _that_ behaviour change, that suddenly all sliders can be dragged in parallel. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] New connection syntax
On Wednesday 17 December 2014 08:35:33 André Somers wrote: Thiago Macieira schreef op 16-12-2014 17:13: On Tuesday 16 December 2014 12:41:35 Igor Mironchik wrote: And my question is: is it ok to use QtPrivate::FunctionPointer in my classes? No. That's only permitted for code that is part of Qt itself (hosted on qt- project.org, part of qt.git) Isn't it a bit strange that there are things in the public API that really are private? No. For two reasons: 1) We need a lot of code in the public headers in order to do things that appear in inline code. Take classes like QListData, QHashNode, or even the type_traits replacement that we carry for systems without it. We need them, but we never meant for people to use them. They may change unpredictably. 2) it's not public API at all. It's in public headers, but it's undocumented and therefore private API. If you built your own code on top of Qt, then I at least find it nice to be able to create similar API to what Qt offers so it is easier to use for other developers. This is made more difficult by things like this. It was easy to offer an API like the QAction qthelp://com.trolltech.qt.484/qdoc/qaction.html* QToolBar::addAction( constQString qthelp://com.trolltech.qt.484/qdoc/qstring.html/text/, constQObject qthelp://com.trolltech.qt.484/qdoc/qobject.html*/receiver/, constchar*/member/) in your own code. Nothing private there. But apparently, mirroring Qt API design for the sake of consistency is no longer possible? You can do whatever you want in your own code. But if you use undocumented parts of the Qt API, we can't promise it will continue to work. There are other ways of doing the same. The same also applies to undocumented behaviour of libc or even undocumented processor instructions. If you use them, you're on your own. -- 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] to -fno-exceptions or not ...
On Wednesday 17 December 2014 11:55:21 René J.V. Bertin wrote: QIcon() isn't inline and neither is it marked as noexcept. Therefore, the compiler must add surrounding EH code so that any locals you have in the context where that QIcon was created can be destructed. And QIcon() is part of QtGui which *is* now built with no-exceptions ... But when your code is compiled, the compiler doesn't know that. The question is whether the caller is built with -fno-exceptions or not. -- 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 concurrency memory model C++11
On Wednesday 17 December 2014 11:14:39 Frank Meffert wrote: Hey Qt folks, I’ve got a general question on Qt’s implementation of concurrency (i.e. QThread et al.). The new C++ standard introduces a whole new way of concurrency, incorporating a new memory model making it unnecessary to use 3rd party libs like pthread, for instance. As far as I know, Qt is currently using the pthread-library – in case of linux – within all concurrency related classes. Yes and no. Qt is using pthread on Linux, correct. But it doesn't have concurrency issues. The C11/C++11 memory model applies to pthread too. Will Qt make use of the new memory model and the new Thread API of the new C++ standard in future releases? Are there any plans/roadmaps? Yes, Qt uses the new memory model. All you need for that is to compile your code with a compiler that supports the memory model. Qt code did not need to be changed for it. -- 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] DragDrop between different processes not working?
Am 17.12.2014 um 12:41 schrieb Michael Sué: The problem seems to be a bug for LINUX in Qt 5.4.0, the (exact same) code works it still works in Qt 5.3.1. I can confirm that it works with Qt 5.3.2 (linux). I can drag from my test-application to another instance or to e.g. kate, etc ... That's good news. So, what todo with Qt 5.4.0? Any Workarounds? -- Wilhelm w.me...@unix.net ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] DragDrop between different processes not working?
Am 17.12.2014 um 22:45 schrieb Wilhelm wilhelm.me...@fh-kl.de: ... I can confirm that it works with Qt 5.3.2 (linux). I can drag from my test-application to another instance or to e.g. kate, etc ... That's good news. So, what todo with Qt 5.4.0? Any Workarounds? I am glad that you could track down the issue :) I don't know of any workarounds unfortunatelly, but you should check https://bugreports.qt-project.org/secure/Dashboard.jspa whether a drag and drop related issue already exists (for Qt 5.4), and if not, add one (best with some minimal compileable code). (If an issue already exists you can also vote for it, or even add additional information about how to reproduce etc. ;)) Hopefully it gets fixed in 5.4.1 already (since it seems to be a regression in 5.4). Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
