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 be
John Layt sayeth:
snip, Qt printing API changes
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.
snip,
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. snip,
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
classes
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 that we
snip, C++ Now 2014 Conference
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 kon...@silmor.de 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
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
classes, the
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 vote not
Tony sayeth:
snip,
We'd like to change the reference platforms a bit. We have new
platforms coming in and old ones are just that.old.
snip,
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
Tony sayeth:
snip,
We'd like to change the reference platforms a bit. We have new platforms
coming in and old ones are just that.old.
snip,
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 web
Simon sayeth:
snip, proposed integration of new QML Engine replacing V8
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
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.
+1, that's
Axel sayeth:
snip, whitespace-only changes for consistency to
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
snip, no Qt3D for mid-March Qt5.1 feature freeze
Sean sayeth:
snip, summary of Qt3D API and internals push for Qt5.2
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
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). snip,
+1
It would be nice to make this, turn-key.
For example, on platforms like Windows, it would-be-nice to
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 doing
Hi, Alan--
charley:
I've implemented a C++ adapter-layer (mostly template-based) to expose
C++
objects to QML. snip,
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 suggest
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): Error:
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 property
-
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:
I do not think
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). However,
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 like cygwin,
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, and
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 have
People keep asking for enumerations in QML. snip,
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?
snip,
I'd prefer:
Item {
enum Weather {
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
I understand others' concerns about load-performance. snip,
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
snip, updating the QtService 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
On Mon, Nov 26, 2012 at 10:40 AM, Matt Broadstone mbroa...@gmail.comwrote:
On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay charleyb...@gmail.comwrote:
snip, updating the QtService Component ,
I would like to open a new Qt Playground project to create a new
equivalent
+1
IMHO this would
Maurice spaketh:
snip,
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
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 really
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 snip,
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 a
Shawn Rutledge spaketh:
Personally I think the fundamental problem which CI could do better is to
triage problems. snip,
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
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 commens are
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,
Thanks, Alan -- very rich email that helps me think about
declarative-model-instance-handling.
Alan spaketh:
snip, What is QML declarative-best-practice for models?
Reusable components/delegates, where data propagates in one direction, is
the
best-practices pattern that obviates this need.
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 been
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 noexcept,
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
about
snip, please share thoughts on QFileSystemWatcher (maybe
monitor-recursive)
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,
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 essentially option
snip, possibly move math3d out of QtGui (maybe to QtCore)?
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
snip, possibly move math3d folder out-of-QtGui
charley spaketh:
snip, need not-coupled-to-GUI domain-specific math3D stuff
(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
How would you suggest solving it? QAction does have stuff like
bool showStatusText(QWidget *widget=0);
QWidget *parentWidget() const;
QListQWidget * associatedWidgets() const;
friend class QWidget;
so it seems difficult to make it avoid depending on widgets
snip, QMutex future-direction-discussion
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
snip, theme GUI interfaces for QML
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. snip,
Let me try explain more:
From user perspective: snip, want to re-use controls with different
themes
From
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).
PreferCompleteMatch /
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
m_volume
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 robin...@viroteck.netwrote:
Hi Tuukka,
(now that I've left some hours to digest this...)
2011/12/15 Turunen Tuukka
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.
snip,
I am *very* interested
On Fri, Dec 9, 2011 at 12:49 PM, Marcus D. Hanwell
marcus.hanw...@kitware.com wrote:
2011/12/9 Stephen Kelly stephen.ke...@kdab.com:
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
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 is
snip, Kent upcoming patch changes
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:
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.
56 matches
Mail list logo
