Re: [Development] Qt6 repo

[Eric Lemanisser]

that's the obvious choice, if it was not already used by qt4.

Eric


Le mer. 13 janv. 2021 à 12:27, Allan Sandfeld Jensen  a
écrit :

> On Mittwoch, 13. Januar 2021 11:36:14 CET Nibedit Dey wrote:
> > Hello Everyone,
> >
> > Is there any plan to move the qt6 source code to a different repo (qt6)?
> > Currently, the branch lies inside the qt5 repo.
> > Is there going to be a Qt6 super module in near future?
> >
> If it is going to be a general root name. I would suggest qt.git, so we
> don't
> need to rename again for qt 7.
>
> Allan
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] The future of smart pointers in Qt API

[Eric Lemanisser]

Are we really considering abandoning the parent-child ownership for
qt6 ? that would be a huge breaking change

>  I would like to separate pointers with simple ownership and complicated 
>  ownership. We could solve passing of raw pointers with simple ownership 
>  first using standard smart pointers. Where as the more complicated 
> pointers  would require special classes like those Daniel Teske has been 
> working on. I'm not sure how to properly identify what is the "complicated 
> ownership". I don't think that there are places in Qt API where we really 
> need something more complicated than regular shared/weak/unique pointers. 
> Even intrusive pointers are not required I guess. When you think about 
> something more complicated, this is probably an architectural problem (like 
> with parent-child) or bad API design. Can you provide some real examples 
> where we need something more complicated than regular smart pointers, please?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Issue while compiling with MinGw_64

[Eric Lemanisser]

it looks like https://bugreports.qt.io/browse/QTBUG-67443 what version of
mingw are you using ?

Le mar. 31 juil. 2018 à 17:00, Thiago Macieira 
a écrit :

> On Tuesday, 31 July 2018 06:21:41 PDT Khuram Ali via Development wrote:
> > qglobal.cpp::5: error: '_wgetenv_s' was not declared in this scope
>
> The problem is your MinGW headers and CRT. You need one that has
> _wgetenv_s.
>
> In the MinGW-w64 headers I have, they exist. So check if you should erase
> your
> MinGW installation and install another.
>
> --
> 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] gsl::owner (Was: Setters: Clarifying the ownership)

[Eric Lemanisser]

Please, don't introduce another type alias. It would loose the advantage of
static analysis like
http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-owning-memory.html

Le mar. 31 juil. 2018 à 14:52, Giuseppe D'Angelo via Development <
development@qt-project.org> a écrit :

> Hi,
>
> On 31/07/18 13:11, Sérgio Martins via Development wrote:
> > I would recommend however that our docs show T* instead of gsl::owner
> > and continue to include "Takes ownership of foo" in the text.
> > While I believe in self-documenting signatures I think it's too much
> > noise and hurts readability, and most devs never heard of gsl.
> >
> > Should be just an aid for tooling IMO.
>
> I agree with the rest of your email, but I kind of disagree with this
> particular point, for different reasons:
>
>
> * Because we need to educate our users that there's more C++ than Qt out
> there, and the Core Guidelines and the GSL are a fundamental part of
> knowledge for a C++ developer.
>
> * Even if we consider talking about the GSL too much of a "distraction"
> in the docs, we can simply add our own qOwner type alias, with identical
> semantics, and document what it does and what it means in signatures.
>
> * Leaving gsl::owner in the signature of a function documentation can
> help clarify situations where the textual documentation does not say
> anything about the ownership. At least, it's one more safeguard against
> adding functions that take/return pointers and don't clearly document
> the ownership.
>
>
> However, from a practical point of view, unless someone adds gsl::owner
> _everywhere_ to Qt, we can't report it in the docs, as they would
> otherwise be inconsistent :-(
>
>
> My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53 <04%2090%2084%2008%2053>,
> http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> 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] gsl::owner (Was: Setters: Clarifying the ownership)

[Eric Lemanisser]

+1

Le mar. 31 juil. 2018 à 13:11, Sérgio Martins via Development <
development@qt-project.org> a écrit :

