Re: [Development] Nominating Pasi Petäjäjärvi for Approver status

[Al-Khanji Louai]

Congrats!

_
From: Blasche Alexander 
>
Sent: Tuesday, December 15, 2015 3:21 AM
Subject: Re: [Development] Nominating Pasi Petäjäjärvi for Approver status
To: >



Congratulations to Pasi. Jira and Gerrit rights have been set.


--

Alex



From: Development 
> 
on behalf of Agocs Laszlo 
>
Sent: Tuesday, November 24, 2015 10:04
To: development@qt-project.org
Subject: [Development] Nominating Pasi Petäjäjärvi for Approver status


Hello,



I would like to nominate Pasi Petäjäjärvi for Approver status in the Qt Project.



Pasi is the maintainer of the VxWorks port and has also been contributing a lot 
for other embedded platforms over the years.



Public Gerrit dashboard: 
https://codereview.qt-project.org/#/q/owner:pasi.petajajarvi,n,z

[https://codereview.qt-project.org/static/logo_open_gov.png]

Gerrit Code 
Review
codereview.qt-project.org
Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet 
Qt; Qt Repository Browser




Best regards,

Laszlo




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

Re: [Development] Nominating Samuli Pippo for Approver status

[Al-Khanji Louai]

+1!

_
From: Meadows Louis 
>
Sent: Wednesday, December 2, 2015 2:01 PM
Subject: Re: [Development] Nominating Samuli Pippo for Approver status
To: >, Agocs 
Laszlo >


+1 from me as well

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of 
Agocs Laszlo
Sent: Wednesday, December 02, 2015 6:13 AM
To: development@qt-project.org
Subject: [Development] Nominating Samuli Pippo for Approver status


Hello,

I would like to nominate Samuli Piippo for Approver status in the Qt Project. 
Samuli has been working on Qt's Embedded Linux support and Qt for Device 
Creation during the past few years. He is our resident Yocto expert and is 
contributing to meta-qt5 as well.

Public Gerrit dashboard: 
https://codereview.qt-project.org/#/q/owner:samuli.piippo,n,z

meta-qt5 contributions: 
https://github.com/meta-qt5/meta-qt5/commits/master?author=sapiippo

Best regards,
Laszlo



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

Re: [Development] Nominating Pier Luigi Fiorini (plfiorini) as an Approver

[Al-Khanji Louai]

 On 15 Jul 2015, at 11:05, Andy Nichols andy.nich...@theqtcompany.com wrote:
 On 14 Jul 2015, at 16:37, Robin Burchell robin...@viroteck.net wrote:

 Hi,

 I would like to nominate plfiorini for Approver status.

 Would anyone like to second?

+1 from me as well


Another +1 from me too.

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

Re: [Development] Qt LTS C++11 plans

[Al-Khanji Louai]

What they did was to move registration of meta object content to runtime. They 
basically have structs with static variables and they rely on initialization of 
these variables at program start-up. It's a lot of macro magic and relies on 
things like __LINE__ to create unique tokens.

The info above is based on this presentation, the meta object stuff is covered 
from slide 20 onwards: 
https://docs.google.com/presentation/d/1Sxei-Em6cnYbE0Zj16j6gwF4SIvGJIE_1tb4P78RN3o/edit?usp=sharing

I don't think they did anything to the container classes, but I haven't looked.

Cheers,
Louai

 -Original Message-
 From: development-bounces+louai.al-khanji=theqtcompany.com@qt-
 project.org [mailto:development-bounces+louai.al-
 khanji=theqtcompany@qt-project.org] On Behalf Of Thiago Macieira
 Sent: Thursday, June 25, 2015 7:03 PM
 To: development@qt-project.org
 Subject: Re: [Development] Qt LTS  C++11 plans
 
 On Thursday 25 June 2015 13:18:17 Cristian Adam wrote:
  They've got rid of moc and plan to replace Qt containers with std
 ones.
 
 If they got rid of moc, then they also got rid of QtDBus, QtScript and
 QtQml.
 That doesn't sound like a fork of Qt.
 
 Getting rid of moc is waiting for SG7 from the standards committee to
 come up
 with a language reflection feature. At the current pace, it might
 happen as a
 TS for C++2x, so we may be able to start using it in Qt around 2025.
 
 And if they replaced Qt containers with std ones, what replaced QString?
 Because the standard ones are nowhere near feature parity with QString.
 Unfortunately, CopperSpice's documentation is offline, so I can't tell.
 
 Doesn't seem like a serious project to me. That sounds a lot like TQt
 from the
 Trinity Project...
 
 --
 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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Specifying module dependencies

[Al-Khanji Louai]

 To the CI system the optional dependencies are
 also required ones.

So we're not going to test the optionality of said dependencies?

Louai


 -Original Message-
 From: development-bounces+louai.al-khanji=theqtcompany.com@qt-
 project.org [mailto:development-bounces+louai.al-
 khanji=theqtcompany@qt-project.org] On Behalf Of Hausmann Simon
 Sent: Wednesday, June 10, 2015 9:48 PM
 To: Thiago Macieira; development@qt-project.org
 Subject: Re: [Development] Specifying module dependencies
 
 Hi,
 
 Why do we need to pin anything beyond the regular git submodules
 handling of qt5.git (where the information is in the tree object)?
 
 In think we should have a configuration file in each module listing
 required and optional dependencies. Qt.pro can interpret that file and
 so can the CI system. To the CI system the optional dependencies are
 also required ones.
 
 Simon
 
   Original Message
 From: Thiago Macieira
 Sent: Wednesday, June 10, 2015 18:44
 To: development@qt-project.org
 Subject: Re: [Development] Specifying module dependencies
 
 
 On Wednesday 10 June 2015 18:30:34 Frederik Gladhorn wrote:
  4) qt5.git
  in qt.pro we list all modules again, with deps:
  addModule(qtdeclarative, qtbase, qtsvg qtxmlpatterns)
  (amusingly this is not even correct, qtsvg is not a dependency of
  qtdeclarative any more)
 
 That's an optional dependency.
 
 Note that the qt.pro file allows us to do the full build, so unless we
 teach
 qmake to parse any other sources, we'll need to keep it.
 
 That said, I don't think qt.pro should keep SHA-1 of pinned revisions,
 so
 we'll need something else anyway.
 --
 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
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Long Term Release discussion

