Apologies for the cross-post (interest@ and development@), but registration
just opened this morning for "CppCon 2014", September 7-12, 2014 in
Bellevue, Washington, USA.
http://cppcon.org/
There is a "Super-Early-Bird" registration price of $695 for the week for
the first 100 people.
It would b
>
> John Layt sayeth:
>
> >As noted on the Releasing list, I didn't get the OSX 10.7 blocker bug
> >fixed in
> >time, and using just the layout code without the plugin proved too much
> >work
> >to be stable in time, so *none* of this change set has made it for 5.3.
>
,
> >Thoughts?
>
Knoll Lar
John Layt sayeth:
> Hi,
>
> I've spent the last few weeks going over the current print support and
> trying to map out a plan to improve things. ,
Given my limited time, I've decided to take a different approach to
> try build the new code over the next few releases as a new set of QPA
> classe
Sean Harmer sayeth:
> Hi,
>
> during the development of the new version of Qt3D's QML API we have come
> across an interesting (well if you like that kind of thing) problem.
>
> The issue is that at present the QML value type helpers for types such as
> QVector3D are provided by QtQuick meaning th
Thiago Macieira wrote:
> Anyone else wants to submit this time?
>
> This year, as representatives of the Qt Project, we had Charley Bay, Tony van
> Eerd and me. I'd like a few more Qt devs showing up and presenting our more...
> ahem, pragmatic / conservative... solutions
On Wed, Oct 30, 2013 at 1:59 AM, Konrad Rosenbaum wrote:
> **
>
> Hi,
>
>
>
> On Wednesday 30 October 2013 00:58:05 Calogero Mauceri wrote:
>
> > The Qt documentation states that QDir::currentPath() returns "The
>
> > application working directory". Shouldn't the workind directory be
>
> > initia
On Wed, Oct 2, 2013 at 12:39 PM, André Pönitz <
andre.poen...@mathematik.tu-chemnitz.de> wrote:
> On Wed, Oct 02, 2013 at 06:57:01AM +0200, Thomas Sondergaard wrote:
> > On 2013-10-01 21:20, Thiago Macieira wrote:
> > > Since we decided to roll back support for exceptions in our container
> > > cl
Thiago wrote:
> Since we decided to roll back support for exceptions in our container
> classes,
> the only thing that currently needs exception support is the mainloop
> allowing
> std::bad_alloc through.
>
> Is it worth it?
>
> Should we disable exceptions in QtCore?
>
No, and yes. ;-))
I vot
Rene wrote:
> Hi Qt developers
>
> A little over a year ago I raised a question on this list about
> QSharedPointers and QML, and got a lot of debate started, which turned out
> to be very illuminating. (
> http://lists.qt-project.org/pipermail/development/2012-May/004049.html)
>
>
>
> , Clea
>
> Tony sayeth:
>>>
,
We'd like to change the reference platforms a bit. We have new
platforms coming in and old ones are just that.old.
>>>
>>>
,
These changes would be targeted for Qt 5.2 and the current proposition
can be seen here:
http://
Tony sayeth:
> ,
> We'd like to change the reference platforms a bit. We have new platforms
> coming in and old ones are just that.old.
>
> ,
> These changes would be targeted for Qt 5.2 and the current proposition can
> be seen here:
>
> http://qt-project.org/wiki/CI_Configurations
>
> (That we
Simon sayeth:
>
Chris replied:
> > This is really exciting news! Good stuff!
>
+1
> > I wonder how much performance delta there is between JIT and pure
> > interpretted, with a tight enough interpreter loop, if you make some
> > simplifying assumptions (eg, types can't change at runtime / e
Samuel sayeth:
> A good reason for using the
>
> Foo()
> : x(0)
> , y(0)
> {
> }
>
> syntax for initializer lists after all is to make diffs easier to read
> when adding or removing a member variable. The same argument could be
> made for permitting braces for one-line if-statements.
>
Axel sayeth:
>
> >> >> coding standard>
+1 YAY, Axel!
This is a personal wish by me -- consistency. Including for whitespace.
I find it astounding the "legacy-code-bases" that essentially decide that
they cannot be improved -- no such patches are welcome -- because it would
require work, add
Sean sayeth:
>
>
I also was disappointed that Qt3D would not make it into Qt5.1, but IMHO
the details Sean (and James Turner) provided are quite excellent -- there's
a lot there, and it makes sense to provide this "think-it-through" for the
APIs.
Nobody wants to rewrite their 3D to a new API
Mitch sayeth:
> I think a lot of people are hesitant to contribute fixes because of all of
> the
> setup required to contribute, also (yeah, it's easy once you are familiar
> with
> it). ,
+1
It would be nice to make this, "turn-key".
For example, on platforms like Windows, it "would-be-nice"
Hi, Alan--
charley:
> > I've implemented a C++ "adapter-layer" (mostly template-based) to expose
> C++
> > objects to QML. ,
>
> Sounds like this is for developers using Qt, not working on Qt.
qt-interest is the correct ML for that (although given the youthful
> state of QML, this could also su
I've implemented a C++ "adapter-layer" (mostly template-based) to expose
C++ objects to QML.
We are in the "early-stages" for its use, and (of course) the "final-API"
will significantly impact how we expose our (domain-specific) C++ classes
to QML.
My manager suggested I ask others what they are
There's a Qt5 moc error when using Boost, with a work-around. See:
http://qt-project.org/forums/viewthread/22993
It describes "Boost 1.49", but this work-around also works for "Boost 1.52":
...leads to compile error (Win7/MSVS2010):
C:/Some/Path/3rd/Boost/boost_1_52_0/boost/mpl/if.hpp(131): Err
Alberto sayeth:
> > Hi all!
> >I'd like to make C++ models more usable from QML; in the net there
> > are several blog posts illustrating how to achieve that, but IMHO it
> > would be better if at least some of these handy features were in
> > QAbstractListModel itself:
> >
> > - "count" prope
Robert wrote:
> > If added to Qt, we would consider dropping our in-house implementations
> to use Glen's QNDArray (this is serious investigation at present).
>
> What stops you or anyone else from using QNDArray if it is maintained
> outside of Qt?
>
Nothing (that would be a minor barrier). Ho
>
> Glen Mabey wrote:
> Hello,
> >
> > For some time, I have been working on a QtCore-based class that would be
> a
> > container class of arbitrary dimensionality. I did give a presentation
> on
> > this topic at DevDays-CA:
>
Olivier Goffart responded:
> Just my personal opinion on this:
>
>
amogh kudari wrote:
> > Hi All,
> >
> > Currently I am using cygwin build environment with cl compiler. Is
> it
> > possible to compile qt with qws using cl compiler on cygwin build
> > environment?..
>
Thiago Macieira wrote:
> We barely support cygwin at all. We prefer mingw, which is li
Unto all so did sayeth Alan:
> > What should enumeration declarations in QML look like?
>
Did respondeth Erik:
> And, also important: how much slower is it allowed to be than the current
> implementation?
>
> I remembered that there was talk about enums in QML before, so I dug
> around a bit, an
>
> > I understand others' concerns about "load-performance". ,
> The concern about load-performance isn't about "users now have an
> informed choice between faster development speed or faster runtime
> speed". The concern is about people using import Qt 5.0 because it's
> convenient, and then
Alan spaketh:
I've heard complaints about all the varying version numbers used in
> QML imports. I don't think we can just standardize, for example on
> 5.0, because the whole point of modularization is that modules don't
> have to move in lockstep anymore. But I did hear an idea at Dev Days
> to
>
> > People keep asking for enumerations in QML. ,
> > Now I don't know when these issues will be
> > resolved, but there's an important discussion to have before it can
> > even be scheduled: What would proper enum support look like in QML?
> > ,
>
> I'd prefer:
>
> Item {
> enum Wea
Alan spaketh:
> Finally Qt 5 brings better QtQml and QtQuick separation! Better, not
perfect. The main things I've heard are missing is dynamic
> instantiation of non-Items. What I propose is a new element for the
> QtQml module which provides that functionality. Note that while some
> people ha
Hi, Matt--
thoughts:
>
> a) I think the only reason the old QtService uses a template based
> approach is to support the different types of Q*Application. It would be
> quite useful to have someone who worked on the original solution discuss
> why they went with this approach rather than subclassi
On Mon, Nov 26, 2012 at 10:40 AM, Matt Broadstone wrote:
> On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay wrote:
>
>> >>> " Component >,
>> >>> I would like to open a new Qt Playground project to create a new
>> equivalent
>>
>> +1
&g
>>> " Component >,
>>> I would like to open a new Qt Playground project to create a new
equivalent
+1
IMHO this would be a cross-platform useful module that I'd vote to
ultimately end-up within "Qt-proper".
Disclosure: I traded emails with BRM off-list, and would like to help.
--charley
__
Maurice spaketh:
> >,
> > My question is, what are the benefits compared to picking the example
> source code from the source package directly. Does anybody really want to
> have prebuilt binaries in the examples directory? Current assumption is
> that you go through the list via Qt Creator and bu
> Friedemann said he'd like to have msvc 2010 64 bit as reference platform,
> maybe replacing msvc 2010 32 bit.
Really? I would assume that 32-bit is still a significantly-large
audience that we could *add* 64-bit, but that we likely would need to
keep 32-bit (for a while).
Have developers reall
Kai spaketh:
> The list of reference & Tier 1 platforms at
> http://qt-project.org/wiki/Qt-5#Platforms
> is somewhat out of date ... Here is a new proposal ,
Seems fine to me.
An aside -- serious suggestion:
We are successfully using the, "MSVS2010, SP1" compiler within the
"MSVS2008 IDE" using
Tuukka spaketh:
> What comes to WP8 we believe it is more important to tackle Android and iOS
> first, as discussed earlier. It does not mean we do not care about WP8.
> There is just so much more user base in Android and iOS that we think it
> would be outright stupid not to address those.
+1
As
Shawn Rutledge spaketh:
> Personally I think the fundamental problem which CI could do better is to
> triage problems. ,
>
> I think when a test fails, the CI system should try to break down the
> patch set in some way. For example it could divide the patch set in half,
> arbitrarily, and see if
Wow. I don't usually "rubber-neck" as I drive by car-crashes, but I
must say, this has been one of the more fascinating email chains.
Not because of content; but rather, because in my introverted
"I'm-so-lonely!" world, observing humans-being-human has recently
become fascinating to me.
I had to
I stumbled across an interesting discussion from Feb-2008 about using
QTcpSocket and QLocalSocket, which also suggested the design might be
revisited post Qt5:
http://blog.qt.digia.com/2008/02/22/qlocalserver-qlocalsocket/
REVIEW:
- QTcpSocket (derived from QAbstractSocket) is really a
network-
Yuchen spaketh:
> I noticed Nokia stop developing qbs for a long time, and qtcreator's
> wip/qbs seems stop developing too.
> And for now Nokia sells Qt to Digia, I want know how about the future of
> qbs?
> If the Digia give up qbs, I will choice CMake as my build system.
> So, any news or commen
We just renewed our Qt Commercial licenses through Digia.
Happy to do it.
Good value. Great code base.
Tuukka has been great about Digia's very-public-goal to keep the *same
code* in Qt releases (Commercial and at qt-project.org). That's what we
want too.
Great stuff!
--charley
On Thu, Aug
Ben spaketh:
> As one of those who is working towards being a new contributor, I
> would want a use a generally stable branch for most of the initial work of
> adding a new module; and then move it up towards "fire-hose" just prior to
> pushing it out to everyone.
>
> That is:
>
> - Grab the 6 m
Thiago spaketh:
> I'd like to propose we add Q_DECL_NOEXCEPT to many methods in our API.
>
> We already took the decision to turn exception off in most modules, except
> QtCore and where exceptions were used, like QtXmlPatterns. This is the next
> step.
>
> The Q_DECL_NOEXCEPT macro expands to noe
Agree with Thiago:
For 3D and Location, I have a feeling it's a little premature, but I can't
> blame you for it. Especially in Location's case, with lots of plugins to be
> kept in working order, it might be tricky in the current situation.
>
> Qt3D might be quite mature, actually, since it's bee
Thanks, Alan -- very rich email that helps me think about
declarative-model-instance-handling.
Alan spaketh:
> Reusable components/delegates, where data propagates in one direction, is
> the
> best-practices pattern that obviates this need. ,
> For list delegates, this is managed through the m
Mark spaketh:
> Sadly, QML 1 doesn't have id in dynamically generated id. That is a
> real big pain if you want to drag/drop something since then you
> need... an id! Right now i'm trying to fight against a lot of issues
> that wouldn't even be there if i simply had an ID. You can read more
> abo
> As you say, applications which are watching (possibly large) directory
> trees will likely
> have their own database of content which they will compare any changes
> to. The app
> can optimize this in domain-specfic ways, such as not recording any
> information about
> types of files it doesn'
>
> João spaketh:
>> I think it would be feasible to do a binary-only break somewhere
> >> around the 5.2 timeframe (say, ~12 months) where we address this.
> >> Technically, this would be Qt 6, but user porting effort would be
> >> reduced to a recompile.
>
> André respondeth:
> > That's essen
charley spaketh:
>
> > (We currently have our own 2D and 3D math libs, but if Qt had a non-GUI
> coupled lib, we could use it.)
>
Thiago respondeth:
> Can you tell me whether those classes would suffice to your needs?
>
Inside "math3d" I see some "qvector") stuff (2d, 3d, 4d), a
"qgenericma
I agree with Laszlo: The "3D-math" stuff is generally useful, and need not
be coupled to QtGui. (We have domain-specific reasons for using 3D-math
stuff outside GUIs, separate of Laszlo's interest in "QtAudio3D" which also
does not want to couple to "QtGui" -- we cannot couple to QtGui either.)
>
> > How would you suggest solving it? QAction does have stuff like
> >
> > bool showStatusText(QWidget *widget=0);
> > QWidget *parentWidget() const;
> > QList associatedWidgets() const;
> > friend class QWidget;
> >
> > so it seems difficult to make it avoid depending on wid
I've followed this very technical discussion from the beginning--
impressive array of topics. Thanks to all digging into this, and great
thanks to Thiago for opening the issue.
I have a question on the point of "recursive-locks":
I understand "recursive-locks" (e.g., "recursive-lock-count") we
Ok.
On Mon, Apr 16, 2012 at 7:26 AM, Daker Fernandes Pinheiro <
daker.pinhe...@openbossa.org> wrote:
> My team in INdT has been researching about theming/styling of Qt
> Components.
> I’ve synthetised what we’ve been done and some of our aims and ideas:
>
> http://codecereal.blogspot.com.br/201
>
>
>
> A theme manager will make the things much more simpler and clear for the
> user and
> when it comes to add support for other platforms. ,
> Let me try explain more:
>
> >From user perspective: themes>
>
> >From developer perspective who wants to add support for another platform
>
>
>
> /me wonder why we still even care about QT_NO_STL
>>
>>
> Embedded?
>
+1
Further, half of C++ developers *hate* STL. (Long story, off-topic for
here.)
--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/ma
>
> > 3) Need a couple of better names for partial matching:
> > - partial match preferring a complete match
> > - partial match returning whatever match (partial or complete) is found
> > first
> >
> > PCRE uses Soft and Hard respectively (which are quite meaningless to
> > me).
>
> PreferComplete
>
> Stephen Kelly spaketh:
> > http://boost.2283326.n4.nabble.com/Boost-with-Darwin-Mac-gcc-4-0-1-
> > td2580330.html
> >
> > So, keep in mind - for portability treat 'check' as an out of bounds name
> > for a method or variable.
>
Thiago Macieira respondeth:
> Also to avoid:
>sun
>
I'm quoting Robin's email (with some of my comments), because I think it
was a great message that I don't want "lost":
On Thu, Dec 15, 2011 at 2:16 PM, Robin Burchell wrote:
> Hi Tuukka,
>
> (now that I've left some hours to digest this...)
>
> 2011/12/15 Turunen Tuukka :
> > So now there is tota
On Fri, Dec 9, 2011 at 12:49 PM, Marcus D. Hanwell <
marcus.hanw...@kitware.com> wrote:
> 2011/12/9 Stephen Kelly :
> > On Friday, December 09, 2011 20:12:05 Stephen Kelly wrote:
> >
> >> This week:
> >
> > Oops, sorry. This was not intended for the Qt mailing list.
> >
> > I was compiling it for
morten spaketh:
> Those of you that follow the commits on Gerrit closely may have noticed
> the new QPlatformTheme API and wondered what it is. In short, the
> QPlatformTheme API is there to support deeper platform integration,
> indepentently of QPlatformIntegration.
>
> ,
I am *very* interested
On Monday, 5 de December de 2011 14.50.23, Jeff Mitchell wrote:
> > At the Contributor Day in San Francisco, a number of people met to
> > discuss some of the issues involving QtNetwork, espcially
> > QNetworkAccessManager (QNAM). The overall idea is that eventually
> > QNetworkAccessManager, which
On Mon, Dec 5, 2011 at 12:50 PM, Jeff Mitchell wrote:
> Hello,
>
> I was asked to put this information on the wiki, but wasn't actually
> sure where the correct place was to do it. I'll put the info here and it
> can be moved into the wiki later. ,
>
At the Contributor Day in San Francisco, a nu
On Fri, Dec 2, 2011 at 8:27 AM, Kent Hansen wrote:
> Den 02. des. 2011 16:13, skrev ext Charley Bay:
> >
> > Den 02. des. 2011 09:33, skrev ext Kent Hansen:
> >
> > > Hi,
> > > See https://bugreports.qt.nokia.com/browse/QTBUG-22889
> &
Den 02. des. 2011 09:33, skrev ext Kent Hansen:
> > Hi,
> > See https://bugreports.qt.nokia.com/browse/QTBUG-22889
> >
> > Once http://codereview.qt-project.org/#change,9948 goes through CI,
>
This seems like important info, so I made a page on the wiki:
https://wiki.qt-project.org/Transition_
Marcus spaketh:
> I attended the Qt Contributor Day in San Francisco [1], and talked a
> little about infrastructure for the Qt project. infrastructure>
https://wiki.qt-project.org/Infrastructure >
>
IMHO this is an excellent effort -- the current system seems well
thought-out, and is clearly
On Thu, Nov 17, 2011 at 9:24 AM, David Faure wrote:
> On Thursday 17 November 2011 17:14:06 Robin Burchell wrote:
> > On Thu, Nov 17, 2011 at 5:11 PM, David Faure
> wrote:
> > > The method already asserts if the path is empty or is ".", we could
> make
> > > that stricter to catch more bugs (err
>
> Atlant spaketh:
> > When you settle on the set of "enhanced" features that
> > compilers must support to allow use with Qt, please design,
> > as the VERY FIRST PORTIONS of the Qt build procedure, a
> > small series of programs that deliberately test for and
> > stress those features.
Reading Alan's post a couple times, I *think* this summarizes to:
(a)- A new "Window{}" element is being proposed for QML that is different
from the current QML components. Specifically, the new "Window{}" is a
"top-level" concept, where you could have more-than-one, such as one for
each monitor.
67 matches
Mail list logo