> On 2018-01-19 18:32, Thiago Macieira wrote:
> > On Friday, 19 January 2018 09:26:10 PST Edward Welbourne wrote:
> >> Jaroslaw Kobus (19 January 2018 17:09)
> >>
> >> > "give" may be confused with "get", which is usually an accessor. I may
> >> > also think "Am I giving (to QCoreApplication)" or "The
> >> > QCoreApplication is giving (me)". Maybe it is just a matter of the
> >> > other verb? Absorb, hand over, hand on, suck in, swallow...
> >>
> >> However, we have plenty of take functions, where the caller takes
> >> ownership from the object on which the method is called; so it makes
> >> sense that a give function would be the caller giving ownership to the
> >> object on wich the method is called.
> >>
> >> Thus we'd keep child.setParent(newParent), since the child doesn't
> >> take
> >> ownership of the parent; but QMainWindow's setCentralWidget() would
> >> become giveCentralWidget(), matching its takeCentralWidget().  This
> >> would save the search for its doc, to find that it does indeed take
> >> ownership.
> >>
> >> The signature is, in any case, always sufficient to make clear that a
> >> give()r isn't a get()ter.
> >
> > Let's stop the discussion about method *naming* right here. We're not
> > going to
> > change hundreds of getters and setters now or even in Qt 6.
> >
> > Let's instead find a solution that either uses macros or uses simple
> > binary-
> > compatible pointer wrappers like GST.
> >
> > And be careful with template functions. Changing from T to Something
> > may
> > change what gets deduced.
>
>
> Nuno experienced a crash [1] which could have been easily caught by a
> compiler plugin or clang-tidy if we used gsl::owner or similar.
>
> So to try to move things forward I asked Marc to restore his gsl::owner
> change [2].
>
> I would recommend however that our docs show T* instead of gsl::owner
> and continue to include "Takes ownership of foo" in the text.
> While I believe in self-documenting signatures I think it's too much
> noise and hurts readability, and most devs never heard of gsl.
>
> Should be just an aid for tooling IMO.
>
>
>
> [1] http://lists.qt-project.org/pipermail/interest/2018-July/030530.html
> [2] https://codereview.qt-project.org/#/c/178107/
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090 <+46%20563%2054%2000%2090>, USA
> +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> 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] Relocating a Qt compilation

[Eric Lemanisser]

Hello,

I'm currently working on a Qt package for conan, and the fact that qt files
have absolute path hard-coded in them is problematic. The use case is the
following : a user downloads a binary distribution of Qt
(qmake+moc+include+libs etc.), which is then stored in a directory which
cannot be known when compiling said distribution.
MaintenanceTool does the exact same job of downloading existing binaries
and storing them in directory chosen by the user, so it has to patch the
files. Are MaintenceTool's sources available, or at least the patching
process ? There used to be a small tool (qpatch? qtpatch?) doing that, but
I cannot find it

Thanks!

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

Re: [Development] Fornux C++ Superset

[Eric Lemanisser]

What about
void foo(int ()[3])
and
template
void foo(int ()[N]) ?
Both of these functions make sure the caller and the callee use the same
array size at compile time. I don't see anybody giving away this kind of
security, especially fro functions called across translation units. Does
your system store the length of the array next to the pointer at runtime ?
What is the cost of this ?

Le mer. 25 avr. 2018 à 14:58, Phil Bouchard <philipp...@gmail.com> a écrit :