[Al-Khanji Louai]

So this bit in the article is not factual?

Windows Embedded Compact no longer provides its own tool chain (compiler, 
assembler, and make), but instead use the same tools as desktop development.

Louai


 -Original Message-
 From: development-bounces+louai.al-khanji=theqtcompany.com@qt-
 project.org [mailto:development-bounces+louai.al-
 khanji=theqtcompany@qt-project.org] On Behalf Of Gunnar Roth
 Sent: Friday, June 19, 2015 7:50 PM
 To: Knoll Lars
 Cc: development@qt-project.org; Thiago Macieira
 Subject: Re: [Development] QtCS: Long Term Release discussion
 
 
  Am 19.06.2015 um 18:38 schrieb Knoll Lars
 lars.kn...@theqtcompany.com:
 
 
  There was never an intention to remove it after 5.6. But I was hoping
 that we could be using VC++ 2013 (and support wec2013 with it). Looks
 like that is unfortunately not the case. That implies that our new
 compiler baseline will stay with 2012 for some time :/
 
 
 Thanks a lot for your answer. That is a big relief.
 
 Regards,
 Gunnar
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New Module for Serial Buses

[Al-Khanji Louai]

 I guess I was expecting something higher-level... :)

One step at a time. :)

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

Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5

[Al-Khanji Louai]

 -Original Message-
 From: development-bounces+louai.al-khanji=theqtcompany.com@qt-
 project.org [mailto:development-bounces+louai.al-
 khanji=theqtcompany@qt-project.org] On Behalf Of Marc Mutz
 Sent: Monday, May 18, 2015 2:47 PM
 To: development@qt-project.org
 Subject: Re: [Development] QTextStream::readLine(0) is an ambiguous
 overload in 5.5
 
 On Monday 18 May 2015 12:17:32 Koehne Kai wrote:
  Can you elaborate? We're talking about in/out parameters here, where
  raw pointers IMO are still perfectly valid. What do you expect the
  signature  of readLine(QString *line) to be in C++14?
 
 QString readLine(QString reuseThisStringsCapacity);
 
 --
 Marc Mutz marc.m...@kdab.com | Senior Software Engineer
 KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
 Tel: +49-30-521325470
 KDAB - The Qt Experts
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


