Re: [Development] Moving QFuture from QtConcurrent to QtCore

Hi, On Thursday 05 July 2012 08:01:43 Thiago Macieira wrote: > On quinta-feira, 5 de julho de 2012 04.46.22, lorn.pot...@nokia.com wrote: > > On 05/07/2012, at 2:16 PM, ext Thiago Macieira wrote: > > > There are no plans to write any class to replace QFuture. However, > > > renaming > > > the clas

Re: [Development] cmake files for qt5 problems with Qt5Quick/Qt5Qml modules on Mac OS X

On Wednesday, July 04, 2012 17:03:39 you wrote: > Hi Stephen, > > > Ok, can you post the full path of the Qt5QmlConfig.cmake you want to > > use, > > the full path of the Qt5CoreConfig.cmake you want to use, > > All the config files are found in qtbase: > > njeiseck ~/projects/qt/qt5 (master)$ f

Re: [Development] Move math3d from QtGui to QtCore

> Qwt would also have interest interest in classes like QPointF3D +1 > but this is not what QVector3D is ( or at least in Qt4 was ). As far as I > understood QVector3D is designed as a helper class for drawing and IMHO > should stay in QtGui as long as it is not implemented with a more common > u

Re: [Development] Move math3d from QtGui to QtCore

On 07/04/2012 08:33 PM, Thiago Macieira wrote: > And you also need to tell me that the classes are generally useful, even > outside of any relation to OpenGL (which was their original goal). Qwt would also have interest interest in classes like QPointF3D, but this is not what QVector3D is ( or a

[Development] Abandoning the container changes

Hello all I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. The changes are public, though, so we can always retrieve them for Qt 6 when we do it in

Re: [Development] Moving QFuture from QtConcurrent to QtCore

On quinta-feira, 5 de julho de 2012 04.46.22, lorn.pot...@nokia.com wrote: > On 05/07/2012, at 2:16 PM, ext Thiago Macieira wrote: > > There are no plans to write any class to replace QFuture. However, > > renaming > > the class right now is close to impossible due to source-compatibility > > requi

Re: [Development] QtCS: Qt Embedded

Hi Laszlo, On Fri, Jun 22, 2012 at 2:16 PM, Laszlo Papp wrote: > On Fri, Jun 22, 2012 at 6:45 AM, Girish Ramakrishnan > wrote: >> Hi, >> For those who were unable to attend, I have posted notes on >> http://qt-project.org/groups/qt-contributors-summit-2012/wiki/Qt-in-Embedded. > > Great! I have

Re: [Development] Moving QFuture from QtConcurrent to QtCore

On quarta-feira, 4 de julho de 2012 23.09.03, Marc Mutz wrote: > Any opinions either way? There are no plans to write any class to replace QFuture. However, renaming the class right now is close to impossible due to source-compatibility requirements. -- Thiago Macieira - thiago.macieira (AT) inte

[Development] Qt5 beta, MinGW: undefined reference to `WinMain@16'

main.cpp > #include > int main(int argc, char **argv) > { > QCoreApplication app(argc, argv); > return app.exec(); > } > > test.qbp > import qbs.base 1.0 > Application { > name : "Test" > Depends { > name: "Qt.widgets" > } > files : [ > "main.cpp" > ]

Re: [Development] Notes from the QWidget session

On Fri, 29 Jun 2012 11:57:58 ext Olivier Goffart wrote: > On Friday 29 June 2012 11:50:55 Alan Alpert wrote: > > On Tue, 26 Jun 2012 12:56:06 ext Harri Porten wrote: > > > - Converter of .ui files to QML? > > > > That's a good idea, and actually pretty close to useful already. All you > > really

Re: [Development] Move math3d from QtGui to QtCore

On 05/07/2012, at 5:31 AM, ext Thiago Macieira wrote: > > I don't know what other applications would use these classes you're proposing > to move. You have to show me that. advanced motion/computer vision gesture recognition systems could make use of them. I agree these classes should be lo

Re: [Development] Move math3d from QtGui to QtCore

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

[Development] Moving QFuture from QtConcurrent to QtCore

Hi, When QtConcurrent was been moved out of QtCore, some of it stayed behind in QtCore: QThreadPool, but not QFuture. I'm arguing here that QFuture should stay in QtCore, or else be renamed to QtConcurrent::Future, to not impede development in that area until Qt 6. QFuture is currently very mu

Re: [Development] Move math3d from QtGui to QtCore

On quarta-feira, 4 de julho de 2012 14.41.45, Charley Bay wrote: > (We > currently have our own 2D and 3D math libs, but if Qt had a non-GUI coupled > lib, we could use it.) Can you tell me whether those classes would suffice to your needs? -- Thiago Macieira - thiago.macieira (AT) intel.com Sof

Re: [Development] Move math3d from QtGui 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 couple to "QtGui" -- we cannot couple to QtGui either.)

Re: [Development] Move math3d from QtGui to QtCore

> I'm waiting for a reason to be in QtCore before I accept the classes into my > lib. You wanna me heading towards a math add-on module for these few classes? > There is a good reason for the command-line parser to be in QtCore: there are > uses for QtCore-only applications, as well as in QtCore

Re: [Development] Move math3d from QtGui to QtCore

On quarta-feira, 4 de julho de 2012 20.05.37, Laszlo Papp wrote: > I do *NOT* wanna have the QtGui stack as a dependency. If you think, I > should establish another module for these few classes because you do > not accept this in QtCore, I will. Again, this is VERY bad to depend > on the whole UI s

Re: [Development] Move math3d from QtGui to QtCore

> My concern is that QtCore is not a dumping ground for "everything non-GUI that > some library or app might need". We now have two discussions about moving > classes into QtCore. > I want to see a good argument of why it should be in QtCore, as opposed to why > it shouldn't be in QtGui. 99% of the

Re: [Development] Move math3d from QtGui to QtCore

On quarta-feira, 4 de julho de 2012 18.27.19, Laszlo Papp wrote: > Hi, > > I would like to propose to move the math3d folder with all the > portings of course to QtCore from QtGUI in Qt5. The reason is simple: > I have recently started to work again on QtAudio3D, and I realized > that, I would need

[Development] Mac: MouseMove events for inactive applications (qt4+qt5)

Hi, in Qt 4.x it's currently not possible to have mouse over effects for e.g. overlay windows if the application is not active. The following patch fixes that: diff --git a/src/gui/kernel/qcocoaview_mac.mm b/src/gui/kernel/qcocoaview_mac.mm index 646053a..9bd1d06 100644 --- a/src/gui/kernel/qcoc

[Development] Move math3d from QtGui to QtCore

Hi, I would like to propose to move the math3d folder with all the portings of course to QtCore from QtGUI in Qt5. The reason is simple: I have recently started to work again on QtAudio3D, and I realized that, I would need such things like QVector3D. Surely, an 3D audio Qt5 add-on should not depen

Re: [Development] Migrating widgets out of qtbase into their own repo

On 4 July 2012 07:03, wrote: > While on the topic, if we move the widgets, we should also move > libQtPrintSupport and libQtOpenGL to their own repositories. That would be nice, but I don't think QtPrintSupport can go as yet as the Mac plugin implementation is actually in the main Mac platform

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

On Tuesday, July 03, 2012 08:46:24 PM d3fault wrote: > QML is not interoperable with Qt/C++. > > It claims to be interoperable, but it's really not. > > QML can access everything from Qt/C++ (usually requires glue code), but Qt cannot access everything from QML. > > Examples: > a) Qt Graphical

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

On 07/04/2012 12:00 PM, d3fault wrote: > > > This is a bit of a red herring. You can do everything in the .ui you can > > do in C++ exactly because there is not that much you can do with it. You > > can have a fully static QML (without any JS) for the same purpose, but > > that would make no sense

Re: [Development] cmake files for qt5 problems with Qt5Quick/Qt5Qml modules on Mac OS X

Hi Stephen, > Ok, can you post the full path of the Qt5QmlConfig.cmake you want to use, > the full path of the Qt5CoreConfig.cmake you want to use, All the config files are found in qtbase: njeiseck ~/projects/qt/qt5 (master)$ find . -name "Qt5*Config.cmake" ./qtbase/lib/cmake/Qt53D/Qt53DConfig.

Re: [Development] cmake files for qt5 problems with Qt5Quick/Qt5Qml modules on Mac OS X

On Monday, July 02, 2012 15:06:34 Stephen Kelly wrote: > > The headers that are not being copied during a developer build cause > > build errors like this: > > myheaderfile.h:4:31: error: QQuickImageProvider: No such file or > > directory > > Ok, can you post the full path of the Qt5QmlConfig.cma

Re: [Development] Move QAction from QtWidgets to QtGui

On Wednesday, July 04, 2012 08:22:06 lars.kn...@nokia.com wrote: > * integration between a new action class and qaction doesn't require > inheritance. > > * i believe this class can and should be developed together with QML > components using it and with QAction interoperability in mind. This wou

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

> > So that is possible. > > QtQuick3D for example just does: > > "QT = core gui qml quick 3d" > > > > and there is no check anywhere in that repo that checks if QML should > be built, so you get an error about missing qml and quick modules. > > > > I wouldn't mind fixing it, but I just missed how

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

On Wed, Jul 04, 2012 at 12:11:02PM +, ext gunnar.sle...@nokia.com wrote: > contains(QT_CONFIG, qml):{ > # add qml stuff > } else { > # add other stuff > } > that's deprecated. !isEmpty(QT.qml.name) { ... is the official syntax. according to marius' will, anyway. ;) __

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

On Jul 4, 2012, at 1:27 PM, Vandonderen Casper (Nokia-MP/Oslo) wrote: > >> The modularization system already gives you this ability. If you do not >> build the qtdeclarative module, it will not >> install itself in the mkspecs/modules directory under QT_INSTALL_PATH and >> will not be availab

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

> The modularization system already gives you this ability. If you do not build > the qtdeclarative module, it will not > install itself in the mkspecs/modules directory under QT_INSTALL_PATH and > will not be available as modules. > .pro files can check for the availability of a certain modul

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

On Jul 4, 2012, at 12:49 PM, ext Corentin Jabot wrote: > 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

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

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 t

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

d3fault, after seeing all your posts in this list it is clear that your aim might be well aimed but is more obstructive than constructive. There is no lack of unavoidable obstacles in the road to Qt 5 launch and we really don't need any more - especially if they can be avoided. Can I ask you to

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

Op 4-7-2012 11:00, d3fault schreef: On Jul 4, 2012 1:18 AM, "Attila Csipa" > wrote: > >>replacement. There is no C++ equivalent of much of the functionality > > in QML, whereas everything you can do in a .ui file, you can do in C++. > > > > This is a bit of a red herr

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

On Wed, Jul 4, 2012 at 10:49 AM, wrote: > I would like to see the first, I think that being able to interface it to > different scripting languages would give it a lot of power. leaving aside the technical ramifications (increased code complexity, QA/performance hit due to abstraction and havin

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

On Jul 4, 2012 1:18 AM, "Attila Csipa" wrote: > >>replacement. There is no C++ equivalent of much of the functionality > > in QML, whereas everything you can do in a .ui file, you can do in C++. > > > > This is a bit of a red herring. You can do everything in the .ui you can > do in C++ exactly be

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

On 04/07/2012, at 6:07 PM, Konstantin Ritt wrote: > @Lorn: It would be nice if you give a more detailed response than just > "no" ;) Some technical details would be great to hear also. > technical details: if you don't sexy whiz bang animated ui's, don't use it. Not to mention we're not going

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

I would like to see the first, I think that being able to interface it to different scripting languages would give it a lot of power. Re "compilation", can't you include a qml file in a .qrc? I know it's not technically the same, but... --     Bill King     Lead Test Engineer     Nokia, Qt Cre

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

On 4 July 2012 09:17, d3fault wrote: > Also, did QML in the Trolltech days have javascript hacked on and forced-JIT > in the design? There's a 3rd option that I intentionally didn't mention that > is actually a sensible home for QML: .ui file replacement. Currently QML > depends too much on itself

Re: [Development] Move QAction from QtWidgets to QtGui

A few comments on the thread: * a QAction like class is needed, and yes it could maybe even live in QtCore * current Action is very tied to.widgets and i don't think splitting it up is a good idea * integration between a new action class and qaction doesn't require inheritance. * i believe t

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

In short, the introduction of QML introduces a new application model. Here, the C++ code is the model / logic, and the QML code is the UI / user interaction part. I don't really understand why the model / logics needs to access e.g. what animation or graphics effect the UI provides. Besides, you

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

On 07/04/2012 10:17 AM, d3fault wrote: > Lorn, so you think it should be allowed that Qt Modules are not > interoperable? > > Also, did QML in the Trolltech days have javascript hacked on and > forced-JIT in the design? There's a 3rd option that I intentionally > didn't mention that is actually

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

QML is in either the qtquick1 or qtdeclarative submodule, entirely outside of qtgui. Since qtgui is your personal feast, make merry and let your poised hurricane of commits run down upon us. w00t Diatribe Corr On Wed, Jul 4, 2012 at 12:17 AM, d3fault wrote: > On Jul 3, 2012 10:04 PM, wrote: >>

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

@Lorn: It would be nice if you give a more detailed response than just "no" ;) Some technical details would be great to hear also. @d3fault: Plz stop trolling and concentrate on technical issues, pros and cons, etc. The next time plz stop after your "Therefore, QML is not interoperable with Qt/C++

Re: [Development] Move QAction from QtWidgets to QtGui

Op 3-7-2012 18:31, Tomasz Siekierda schreef: > Hi, > > just a quick note regarding this: > >> Would it not be possible to split QAction in two classes, just like > QApplication was split? We could perhaps create a QCoreAction > > I think a better name would be QSimpleAction. Runs off the tongue a >

Re: [Development] Move QAction from QtWidgets to QtGui

Op 3-7-2012 18:45, simon.hausm...@nokia.com schreef: > I'm not a fan of moving QAction back to QtGui, because there it would be a > class that cannot be used by itself. Out of the box it is only useful with > the containers in QtWidgets. Why could it not be used by itself? I would totally use it

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

On Jul 3, 2012 10:04 PM, wrote: > > QML was started long before Nokia bought Trolltech. > > To answer your question, my opinion is No, QML should not be removed. > Lorn, so you think it should be allowed that Qt Modules are not interoperable? Also, did QML in the Trolltech days have javascript h