> Eric Lemanisser <eric.lemaniss...@gmail.com> wrote:
> > Le mer. 25 avr. 2018 à 14:03, Phil Bouchard <philipp...@gmail.com> a
> écrit :
> >
> >> On 04/25/2018 04:46 AM, Edward Welbourne wrote:
> >>> Phil Bouchard (24 April 2018 19:05)
> >>>> I’m not sure if you read the link I posted about static analysis but a
> >>>> software bug can cause billion dollar projects like space shuttles to
> >> fail.
> >>>> Maybe MS Word was a bad example but they can be very costly.
> >>>
> >>> The Columbia crash wasn't a (computer) software issue.  One can think
> of
> >>> the organisational failure that lead to it as a (human) software issue,
> >>> but I don't think we have static analysis software for that.  The
> >>> closest you'll get is an ISO 9000 compliance auditor.
> >>>
> >>> The Ariane 5 crash was a software error, but it wasn't a memory abuse;
> >>> it was using an under-sized integer to hold a value that overflowed.
> >>> With luck, static analysis would find that, but it's a pointer abuse.
> >>>
> >>> The loss of the Mars Climate Orbiter involved a software bug, but it
> was
> >>> a wrong choice of units rather than a pointer abuse.  Mixing archaic
> >>> silly units with sensible SI ones has caused more grief for space
> >>> missions than pointer abuses.
> >>
> >> You need to see the big picture; memory leaks are the most difficult
> >> problems to solve. In the labs you stress-test your software for a few
> >> days but in real life your software is going to run for a few months
> >> consecutively.
> >>
> >> I was working for a WebKit-based browser for TVs for a software company
> >> and the browser kept crashing after a day of usage because of memory
> >> leaks. I mean how are you supposed to watch TV if you need to reboot the
> >> set-top box every day at a random time?
> >>
> >> Also do you really want to spend time running Valgrind on iPhones or
> >> Androids to find these problems? First Valgrind won't fix the problem,
> >> second it is not giving always the same answer and third it doesn't run
> >> on all embedded devices.
> >>
> >> There is more you can read about the subject here:
> >>
> >> "Real Production Issue - Hard to find memory leaks"
> >> https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh
> >>
> >> And BTW:
> >>
> >> "Garbage collection is out the window, because you cannot know when it
> >> is going to happen or how long it will take, which leads to stuttering
> >> frame rates."
> >>
> >>
> https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games
> >>
> >>> So bugs can have disastrous consequences, sure; but fixing all pointer
> >>> abuses won't stop that from being the case.  Meanwhile, in the world of
> >>> most programmers, most bugs are more or less endurable and most users
> >>> would sooner have something that ships today with a few endurable bugs
> >>> than not have the software that helps them do whatever it is they do
> >>> until someone is sure there are no bugs in it.  Buts aren't the only
> >>> thing that can cause a software project to fail.
> >>>
> >>>> Also it is possible for me to support nested structures by prefixing
> >> class
> >>>> names so that their meta-data fits into the top-level namespace but
> for
> >> the
> >>>> moment they’re not. But those are personal preferences like not using
> >>>> underscores in function names, etc.
> >>>
> >>> Well, if you can support nested structures, you might have a better
> >>> chance of persuading folk to port to your new language; but those with
> >>> large code-bases aren't about to re-write them to eliminate nested
> >>> structures just because you regard that choice as a personal
> preference.
> >>> I note that Qt has

Re: [Development] Fornux C++ Superset

[Eric Lemanisser]

Le mer. 25 avr. 2018 à 14:03, Phil Bouchard  a écrit :