Ooh, a bike shed thread! I vote that we implement N4282 and make the function 
signature

bool readLine(std::observer_ptrQString, qint64);

This is obviously better since we now can report failures *AND* make object 
lifetimes explicit!

/snark

:)

Louai

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

Re: [Development] [Interest] Qt XML patterns

[Al-Khanji Louai]

I've used it in various projects to massage badly designed XML data into a 
nicer format using  XQuery. It's a shame the module isn't worked on more, 
sometimes one line of XQuery solves a problem that would take a lot of effort 
with our XML stream reader.

Louai

 -Original Message-
 From: development-bounces+louai.al-khanji=theqtcompany.com@qt-
 project.org [mailto:development-bounces+louai.al-
 khanji=theqtcompany@qt-project.org] On Behalf Of Samuel Gaist
 Sent: Friday, May 08, 2015 3:47 PM
 To: Gladhorn Frederik
 Cc: development@qt-project.org
 Subject: Re: [Development] [Interest] Qt XML patterns
 
 On 8 mai 2015, at 14:32, Frederik Gladhorn
 frederik.gladh...@theqtcompany.com wrote:
 
  Hello all,
 
  I've just looked a bit at the QtXmlPatterns module. The module has a
 few
  issues and is not actively maintained. I wonder if it should see
 improvements
  or if there are good alternatives which might be more spec compliant
 which
  people end up using. One option in the long term might be to wrap some
 other
  library instead of trying to do our own.
 
  I'm interested in usage of it - please let me know if you do use it or
 if you
  ended up using alternative libraries. I'm also interested in which
 parts,
  since the module supports XPath, XQuery, XSLT and XML Schema
 validation.
 
  Greetings,
  Frederik
 
  Please not that this question is unrelated to the XML classes in
 QtBase (sax,
  stream-reader/writer, dom).
 
 
 Hi,
 
 I've used it for schema validation which worked nicely.
 
 Most of the questions i've seen on the forum were related to XQuery and
 XPath and IIRC XmlListModel was involved most of the time so not
 directly this module.
 
 Samuel
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCore missing check for memory allocation

[Al-Khanji Louai]

It's my understanding that on Windows you link the global operator new/delete 
replacement into every dll separately.

A howto:

1) Implement your replacement global operator new and delete. Just do so in a 
single .cpp file, you don't need a header.
2) Compile this into a static library.
3) Pass the static library to the configure script as an extra library so that 
it is linked into every Qt .dll.

If you want, also link it into your main .exe or just add the .cpp directly. 
You don't need to link to Qt statically, but you do need to compile Qt yourself 
in order to statically link into every dll your custom implementation of global 
operator new  delete.

Now, replacing malloc/free on Windows is non-trivial. To my knowledge, your 
best bet would be to use detours [1], but I have never tried it.

Cheers,
Louai

[1] http://research.microsoft.com/en-us/projects/detours/


