Re: [Development] submitting a multi-dimensional container class for Qt: QNDArray
On 12/28/2012 03:36 PM, Glen Mabey wrote: > Hello, > > For some time, I have been working on a QtCore-based class that would be a > container class of arbitrary dimensionality. I did give a presentation on > this topic at DevDays-CA: > > http://www.qtdeveloperdays.com/northamerica/sites/default/files/presentation_pdf/QNDArray%20at%20Qt%20Developer%20Days.pdf I see that you've specialized on bools to store one bool per bit. Is that wise, considering that it's generally agreed that std::vector doing the same was a mistake? http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=98 -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] submitting a multi-dimensional container class for Qt: QNDArray
11.01.2013, 11:57, "Uwe Rathmann" : > On Wed, 09 Jan 2013 16:02:17 -0600, Thiago Macieira wrote: > I think this is out of the scope of Qt. I do not see that many uses case for normal Qt applications. >>> I am not surprised that some developers would feel this way, and I >>> think I would also feel that way if Qt were still strictly a GUI >>> toolkit, instead of the application framework that it became in Qt4. >> I'm not sure it's out of scope for Qt. In fact, I don't know yet whether >> it should be part of Qt Core or not. > > Something I was missing several times is a 2D container. Qt has objects > organized in rows and columns ( QTable, QImage ... ) - so IMHO it is > related to Qt. To work with matrices, you can use Eigen: http://eigen.tuxfamily.org/ -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and QAbstractListModel
On Jan 10, 2013, at 5:46 PM, Alberto Mardegan wrote: > Hi all! > I'd like to make C++ models more usable from QML; in the net there > are several blog posts illustrating how to achieve that, but IMHO it > would be better if at least some of these handy features were in > QAbstractListModel itself: > > - "count" property > - "get(index)" invocable method, returning a QVariantMap mapping all the > roles to their data for the specified index +1 from me. That would clean up a lot of the ugly special casing we have to deal with whenever models are provided to components. > Also, though not very often requested, we could add: > - "remove(index)" which just calls QAbstractItemModel::removeRow() > - "QList items(const QString &role)", which returns the data > for the role "role" for all items. > > The implementation for the above is fairly trivial, so I wonder if > there's some other reasons why it hasn't been done or if it's just that > no one did and a patch is welcome. I would suspect it the latter and we just assumed there was a philosophy behind it. Another possibly low hanging fruit is to add some convenience for sorting models. But the model implementation differences make straight forward use of QSortFilterProxyModel problematic. Jens ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform Content Selection
On 10-Jan-13 17:26, Alan Alpert wrote:
>> The Qt
>> heritage so far was, to maximize portability level, to "test for
>> features" - something sadly currenly NOT possible in an easy way in QML.
> The Qt heritage so far was desktop, where cross-device compatibility
> meant "make sure it'll still work in 640x480 resolution". Desktop
Wasn't talking about just UI. To link with dbus, you added dbus to the
Qt configuration, not "Linux" or "Ubuntu". In an ideal world, you did
this via pkgconfig. What I'm saying is that on the desktop it was a very
rare case where you wouldn't have all modules, or that some modules are
built in an incompatible way. In today's Qt world, you cannot count on
any Qt module, component or such being present (In theory, there's Qt
Essentials, but let's see how that plays out in terms of actual
deployment). No way of checking whether you have QtWebkit other than
having a Loader, put a Hello world in it and if it fails, use the layout
that foregoes WebView usage. Ditto for MultimediaKit. Add-ons are even
worse (having to access sensors through Loader wrappers is hardly an
elegant proposition).
>> complete solution - users probably won't be happy people triggering tens
>> of megs of Qt downloads every now and then just because an extra
>> property has been introduced. I still think "then don't use it" is a
>> poor argument as it means "You're stuck with the first major Qt release
>> for that platform forever".
> This isn't about selecting versions of imports. You always write for
> the current version of the platform, and when the platform updates you update
> your app if you need new functionality. This is for the case
I'm repeating myself here, but there is no universal "current version of
the platform" in the real, deployed world as the world doesn't
insta-update every device of every OS when the Qt project makes a
release, and this will be increasingly true with super-fragmented
platforms like Android joining the show. If QtQuick 2.0 gets released to
the Android world, you will never really be able to use features from a
2.1 without making the choice of a) maintaining a parallel branch or b)
ditching millions of people who did not update to whatever provides
version 2.1. Whether it's a minor or major version bump doesn't really
matter, as in QMLs case the file-fragmentation is immediate.
As a real life example - QtQuick 1.1 introduced the "maximumLineCount"
property to Text {}. Symbian didn't support it till a year later, and
the N900 never got QtQuick 1.1 officially so options were a) don't use
the property and sacrifice visuals on N9(50) and desktop or b) maintain
two sets of source files differing in just that property use. In this
particular case, this is a worse compatibility proposition than C++
(where you either have an #ifdef, or, if it's addressable via MOC, just
a plain "if")
Best regards,
Attila
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Playground: Crypto module
QMessageAuthenticationCode is ready: https://codereview.qt-project.org/44512 11.01.2013, 02:51, "Richard Moore" : > On 10 January 2013 22:32, Ruslan Nigmatullin wrote: > >> 11.01.2013, 00:55, "Richard Moore" : >>> On 10 January 2013 20:48, Ruslan Nigmatullin wrote: 2. HMAC is unsupported, so it's usually impossible to use OAuth with hmac-authorization (like "hmac(sha256)") >>> Adding support for HMAC to QCryptographicHash would be pretty trivial. >>> I don't see any reason why such a change would not be accepted. >> If it's fit logically into QCryptographicHash, there is no problem to >> implement it, I agree. Should I implement it as another one class, i.e. >> QMessageAuthenticationCode? > > I think a separate QMessageAuthenticationCode class is probably a better API. > > Cheers > > Rich. -- Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] submitting a multi-dimensional container class for Qt: QNDArray
On Jan 11, 2013, at 1:56 AM, Uwe Rathmann wrote: > On Wed, 09 Jan 2013 16:02:17 -0600, Thiago Macieira wrote: > I think this is out of the scope of Qt. I do not see that many uses case for normal Qt applications. >>> >>> I am not surprised that some developers would feel this way, and I >>> think I would also feel that way if Qt were still strictly a GUI >>> toolkit, instead of the application framework that it became in Qt4. >> >> I'm not sure it's out of scope for Qt. In fact, I don't know yet whether >> it should be part of Qt Core or not. > > Something I was missing several times is a 2D container. Qt has objects > organized in rows and columns ( QTable, QImage ... ) - so IMHO it is > related to Qt. > > But I would expect to find a class with an API comparable to QVector. Yes, if the container object is strictly 2D, then I think that the API would probably be much like that of QVector. There are cases I've used where the DTYPE is a non-numeric class, but most of the time (for me) it's been numeric, and the ability to do basic mathematical operations (such as add 2 of them together, or multiply all elements by a scalar) is a really handy feature. Where it starts to get tricky is what the behavior should be when two instances of different dimensionality are multiplied (for example), and that is precisely what Numpy has already hammered out (they call it "broadcasting"), and I sure didn't want to reinvent the wheel there! Best Regards, Glen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] ICU and Windows
As I was investigating a different problem I came across a bigger issue regarding ICU on Windows. The problem is that when ICU is linked against on Windows it links against the same copy of the library even if it is building for release which causes a problem with C runtime libraries on Windows if you use MSVC. For those who are not aware of the issue here whenever you link an application or library on Windows with MSVC then it will use a setting for the C runtime libraries, Qt defaults to using the release version for release builds (-MD) and the debug version for debug builds (-MDd). And provided the same one is used for all the libraries linked against and the application then everything is fine. However if they were to be mixed then it opens up the potential for memory corruption to occur as it ends up with two memory heaps in use by the application. 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. Since ICU doesn't provide the debug version of the libraries in their binary packages then this means that either the user has to build them themselves (which means modifying the target as well since the output for debug and release defaults to be the same in their project files) or we should consider adding them to the 3rdparty section (like we do for libegl and so on) so we can control the situation better. Either way I feel that this needs to be fixed ASAP because we could end up seeing bug reports that are in effect caused by this and end up creating more noise as a result. A short term option (and potentially permanent) would be to link against a different version of the ICU libraries and point out that if they want to use Qt in debug they would need to build ICU themselves and make the relevant modifications to the output library names. Regards, Andy -- Andy Shaw Head of Support, Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] submitting a multi-dimensional container class for Qt: QNDArray
On Jan 11, 2013, at 2:03 AM, Samuel Rødal wrote: > On 12/28/2012 03:36 PM, Glen Mabey wrote: >> Hello, >> >> For some time, I have been working on a QtCore-based class that would be a >> container class of arbitrary dimensionality. I did give a presentation on >> this topic at DevDays-CA: >> >> http://www.qtdeveloperdays.com/northamerica/sites/default/files/presentation_pdf/QNDArray%20at%20Qt%20Developer%20Days.pdf > > I see that you've specialized on bools to store one bool per bit. Is > that wise, considering that it's generally agreed that std::vector > doing the same was a mistake? > http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=98 Great question! I actually had no knowledge of std:vector's bit-packed implementation, and that article does make some very pertinent points, most of which I don't think apply to my experiences with multi-dimensional arrays -- let's see how well I can make that case. First, bit-packed QNDArray's was not premature optimization, but rather post-facto optimization. I had planned to make this change, but hadn't ever needed it, until I had an application (that runs in an HPC system) that was not running in real time, and used lots of QNDArray<2,quint8> instances. I didn't ever even measure by what factor it was too slow -- it was really bad. Without any algorithmic changes, QNDArray<2,bool> with the bit-packed partial specialization implementation made the algorithm run (barely!) in real-time. I know that's more detail than you needed to hear, but it was really exciting to see the power of the L2 cache grow with such a small code change in the application (there were lots of random accesses in some rather large arrays). And just as the article indicates, QNDArray<2,quint8> is still an option, but I don't think that most programmers will feel a need to substitute with it. That's because (in my experience) most of the time I find myself *operating* on an array instead of iterating over it. I don't know whether logical operators (!,~,&,|,^,&=,|=,^=) for std::vector instances are supported (somehow I doubt it), but that's a fundamental aspect of QNDArray. And those logical operators (in QNDArray) all operate on the two instances whole words at a time. (and incidentally, studying the DTYPE=bool case is easier because of a reduced number of operators) It turns out that std::vector and QNDArray both took the same approach to "addressing" a single bit (the separate class that is instantiated when indexing a single element) but IMHO the QNDArray's class is a natural extension and base case to the process of dimensional reduction from any value of N. That is, for QNDArray<3,bool> a3( T3(4,5,6) ); a3 = true; QNDArray<3,bool> a2 = a3[1]; // shape is (5,6) QNDArray<1,bool> a1 = a2[3]; // shape is (6,) bool a0 = a1[2]; the N=0 case has the same mechanics as the N=1 and N=2 cases. I won't elaborate here, but this is true for all DTYPEs. However, the bool partial specialization has a little bit of extra magic foo to support these maneuvers: a3[ T3(0,4,2) ] = false; a1[ 3 ] = false; which is precisely the "reference" class the article referred to. So, I am very happy with the numerical (well, logical) usage of bit-packed QNDArray's that I have had experience with -- I hope yours is just as good! Best Regards, Glen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Proposal: Adding a repository in Qt Project for the Ministro tool, needed by Qt for Android
Hi, As part of the Android-port of Qt 5 being contributed to the Qt Project by BogDan, he also contributed the code for a general-purpose Android app which is used for getting libraries and plugins on demand when a Qt app is deployed to an Android device. This tool is called "Ministro". We need a repository to put it in, and the existing repositories do not seem to fit, so I'm proposing making a new repository for this: ministro/ministro Thanks! -- Eskil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] submitting a multi-dimensional container class for Qt: QNDArray
On Fri, 11 Jan 2013 07:19:19 -0600, Glen Mabey wrote: >> Something I was missing several times is a 2D container. Qt has objects >> organized in rows and columns ( QTable, QImage ... ) - so IMHO it is >> related to Qt. >> >> But I would expect to find a class with an API comparable to QVector. > > Yes, if the container object is strictly 2D, then I think that the API > would probably be much like that of QVector. I bet this would cover 98% of all use cases ( Qt is a 2D toolkit ) and usually it doesn't need to have any maths. The motivation of such a class is simply that you can build better APIs when you can copy implicitly shared 2D Arrays and access them with row, column indexes. Of course that doesn't mean, that the other 2% are not important enough to have another container like yours. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] submitting a multi-dimensional container class for Qt: QNDArray
On 01/11/2013 02:41 PM, Glen Mabey wrote: > > On Jan 11, 2013, at 2:03 AM, Samuel Rødal wrote: > >> On 12/28/2012 03:36 PM, Glen Mabey wrote: >>> Hello, >>> >>> For some time, I have been working on a QtCore-based class that would be a >>> container class of arbitrary dimensionality. I did give a presentation on >>> this topic at DevDays-CA: >>> >>> http://www.qtdeveloperdays.com/northamerica/sites/default/files/presentation_pdf/QNDArray%20at%20Qt%20Developer%20Days.pdf >> >> I see that you've specialized on bools to store one bool per bit. Is >> that wise, considering that it's generally agreed that std::vector >> doing the same was a mistake? >> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=98 > > Great question! > > I actually had no knowledge of std:vector's bit-packed implementation, and > that article does make some very pertinent points, most of which I don't > think apply to my experiences with multi-dimensional arrays -- let's see how > well I can make that case. > > First, bit-packed QNDArray's was not premature optimization, but rather > post-facto optimization. I had planned to make this change, but hadn't ever > needed it, until I had an application (that runs in an HPC system) that was > not running in real time, and used lots of QNDArray<2,quint8> instances. I > didn't ever even measure by what factor it was too slow -- it was really bad. > Without any algorithmic changes, QNDArray<2,bool> with the bit-packed > partial specialization implementation made the algorithm run (barely!) in > real-time. I know that's more detail than you needed to hear, but it was > really exciting to see the power of the L2 cache grow with such a small code > change in the application (there were lots of random accesses in some rather > large arrays). > > And just as the article indicates, QNDArray<2,quint8> is still an option, but > I don't think that most programmers will feel a need to substitute with it. > That's because (in my experience) most of the time I find myself *operating* > on an array instead of iterating over it. I don't know whether logical > operators (!,~,&,|,^,&=,|=,^=) for std::vector instances are supported > (somehow I doubt it), but that's a fundamental aspect of QNDArray. And those > logical operators (in QNDArray) all operate on the two instances whole words > at a time. (and incidentally, studying the DTYPE=bool case is easier because > of a reduced number of operators) Yep, very good points. In the cases when doing bit operations on large data sets your representation will both use less space and perform a lot better. > It turns out that std::vector and QNDArray both took the same > approach to "addressing" a single bit (the separate class that is > instantiated when indexing a single element) but IMHO the QNDArray's class is > a natural extension and base case to the process of dimensional reduction > from any value of N. That is, for > > QNDArray<3,bool> a3( T3(4,5,6) ); > a3 = true; > QNDArray<3,bool> a2 = a3[1]; // shape is (5,6) > QNDArray<1,bool> a1 = a2[3]; // shape is (6,) > bool a0 = a1[2]; > > the N=0 case has the same mechanics as the N=1 and N=2 cases. I won't > elaborate here, but this is true for all DTYPEs. However, the bool partial > specialization has a little bit of extra magic foo to support these maneuvers: > > a3[ T3(0,4,2) ] = false; > a1[ 3 ] = false; > > which is precisely the "reference" class the article referred to. > > So, I am very happy with the numerical (well, logical) usage of bit-packed > QNDArray's that I have had experience with -- I hope yours is just as good! Ok, I guess QNDArray is also meant to represent data sets that are potentially a lot larger as well, compared to the average std::vector use case. And as you say there's always quint8 if someone has different requirements. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a "non-destabilising" bug-fix?
Hi, We should finish this discussion and document the conclusion in http://qt-project.org/wiki/Branch-Guidelines ... Marc Mutz wrote: > > > Ok, trying to summarise, I understand it this way: > > > > > > 1. release-critical fixes are submitted and merged to 'stable' now, > > >'release' later, when it exists. > > >No-brainer fixes are also welcome. > > > 2. bug-fixes that don't violate string or BC freezes are submitted, > > >but NOT merged, against stable. > > >They will be merged once RC2 is tagged and 'release' is branched off. > > >Maintainers and other reviewers can redirect a fix to 'dev' instead, > > >but all fixes that don't require string or BiC changes should > > > initially be submitted to 'stable'. > > >[Personally, I'd add that if a fix goes to 'dev' instead of 'stable', > > >then the commit message should say why.] > > [snip] On Monday December 10 2012, Shaw Andy replied: > > I don't agree that all bug fixes should go into stable, judgement should > > certainly be made, but we can't just put all bug fixes blindly into stable > > otherwise it will probably end up as being far from stable. There are > > times when it would be better for a bug fix to go into dev instead of > > stable because it may give a much too obvious behavior change for example. On Monday 10 December 2012 12:07:21 Marc Mutz replied: > I was suggesting that bug-fixes _initially_ be submitted for stable > (blindly, if you will) and that review decides whether to redirect them to > dev instead. > > So I wasn't suggesting to "just put all bug fixes blindly into stable". I > want to avoid them going blindly to dev, though, esp. without the commit > message explaining why. One problem is that re-targeting a branch with gerrit is not working. so you need to re-submit, which is a small annoyance. Even if we do it like that we still need criterion for the reviewer to decide. And if those criterion are on the wiki, the contributor can just apply the criteria them self. And what are those criteria? When does a patch goes to dev or to stable? I suggest this: Go to stable: a. Fixes to regressions against a previous "recent" version of Qt. (less than 2 or 3 years old) b. Fixes in new feature introduced in the most recent minor version. c. Critical fixes (P1/P0): security, crashes or data corruption. d. Compilation fixes or adaptations required for different version of the compilers or upstream libraries. Everything else go to dev. The reason to limit to regression fixes is that if one could live few releases with a given bug, then he can still wait another 6 months for the bug fixe. That way we minimize the risks of introducing new subtle bugs in patch release. Then there is the question: What can go into Qt 4.8? Normaly, the criterias for Qt 4.8 should be the same as for the stable branch. For example, to me, small bugs like QTBUG-20403 should go to dev, and not to stable or 4.8 It would be nice to come to an agreement and write the policy on the wiki. Regards. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Android port - Why do we need Ministro?
I have to assume this subject has been discussed before in other lists but since the android port it is a "hot topic" on this list right now I thought it was worth starting again. I deployed a test application using the necessitas project and while I was impressed on how nice the development experience was (minor a few crashes on qt creator) I found out that most users that tried to install my application had a very hard time. The current flow requires a user to: 1) download your "app" from the store; 2) When executing it for the first time (assuming that the user has never installed another application based on necessitas) the application will redirect the user to the google play store to download ministro (what I found most users will not understand); 3) After installing ministro the user will need to know to try to execute the "app" again; 4) On executing the app for the second time the qt libraries will be downloaded. 5) enjoy the app! Are there plans to change this flow? I have to assume there were good reasons to do like this but without actually looking into the code it seems that would make more sense to combine the ministro code with the java wrapper generated for each application, no? I understand ministro plays an important part and donwloads the right version of the libraries for each device and that we would have to duplicate its code with every application but it seems like a very reasonable price to pay if that would actually make the "first install" experience better. Are there any other technical reasons why this approach would not work? cheers, Felipee ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android port - Why do we need Ministro?
On Fri, Jan 11, 2013 at 2:36 PM, Felipe Crochik wrote: > I have to assume this subject has been discussed before in other lists but > since the android port it is a "hot topic" on this list right now I thought > it was worth starting again. I think it is a good idea to reiterate again because many people here have not seen this topic before on this list, I assume. > I deployed a test application using the necessitas project and while I was > impressed on how nice the development experience was (minor a few crashes > on qt creator) I found out that most users that tried to install my > application had a very hard time. > > The current flow requires a user to: > 1) download your "app" from the store; > 2) When executing it for the first time (assuming that the user has never > installed another application based on necessitas) the application will > redirect the user to the google play store to download ministro (what I > found most users will not understand); > 3) After installing ministro the user will need to know to try to execute > the "app" again; > 4) On executing the app for the second time the qt libraries will be > downloaded. > 5) enjoy the app! > > Are there plans to change this flow? > We have not used this workflow for the KDE Harmattan project, but I can understand the reasoning behind as well. We had put the libraries into each application (self-contained or "bundled"), but that resulted the same (sometimes huge) libraries shipped several times. This could mean dozen and even more occurrences for Qt applications. > I have to assume there were good reasons to do like this but without > actually looking into the code it seems that would make more sense to > combine the ministro code with the java wrapper generated for each > application, no? > I am not familiar with the java wrapper et al. Could you please summarize the steps from user perspective you are thinking of? My opinion is now that the two ways (self-containment and explicite downloading) could coexist depending on the use case. I would not use ministro for a small application where I could boundle a small library up. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android port - Why do we need Ministro?
Mainly my suggestion is to avoid the step of having to have ministro installed. I appreciate that including the qt libraries with every app is not the best approach (especially if we need different sets for the different android versions/devices). I would like for each application to include some shared code that would download, only if necessary, the "best" qt libraries to a shared location on the device. I assume that is exactly what ministro does but as it is the user MUST have "the ministro applicaiton" installed before any other application (based on necessitas) can request the qt libraries. In a sense I want to include ministro with every application - not the qt libraries. And in the process make it as seamless as possible. I guess possible reasons for the design we have now are (just a wild guess since I didn't look into the code and was not involved with its development) 1) because this way ministro can be improved to include more libraries regardless of the applications that depend on it; or 2) because there is some challenge with applications sharing libraries and we need a "broker". On Fri, Jan 11, 2013 at 9:51 AM, Laszlo Papp wrote: > On Fri, Jan 11, 2013 at 2:36 PM, Felipe Crochik wrote: > >> I have to assume this subject has been discussed before in other lists >> but since the android port it is a "hot topic" on this list right now I >> thought it was worth starting again. > > > I think it is a good idea to reiterate again because many people here have > not seen this topic before on this list, I assume. > > >> I deployed a test application using the necessitas project and while I >> was impressed on how nice the development experience was (minor a few >> crashes on qt creator) I found out that most users that tried to install my >> application had a very hard time. >> >> The current flow requires a user to: >> 1) download your "app" from the store; >> 2) When executing it for the first time (assuming that the user has never >> installed another application based on necessitas) the application will >> redirect the user to the google play store to download ministro (what I >> found most users will not understand); >> 3) After installing ministro the user will need to know to try to execute >> the "app" again; >> 4) On executing the app for the second time the qt libraries will be >> downloaded. >> 5) enjoy the app! >> >> Are there plans to change this flow? >> > > We have not used this workflow for the KDE Harmattan project, but I can > understand the reasoning behind as well. We had put the libraries into each > application (self-contained or "bundled"), but that resulted the same > (sometimes huge) libraries shipped several times. This could mean dozen and > even more occurrences for Qt applications. > > >> I have to assume there were good reasons to do like this but without >> actually looking into the code it seems that would make more sense to >> combine the ministro code with the java wrapper generated for each >> application, no? >> > > I am not familiar with the java wrapper et al. Could you please summarize > the steps from user perspective you are thinking of? > > My opinion is now that the two ways (self-containment and explicite > downloading) could coexist depending on the use case. I would not use > ministro for a small application where I could boundle a small library up. > > Laszlo > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android port - Why do we need Ministro?
On 01/11/2013 03:36 PM, Felipe Crochik wrote: Are there plans to change this flow? I have to assume there were good reasons to do like this but without actually looking into the code it seems that would make more sense to combine the ministro code with the java wrapper generated for each application, no? I understand ministro plays an important part and donwloads the right version of the libraries for each device and that we would have to duplicate its code with every application but it seems like a very reasonable price to pay if that would actually make the "first install" experience better. Are there any other technical reasons why this approach would not work? Hi, We need alternative deployment mechanisms for the use cases that are not covered by Ministro, but there are issues with this for deploying imports and plugins and Ministro also makes it easier to deploy to different devices, as it downloads the correct version of the platform plugin for you. I think this is all solvable somehow, but I don't think the solution is integrating Ministro in each app, because each app would still have to download their own libraries if there's no central repository on the device. I think it would be better to make a secondary deployment method which allows you to put everything you need into the apk so that the app works out of the box and you have full control over the Qt libraries it uses and when these are updated. I'm not 100% sure what that would require at the moment, though. It could mean building statically, or it could mean something else. So the bottom line: I do think we need support for this, but I think we should spend the time to find the right solution, so it's not likely to happen for the experimental version of the port we're planning to release with Qt 5.1. Since Ministro is well-tested and provides both a simple and working way of deploying and updating the libraries, imports and plugins we need, and it allows several apps to share the same binaries, so you avoid bloating the size of your app (which might a problem depending on how large your app is to begin with), I think it's a good solution for the first version of the port. -- Eskil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android port - Why do we need Ministro?
With my very limited experience on the subject I have to say that "the current flow" is probably good enough for "controlled distribution" but pretty bad for mass market apps. Having the application download the libraries after "being downloaded" is bad enough for the average user but figuring out the "installing ministro step" requires a level of commitment that I think very few "average/casual" users will show for a "random application they found in the store". Why do you think incorporating ministro code into each application is bad? Unless there is some technical limitation to install shared libraries this way the only drawback I can imagine is that we will need to update applications that depend on it with any "improvement on it" is made because of new devices - what is a pretty reasonable problem to work around. Note that I am only talking about "the Qt shared libraries" - not any other third party libraries. just my 2ct. On Fri, Jan 11, 2013 at 10:07 AM, Eskil Abrahamsen Blomfeldt < eskil.abrahamsen-blomfe...@digia.com> wrote: > On 01/11/2013 03:36 PM, Felipe Crochik wrote: > > Are there plans to change this flow? I have to assume there were good > reasons to do like this but without actually looking into the code it seems > that would make more sense to combine the ministro code with the java > wrapper generated for each application, no? > > I understand ministro plays an important part and donwloads the right > version of the libraries for each device and that we would have to > duplicate its code with every application but it seems like a very > reasonable price to pay if that would actually make the "first install" > experience better. Are there any other technical reasons why this approach > would not work? > > > Hi, > > We need alternative deployment mechanisms for the use cases that are not > covered by Ministro, but there are issues with this for deploying imports > and plugins and Ministro also makes it easier to deploy to different > devices, as it downloads the correct version of the platform plugin for > you. I think this is all solvable somehow, but I don't think the solution > is integrating Ministro in each app, because each app would still have to > download their own libraries if there's no central repository on the > device. I think it would be better to make a secondary deployment method > which allows you to put everything you need into the apk so that the app > works out of the box and you have full control over the Qt libraries it > uses and when these are updated. I'm not 100% sure what that would require > at the moment, though. It could mean building statically, or it could mean > something else. > > So the bottom line: I do think we need support for this, but I think we > should spend the time to find the right solution, so it's not likely to > happen for the experimental version of the port we're planning to release > with Qt 5.1. Since Ministro is well-tested and provides both a simple and > working way of deploying and updating the libraries, imports and plugins we > need, and it allows several apps to share the same binaries, so you avoid > bloating the size of your app (which might a problem depending on how large > your app is to begin with), I think it's a good solution for the first > version of the port. > > -- Eskil > > > > > > > ___ > 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] Android port - Why do we need Ministro?
On 01/11/2013 04:23 PM, Felipe Crochik wrote: With my very limited experience on the subject I have to say that "the current flow" is probably good enough for "controlled distribution" but pretty bad for mass market apps. Having the application download the libraries after "being downloaded" is bad enough for the average user but figuring out the "installing ministro step" requires a level of commitment that I think very few "average/casual" users will show for a "random application they found in the store". Why do you think incorporating ministro code into each application is bad? Unless there is some technical limitation to install shared libraries this way the only drawback I can imagine is that we will need to update applications that depend on it with any "improvement on it" is made because of new devices - what is a pretty reasonable problem to work around. Note that I am only talking about "the Qt shared libraries" - not any other third party libraries. This suggestion is definitely something we'll investigate. I haven't looked into the Ministro code yet, so I don't know if it's technically possible, but as far as I've understood from previous discussions, there are limits to where apps can write on the device and there are limits to where they can load libraries, which makes the app serving as a central repository of libraries necessary. But it's something we need to investigate further, and for the moment we don't have the resources to take this on for Qt 5.1, where our main priority will be to get the Qt 5 port on par with the Qt 4 version of Necessitas. When get that far, we can start looking into alternative solutions for deploying Qt apps which does not require the extra "install ministro" step when a user launches a Qt app for the first time on a device. If integrating Ministro in the app is an option, then I agree it might better than depending on an external app, but I still think we would need a second solution which allows you to bundle the libraries with your app. -- Eskil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android port - Why do we need Ministro?
On Fri, Jan 11, 2013 at 4:31 PM, Eskil Abrahamsen Blomfeldt < eskil.abrahamsen-blomfe...@digia.com> wrote: > This suggestion is definitely something we'll investigate. I haven't > looked into the Ministro code yet, so I don't know if it's technically > possible, but as far as I've understood from previous discussions, there > are limits to where apps can write on the device and there are limits to > where they can load libraries, which makes the app serving as a central > repository of libraries necessary. But it's something we need to > investigate further, and for the moment we don't have the resources to take > this on for Qt 5.1, where our main priority will be to get the Qt 5 port on > par with the Qt 4 version of Necessitas. When get that far, we can start > looking into alternative solutions for deploying Qt apps which does not > require the extra "install ministro" step when a user launches a Qt app for > the first time on a device. > Many Symbian applications you can download from the Ovi Store include something like "This application may require a one-time download of around 20 MB" in the description. What happens behind the scenes in that case? Is Qt downloaded from Ovi when the user asks to install the application? Or is Qt downloaded the first time the application is launched? I'd say Qt on Android, iOS, etc is not too different of a case from Qt on Symbian. Or maybe it is, if there is specific support in the Ovi Store for that. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a "non-destabilising" bug-fix?
On sexta-feira, 11 de janeiro de 2013 15.21.43, Olivier Goffart wrote: > Go to stable: > a. Fixes to regressions against a previous "recent" version of Qt. (less > than 2 or 3 years old) > b. Fixes in new feature introduced in the most recent minor version. > c. Critical fixes (P1/P0): security, crashes or data corruption. > d. Compilation fixes or adaptations required for different version of the > compilers or upstream libraries. > Everything else go to dev. I agree with almost all: I'd like to relax "c" to include Important (P2) fixes, subject to the approvers' decision. Those should happen most commonly in the first one or two patch releases (.0 and .1). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Importing Snowshoe QML browser to the Qt project
Hi all, Now that Qt 5.0.0 is out I feel that it is a good time to also emphasize show cases of Qt and QML as a technology. In Qt 4 we've had a couple of pretty nice demos in the source code, including a pretty neat demo browser. It serves as a show-case for QtWebKit's C++ API and the Qt widgets (line edit, customizable tab widget, etc.). I would like to have the same for the new technologies we've been working on in the past years, Qt 5, QtQuick 2 and the multi-process capable WebKit integration into Qt. That means basically a little web browser that blends all these technologies together. One option is to start with a new code base from scratch, but I would like to explore another option first: Our friends at INdT started writing a little web browser with exactly that spirit, and to top it off: It's open source and it looks very pretty! It's got a shiny website at http://snowshoe.openbossa.org/ and source code that is currently hosted at Github. So I got in touch with them and they're willing to contribute the code to the Qt project. I'm therefore seeking approval from the Qt project to importing Snowshoe into Gerrit, with playground/snowshoe as proposed location, although I admit that we do have a little problem with the naming there as it's not in line with the guidelines: http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt#681f347d064c99a795cb47631e853396 Opinions? Thoughts? Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU and Windows
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. > Either way I feel that this needs to be fixed ASAP because we could end up > seeing bug reports that are in effect caused by this and end up creating > more noise as a result. A short term option (and potentially permanent) > would be to link against a different version of the ICU libraries and point > out that if they want to use Qt in debug they would need to build ICU > themselves and make the relevant modifications to the output library names. 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. I think we are taking such care (we don't free any memory allocated by ICU). So what exactly is the problem we need to solve? Has anyone noticed a crash, a warning from the C++ runtime, etc.? Is there a latent issue we just haven't hit? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] [Releasing] Preparing Qt 5.0.1 release
> Hi, > > All the repos part of the Qt 5.0.1 release were merged yesterday from > stable->release as announced. > > So changes for 5.0.1 need to be pushed to 'refs/for/release' with a > Task-number tag in the commit message pointing to a P0/P1 task [1]. > > The process should be that you get the change approved normally and you > add me as Reviewer (since only the release team can stage those > changes). > > NOTE: No cherry-picks this time !! > What about changes that are integrated to stable already but missed the branch due to unrelated test failures delaying the integration? 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 e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a "non-destabilising" bug-fix?
On 11 January 2013 15:21, Olivier Goffart wrote: > c. Critical fixes (P1/P0): security, crashes or data corruption. Aren't important fixes (such as security fixes) good candidates for the release branch instead of stable? -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Preparing Qt 5.0.1 release
On 01/11/2013 04:51 PM, shane.kea...@accenture.com wrote: >> Hi, >> >> All the repos part of the Qt 5.0.1 release were merged yesterday from >> stable->release as announced. >> >> So changes for 5.0.1 need to be pushed to 'refs/for/release' with a >> Task-number tag in the commit message pointing to a P0/P1 task [1]. >> >> The process should be that you get the change approved normally and you >> add me as Reviewer (since only the release team can stage those >> changes). >> >> NOTE: No cherry-picks this time !! >> > What about changes that are integrated to stable already but missed the > branch due to unrelated test failures delaying the integration? > You read my mind. I was about the same after Oliver revived the "Branching Guidelines" wiki page. As far as I can see, there are some options to discuss. - Merge stable into release again (doesn't sound too good) - push it again to 'release' (doesn't sound good either) - cherry-pick from stable to release (we already said that we wont do it) - just wait for the next patch/minor release We have some cases already asking how to deal with this for 5.0.1 so I think it would be nice if we can agree on something. Cheers, ps: flaky tests is something that we should discuss in another thread because I think it's also rather important. -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Importing Snowshoe QML browser to the Qt project
On 01/11/2013 04:47 PM, Simon Hausmann wrote: > So I got in touch with them and they're willing to contribute the code to the > Qt > project. I'm therefore seeking approval from the Qt project to importing > Snowshoe > into Gerrit, with [...] I like the idea, but I'm a bit concerned about the future of Snowshoe then: suppose that someone wants to contribute a brilliant (though very complex) feature, will he be able to do so or will the feature be rejected because it would go beyond the scope of a showcase project? Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Importing Snowshoe QML browser to the Qt project
On Fri, Jan 11, 2013 at 12:59 PM, Alberto Mardegan wrote: > On 01/11/2013 04:47 PM, Simon Hausmann wrote: >> So I got in touch with them and they're willing to contribute the code to >> the Qt >> project. I'm therefore seeking approval from the Qt project to importing >> Snowshoe >> into Gerrit, with > [...] > > I like the idea, but I'm a bit concerned about the future of Snowshoe > then: suppose that someone wants to contribute a brilliant (though very > complex) feature, will he be able to do so or will the feature be > rejected because it would go beyond the scope of a showcase project? Why on earth we would refuse such a contribution? It's more than welcomed :). Note that it is under the umbrella of qt-project but in no way in the Qt source tree so it can totally be a mature and advanced project one day. > > Ciao, >Alberto > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Software Engineer @ Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU and Windows
On Friday 11 Jan 2013 13:32:35 Shaw Andy wrote: > Since ICU doesn't provide the debug version of the libraries in their binary > packages then this means that either the user has to build them themselves > (which means modifying the target as well since the output for debug and > release defaults to be the same in their project files) or we should > consider adding them to the 3rdparty section (like we do for libegl and so > on) so we can control the situation better. > > Either way I feel that this needs to be fixed ASAP because we could end up > seeing bug reports that are in effect caused by this and end up creating > more noise as a result. A short term option (and potentially permanent) > would be to link against a different version of the ICU libraries and point > out that if they want to use Qt in debug they would need to build ICU > themselves and make the relevant modifications to the output library names. Hi Andy, I'm no expert on the various build and link issues, but in trying to write the new ICU backend for QLocale which would make ICU a hard requirement in the future I've started running into problems which may affect your choice of solution. For those interested, I have working code for ICU-based number and date formatter classes at: http://qt.gitorious.org/~odysseus/qt/odysseus-qtbase/commits/qlocale-icu Up to now I've been using the ICU C api due to ICU not providing a binary compatibility guarantee on their C++ api between major versions. This C api is a simplified wrapper around the C++ implementation. This works fine for the most commonly used functions like number and date formatting, but the C api is completely inadequate for using the calendar and time zone functions, which are a primary reason for switching to ICU. For example, you can't even find out what the current time zone is via the C api, let alone create and query a custom timezone in an efficient way. I'm trying to find a way around this with just the C api, but right now the easiest solution does appear to be using the C++ api and somehow dealing with the binary compatibility problem. Could we make that work? On Linux, I have heard that some/many distro's automatically rebuild all packages depending on ICU whenever the ICU major version changes due to its bad reputation. Could we simply just state that it is a requirement to rebuild Qt if the ICU major version on a system is changed? On Mac, because OSX doesn't ship with the ICU headers installed, my understanding is we currently require people to install ICU via MacPorts or HomeBrew and build against that instead of the system ICU libraries. I don't see that as a long-term solution when we start requiring ICU as it's not very portable or reliable as to the version used. The alternative is to manually install the headers from opensource.apple.com and use the system library (how I'm currently building), but I've heard there's been issues in the past with published headers not actually matching? The best option is probably not to use ICU at all on Mac, but just use the Carbon/Cocoa api which is actually just a thin wrapper around ICU and for localization at least is complete for our current purposes. However, I'm not sure this is an option for the other proposed uses of ICU, such as code tables. On Windows, well it almost seems we have to require people to either build their own ICU and keep it in sync with Qt, or we have to start providing it ourselves. Perhaps the best solution is going to be including ICU in 3rdparty: * On Linux always build with 3rdparty ICU, unless the distro/dev chooses to use their system library and accepts the need to rebuild Qt with a major version change. * On Windows always build with the 3rdparty ICU, unless the dev wants to use their own and takes responsibility for maintaining compatibility * On Mac don't use ICU for QLocale, but use the native api instead, only build 3rdparty ICU if other features are enabled that need it. Alternatively trust the opensource.apple.com headers and use the system library. One plus point to shipping in 3rdparty is that we can use a more modern version than the ICU 4.0 we're currently stuck with due to Snow Leopard support. The big minus is ICU is big and possibly icky to build. Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU and Windows
11.01.2013, 20:29, "John Layt" : > On Friday 11 Jan 2013 13:32:35 Shaw Andy wrote: > >> Since ICU doesn't provide the debug version of the libraries in their binary >> packages then this means that either the user has to build them themselves >> (which means modifying the target as well since the output for debug and >> release defaults to be the same in their project files) or we should >> consider adding them to the 3rdparty section (like we do for libegl and so >> on) so we can control the situation better. >> >> Either way I feel that this needs to be fixed ASAP because we could end up >> seeing bug reports that are in effect caused by this and end up creating >> more noise as a result. A short term option (and potentially permanent) >> would be to link against a different version of the ICU libraries and point >> out that if they want to use Qt in debug they would need to build ICU >> themselves and make the relevant modifications to the output library names. > > Hi Andy, > > I'm no expert on the various build and link issues, but in trying to write the > new ICU backend for QLocale which would make ICU a hard requirement in the > future I've started running into problems which may affect your choice of > solution. > > For those interested, I have working code for ICU-based number and date > formatter classes at: > http://qt.gitorious.org/~odysseus/qt/odysseus-qtbase/commits/qlocale-icu > > Up to now I've been using the ICU C api due to ICU not providing a binary > compatibility guarantee on their C++ api between major versions. This C api > is a simplified wrapper around the C++ implementation. This works fine for > the most commonly used functions like number and date formatting, but the C > api is completely inadequate for using the calendar and time zone functions, > which are a primary reason for switching to ICU. For example, you can't even > find out what the current time zone is via the C api, let alone create and > query a custom timezone in an efficient way. > > I'm trying to find a way around this with just the C api, but right now the > easiest solution does appear to be using the C++ api and somehow dealing with > the binary compatibility problem. Could we make that work? > > On Linux, I have heard that some/many distro's automatically rebuild all > packages depending on ICU whenever the ICU major version changes due to its > bad reputation. Could we simply just state that it is a requirement to > rebuild Qt if the ICU major version on a system is changed? > > On Mac, because OSX doesn't ship with the ICU headers installed, my > understanding is we currently require people to install ICU via MacPorts or > HomeBrew and build against that instead of the system ICU libraries. I don't > see that as a long-term solution when we start requiring ICU as it's not very > portable or reliable as to the version used. The alternative is to manually > install the headers from opensource.apple.com and use the system library (how > I'm currently building), but I've heard there's been issues in the past with > published headers not actually matching? The best option is probably not to > use ICU at all on Mac, but just use the Carbon/Cocoa api which is actually > just a thin wrapper around ICU and for localization at least is complete for > our current purposes. However, I'm not sure this is an option for the other > proposed uses of ICU, such as code tables. > > On Windows, well it almost seems we have to require people to either build > their own ICU and keep it in sync with Qt, or we have to start providing it > ourselves. > > Perhaps the best solution is going to be including ICU in 3rdparty: > * On Linux always build with 3rdparty ICU, unless the distro/dev chooses to > use their system library and accepts the need to rebuild Qt with a major > version change. > * On Windows always build with the 3rdparty ICU, unless the dev wants to use > their own and takes responsibility for maintaining compatibility > * On Mac don't use ICU for QLocale, but use the native api instead, only build > 3rdparty ICU if other features are enabled that need it. Alternatively trust > the opensource.apple.com headers and use the system library. > > One plus point to shipping in 3rdparty is that we can use a more modern > version than the ICU 4.0 we're currently stuck with due to Snow Leopard > support. The big minus is ICU is big and possibly icky to build. It's icky to cross-compile, otherwise bearable. Size comes only from bundled data, if you can use external dat file, your ICU may be quite small. > > Cheers! > > John. > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android port - Why do we need Ministro?
This is my experience as well, as of now I am doing native or Cordova app dev on the android platform since for my particular audience the Ministro workflow is too much. WHat about the statically linking libs in or talking to Google to include it there anyways ? On Fri, Jan 11, 2013 at 4:36 PM, Felipe Crochik wrote: > I have to assume this subject has been discussed before in other lists but > since the android port it is a "hot topic" on this list right now I thought > it was worth starting again. > > I deployed a test application using the necessitas project and while I was > impressed on how nice the development experience was (minor a few crashes > on qt creator) I found out that most users that tried to install my > application had a very hard time. > > The current flow requires a user to: > 1) download your "app" from the store; > 2) When executing it for the first time (assuming that the user has never > installed another application based on necessitas) the application will > redirect the user to the google play store to download ministro (what I > found most users will not understand); > 3) After installing ministro the user will need to know to try to execute > the "app" again; > 4) On executing the app for the second time the qt libraries will be > downloaded. > 5) enjoy the app! > > Are there plans to change this flow? I have to assume there were good > reasons to do like this but without actually looking into the code it seems > that would make more sense to combine the ministro code with the java > wrapper generated for each application, no? > > I understand ministro plays an important part and donwloads the right > version of the libraries for each device and that we would have to > duplicate its code with every application but it seems like a very > reasonable price to pay if that would actually make the "first install" > experience better. Are there any other technical reasons why this approach > would not work? > > cheers, > Felipee > > ___ > 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
Re: [Development] ICU and Windows
On Friday 11 Jan 2013 20:45:43 Konstantin Tokarev wrote: > It's icky to cross-compile, otherwise bearable. Size comes only from bundled > data, if you can use external dat file, your ICU may be quite small. Unfortunately, the format of the the dat file is very tightly coupled with the ICU major version, so you would almost certainly have to ship the dat file if you ship the library. John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android port - Why do we need Ministro?
Hi, I have write a few mails on this matter at android-qt mailing list. Here https://groups.google.com/group/android-qt/msg/854062a719092224 you can find my reasons why I believe that Ministro is the best solution for Android deployment. I'll do a summary of them: - the most important is that qt libs are very big (Qt4 libs are +40Mb for one platform and most probably Qt5 will be more than that), if you want to target two platforms (armv5 and armv7) you need to bundle +80Mb of qt libs. Even more, if you want to use NEON for armv7 and VFP for armv5 you need to double that size. Ministro downloads the right libs for your platform only once. - android offers no way to install shared libs into its system libs folder, and there is no read/write location that application can use to store shared libs (obviously, for security reasons). Ministro solves this problem by using its own home folder as a central location for qt libs, where only Ministro has read/write permissions to these libs, the other app have only read-only permission, just like your linux desktop. - statically linking or bundling LGPL libs into your package comes with even more challenges than the package size, developers *MUST* provide a way to their users to repack the application with other Qt libs (please check LGPL license on this matter). Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: What constitutes a "non-destabilising" bug-fix?
On Fri, Jan 11, 2013 at 04:53:25PM +0100, Giuseppe D'Angelo wrote: > On 11 January 2013 15:21, Olivier Goffart wrote: > > c. Critical fixes (P1/P0): security, crashes or data corruption. > > Aren't important fixes (such as security fixes) good candidates for > the release branch instead of stable? > olivier's summary does not consider the release branches at all. the active existence of release branches is temporary. their activation (merge from stable) needs to be announced a day or more in advance (so stuff important for the release is not still integrating to stable while the branch is updated). they get deactivated again after a release. as such, the release branch submission policy is a special case of the stable branch submission policy. the above point c is certainly a good starting point. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android port - Why do we need Ministro?
BogDan: Thank you for all your work and this explanation! I was afraid that, at least part of, the reasoning for Ministro was the create/control a "shared location" :( Do you have any ideas of how we could continue with "shared libraries" (not per app) but avoid having to install ministro "manually" ? I know it sounds like a lot of trouble for something that only has to happen once per device but I found out that is the big roadblock for a lot of people to install your application. On Fri, Jan 11, 2013 at 1:52 PM, BogDan wrote: > Hi, > > I have write a few mails on this matter at android-qt mailing list. > Here https://groups.google.com/group/android-qt/msg/854062a719092224 > you can find my reasons why I believe that Ministro is the best solution > for > Android deployment. > > I'll do a summary of them: > - the most important is that qt libs are very big (Qt4 libs are +40Mb for > one > platform and most probably Qt5 will be more than that), if you want to > target > two platforms (armv5 and armv7) you need to bundle +80Mb of qt libs. > Even more, if you want to use NEON for armv7 and VFP for armv5 you need > to double that size. Ministro downloads the right libs for your platform > only once. > - android offers no way to install shared libs into its system libs > folder, and there > is no read/write location that application can use to store shared libs > (obviously, > for security reasons). Ministro solves this problem by using its own home > folder > as a central location for qt libs, where only Ministro has read/write > permissions > to these libs, the other app have only read-only permission, just like > your linux > desktop. > - statically linking or bundling LGPL libs into your package comes with > even more > challenges than the package size, developers *MUST* provide a way to their > users > to repack the application with other Qt libs (please check LGPL license on > this matter). > > Cheers, > BogDan. > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android port - Why do we need Ministro?
On Fri, Jan 11, 2013 at 6:52 PM, BogDan wrote: > I'll do a summary of them: > - the most important is that qt libs are very big (Qt4 libs are +40Mb for > one > platform and most probably Qt5 will be more than that), if you want to > target > two platforms (armv5 and armv7) you need to bundle +80Mb of qt libs. > Even more, if you want to use NEON for armv7 and VFP for armv5 you need > to double that size. Ministro downloads the right libs for your platform > only once. > QtCore 4.8.4 is 2.9 MB for me. It does not look that bad if you need some core feature only. Besides, there is another point (perhaps mentioned in this thread already), you can make sure your application remains working against unexpected behavior and so forth changes we had unfortunate examples in the past. So, it is also a matter of ensuring the functionality of your application. In my opinion, this can be a valid concern for certain application developers. The convenient way for the end user would just be a plus in such a scenario. > - android offers no way to install shared libs into its system libs > folder, and there > is no read/write location that application can use to store shared libs > (obviously, > for security reasons). Ministro solves this problem by using its own home > folder > as a central location for qt libs, where only Ministro has read/write > permissions > to these libs, the other app have only read-only permission, just like > your linux > desktop. > > - statically linking or bundling LGPL libs into your package comes with > even more > challenges than the package size, developers *MUST* provide a way to their > users > to repack the application with other Qt libs (please check LGPL license on > this matter). > I do not see the problem in there yet. It is replacable after repackaging or by direct overwrite if the platform security allows that with Harmattan for instance. That being said, I also agree about that Ministro can be a useful tool. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Preparing Qt 5.0.1 release
On Fri, Jan 11, 2013 at 03:51:02PM +, shane.kea...@accenture.com wrote: > > NOTE: No cherry-picks this time !! > > > What about changes that are integrated to stable already but missed > the branch due to unrelated test failures delaying the integration? > your premise is already wrong. if it failed integration and you already knew that and when the branch will be created, then you should have abandoned, waited for the branch creation, and re-targeted the change. ergo, your fault, and you deal with the consequences (your precious change will have to wait for the next release). if you didn't know the timing of the branching (*), the fact that the first integration(s) failed is irrelevant. (*) that would be your fault, too, as iikka announced it with sufficient headroom. i'd have liked a more precise branching time specification, but otoh that just increases the risk of people making a too tight bet. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Importing Snowshoe QML browser to the Qt project
On Fri, Jan 11, 2013 at 4:47 PM, Simon Hausmann wrote: > Hi all, > > Now that Qt 5.0.0 is out I feel that it is a good time to also emphasize show > cases > of Qt and QML as a technology. In Qt 4 we've had a couple of pretty nice demos > in the source code, including a pretty neat demo browser. It serves as a > show-case > for QtWebKit's C++ API and the Qt widgets (line edit, customizable tab > widget, etc.). > > I would like to have the same for the new technologies we've been working on > in > the past years, Qt 5, QtQuick 2 and the multi-process capable WebKit > integration > into Qt. That means basically a little web browser that blends all these > technologies > together. One option is to start with a new code base from scratch, but I > would > like to explore another option first: > > Our friends at INdT started writing a little web browser with exactly that > spirit, > and to top it off: It's open source and it looks very pretty! It's got a > shiny website at > > http://snowshoe.openbossa.org/ > > and source code that is currently hosted at Github. > > So I got in touch with them and they're willing to contribute the code to the > Qt > project. I'm therefore seeking approval from the Qt project to importing > Snowshoe > into Gerrit, with > > playground/snowshoe > > as proposed location, although I admit that we do have a little problem with > the naming there as it's not in line with the guidelines: > > http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt#681f347d064c99a795cb47631e853396 > > > > Opinions? Thoughts? > > > Simon > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development WOW! I never saw that project before. It looks cool, but i can't compile it under windows.. If it looks as neat as the screenshots then i'm certainly hoping on that browser to become a chrome alternative :) It's also very nice to see my QShortcut wrapper for QML (Shortcut class) being used in there though it's modified quite a bit in there. Really interesting stuff! Do you happen to know more Qt5 projects like this? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Preparing Qt 5.0.1 release
On sexta-feira, 11 de janeiro de 2013 20.18.52, Oswald Buddenhagen wrote: > On Fri, Jan 11, 2013 at 03:51:02PM +, shane.kea...@accenture.com wrote: > > > NOTE: No cherry-picks this time !! > > > > What about changes that are integrated to stable already but missed > > the branch due to unrelated test failures delaying the integration? > > your premise is already wrong. > if it failed integration and you already knew that and when the branch > will be created, then you should have abandoned, waited for the branch > creation, and re-targeted the change. ergo, your fault, and you deal > with the consequences (your precious change will have to wait for the > next release). > if you didn't know the timing of the branching (*), the fact that the > first integration(s) failed is irrelevant. > > (*) that would be your fault, too, as iikka announced it with sufficient > headroom. i'd have liked a more precise branching time specification, but > otoh that just increases the risk of people making a too tight bet. If you think the fix is important for 5.0.1, cherry-pick yourself and resubmit to release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] ICU and Windows
> 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. > > > > Either way I feel that this needs to be fixed ASAP because we could end up > > seeing bug reports that are in effect caused by this and end up creating > > more noise as a result. A short term option (and potentially permanent) > > would be to link against a different version of the ICU libraries and point > > out that if they want to use Qt in debug they would need to build ICU > > themselves and make the relevant modifications to the output library > names. > > 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. > > I think we are taking such care (we don't free any memory allocated by ICU). > > So what exactly is the problem we need to solve? Has anyone noticed a crash, > a > warning from the C++ runtime, etc.? Is there a latent issue we just haven't > hit? Usually with this sort of thing it does not crash right away, you usually get a crash later on that looks strange and gets blamed on memory corruption, I have seen a crash that only happened in a prebuilt version of Qt which did not happen in my own build of Qt 5 which basically was an unhandled exception but I couldn't see what caused the exception since the stack trace did not give anything useful. The very same example when running on a source build of Qt worked fine. For reference the example was the browser one in the webkitwidgets examples directory crashing in the commercial 2010 binary package, it crashed every time it started up and it is because of that why I saw the mixing of the runtimes. Microsoft in the past has also said that you should keep the -MD(d)/-MT(d) setting consistent so it is the same across all libraries and applications, and I have personally seen the result of this sort of thing happening which is why I have always recommended that everything is kept consistent to prevent this sort of thing from being a problem. Granted it might be the case that we are generally very careful about it and we never really hit the problem, but wouldn't it be better to err on the side of caution and link against a debug version of ICU for the debug build of Qt? If people want to override it then we could make that easy to do but personally I think we should at least be setup to do what would be the recommended thing to prevent any undue problems. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU and Windows
> I'm no expert on the various build and link issues, but in trying to write the > new ICU backend for QLocale which would make ICU a hard requirement in > the > future I've started running into problems which may affect your choice of > solution. > > For those interested, I have working code for ICU-based number and date > formatter classes at: > http://qt.gitorious.org/~odysseus/qt/odysseus-qtbase/commits/qlocale- > icu > > Up to now I've been using the ICU C api due to ICU not providing a binary > compatibility guarantee on their C++ api between major versions. This C api > is a simplified wrapper around the C++ implementation. This works fine for > the most commonly used functions like number and date formatting, but the > C > api is completely inadequate for using the calendar and time zone functions, > which are a primary reason for switching to ICU. For example, you can't even > find out what the current time zone is via the C api, let alone create and > query a custom timezone in an efficient way. > > I'm trying to find a way around this with just the C api, but right now the > easiest solution does appear to be using the C++ api and somehow dealing > with > the binary compatibility problem. Could we make that work? > > On Linux, I have heard that some/many distro's automatically rebuild all > packages depending on ICU whenever the ICU major version changes due to > its > bad reputation. Could we simply just state that it is a requirement to > rebuild Qt if the ICU major version on a system is changed? > > On Mac, because OSX doesn't ship with the ICU headers installed, my > understanding is we currently require people to install ICU via MacPorts or > HomeBrew and build against that instead of the system ICU libraries. I don't > see that as a long-term solution when we start requiring ICU as it's not very > portable or reliable as to the version used. The alternative is to manually > install the headers from opensource.apple.com and use the system library > (how > I'm currently building), but I've heard there's been issues in the past with > published headers not actually matching? The best option is probably not to > use ICU at all on Mac, but just use the Carbon/Cocoa api which is actually > just a thin wrapper around ICU and for localization at least is complete for > our current purposes. However, I'm not sure this is an option for the other > proposed uses of ICU, such as code tables. > > On Windows, well it almost seems we have to require people to either build > their own ICU and keep it in sync with Qt, or we have to start providing it > ourselves. > > Perhaps the best solution is going to be including ICU in 3rdparty: > * On Linux always build with 3rdparty ICU, unless the distro/dev chooses to > use their system library and accepts the need to rebuild Qt with a major > version change. > * On Windows always build with the 3rdparty ICU, unless the dev wants to > use > their own and takes responsibility for maintaining compatibility > * On Mac don't use ICU for QLocale, but use the native api instead, only build > 3rdparty ICU if other features are enabled that need it. Alternatively trust > the opensource.apple.com headers and use the system library. > > One plus point to shipping in 3rdparty is that we can use a more modern > version than the ICU 4.0 we're currently stuck with due to Snow Leopard > support. The big minus is ICU is big and possibly icky to build. What you are trying to do would not be affected at all in anyway by either solution, all I want to ensure is that the ICU libraries are built with -MD when used with the release version of Qt and -MDd when used with the debug version of Qt. It doesn't effect the API of ICU at all in any way. I only suggested that we bundle the source with Qt as it would make it easier to ensure that this took place and it seems that you would also benefit from bundling as well :) Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Adding a repository in Qt Project for the Ministro tool, needed by Qt for Android
> Hi, > > As part of the Android-port of Qt 5 being contributed to the Qt Project > by BogDan, he also contributed the code for a general-purpose Android > app which is used for getting libraries and plugins on demand when a Qt > app is deployed to an Android device. This tool is called "Ministro". > > We need a repository to put it in, and the existing repositories do not > seem to fit, so I'm proposing making a new repository for this: > ministro/ministro I certainly don't mind adding the repository but I presume there will be a branding change once the Android port is made official. While "Neccessitas" and "Ministro" sounds cool, I think it would be better if we stop using those names officially and start to refer to them just as "Qt for Android" and "Qt Library Installer" or something similar and clear. I think people get a bit worried when they have to install something called "Ministro" on their phones. At least I was rather concerned the first time I installed a Qt app on my device and had to check twice. Perhaps we should name the repository accordingly? Regards, Jens ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU and Windows
[...]
> Microsoft in the past has also said that you should keep the -MD(d)/-MT(d)
> setting consistent so it is the same across all libraries and applications,
[...]
Which is cool, if you can manage it. But it's far from what happens in the
real world.
In the real world you have foreign libraries to load, doesn't matter if these
are stock libraries provided from Microsoft, from 3rd parties or even
yourself. It is not uncommon to have all kinds of memory managers mixed in one
application (some windows libraries still use MSVC6's runtime as dll).
However - like Thiago said - as long as you keep on freeing your memory
yourself and never another library's HEAP-memory, everything's fine.
Heap memory here clearly refers to memory allocated by calloc, malloc or
::operator new() as opposed to memory allocated via HeapAlloc, VirtualAlloc or
any COM-Mechanism, which are designed to be shared depending on settings.
Actually, this means: You can mix C/C++ freely. At least in the Microsoft
universe, operator new() is just a wrapper for malloc or it's debug counter-
part.
Contrary to Thaigo, I had assumed that the C++ case is in general more
problematic. I don't know for the icu-case at hand, but generally C-libraries
tend to provide a free method, like FOOLibrary_free(void*) for free'ing
memmory allocated by them.
For C++, consider this:
In library 1:
struct A{ virtual ~A(); };
void x( A* a ){ delete a; }
In library 2:
struct B : A { ~B(); };
void y(){ x( new B ); }
Whose memmory manager's free() will be used if those 2 libraries link against
different memory managers?
Sascha
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Adding a repository in Qt Project for the Ministro tool, needed by Qt for Android
On 01/12/2013 07:43 AM, Bache-Wiig Jens wrote: >> Hi, >> >> As part of the Android-port of Qt 5 being contributed to the Qt Project >> by BogDan, he also contributed the code for a general-purpose Android >> app which is used for getting libraries and plugins on demand when a Qt >> app is deployed to an Android device. This tool is called "Ministro". >> >> We need a repository to put it in, and the existing repositories do not >> seem to fit, so I'm proposing making a new repository for this: >> ministro/ministro > I certainly don't mind adding the repository but I presume there will be a > branding change once the Android port is made official. While "Neccessitas" > and "Ministro" sounds cool, I think it would be better if we stop using those > names officially and start to refer to them just as "Qt for Android" and "Qt > Library Installer" or something similar and clear. > > I think people get a bit worried when they have to install something called > "Ministro" on their phones. At least I was rather concerned the first time I > installed a Qt app on my device and had to check twice. Perhaps we should > name the repository accordingly? Makes sense to me. I was also a bit concerned although I was reading the installation guide the first time I tried back when Necessitas was still a fairly new project under Qt 4.7. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Adding a repository in Qt Project for the Ministro tool, needed by Qt for Android
On Fri, Jan 11, 2013 at 1:43 PM, Bache-Wiig Jens wrote: > >> Hi, >> >> As part of the Android-port of Qt 5 being contributed to the Qt Project >> by BogDan, he also contributed the code for a general-purpose Android >> app which is used for getting libraries and plugins on demand when a Qt >> app is deployed to an Android device. This tool is called "Ministro". >> >> We need a repository to put it in, and the existing repositories do not >> seem to fit, so I'm proposing making a new repository for this: >> ministro/ministro > > I certainly don't mind adding the repository but I presume there will be a > branding change once the Android port is made official. While "Neccessitas" > and "Ministro" sounds cool, I think it would be better if we stop using those > names officially and start to refer to them just as "Qt for Android" and "Qt > Library Installer" or something similar and clear. > > I think people get a bit worried when they have to install something called > "Ministro" on their phones. At least I was rather concerned the first time I > installed a Qt app on my device and had to check twice. Perhaps we should > name the repository accordingly? I agree that a more utilitarian (meaning less cool) name would be better for the app, but this shouldn't block the repo creation question. We can paint that bikeshed when we come to it (unless everyone immediately agrees on a new name of course). Recall that we already have repositories with embarrassingly inaccurate names, and it hasn't hurt anyone. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU and Windows
> [...] > > > Microsoft in the past has also said that you should keep the -MD(d)/-MT(d) > > setting consistent so it is the same across all libraries and applications, > > [...] > > Which is cool, if you can manage it. But it's far from what happens in the > real world. > > In the real world you have foreign libraries to load, doesn't matter if these > are stock libraries provided from Microsoft, from 3rd parties or even > yourself. It is not uncommon to have all kinds of memory managers mixed in > one > application (some windows libraries still use MSVC6's runtime as dll). [snip] Granted it is tricky to ensure it happens in the real world, but we are in the position to ensure that we do in fact do the right thing in this case then shouldn't we actually do so? Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Adding a repository in Qt Project for the Ministro tool, needed by Qt for Android
On Friday 11 January 2013 15:01:57 Alan Alpert wrote: > On Fri, Jan 11, 2013 at 1:43 PM, Bache-Wiig Jens > > wrote: > >> Hi, > >> > >> As part of the Android-port of Qt 5 being contributed to the Qt Project > >> by BogDan, he also contributed the code for a general-purpose Android > >> app which is used for getting libraries and plugins on demand when a Qt > >> app is deployed to an Android device. This tool is called "Ministro". > >> > >> We need a repository to put it in, and the existing repositories do not > >> seem to fit, so I'm proposing making a new repository for this: > >> ministro/ministro > > > > I certainly don't mind adding the repository but I presume there will be a > > branding change once the Android port is made official. While > > "Neccessitas" and "Ministro" sounds cool, I think it would be better if > > we stop using those names officially and start to refer to them just as > > "Qt for Android" and "Qt Library Installer" or something similar and > > clear. > > > > I think people get a bit worried when they have to install something > > called "Ministro" on their phones. At least I was rather concerned the > > first time I installed a Qt app on my device and had to check twice. > > Perhaps we should name the repository accordingly? > I agree that a more utilitarian (meaning less cool) name would be > better for the app, but this shouldn't block the repo creation > question. We can paint that bikeshed when we come to it (unless > everyone immediately agrees on a new name of course). > > Recall that we already have repositories with embarrassingly > inaccurate names, and it hasn't hurt anyone. > > -- > Alan Alpert > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development I must say, I like how Android project has named itself. ”Qt for Android” or similar names would bring pretty ”ee, some kind of developer project” vibe, something not mature. So I’d hugely vote for this kind of naming. Qt, too, is just a brand, and doesn’t explain what it actually is.. -- Terveisin, Samu Voutilainen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU and Windows
Am Freitag, 11. Januar 2013, 23:07:25 schrieb Shaw Andy: > > [...] > > > > > Microsoft in the past has also said that you should keep the > > > -MD(d)/-MT(d) > > > setting consistent so it is the same across all libraries and > > > applications, > > > > [...] > > > > Which is cool, if you can manage it. But it's far from what happens in the > > real world. > > > > In the real world you have foreign libraries to load, doesn't matter if > > these are stock libraries provided from Microsoft, from 3rd parties or > > even yourself. It is not uncommon to have all kinds of memory managers > > mixed in one > > application (some windows libraries still use MSVC6's runtime as dll). > > [snip] > > Granted it is tricky to ensure it happens in the real world, but we are in > the position to ensure that we do in fact do the right thing in this case > then shouldn't we actually do so? In my book, the right thing to do is - as Thiago said - to ensure that memmory allocated by library X is also freed by library X. Everything other, including the play-safe recommendation from Microsoft above, looks like a workaround to me. An additional reasoning comes to mind: If one ever wanted to use a memory profiler that is not a virtual-machine (like valgrind) or does dependency injecting but depends on code-augmentation, you won't have any luck getting this setup unless you compile all 3rd party provided code with that augmentation, too. Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal - QtSerialPort graduation from the Playground
>A cross platform compatible API for the serial port is a useful thing, >but is there a good reason for limiting it to Qt applications ? Why do you think that this is a limitation? This is just a separate, cross-platform implementation of the serial port, taking into account the Qt-specific, and designed specifically for Qt, like as QAbstractSocket, QFile and so forth... So, we are not saying that QAbstractSocket and QFile restricts/limiting use !? PS: For example, boost also has its own implementation of ... PS2: or I misunderstood your question? Best regards, Denis 11.01.2013, 11:41, "Uwe Rathmann" : > On Wed, 09 Jan 2013 21:18:40 +0100, Laszlo Papp wrote: > >> Another try: can we reiterate this question for 5.1? > > Several years ago I was asked if I would accept the ( at that time > orphaned ) qextserialport project as module of Qwt. > > I decided not to do so because its code was more or less unrelated to Qt > - beside a couple of lines building an QIODevice. > > A cross platform compatible API for the serial port is a useful thing, > but is there a good reason for limiting it to Qt applications ? > > Uwe > > ___ > 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
[Development] QT5.0 does not create VC2010 Projects
Is it known issue that QT5.0 does not create VC2010 Projects? Thanks ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