> On 04/25/2018 04:46 AM, Edward Welbourne wrote:
> > Phil Bouchard (24 April 2018 19:05)
> >> I’m not sure if you read the link I posted about static analysis but a
> >> software bug can cause billion dollar projects like space shuttles to
> fail.
> >> Maybe MS Word was a bad example but they can be very costly.
> >
> > The Columbia crash wasn't a (computer) software issue.  One can think of
> > the organisational failure that lead to it as a (human) software issue,
> > but I don't think we have static analysis software for that.  The
> > closest you'll get is an ISO 9000 compliance auditor.
> >
> > The Ariane 5 crash was a software error, but it wasn't a memory abuse;
> > it was using an under-sized integer to hold a value that overflowed.
> > With luck, static analysis would find that, but it's a pointer abuse.
> >
> > The loss of the Mars Climate Orbiter involved a software bug, but it was
> > a wrong choice of units rather than a pointer abuse.  Mixing archaic
> > silly units with sensible SI ones has caused more grief for space
> > missions than pointer abuses.
>
> You need to see the big picture; memory leaks are the most difficult
> problems to solve. In the labs you stress-test your software for a few
> days but in real life your software is going to run for a few months
> consecutively.
>
> I was working for a WebKit-based browser for TVs for a software company
> and the browser kept crashing after a day of usage because of memory
> leaks. I mean how are you supposed to watch TV if you need to reboot the
> set-top box every day at a random time?
>
> Also do you really want to spend time running Valgrind on iPhones or
> Androids to find these problems? First Valgrind won't fix the problem,
> second it is not giving always the same answer and third it doesn't run
> on all embedded devices.
>
> There is more you can read about the subject here:
>
> "Real Production Issue - Hard to find memory leaks"
> https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh
>
> And BTW:
>
> "Garbage collection is out the window, because you cannot know when it
> is going to happen or how long it will take, which leads to stuttering
> frame rates."
>
> https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games
>
> > So bugs can have disastrous consequences, sure; but fixing all pointer
> > abuses won't stop that from being the case.  Meanwhile, in the world of
> > most programmers, most bugs are more or less endurable and most users
> > would sooner have something that ships today with a few endurable bugs
> > than not have the software that helps them do whatever it is they do
> > until someone is sure there are no bugs in it.  Buts aren't the only
> > thing that can cause a software project to fail.
> >
> >> Also it is possible for me to support nested structures by prefixing
> class
> >> names so that their meta-data fits into the top-level namespace but for
> the
> >> moment they’re not. But those are personal preferences like not using
> >> underscores in function names, etc.
> >
> > Well, if you can support nested structures, you might have a better
> > chance of persuading folk to port to your new language; but those with
> > large code-bases aren't about to re-write them to eliminate nested
> > structures just because you regard that choice as a personal preference.
> > I note that Qt has plenty of nested structures.
> > I'm not volunteering to refactor them away.
>
> Support for nested structures is easy to fix and will just take a day or
> two to do so. For example:
>
> struct A
> {
>struct B
>{
>};
> };
>
> Will be converted into the following so that I can have their
> specialization in a top-level namespace:
>
> struct A__B
> {
> };
>
> struct A
> {
> };
>
>
This would break existing code, as name lookup from nested class should
visit first enclosing class before visiting namespace. Also, the nested
class must have access to all names (private, protected, etc) to which the
enclosing class has access (
http://en.cppreference.com/w/cpp/language/nested_types)

Since there is no hidden catch then I will tell you right now that:
> - NULL C pointers will need to be typed
> - pointer casts to their encompassing structure needs to use
> _containerof() macro
> - C-style array parameters needs to be converted to pointers
>
What for ? you loose the size information by doing so.

> - Types instantiated in the same statement need not be different (Ex.:
> int * i, j[4]; // needs to be 2 different statements)
>
> That's about it. It took me 1 week to adapt "libarchive" to follow the
> aforementioned rules:
>
> https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b
>
>
> Regards,
> -Phil
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

Re: [Development] Setters: Clarifying the ownership

[Eric Lemanisser]

Please use an already existing solution to this problem :
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Ri-raw
Errors will be caught by the compiler in case of std::unique_ptr, and by
static analysers (like clang-tidy) for gsl::owner, without run-time cost.
There was already an attempt to use gsl::owner
https://codereview.qt-project.org/#/c/178107/ but it did not go forward,
because of lack of time ?

Le ven. 19 janv. 2018 à 19:33, Thiago Macieira 
a écrit :

> On Friday, 19 January 2018 09:26:10 PST Edward Welbourne wrote:
> > Jaroslaw Kobus (19 January 2018 17:09)
> >
> > > "give" may be confused with "get", which is usually an accessor. I may
> > > also think "Am I giving (to QCoreApplication)" or "The
> > > QCoreApplication is giving (me)". Maybe it is just a matter of the
> > > other verb? Absorb, hand over, hand on, suck in, swallow...
> >
> > However, we have plenty of take functions, where the caller takes
> > ownership from the object on which the method is called; so it makes
> > sense that a give function would be the caller giving ownership to the
> > object on wich the method is called.
> >
> > Thus we'd keep child.setParent(newParent), since the child doesn't take
> > ownership of the parent; but QMainWindow's setCentralWidget() would
> > become giveCentralWidget(), matching its takeCentralWidget().  This
> > would save the search for its doc, to find that it does indeed take
> > ownership.
> >
> > The signature is, in any case, always sufficient to make clear that a
> > give()r isn't a get()ter.
>
> Let's stop the discussion about method *naming* right here. We're not
> going to
> change hundreds of getters and setters now or even in Qt 6.
>
> Let's instead find a solution that either uses macros or uses simple
> binary-
> compatible pointer wrappers like GST.
>
> And be careful with template functions. Changing from T to Something may
> change what gets deduced.
>
> --
> 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] Threads and the SQL Module

[Eric Lemanisser]

Thanks for pointing this out Łukasz, I created a change to disable useless
mutexes on sqlite db connection :
https://codereview.qt-project.org/#/c/185835/
Unfortunately that would break your usage, but it seems like it is already
broken as Lorenz explained. All db intensive usage should see a perfromance
win.

Eric

Le jeu. 16 févr. 2017 à 07:37, Samuel Nevala  a
écrit :

> Hi,
>
> Just recently needed to fix threading issues with SQLite on
> non-Qt-context. Here here is obsolete information that helped me:).
> http://www.sqlite.org/cvstrac/wiki?p=MultiThreading. From that doc: "By
> "threadsafe" we mean that you can use different SQLite database connections
> in different threads at the same time. It has never been safe to use the
> same database connection simultaneously in multiple threads."
>
> Samuel
>
> On 15 February 2017 at 21:24, Lorenz Haas  wrote:
>
> Hi,
>
> AFAIS it does not matter if sqlite is thread safe or not. The problem is
> that QSQLiteDriver itself is not thread safe. For example if two threads
> call beginTransaction() on the same driver and the "COMMIT" fails, both
> threads will call QSqlDriver::setLastError() which does "d->error =
> error;". And here is the first problem.
>
> I am not an expert with QSqlQuery, but since it uses the driver, I bet,
> you'll also find UB and races there.
>
> Cheers
> Lorenz
>
> Am 15.02.2017 um 13:37 schrieb Łukasz Korbel:
> > According to
> > http://doc.qt.io/qt-5/threads-modules.html#threads-and-the-sql-module
> > database connection should be used within one thread *only*.
> >
> > I have checked SQLite driver and according to
> > https://www.sqlite.org/threadsafe.html it supports multithreading by
> > default. And it seems that Qt implementation does not restrict it
> > (
> http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp#n645
> ).
> > Code I'm working on is creating QSqlQuery for the same connection in
> > different threads and it works.
> >
> > I understand it doesn't mean Qt want or need to support such use case
> > but maybe documentation
> > can be slightly more accurate? Right now it implies that database
> > connection can never be used from different threads but it seem it
> > depends more on particular driver/3rdparty lib.
> >
> >
> > *Łukasz Korbel *
> > Senior Software Developer
> > Email:lkor...@milosolutions.com
> > Skype:lukasz_korbel
> > *Milo Solutions*
> > www.milosolutions.com  | Facebook
> >  | Twitter
> > 
> > Disclaimer: This e-mail and any attachments contain information that may
> > be privileged or confidential and is the property of Milo Solutions. If
> > you are not the intended recipient, please notify me immediately by
> > replying to this e-mail, and then delete it. Any unauthorised
> > dissemination, distribution, copying or use of this communication is
> > strictly prohibited. The contents of an attachment to this e-mail may
> > contain software viruses, which could damage your own computer system.
> > Although this e-mail and any files attached to it may have been checked
> > with virus detection software before transmission you should carry out
> > your own virus checks before opening the attachment. No liability can be
> > accepted for any damage which you may sustain as a result of software
> > viruses.
> >
> >
> >
> > ___
> > 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Eric Lemanisser]

