Marc:
> I know Howard's ideas about hashing, and I agree with them. In Qt, we
> largely
> ignore the issue of hash collisions for a given type and just hash its
> members, combining with boost::hash_combine, and hope for the best. As
> such,
> the problem described in Paragraph 5 of
> https://iso
On Fri, Feb 10, 2017 at 3:59 AM, Tuukka Turunen wrote:
> Short summary: The Qt Company has decided to focus development effort to 5.9
> and dev branches in order to reach the planned timeline for Qt 5.9 release
> and make improvements in the CI system. ,
> In the CI system side we have major impr
On Tue, Jul 12, 2016 at 3:47 AM, Marco Bubke wrote:
> , Lets face it, the world is much bigger than Qt, and I think there
> is much to gain if we integrate better with alien libraries.
>
My understanding is that most alien libraries are not binary-based (i.e.,
they are ternary or use other forms
+1, I've found many good uses for QtSingleApplication, and think this is a
good (highly practical) feature for "Qt-proper".
--charley
On Sun, Jun 19, 2016 at 11:59 PM, Kevin Funk wrote:
> On Donnerstag, 16. Juni 2016 00:19:10 CEST Kevin Funk wrote:
> > (snip)
> >
> > Question:
> > Is there a
>
> Visual Studio 2015 Update 1 to Windows 10
>
> Please let’s keep in mind that Visual Studio 2015 Update 2 is coming out,
> I don’t think that it will be ready for Qt 5.7, but we should be prepared
> for Qt 5.8 indeed.
>
> Regards,
> Diego
>
+1
--charley
On Thu, Feb 25, 2016 at 8:20 AM, Thiago Macieira
wrote:
> Just starting a new thread to get the attention of those that may have
> missed
> it in the other platform.
>
> The proposal is to drop VS 2012 support in Qt 5.7 already, instead of
> supporting it in 5.7 only and dropping in 5.8.
>
> The
The Call For Submissions for the CppNow conference (May 9-14, 2016) in
Aspen, CO will close this Friday (Fri-29-Jan).
This is an intimate C++ conference with great minds, including many Qt
users, and past speakers have come from the Qt community.
Consider attending, and/or submitting a talk.
htt
Thiago sayeth:
> ,
> But I have no plans on extending QAtomicInteger and QAtomicPointer further.
> There are a couple of missing features that will probably never be
> implemented:
>
> * std::memory_order_consume and std::memory_order_cst
> * GCC's extension for hidden lock elision
> * compare_
Thiago sayeth:
> So no, I don't think we risk becoming irrelevant against other airplane
> makers
> anytime soon. Our competitor are those transatlantic heavyweight ships
> (HTML5).
>
,
LOL!!!
That's actually a very good point (in addition to the fact that I really
did Laugh-Out-Loud).
C++ is
+1
On Tue, Jan 19, 2016 at 4:32 AM, Knoll Lars
wrote:
> +1 and +1 from me as well :)
>
> Cheers,
> Lars
>
>
>
>
> On 19/01/16 13:16, "Development on behalf of Marc Mutz" <
> development-boun...@qt-project.org on behalf of marc.m...@kdab.com> wrote:
>
> >On Tuesday 19 January 2016 08:22:54 Viiron
Apologies for "hijacking" the thread, but two points were raised that IMHO
would be helpful if they were answered directly:
(1) Future of Qt binary compatibility
(2) Use of std:: containers (especially in context of (1)).
We can take this to another thread as-needed. However, quick "recap":
===
Hi, Brett--
IMHO, this is a very good change. The library will be easier to use, and
more accessible from QML.
Also, now is probably the time to make such an API change.
I'm watching this effort with great interest -- thanks for all your hard
work.
--charley
On Sat, Jan 2, 2016 at 10:51 AM,
>
> On Wednesday 23 September 2015 08:37:54 Heikkinen Jani wrote:
> > We are targeting to release Qt 5.5.1 as soon as possible, most probably
> > during next week.
>
On Tue, Oct 6, 2015 at 2:56 AM, Gerhard Scheikl
wrote:
> Hi
>
> Could you please give us a new estimate?
> Unfortunately, we rely
Microsoft announced MSVS2015 will be released on July 20:
http://www.zdnet.com/article/microsoft-sets-release-date-for-visual-studio-2015/
Those of us that have been following the MS compiler know that the MSVC2015
is a particularly strong compiler, making up for lots of "lost-ground" in
supporti
>
>
>
Bo Thorsen sayeth:
> This answer is going to be one big IMHO.
>
> Anything that stops people from throwing shared pointers all over the
> code is A Good Thing. As someone once said: Shared pointers are a
> solution in search of a problem.
>
> Scoped pointers are fine, but shared pointers i
>
> > For example, with moc removed we support template classes that inherit>
> > from QObject.
>
> Wow. I would (almost) kill for having that feature in Qt!
>
> You can work around it quite easily. What doesn’t work is adding new
> signals / slots inside a template class. So just add a base class
>
> Sayeth Simon:
>
> On the other hand I think it is critical for Qt's success to also support
> use-
> > cases that leave our little universe (of Qt). And that means either
> building
> > something yourself and convincing others to adopt it or adopt a
> > technology/approach that already has exis
Just got back from CppCon (http://cppcon.org/), WOW what a great conference
for C++.
Apologies for cross-post qt-interest and qt-dev, but wanted to be sure both
groups saw the announcement for next year (20-25 Sep-2015).
WOW AGAIN for a great conference. Really heavy-hitters there, with
informat
Just a silly question related to the Qt roadmap (I don't want to distract
this weekend's Qt5.4 freeze-activity):
Qt6 (and even Qt7) has been mentioned on this list in the past year, and I
was curious if there were a "30,000-mile-high-view" of what might be
"on-deck" for consideration.
A web-searc
>
> This cross process stuff is starting to feel like 1996 and
> remote procedure RPC calls, now using QT signals and slots. ""
> again for effect.
>
> One could review the history of microsoft and the fine RPC mechanisms
> that turned out to be mostly unusable, or maybe just unused.
>
> Keep the o
(I'm just jumping in here...)
Bret spaketh:
> In trying to address your points, I fear it sounds like I think D-Bus is
> bad. That's not
> what I'm trying to say. I'm saying D-Bus/QtDBus didn't work *for my
> use-case*.
> So I created something that worked better *for my use-case*.
>
> There
On Mon, Apr 28, 2014 at 4:39 AM, Hartmann Thomas
wrote:
> Hi,
>
> gluing together C++ and Java Script is currently not always that easy.
> The solution I propose is the option to write C++ code in the exact same
> way you currently write Java Script code.
> This means every QML context/component c
>
>
>
> >>> While your proposed approach is rather clean, it carries one drawback,
> >>> which is the lack of type information, with all its consequences.
>
PRO:
*- Can data-clean/input-validate on either C++ or QML side, can add more
custom validators in different places
*- ?More fine-grain
I'm not Roland (talking about "value-types"), but I completely agree with
his comments on why they are important (we have that issue also).
But, "jumping-in", ...
,
> >> - Our application has a huge framework of value classes. They cannot
> (or
> > >> at least it does not make sense to) derive f
Roland sayeth:
> , I liked the design to split business logic into
> C++ and UI design into QML and I still like it, but I came across
> several blocking issues (some of them are only valid for our
> application, some of them are general):
>
> - Our application has a huge framework of value classe
25 matches
Mail list logo