From: development-bounces+louai.al-khanji=theqtcompany@qt-project.org 
development-bounces+louai.al-khanji=theqtcompany@qt-project.org on behalf 
of Koehne Kai kai.koe...@theqtcompany.com
Sent: Tuesday, March 10, 2015 10:18 AM
To: Alex Montgomery; Knoll Lars
Cc: development@qt-project.org
Subject: Re: [Development] QtCore missing check for memory allocation

 -Original Message-
 From: development-bounces+kai.koehne=theqtcompany.com@qt-
 project.org [mailto:development-
 bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of
 Alex Montgomery
 Sent: Monday, March 09, 2015 6:56 PM
 To: Knoll Lars
 Cc: development@qt-project.org
 Subject: Re: [Development] QtCore missing check for memory allocation

 On Mon, Mar 9, 2015 at 12:57 AM, Knoll Lars
 lars.kn...@theqtcompany.com wrote:

  Yes, the best solution IMO is still to use your own malloc and
  operator new replacements. In addition, OOM handlers on the OS level can
 help.

 Except that dynamically linked Windows Qt applications (read: most) don't
 work this way, so Windows users are left out in the cold. DLLs do not allow
 you to simply replace one new operator across link boundaries. See the
 comments in this Qt bug:
 https://bugreports.qt.io/browse/QTBUG-37395

True.

 Is there any strategy for the large body of Qt developers targeting Windows,
 or is statically linking the only supported method for replacing Qt allocators
 on Windows?

You almost definitely need to recompile Qt , because you can't really override 
operator new/delete across DLL boundaries (as you already pointed out in the 
bug report).

Question is whether you can easily force all Qt modules to use a custom 
operator new / delete ... I've seen suggestions [1] to define an inline 
operator new / delete (e.g. in qglobal.h), but that seems to violate the 
standard explicitly stating that The program's definitions shall not be 
specified
as inline  (C++14 17.6.4.3.3 3). Might nevertheless work though, since there's 
a high chance that qglobal.h is included in all places where Qt 
allocates/deallocates memory...

Regards

Kai

[1]: 
https://social.msdn.microsoft.com/Forums/vstudio/en-US/ab642c88-2d2d-4f5d-9fd7-2341442d5a46/replacing-new-and-delete-how-to-export-the-implementation?forum=vclanguage)

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

Re: [Development] QtCore missing check for memory allocation

[Al-Khanji Louai]

Sure, here's what I know:

Regarding operator new:

http://en.cppreference.com/w/cpp/memory/new/operator_new

C++11 cleans up the exception specifications and specifies that the no-throw 
single object variant is called by the standard implementations of all other 
versions.

Regarding operator delete:

http://en.cppreference.com/w/cpp/memory/new/operator_delete

C++11 again cleans up the exception specifications and specifies like with 
operator new that the single object variant is called by the standard 
implementations of all other variants.
C++14 introduces sized global delete which can be very useful for custom 
allocators (for a classic example see the small object allocator in 
Alexandrescu's Modern C++ Design, source code for his library: 
http://sourceforge.net/p/loki-lib/code/HEAD/tree/trunk/).


That the various implementations all internally by default call the single 
object versions of new/delete has long been the canonical thing to do, but it 
wasn't actually specified by the standard. The noexcept cleanups are 
straight-forward but necessary. The really interesting bit to me is the 
addition of global sized operator delete in C++14.


--Louai


 -Original Message-
 From: Gunnar Roth [mailto:gunnar.r...@gmx.de]
 Sent: Friday, February 27, 2015 2:11 PM
 To: Al-Khanji Louai
 Cc: development@qt-project.org
 Subject: Aw: Re: [Development] QtCore missing check for memory allocation
 
 Hi,
 
   in fact both C++11 and C++14 have improved the ways in which the
 new/delete operators can be overridden.
 
 can you give me some links describing these improvements?
 
 regards,
 Gunnar Roth
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCore missing check for memory allocation

[Al-Khanji Louai]

In that case they cannot be overwritten without a recompile. Which brings me 
back to my original comment from yesterday (to which no one replied):

How is that different from linking a custom implementation of operator 
new/operator delete and malloc/free into Qt?

These are embedded use-cases anyway, so you wouldn't be using a stock Qt 
binary.  Implementing the above is well-documented, and in fact both C++11 and 
C++14 have improved the ways in which the new/delete operators can be 
overridden.

Just put your implementation in a static lib and pass it to the configure 
script as an additional library.

On Linux you can also inject such a library using LD_PRELOAD, most operating 
systems have a similar mechanism. Unlike changing a header, that doesn't 
require a recompile of Qt.

--Louai


 -Original Message-
 From: development-bounces+louai.al-khanji=theqtcompany.com@qt-
 project.org [mailto:development-bounces+louai.al-
 khanji=theqtcompany@qt-project.org] On Behalf Of Koehne Kai
 Sent: Friday, February 27, 2015 12:57 PM
 To: Robin Burchell; development@qt-project.org
 Subject: Re: [Development] QtCore missing check for memory allocation
 
 
 
  -Original Message-
  From: development-bounces+kai.koehne=theqtcompany.com@qt-
  project.org [mailto:development-
  bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of
  Robin Burchell
  Sent: Friday, February 27, 2015 11:47 AM
  To: development@qt-project.org
  Subject: Re: [Development] QtCore missing check for memory allocation
 
  On Fri, Feb 27, 2015 at 9:20 AM, Oswald Buddenhagen
  oswald.buddenha...@theqtcompany.com wrote:
   The argument is that it implies runtime overhead. See Robin's email
   for numbers. This is asking for making the code slower on the very
   devices where it needs to run faster.
  
   i don't trust this number. i don't know how qMalloc was implemented,
   but there is no way a simple forwarding wrapper would add 10%
 overhead
   to malloc (esp. in an optimized build).
   modern processors even have a specific optimization for call
   forwarding (or whatever it's called properly).
 
 qmalloc and friends where implemented in qmalloc.cpp. That is, they can't be
 inlined, and every call to it from another library will be a cross-library 
 one.
 
 A inlined, header-only wrapper should get away with this.
 
 Regards
 
 Kai
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCore missing check for memory allocation

[Al-Khanji Louai]

How is that different from linking a custom implementation of operator 
new/operator delete and malloc/free into Qt?

These are embedded use-cases anyway, so you wouldn’t be using a stock Qt 
binary.  Implementing the above is well-documented, and in fact both C++11 and 
C++14 have improved the ways in which the new/delete can be overridden.

Just put your implementation in a static lib and pass it to the configure 
script as an additional library.

--Louai


Maybe a bit off-topic: can we introduce our own (probably customizable)  memory 
allocation API, something like Apple's CFAllocator [1], and move Qt internals 
to use it instead of malloc/realloc/free (and maybe instead of some 
new/delete-s, based on some policies)?
Then we could let the user to decide if he needs a OOM safety, i.e. with 
QAllocator::setDefaultAllocator(..)
Such a centralized memory allocation routines also could be very useful in 
debugging or memory consumption monitoring.

Regards,
Konstantin

[1] 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFAllocatorRef/

2015-02-26 0:29 GMT+04:00 Marc Mutz 
marc.m...@kdab.commailto:marc.m...@kdab.com:
On Wednesday 25 February 2015 16:30:56 Giuseppe D'Angelo wrote:
 And on the other hand, this assumption of having infinite memory has
 held for a while

Only in the niche that Qt exists in. Now, the question is whether Qt does not
play a role in systems that handle oom gracefully because Qt doesn't handle
them gacefully or whether it doesn't play a role in those systems because
there are no such systems.

But I'm sure there are embedded systems that fall in between the desktop model
of inifinite VM space and hard-realtime systems that allow no dynamic memory
allocations after program initialisation. For such systems, recovering from
oom is actually a plausible alternative. Relying on the oom killer in a soft
realtime application is asking for trouble. It can literally take an hour for
the system to recover. I just experienced a 50min thrashing when I dared to
start up a 4GB VM without waiting for qtcreator to fully quit. The oom killer
killed qt-creator, but it _did_ take 50mins.

As Ossi said, overcommitting is likely turned off in those systems. BTW, IIRC,
you also get nullptr mallocs (without thrashing swap first when you run into
user-defined ulimits.

If Qt wants to be(come) relevant to that part of the embedded space (or that
part of server space that still uses ulimit), we better stop acting like
there's only infinite memory.

 -- why should now people have a slower library because
 of all those checks?

Q_CHECK_PTR does not necessarily make the library slower. It only needs to be
applied to malloc/calloc and nothrow operator new, because ordinary new
already throws. We can port such code to normal operator new instead.

Thanks,
Marc

--
Marc Mutz marc.m...@kdab.commailto:marc.m...@kdab.com | Senior Software 
Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
www.kdab.comhttp://www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) 
+46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list
Development@qt-project.orgmailto:Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Adding new third party component three.js to Qt?

[Al-Khanji Louai]

The thread seems to have derailed quite badly, so let's reboot it and return to 
the original topic of how to bundle the javascript code.

If I understand correctly, there is a desire to be able to provide the modified 
three.js code as a separate package.

We have an existing solution for this, the configure script. Wouldn't the whole 
issue be solved by just adding a compile-time check for the library? If it's 
found on the system, fine, use that code. If not, use the code bundled with Qt. 
Add a switch to override the selection. Treat like any other library, because 
it is.

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

Re: [Development] Adding new third party component three.js to Qt?

[Al-Khanji Louai]

 On Wednesday 7. January 2015 06.03.14 Keränen Pasi wrote:
  Hi,
 
  I¹d like to open the discussion on including the three library as part of
  Qt 5.6 and onwards. Mainly because this would give our users a better
  experience if we¹d bundle the right, tested version of Three.js together
  with the Qt version it was tested on.
 
  I¹ve been pushing the Qt Canvas3D component onwards and timewise it
 should
  be landing to Qt 5.5 release. The WebGL-like API (non-conformance tested)
  it offers is very low level and most users will not like to work on that
  level. To that end I¹ve ported the WebGL based Three.js scenegraph library
  available at http://threejs.org on top of Canvas3D. You can find the
  latest version from master branch at https://github.com/tronlec/three.js
 
  The reason for picking this particular library over others are:
  * It¹s one of the most active WebGL scene graph projects out there.
  * It¹s well done, with examples, API documentation etc.
  * It has excellent support form community in the form of tutorials,
  websites, discussion forums etc.
  * It is available under permissive MIT license:
  https://github.com/mrdoob/three.js/blob/master/LICENSE
 
  In Qt 5.5 we¹ll include a few examples that will have this library as part
  of the examples.
 
  The library will for now at least need some porting effort to make it run
  on top of Canvas3D as there are some HTML depencencies that need to be
  handled, plus V4VM has a few quirks that need to be accounted for.
  Hopefully some of the V4VM quirks are bugs and will be fixed in due time,
  but the HTML dependencies do remain. And my current experience with
  graphics APIs is that you want to test the whole stack together. If we
  e.g. add support for new extensions in Canvas3D, that can activate new
  codepaths in Three.js that again need testing and possibly new Qt specific
  delta must be added to the three.js for those parts.
 
 
  Comments? Thoughts?
 
 Sounds like a good idea to me. What's the size (lines of code) that we are
 talking about here? Is it just one big minified .js file?
 
 
 Simon

Out of curiosity, how large are the changes that were required to port the 
library?

-- Louai

 

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

Re: [Development] changing Q_GADGET

[Al-Khanji Louai]

Out of the box, C++ makes class member declarations private. I quite strongly 
feel that changing that behavior in a macro is not what the user expects. So 
for me at least the better API box is not being checked here - I quite 
regularly declare private variables under Q_OBJECT and have done so with 
Q_GADGET as well.

-- Louai
 
 Hi,
 
 Monsieur Goffart did awesome work in the dev branch on allowing
 structures with
 Q_GADGET to have properties and invokable methods. This brings the macro
 to a
 much wider audience and I'd like to use this opportunity to propose a slight
 change to it that may be controversial:
 
 The macros Q_OBJECT and Q_GADGET both - towards the end of their
 definition -
 change the member access permission level to private. It's always been
 that
 way.
 
 I'd like to propose changing Q_GADGET to not change the access permission
 level, so that you can write
 
 struct MyStructure
 {
 Q_PROPERTY(int x MEMBER x)
 Q_GADGET
 
 int x;
 }
 
 
 I feel that Q_GADGET has its primary use with structures and the default
 access level for those is public. I find it awkward that you currently have to
 write:
 
 structure MyStructure
 {
 Q_PROPERTY(int x MEMBER X)
 Q_GADGET
 public:
 int x;
 }
 
 
 The proposed change would have two effects:
 
 1) It makes any existing code that _relies_ on Q_GADGET turning to private
 suddenly expose members in structures.
 
 2) On paper it breaks binary compatibility with MSVC, in the unlikely event
 that somebody
 a) produces a DLL and cares about binary compatibility
 b) exposes bare structures
 c) relies on Q_GADGET turning access permission levels to private
 
 
 I feel that the effects are negligible compared to the benefit of a better 
 API.
 
 What do you think?
 
 
 Simon
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Paul Lemire as Approver