We have been using the MinGW binaries of Qt for years in production without
problems. Until now 64bit has not been required, so we only used 32bit
which is able to run on all windows platforms. A non-negligible part of
users are using 32bit windows (on tablets for example), so it does not seem
a very good move to stop offering MinGW 32bits. That said we would
definitely make use of MinGW 64bits binaries !

Eric Lemanissier

Le ven. 25 nov. 2016 à 08:03, Bo Thorsen  a écrit :

> Den 23-11-2016 kl. 23:10 skrev Thiago Macieira:
> > On quarta-feira, 23 de novembro de 2016 21:14:52 PST Simon Everts wrote:
> >>> That is not relevant here. I am using Windows 10 (64-bit) but I am
> still
> >>> forced (because of 3rt-party-libraries) to develop
> 32-bit-Qt-applications.
> >>> Even if the operating system is 64-bit there can be a lot of 32-bit
> >>> application, e.g. VS 2013 and VS 2015 are still 32-bit applications.
> >>
> >> +1
> >>
> >> As a machine manufacturer we are still deploying 32bit windows systems
> >> because of this reason. We'll be on 64bit windows soon, but need to
> support
> >> the 32bit systems for at least 5 years. A lot of industrial computer
> >> suppliers still install 32bit images on computers because there aren't
> any
> >> 64bit drivers available for the hardware.
> >
> > Good, thanks for the information, Simon and Helmut.
> >
> > I know the sample size here is horrible, but in your opinion what
> compiler
> > should we keep offering a 32-bit binary build for?
> >
> > MSVC 2013
> > MSVC 2015
> > MinGW
>
> The reason for doing 32 bit MSVC releasees is 3rd party libraries. Is
> that a valid reason for MinGW? I would have thought that the guys using
> it pretty much have to compile everything themselves anyway.
>
> I don't know, though. I won't ever use MinGW myself unless a customer
> forces me to.
>
> Bo Thorsen,
> Director, Viking Software.
>
> --
> Viking Software
> Qt and C++ developers for hire
> http://www.vikingsoft.eu
> ___
> 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] QDataStream: blackbox or document all versions?

[Eric Lemanisser]

