Re: [Development] Notes of the QSetting session at DevDays meeting
On Tue, Nov 1, 2011 at 1:35 AM, Andreas Hartmetz ahartm...@gmail.com wrote: - KConfig code reuse possible? No: QtCore code can't be LGPL, and too many authors for relicensing! QtCore code can't be LGPL? Please elaborate. Cheers, Frans ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Installing Qt5Config.cmake from the Qt repo?
On Tuesday, November 01, 2011 15:49:27 Thiago Macieira wrote:
On Tuesday, 1 de November de 2011 15:44:18 Stephen Kelly wrote:
find_package(Qt5 REQUIRED Core Gui Widgets)
include(${Qt5_USE_FILE})
add_library(itemmodels SHARED ${itemmodels_SRCS})
target_link_libraries(itemmodels
${Qt5Core_LIBRARY}
${Qt5Gui_LIBRARY}
${Qt5Widgets_LIBRARY}
)
Where's the include_directories call?
if that's hidden in that ${Qt5_USE_FILE}, can you have different use-files
per target? For example, a test associated with that library above will
need to include and link to QtTest.
Yes, the include_directories call is hidden in the use file. The Qt5Use.cmake
file looks like this:
foreach(_USE_FILE ${Qt5_USE_FILES})
include(${_USE_FILE})
endforeach()
Qt5_USE_FILES is a variable populated by Qt5Config.cmake. It is a list of use
files resulting from the call to find_package. That is
find_package(Qt5 COMPONENTS Core DBus Test)
creates a Qt5_USE_FILES list which contains the use files Qt5CoreUse.cmake,
Qt5DBusUse.cmake and Qt5TestUse.cmake.
This also means that instead of
include(${Qt5_USE_FILE})
you can use
include(${Qt5Core_USE_FILE})
include(${Qt5DBus_USE_FILE})
include(${Qt5Test_USE_FILE})
Also, instead of
find_package(Qt5 REQUIRED Core Gui Widgets)
you can use:
find_package(Qt5Core)
find_package(Qt5Widgets)
find_package(Qt5Gui)
It is completely granular. Qt5Config.cmake and Qt5Use.cmake are just simple
aggregators as discussed.
Thanks,
--
Stephen Kelly step...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-10481: Adding support for DNS SRV lookups
Hi, On Tue, Nov 1, 2011 at 4:15 PM, Jeremy Lainé jeremy.la...@m4x.org wrote: While we are on the topic of the API, one thing which needs to be adressed is the kind of handle (if any) we return for asynchronous lookups: - QHostInfo::lookupHost() returns an integer - QDnsServiceInfo::lookupService() currently doesn't return anything If I recall correctly, Thiago was not happy with returning an integer, stating a more modern API should be used. Are we talking about replacing QDnsServiceInfo with a QDnsServiceReply* ? Pro: it's consistent with QNAM. Con: we place the burden of freeing memory on the user. How about returning a QSharedPointerQDnsServiceReply then? Pro: Using the right shared pointer immediately makes clear who is the owner of the object in question. In this case: whoever holds on to the pointer the longest. Con: this is not currently used in Qt APIs. Andre ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtsystems doesn't compile - mtcore mandatory dependency
Hi,
Yes, the screen saver for Linux needs to be fixed, and it's on my todo list.
For the MAC implementation, I already have some code locally, but they're not
properly tested yet, so I don't want to publish them now...
Xizhi Zhu (Steven)
Software Engineer @ Qt Development Frameworks
Nokia
Mobile: +358 (0)50 480 1247
From: development-bounces+xizhi.zhu=nokia@qt-project.org
[development-bounces+xizhi.zhu=nokia@qt-project.org] on behalf of ext
Thiago Macieira [thi...@kde.org]
Sent: Tuesday, November 01, 2011 4:44 PM
To: development@qt-project.org
Subject: Re: [Development] qtsystems doesn't compile - mtcore mandatory
dependency
On Tuesday, 1 de November de 2011 15:06:57 Robin Burchell wrote:
!contains(QT_CONFIG, jsondb): {
PRIVATE_HEADERS += qscreensaver_linux_p.h
SOURCES += qscreensaver_linux.cpp
DEFINES += QT_NO_JSONDB
} else {
PRIVATE_HEADERS += qjsondbwrapper_p.h \
qscreensaver_jsondb_p.h
SOURCES += qjsondbwrapper.cpp \
qscreensaver_jsondb.cpp
QT += jsondb
PKGCONFIG += mtcore
LIBS += -L$$[QT_INSTALL_PREFIX]/opt/mt/lib -lmtcore
-Wl,-rpath,$$[QT_INSTALL_PREFIX]/opt/mt/lib
}
Whoever maintains this, you should probably change that contains()
conditional to also check packagesExist(mtcore). For an example, see:
I'm not sure that's the proper solution.
Look at the files it's turning off because jsondb was found: the screensaver
files. I have no clue what a database has to do with screensavers, but I doubt
my KDE will react to it, so the proper solution is to fix
qscreensaver_linux.cpp.
And now I've looked at qscreensaver_linux.cpp. First of all, it should be
called qscreensaver_x11.cpp, since it's an X11 implementation. Second, in
Qt 5, there's no more Q_WS_X11, so this code will never work. It needs to be
replaced with a QPA equivalent, getting the name of the QPA plugin loaded at
runtime (like we discussed) and do the proper thing.
At minimum, this file needs to be qscreensaver_unix.cpp and deal with X11/XCB
and Wayland, plus the Mac and Windows implementations. Also note a Mac
implementation (a reference platform) is missing.
I have no clue what the jsondb implementation is for, but it looks extremely
non-standard to me. If anyone wants it, they should set a flag when compiling
qtsystems. The default should be to use the QPA solutions.
It seems to me we have two tasks here. The first is a P0, to fix the build. The
second is a P1, to implement the functionality for the reference platforms.
I'll create those tasks tomorrow.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] proposing Richard Moore as approver
I second this nomination, based on the quality of code reviews and technical discussion I have seen. -Original Message- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Thiago Macieira Sent: Tuesday, November 01, 2011 16:08 To: development@qt-project.org Subject: Re: [Development] proposing Richard Moore as approver On Tuesday, 1 de November de 2011 16:00:30 Peter Hartmann wrote: Hello, hereby I would like to propose Richard Moore as approver for the Qt project. Rich has made numerous high-quality commits to the Qt SSL code and knows Qt very well, being a KDE contributor since the very beginning. Shane Kearns and Martin Petersson second this proposal. It would be better if they could post to the mailing list voicing their approval, Not that I doubt that you talked to them, but just in case... Just to add that I also second his nomination. Please raise any concerns you might have about this until 22nd of November 2011 (see the guide lines at http://wiki.qt- project.org/The_Qt_Governance_Model#How_to_become_an_Ap prover ). -- 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 This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Installing Qt5Config.cmake from the Qt repo?
On Tuesday 01 November 2011 15:44:18 ext Stephen Kelly wrote: == Clarification == To avoid misunderstanding: * This proposal is not about porting the Qt build system to CMake. * This would not make Qt depend on CMake at all * I am proposing to add some plain text files to the Qt repo for installation * Those plain text files would need to be generated while building Qt (using existing mechanisms, like perl). In the branch, I do depend on cmake at configure-time to generate the Targets files. These are platform specific files that cmake uses to build against libraries in debug and release versions. I would like to add this non-optional configure time dependency on cmake to Qt. This seems to invalidate the initial Clarification as it _does_ make building Qt from source depending on cmake. That's not so much an issue on Linux, where it's easy to install cmake from the distribution, but it _is_ an issue on e.g. Windows where there is no proper package management available, and cause extra effort for e.g. the SDK maintainers or for the random non-cmake using user of Qt on Windows who compiles himself. Don't get me wrong. I have no problems with adding a few files to Qt that make the life of cmake users easier. But maintainance has to be done by the people introducing these files, not by imposing additional burden on others. The alternative would be to maintain Targets files for multiple platforms by generating those files at maintenance time (ie, running the script to generate them, copy the result into place and check it in). This maintenance burden is not really justifiable. The CMake dependency is already available where Qt is available. Qt does not depend on cmake _anywhere_. The fact that cmake is _available_ does not mean depending on it is free. Depending on CMake would also mean that I could use configure_file() and file(WRITE ...), which would make the stuff work across platforms already (currently it depends on sed being available). So I would be able to clean up the branch considerably. Additionally, it would be easier to create a similar Config.cmake file for Qt libraries outside of qtbase.git (such as QtWebKit) as I could simply install the Qt5BasicConfig.cmake from qtbase and use it from the other repos. I would make this dependency on CMake non-optional because it is important to be able to use find_package(Qt5) without having to care about whether the person who built it had cmake installed at the time. find_package(Qt5) needs to work for each Qt5 build, so the config files need to be all the time. Let me know if this is acceptable for Qt. A non-optional dependency on cmake for Qt 5.0 is not acceptable from my perspective. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QPrintPreview: access to single pages
On Monday 31 Oct 2011 09:37:18 Giovanni Bajo wrote: Hi John, thank you very much for accepting to be the printer maintainer. Last year, we (Develer) proposed a patch that was rejected: http://qt.gitorious.org/qt/qt/merge_requests/733 We then opened a bug to discuss an alternative API to implement the features we require: https://bugreports.qt.nokia.com//browse/QTBUG-12168 (the two links above summarize our needs quite well) If we could agree on the API at least, we could move on and submit a new patch. Thanks! Hi Giovanni, Thanks for bringing this to my notice. I have to confess that QPrintPreview is something I haven't touched and so have little knowledge of and it is on my learning TODO list. I'll need to get up to speed there before I can comment on the proposal properly, but it does feel somewhat awkward to me. The big hurdle is that we don't really want to make any changes to the existing printing code in 5.0 other than the work done to split it into a separate module. We want to leave any significant changes for the new module in 5.1 or 5.2. That said, if the implementation is a single new method that doesn't change much of the existing code and doesn't change the existing api or its behaviour then I would consider it. The bug report mentions 2 points, 1) to Aquire a separate preview for each page and 2) the ability to print page subsets like 1,8,12. I can say now that 2) is not supported by Qt currently and will not be supported in QPrintSupport in 5.0 as it would require considerable changes to the existing code and api. It is a feature that will be in the new printing module though in 5.1/5.2 (in fact, it was writing patches to do this that led to my becoming maintainer). Will fixing 1) still be useful to you without 2)? Thanks again, and I'll try get back to you in the next week or two. John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtsystems doesn't compile - mtcore mandatory dependency
-Original Message-
From: development-bounces+alex.blasche=nokia@qt-project.org
[mailto:development-bounces+alex.blasche=nokia@qt-project.org] On
Behalf Of ext Robin Burchell
Sent: Wednesday, 2 November 2011 0:07
To: Thiago Macieira
Cc: development@qt-project.org
Subject: Re: [Development] qtsystems doesn't compile - mtcore mandatory
dependency
2011/11/1 Thiago Macieira thi...@kde.org:
I cannot find this mandatory dependency. If it's open, can someone share
the
link to where it can be found? If it's not open, please disable this
functionality.
I guess this might be a consequence of qtjsondb becoming available:
!contains(QT_CONFIG, jsondb): {
PRIVATE_HEADERS += qscreensaver_linux_p.h
SOURCES += qscreensaver_linux.cpp
DEFINES += QT_NO_JSONDB
} else {
PRIVATE_HEADERS += qjsondbwrapper_p.h \
qscreensaver_jsondb_p.h
SOURCES += qjsondbwrapper.cpp \
qscreensaver_jsondb.cpp
QT += jsondb
PKGCONFIG += mtcore
LIBS += -L$$[QT_INSTALL_PREFIX]/opt/mt/lib -lmtcore
-Wl,-rpath,$$[QT_INSTALL_PREFIX]/opt/mt/lib
}
Whoever maintains this, you should probably change that contains()
conditional to also check packagesExist(mtcore). For an example, see:
Thank you for pointing this out. Yes, the above logic is broken and will be
fixed shortly/was partly fixed last night.
--
Alex
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Optional Qt module dependencies (was: RE: qtsystems doesn't compile...)
-Original Message- From: development-bounces+alex.blasche=nokia@qt-project.org [mailto:development-bounces+alex.blasche=nokia@qt-project.org] On Behalf Of ext Rohan McGovern Incidentally it's rather dangerous to do this kind of contains(QT_CONFIG,some_module):QT+=some_module ...behavior nowadays. In Qt4, QT_CONFIG would be decided at configure time, but in Qt5 it can be changed when you qmake additional modules. In other words, if you test contains(QT_CONFIG,some_module) in your Qt5 module, you've made your build behavior implicitly depend on the order in which the user happened to run `qmake' over the qt5 modules, which is largely undefined. e.g. if you are doing a `make -j20' in qt5.git, the qmakes are also parallelized, and your result might flipflop between builds. Surely there must be a way of enforcing dependencies between Qt modules. How would somebody create such a dependency? Is it a matter of mentioning it in sync.profile? Note that the dependency might be platform specific on and currently I don't see a way of specifying it in syn.profile. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
