[Development] Can't login on bugreports.qt.io
Hello all, Asking here, as I'm not sure where to ask. I want to login on https://bugreports.qt.io I'm redirected to a page on https://login.qt.io asking me to approve, two buttons "Allow" and "Deny" - I click "Allow" Then a page ask me to choose a username, suggesting two, with a button "Set username". I click on it... ... then I get a blank page showing nothing else than "Internal Server Error". Any help is welcome... -- Yves Bailly Software developer ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why does QLabel::pixmap() return `const QPixmap*`?
On 30/11/2014 09:35, Olivier Goffart wrote:
On Sunday 30 November 2014 06:37:11 Kevin Kofler wrote:
Sze Howe Koh wrote:
I'm curious about the rationale behind this API design. I can't think
of any other Qt function that returns an implicitly-shared object by
pointer, so this seems inconsistent. e.g. QWidget::font() returns a
QFont by const-ref.
Probably because the pointer can be null. C++ does not allow null
references. (The compiler might let you get away with it, but in principle,
it is not allowed.)
That's not the reason because you can return a null pixmap (QPixmap::isNull).
However a null pixmap and no pixmap at all are two different things :-)
QPixmap const* pix = label-pixmap();
if ( pix == nullptr )
{
// this label has no pixmap
}
else if ( pix-isNull() )
{
// this label does have a pixmap, which is null/empty
}
else
{
// etc.
}
Because of the different meanings, the API seems sensible to me.
Regards,
--
(o | Yves Bailly | -o)
//\ | Linux Dijon : http://www.coagul.org | //\
\_/ | | \_/`
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QOpenGLWidget vs. QGLWidget
On 31/07/2014 20:03, Agocs Laszlo wrote: Yes, setViewport() will continue to work with QOpenGLWidget too. Great! :-) Note that all this does not mean existing code has to migrate away from QGLWidget. It is not going to disappear. If it works, just keep using it. Fine, however QGLWidget's status moving to deprecated is the first step on the road to obsolete, then sooner or later removed... So I guess new codes should use QOpenGLWidget, while old ones should migrate little by little. Is there already some doc somewhere, describing the differences between QGLWidget and QOpenGLWidget? not only the API, also the internals maybe. 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QOpenGLWidget vs. QGLWidget
Greetings all, I've just read the new features for the upcoming Qt 5.4, here: http://qt-project.org/wiki/New-Features-in-Qt-5.4 ...and I noticed this: Deprecated features: Qt Gui: The QtOpenGL module, that is, the QGL classes are deprecated since QGLWidget has a suitable replacement now. Will the new QOpenGLWidget class be usable like the old QGLWidget, notably as a background for a QGraphicsView? allowing to draw QGraphicsItem, even widgets, on top of an OpenGL scene... 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
On 27/04/2014 12:55, Peter Kümmel wrote: Having imperative code on the JS side is also the root of the rejection of QML for many C++ developers. If QML would have been just a improved .ui nobody would have complained. +1 -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
On 21/04/2014 04:53, Thiago Macieira wrote: Em dom 20 abr 2014, às 22:37:11, m...@rpzdesign.com escreveu: Isn't Qt Widgets so mature that they are stable? They are. But so much could still be done... as a basic example I stumbled upon very recently, why is it so hard to change the font of *one* item in a combo box?? The design direction is because QML is easier to develop with, Not for heavy-weight applications, even less when part of the UI is dynamically build at runtime according to context, config files, etc. more modern, and based on OpenGL. Widgets don't have that and will never be as efficient. Therefore, the effort is directed towards the technology that has the potential to make interfaces for 2017-2020. Even in 2017-2020, we'll still have desktops. Phones or even tablets are just not suited for *real* work, and I don't see how they could be. A professional writer can type 100 words per minute on a keyboard, I doubt this will be even remotely possible on a tablet. Doing serious 3D modeling on a tablet is a joke. And think about the hundreds of mouse/keyboards shorcuts... if you remove them, as its the case on modern devices, you loose a lot in productivity. QtCreator is a complex application, though not as heavy-weight as some I work on. Could it be redone the right way, with *all* the UI in QML and the business logic in C++? would developing QtCreator this way be as efficient as it is today? and finally, would a user be as efficient with it on a modern device as he can be on a good'old desktop? Same question for Calligra and others. QML has its merit, it's certainly perfect for some projects. But for all I've seen and tried until now, only for projects having a rather simple UI. For really complex UIs, QML seems not suitable - at least for now. Mind, what I (and others) is talking about, are applications where user's productivity matters more than the UI being nice - or even looking native. Take Blender: sure, the learning curve is steep. But once you know it, you can very very productive with it, *on any platform*, because it looks the same *on all platform*. Looking native might be a nice selling or demo thing, but it's just irrelevant (or even counter-productive) for a whole class of applications. So please, please... keep improving widgets! :-) some things are unnecessary difficult to do, some features would be so nice to have... -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Historical question
Greetings all, At the time of the move from Qt3 to Qt4, does anyone remember the reasons given for using headers without extensions? e.g. #include QLabel instead of #include qlabel.h I think I read something explaining that choice at the time, but I'm enable to find it again... Just curious, no intent to start a flame :-) -- /- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OK to add zero/bulk copy to QVector?
On 29/12/2013 20:10, Jiergir Ogoerg wrote: Hi, there are 2 simple options to speed up setting/adding elements to a vector when a heap buffer is filled in in advance: 1) Bulk copy. Assign a bunch of elements at once (from another vector or array), like std::vector::assign() does. A big extra copy happens, but avoids multiple calls to push_back(). What about this, re-using your example: my_struct *arr = new my_struct[count]; QVectormy_struct v(count); memcpy(v.data(), arr, sizeof(my_struct)*count); Assuming my_struct doesn't contain self-referencing references or virtual table. Regards, -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Proposal] Replace size related parameters with size_t
On 24/12/2013 19:26, Kurt Pattyn wrote: QString, QByteArray, QList, aso often use sign integers to store sizes, indexing, aso. This often leads to signed/unsigned mismatches and is not really according standard practice. Also, this restricts the indexes, sizes, aso to 32-bit. 31-bit actually... :-) unless you use negative indices, which can be handy sometimes. That said, the days where you would need to index more than 2147483647 items don't seem so close yet. In cases where it might happen (file offset), usually long long or int64_t is used, which should be plenty enough for some years. This might be an issue when using e.g. QByteArray to handle more than 2GB of memory, or sharing more than 2GB with QSharedMemory. If keeping the signed indices is desirable, then maybe those classes should switch to int64_t - after all, huge amount of RAM is more and more common these days. One solution to resolve the signed/unsigned mismatch is to cast the types to the appropriate type, but this can be dangerous, and hides the real problem. A better approach would be to use std::size_t. My proposal is to replace all int types with size_t where appropriate. I realise that this has a major impact on compatibility, but it is certainly something that should be considered. A solution to the compatibility problem could be to duplicate the methods and mark the old ones as obsolete. What are your thoughts? This a subject which as already been highly discussed already. A side effect is to have to define a special value as being invalid index, similar to std::string::npos, for e.g. search functions which return an index instead of an iterator. I used to agree to use size_t for all size-related semantic, whereas Qt developers have consistently preferred int, for reasons they will recall much better than me. Along the years I got to deal with it, really it's a minor annoyance. So for what it worthes, my thought is to consider there are more important things to do before such an important change. Regards, -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 RC1 candidate packages available
Greetings everyone, Le 28/11/2013 14:36, Heikkinen Jani a écrit : We have finally Qt 5.2 RC1 candidate packages available in http://download.qt-project.org/snapshots/qt/5.2/5.2.0-rc1/2013-11-28_179/ . Mirroring is ongoing so it is possible that all packages aren’t visible yet but will be soon … Again a great thanks for all this tremendous work... Just a question for the post-5.2.0 era, i.e. 5.2.1: can we expect pre-built binaries for both MinGW 64bits and Visual C++ 2013 (OpenGL 64bits) ? -- /- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit : On 8 November 2013 10:01, Yves Bailly yves.bai...@sescoi.fr wrote: As a float is 4 bytes, I would expect the second f.pos() to display 4... but it displays 8, as if QDataStream had moved 8 bytes ahead instead of just 4. Needless to say, the read float is wrong... Am I missing something here, or is it a bug? See QDataStream::setFloatingPointPrecision. The default is double. That's pretty strange... what if I want to read a float then a double? do I have to switch between the two each time? Does this means it's impossible to use code like this: float f; double d; datastream f d; ? -- /- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
Le 08/11/2013 10:29, Christian Ehrlicher a écrit : Am 08.11.2013 10:15, schrieb Yves Bailly: Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit : On 8 November 2013 10:01, Yves Bailly yves.bai...@sescoi.fr wrote: As a float is 4 bytes, I would expect the second f.pos() to display 4... but it displays 8, as if QDataStream had moved 8 bytes ahead instead of just 4. Needless to say, the read float is wrong... Am I missing something here, or is it a bug? See QDataStream::setFloatingPointPrecision. The default is double. That's pretty strange... what if I want to read a float then a double? do I have to switch between the two each time? Does this means it's impossible to use code like this: float f; double d; datastream f d; ? setFloatingPointPrecision does only change the way the floating point numbers are stored in the data stream, not what you read from it. Sorry but this seems wrong to me... as soon as I used setFloatingPointPrecision(SinglePrecision), magically I can read the floats correctly. So setFloatingPointPrecision() *also* changes the way numbers are read. Also I think you're wrong in what you want to do. You can't read data from a file which was not stored with QDataStream before! See http://qt-project.org/doc/qt-5.0/qtcore/qdatastream.html#details I can understand this for high-level Qt objects, but what about lower-level data? Does this mean I can't use QDataStream to read a file written by some other program, and/or can't use it to *write* a file which could be read back by some other program? Again, only using low-level data, ints, floats, and so on. If that is true, then it's a huge step backward in the ease of use provided by Qt in the realm of reading/writing binary files. Just to give a context, the goal here is to read and write binary STL (stereolithography) or PLY files. I have old Qt3 code which works like a charm, reading and writing files usable to and from other soft (e.g. Blender). Now moving that old code to Qt5 it seems to not work as expected, despite using only basic, low-level data types. -- /- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Weird offseting in QDataStream
On 08/11/2013 11:37, Andreas Aardal Hanssen wrote: On 08 Nov 2013, at 11:32, André Somers an...@familiesomers.nl wrote: Eskil Abrahamsen Blomfeldt schreef op 8-11-2013 11:20 QDataStream supports reading and writing floats and doubles, but it might use more bytes than necessary to represent them in the stream. the main ... I don't see what's wrong with such a mode, as long as the documentation warns that it won't work reliably with qreal (before 5.2, I read). You To me it sounds like Qt needs a new lower-level class for serializing and deserializing stuff. A QRawDataStream class, but keeping the ease-of-use :-) mostly the setByteOrder() in my case. Otherwise there's no added value compared to the standard std::fstream. QDataStream is for Qt only, it’s incompatible with all other binary formats out there, with the undocumented exception for cases where primitive types match. Then maybe it should be stated more clearly in the doc? A big red blinking warning don't use QDataStream for anything else than to and from itself... I would recommend against using QDataStream for anything else than reading back what was written using QDataStream. This is what I called a step backward. Regards, -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2, Android and QWidget over OpenGL
On 28/10/2013 06:25, BogDan wrote: Hi, Please use https://bugreports.qt-project.org to open a new issue. It looks like a very serious regression to me! Done: https://bugreports.qt-project.org/browse/QTBUG-34412 Thanks for your work! Regards, -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] #error for unreleased MSVC versions
Hello, Le 24/10/2013 15:49, Thiago Macieira a écrit : I'm going to add an #error to qcompilerdetection.h for any unreleased version of MSVC. The reason is this combination: 1) MSVC does not provide a way to turn C++11 off (and won't provide for C++14 either) 2) MSVC does instantiates *ALL* class members of exported classes, even inline functions. The result of those is that the DLLs need to export all methods with rvalue references, rvalue refs and other C++11 constructs. == In other words, adding new Q_COMPILER_xxx defines for C++11 for MSVC breaks binary compatibility === So what? While I understand the reasoning about binary compatibility, in my humble opinion such a drastic change should be at least deactivable, for example by adding a switch to configure, something like -ignore-binary-compatibility. This way older versions of Qt would still be compilable (assuming no other compile error). For that reason and because we don't know what features newer MSVC will support, I am right now declaring all future versions unsupported until there's a Qt release that adds the defines. Retroactively, that means Qt 5.0 and 5.1 are unsupported on MSVC 2013 and are not binary compatible with Qt 5.2 there. Fine :-) but unsupported should not mean not allowed to compile at all... 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Visual C++ 2013 binaries
Greetings all, As most already probably know, Visual C++ 2013 is out. While it's most probably too late for the upcoming Qt 5.2, are there any plan to provided binaries from Visual 2013 in the future? For Qt 5.2.1, 5.2.2... or later? This information can have a significant impact on our planning here. 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature request: several layouts in a single ui file
On 02/09/2013 09:46, Saether Jan-Arve wrote: What you are suggesting should be possible, but I would like to explore if there can be a more generic way. You are suggesting to push this even further, i.e. one layout might use a QComboBox instead of a groupbox with radio buttons. * If its pushed far enough, wouldn't this be like having two separate .ui files that could be switched? I had not considered to go as far as change the contents itself - this would imply to destroy (or hide) some things, then to create (or show) some others. Maybe it's a step too far... But overall, indeed it's a bit like having two .ui then switch between them - with the important goal to avoid as much as possible to destroy/recreate things. In the beginning it was just about changing the layout and some properties (e.g. some size policies). Regards, -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Flat directory structure for Qt 5.2 documentation
On 02/09/2013 09:52, Smith Martin wrote: Two reasons. First, so people can enter documentation page paths without knowing the module subdirectory they are in. Second, so the pages will appear first in google searches. One more reason: take the Qt5's QObject page, QWidget doesn't show in its subclasses. This is true for others as well. Overall I find the documentation harder to navigate since Qt4, compared to Qt3 which was a real pleasure. -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature request: several layouts in a single ui file
On 01/09/2013 05:49, Sze Howe Koh wrote: On 1 September 2013 05:27, Yves Bailly yves.bai...@laposte.net wrote: On 31/08/2013 14:42, Mark wrote: A nice way to load different gui versions is by combining states [1] and the loader object [2] and just load the gui you want based on the state you set. [1] http://qt-project.org/doc/qt-5.1/qtquick/qml-qtquick2-state.html [2] http://qt-project.org/doc/qt-5.1/qtquick/qml-qtquick2-loader.html If I understand things correctly, using the loader is a bit like destroy the current GUI followed by rebuild a new GUI. You can achieve that with traditional QWidgets without destroying and reconstructing any objects. I'm perfectly aware of this, that's what I'm doing by hand for now. What I was suggesting in the beginning of this thread, was to add support for this in QtDesigner and UI files. -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature request: several layouts in a single ui file
On 31/08/2013 14:42, Mark wrote: A nice way to load different gui versions is by combining states [1] and the loader object [2] and just load the gui you want based on the state you set. [1] http://qt-project.org/doc/qt-5.1/qtquick/qml-qtquick2-state.html [2] http://qt-project.org/doc/qt-5.1/qtquick/qml-qtquick2-loader.html If I understand things correctly, using the loader is a bit like destroy the current GUI followed by rebuild a new GUI. What I'm looking for is quite different: it's out of question to *destroy* widgets, just change their layout - only the layouts are destroyed, not the widgets. Imagine the case where a displayed component needs a lot of time to build its contents, either from user inputs or some long computation. All of this re-layouting should be completely dynamic, done and un-done several time during the application running time. Or am I missing something? -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Feature request: several layouts in a single ui file
Greetings all,
Following given advices, I post here a question posted in the forum...
I’m talking here about widgets-based applications, although it might be
relevent too for qml-based applications. And
posting in “general” because I think it’s truely “general”, despite being
inspired by mobile (Android) development.
Here’s the point. More and more the computers which run our applications can
self-adjust their display according to a
“portrait” or “landscape” orientation – tablets and mid-end or high-end phones
are actual computers. An application run
in fullscreen should adjust itself, its layout, according to this orientation.
On the desktop, one can also imagine an
application adjusting its layout according to its main window form factor.
For example, an application can show a row of buttons at the top (or bottom) in
a portrait layout, but a column of
buttons at the left (or right) in a landscape layout.
However, when a GUI is designed in QtDesigner, only one layout can be defined.
If the application has to adjust itself,
this layout needs to be manually destroyed then re-created. It would be nice if
it was optionally possible to define
more than one layout in an UI file, then have the main container be allowed
(optionally) to use one layout or the other
according to e.g. an orientation change.
Maybe this could be achieved by splitting the generated setupUi() method.
Something like this:
class Ui_My_Widget
{
void setupUi(QWidget* My_Widget)
{
/* here create the various controls and set common properties */
}
void setupPortrait(QWidget* My_Widget)
{
/* apply a layout for portrait orientation */
}
void setupLandscape(QWidget* My_Widget)
{
/* apply a layout for landscape orientation */
}
virtual bool hasOrientationLayouts() override
{ return true; }
virtual bool setupOrientationLayout(QWidget* My_Widget) override
{
if ( My_Widget-width() My_Widget-height() )
this-setupLandscape();
else
this-setupPortrait();
}
};
The hasOrientationLayouts() method would override a virtual method provided in
QWidget itself, which would return false
by default. Then QWidget::resizeEvent() would call setupOrientationLayout() if
hasOrientationLayouts() returns true. Of
course setupOrientationLayout() would also be a virtual method in QWidget,
doing nothing by default.
This way QtDesigner can provide two layouts an allows a GUI to automagically
adjust itself, or this can be done “by
hand” more easily.
Pushing the idea even further, some properties of some controls might be
different according to the layout – e.g. some
size policies. Or the size itself may induce some major changes, for example a
small window (phone screen) may use tabs,
while a large window (desktop or big tablet) may display everything in a single
view.
Any thoughts?
Regards,
--
(o | Yves Bailly | -o)
//\ | Linux Dijon : http://www.coagul.org | //\
\_/ | | \_/`
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature request: several layouts in a single ui file
On 30/08/2013 15:49, Olivier Goffart wrote: On Friday 30 August 2013 12:16:53 Yves Bailly wrote: Here’s the point. More and more the computers which run our applications can self-adjust their display according to a “portrait” or “landscape” orientation – tablets and mid-end or high-end phones are actual computers. I think this is an ambitious proposal for QWidget based UI. Maybe ambitious, however I'm already doing this by hand in a few applications ;-) So it's not impossible, I just think some lower-level support directly from QtDesigner might help. I believe that QtQuick is already solving the problem quite elegantly with states. I'm not at all aware of QtQuick and its states. Can you point some documentation about this? Regards, -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Announce] Qt 5.0.1 released
Le 05/02/2013 09:08, Koehne Kai a écrit : The analogclock example doesn't start. Even if I try to create an almost- empty project (you know, the default, auto-generated one with a single QMainWindow), it doesn't start either - debug or release. [...] That's weird. For the record that's my log after _get_output_format call (also with Win7/64 bit) ... 00:00:11.781: GetProcAddress(0x766F [c:\windows\syswow64\MSVCRT.DLL], _get_output_format) called from c:\qt\qt5.0.1-mingw\5.0.1\mingw47_32\bin\ICUUC49.DLL at address 0x675F3009 and returned 0x76765CE8. I notice you installed it in the default location c:\qt\qt5.0.1, whereas I installed it in c:\qt501... can this make a difference? Don't know whether the problem is indeed in the icu (or handling of its results in Qt5Core), or if for some reason the loading of platform plugins fails. Doesn't the debugger show you anything? A segmentation fault... stack trace: 0 loadint qgenericatomic.h98 0x40d87f 1 QBasicAtomicIntegerint::load qbasicatomic.h 145 0x40d87f 2 QtPrivate::RefCount::isShared qrefcount.h 99 0x40d973 3 QVectorchar*::isDetached qvector.h 109 0x40d905 4 QVectorchar*::detach qvector.h 306 0x40d464 5 QVectorchar*::dataqvector.h 128 0x40d437 6 WinMain@16 qtmain_win.cpp 131 0x4026ee 7 mainmain.c 73 0x40244e Starting other Qt programs, such as designer or linguist from the provided command-line works fine. Any hint or idea? I really don't know where to investigate here... Did you try to launch the example from exactly the same environment/command line as designer or linguist? Yes :-) but without any luck. PS: Could you create a bug in the bugtracker, and fill in the details there? It's just easier to track there ... I'll do this if no magic light comes... 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Announce] Qt 5.0.1 released
Le 05/02/2013 16:02, Thiago Macieira a écrit : On terça-feira, 5 de fevereiro de 2013 09.34.54, Yves Bailly wrote: A segmentation fault... stack trace: 0loadint qgenericatomic.h98 0x40d87f 1QBasicAtomicIntegerint::load qbasicatomic.h 145 0x40d87f 2QtPrivate::RefCount::isShared qrefcount.h 99 0x40d973 3QVectorchar*::isDetached qvector.h 109 0x40d905 4QVectorchar*::detach qvector.h 306 0x40d464 5QVectorchar*::dataqvector.h 128 0x40d437 6WinMain@16 qtmain_win.cpp 131 0x4026ee 7mainmain.c 73 0x40244e Crash inside qtmain. It's probably the same as this already-filed bug report: https://bugreports.qt-project.org/browse/QTBUG-29443 Looks similar, however the crash is inside qgenericatomic.h, not qtmain. The reporter there provided a patch which looks completely unrelated to the problem at hand. If indeed it is solving a problem, then we must conclude that the problem is a miscompilation. If that's the case, the solution is: shoot the compiler in the head. I used the provided pre-build binaries, I did not compile Qt myself. Installer used: http://releases.qt-project.org/qt5/5.0.1/qt-windows-opensource-5.0.1-mingw47_32-x86-offline.exe So I don't really know who should shoot which compiler in the head... ;-) Anyway this is getting really frustrating, since the 5.0 initial release I can't get a Qt working even remotely correctly on my Win7/64bits computer... even this 32bits, MinGW-compiled release doesn't work properly, even using the provided pre-build binaries. I'm ready to try and check whatever one might ask, I just don't have an idea where to start. 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Announce] Qt 5.0.1 released
Greetings all, Le 31/01/2013 14:10, List for announcements regarding Qt releases and development a écrit : I'm happy to announce that Qt 5.0.1 is now released. See the blog on http://blog.qt.digia.com/blog/2013/01/31/qt-5-0-1-released/ I've just downloaded and insalled the (huge) bundle Qt 5.0.1 for Windows 32-bit with included MinGW 4.7. Installed fine on a 64bits, Win7 host. QtCreator starts fine, but... The analogclock example doesn't start. Even if I try to create an almost-empty project (you know, the default, auto-generated one with a single QMainWindow), it doesn't start either - debug or release. Profiling using DependencyWalker ends with this: [...many messages...] 00:00:09.298: DllMain(0x1022, DLL_PROCESS_ATTACH, 0x0028FD24) in c:\qt501\5.0.1\mingw47_32\bin\QT5WIDGETSD.DLL called by thread 1. 00:00:09.298: DllMain(0x1022, DLL_PROCESS_ATTACH, 0x0028FD24) in c:\qt501\5.0.1\mingw47_32\bin\QT5WIDGETSD.DLL returned 1 (0x1) by thread 1. 00:00:09.298: GetProcAddress(0x7550 [c:\windows\syswow64\MSVCRT.DLL], _get_output_format) called from c:\qt501\5.0.1\mingw47_32\bin\ICUUC49.DLL at address 0x675F3009 and returned 0x75575CE8 by thread 1. 00:00:09.298: First chance exception 0xC005 (Access Violation) occurred in c:\qt501\5.0.1\mingw47_32\examples\widgets\widgets\analogclock-build-desktop_qt_5_0_1_mingw_32bit-debug\debug\ANALOGCLOCK.EXE at address 0x0040D87F by thread 1. 00:00:09.313: Second chance exception 0xC005 (Access Violation) occurred in c:\qt501\5.0.1\mingw47_32\examples\widgets\widgets\analogclock-build-desktop_qt_5_0_1_mingw_32bit-debug\debug\ANALOGCLOCK.EXE at address 0x0040D87F by thread 1. 00:00:09.313: Exited c:\qt501\5.0.1\mingw47_32\examples\widgets\widgets\analogclock-build-desktop_qt_5_0_1_mingw_32bit-debug\debug\ANALOGCLOCK.EXE (process 0x1064) with code -1073741819 (0xC005) by thread 1. Starting other Qt programs, such as designer or linguist from the provided command-line works fine. Any hint or idea? I really don't know where to investigate here... 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Announce] Qt 5.0.1 released
Le 31/01/2013 14:28, Yves Bailly a écrit : Hello, Le 31/01/2013 14:10, List for announcements regarding Qt releases and development a écrit : I'm happy to announce that Qt 5.0.1 is now released. See the blog on http://blog.qt.digia.com/blog/2013/01/31/qt-5-0-1-released/ Thanks for the ongoing hard work! Looking at http://qt-project.org/downloads, I see the archive size of the MinGW build is an enormous 823MB, whereas all other builds are more around 400-500 MB... any idea which cause this huge difference? OK, The MinGW binary package includes a 32 bit MinGW-builds Sorry for the noise, next time I'll read a bit paste the next line. -- /- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.0.1 -- Release Testing
Greetings, Le 18/01/2013 14:37, Motyka Rafal a écrit : Qt 5.0.1 release testing has been started. We would like to kindly ask the Qt Community for help by testing the new packages. 1. Installer packages are available here: http://releases.qt-project.org/digia/5.0.1/backups/2013-01-18-412/ Not sure it deserves a bug report, but: - installed the release using qt-windows-opensource-5.0.1-msvc2012_64-x86_64-offline-2013-01-18-412.exe on a Windows 7 64bits host. - when trying to launch examples\webkitwidgets\browser\browser.exe, I get an error saying D3DCOMPILER_46.dll is missing - while there's a _43 in the bin directory. Maybe just a missing file in the installer? 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU and Windows
Le 11/01/2013 16:50, Thiago Macieira a écrit : On sexta-feira, 11 de janeiro de 2013 13.32.35, Shaw Andy wrote: Unfortunately this is what is happening now if ICU is linked in, ICU will always use the release version so if Qt is built in debug mode then it will end up mixing the C runtime libraries. As far as I know, mixing C++ (not C!) runtime libraries is permitted, provided that certain care is taken, especially that the runtime that allocated memory must be the one to free it. Which is not always that easy... if a library function returns, say, an simple std::string *by value*, then who will destroy the allocated memory? It's really too easy to break something, somwhere, causing a random crash almost impossible to reproduce reliably. For what it worths, for years in my job we've been taking the greatest care to avoid mixing runtimes at all cost, requiring external library providers to provide debug builds of their libraries. By applying this rule, a whole set of random, very hard-to-track crashes simply stopped occuring. Indeed most of them where due to freeing in a lib memory which had been allocated in another. The nice thing with Qt is that everything really needed was provided with Qt itself in its 3rdparties: libjpeg, libpng, sqlite... If ICU is a hard need, then IMHO it's a good candidate to be provided alongside the other 3rdparties. 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL in Qt 5.1 and onwards
Le 07/01/2013 09:13, Sletta Gunnar a écrit : Le 18/12/2012 14:34, Sean Harmer a écrit : I would like to start a discussion on the future level of support for OpenGL enablers in Qt for those that are interested. So here goes... This may be a bit off-topic, but I have a little concern when reading the Qt5 doc about OpenGL support... it is said here and there that the old QGLFormat, QGLContext, ... classes are deprecated and should no longer be used. However, there's no alternative when using QGLWidget, so are they really deprecated or in some kind of not-yet-deprecated-but-soon state? Or did I miss something? What we have done in Qt 5 is to move most of what is in QtOpenGL into QtGui under new names. The old classes in the QtOpenGL will continue to work and will not go away anytime soon, so you can safely continue using them if you are already using them for existing code. We do however promote using QWindow, QOpenGLContext and QOpenGLFormat classes in QtGui for new code. They have cleaner API, are slightly more light-weight and support one OpenGL context for multiple surfaces if that is interesting for you. The QOpenGL module is implemented in terms of the classes in QtGui so they do interoperate. Thanks for the clarification. I've had a look at the examples, however QWindow is (for now) of little interest for me, as I'm working on a desktop app, where an OpenGL widget is just an element among others of the overall GUI. Whereas QWindow and others are made for GL-only GUIs (no QWidgets), if I understood things well. 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL in Qt 5.1 and onwards
Greetings all, Le 18/12/2012 14:34, Sean Harmer a écrit : I would like to start a discussion on the future level of support for OpenGL enablers in Qt for those that are interested. So here goes... This may be a bit off-topic, but I have a little concern when reading the Qt5 doc about OpenGL support... it is said here and there that the old QGLFormat, QGLContext, ... classes are deprecated and should no longer be used. However, there's no alternative when using QGLWidget, so are they really deprecated or in some kind of not-yet-deprecated-but-soon state? Or did I miss something? 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL in Qt 5.1 and onwards
Le 07/01/2013 08:44, Samuel Rødal a écrit : On 01/07/2013 08:28 AM, Yves Bailly wrote: Greetings all, Le 18/12/2012 14:34, Sean Harmer a écrit : I would like to start a discussion on the future level of support for OpenGL enablers in Qt for those that are interested. So here goes... This may be a bit off-topic, but I have a little concern when reading the Qt5 doc about OpenGL support... it is said here and there that the old QGLFormat, QGLContext, ... classes are deprecated and should no longer be used. However, there's no alternative when using QGLWidget, so are they really deprecated or in some kind of not-yet-deprecated-but-soon state? I'm not sure _all_ the QGL*-classes are marked as deprecated at the moment? QGLFormat, QGLContext, and QGLWidget still show up in the class list: http://qt-project.org/doc/qt-5.0/qtdoc/classes.html Hu... that was obvious, seems I read more than what is written. Sorry for the noise. -- /- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Non-movable Qt build
Le 28/12/2012 13:15, Thiago Macieira a écrit : On sexta-feira, 28 de dezembro de 2012 12.39.40, Stephen Kelly wrote: On Wednesday, December 26, 2012 16:14:10 Yves Bailly wrote: Any hint greatly appreciated. Why can you not use 'make install'? He can do make install, but most people developing on Windows don't because their prefix is equal to the source dir. In any case, that's not the point: he wants to move the installed files after they've been installed. Indeed. Does anyone knows where I could find the source code of the official installer, or at least some information about what it does? Because the installer *does* relocate the binaries, that would be a good starting point to relocate my own binaries... Anyway, have all a happy and healthy new year ;-) 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Non-movable Qt build
Le 02/01/2013 13:50, Sergio Ahumada a écrit : On 01/02/2013 01:50 PM, Yves Bailly wrote: Le 02/01/2013 13:42, Thiago Macieira a écrit : On quarta-feira, 2 de janeiro de 2013 10.53.03, Yves Bailly wrote: Does anyone knows where I could find the source code of the official installer, or at least some information about what it does? Because the installer does relocate the binaries, that would be a good starting point to relocate my own binaries... It simply edits the qmake and QtCore DLL binaries, plus maybe some files in mkspecs, changing a placeholder prefix to the installation dir. Editing binaries? hu, havent't done that since... a long time ;-) Changing some internal strings I guess? any idea which one or how they can be spotted? http://qt-project.org/wiki/Building-Qt-Package may give some ideas Quite interesting indeed... too bad those release-tools/ seem not provided with the downloadable source archives, I guess they're available only from Git. Also it seems they would need to be tweaked a bit, e.g. to give the needed options to configure. I'll have a look at this, however, as someone already said, it would be very nice if a kind of packager was provided with the source archives. Maybe make the installer framework (cited by Maurice) publicly available and usable? Thanks for the information. -- /- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Non-movable Qt build
Le 26/12/2012 16:39, Thiago Macieira a écrit :
On quarta-feira, 26 de dezembro de 2012 16.14.10, Yves Bailly wrote:
Why not use relative paths, e.g.
QT_MODULE_BIN_BASE = ../../qtbase/bin
...or some variable, e.g.
QT_MODULE_BIN_BASE = ${QTDIR}/qtbase/bin
??
Any hint greatly appreciated.
Create a file called qt.conf in the bin dir and write this inside:
[Paths]
Prefix=..
I tried that (although giving an absolute path), but qmake still gives the
warnings.
Just tried using .., I still get the warnings...
--
/- 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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
Hello all, Le 30/08/2012 14:33, Yves Bailly a écrit : Le 30/08/2012 13:23, lars.kn...@nokia.com a écrit : the Qt 5 beta has now been released. Please find all the details at http://www.qt-project.org/wiki/Qt-5-Beta Trying to compile on Windows 7 64bits using MSVC 2010 (32bits compiler). After having read the provided README. NMAKE : fatal error U1077: 'C:\vs10\VC\BIN\cl.EXE' : return code '0x2' Stop. *** qtbase/configure exited with non-zero status. No more idea about this compiling issue? it's quite frustrating... -- /- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
Le 31/08/2012 09:05, Thiago Macieira a écrit : On sexta-feira, 31 de agosto de 2012 09.00.40, Yves Bailly wrote: NMAKE : fatal error U1077: 'C:\vs10\VC\BIN\cl.EXE' : return code '0x2' Stop. *** qtbase/configure exited with non-zero status. No more idea about this compiling issue? it's quite frustrating... Please note each try is done from a clean, just-unpacked archive (hard learned lesson after 15 years of experience building Qt releases...) It looks like perl wasn't found, so the forwarding headers weren't created. Well, Perl (ActiveState) should be found, at least it's in PATH: D:\qt\qt5-5.0.0-win32-msvc2010perl -v This is perl 5, version 14, subversion 2 (v5.14.2) built for MSWin32-x64-multi-thread (with 1 registered patch, see perl -V for more detail) Copyright 1987-2011, Larry Wall Binary build 1402 [295342] provided by ActiveState http://www.ActiveState.com Built Oct 7 2011 15:19:36 Ensure that perl is in PATH and re-run configure. If that still fails, run syncqt manually and let us know if that produces errors: perl bin/syncqt ...and now it works... I really don't know what happened, maybe an unlikely error while unpacking... configure worked, compiling right now. Sorry for the noise. Last word at last, despite the troubles I encountered (which may well be my fault): a great thank and congratulation to all those who made that release even possible, despite all the troubles and non-technical mess. 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
Greetings all, Le 30/08/2012 13:23, lars.kn...@nokia.com a écrit : the Qt 5 beta has now been released. Please find all the details at http://www.qt-project.org/wiki/Qt-5-Beta and my blog post at http://labs.qt.nokia.com/2012/08/30/qt5-beta-is-here Enjoy! Trying to compile on Windows 7 64bits using MSVC 2010 (32bits compiler). After having read the provided README. D:\qt\qt5-5.0.0-win32-msvc2010configure -help + D:/qt/qt5-5.0.0-win32-msvc2010/qtbase/configure -help Please wait while bootstrapping configure ... Microsoft (R) Program Maintenance Utility Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. cl -c -Yc -nologo -Zm200 -Zc:wchar_t -MT -W3 -GR -EHsc -w34100 -w34189 -DUNICODE -DQT_NO_CODECS -DQT_NO_TEXTCODEC -DQT_NO_UNICODETABLES -DQT_LITE_COMPO NENT -DQT_NO_COMPRESS -DQT_NO_THREAD -DQT_NO_QOBJECT -DQT_NO_GEOM_VARIANT -D_CRT_SECURE_NO_DEPRECATE -DQT_BOOTSTRAPPED -DCOMMERCIAL_VERSION -I..\..\include -I ..\..\include\QtCore -I..\..\include\QtCore\5.0.0 -I..\..\include\QtCore\5.0.0\QtCore -ID:\qt\qt5-5.0.0-win32-msvc2010\qtbase\tools\shared -ID:\qt\qt5- 5.0.0-win32-msvc2010\qtbase\mkspecs\win32-msvc2008 -Fpconfigure_pch.pch -Foconfigure_pch.obj -TP D:\qt\qt5-5.0.0-win32-msvc2010\qtbase\tools\configure\configur e_pch.h configure_pch.h D:\qt\qt5-5.0.0-win32-msvc2010\qtbase\tools\configure\configure_pch.h(49) : fatal error C1083: Cannot open include file: 'qlist.h': No such file or directory NMAKE : fatal error U1077: 'C:\vs10\VC\BIN\cl.EXE' : return code '0x2' Stop. *** qtbase/configure exited with non-zero status. ...and some others, missing QtCore/qalgorithms.h... - Added to -I..\..\src\corelib\tools to EXTRA_CXXFLAGS - Changed ...\qtbase\src\corelib\tools\qlist.h to #include qalgorithms.h instead of QtCore/qalgorithms.h ...and more errors like those ones... Giving up for now. However if someone want me to try something I'll be glad to try, I just don't have time to dig myself. *sigh* -- /- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
Le 30/08/2012 14:43, jan-arve.saet...@nokia.com a écrit : ext Yves Bailly wrote on 2012-08-30: configure.bat will run perl. Please check if it will use the ActiveState perl, and not the perl shipped with msysgit. I always put the ActiveState perl directory as the first path in %PATH% in order to avoid this. I guess it's actually ActiveState's Perl indeed: D:\qtperl --version This is perl 5, version 14, subversion 2 (v5.14.2) built for MSWin32-x64-multi-thread (with 1 registered patch, see perl -V for more detail) Copyright 1987-2011, Larry Wall Binary build 1402 [295342] provided by ActiveState http://www.ActiveState.com Built Oct 7 2011 15:19:36 Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using man perl or perldoc perl. If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. -- /- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8 clang and libc++
Le 24/08/2012 19:11, Sylvain Pointeau a écrit : Hi, I would like to compile Qt 4.8 using clang / libc++ (to have c++11) is it possible? Doesn't simply using GCC 4.7 provides C++11? or is C++11 support in CLang more advanced? -- /- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Essentials
Greetings all, first of all let me express a deep and warm feeling for all those writing so nice code since so long and rewarded in such manner... Le 02/08/2012 14:26, Thiago Macieira a écrit : [...] Qt3D might be quite mature, actually, since it's been around for longer and has no platform-specific dependencies other than OpenGL. For what is worthes, here we're hardly waiting for Qt3D, delaying an internal long-term project which would have been quite similar. That said we're not the ones doing the job on Qt3D, so any decision you make will be seen as simply right. Kindly, -- /- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