You could choose to turn QDataStream into a black-box, but I think there
should be a white-box alternative which has to be
1/ as efficient : binary format
2/ as easy to use : QDataStream is able to serialize any type with the help
of qRegisterMetaTypeStreamOperators
3/ as generic : it should be able to use any QIODevice for transport/storage

1/ discards XML and JSON, and 3/ discards QSettings and D-Bus. I don't know
CBOR, but it seems an interesting alternative.

Eric Lemanissier

Le dim. 25 sept. 2016 à 05:59, Thiago Macieira 
a écrit :

> A thread[1] on the interest mailing list started when someone asked for the
> docs for the current format of the QDataStream wire protocol, to which I
> replied that it doesn't exist as we don't maintain such docs.
>
> Long story short, we have two options:
>
> that can read QDataStream is QDataStream. That means removing the
> Option 1: claim QDataStream is a blackbox and tell people that the only
> thing
> that can read QDataStream is QDataStream. That means removing the
> documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't
> want
> people getting any ideas that they could write their own decoders or
> encoders.
>
> Option 2: the opposite, saying that reading QDataStream's output is fine
> from
> non-Qt code and it's fine to write data that QDataStream should read. This
> means extending the documentation to cover ALL 17 wire formats (including
> bugs) and keeping it up to date whenever someone modifies the format.
>
>
> I am in favour of Option 1 because I really don't think QDataStream is a
> good
> format for exchanging data with non-Qt code. It's designed first and
> foremost
> for Qt's own internal data formats (sometimes even depending on internal
> details), the marshalling of certain types in certain versions is buggy and
> lossy. Instead, people should find a better transport format for their
> data, of
> which we already have in Qt:
>
> XML
> JSON
> D-Bus
> QSettings (to an extent)
>
> And I can add CBOR support if we want to.
>
> [1]
> http://lists.qt-project.org/pipermail/interest/2016-September/024387.html
> --
> 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] Bluetooth support for Windows (RT/10) in Qt 5.6

[Eric Lemanisser]

Hello,

I totally +1 this feature !
However if I'm not mistaking, focusing on WinRT api discards MinGW
compiler, that's bad news for open source tools.

Best regards,

Eric

Le mar. 16 juin 2015 à 15:35, Attila Csipa q...@csipa.in.rs a écrit :

 Hi,

 A huge +1 on this, BT support on Windows is long overdue.

 While there is certainly more inertia in the windows desktop version
 than probably any other Qt supported platform, Microsoft itself is
 trying to nudge people into quicker upgrade cycles, and while Win8 has
 certainly gotten a pushback, with Win10 around the corner I would also
 try not to get bogged down with pre-WinRT solutions, as painful as that
 might sound in some cases.

 Best regards,
 Attila

 On 6/16/2015 1:42 PM, Kalinowski Maurice wrote:
  Hi everyone,
 
  It might sound weird that while we're trying to get 5.5.0 out I am
 starting a discussion about Qt 5.6, but if you look at the release schedule
 there is not much time for the feature freeze
 
  https://wiki.qt.io/Qt-5.6-release
 
  One of the items the Windows / WinRT team would really like to see
 included to that release is support for Bluetooth and BTLE.
 
  The current idea is to use the WinRT API for that backend, as it
 provides the advantage that it can also be used on Windows Desktop starting
 Windows 8(.1). WinRT covers Windows 10 support (both classic and Unified
 Windows Platform) as well.
 
  This leaves out support for Windows Desktop older than Windows 8. But as
 we are aiming to implement new features, we should draw the line somewhere
 and the WinRT backend clearly has the biggest potential to be supported in
 many years' time, while the (or multiple) pure desktop solution would be
 deprecated sooner or later again. Also given the fact that we can target
 quite many platforms with one backend gives us a better coverage for
 maintenance and resourcing.
 
  The reason that I am mentioning this on the mailing list is that after
 talking to some folks here in The Qt Company, multiple people inside and
 outside already started or wanted to start efforts on this topic. Hence the
 aim of this email is to get everyone connected and work on it together to
 make it happen within the 5.6 feature freeze.
 
  So, if you have worked on Bluetooth (LE) on Windows or want to, please
 get in touch with me to align.
 
 
  BR,
  Maurice
 
 
  
  Maurice Kalinowski - Senior Manager, Qt Tools
 
  The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
  Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der
 Gesellschaft:
  Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
 
  Email: maurice.kalinow...@theqtcompany.com | Mobile: + 49 175 187 19 52
 | Phone:
  +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ |
 Twitter:
  @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt
 
 
  ___
  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