General and Desktop

Thanks Andre. Got a bit confused.

So... how did you declare and implement your QDataStream operator overloads?

Good to know, and thanks for providing your solution!

[quote author="VanDerSam" date="1330770978"]See Qt documentation about QtMultimedia module and Phonon module.[/quote] but i did not find camera related api for desktop application. Is Qcamera will work only for mobile application or for desktop application?

The thread scheduling policies are OS specific. Today, most OSes automatically switch between threads. The answers in this thread are Linux-focused, where scheduler policies and thread priorities are available through system APIs (not Qt). On some setups, manipulating these requires security privileges (google for AEGIS, for example on the N9). There were OSes in the old days (that are sometimes still around, which is why I mention that) where threads needed to "yield" (cooperative multitasking). There are a few tools in Qt that can make your live a lot easier, like QThreadPool and QRunnable. Implementing your own thread class is rarely needed and rather old school.

Couldn't recreate this on Windows so perhaps it's Mac only. Will try and test it on a pre-Lion Mac to narrow it down further. (Sorry, I know I seem to be basically using this thread as a notepad now, but hopefully I'll be able to cobble together enough info for a bug report at least).

You added that to the .PRO file and ran QMake afterwards? Anyways, as you say, case is closed.

Is it not working when you just run what you wrote here?

Thanks. I thought it was a scope problem but my typo masked my test results. It's always the little things!

You seem to be getting confused between the embedded QtScript which is a javascript interpreter embedded in your Qt application for writing extensions etc. and the javascript interpreter used in QtWebkit. Whilst these may be using the same underlying interpreter code, they are not the same thing. To do what you want, you need to integrate tightly with the javascript implementation being used by your web browser, which will basically mean working on the webkit code directly, not simply using the QWebView etc. APIs and the javascript bridge code.

It is certainly possible to get one X11 process to draw into a pixmap created by another by passing the Pixmap handle around, and I've written test code that does this. Unfortunately for video drivers etc. such as TV capture cards, I found that whilst the video4linux api specifies a Drawable which means that both a Window handle and a Pixmap handle should work, in many cases only a Window handle is actually supported by the drivers. Since sharing pixmaps between processes requires addition work anyway to ensure that you avoid race conditions, I doubt it is a good solution to your problem.

QNetworkManager can perform several requests at the same time. You have done nothing to make sure that your two http requests are not performed in parallel. Rather than creating your two requests at the same time, make the second one be created when the first one has completed. At the moment, your code inherently contains a race condition which means the behaviour is likely to be unpredictable. I'm not saying this is definitely what's happening here, just that unless you address this it's not going to be possible to determine what the code should do.

Hi everyone! Maybe it would be useful. Problem may be in path to image. Just by adding ":" a got my image to display. E.g.: "images/pic.jpg" -> ":images/pic.jpg".

Figured out a fairly low level way to do it - if anyone should care to do the same - it is achievable by "injecting" alpha data into the appropriate locations of a QByteArray and using QPixmap::loadFromData to turn it back into a pixmap

Hello thank you very much for your reply, I'll try it.

[quote author="przybysh" date="1330692429"][quote author="Volker" date="1330691822"] @przybysh: It's stated nowhere that loadFromData() requires the uchar array to be valid dring the life time of the QImage object. The source code doesn't suppose that either. The overload that takes a QByteArray just calls the uchar version, so anything that holds true for the one does so for the other too.[/quote] I agree that it's not stated explicitly. Later today I will provide example which proves that loadFromData() requires valid data during life time. For me loadFromData acts just like bq. QImage ( const uchar * data, int width, int height, Format format ) [/quote] OK, I took a look at the code, and my conclusions are that loadFromData follows a completely different code path than the constructor version, but that indeed the QByteArray version is the same as the uchar* version (in quite a weird way, actually[1]). The loadFromData version creates a QBuffer, and then uses the normal image loading code (QImageReader) to create a new image, which is then assigned to this using an explicit operator=() call. My conclusion is that the data does not need to stay valid after that. [quote author="phantom23" date="1330745543"]I have two follow-up questions if it is not too much of a hassle: If QImage does indeed create a deep copy of the image data, should I assume that the destructor will release the memory? Or should I create a QByteArray, copy the image data into that and release it myself when the iamge is no longer needed? [/quote] QByteArray will take care of clearing up its own data. There is no need for manual memory management here. QImage using this path indeed will own the data it stores the image in. [quote] I also have a question related to QTextDocument::addResource(). When I'm done with the image, should I re-set the resource name using a null QVariant, or is that not necessary?[/quote] I'm not sure what you mean by this exactly. [1] The QByteArray version calls the uchar* version, which in turn creates a QByteArray from the raw data. Doing it the other way around would have been more logical, IMHO.