Re: [Development] Qt 5 and old versions of XCB

On 18/03/2012, at 5:46 PM, Thiago Macieira wrote: I asked about xcb on the LSB mailing list and early responses suggest that although xcb has been mentioned there before, it doesn't sound like it's progressed much beyond that. Dropping support for xlib and relying on xcb would thus make Qt5 a non

Re: [Development] Qt 5 and old versions of XCB

>> >> >> >>Every Linux distro uses X.org, which uses XCB. >> >> >> >> Including openSUSE 11.1, but just any XCB is not enough. It needs to be >>more recent than some version. For users with an incompatible version of >>XCB, I think we can provide a better user experience than hitting >>compiler er

Re: [Development] Qt 5 and old versions of XCB

On 18/03/2012, at 12:03 PM, Robin Burchell wrote: > On Sun, Mar 18, 2012 at 1:43 AM, wrote: >> I asked about xcb on the LSB mailing list and early responses suggest that >> although xcb has been mentioned there before, it doesn't sound like it's >> progressed much beyond that. Dropping suppor

Re: [Development] Qt 5 and old versions of XCB

On 18/03/2012, at 11:53 AM, Thiago Macieira wrote: > On domingo, 18 de março de 2012 11.43.02, craig.sc...@csiro.au wrote: >> That's fine when you are only building an application to run on your >> machine, but for people who want to distribute Qt5 apps, this would be an >> undesirable solution.

Re: [Development] Qt 5 and old versions of XCB

On 18/03/2012, at 9:58 AM, Pier Luigi wrote: > 2012/3/17 Bradley Smith : >> >>> The workaround for systems that don't meet the minimum requirements is to >>> upgrade. Running brand, new and bleeding edge Qt 5 on an old system is not >>> a >>> target for us. Simply upgrade -- at the very least th

Re: [Development] Changing qreal to a float

On 20/02/2012, at 1:29 PM, Lincoln Ramsay wrote: > On 02/17/2012 09:58 PM, ext lars.kn...@nokia.com wrote: >> On the idea itself I'd like to hear some more opinions. Removing qreal >> would cause some SC breakage, but you would also get a compile error on >> places that could break. Unfortunately

Re: [Development] Changing qreal to a float

On 15/02/2012, at 8:58 PM, wrote: > On 2/15/12 10:28 AM, "ext Thiago Macieira" > wrote: > >> On quarta-feira, 15 de fevereiro de 2012 08.49.31, lars.kn...@nokia.com >> wrote: >>> I don't think it'll break too many places though, so I'm not too worried >>> about the change. >> >> It will. Ask

Re: [Development] RFC: The Future of QDoc

On 10/02/2012, at 5:13 AM, mailto:marius.storm-ol...@nokia.com>> mailto:marius.storm-ol...@nokia.com>> wrote: I think there are a few issues here: 1) Only Dimitri touches Doxygen code, and it doesn't look like contributions go in (at least not under the authors name). This means that the funct

Re: [Development] RFC: The Future of QDoc

On 11/02/2012, at 12:47 AM, André Somers wrote: My suggestion would be this: 1) If possible, documentation goes right above the relevant code (implementation or declaration) 2) Prefer the implementation over the declaration when you have to choose 3) If neither is possible, prefer the implementat

Re: [Development] Dropping QT_NO_STL

From: "lars.kn...@nokia.com" mailto:lars.kn...@nokia.com>> Date: 2 February 2012 4:49:45 AM AEDT To: "thiago.macie...@intel.com" mailto:thiago.macie...@intel.com>>, "development@qt-project.org" ma

Re: [Development] Work on qDebug and friends

Sorry for the lack of context (dealing with digest emails while on leave :-P ). With the talk about logging in this thread, is it of interest / scope to also have the associated classes support capturing the standard C/C++ streams? By this, I mean capturing whatever gets logged via std::cout or

Re: [Development] QFile: writing via a temporary file

On 09/01/2012, at 10:14 PM, Oswald Buddenhagen wrote: > On Fri, Jan 06, 2012 at 07:13:00PM -0200, ext Thiago Macieira wrote: >> On Friday, 6 de January de 2012 21.27.20, David Faure wrote: >>> Exception handling is a new argument though. But doesn't the current QFile >>> have the exact same issu

Re: [Development] API review for a new QDnsResolver class