[Al-Khanji Louai]

Another +1 from me.

Sorry for the top post.

-- Louai

 -Original Message-
 From: development-bounces+louai.al-khanji=theqtcompany.com@qt-
 project.org [mailto:development-bounces+louai.al-
 khanji=theqtcompany@qt-project.org] On Behalf Of Milian Wolff
 Sent: Friday, November 14, 2014 1:07 PM
 To: development@qt-project.org
 Subject: Re: [Development] Nominating Paul Lemire as Approver
 
 On Friday 14 November 2014 10:24:19 Sean Harmer wrote:
  Hi,
 
  I would like to nominate Paul Lemire as an approver of the Qt Project.
 
  Paul has been the main development fire power for the Qt3D rewrite. Paul
 has
  an excellent understanding of the new Qt3D architecture.
 
  His contributions and reviews are at:
 
  https://codereview.qt-project.org/#/q/owner:paul.lemire,n,z
  https://codereview.qt-project.org/#/q/reviewer:paul.lemire,n,z
 
  Can I get a So say we all from the collective please?
 
 +1 from my side. It is a pleasure working with him on Qt3D these past weeks
 and letting him explain me whats going on there :)
 
  Disclaimer: Paul is a colleague and works at KDAB.
 
 The above also applies for me.
 
 Bye
 --
 Milian Wolff | milian.wo...@kdab.com | Software Engineer
 KDAB (Deutschland) GmbHCo KG, a KDAB Group company
 Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
 KDAB - Qt Experts - Platform-independent software solutions
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The dark side of QtMultimedia

