Re: [Development] Experimental Qt 5 installers by Digia
Hi, I install qt5 using linux installer. When I try to compile a simple project, I get: $ qmake $ make g++ -Wl,-O1 -Wl,-rpath,/home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib -Wl,-rpath,/home/leandro/qt/ -o project main.o -L/home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib -lQtCore -lpthread /usr/bin/ld: warning: libicui18n.so.44, needed by /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libicuuc.so.44, needed by /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so, not found (try using -rpath or -rpath-link) /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so: undefined reference to `u_strToLower_44' /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so: undefined reference to `u_strToUpper_44' /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so: undefined reference to `ucol_setAttribute_44' /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so: undefined reference to `ures_close_44' /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so: undefined reference to `ucol_getSortKey_44' /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so: undefined reference to `ures_open_44' /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so: undefined reference to `ures_getStringByKey_44' /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so: undefined reference to `ucol_close_44' /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so: undefined reference to `ucol_strcoll_44' /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so: undefined reference to `ucol_open_44' /home/leandro/Qt5.0.0beta/Desktop/Qt/5.0.0-beta/gcc/lib/libQtCore.so: undefined reference to `ucol_getAttribute_44' collect2: ld returned 1 exit status make: ** [project] Erro 1 My linux distribution is Ubuntu 12.04 and I have libicui18n installed, but version 48 not 44. Any clue? []s, Leandro. 2012/7/15 Leandro Melo de Sales > Hi, >Why the current installers directory > (http://releases.qt-project.org/digia/2012-07-14/) does not contain a > .dmg file for QtSDK? Maybe it happened an error while compiling Qt for > MacOS... > > -- > Leandro Melo de Sales > Professor at Institute of Computing at Federal University of Alagoas, > Brazil > PhD candidate in Computer Science > Pervasive and Embedded Computing Laboratory, UFCG > Twitter: @leandrosalesal > > "The warrior is strong in loyalty, intensity, determination, > initiative, persistence, courage and willpower. The warrior is light > in the soul, self-trust and compassion. The warrior is often called to > take the front when other cowardly make a step backwards. There are > warriors on the battlefields and in everyday life." > > > 2012/7/13 Leandro Melo de Sales : > > Ok... thanks. > > > > > > > > 2012/7/13 > >> > >> When using the links below, please ensure that you are not redirected to > >> URLs which has “origin.” prefixed. If you are on a > >> > >> http://origin.releases.qt-project.org/... > >> > >> URL, you are downloading from the “master” machine, and it will be slow. > >> Simply remove the “origin.” prefix, and you should be using the CDN, and > >> download the packages much much faster. > >> > >> > >> > >> We are not quite sure why this redirect is happening. > >> > >> > >> > >> -- > >> > >> .marius > >> > >> > >> > >> From: releasing-bounces+marius.storm-olsen=nokia@qt-project.org > >> [mailto:releasing-bounces+marius.storm-olsen=nokia@qt-project.org] > On > >> Behalf Of ext Turunen Tuukka > >> Sent: Thursday, July 12, 2012 9:00 AM > >> To: releas...@qt-project.org; development@qt-project.org > >> Subject: [Releasing] Experimental Qt 5 installers by Digia > >> > >> > >> > >> > >> > >> Hi All, > >> > >> > >> > >> As you know we have been working in close co-operation in the Qt Project > >> for making the installers for Qt 5 as well as the tools to create these. > >> > >> > >> > >> If you wish, you can take a look on the experimental installers we > create > >> at: http://releases.qt-project.org/digia/ > >> > >> > >> > >> Currently the installers are built each night from the latest stable Qt > 5 > >> and placed to the above mentioned location. If the build or packaging > fails, > >> then that installer is omitted. Though called beta1, these are currently > >> made with the latest Qt 5, which as we know has not yet reached beta > >> maturity. > >> > >> > >> > >> These are additional to the ones you can get from > >> http://releases.qt-project.org/qt5.0/beta-snapshots/ In essence these > should > >> be identical. While we cook with the same recipes, these are baked in > our > >> kitchen that has some differences to the Qt Project build machines. So > >> sometimes there are differences in the created installers as well. > Having > >> two different setups is good in verifying that the recipes really work > and
Re: [Development] The containers in the "containers" branch
Thiago Macieira said: > On quinta-feira, 26 de julho de 2012 13.27.16, Thiago Macieira wrote: > > I'll abandon all changes still open in one week. They're cluttering my > > dashboard. > > Uh... André has approved one commit and tried to stage it, but it failed. > Gerrit claims a conflict. > > Should be easy to fix... > > ... except that the commits are already rebased and there are no new commits > in that branch. Can someone check to see what we're doing wrong? > The conflict is with the staging branch (refs/staging/containers). That was 8141e34280a92088a527e0935765ad8ba8e92be8. It looks to me like the 'containers' branch has been used inconsistently with respect to CI, like somebody fast-forwarded it from 8141e34280a92088a527e0935765ad8ba8e92be8 to 7a0b8d580df8d6b0012d11f61299046682f4d18a rather than putting a merge commit through CI. Apparently, doing that will not automatically cause the staging branch to be updated. For future reference, whoever is bypassing the CI to change the SHA1 of a branch should also issue a command like this to update the staging branch: ssh -p 29418 codereview.qt-project.org gerrit staging-rebuild --project qt/qtbase --branch containers , which I have now done, fixing the conflict. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The containers in the "containers" branch
On quinta-feira, 26 de julho de 2012 13.27.16, Thiago Macieira wrote: > I'll abandon all changes still open in one week. They're cluttering my > dashboard. Uh... André has approved one commit and tried to stage it, but it failed. Gerrit claims a conflict. Should be easy to fix... ... except that the commits are already rebased and there are no new commits in that branch. Can someone check to see what we're doing wrong? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML TranslationLoader element?
Jeremy, Take a look here: - https://gitorious.org/cquick#more - a brain dump spec I am waiting for some free time (god I need more of that!) to finish, http://qt-project.org/groups/qt-contributors-summit-2011/wiki/CrowdQuick I'd be happy if people would join and help me get this up and running. My idea as well for localization is to element out texts etc and load them on demand , based perhaps on user's location or locale preference. I have a basic backend here: http://www.crowdquick.org/ , take a look at the code in gitorious, really not much but that is what I managed to pull so far with my very limited spare time. Currently I want to achieve a client that will be able to load QML off the cloud , I started modding this example but I got bery busy again so this got side wayed, this is relevant for that: - http://www.mail-archive.com/interest@qt-project.org/msg02744.html - http://doc.qt.nokia.com/4.7-snapshot/network-download.html I've started sanitizing the example so it could be usable as a utility class for cqclient but never finished due to time constraints. Your feedback and help appreciated! -Sivan On Mon, Jul 30, 2012 at 8:34 PM, Jeremy Lainé wrote: > I have found QML's network transparency very handy for loading whole UIs over > the network, it makes it possible for instance to have "live updates" to an > application provided all the changes happen on the QML side. However, once > internationalization comes into play, there's a catch: unless I'm mistaken > there's currently no way to load Qt's .qm translations straight from QML code. > > I was therefore thinking of adding a "TranslationLoader" QML element (along > the lines of FontLoader) which would have the following properties: > > - QUrl source: the URL to the .qm file > - enumeration status (Null / Ready / Loading / Error): the loader's status > > Any thoughts on such an addition, or on a better API? > > Jeremy > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- -Sivan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QML TranslationLoader element?
I have found QML's network transparency very handy for loading whole UIs over the network, it makes it possible for instance to have "live updates" to an application provided all the changes happen on the QML side. However, once internationalization comes into play, there's a catch: unless I'm mistaken there's currently no way to load Qt's .qm translations straight from QML code. I was therefore thinking of adding a "TranslationLoader" QML element (along the lines of FontLoader) which would have the following properties: - QUrl source: the URL to the .qm file - enumeration status (Null / Ready / Loading / Error): the loader's status Any thoughts on such an addition, or on a better API? Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QTest::mouseClick doesn't set QApplication::keyboardModifiers anymore
A testcase like the attached one, which sends a mouse event to a QWidget using
QTest::mouseClick, used to adjust QApplication::keyboardModifiers() in Qt4,
but doesn't do so anymore in Qt5.
It seems the code that changes modifier_buttons is now in
QGuiApplicationPrivate::processMouseEvent, which is not called by
QTest::mouseClick.
qapplication.cpp:2983 (which is called) says
// capture the current mouse/keyboard state
but it only captures the mouse state, not the keyboard state.
Should it capture keyboard state again, like in Qt4?
But the interesting thing in all this is that outside of unit tests, it's all
working fine (when I click on an actual widget,
QApplication::keyboardModifiers() is set).
So maybe the real fix would be that QTest::mouseClick works more like a real
mouse click, going via the QWindow first, before being sent to the
target QWidget? Not sure what this means exactly in terms of code changes
though.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
diff --git a/tests/auto/widgets/kernel/qwidget/tst_qwidget.cpp b/tests/auto/widgets/kernel/qwidget/tst_qwidget.cpp
index 1b4cacf..14a856d 100644
--- a/tests/auto/widgets/kernel/qwidget/tst_qwidget.cpp
+++ b/tests/auto/widgets/kernel/qwidget/tst_qwidget.cpp
@@ -387,6 +387,8 @@ private slots:
void touchEventSynthesizedMouseEvent();
+void keyboardModifiers();
+
private:
bool ensureScreenSize(int width, int height);
QWidget *testWidget;
@@ -9443,5 +9445,28 @@ void tst_QWidget::touchEventSynthesizedMouseEvent()
}
}
+class KeyboardWidget : public QWidget
+{
+public:
+KeyboardWidget(QWidget* parent = 0) : QWidget(parent), m_eventCounter(0) {}
+virtual void mousePressEvent(QMouseEvent* ev) Q_DECL_OVERRIDE {
+m_modifiers = ev->modifiers();
+m_appModifiers = QApplication::keyboardModifiers();
+++m_eventCounter;
+}
+Qt::KeyboardModifiers m_modifiers;
+Qt::KeyboardModifiers m_appModifiers;
+int m_eventCounter;
+};
+
+void tst_QWidget::keyboardModifiers()
+{
+KeyboardWidget* w = new KeyboardWidget;
+QTest::mouseClick(w, Qt::LeftButton, Qt::ControlModifier);
+QCOMPARE(w->m_eventCounter, 1);
+QCOMPARE(int(w->m_modifiers), int(Qt::ControlModifier));
+QCOMPARE(int(w->m_appModifiers), int(Qt::ControlModifier));
+}
+
QTEST_MAIN(tst_QWidget)
#include "tst_qwidget.moc"
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] how to reduce the relocation <-- Use static qt libraries
On segunda-feira, 30 de julho de 2012 08.54.20, lars.kn...@nokia.com wrote: > Hope they can agree at some point, so we can start using it. Until then it > would be great if we could have it as a configure option (off by default). That depends on what they agree on. If they agree on the GCC team's interpretation, we can use it. If they agree on the binutils team's interpretation, the option will be useless. Meanwhile, no action was taken and they're still generating code like they were 2 years ago (or more). That means sometimes the linker bails out saying that the code the compiler generated is wrong. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] how to reduce the relocation <-- Use static qt libraries
On Jul 30, 2012, at 10:34 AM, ext Thiago Macieira wrote: > On domingo, 29 de julho de 2012 10.12.50, song.7@nokia.com wrote: >>> After changed with _protected_ visibility, that kind of relocation is >>> reduced, but I still don't know why more R_ARM_RELATIVE relocation >>> introduced. >> Answer my own question, that is because the loading address of the module >> needs to be added to know actual address of each virtual functions. >> >> So for the qt(5), should we change all the exported symbol 's visibility to >> _protected_ ? Or is there still some exited use case to use _default_ >> visibility ? > > I have a pending patch that turns all Qt relocations to "protected". However, > it cannot be enabled by default since it often runs into bugs in the linker. > Protected visibility seems not to be tested properly, as the compiler and > linker people have different interpretations on how it should be used. Hope they can agree at some point, so we can start using it. Until then it would be great if we could have it as a configure option (off by default). Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] how to reduce the relocation <-- Use static qt libraries
On domingo, 29 de julho de 2012 10.12.50, song.7@nokia.com wrote: > > After changed with _protected_ visibility, that kind of relocation is > > reduced, but I still don't know why more R_ARM_RELATIVE relocation > > introduced. > Answer my own question, that is because the loading address of the module > needs to be added to know actual address of each virtual functions. > > So for the qt(5), should we change all the exported symbol 's visibility to > _protected_ ? Or is there still some exited use case to use _default_ > visibility ? I have a pending patch that turns all Qt relocations to "protected". However, it cannot be enabled by default since it often runs into bugs in the linker. Protected visibility seems not to be tested properly, as the compiler and linker people have different interpretations on how it should be used. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