On 07/01/2012, at 4:46 AM, Jeremy Lainé wrote: >> - finalise the class name (I think QDns was suggested) >> > > Could we get this point settled once and for all? My suggestions: > > - QDnsLookup (my preferred one, as the object represents a lookup and its > result) +1 Says exactly what the

Re: [Development] QFile: writing via a temporary file

On 06/01/2012, at 10:32 AM, David Faure wrote: > On Friday 06 January 2012 10:24:04 craig.sc...@csiro.au wrote: >> I like the idea that if nothing goes wrong, then close() commits the changes >> (ie renames the temporary file to the real file name). It makes using a >> QFile with this feature ver

Re: [Development] QFile: writing via a temporary file

On 06/01/2012, at 10:13 AM, David Faure wrote: > On Thursday 05 January 2012 22:21:54 Richard Moore wrote: >> 2012/1/5 David Faure : >>> Solution 2: how about making this functionality part of QFile itself? >>> No need to "port to another class" anymore, just enable the safety feature >>> by call

Re: [Development] API review for a new QDnsResolver class

On 05/01/2012, at 12:11 PM, Thiago Macieira wrote: > On Thursday, 5 de January de 2012 12.07.37, craig.sc...@csiro.au wrote: >> On 05/01/2012, at 11:47 AM, Thiago Macieira wrote: >>> On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote: This could be perceived as creating a

Re: [Development] API review for a new QDnsResolver class

On 05/01/2012, at 11:47 AM, Thiago Macieira wrote: > On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote: >> This could be perceived as creating a race condition. You'd have to connect >> a slot to the signal on the object returned, but what if the signal is >> emitted before y

Re: [Development] API review for a new QDnsResolver class

On 05/01/2012, at 3:51 AM, Jeremy Lainé wrote: > Replying to myself to try and get the discussion going again. > > A summary of API decisions so far: > > - we only provide an asynchronous API > > - we do not want a "manager" object (QNAM-style) to avoid users creating a > manager per lookup >

Re: [Development] Possible bug in signals and slots handling in QML.

Starting a signal name with an underscore could be viewed as a violation of the C++ standard, depending on how you interpret it. Item 17.4.3.1.2 in the standard reserves names beginning with an underscore as for use only by the implementation (ie the compiler): "17.4.3.1.2 Global names Certain

Re: [Development] Hacking guide for Qt's SSL Support

On 03/01/2012, at 11:27 AM, Thiago Macieira wrote: > On Tuesday, 3 de January de 2012 10.57.11, craig.sc...@csiro.au wrote: >> Unfortunately, OpenSSL is not part of the LSB, so if you want SSL support on >> linux and you want your application to be LSB compliant, you end up having >> to link in t

Re: [Development] Hacking guide for Qt's SSL Support

On 02/01/2012, at 11:06 PM, Richard Moore wrote: > On Sun, Jan 1, 2012 at 3:51 PM, Andreas Aardal Hanssen > wrote: >> Hi Richard, looks really good! For Qt 4, the idea was to have several >> backends like you write here. Still we ended up with only one, and it's not >> really that much of a well

[Development] QMetaType templates

Given Jedrzej's recent post on QMetaType, it sounds like there are people looking at QMetaType in a bit more detail at the moment. That being the case, I'd appreciate a few more opinions on QTBUG-15313 which I believe was closed prematurely. The brief version is that I suggested that the documen

Re: [Development] Patches in JIRA (Was: (no subject))

On 21/12/2011, at 6:16 PM, Alan Alpert wrote: > On Wed, 21 Dec 2011 16:52:54 ext craig.sc...@csiro.au wrote: >> On 21/12/2011, at 5:14 PM, Robin Burchell wrote: >>> On Wed, Dec 21, 2011 at 2:57 AM, wrote: On 21/12/2011, at 12:19 PM, > wrote: > Posting patches to the JIRA bugreportin

Re: [Development] (no subject)

On 21/12/2011, at 5:14 PM, Robin Burchell wrote: > On Wed, Dec 21, 2011 at 2:57 AM, wrote: >> >> On 21/12/2011, at 12:19 PM, >> wrote: >> >>> Posting patches to the JIRA bugreporting system is contrary to the terms of >>> use for that system. >>> https://bugreports.qt.nokia.com/secure/Ter

Re: [Development] (no subject)