[Al-Khanji Louai]

  Usually, I’d say that should be gstreamer’s job. They should provide unit
  tests that allow testing a gstreamer implementation on a linux
  system/board.
 
 Agreed, and you'd expect that a decent Linux distribution runs them to be
 sure
 that they've installed everything correctly.
 
 But we're discussing a non-decent state already. If we could provide a
 handful
 of manual test scripts that let people check their conditions, we can isolate
 the problem and convince them it's not our fault.
 

I have to say I agree. In practice a lot of systems are very poorly configured 
to the point that functionality that the vendor specifically advertises does 
not work.

I'm currently looking at a board where a glClear() followed by eglSwapBuffers() 
does not run above 52 fps on a 60hz display. This is clearly an issue outside 
Qt - I am able to demonstrate this with a sample that uses DRM, GBM and EGL 
directly. As long as Qt is in the equation there is always the suspicion that 
the cause lies with it.

This is not the first time I have to show that some issue is not caused by Qt. 
I have also watched many of my colleagues go through contortions to convince 
customers that their setups are just broken or plain not fast enough - although 
of course sometimes it really is down to something within Qt. :) Even for those 
cases an independent Qt Conformance Suite would be useful.

Maybe such tests could be incorporated into the module unit tests as a sort of 
precondition - if these tests don't work, then the module won't work properly 
either.

