Re: [Development] Moving itemmodels classes to QtCore
On Monday, December 05, 2011 15:28:36 Thiago Macieira wrote: On Monday, 5 de December de 2011 21.23.04, Stephen Kelly wrote: $ size libQtCore.so.5.0.0 textdatabss dec hex filename 3543451 74688 5080 3623219374933 libQtCore.so.5.0.0 And after compiling them into QtCore: $ size libQtCore.so.5.0.0 textdatabss dec hex filename 3714394 78272 5080 3797746 39f2f2 libQtCore.so.5.0.0 The data size increased by 4k. Can you run the attached script too, please? Before: stephen@hal:~/dev/build/qtbase/qtbase/lib$ size libQtCore.so.5.0.0 textdata bss dec hex filename 3542594 747525048 3622394 3745fa libQtCore.so.5.0.0 ./relinfo.pl libQtCore.so.5.0.0 libQtCore.so.5.0.0: 4037 relocations, 1813 relative (44%), 2562 PLT entries, 2562 for local syms (100%), 0 users After: stephen@hal:~/dev/build/qtbase/qtbase/lib$ size libQtCore.so.5.0.0 textdata bss dec hex filename 3725848 789205048 3809816 3a2218 libQtCore.so.5.0.0 stephen@hal:~/dev/build/qtbase/qtbase/lib$ ./relinfo.pl libQtCore.so.5.0.0 libQtCore.so.5.0.0: 4326 relocations, 1855 relative (42%), 2746 PLT entries, 2746 for local syms (100%), 0 users -- 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
[Development] What about including serial port support component to Qt?
Hello, developers. We want to provide a library QSerialDevice v 2.0 to work with serial ports: https://gitorious.org/qserialdevice/qserialdevice/trees/2.0 We would like to include it as a separate module for Qt. The implementation of the library is closely linked to the internal architecture of Qt and uses some private classes Qt. We want to know: Is there interest in this subject, and find like-minded in its development? At present, the library has two classes of SerialPort and SerialPortInfo. So what we have: Class SerialPort - full-fledged support for OS Windows, WinCE, POSIX-compatible. Partially implements the interface for OS Symbian. As a basis of the SerialPort was taken QAbstractSocket, therefore, their implementation is somewhat similar. Class SerialPortInfo - fully supports OS Windows, WinCE, GNU/Linux, MacOSX, other * nix (simplified), Symbian. As a basis of the SerialPortInfo was taken QPrinterInfo, therefore, their implementation is somewhat similar. For all class added comments in QDoc style. What else is needed make: 1. Implement SerialPort support in OS Symbian. 2. Make a proper configuration for documentation generation. 3. Make the correct configuration to build the project. 4. Correct spelling errors in comments. If you're interested to include it into reguar Qt stuff - please let me know Thanks kuzulis ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork changes from QtDD SF 2011
On 12/06/2011 12:32 AM, ext Thiago Macieira wrote: (...) The cache, however, could be an issue. Imagine I do a get() from an auxiliary thread, one that the QNAM and the cache are not affined to. The implementation would need to read from the cache in one thread and make the data available to the user, in the QNetworkReply, in another thread. Another interesting thing to note is that AFAIU with WebKit 2 there can be multiple web processes per application, all using the same cache (and cookie jar), so we would need to make the cache usable by several applications at the same time. Maybe Webkit people can elaborate or know how other ports do that... Peter This would, however, make a clean solution. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: [Marketing] FOSDEM Qt Project
For your information, forwarding here since I'm not sure everybody interested is aware of the new marketing list - and this topic requires a fast response. Forwarded message From: Gil Quim (Nokia-SD/SiliconValley) [quim@nokia.commailto:quim@nokia.com] Date: Mon Dec 5 16:55:38 2011 To: market...@qt-project.orgmailto:market...@qt-project.org Cc: Subject: [Marketing] FOSDEM Qt Project Hi, this is the first call to this mailing list: we have a week to decide the fundamentals of what we do at FOSDEM. Brussels, Feb 4-5 http://forsdem.org We seem to have missed the chance to submit a session to the main track. Pity, because I bet a Qt Project introduction spiced up with the last developments of Qt 5 + demo would have been gladly received by that audience. Still, there are good chances to be active in FOSDEM: Call for stands http://fosdem.org/2012/call-for-stands Is there interest and critical mass to man properly a booth? Call for Lightning Talks http://fosdem.org/2012/call-for-lightningtalks Who can submit a proposal to pitch the Qt Project and/or Qt 5? ... and the DevRooms. DevRooms are still receiving proposals, and as far as I know each one is organized quite autonomously. The list of DevRooms can be found at http://fosdem.org/2012/devrooms_for_2012 We have good contacts at Cross Desktop and Open Mobile Linux. Other DevRooms might be interested in Qt related content since we really don't fit in only one place e.f. Embedded or Open Source Game Development. Also, if there is critical mass we could aim to organize a Qt Contributors Day e.g. on Feb 3rd (Friday, with time to reach the Fosdem Beer Party) ;) Thoughts? Volunteers? -- Quim ___ Marketing mailing list market...@qt-project.org http://lists.qt-project.org/mailman/listinfo/marketing ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] What about including serial port support component to Qt?
On 06/12/2011 06:47, ext lars.kn...@nokia.com wrote: support for serial ports makes sense as a Qt add-on, and I'd be a great addition to Qt and the Qt project. The legal requirement for adding it at qt-project.org is that the contributors (looks like that's you and two others) sign the contribution agreement (see http://qt-project.org/legal.html). Actually, signing that agreement is for future contribution. For moving an existing project into Qt Project, there needs to be signing of a separate CLA, based on the same Contribution Agreement, but with extra wording to cover the previous work done in the project. The the proper process to handle project migrations is coming together, and we should have it up and running soon. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork changes from QtDD SF 2011
On Dec 6, 2011, at 12:40 PM, Thiago Macieira wrote: On Tuesday, 6 de December de 2011 12.24.11, Peter Hartmann wrote: Another interesting thing to note is that AFAIU with WebKit 2 there can be multiple web processes per application, all using the same cache (and cookie jar), so we would need to make the cache usable by several applications at the same time. Maybe Webkit people can elaborate or know how other ports do that... That's a slightly different problem. With WebKit 2, we have different processes, so different instances of QAbstractNetworkCache. The problem then is not to make the class be thread-safe, but to make the cache methodology be multi- process-safe. Yes, that's what we need. For example, you cannot use QMutex. You need to make it safe against another process reading or writing to the cache at the same time without using the normal threading primitives. Exactly. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork changes from QtDD SF 2011
On Dec 5, 2011, at 4:50 PM, Jeff Mitchell wrote:
Hello,
Hi,
I was asked to put this information on the wiki, but wasn't actually
sure where the correct place was to do it. I'll put the info here and it
can be moved into the wiki later.
At the Contributor Day in San Francisco, a number of people met to
discuss some of the issues involving QtNetwork, espcially
QNetworkAccessManager (QNAM). The overall idea is that eventually
QNetworkAccessManager, which is meant to generally be
one-per-application, must be made thread-safe in order to fulfill this
desired use.
Here are the notes from the discussion:
Long term: QNAM needs to be thread-safe (and each QNAM will be in its
own thread)
* As a result so does the cookie jar and disk cache (and these would not
moveToThread())
* After that, implement QNAM::setApplicationNetworkAccessManager()
* QML can stop using multiple QNAMs and QNetworkProxyFactories (QNPFs) too.
Disk cache:
* Get implementation from somewhere which is good enough for most
applications
* Set caching on by default: no
Cookie jar:
* Get Alexi to redesign the API
I had a chat with Peter about that.
What QtWebKit need is (though we already implemented it, work-arounding the
current issues) :
- setCookieFromUrl to not be magic. It may removes/update cookies and therefore
If I implement a persistent storage it would be nice to know what is
added/removed/updated from the internal list.
- I need some hooks whenever something is added/removed/updated from the
internal list of cookie stored by QNetworkCookieJar. Basically all the black
magic done by QNetworkCookieJar, I need to know about it so I can update
accordingly where I store my cookies (read a SQL database). I was thinking that
a couple of virtual method should be fine, for example :
void writeCookie(const QNetworkCookie foo) {
// Store into my database
// Call the base class.
QNetworkCookieJar::write(cookie);
}
The base class just adding it into the list.
- Maybe put the security filtering into a separate virtual function (to make
setCookieFromUrl less magical, even if the latter will call that function).
Make the API looks nicer to me.
In the ideal world an add-on of Qt should give the possibility to have a
persistent storage built in (Mac OS has an API cross OS/apps for that) for
example a subclass of QNetworkCookieJar which already implement a SQL storage
for example.
* Need a default persistent cookie jar: possibly?
* Talk to WebKit guys, see if we can make an addon based on their cookie jar
Application proxy:
* Use system proxy by default
System proxy config:
* Global proxy config needs to be in network manager/connection manager
so there is a known place to fetch it before system proxies can be
supported on non-Windows/MacOS
QNetworkProxyFactory:
* queryProxy() needs to be documented that it must be thread-safe
* proxyForQuery(): unlock mutex before calling user code
QSharedPointer:
* Use for all three (disk cache, cookie jar, qnam) so that the user can
keep a ref around if they want (also for the static methods)
* Make QSharedPointer be able to delete properly with a forward declaration
* QObject::connect needs to be able to take a QSharedPointerQObject
* QObject::connect needs to be able to take a QWeakPointerQObject
Ultra long term (Qt6): Fix QIODevice to do zero-copy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork changes from QtDD SF 2011
On Tue, Dec 6, 2011 at 1:43 PM, Alexis Menard alexis.men...@openbossa.orgwrote: On Dec 6, 2011, at 12:40 PM, Thiago Macieira wrote: On Tuesday, 6 de December de 2011 12.24.11, Peter Hartmann wrote: Another interesting thing to note is that AFAIU with WebKit 2 there can be multiple web processes per application, all using the same cache (and cookie jar), so we would need to make the cache usable by several applications at the same time. Maybe Webkit people can elaborate or know how other ports do that... That's a slightly different problem. With WebKit 2, we have different processes, so different instances of QAbstractNetworkCache. The problem then is not to make the class be thread-safe, but to make the cache methodology be multi- process-safe. Yes, that's what we need. For example, you cannot use QMutex. You need to make it safe against another process reading or writing to the cache at the same time without using the normal threading primitives. Exactly. Sorry if this is a stupid point, but there is a pretty standard mechanism for multiprocess mutexes in the form of .lock files. Isn't this an obvious and acceptable solution(to that part of the issue)? They have the same up/down sides of actual mutexes. Gastal. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork changes from QtDD SF 2011
On Tuesday, 6 de December de 2011 13.56.18, Jonas Gastal wrote: Sorry if this is a stupid point, but there is a pretty standard mechanism for multiprocess mutexes in the form of .lock files. Isn't this an obvious and acceptable solution(to that part of the issue)? They have the same up/down sides of actual mutexes. Yes, it is, provided you do the lock file operations correctly (which isn't a given). I was just saying that you can't use QMutex. You need to use a different kind of mutex. -- 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] Antwort: Building Qt5 for embedded Linux ARM
On Tuesday, 6 de December de 2011 17.02.46, Dietrich.Gossen@continental- corporation.com wrote: Hi Thiago, thank you for your help. Freescale (the manufacturer of the iMX53 Board) provides an Ubuntu image for the board. So the OS is already running. All I need is to cross compile Qt5 for ARM. Also, there's a toolchain available that contains a compiler. This compiler is the arm-none-linux-gnueabi-gcc. Good, but the compiler alone isn't enough. We need a couple more things: My problem right now is, that during the building process of Qt5, the linker can't find some libraries. Output.txt (attached file) contains the output and the errors of the build. These are the headers that the linker couldn't find: Those aren't it. Those errors you got from configure -v are simply telling you that the compiler searched for those libraries and couldn't find them. The corresponding functionality was either disabled (PulseAudio, ICU, some SQL drivers) or the in-tree copy was enabled (tiff, sqlite). Nothing to worry about, unless you want to have the functionality that was disabled. Additionaly the arm-none-linux-gnueabi-g++ compiler does not recognize the following arguments: -mmx -m3dnow -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx Those are non-issues. That's just the configure -v output telling you that it tried those arguments to gcc and found out that it doesn't support them. That's to be expected: your ARM compiler will not support the x86 extensions. -lxcb This one means you don't have your development package for libxcb installed. If you want to use the XCB backend for Lighthouse, you need to install that library. Any ideas? The actual problem was the last one in your output file. Since the XCB library could not be found, the OpenGL ES test failed too, which means Qt could not be built. I don't know if the OpenGL ES test should be trying to link to XCB or not, that's a question for the people who wrote that test. -- 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 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] QtNetwork changes from QtDD SF 2011
On 12/06/2011 11:09 AM, Thiago Macieira wrote: On Tuesday, 6 de December de 2011 13.56.18, Jonas Gastal wrote: Sorry if this is a stupid point, but there is a pretty standard mechanism for multiprocess mutexes in the form of .lock files. Isn't this an obvious and acceptable solution(to that part of the issue)? They have the same up/down sides of actual mutexes. Yes, it is, provided you do the lock file operations correctly (which isn't a given). Right -- that's why Python's lockfile uses link operations on *nix but mkdirs on Windows. And various mechanisms may or may not work on various other file system types (FUSE filesystems, various types of networked filesystems, etc.) It's not an easy task. --Jeff ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Call for Volunteers: SSO-improvements for qt-project.org
On Wed, Dec 7, 2011 at 2:28 AM, Jeff Mitchell q...@jefferai.org wrote: At Qt Contributor Day in SF I talked to Alexandra Leisse about MediaWiki. Specifically, she hates MediaWiki, and I suggested moving to Confluence, as it's a much, much, much, much nicer wiki than MediaWiki, I think this is a tiny bit overly hasty, considering we already have someone who has started to help get MediaWiki into shape for us. I'm also not the world's greatest fan of open projects tying themselves to tooling with commercial/restrictive licenses. Qt already has this to some degree, and it's something I'm not overly keen to see expand without very good reason. $0.02, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Missing ARM, MIPS, other mkspecs in qt5
Thiago Macieira said: On Wednesday, 30 de November de 2011 15.47.00, Rohan McGovern wrote: Hello, In Qt5, we no longer appear to have any mkspecs for cross-compiling for ARM or MIPS. They were tied up with qws, so they were removed when qws was removed. Is it intentional that we still don't have any, or has it just fallen out that way and we're free to add some generic ARM, MIPS mkspecs for testing purposes? mkspecs for cross-compilation are ill-suited, because the compiler name changes a lot. A better solution would be to make those configure-time options and simply use the standard mkspec for the platform. I guess that until such time as a proper build system is in place for Qt, we'll have to make do though. A linux-arm-gnueabi-g++ mkspec was added, which is identical to a linux-g++ mkspec except for the compiler commands. The next issue we hit in testing is that a standalone cross-compiler does not provide any GL API, which is nowadays required to compile Qt. We did not want to use some vendor-specific GL (or couldn't due to licensing), so we're now using a cross-compiled mesa (packaged at https://launchpad.net/~rohanpm/+archive/qtqa-cross ). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
