Re: [Development] qt 4/5 co-installs
On 06/27/2012 07:12 AM, Girish Ramakrishnan wrote: As you say, one solution is to have distros package the Qt4 and Qt5 libs with different prefix as /usr/lib/qt4 and /usr/lib/qt5. Certainly makes it easy for us but I guess there is a reason why all libs are stuck under /usr/lib ? Well Qt is not the only piece of software, that needs to live in different versions on the same system. Having individual paths for all of them ... A related note: distros also install Qt addon libraries ( here Qwt ) under /usr/lib. Unfortunately qmake/qtAddLibrary prepends - instead of appending - this path ( the include path too ) what leads to conflicts, when trying to build a local version of the addon library. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Assimp update for Qt5.0
Hi, I saw that Qt5 is using the Assimp-Library as a third party library for the Q3d-part, right. I just want to let you know that we just released version 3.0 for the next debian release. You can find it here: https://sourceforge.net/projects/assimp/ https://sourceforge.net/projects/assimp/ We changed the API, so 3.0 will not be binary compatible any more. Because we all are spare on time we haven't release our release-notes now but this will follow. Kimmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt 4/5 co-installs
On 27 June 2012 06:12, Girish Ramakrishnan gir...@forwardbias.in wrote: My reasoning for renaming tools and libraries was relatively straightforward: They are not backward compatible and thus shouldn't be given the same since Qt4 and Qt5 will have to live together for a long time. Qt4 and Qt5 should be able to exist in user's PATH simultaneously. But I don't see why the libraries need to be renamed. The sonames are different already. Most development software does not support installing the development files of two different major versions at the same time, in the same prefix. Is that true? gtk2 and gtk3 seems to reside together on my ubuntu 12.04. As you say, one solution is to have distros package the Qt4 and Qt5 libs with different prefix as /usr/lib/qt4 and /usr/lib/qt5. Certainly makes it easy for us but I guess there is a reason why all libs are stuck under /usr/lib ? As Thiago says it's pretty normal for libraries to keep the same names in different versions, the changed SONAME allows for the runtime bits both to be installed at the same time. It's the development files which can't be installed together, but that's not unusual. However gtk2 3 do differ in the actual library name /usr/lib/i386-linux-gnu/libgdk-3.so - libgdk-3.so.0.504.0 /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so - libgdk-x11-2.0.so.0.2400.10 so changing library names is also not uncommon and allows for developer environments to be co-installed. The tools are more important because this makes packaging fiddly. The runtime plugin environment variable $QT_PLUGIN_PATH is most important because the runtime libraries should be co-installable. Libraries need to be in /usr/lib so that they can be found, if they're in a directory not in the known load library path they can't be loaded when programmes that need them get run. Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Assimp update for Qt5.0
I saw that Qt5 is using the Assimp-Library as a third party library for the Q3d-part, right. I just want to let you know that we just released version 3.0 for the next debian release. You can find it here: Have you fixed the compilation issue with VS 2012 RC ? There was a missing include... Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Is clang still considered unsupported for Linux in Qt 5?
Top of the morning, There is an infinite amount of insight on this list and a complimentary infinite deficit in my noodle, so I thought I would put it to the list: building Qt with unsupported/linux-clang has worked gloriously (on Linux) for most of the Qt 5 dev cycle although there was some unparseable low level breakage in Qt Declarative at some point. This is clearly fixed now, and I was wondering if there was a reason Clang is not advancing to being a first class citizen, whether there was a time frame for joining the CI system, what the outstanding issues were and whether this was simply off the radars of the more freakishly insightful tech-gnomes we have scuttling around. Cheers, Donald -- --- °v° Donald Carr /(_)\ Vaguely Professional Penguin lover ^ ^ Cave canem, te necet lingendo Chasing my own tail; hate to see me leave, love to watch me go Feeding the trolls is only marginally more rewarding than feeding the pigeons, and carries the same consequences ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Assimp update for Qt5.0
Good question, I have to doublecheck. Grettings Kim Kulling On Wed, Jun 27, 2012 at 11:02 AM, Laszlo Papp lp...@kde.org wrote: I saw that Qt5 is using the Assimp-Library as a third party library for the Q3d-part, right. I just want to let you know that we just released version 3.0 for the next debian release. You can find it here: Have you fixed the compilation issue with VS 2012 RC ? There was a missing include... Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Assimp update for Qt5.0
On Wed, Jun 27, 2012 at 10:17 AM, kim kulling kim.kull...@googlemail.com wrote: Good question, I have to doublecheck. http://lists.qt-project.org/pipermail/development/2012-June/004431.html Please make a patch release, if needed. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt 4/5 co-installs
On quarta-feira, 27 de junho de 2012 09.48.01, Jonathan Riddell wrote: As Thiago says it's pretty normal for libraries to keep the same names in different versions, the changed SONAME allows for the runtime bits both to be installed at the same time. It's the development files which can't be installed together, but that's not unusual. However gtk2 3 do differ in the actual library name /usr/lib/i386-linux-gnu/libgdk-3.so - libgdk-3.so.0.504.0 /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so - libgdk-x11-2.0.so.0.2400.10 Yes, they do, but there are many more libs that don't. I don't want to forcibly rename the Qt libraries now. We could add the 5 to the name in all platforms, such as Windows is doing right now, but I simply don't want to do that. I see no compelling reason to do it. If you really, really, really want to install the two development environments in parallel, and considering that we already do need different prefixes, I'd say that the .so and .a files (if any) should be in $prefix/lib (e.g., /usr/lib/qt5/lib) and symlink to the actual files that live in /usr/lib. qmake will have the lib path hardcoded and will add the necessary -L; cmake gets the information from qmake. so changing library names is also not uncommon and allows for developer environments to be co-installed. The tools are more important because this makes packaging fiddly. The runtime plugin environment variable $QT_PLUGIN_PATH is most important because the runtime libraries should be co-installable. I agree on the environment variable. Let's add a version number there. I said I wasn't going to comment on the tools, but here's one comment: only qmake needs to be versioned, since it's the only tool that users run. The other ones like moc, uic, rcc, lconvert, lrelease, lupdate, qmlviewer, qmlscene can be hidden away in libexec or in $prefix/bin. And designer, assistant, linguist, qdbus, qdbusviewer are applications: you don't install two of them. Of much greater interest is ensuring that multi-arch works properly. The Qt headers should be entirely platform-agnostic now, as there's no QT_ARCH setting in qconfig.h. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt 4/5 co-installs
On Wednesday, June 27, 2012 11:28:18 Thiago Macieira wrote: If you really, really, really want to install the two development environments in parallel, and considering that we already do need different prefixes, I'd say that the .so and .a files (if any) should be in $prefix/lib (e.g., /usr/lib/qt5/lib) and symlink to the actual files that live in /usr/lib. qmake will have the lib path hardcoded and will add the necessary -L; cmake gets the information from qmake. That is true in Qt 4, but not in Qt 5. CMake would need some way of finding the Qt5CoreConfig.cmake file if both Qt 4 and Qt 5 development files were installed. That could be a user-issue and not a distro-issue though, as the easist way to do that is with an environment variable. The file will already automatically be found if installed to /usr/lib. so changing library names is also not uncommon and allows for developer environments to be co-installed. The tools are more important because this makes packaging fiddly. The runtime plugin environment variable $QT_PLUGIN_PATH is most important because the runtime libraries should be co-installable. I agree on the environment variable. Let's add a version number there. I said I wasn't going to comment on the tools, but here's one comment: only qmake needs to be versioned, since it's the only tool that users run. The other ones like moc, uic, rcc, lconvert, lrelease, lupdate, qmlviewer, qmlscene can be hidden away in libexec or in $prefix/bin. And designer, I can imagine wanting to be able to run both Qt 4 and Qt 5 designer. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QStandardItemModel to QtGui
On Tuesday 26 June 2012 18:12:14 Stephen Kelly wrote:
Hi there,
I know it is late, but it was recently brought to my attention that
QStandardItemModel could be moved from QtWidgets to QtGui, since QIcon was
moved to QtGui.
It seems that people doing model-view like to use QStandardItemModel, and
forcing the use of the widgets module for that is unfortunate.
Any objections to me moving that to src/gui/itemmodels?
Thanks,
How about QtCore?
Yes, there are mention of QBrush, QFont, QIcon... but:
In the .cpp file, they are only used by reference, so do not need to include
them.
In the .h file, it is used in inline code for some setter and getter.
The setters just need QVariant. QVariant::fromValue does not need to know
about the type, it just needs the qMetaTypeId (we have it, it is a builtin
type) and the QTypeInfo (we could register thos types). So we are fine.
For the getters: since they are not called from the .cpp we could do some
template magic
templatetypename T = QIcon
inline T icon() const {
static_assert(std::same_typeQIcon, T::value, wrong template arg);
return qvariant_castT(data(Qt::DecorationRole));
}
Since there is a default argument, you can call the function as if it was not
a template function, and because it is a template function, it is only
compiled at instentiation time, where QIcon must be included.
And that's it: we could move it in QtCore if we want.
That said, it is probably fine in QtGui
--
Olivier
Woboq - Qt services and support - http://woboq.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Behavior change in QtQuick 2.0 Qml ListModel (for javascript date object)
Hi, The relevant bug is https://bugreports.qt-project.org/browse/QTBUG-24456. For now, using dynamicRoles as Joona suggested should work around the problem. thanks for pointing me to bug report and for providing the workaround! Nils ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QStandardItemModel to QtGui
I was requesting the same a good while back, but then decided that my needs are better served by more QML-optimized class (QSIM is badly stuck in QWidget mindset): https://github.com/jnynas/QuickModel https://github.com/jnynas/QuickModel/blob/master/quickmodel.h Instead of QStandardItemModel, it could make sense to introduce a new class that didn't carry around the QWidget legacy of QSIM. On Tue, Jun 26, 2012 at 7:12 PM, Stephen Kelly stephen.ke...@kdab.com wrote: Hi there, I know it is late, but it was recently brought to my attention that QStandardItemModel could be moved from QtWidgets to QtGui, since QIcon was moved to QtGui. It seems that people doing model-view like to use QStandardItemModel, and forcing the use of the widgets module for that is unfortunate. Any objections to me moving that to src/gui/itemmodels? Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QBS] qbs platforms ls show nothing, qbs-platforms ls works well!
On 26/06/2012 01:37, ext Loaden wrote: Of cause, It's only Qt5 issue. and only happened on Windows. (As I know on Linux everything works well) See: [...] If re-direct to some log, like this: qbs platforms ls output.log output.log, Then you can see what you want. Any comments? So you mean in Qt5 QProcess:execute does not forward the output of the process on Windows? I can't reproduce this issue with Qt5 and MSVC2008. BR, Jörg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QBS] qbs platforms ls show nothing, qbs-platforms ls works well!
Yes, that what's I mean. and I use *MSVC2010SP1 (from Windows SDK 7.1 + VCSP1_update)*, on Windows 7 SP1 x64 or Windows 7 SP1 x86 both has the problem. 2012/6/27 Joerg Bornemann joerg.bornem...@nokia.com On 26/06/2012 01:37, ext Loaden wrote: Of cause, It's only Qt5 issue. and only happened on Windows. (As I know on Linux everything works well) See: [...] If re-direct to some log, like this: qbs platforms ls output.log output.log, Then you can see what you want. Any comments? So you mean in Qt5 QProcess:execute does not forward the output of the process on Windows? I can't reproduce this issue with Qt5 and MSVC2008. BR, Jörg -- Please don't ask where I come from, It's a shame! Best Regards Yuchen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
On 25/06/2012 13:44, ext Girish Ramakrishnan wrote: Future plans - Desktop OpenGL 3+ support, ES 3 support We've just added ANGLE support in Qt (-angle dir), to enable DirectX usage instead of OpenGL ES 2 on Windows, due to many buggy drivers. How will this effort affect this usage? Will we actively contribute to the ANGLE project, to ensure it's usable when we extend our use of OpenGL? It would be bad for end users if they rely on ANGLE and we change the OpenGL backend to use functionality not covered by ANGLE in the next version, making migration to the next version of Qt impossible. What is the timeline for OpenGL 3+ support, and when is OpenGL ES 3 scheduled for release? -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
On 27/06/2012 12:14, ext Sean Harmer wrote: On Wednesday 27 June 2012 16:30:50 marius.storm-ol...@nokia.com wrote: On 25/06/2012 13:44, ext Girish Ramakrishnan wrote: Future plans - Desktop OpenGL 3+ support, ES 3 support We've just added ANGLE support in Qt (-angle dir), to enable DirectX usage instead of OpenGL ES 2 on Windows, due to many buggy drivers. You mean for embedded flavours of Windows right? OpenGL 3+ works fine on desktop windows - although getting hold of a Core Profile context on Windows via Qt was broken last time I tried it (but that was some months ago). No, I don't mean for embedded alone. Desktop OpenGL drivers are also of quite varying quality, and the DirectX drivers are usually better. Not to mention that with Windows 8 you might have a hard time getting access to the OpenGL APIs, depending on which system you are on and how integrated you want to be. No WGL/EGL support for Metro applications afaik, see http://msdn.microsoft.com/en-us/library/windows/apps/br205756.aspx and http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/c77de65a-1fbb-491f-9f6b-0c4a7b452ec2 and http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/a861db02-dce8-4f61-9969-b8a7a7cd55c7 (Yes, non-Metro apps can use OpenGL just fine, although reports have come back that currently the OpenGL drivers are lagging behind the DirectX ones.) No OpenGL for Windows 8 RT (ARM) version either, which should also be a target. How will this effort affect this usage? The same way it will affect those platforms that only support OpenGL ES2 I guess - they just won't use the new features/capabilities. Ok, so ifdef out the extensions completely when we compile with the ANGLE library? Will we actively contribute to the ANGLE project, to ensure it's usable when we extend our use of OpenGL? It would be bad for end users if they rely on ANGLE and we change the OpenGL backend to use functionality not covered by ANGLE in the next version, making migration to the next version of Qt impossible. What is the timeline for OpenGL 3+ support, and when is OpenGL ES 3 scheduled for release? It is possible to use OpenGL 3 (or even 4) on the desktop right now just that Qt does not yet wrap the new features. OpenGL ES 3 is scheduled for release soon which translates to probably sometime this year. It is supposed to reduce the delta between desktop OpenGL and OpenGL ES. Good to know, thanks. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Thanks for the update. I just want to say 'hear hear' (or at least Looks good to me, but someone else must approve) ;) I do think that it would be a *very good idea* to have a QtWidget maintainer. Not because Girish isn't a good approver (since he obviously is) - but in order to ensure that people sees QtWidgets as alive. One of the reasons people consider Qt Widgets as dead (and can argue that they are) - is the lack of a maintainer(!) - and it would be far easier to spread the word about QtWidgets if we had a such. But of course the Widgets are still alive - and Stephen Kelly is also helping improving the Item Views in Qt Widgets - and afaik there has been some nice fixes. To brag a bit I have (with his help) improved QHeaderView so that TableViews can handle many data and unlike Qt4 do moveSection, swapSection(s), hideSection and trunc of model reasonable fast. (Hopefully without any regressions:) ) However - the above is actually not just to brag. It is to give an example of something that has been improved. We need to show and know(!) about QtWidgets progress. It is easy to state: Qt is alive - but someone could ask ... why?. (And the reason 'it wasn't killed is not enough ...). So if people knows about big (or many) improvements to QtWidgets - it could be a good place and time to speak up. So here is a good chance for people to give credit to themselves (or others) Btw. Is somebody looking into the regressions in QGraphicsView? On Tue, Jun 26, 2012 at 12:56 PM, Harri Porten por...@froglogic.com wrote: Here are my notes from the QWidgets session on June 22th, 2012, 11:30 o'clock: http://qt-project.org/groups/qt-contributors-summit-2012/wiki/QtWidgets General === - Great interest in QtWidgets - Code base actively ported to Qt 5, far from dead. - Present company considering maintainership Candidates for new widgets == - Breadcrumb navigation - Progress spinner - Make use of KDE Frameworks 5 + Clear button in QLineEdit + URL button, etc. - Check out widget galleries from other toolkits - Be aware of platform-specific IP protection Help with migration from Qt 3/4 to 5 - Desktop QML components (using QStyle) - Wrap QWidgets in QML container element - Educate developers about UI/backend separation - Converter of .ui files to QML? Open Issues === - Regressions in QGraphicsView - Fixes needed for Mac OS X Lion - Investigate Windows 8 Metro - Get message out about QWidgets being alive ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
On Wednesday 27 June 2012 17:46:32 marius.storm-ol...@nokia.com wrote: On 27/06/2012 12:14, ext Sean Harmer wrote: On Wednesday 27 June 2012 16:30:50 marius.storm-ol...@nokia.com wrote: On 25/06/2012 13:44, ext Girish Ramakrishnan wrote: Future plans - Desktop OpenGL 3+ support, ES 3 support We've just added ANGLE support in Qt (-angle dir), to enable DirectX usage instead of OpenGL ES 2 on Windows, due to many buggy drivers. You mean for embedded flavours of Windows right? OpenGL 3+ works fine on desktop windows - although getting hold of a Core Profile context on Windows via Qt was broken last time I tried it (but that was some months ago). No, I don't mean for embedded alone. Desktop OpenGL drivers are also of quite varying quality, and the DirectX drivers are usually better. I only have access to nVidia boards at present so can't comment on the other manufacturer's driver quality/completeness. Not to mention that with Windows 8 you might have a hard time getting access to the OpenGL APIs, depending on which system you are on and how integrated you want to be. No WGL/EGL support for Metro applications afaik, see http://msdn.microsoft.com/en-us/library/windows/apps/br205756.aspx and http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/c 77de65a-1fbb-491f-9f6b-0c4a7b452ec2 and http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/a861d b02-dce8-4f61-9969-b8a7a7cd55c7 (Yes, non-Metro apps can use OpenGL just fine, although reports have come back that currently the OpenGL drivers are lagging behind the DirectX ones.) No OpenGL for Windows 8 RT (ARM) version either, which should also be a target. Hmmm, I've not played with Win 8 at all yet. No OpenGL on Metro style apps of Win8 Arm is indeed a PITA. Thanks for the info. Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
On 27/06/2012 12:55, ext Thorbjørn Martsum wrote: Btw. Is somebody looking into the regressions in QGraphicsView? Nope, QGV is currently lacking a maintainer. Anyone with qualifications and feeling the urge? :) -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Hi! On Wed, 27 Jun 2012, Thorbjørn Martsum wrote: I do think that it would be a very good idea to have a QtWidget maintainer. Not because Girish isn't a good approver (since he obviously is) - but in order to ensure that people sees QtWidgets as alive. One of the reasons people consider Qt Widgets as dead (and can argue that they are) - is the lack of a maintainer(!) - and it would be far easier to spread the word about QtWidgets if we had a such. Yes. And to be realistic: a single maintainer won't be enough. It's a lot of different fields that might need to be distributed on several shoulders. So even if some individual or company steps up one has to be fair and rather help than demanding too much. But of course the Widgets are still alive - and Stephen Kelly is also helping improving the Item Views in Qt Widgets - and afaik there has been some nice fixes. To brag a bit I have (with his help) improved QHeaderView so that TableViews can handle many data and unlike Qt4 do moveSection, swapSection(s), hideSection and trunc of model reasonable fast. (Hopefully without any regressions:) ) Nice to hear. However - the above is actually not just to brag. It is to give an example of something that has been improved. We need to show and know(!) about QtWidgets progress. It is easy to state: Qt is alive - but someone could ask ... why?. (And the reason 'it wasn't killed is not enough ...). So if people knows about big (or many) improvements to QtWidgets - it could be a good place and time to speak up. Right. That was the main message we wanted to bring across. To state that a positive feedback loop rather than a negative self-fulfilling prophecy is needed and doable. So here is a good chance for people to give credit to themselves (or others) Btw. Is somebody looking into the regressions in QGraphicsView? As Marius already hinted at: it's needed. But given the complexity no easy job. A full-time job maybe. Harri.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
To use Qml on Win8 Metro, we must have a directX backend (with or without angle .. but it seems that for now angle is directX9 only and Metro need DX11), and to be able to use qt5 qml for digital signage on low end hardware ( in that case qt5 qml is just perfect...) we need to have hardware accelerated video decoding (dxva) on Windows .. so it need to have a way to bridge qml video to angle directx surface to have access to dxva 2012/6/27 Sean Harmer sean.har...@kdab.com On Wednesday 27 June 2012 17:46:32 marius.storm-ol...@nokia.com wrote: On 27/06/2012 12:14, ext Sean Harmer wrote: On Wednesday 27 June 2012 16:30:50 marius.storm-ol...@nokia.com wrote: On 25/06/2012 13:44, ext Girish Ramakrishnan wrote: Future plans - Desktop OpenGL 3+ support, ES 3 support We've just added ANGLE support in Qt (-angle dir), to enable DirectX usage instead of OpenGL ES 2 on Windows, due to many buggy drivers. You mean for embedded flavours of Windows right? OpenGL 3+ works fine on desktop windows - although getting hold of a Core Profile context on Windows via Qt was broken last time I tried it (but that was some months ago). No, I don't mean for embedded alone. Desktop OpenGL drivers are also of quite varying quality, and the DirectX drivers are usually better. I only have access to nVidia boards at present so can't comment on the other manufacturer's driver quality/completeness. Not to mention that with Windows 8 you might have a hard time getting access to the OpenGL APIs, depending on which system you are on and how integrated you want to be. No WGL/EGL support for Metro applications afaik, see http://msdn.microsoft.com/en-us/library/windows/apps/br205756.aspx and http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/c 77de65a-1fbb-491f-9f6b-0c4a7b452ec2 and http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/a861d b02-dce8-4f61-9969-b8a7a7cd55c7 (Yes, non-Metro apps can use OpenGL just fine, although reports have come back that currently the OpenGL drivers are lagging behind the DirectX ones.) No OpenGL for Windows 8 RT (ARM) version either, which should also be a target. Hmmm, I've not played with Win 8 at all yet. No OpenGL on Metro style apps of Win8 Arm is indeed a PITA. Thanks for the info. Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Hm... What about adding new (maybe rather simple) widgets? QtCreator has QtColorButton class, QtFontButton, lineedit for editing shortcuts (i have my own modified copy). Browser example has ModelMenu and ModelToolBar classes (rather useful in some cases). Recently, I implemented Windows menu (popup menu with list of top-level windows and actions to minimize/maximize/change current window). I can add these classes to QtWidgets, if needed. IMHO, it's nice to have color button in Designer, for example. Ivan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