-- Louai

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

Re: [Development] Nominating Louai Al-Khanji as approver

[Al-Khanji Louai]

Thanks for the votes of confidence!


-- Louai



From: development-bounces+louai.al-khanji=theqtcompany@qt-project.org 
development-bounces+louai.al-khanji=theqtcompany@qt-project.org on behalf 
of Blasche Alexander alexander.blas...@theqtcompany.com
Sent: Friday, October 10, 2014 11:17 AM
To: development@qt-project.org
Subject: Re: [Development] Nominating Louai Al-Khanji as approver


Congratulations. The Approver rights have been set in Jira and Gerrit.


--

Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
development-bounces+alexander.blasche=digia@qt-project.org on behalf of 
Friedemann Kleint friedemann.kle...@digia.com
Sent: Friday, September 19, 2014 10:31
To: development@qt-project.org
Subject: [Development] Nominating Louai Al-Khanji as approver

Hi,
I'd like to nominate Louai Al-Khanji as approver in the Qt Project:
https://codereview.qt-project.org/#/q/owner:louai.al-khanji,n,z
https://codereview.qt-project.org/#/q/reviewer:louai.al-khanji,n,z
He implemented the Windows Direct2D platform plugin (which works well beyond 
expectations) and has also done significant work in other areas (Qt3D, Wayland).
Regards,
Friedemann

