Hi all,
There's a list of platform-specific functions from Qt 4:
http://doc.qt.io/qt-5/exportedfunctions.html
It looks like most of these functions are now gone. The non-existing
functions should be removed from the documentation, but 3 functions
remain in the code base:
*
Hi great Qt and KDE developers,
I like QML, it is high speed development language, easy to create candy
UI and not difficult to debug. KDE4 began to use it in some projects,
for example, KScreen`s kcm module, it used QML to take place of
traditional QWidget. and KDE5, it is full of QML, for
On 30 August 2015 at 16:02, Dmitry Volosnykh wrote:
> By the way, what are those "newer ones"?
I don't have a specific book in mind, but I would encourage newcomers
to learn the high-level API introduced in C++11 (std::thread,
std::async, etc.) instead of the
On 30 August 2015 at 16:32, Hausmann Simon
wrote:
> I think that there is a big difference between it being easy enough to find
> reading material and us - the project - making specific recommendations for
> material that we think is of particularly high
On 15/09/15 03:51, "Thiago Macieira" wrote:
>On Monday 14 September 2015 08:09:28 Sorvig Morten wrote:
>> Then the question is: which ones should QtGui link against? On other
>>words
>> OpenGL usage is not confined to platform plugins only.
>>
>> To me this points to
> On 15 Sep 2015, at 03:51, Thiago Macieira wrote:
>
> On Monday 14 September 2015 08:09:28 Sorvig Morten wrote:
>> Then the question is: which ones should QtGui link against? On other words
>> OpenGL usage is not confined to platform plugins only.
>>
>> To me this
On 09/14/2015 12:43 PM, André Somers wrote
> I guess that also means that your countTo() would need to be virtual,
> right? That would not be bc.
No. This would be just additional functionality of the
QIODevicePrivateLinearBuffer.
Since this buffer is available from QIODevicePrivate which itself
On 09/15/2015 03:53 AM, Thiago Macieira wrote:
> On Monday 14 September 2015 12:25:20 Andrzej Ostruszka wrote:
>> So what I'm aiming to is to make the "line" (or more generally "packet")
>> termination a bit more flexible, that is to allow user to specify the
>> delimiter. Currently I think the