Having had the pleasure to use QBS quite extensively (and successfully) in
the past, I would like to thank the QBS team and contributors for showing
us what a sane, modern build system could look like.
So long!
On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote:
> Hi all,
>
> As you will probably
I think that part of the issue is that the way the STL should be treated is
a bit of a polarizing issue.
Of course, there are technical considerations, such as some STL
implementations being lacking on older platforms, but mostly Qt and the STL
have some overlaps, and people can't agree on how to
Funny, a friend at kdab asked me about that exact question a few minutes
ago.
The reason for the difference is most certainly an historical one ( and
can't be changed because it would break quite a bit of code ).
If you want the same behavior, you can create a proxy for your associative
container
Is std::algo(std::begin(container), std::end(container) ... ) troublesome
enough that it warrants a wrapper ?
I have a few concerns:
* There is a large momentum behind the range proposal, and, if it wont
be in the standard before 2-4 years, I would expect the TS to be usable
long before that.
JSC is pretty slow to build compared to V4. I think It's an inconvenient.
And it would negate the efforts to get rid out of QtScript/JSC in Qt.
It may be wishful thinking, but it would be great if QBS and Qml could use
the exact same engine that would only be build once.
Le mer. 8 mars 2017 à
For what it's worth, as a Qt user, QBS was, last time I checked missing
some features, like non-transitive compilatuons flags, platform support and
documentation.
That being said, in the past few years, I wrote some makefiles, some cmake
projects. I've used WAF, qmake... QBS is the best C++
WIP patch to add QJSEngine::newQMetaObject
https://codereview.qt-project.org/160759
Le sam. 28 mai 2016 à 11:42, Corentin <corentin.ja...@gmail.com> a écrit :
> Hello.
> I'm once again trying to cut dependencies on Qt Script.
>
> QJSEngine still lacks some
?
- If not, is there an interest for these api ?
[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Necko/Proxy_Auto-Configuration_(PAC)_file
Regards,
Corentin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman
First of, it should be ensured future planes fit on the tarmac and that
people now how to fly these things. Major breakage are a huge pain.
Unavoidable minor breakage are painful enough, we always seem to
underestimate the cost of any stack change. The plane metaphor still holds.
You need to
Having stumbled upon this issue very recently, here are my 2 cents.
- Svg images should be devicePixelRatio aware without having to set a
source size
- Likewise, QQuickImageProvider should know about devicePixelRation,
without having to set a source size.
- I would absolutely love
2015-03-18 11:00 GMT+01:00 Simon Hausmann simon.hausm...@theqtcompany.com:
On Tuesday 17. March 2015 15.04.19 Corentin Jabot wrote:
Regarding QJSEngine, some things are unclear to me.
Let's say I have a QObject-derived class. how do I create an instance of
that class from a script
...
worrisome
I think QJSEngine should aim to be compatible with any script that worked
with QScriptEngine (provided the C++ code is modified accordingly)
Regards,
Corentin Jabot
2015-02-10 4:30 GMT+01:00 Thiago Macieira thiago.macie...@intel.com:
On Monday 09 February 2015 22:52:34 Kevin Kofler
Looks like there are many different uses cases and point of views, we may
not reach an agreement.
I agree that the default settings should be as unified as possible, but, on
the other and, each platform
having different capabilities, it make sense to set the default behavior on
a
:
I don't expect end-users to know how access those logs, even less to
provide the developers
with them when something goes wrong.
Corentin
2014-07-10 1:20 GMT+02:00 Thiago Macieira thiago.macie...@intel.com:
On Wednesday 09 July 2014 14:43:36 Thiago Macieira wrote:
Current Linux desktops
several items
Corentin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
2013/3/12 Oswald Buddenhagen oswald.buddenha...@digia.com:
somebody attempted this just a few days ago, but gave up when the scope
of the undertaking became clear. i can't find the change now ...
https://codereview.qt-project.org/#change,48150
I indeed gave up, or at least I was trying to
. That would truly be
event-driven C++!
Yeah, that is a very unfortunate artifact of the way Qt implements
signals and slots. However, it is what it is...
Would that even be possible ? It sure would be nice
Corentin
___
Development mailing list
Development
returning QThread* : what about the function return value ? That
should be accessible, easily.
It's one of the reason I prefer QFuture over QThread*
Regards,
Corentin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org
requiered signals/slots) - QFutureT
or is there something I'm not seeing ?
Of course now its too late, but we could introduce something new, like
QFutureObject ?
Corentin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org
, I'm not sure we would benefit from
a function - the only factorizable part is
QThread* t = new QThread();
obj-moveToThread(t);
connect(t, SIGNAL(finished()), t, SLOT(deleteLater()));
Maybe we should first agree on how QThread sould work before trying to
add yet-another-way.
Regards,
Corentin
I agree with d3fault/oswald.
Adding some setters/properties for the connection parameters of
QLocalSocket/QAbstractSocket and a generic connect method would make
the api somehow more usable.
Maybe a connectToHost() method - connectToPeer may be a little less generic.
QLocalSocket and
error ( QAbstractSocket::SocketError socketError )
void stateChanged ( QAbstractSocket::SocketState socketState )
I dont see how the connectTo* methods could be shared, and I don't
think it would be a good idea to try to do so.
Regards,
Corentin.
2012/11/6 Thiago Macieira thiago.macie...@intel.com
2012/11/7 Thiago Macieira thiago.macie...@intel.com:
On quarta-feira, 7 de novembro de 2012 00.07.41, Corentin Jabot wrote:
The following seems like a good subset of the QAbstractSocket
interfaces that also makes sense for QLocalSocket
I don't want you to list functions that are common. I can
become quite unmanageable and slow the evolution of QML
Corentin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Hi.
It just happen I worked on the ANGLE integration few weeks ago.
ANGLE offer an OpenGL-ES 2.0 api on top of DirectX 9.
I manage to get Qt compiling with ANGLE and some (one actually)
examples are working.
But, for the the others example, I just got a black surface or crashes.
Sadly, I do not
So, There is the patch.
* First, checkout and build ANGLE as explain here
http://code.google.com/p/angleproject/wiki/DevSetup ( require directx sdk
visual studio )
* Then, edit qtbase/mkspecs/features/win32/opengl.prf and change the
include and library path of angle ( or just build angle in
to work on a patch.
Like it seems a little late for 5.0, it could be add in 5.1.
What do you think ?
Corentin Jabot,
Software Developer at Ankama, France.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman
- but perhaps
the other way around would have made more sens
The change should be both binary and source compatible.
Also, as it my first contribution to Qt I'm not so sure about the naming rules
Corentin Jabot.
___
Development mailing list
Development@qt
28 matches
Mail list logo