--
Friedemann Kleint
Digia, Qt

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

Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

[Al-Khanji Louai]

It's not a platform bug. It's an application/framework (Qt) bug.


Unix paths are just a byte array, where certain bytes have special meaning 
(mostly just '/'). Passing around those byte arrays from/to platform functions 
will always work correctly.


The problem is that Qt tries to interpret those byte strings by converting them 
to unicode for use inside QString. There's no guarantee that this conversion 
will succeed using the current system encoding, as the file name may have 
previously been encoded with a different encoding.


On Unix, the correct way to handle paths is to never encode/decode the byte 
array.


Showing a path in a UI is a separate issue from just passing it around and/or 
modifying it.


-- Louai



From: development-bounces+louai.al-khanji=theqtcompany@qt-project.org 
development-bounces+louai.al-khanji=theqtcompany@qt-project.org on behalf 
of Konstantin Ritt ritt...@gmail.com
Sent: Thursday, October 9, 2014 3:44 AM
To: Marc Mutz
Cc: development@qt-project.org
Subject: Re: [Development] The life of a file name and other possibly 
mal-encoded strings on non-Windows systems

2014-10-09 3:57 GMT+04:00 Marc Mutz 
marc.m...@kdab.commailto:marc.m...@kdab.com:
Hi Julien,

On Tuesday 07 October 2014 14:30:59 Julien Blanc wrote:
 However, i agree that changing this would :
 * break a lot of code

No, it cannot, if, as I propose, it's added to Qt 5.

 * permit only to solve really lower level / corner case issues

The value lies _also_ in being able to iterate over weird filenames (where
weird simply means plugging in a USB stick into an otherwise UTF-8-only
system).

Qt doesn't mount that USB stick, Qt doesn't manage mounting [and whatever else 
system-wide] flags and settings; so should Qt ever care about some 
platform/misconfiguration issues?
IMO, issues like this one should (or even must) be fixed at a platform level, 
whilst high-level frameworks should not even try to workaround them. This is 
exactly what we were decided to do with the space character(s) at the end of 
file name issue on Windows, BTW.

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