Re: [Interest] Can't login to bugreports.qt.io / OpenGL bug
> > And just in case, here's the bug: > > - Download and install Qt 5.6.0 for Windows, 64bits, Visual 2013 > > - Open \5.6\Src\qtbase\examples\opengl\qopenglwidget\ > > qopenglwidget.pro example in QtCreator > - Build, run: fine. > > - Set the screen colors to 65536 (16bits), from > > "Display/Resolution/Advanced" monitor property. > - Build, run: crash. > > Tested in Windows 7, 64bits, GPU nVidia Quadro K2000. In can give a > > call stack is needed. > > The example requests a 32-bit RGBA default framebuffer. System can't > provide it as you set it to 16-bit colour. Example doesn't check for > this case. Boom. > > 1) Change system back to 32-bit color (24-bit RGB) > 2) Change example to request 16-bit framebuffer. Actually I didn't find any request for 32-bit RGBA in the example... Neither in the doc about QPainter, QOpenGLWidget nor QOpenGLWindow. Unless I missed something? Just in case, I removed the format request in the main(): so basically now I get whatever the OS will give me by default. But it still crashes... Also I may not have the hand on the machine running the program - it may be a customer's machine far, far away in a distant... well you get the idea. Regards, ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Can't login to bugreports.qt.io / OpenGL bug
Hello all, Not sure where to ask, so I post here I'm trying to report a bug, but I can't login to bugreports.qt.io nor login.qt.io. I gave a mail address, a password, but then I'm stuck at the page " This will be your username at blabla": when I click "Set username", it ends with a "Internal server error" page. Tried on Windows 7, 64bits, Firefox & IE. Any hint is welcome... And just in case, here's the bug: - Download and install Qt 5.6.0 for Windows, 64bits, Visual 2013 - Open \5.6\Src\qtbase\examples\opengl\qopenglwidget\ qopenglwidget.pro example in QtCreator - Build, run: fine. - Set the screen colors to 65536 (16bits), from "Display/Resolution/Advanced" monitor property. - Build, run: crash. Tested in Windows 7, 64bits, GPU nVidia Quadro K2000. In can give a call stack is needed. Regards, -- Yves Bailly Software developer ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Are slots even needed these days?
A use case for "old-style" slots is when you have dynamic connections,
established at runtime
from some config file: you get the names of the signals and the slots as
strings.
With the old style, your code can be as simple as
QObject::connect(foo, signal_name_string, bar, slot_name_string);
With the new style, you would have to manually map the strings to the function
pointers, hence modifying the connection code each time a new signal or slot is
added.
--
Yves Bailly
Software developer
> -Original Message-
> From: Interest [mailto:interest-bounces+yves.bailly=verosoftware.com@qt-
> project.org] On Behalf Of Nikos Chantziaras
> Sent: Wednesday, March 16, 2016 3:25 PM
> To: interest@qt-project.org
> Subject: [Interest] Are slots even needed these days?
>
> Since in modern Qt you connect signals to functions/lambdas, is there a
> reason to declare slots anymore?
>
> In other words, is there any difference between:
>
>class Foo: public QObject {
>Q_OBJECT
>
>public slots:
>void bar();
>};
>
> and:
>
>class Foo: public QObject {
>Q_OBJECT
>public:
>
>void bar();
>};
>
> I can connect to Foo::bar either way. If I don't intend to ever use the
> old-style connect syntax, is there a reason to have "public slots:"
> anymore?
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] WIndows | QMake | DLL
> -Original Message- > I'm trying to build my project on windows using MSVC 2013. > > Project consist of shared lib project and app project. app project > depends on shared lib. > > Everything is fine, but on final link I always receive error like: > "cannot open input file MyDll.lib". > > MyDll.dll is built, but MyDll.lib doesn't exists. > > Is it qmake's error? If you're coming from a GCC world, there's an important difference between GCC and MSVC: GCC exports symbols by default, while MSVC doens't. In MSVC, you need to explicitly exports the symbols you want to link against in other projects. If you don't export anything, then MSVC won't generate the .lib file. See: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx https://msdn.microsoft.com/en-us/library/a90k134d.aspx ...or Google for "__declspec(dllexport)". Hope this helps, -- Yves Bailly Software developer ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Windows, OpenGL and Qt5.5.0
Hello all, I just downloaded Qt 5.5.0 for Windows (Win7, 64bits, Visual C++ 2013) and started rebuilding a large project, which is running just fine with Qt 5.4.1. Now I get many OpenGL-related link errors, such as: error LNK2019: unresolved external symbol __imp_glDisable referenced in function Is there some config needed in the .pro file? I read somewhere that now desktop OpenGL is dynamically loaded using some kind of config file... After having spend 45min digging in the documentation, I can't find anything related to those issues... Any help greatly appreciated! Regards, -- Yves Bailly Software developer ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Windows, OpenGL and Qt5.5.0
Thanks Kai for your answer. Indeed I bumped on this page, but as it talks about building Qt related to requirements, I didn't read it thoroughtly... as the issue is not related to building Qt nor to Windows requirements, but more related to how to use OpenGL in Qt ;-) Maybe at least a link into the Windows specific section and/or the Whatsnew in Qt5.5 section would improve the discoverability of this essential piece of information. Anyway I'll follow the advices and hopefully will be able to rebuild the project. Best regards, -- Yves Bailly Software developer -Original Message- From: Koehne Kai [mailto:kai.koe...@theqtcompany.com] Sent: Thursday, July 16, 2015 5:04 PM To: Yves Bailly; interest@qt-project.org Subject: RE: Windows, OpenGL and Qt5.5.0 -Original Message- From: interest-bounces+kai.koehne=theqtcompany@qt-project.org [mailto:interest-bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of Yves Bailly Sent: Thursday, July 16, 2015 4:53 PM To: interest@qt-project.org Subject: [Interest] Windows, OpenGL and Qt5.5.0 Hello all, I just downloaded Qt 5.5.0 for Windows (Win7, 64bits, Visual C++ 2013) and started rebuilding a large project, which is running just fine with Qt 5.4.1. Now I get many OpenGL-related link errors, such as: error LNK2019: unresolved external symbol __imp_glDisable referenced in function Is there some config needed in the .pro file? I read somewhere that now desktop OpenGL is dynamically loaded using some kind of config file... After having spend 45min digging in the documentation, I can't find anything related to those issues... I guess you already bumped into http://doc.qt.io/qt-5/windows-requirements.html#dynamically-loading- graphics-drivers This blog post is also an excellent introduction: https://blog.qt.io/blog/2014/11/27/qt-weekly-21-dynamic-opengl- implementation-loading-in-qt-5-4/ Regards Kai ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QOpenGLWidget and text
-Original Message- Sent: Wednesday, April 01, 2015 3:42 PM To: interest@qt-project.org Subject: [Interest] QOpenGLWidget and text I've been working on porting a Qt4 GL application to Qt5, using the new QOpenGL classes instead of the old and deprecated QGL classes. Some of it was really easy. Some of it is requiring MASSIVE amounts of work. I refer specifically to the removal of the text rendering methods. Since these are removed, what is the easiest way to go about drawing non-scaled, billboarded text in a GL scene? (Note: I am on Qt 5.4 at present; no Qt3D.) You can use a QPainter to draw on a QOpenGLWidget. You can even create a QLabel having the QOpenGLWidget as parent. This is if you need to draw the text over the 3D scene. Hope this helps. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] question about relocating Qt library installation
On 05/08/2014 05:59, Thiago Macieira wrote: On Monday 04 August 2014 09:47:55 Darren Dale wrote: I spent a good part of the weekend looking for information on the web. I'm not certain I understand the problem, but am certain there must be a solution, since the Qt installer for windows can install to an arbitrary location. It does that by binary-patching QtCore and qmake. Does your installation do that? I found a short discussion at http://stackoverflow.com/a/17640221 , talking about how qmake, Qt5Core, and a few other files need to be patched, but did not understand exactly what needs to be patched, and how. (Please excuse me for not understanding the c++ code that was posted.) Is there any documentation on how to do this? Looks like you didn't. Run strings on those files and you'll see the build paths. You need to replace those paths in the binaries and remove the qt.conf file. Or you may use this, which is pretty handy and easy to use: http://tver-soft.org/programs/qtbinpatcher Hope this helps. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] OpenGL weirdness
On 24/07/2014 20:33, Till Oliver Knoll wrote: Am 24.07.2014 um 14:13 schrieb Yves Bailly yves.bai...@verosoftware.com: [...] fmt.setVersion(2, 1); ...getGetString(GL_VERSION) gives 4.4.0 (unexpected), and no triangle displayed. As already mentioned in a previous reply: maybe a bit unexpected, but totally fine, because you get a Compatibility profile. With simply requesting the profile, without giving a version: Doesn't make sense really: profiles are only introduced on OpenGL 3.2 and above :) Any idea about what's going on? I strongly assume that you're not using any fixed pipeline functions such as glVertex etc. ;) so my best bet would be your shader code: did you copy/paste from some older OpenGL (ES) 2 shaders? Thanks all for your answers, finally I found where the problem was. In short, here's what happened. This was a piece of code which used to work fine with Qt 5.2.1, a few months ago. Indeed no fixed pipeline, good #version 330 shaders, and so on. Yesterday I just rebuild it but using Qt 5.3.1, to see it was no more working. Why? In the meantime, two things had change: the Qt version, *and* I got a new workstation, with a new GPU, a new OS, a new driver. And this is where the problem lies. In my code, I was *not* using any VAO. It seems the old driver was always giving me a compatibility profile - hence no need for VAOs. But the new drivers gives me a real core profile, in which VAOs are mandatory. No VAO, no display... :-) Just adding the needed VAOs made the things work again. Thanks all for your help. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] OpenGL weirdness
Greetings all, I'm trying to build a very basic OpenGL program, just displaying a red triangle. Context: - Windows 7 64bits - Qt 5.3.1 (tested with the official MinGW build and a Visual 2012 build) - I will need OpenGL 3.3 core and have to use GLEW - using QGLWidget, overriding the usual initializeGL() and paintGL() When I'm creating my widget like this: QGLFormat fmt( QGL::DoubleBuffer bitor // enables double-buffering QGL::DepthBuffer bitor// enables support for depth buffer QGL::AlphaChannel bitor // enables support for alpha-blending QGL::StencilBuffer bitor // enables support for stencil buffer QGL::DirectRendering // enables direct rendering to display ); fmt.setStencilBufferSize(8); QGLFormat::setDefaultFormat(fmt); Gl_Widget glw; glw.show(); ...then it works fine, I see my triangle. glGetString(GL_VERSION) gives 4.4.0. But if I add an explicit request for the GL version: fmt.setVersion(4, 4); fmt.setProfile(QGLFormat::CoreProfile); ...then I no longer see my triangle, however glGetString(GL_VERSION) still gives 4.4.0. If I try using some other version: fmt.setVersion(3, 3); fmt.setProfile(QGLFormat::CoreProfile); ...getGetString(GL_VERSION) gives 3.3.0 (as expected), but no triangle displayed. With: fmt.setVersion(2, 1); ...getGetString(GL_VERSION) gives 4.4.0 (unexpected), and no triangle displayed. With simply requesting the profile, without giving a version: fmt.setProfile(QGLFormat::CoreProfile); ...getGetString(GL_VERSION) gives 4.4.0 and my triangle is displayed. Any idea about what's going on? The same thing occures on both MinGW (32bits) and Visual C++ 2012 (64bits). I'm investigating this thing because a program that used to work well with Qt 5.2.1 no longer works with Qt 5.3.1. Any hint highly welcome. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Is a pre-built mingw-w64 Qt available?
On 18/06/2014 14:49, K. Frank wrote: Hello List! Is Qt (preferably the latest version) available pre-built with mingw-w64? I would hope for at least gcc 4.8, but preferably gcc 4.9. http://tver-soft.org/qt64 scroll down for MinGW builds. No 4.9 for now it seems though. Regards, -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Low-level font identifier
Greetings all, Having to reuse some piece of very old code, I need to get the low-level handle on a font - specifically the HFONT, as we're running on Windows. In the Qt3 days, there was a method QFont::handle() which was providing this information, but it seems it's gone in Qt5. Having a QFont, is there any easy way to get the corresponding HFONT? Thanks for any hint. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Using OpenGL with Qt
Greetings all,
I would like to raise again a question which has already been discussed
a bit, without finding a satisfactory answer (for me at least).
It's about using OpenGL, more precisely getting access to OpenGL functions.
Is it possible to use Glew with Qt 5.2? I mean, is it possible to use Glew,
QGLWidget, QOpenGLShader, etc. in the same piece of code?
I know there are the QOpenGLFunctions_* classes, but they're too cumbersome
to use for any heavy work. They somehow require to have a kind of global
instance, e.g.
QOpenGLFunctions_3_3_Core* gl =
QOpenGLContext::current()-versionFunctions...();
...which then leads to code like
gl-glSomething();
gl-glDoThis();
gl-glDoThat();
...
That gl-gl prefix is just odd and makes it almost impossible to reuse
existing, older (Glew-based) code. Just try to copy-paste some GL example
from the web, or copy-paste this gl-gl code to some other program not
using Qt. In a even slightly mixed environment, it's really a pain.
And subclassing from QOpenGLFUnctions_* is not an option when you may have
thousands of instances: it's way to much memory and time for each to
resolve its functions.
Note subclassing *can* be an option, if only there was some kind of smart
constructor which would share internals, pretty much like it's done so well
since so long in QString, QImage, containers... Something like this:
class QOpenGLFunctions_3_3_Core
{
public:
QOpenGLFunctions_3_3_Core(QOpenGLFunctions_3_3_Core* shared_internals)
/* ... */
};
Than it can be used easily:
class My_Class: public My_Parent, protected QOpenGLFunctions_3_3_Core
{
public:
My_Class(Some_Data data):
My_Parent(data),
QOpenGLFunctions_3_3_Core(
QOpenGLContext::current()
-versionFunctionsQOpenGLFunctions_3_3_Core())
{ }
};
Then from inside My_Class, no more need for any kind of gl- prefix and
everyone is happy :-)
Or maybe I missed something? For now our only alternative is to use Glew,
can you confirm it works well alongside Qt?
Regards,
--
/- Yves Bailly - Software developer -\
\- Sescoi RD - http://www.sescoi.fr -/
The possible is done. The impossible is being done. For miracles,
thanks to allow a little delay.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Using OpenGL with Qt
Le 17/03/2014 09:28, Agocs Laszlo a écrit : Some notes about QOpenGLFunctions: One QOpenGLFunctions belongs to one QOpenGLContext. Creating additional instances of QOpenGLFunctions for the same context will automatically share the internals behind the scenes so it's way too much memory and time for each to resolve is functions should not be the case. Also, functions that are never called are never resolved. This is great :-) So I guess the internals are also shared between shared contexts? And does this mean the QOpenGLFunctions_* default constructor will do the right thing, assuming there's a current context? If that's the case, then subclassing is no longer an issue. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Using OpenGL with Qt
Le 17/03/2014 10:05, Agocs Laszlo a écrit :
I must correct my previous statement about not resolving functions that are
not called. This deferred behavior is only true for QOpenGLFunctions. The
versioned variants will resolve all functions for the given version already
when initializeOpenGLFunctions() is first called with a given context.
Here's what I tried.
First I define a default GL format:
QGLFormat fmt;
fmt.setVersion(3, 3);
fmt.setProfile(QGLFormat::CoreProfile);
fmt.setStencilBufferSize(8);
QGLFormat::setDefaultFormat(fmt);
Now let's say I have two classes:
class Gl_Model: protected QOpenGLFunctions_3_3_Core
{
public:
Gl_Model();
void create();
void draw();
private:
GLuint buff_ids[3];
}; // class Gl_Model
class Gl_Widget:
public QGLWidget,
protected QOpenGLFunctions_3_3_Core
{
Q_OBJECT
public:
explicit Gl_Widget(QWidget* const parent = nullptr);
protected:
virtual void initializeGL() override;
virtual void paintGL() override;
virtual void resizeGL(int width, int height) override;
private:
Gl_Model* model{nullptr};
}; // class Gl_Widget
inside Gl_Model::create():
void Gl_Model::create()
{
this-initializeOpenGLFunctions();
/* ... */
}
inside Gl_Widget::initializeGL():
{
QOpenGLContext* ctx = QOpenGLContext::currentContext();
ctx-versionFunctionsQOpenGLFunctions_3_3_Core();
this-initializeOpenGLFunctions();
this-model = new Gl_Model;
this-model-create();
}
Now if I follow the program step-by-step, indeed the second call to
initializeOpenGLFunctions (inside Gl_Model::create) it will reuse some
already allocated data... but it will perform 12 searchs in a QHash.
If I have to create, say, 10 instances of Gl_Model, that will
imply 120 searchs. I know QHash is quite fast, but that seems
a bit overkill to me...
Or am I missing something again?
--
/- Yves Bailly - Software developer -\
\- Sescoi RD - http://www.sescoi.fr -/
The possible is done. The impossible is being done. For miracles,
thanks to allow a little delay.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Using OpenGL with Qt
Le 17/03/2014 12:59, Agocs Laszlo a écrit : No, that is expected. After all it has to look up the versionFunction internals from the hash table maintained by the context. With the design shown here, deriving GL_Model from QOpenGLFunctions* feels like an overkill indeed. The options I see are: 1. Do not derive, just get an QOpenGLFunctions* instance. This of course leads to the f-glBlah() type of code which some (myself not included) may find ugly. As you say, some find it ugly ;-) myself included, but I'm not the only one. 2. Use a different design. Separating the GL initialization/rendering into a separate class (e.g. GL_ModelRenderer) with a single instance could avoid the issue altogether. This would probably be the best approach. However this is not a new project, we're dealing with a huge (and old) code base, such a refactoring is not (yet) an option. So I'm back to my initial question: can Glew be used nicely with Qt? Seems so in my quick test program (even using QOpenGLShaderProgram), but I'm wondering in larger contexts. Thanks anyway for your inputs Laszlo :-) -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Using OpenGL with Qt
Le 17/03/2014 16:03, Sean Harmer a écrit : On Monday 17 March 2014 13:42:04 Yves Bailly wrote: Le 17/03/2014 12:59, Agocs Laszlo a écrit : So I'm back to my initial question: can Glew be used nicely with Qt? Seems so in my quick test program (even using QOpenGLShaderProgram), but I'm wondering in larger contexts. Thanks anyway for your inputs Laszlo :-) I would also suggest refactoring to separate out the data you're rendering (the 10,000 instances) and how you render it (the function pointers). As I said, that would be the way to go... but this kind of refactoring is not yet an option for us, the needed work is just too huge for now. In fact if you're looking at rendering 10k instances of something you probably want to be looking at glDrawElementsInstanced() or maybe even glMultiDrawIndirect() type functions. That was 100k ;-) and each is a different piece of mesh, so no instances. Its 100k instances of a *class*, not 100k instances of a *model* - each class instance containing its own model. Now to be honest, that 100k number is quite extreme, the usual common case is around 5k-10k nowadays (but increasing with time). We're perfectly aware of the need of a vast refactoring, but again this will not happen before at least a year - other huge refactorings are to be made before taking care of the rendering. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Weird error using Visual C++ 2013
Le 04/03/2014 17:57, Thiago Macieira a écrit : Em ter 04 mar 2014, às 15:04:13, Yves Bailly escreveu: When trying GCC, either on Linux or using MinGW, it works fine. Any hint about what may happen? is it a compiler bug, or something else? Any idea about a workaround? Please valgrind your code. A heisenbug like this is probably memory smashing or a dangling pointer dereferencing. Obviously it's a memory problem :-) And alas, valgrind doesn't work on Windows... I'll try to get some Windows tool. FYI, trying on Linux with valgrind, it doesn't complain at all. What I'm trying to understand is *why* it occures *only* when using Visual 2013 and using a QString... if I replace all QString by std::string, it works just fine. It even works fine if I add a char const*-based constructor to my S class, thus bypassing the implicit QString's conversion. For what I can see, it seems there's some troubles between QString and Visual 2013 initializer-lists implementattion. Keeping searching... -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Weird error using Visual C++ 2013
Le 05/03/2014 13:24, Krzysztof Kawa a écrit : 2014-03-05 8:59 GMT+01:00 Yves Bailly yves.bai...@sescoi.fr mailto:yves.bai...@sescoi.fr: For what I can see, it seems there's some troubles between QString and Visual 2013 initializer-lists implementattion. Keeping searching... This is a bug in VS2013 initializer_list that basically makes initializer_list useless for anything but simple types. That's whay I was suspecting... and it seems a known bug: http://blogs.msdn.com/b/bharry/archive/2014/01/20/vs-2013-1-update-1-is-available.aspx#10491639 Thanks anyway. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.2.1 for Windows 32-bit (VS 2012, OpenGL) version?
Le 26/02/2014 13:14, Thomas Meyer a écrit : Hi, I can't find a Qt 5.2.1 for Windows 32-bit (VS 2012, OpenGL) version on http://qt-project.org/downloads. Is it true and will it be there sometime? Check http://tver-soft.org/qt64 (the Qt 5.2 x86 tab) Hope this helps. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt5/Android examples on the Play store?
Le 02/01/2014 22:14, Jason H a écrit : The list doubled from yesterday to today! - *From:* Jonathan Greig redteam...@gmail.com *To:* Дмитрий Козлов gni...@mail.ru *Cc:* Interests Qt interest@qt-project.org *Sent:* Tuesday, December 31, 2013 3:29 AM *Subject:* Re: [Interest] Qt5/Android examples on the Play store? Here is the search list of android apps that use Qt5: https://play.google.com/store/search?q=Qt5c=apps But it's still missing a few, such as https://play.google.com/store/apps/details?id=org.ybailly.qtoverflow or https://play.google.com/store/apps/details?id=org.kde.necessitas.example.kanaroma (ok this one is Qt4 using the old and great Necessitas, but well) -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Compile Speed Question regarding MOC
Le 19/02/2014 09:21, Till Oliver Knoll a écrit : - Use the private *d idiom (there is a name for it which I don't recall at the moment) The pimpl (pointer to implementation) idiom, or Cheshire cat. http://en.wikipedia.org/wiki/Pimpl see also http://herbsutter.com/2013/12/31/gotw-7b-solution-minimizing-compile-time-dependencies-part-2/ :-) -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QLabel and QScrollArea
Le 18/02/2014 12:57, igor.mironc...@gmail.com a écrit : Hi. I’ve looked at QLabel code and concluded that QLabel doesn’t support shrinking less than 80 characters long. Fix me if I’m wrong. Try to include your text in qtyour text here/qt tags, QLabel should then shrink and cut the lines when needed. Alternatively try QLabel::setWordWrap(true). Hope this helps. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5 release PDBs for MSVC2012
Le 27/01/2014 13:27, Philipp Kursawe a écrit : The source informations can be fixed during runtime. VS asks to locate the source files (which we do have installed). So it would be very, very helpful to have them available *without* forcing us to build Qt ourselfs (which could introduce bugs because of different compilers/linkers used than in the official distribution). I would also be really interested in having those files. Maybe as a separate archive, as they can get quite huge? -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtThread
Le 21/01/2014 18:48, Constantin Makshin a écrit : There's no real need to use debug version of Qt if you don't want to debug Qt itself, so in most cases the programmer won't see that warning. Sorry, but I strongly disagree with that... sometimes when facing a bug or some strange, hard-to-track behaviour, it's quite handy to follow the path of the data *inside* Qt itself. It's not debugging Qt, it's just trying to figure out why something is not used or interpreted as (maybe naively) expected. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Usage of QAbstractOpenGLFunctions and derived classes
Greetings all,
Using the just released Qt 5.2.0 with QtCreator 3.0, compiler Visual C++ 2012
64bits on Windows 7 64bits.
I'm trying to use the QtGui/QOpenGLFunctions_3_3_Core class to get access to
OpenGL 3.3 Core functions (desktop obviously), by subclassing QGLWidget like
this:
class Gl_Widget: public QGLWidget, protected QOpenGLFunctions_3_3_Core
{
virtual void initializeGL() override;
/*...*/
};
The first lines of initializeGL() are:
void Gl_Widget::initializeGL()
{
if ( not this-isInitialized() )
this-initializeOpenGLFunctions();
/*...*/
}
A few questions now.
(1)
When I try to build this program, I get a link error:
gl_widget.obj : error LNK2019: symbole externe non résolu protected: bool
__cdecl
QAbstractOpenGLFunctions::isInitialized(void)const
(?isInitialized@QAbstractOpenGLFunctions@@IEBA_NXZ) référencé dans la fonction
protected: virtual
void __cdecl Gl_Widget::initializeGL(void) (?initializeGL@Gl_Widget@@MEAAXXZ)
...which basically says the external symbol
QAbstractOpenGLFunctions::isInitialized() could not be
resolved.
If I remove the if line, thus not calling isInitialized(), everything works
fine. I even tried to force
name resolution with if (not
this-QOpenGLFunctions_3_3_Core::isInitialized()), but no luck.
Any idea about what can go wrong?
(2)
For what I see, the QOpenGLFunctions_* classes are storing a bunch of function
pointers, which are
dynamically resolved at runtime. If I want to use those functions, I can either:
- ask a pointer from the context by QOpenGLContext::versionFunctions(), which
makes then a code looking
like:
gl_funcs-glGenBuffer(...);
gl_funcs-glBindBuffer(...);
gl_funcs-glDrawElements(...);
...where the gl_funcs- prefix is quite cumbersome, to say the least.
- or subclass from QOpenGLFunctions_* when needed for a more direct access to
the function. But in
this case, what if I need access to OpenGL functions in hundreds or
thousands of instances?
resolving and storing function pointers in each of them would be overkill.
To alleviate those points, I tried something like this (with various variations
and more sanity checks):
class My_Class: public Some_Other_Super, protected QOpenGLFunctions_3_3_Core
{
void some_init_method()
{
QOpenGLContext* ctx = QOpenGLContext::currentContext();
QOpenGLFunctions_3_3_Core* funcs =
ctx-versionFunctionsQOpenGLFunctions_3_3_Core();
dynamic_castQOpenGLFunctions_3_3_Core(*this) = *funcs;
}
}
...in the hope to be able to reuse already resolved function pointers, hoping
QOpenGLFunctions_*
classes are using implicit sharing or something like that... but of course it
doesn't work, I
get crashes when destroying instances, double-deletes, and so on.
I tried to fallback to Glew, but for whatever reason it refuses to resolve e.g.
glCopyBufferSubData(),
whereas it's resolved fine by QOpenGLFunctions_3_3_Core...
I searched the doc, but couldn't find any hint on the right way to easily use
those QOpenGLFunctions_*
classes in non-trivial cases. Has others had more ideas?
Thanks in advance.
--
/- Yves Bailly - Software developer -\
\- Sescoi RD - http://www.sescoi.fr -/
The possible is done. The impossible is being done. For miracles,
thanks to allow a little delay.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Usage of QAbstractOpenGLFunctions and derived classes
Le 17/12/2013 10:21, Thiago Macieira a écrit : On terça-feira, 17 de dezembro de 2013 09:49:48, Yves Bailly wrote: (1) When I try to build this program, I get a link error: gl_widget.obj : error LNK2019: symbole externe non résolu protected: bool __cdecl QAbstractOpenGLFunctions::isInitialized(void)const (?isInitialized@QAbstractOpenGLFunctions@@IEBA_NXZ) référencé dans la fonction protected: virtual void __cdecl Gl_Widget::initializeGL(void) (?initializeGL@Gl_Widget@@MEAAXXZ) Yes: you're calling a function that is not public. Stop calling isInitialized(). It is protected, so public for any derived class... if it's not intended to be used at all, then maybe it might be better to remove it entirely? -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Usage of QAbstractOpenGLFunctions and derived classes
Le 17/12/2013 11:53, Sean Harmer a écrit : If you're planning on using the functions object in more than one class you may be better off obtaining a pointer to it from the QOpenGLContext::versionFunctionsQOpenGLFunctions_3_3_Core() function rather than sub-classing. The object is owned by the context and is shared which is less overhead than having multiple classes of your own all of which subclass. Then I'm back to my first point: I have a pointer, let's give it a short name like gl, then the code looks like: gl-glGenBuffer(...); gl-glBindBuffer(...); gl-glDrawElements(...); Again that repetitive prefix (gl- here) looks a bit odd and is quite cumbersome... that's why I why looking for a way to get rid of it by subclassing. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Usage of QAbstractOpenGLFunctions and derived classes
Le 17/12/2013 17:58, Thiago Macieira a écrit : On terça-feira, 17 de dezembro de 2013 11:56:58, Yves Bailly wrote: It is protected, so public for any derived class... if it's not intended to be used at all, then maybe it might be better to remove it entirely? It's used by derived classes. These classes: I know this. But it's visible in the public API as any protected method, it even appears in the doc (https://qt-project.org/doc/qt-5/qabstractopenglfunctions.html#isInitialized), which is where I saw it the first time. So if it should not be used by users, at least it should be hidden in the doc or with a notice added such as for internal use only, don't use. However this discussion about this method doesn't answer at all about the overall usability of those QOpenGLFunctions_* classes. To be clear, I really like the idea - indeed having a compile error when trying to use a deprecated function is way better than random runtime crashes. But having to move around everywhere some kind of pointer and call all the OpenGL functions by prefixing them with my_pointer_on_gl_funcs- is a real burden. This could be solved just by making QOpenGLFunctions_* classes more like implicitly-shared classes (QImage, QString, QVector, etc.) : then one could subclass from it and initialize function pointers by copy-constructor or operator=. Internally only a shared pointer would be copied, functions resolving done only once, and no more annoying prefix to call functions. Don't you think it would make them more pleasant to use? at least in the context of a heavy OpenGL, (tens of) thousands of OpenGL calls involved. Regards, -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] VS2013
Le 13/12/2013 08:50, Michael Sué a écrit : I think support for VS 2010 should be held up as long as WINDOWS XP is officially supported (April 2014). The newer VS versions do not support native development on WINDOWS XP but this will stop to be an issue as soon as the platform does no longer exist. In that case, maybe the ANGLE version could be dropped, as it doesn't work on WinXP according to http://qt-project.org/wiki/Qt-5-on-Windows-ANGLE-and-OpenGL ? -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt and MSVC 2013
Le 27/11/2013 09:17, Philippe a écrit : Would be nice, but without the Visual Studio Addin (I haven't seen yet any VS 2013 beta version), this will not be usable for many. Perfectly usable if you're using only the compiler and QtCreator as IDE :-) -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Semi-OT: Was Nokia net good or bad for Qt?
Le 27/09/2013 20:20, Thiago Macieira a écrit : On sexta-feira, 27 de setembro de 2013 13:44:23, Uwe Rathmann wrote: On Thu, 26 Sep 2013 14:13:33 -0400, K. Frank wrote: [...] The existence of 2 different systems is a problem of itself. The development is working on the QML side, while the majority of the user base is doing widgets. For me as an author of a 3rd party lib it means I have to deal with 2 different platforms. The opposite of code once ... what used to be the mantra of Qt in the TrollTech days. Because the industry has changed. There's no way the C++ widgets as they have been designed will work on the new platforms. I don't understand here: currently widgets *do work* on at least some of the new platforms, I have some real working apps running on Android phones... In some cases (many for me), widgets are just the easiest way to go, when parts of the display is not static and needs to be created on-the-fly at runtime. Sure some tweakings are needed here and there, because a mobile is not a desktop. But widgets are working fine :-) despite some shortcomings, mostly related to the styles and stylesheets management in my case, which are also valid on the desktop anyway. Regards, -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QGLWidget and OGL version 4.3 functions?
Le 29/09/2013 11:21, Sean Harmer a écrit : Hi, On 27/09/2013 07:35, Thomas Meyer wrote: Hi, is it possible to render in a QGLWidget with the OGL 4.3 functions? Yes but it is now recommended to use QWindow + QOpenGLContext for new code as QGLWidget will not see any further development. Will it be replaced by something just as convenient? QWindow is just not as easy to use, moreover embedding it in the middle of a GUI full of controls (in a QMdiSubWindow for example). QWidget::createWindowContainer() is pretty unnatural. Regards, -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QGLWidget and QGraphicsView
Greetings all, Using Qt 5.0.2 on Windows 7 (Visual C++ 2010), I'm trying to use a QGLWidget-based class as viewport for a QGraphicsView, using the setViewport() method. However it seems the paintGL() method is never called. The code look like this, where Gl_Widget inherits from QGLWidget: QGraphicsView* view = new QGraphicsView(this); Gl_Widget* gl_widget = new Gl_Widget(nullptr); view-setViewport(gl_widget); ...but nothing is drawn... I've tried setViewportUpdateMode(FullViewportUpdate), no more result. The only way I found to get something drawn is to trigger a timer inside the Gl_Widget which would call updateGL() periodically, which is far from optimal... Any hint appreciated. Regards, -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Desktop deployment
Le 20/06/2013 01:16, Alex Malyushytskyy a écrit : I just wanted to point that you must to deploy all dependencies not only Qt. You will have to deploy VC CRTs at least if your application has no other dependencies. I'm perfectly aware of this. Here my problem is more in the case where I just want to copy my exe to someone's else computer (which already have already all the needed standard runtimes installed). Creating a full-fledged, customer-targeted installer is another matter, which is already nicely handled. Regards, -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Q_PROPERTY notification across processes?
Le 17/05/2013 03:27, Charley Bay a écrit : I have a C++ QObject-derived class that exposes properties for use in QML, works fine (Qt5). WHAT I WANT: I would like to instantiate an instance of this class in each of two processes, where changes in one notifies the other (in the other process). This is logically something like local-instance-reflection to a remote instance in a remote process. [...] A concern I have is that there will be *many* of these pairs (thousands, possibly tens-of-thousands), and I don't know if the approach would scale-well for lots of notifications. I found this project recently: http://www.zeromq.org/ Maybe it could be useful for what you're looking to achieve. I've not yet tried it though. Hope this helps. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QTabWidget Vertical writing
Le 16/05/2013 11:47, Sujan Dasmahapatra a écrit : I want to have the QTabWidget vertically...Mean they should vertical and Tab1 Tab2 text should also be vertical. How can we achieve this. Any help is highly appreciated. Thanks Have a look at QTabWidget::TabPosition and QTabWidget::setTabPosition. Hope this helps. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.1 Beta Released
Le 14/05/2013 15:10, Sergio Ahumada a écrit : Qt 5.1 Beta has been released ! Please check https://blog.qt.digia.com/blog/2013/05/14/qt-5-1-beta-released/ for more information. Congratulations and a great thanks to all those who made this possible :-) Just a little question, about Android support. Are there somewhere some guidelines on how to setup Qt and the needed environment to create applications for Android? More specifically, I'm really interested in creating static applications, which can be deployed as a single program, without requiring the extra install of Ministro. I searched the doc, but couldn't find any information, about installing the right Android SDK/NDK, about configuring Qt for a static build, and so on... Or did I miss the relevent howto ? Again, thanks all for this wonderful release. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.0.2 speed and widgets
Le 14/04/2013 19:55, Philippe a écrit : Compared to Qt 4.8.x, I experiment a very sensible reduction of speed in 5.0.2 when widgets are created or complex windows activated. In Release mode this is sort of acceptable,... maybe half speed. But in debug mode, this is dramatically slower, up to 6x slower than in 4.8.3. Just to have something to compare, here's a mini-benchmark I did using an application I'm working on. Not a trivial one, about 80K SLOC in two libs and an executable. What is benchmarked is the time needed to get a usable GUI displayed. First the application loads a bunch of data from a remote PostgreSQL server. Almost purely internal operations, nothing more than a progress bar. Then the GUI is build on-the-fly according to what is stored in the database, almost no *.ui file involved. This produce around 20 dynamic forms, each showing between 10 and 30 user controls (buttons, line edits, trees). A moderately large CSS is used, and no QML nor QtScript at all. All tests done on the same machine/system, Windows 7 64bits 4-cores Xeon, using the compilers from Microsoft Visual 2010. The Qt5 used is the one downloaded from qt-project.org, the Qt4 (both 32bits and 64bits) compiled by me from sources. Results from the third start, to avoid cache effects. Debug mode == +---+---+---+ | Data loading | GUI building | Cumul | +---+---+---+ Qt 5.0.2 32bits | 5.0s / 36MB | 11.0s / 99MB | 16.0s / 135MB | +---+---+---+ Qt 4.8.4 32bits | 3.5s / 34MB | 8.0s / 94MB | 11.5s / 128MB | +---+---+---+ Qt 4.8.4 64bits | 3.3s / 51MB | 8.2s / 131MB | 11.5s / 182MB | +---+---+---+ Release mode +---+---+---+ | Data loading | GUI building | Cumul | +---+---+---+ Qt 5.0.2 32bits | 1.1s / 17MB | 1.9s / 63MB | 3.0s / 80MB | +---+---+---+ Qt 4.8.4 32bits | 0.9s / 17MB | 1.5s / 59MB | 2.4s / 76MB | +---+---+---+ Qt 4.8.4 64bits | 0.8s / 25MB | 1.5s / 80MB | 2.3s / 105MB | +---+---+---+ As usual, those results are to be taken with caution... however, it seems fair to say Qt5 is slower than Qt4: +40% in debug mode, +25% in release mode. While I don't mind much about debug mode (it's just annoying for developpers), a 25% slowdown even in release mode is more of a concern. For what it worths... -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] can qt.conf be put in a common location?
Le 29/01/2013 06:34, Thiago Macieira a écrit : On segunda-feira, 28 de janeiro de 2013 19.44.18, VStevenP wrote: Is it possible to specify a shared location for qt.conf using an environment variable? It's being a bit of a pain to put a qt.conf file in the app dir for every Qt example installed on my target system. If I could specify a location where the file could be found, I wouldn't have to create a qt.conf for every Qt example I want to run on the target. Why do you need a qt.conf in the first place? qt.conf is supposed to be used for an application that can be installed to an arbitrary location. Which is the case for roughly 99% of Windows apps for example... This old Qt doesn't know about SDK vs deployment location, as said Lincoln, is a real pain on Windows. No way qt.conf can be optional on Windows, unless you have a total control over the client's system - which is the case for roughly 1% of customers... The build twice advice simply doesn't work. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
Le 17/01/2013 15:31, Jason H a écrit : You all are doing it wrong!!! I've been researching this a week or so. Emcripten is not going to work. You do not want your binary transalted to JS. The demos are slow, and regardless of optimization will always be slow. 4MB of compressed javascript for a program? Not with the bandwidth we have. And nevermind textures! If you want to make Qt5 web-able, what you need is a way to directly translate the OpenGL calls of Qt5's QML to WebGL. The barrier there is not hard however I am out of my element. I am not a GL person, though I have a basic understanding. What is needed is a http server, your binary and a translation layer to WebGL. The translation layer would make whatever textures needed available. These should be cached on the client in HTML5 storage. Then it is only a small amount of commands that are easily executed that create each frame. What you describe seems close to Wt: http://www.webtoolkit.eu/wt However the use of emscripten is not so wrong: it can come as a very handy, short-term and quickly-done solution. And there is probably still much room for optimizations, making it even less slow. By the way, slow is a relative idea: clicking a button triggers an action in 1ms on a desktop, 10ms through Emscripten: no big deal, from a user's view it's almost the same even though it's 10 times slower. About bandwidth, for me (at home) 4MB is only 3-4 seconds away, so no big deal, and such bandwidth is more and more common. Granted, it's far from ideal-perfect, but all wrong is a bit over. -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] WebKit 1 or 2 ?
Hello all, Two versions of WebKit are provided with Qt5, WebKit 1 and WebKit 2. Wehn building Qt5 from the ZIP archive, it seems by default it's the WebKit 1 which is build. Is there a way to build WebKit 2 instead? I can't find any related option in configure.exe --help nor anywhere... Regards, -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Non-movable Qt build
Le 26/12/2012 17:05, Bob Hood a écrit : On 12/26/2012 8:14 AM, Yves Bailly wrote: Is there a way to tell qmake to use something else than those hard-coded paths? http://doc.qt.digia.com/qt/qt-conf.html Has already stated, this doesn't work - as if qmake was not reading at all this file. -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Non-movable Qt build
Le 26/12/2012 21:28, Thiago Macieira a écrit : On quarta-feira, 26 de dezembro de 2012 14.58.03, K. Frank wrote: As I understand it, it is not practical to move a Qt installation away from where it is built. [...] But, as I understand it, this battle has been fought already in the past, and, unfortunately, lost. *sigh* Note that there's a difference between running Qt-based applications (and that's what qt.conf is for) and the building of applications against a particular Qt build. The former is relocatable by way of the config file. The latter is a different thing. It definitely isn't for Qt 5. My problem is precisely to build an application against a Qt build that has been moved. Just for the record, after changing hard-coded paths in the qt_*.pri files, I managed to compile QtCreator 2.6.1 against my relocated Qt build. An additional qt.conf is needed in QtCreator's bin directory, but it starts. So, *if* it's enough to change the paths in the qt_*.pri files, it seems we're not far from a relocatable Qt... just use relative paths in those files instead of absolute ones, or use some variable like good'old QTDIR. Yes, I know this just may well not be that simple. Working in a team, until now I'm *THE* one building Qt from sources, then everyone else just pick the binaries I provide in a kind of package. So being able to move Qt around is quite important to us, having everyone spending 4 hours rebuilding the same thing over and over is overkill. The lost battles are the most delightful to restart... ;-) Regards, -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Trouble with release build on Win7
Le 21/12/2012 09:10, Koehne Kai a écrit : I'm building Qt5 for 64bits using Visual 2010 on a Windows 7 64bits host, debug and release. However it seems anything using Qt5Gui.dll fails to start. Now things get weird... I build a 32bits version of Qt5, Visual 2010 Pro SP1, on a Windows 7 64bits host. The example qtbase/exampels/gui/analogclock starts both in release and debug flavor, bug it doesn't show the usual clock... just a grey rectangle with written QWindow in the middle. Same with the rasterwindow example. I can confirm this. Can you create a bug report for it? I will try... ;-) https://bugreports.qt-project.org/browse/QTBUG-28778 However, I couldn't reproduce your 64 bit issues. I've been building with 16.00.40219.01 for x64 , configure was configure -prefix %CD%\qtbase -opensource -confirm-license -nomake tests. The examples show exactly the same behavior as on 32 bit. I have exactly the same compiler version, so maybe the difference is in the configure command. - I used the -mp switch, will try without it. - Maybe the -ltcg is the source of the problem, will try without it. Side question: where's the HTML doc? it used to be provided ready-to-use in Qt4 releases... If you've I installed the binary packages you should find the .html files under docs. Open e.g. 5.0.0/%compiler%/doc/qtdoc/index.html . If you're building yourself, run 'make docs'. From the 64bits build, after a while it says: D:\libsrc\qt-5.0.0-x64\qtbase\bin\qhelpgenerator.exe D:/libsrc/qt-5.0.0-x64/qtbase/doc/qtcore/qtcore.qhp -o D:/libsrc/qt-5.0.0-x64/qtbase/doc/qtcore.qch NMAKE : fatal error U1077: 'D:\libsrc\qt-5.0.0-x64\qtbase\bin\qhelpgenerator.exe' : return code '0xc01d' From the 32bits build, it fails because I removed all the previously generated *.obj files... Well, let's continue the adventure ;-) -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Trouble with release build on Win7
Hello again, Le 21/12/2012 09:44, Yves Bailly a écrit : Le 21/12/2012 09:10, Koehne Kai a écrit : I'm building Qt5 for 64bits using Visual 2010 on a Windows 7 64bits host, debug and release. However it seems anything using Qt5Gui.dll fails to start. Now things get weird... I build a 32bits version of Qt5, Visual 2010 Pro SP1, on a Windows 7 64bits host. The example qtbase/exampels/gui/analogclock starts both in release and debug flavor, bug it doesn't show the usual clock... just a grey rectangle with written QWindow in the middle. Same with the rasterwindow example. I can confirm this. Can you create a bug report for it? I will try... ;-) https://bugreports.qt-project.org/browse/QTBUG-28778 However, I couldn't reproduce your 64 bit issues. I've been building with 16.00.40219.01 for x64 , configure was configure -prefix %CD%\qtbase -opensource -confirm-license -nomake tests. The examples show exactly the same behavior as on 32 bit. I have exactly the same compiler version, so maybe the difference is in the configure command. - I used the -mp switch, will try without it. - Maybe the -ltcg is the source of the problem, will try without it. The build is still ongoing (WebKit is really a big beast!), however I could start some basic GUI examples, compiled as release with Visual C++ 2010 Pro SP1 for x64. The analogclock bug talked about earlier (https://bugreports.qt-project.org/browse/QTBUG-28778) is also present, but at least the examples starts, whereas they were not even showing anything in my previous build. The configure is: -confirm-license -opensource -release -c++11 -shared -accessibility -qt-sql-sqlite -plugin-sql-psql -opengl desktop -qt-zlib -qt-pcre -icu -qt-libpng -qt-libjpeg -qt-freetype -no-angle -no-incredibuild-xge -openssl -no-qml-debug -nomake tests -nomake examples -nomake demos ...and some -I -L... The differences with my previous configure, which was not working at all in release mode, are: - no longer use -mp - no longer use -ltcg - using -release instead of -debug-and-release - added the -nomake to speed things a bit. I assume the last two don't make much a difference on the result... so it seems building for x64 using Visual 2010 doesn't support -mp or -ltcg - or both. Another side note: at the end, configure says to nmake confclean to re-configure. However nmake confclean doesn't work, whereas nmake distclean seems to work. I won't have time today to check if it's -mp or -ltcg which produce invalid binaries, I'll try to isolate the bad one next week. Regards, -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Trouble with release build on Win7
Le 21/12/2012 10:46, Koehne Kai a écrit : -Original Message- From: interest-bounces+kai.koehne=digia@qt-project.org [mailto:interest-bounces+kai.koehne=digia@qt-project.org] On Behalf Of Yves Bailly Sent: Friday, December 21, 2012 10:35 AM Cc: interest@qt-project.org Subject: Re: [Interest] Trouble with release build on Win7 [...] The differences with my previous configure, which was not working at all in release mode, are: - no longer use -mp - no longer use -ltcg It's -ltcg. I now added it to my configure line, and examples are indeed crashing in release mode. Can you create another bug report for this? I'll add it then to the Known issues page ... Done: https://bugreports.qt-project.org/browse/QTBUG-28784 Removing -ltcg allows designer and others to work. And now I can build the docs :-) Thanks and regards, -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Trouble with release build on Win7
Greetings all, I'm building Qt5 for 64bits using Visual 2010 on a Windows 7 64bits host, debug and release. However it seems anything using Qt5Gui.dll fails to start. - Running the example qtbase/examples/gui/analogclock/debug/analogclock.exe works fine. - Running the example qtbase/examples/gui/analogclock/release/analogclock.exe fails. Trying to profile the exec using Dependency Walker, it ends by this message: DllMain(0x07FEEFF5, DLL_PROCESS_ATTACH, 0x0018F700) in d:\libsrc\qt-5.0.0-x64\qtbase\bin\QT5GUI.DLL called by thread 1. First chance exception 0xC01D (Illegal Instruction) occurred in d:\libsrc\qt-5.0.0-x64\qtbase\bin\QT5GUI.DLL at address 0x07FEF01E4FC0 by thread 1. Second chance exception 0xC01D (Illegal Instruction) occurred in d:\libsrc\qt-5.0.0-x64\qtbase\bin\QT5GUI.DLL at address 0x07FEF01E4FC0 by thread 1. The same occures when trying running any GUI program, e.g. assistant or designer. Any idea about what I could check or try to find the issue? My configure command was: configure -confirm-license -opensource -debug-and-release -c++11 -shared -ltcg -accessibility -qt-sql-sqlite -plugin-sql-psql -opengl desktop -qt-zlib -qt-pcre -icu -qt-libpng -qt-libjpeg -qt-freetype -no-angle -no-incredibuild-xge -openssl -no-qml-debug -mp -I %ICU_INCLUDE% -I %OPENSSL_INCLUDE% -I %PGSQL_INCLUDE% -L %PGSQL_LIBS% -L %OPENSSL_LIBS% -L %ICU_LIBS% Any hint much welcome. -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Trouble with release build on Win7
Hello all again, Le 20/12/2012 15:19, Yves Bailly a écrit : Greetings all, I'm building Qt5 for 64bits using Visual 2010 on a Windows 7 64bits host, debug and release. However it seems anything using Qt5Gui.dll fails to start. - Running the example qtbase/examples/gui/analogclock/debug/analogclock.exe works fine. - Running the example qtbase/examples/gui/analogclock/release/analogclock.exe fails. Now things get weird... I build a 32bits version of Qt5, Visual 2010 Pro SP1, on a Windows 7 64bits host. The example qtbase/exampels/gui/analogclock starts both in release and debug flavor, bug it doesn't show the usual clock... just a grey rectangle with written QWindow in the middle. Same with the rasterwindow example. The example qtbase\examples\widgets\animation\animatedtiles seems to work though, and at least QtDesigner starts... I'll give a try to a Visual 2012 compile. However I really need a Visual 2010 64bits built of Qt5. I'm ready to try things, provide any needed information... please help! What should I try or check or whatever? Side question: where's the HTML doc? it used to be provided ready-to-use in Qt4 releases... Thanks for any hint. -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] packaging a build
Le 07/09/2012 06:42, Morgan McKenzie a écrit : Anyone have any other suggestions? I guess that switching to mingw/gcc is an option provided that I can get it to build on my computer, but I'd rather not... Don't know for Qt5, but try this: put the needed Qt DLLs and plugins in the same folder as your executable, then in this same folder place a file named qt.conf containing: [Paths] plugins = plugins (assuming you put the plugins in a plugins subdirectory). This works for me, Qt 4.8.2. Hope this helps. -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
Hello Konrad, Le 19/07/2012 10:07, Konrad Rosenbaum a écrit : Does anyone provide a complete binary package for Qt 4.8.2 compiled with Mingw4.7? Are you trying 32bits or 64bits builds? The only really working 64bits MinGW I ever found is the one from TDM (http://tdm-gcc.tdragon.net/, also probably the easiest to install), but for now, no 4.7.x release available... Are you using MinGW-w64? Is is usable without MSYS, and installable without too much troubles? I'd be more than glad to try such a build, targetting 64bits binaries. Regards, -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Loading compressed SVG in QWebView
Greetings all, Here's an annoying problem I'm facing, trying to display an SVG image in a QWebView. If the image is compressed (*.svgz), it seems QWebView is unable to display it correctly. To be more precise, this works nicely: QByteArray image_data = /* some external source I know nothing about */ QWebView* my_web_view = /* ... */ my_web_view-setContent(image_data, image/svg+xml, source_url); ...but if the image_data contains a compressed SVG, e.g. read from an *.svgz file, then an error is displayed. Browsing around I could not find a nice solution, unless to try to uncompress the data myself... Maybe the MIME type I provide is not correct? Any hint appreciated :-) -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] About model/view sorting and headers
Greetings all, Here's something it seems I can't understand. Let's say I have a model, a subclass from QStandardItemModel, filled with a table-like set of data, creating as much QStandardItem as needed and calling QStandardItemModel::appendRow(). This model contains both an horizontal header (things like ID, Name, ...) and a vertical header (things like rec1, rec2, ...). This model is displayed in a standard QTableView, which allows sorting simply by clicking on the horizontal header. When I click, the rows are sorted, fine... but the rows' *headers* are not sorted. What am I missing here? How can I get the vertical header to be sorted just like the rows are sorted? Thanks for any hint! -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] About model/view sorting and headers
Le 05/03/2012 15:58, Jason H a écrit :
It would seem as your row header isn't header, but data?
Not sure about this... I fill my headers with code like this, in
the loop which appends rows:
// in the following, this is a subclass of QStandardItemModel
QListQStandardItem* row;
// ...filling row items...
this-appendRow(row);
QStandardItem* row_header = this-verticalHeaderItem(this-rowCount()-1);
if ( row_header == nullptr )
{
row_header = new QStandardItem();
this-setVerticalHeaderItem(this-rowCount()-1, row_header);
}
row_header-setText(QString(rec_%1).arg(this-rowCount());
Is this wrong? should I set the rows' headers in another way?
--
/- Yves Bailly - Software developper -\
\- Sescoi RD - http://www.sescoi.fr -/
The possible is done. The impossible is being done. For miracles,
thanks to allow a little delay.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] When its ready
Le 15/12/2011 17:11, Thiago Macieira a écrit : On Thursday, 15 de December de 2011 15.36.24, Yves Bailly wrote: There is a Jira item related to this https://bugreports.qt.nokia.com/browse/QTBUG-20556. The configure succeeds if you leave -ltcg out. Indeed it works (compiling examples and demos right now). That's a bit unfortunate though. WebKit is too big for the link-time compiler's mind. No way out. Maybe split it in two or more sub-libraries? Now I can understand it's not a top priority. -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
