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 feel the urge to give my two cents on that.
At least on unix desktop platforms, I expect to get stderr output on the
console.
So, detecting its presence is certainly a good approach.
When there is no console, I probably don't care about the logs at all.
I *may* care about error/warning
2013/9/11 Olivier Goffart oliv...@woboq.com:
Alright guys, let's try to complete the feature. As I heard from sides
now that you want a key-value store, I'll do it that way.
Feature list:
1. Q_INFO is a new macro (which expands to nothing):
#define Q_INFO(key, value)
Since we have
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
Yes, very much like that, but updated to also support the Qt5 like way
of connecting.
Yes, that could work. To make it truly optional though, the main
parallel function would have to be pre-bound by the programmer (e.g.
using https://codereview.qt-project.org/#change,45294), since the
2013/2/22 Sze Howe Koh szehowe@gmail.com:
Yes, that was my original plan. Someone complained that they couldn't
bind a function + arguments to QtConcurrent::run() first, then run it
at a later time. This approach gives them the opportunity to start it
whenever they want.
The problem is
2013/2/22 André Somers an...@familiesomers.nl
If only QFuture allowed you to connect... Unfortunately, it is not a
QObject
Oh yeah, I almost forgot that bit. And somehow it looks like the core issue.
I wonder why by the way:
We could have something like QObject - QFutureBase (with all
Hi. I'm the one Olivier mentioned :p
I didn't have time to pursue further the work I started, but I intend
to, someday.
The plan, as suggested by thiago was to have a QThread::run(functor)
method acting exactly like QtConcurrent::run, but using a new QThead.
A similar QThreadPool::run function
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
The following seems like a good subset of the QAbstractSocket
interfaces that also makes sense for QLocalSocket
void abort ()
void disconnectFromHost ()
SocketError error () const
bool flush ()
bool isValid () const
qint64 readBufferSize () const
void setReadBufferSize ( qint64 size )
bool
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
I do not want participate to some not constructive discussion
Still,
Last time I checked ( a month ago), each module that provide a QML plugin
had to be build against QML. (system, multimedia kit, etc)
So you can not build Qt without building QML ( and QML it self depends
on several modules)
I
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
20 matches
Mail list logo