On 21/12/2011, at 12:19 PM, wrote: > Posting patches to the JIRA bugreporting system is contrary to the terms of > use for that system. > https://bugreports.qt.nokia.com/secure/TermsAndConditions.html > Don't do this. I know I'll probably be shot down immediately, but. This is one of the

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

On 16/12/2011, at 10:37 PM, David Faure wrote: > On Thursday 15 December 2011 11:21:41 Turunen Tuukka wrote: >> So now there is total of 108 improvements and bug fixes available in Qt >> Commercial 4.8.0 that are not part of the LGPL release. > > While I understand the reasons, I want to state t

Re: [Development] How to create new Qt modules or tools

On 13/12/2011, at 12:09 AM, wrote: > What is it that you require to upload the results to a cdash, and why > wouldn't qmake be able to do so? > I thought cmake simply ran cdash to upload the results, and certainly qmake > can easily add the rules for doing the same? I guess it would be pos

Re: [Development] How to create new Qt modules or tools

On 12/12/2011, at 4:59 PM, Rohan McGovern wrote: > Laszlo Papp said: >> >> 1) Build and software testing service >> Is there a build and software testing service provided for projects in >> the Qt Playground repositories ? I have not seen any mentionings about >> that so far. and it is an import

Re: [Development] Call for Volunteers: SSO-improvements for qt-project.org

On 07/12/2011, at 5:37 PM, Robin Burchell wrote: > On Wed, Dec 7, 2011 at 2:28 AM, Jeff Mitchell 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 nic

Re: [Development] Regular expression libraries for QRegExp

On 22/11/2011, at 9:55 PM, Thiago Macieira wrote: > On Tuesday, 22 de November de 2011 09.58.02, lars.kn...@nokia.com wrote: >> A IMO better solution would be to have a repository called e.g. qtsupport >> (KDE had something similar for quite a while) that contains copies to >> these 3rd party lib

Re: [Development] Regular expression libraries for QRegExp

On 22/11/2011, at 2:45 AM, Giuseppe D'Angelo wrote: > On 16 November 2011 16:08, wrote: >> Yes, the implementation based on UTF-8 vs UTF-16 version of PCRE would >> only differ on two lines, the UTF-16 -> UTF-8 and UTF-8 > UTF-16 >> conversion before and after the matching. >> >> I suggest we

Re: [Development] Platform / compiler support

It occurred to me after my previous email that people may not be aware of what the LSB compilers do, so let me provide just a little bit of info to explain why they should be considered explicitly in addition to plain GCC compilers. In a nutshell, when you build your app with the LSB compilers,

Re: [Development] Platform / compiler support

On 08/11/2011, at 9:06 PM, João Abecasis wrote: > Dr Craig Scott wrote: >> On 08/11/2011, at 1:31 AM, João Abecasis wrote: >>> At the bare minimum, I think we should strive to support these compilers: >>> >>> - GCC 4.2 and up >>> - MSVC 2008 and later >>> - Clang (trunk) >>> >>> On the page

Re: [Development] Platform / compiler support

On 08/11/2011, at 1:31 AM, João Abecasis wrote: > > At the bare minimum, I think we should strive to support these compilers: > >- GCC 4.2 and up >- MSVC 2008 and later >- Clang (trunk) > > On the page above I also put in a list of platforms, splitting them between > Desktop, Embe

Re: [Development] Platform / compiler support

On 08/11/2011, at 8:40 AM, Olivier Goffart wrote: > On Monday 07 November 2011 19:52:37 Thiago Macieira wrote: >> On Monday, 7 de November de 2011 17:42:22 jan-arve.saet...@nokia.com wrote: >>> Don't we need to agree on what criteria a platform needs to fulfill in >>> order to be supported? The s

Re: [Development] Installing Qt5Config.cmake from the Qt repo?

On 02/11/2011, at 1:44 AM, Stephen Kelly wrote: On Friday, October 28, 2011 13:13:20 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 s

Re: [Development] Installing Qt5Config.cmake from the Qt repo?

On 29/10/2011, at 6:14 AM, wrote: > > > On 10/28/11 5:11 PM, "ext Stephen Kelly" wrote: > >> On Friday, October 28, 2011 16:24:08 Matt Williams wrote: >>> On 28 October 2011 14:44, wrote: I think that's reasonable in general. It's similar to what we do to support pkgconfig