Re: [Development] Use QT_DEPRECATED_SINCE macro for specific enum values
On Wed, Aug 12, 2015 at 11:54 AM Denis Shienkov denis.shien...@gmail.com
wrote:
skips three making Four == 3.
yes, and what? :)
This obviously needs to be:
Four = 4
Ok, seems it was a bad example with One-Four.. Let's consider another
abstract example:
enum Foo {
A,
B,
#if QT_DEPRECATED_SINCE(5, 2)
C,
#endif
D
};
From your example, the initial values are the following:
A = 0
B = 1
C = 2
D = 3
If you remove C due to the macro, then D is now equal to 3 from
incrementing its value based off of B's value instead of C.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QVersionNumber: someone to polish and finish the API
On Wed, Jul 8, 2015 at 12:10 PM Thiago Macieira thiago.macie...@intel.com wrote: On Wednesday 08 July 2015 12:07:20 Keith Gardner wrote: Please take the patches starting at https://codereview.qt-project.org/95531. Follow the chain of dependency. Would you like someone to pick up those changes and finish them for you? I am just asking since you started many of them but I know you have a lot on your plate. That's exactly what I want. The only change that I would not feel comfortable modifying is https://codereview.qt-project.org/#/c/95533/. That change is outside my skill set. Like Marc said, it's already approved. I need someone to apply, verify that the whole series works still, and finish the polishing that Marc initiated after my commits. Many of the patches have been cleaned up and merged. The one patch that needs to be approved before all other patches can be completed is https://codereview.qt-project.org/#/c/95533/. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QVector now has rvalue push_back (was: Re: HEADS UP: potential trouble from a recent QVector change)
On Tue, Jul 21, 2015 at 12:49 PM Gunnar Roth gunnar.r...@gmx.de wrote:
void push_back(T t) {
ensureCapacity(size() + 1);
new (m_end) T(std::move(t));// move-construct
from t
++m_end;
why is std::move needed here? Afaik std::move(t) converts t into a rvalue
ref, but t is already an r-value ref.
The rule of thumb is if you can get the address of the object, then it is
an l-value. It may be an r-value going into the function but once in the
function, you can get its address. You need to use std::move to treat data
as an r-value again.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QVector now has rvalue push_back (was: Re: HEADS UP: potential trouble from a recent QVector change)
On Mon, Jul 20, 2015 at 1:11 PM Thiago Macieira thiago.macie...@intel.com wrote: On Monday 20 July 2015 14:06:33 Marc Mutz wrote: https://codereview.qt-project.org/121810 So start using qMove() or pass temporaries in your QVector::append() calls. What's the difference in std::vector between an rvalue push_back and emplace_back? emplace_back takes variadic template arguments to construct the item directly in the vector instead of creating a temporary and then performing a move operation. If the template argument is just an rvalue of the container type, it will perform just like the rvalue push_back function. http://en.cppreference.com/w/cpp/container/vector/emplace_back ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: RAII for property changes
On Wed, Apr 15, 2015 at 9:38 AM Marc Mutz marc.m...@kdab.com wrote:
Hi André,
On Wednesday 15 April 2015 11:49:56 André Somers wrote:
void MyClass::setFoo(QString value)
{
PropertyGuard guard(this, foo); //foo is the name of the Q_PROPERTY
Q_UNUSED(guard);
m_foo = value;
}
This is an interesting idea, though I don't think I have encountered the
problems with which you motivate PropertyGuard.
For use in a library, though, I fear the string-based mechanism is too
inefficient. For use within QtWidgets, say, I'd suggest a mechanism that
works
on the member data directly.
Thanks,
Marc
I have actually run into the same situation and made a template class that
owns the variable. Its constructor takes an initial value and a
std::functionvoid (const T) as a callback for when the value changes.
The callback can be a lambda or a std::bind to the expected signal. I also
added overloads to allow for the templated class to behave just like the
contained type so that it can be swapped in easily. I figured the Qt
project wouldn't like the submission of the class due to its template
nature and its use of std::function but i am willing to share it if anyone
is interested.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: RAII for property changes
I'd certainly be interested to seeing how you solved this, yes. Thanks! I have made a repository for the class with an example. Sorry that there is no documentation for it. It requires C++11 support for r-value references, std::functional, and some type traits features. In addition to having a notify callback, it also provides an optional pre-notify callback to let you know the current value and the value it will change to. https://github.com/kreios4004/Property_Class ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: RAII for property changes
On Wed, Apr 15, 2015 at 2:20 PM Andre Somers an...@familiesomers.nl wrote:
On 15-4-2015 21:05, Keith Gardner wrote:
QPropertyGuard g{this};
g.addProperty(a); // use QObject::property
g.addProperty(b, m_b); // take value member by reference
g.addProperty(m_c, cChanged); // ...and also slot address
There's type erasure going on, so it will allocate memory. Allocating
memory
in a setter that might just change an int is what I call inefficient.
Would something like this be better?
// constructor
// Provide an initial value and a std::function to notify about the change
Propertybool m_example = Propertybool(false, [](bool value){
emit exampleChanged(value);
});
// getter
bool *::example() const {
return m_example;
}
// setter
void *::setExample(bool value) {
m_example = value;
}
The working code for this example can be found
https://github.com/kreios4004/Property_Class.
Thank you for posting that.
I took a look at it, but I am not sure it actually solves much. It moves
the check if something changed to the wrapped variable, but it makes using
that value then more complicated. Instead of using the variable directly,
one now has to go through m_example.getValue() everywhere.
This is partially true. If it is containing a class or a struct, then you
are correct. If it is an int or float and you want to perform some math
operation with it, it has the operator const T() to perform the get
automatically.
Not pretty, I think. The case of modifying more than one property in one
go is also not solved. On the one hand, dependent properties (such a
isValid property) are not updated unless you manually write that code
again, and on the other hand if you use this to set more than one property
in a method, you still are sending signals at the point the class is in an
inconsistent state.
True. My goal was to perform a type safe way of change detection so I
wouldn't have to write the boilerplate code over and over. It also
provides a way customize the way the signal is called in the callback. It
does suffer in the more complex scenarios when more than one operation is
happening to the object.
One nice side effect of my implementation is that the notification is
actually only send once. Even if the property value is changed multiple
times in the meantime, you still get only one notification. That can be
very convenient, even if you don't use it much.
This is very appealing.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: RAII for property changes
QPropertyGuard g{this};
g.addProperty(a); // use QObject::property
g.addProperty(b, m_b); // take value member by reference
g.addProperty(m_c, cChanged); // ...and also slot address
There's type erasure going on, so it will allocate memory. Allocating
memory
in a setter that might just change an int is what I call inefficient.
Would something like this be better?
// constructor
// Provide an initial value and a std::function to notify about the change
Propertybool m_example = Propertybool(false, [](bool value){
emit exampleChanged(value);
});
// getter
bool *::example() const {
return m_example;
}
// setter
void *::setExample(bool value) {
m_example = value;
}
The working code for this example can be found
https://github.com/kreios4004/Property_Class.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing the -c++11 option from configure
More. That's at least a dozen in the configure script, since we need to ensure someone didn't pass the impossible combination -c++14 -no-c++11. Why not make it a switch for highest language support. Instead of -no-c++11, make it -c++03. This would allow for adding -c++1z in the future without adding the -no-c++* all over. This will also handle the contradictory -c++03 and -c++14 being in the same configure args since the existence of -c++14 is the highest requested. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ListView + TextEdit tricky behavior
On Tue, Sep 30, 2014 at 7:55 AM, Matías Néstor Ares matna...@gmail.com
wrote:
Hi everyone!
I'm developing an app with Qt, and I'm having some issues.
I don't get a proper answer from the forums yet.
So I ask it here, sorry if it is not the correct place.
The problem description is on this post:
http://qt-project.org/forums/viewthread/47948/
And a video of the symptom here:
https://www.youtube.com/watch?v=1sHKnNZLzhs
Thanks In Advance
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Matias,
I think the problem is that you are expecting your items to retail the
typed text instead of your model. I think the ListView destroys delegates
that are not within the view. Since your model is not retaining the typed
text, this would explain why it is going away. I modified your delegate to
show that this is the problem.
delegate: Item {
width: 100
height: 40
Component.onDestruction: {
console.debug(Item destroyed)
}
Rectangle {
width: 100
height: 40
color: colorCode
TextEdit {
font.pointSize: 23
anchors.fill: parent
font.bold: true
anchors.verticalCenter: parent.verticalCenter
}
}
}
Keith
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ListView + TextEdit tricky behavior
On Tue, Sep 30, 2014 at 8:35 AM, Mitch Curtis mitch.cur...@digia.com
wrote:
On 30/09/14 14:55, Matías Néstor Ares wrote:
Hi everyone!
I'm developing an app with Qt, and I'm having some issues.
I don't get a proper answer from the forums yet.
So I ask it here, sorry if it is not the correct place.
The problem description is on this post:
http://qt-project.org/forums/viewthread/47948/
And a video of the symptom here:
https://www.youtube.com/watch?v=1sHKnNZLzhs
Thanks In Advance
___
Development mailing
listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development
A hacky solution is below. It's just to point out that the state (text
input) should be stored outside the delegates, as people are mentioning -
in this case, it's stored in textArray.
delegate: Item {
width: 100
height: 40
Rectangle {
width: 100
height: 40
color: colorCode
TextEdit {
id: textEdit
font.pointSize: 23
anchors.fill: parent
text: textArray[index]
onTextChanged: textArray[index] = textEdit.text
font.bold: true
anchors.verticalCenter: parent.verticalCenter
}
}
}
}
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
For the TextEdit, the item should just load and store directly to/from the
model, no array needed.
TextEdit {
id: textEdit
font.pointSize: 23
anchors.fill: parent
text: model.modelData.text
onTextChanged: model.modelData.text = text
font.bold: true
anchors.verticalCenter: parent.verticalCenter
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
On Thu, Jul 10, 2014 at 8:47 AM, Kobus Jaroslaw jaroslaw.ko...@digia.com wrote: Hi All, With the current state of QVersion (patchset 35) I see the following issues: 1. operator() doesn't take the suffix into account (mentioned below) 2. There is no handling of sub version (you cannot differentiate 5.0.0, 5.0 and 5 - they are all equal) The idea which could resolve these issues would be not to keep the suffix inside a QVersion class. I understand that there is a need for version numbers consisting of some labels for preliminary versions. That's why the idea is to provide a mechanism for preliminary versioning system in first place, and then resolve the labels problem with a simple number/string substitution. The problem is that the suffix does not represent just preliminary versions. Some projects use the suffix to represent releases as well. E.g. OpenSSL 1.0.1h Other projects store the git SHA in the version suffix that has nothing to do with the version number. The conclusion was that the suffixes are semantic dependent and there are too many semantics out there to come up with one solution. Simple number/string substitution implies that there is a version semantic already in place. The mentioned mechamism for preliminary versions would operate also on numbers, but one segment of the QVersion would be distinct. This distinct segment (call it preliminary segment) would be the indication for the comparator to treat that segment (and followed segments) in a special way (i.e. if we compare the preliminary segment with normal one, we say that preliminary is always less than normal one, even if its numerical value is greater). For now, in QString version for a QVersion, I will use * for this distinction. Example: All below are preliminary versions: 5.4.0.*0 - the very first alpha version for the upcomming 5.4.0 release. 5.4.0.*1.1 - beta 1 release 5.4.0.*1.2 - beta 2 release 5.4.0.*2.1 - rc 1 release 5.4.0.*2.2 - rc 2 release And finally there is: 5.4.0 - we plan to release that, no preliminary marker How would this handle an alpha release marker as mentioned above? Also would -alpha and alpha have the same weight or would one have priority over the other? There are also projects that use a suffix of -1 to indicate a second release with the same version number. How would the number/string substitution support this? Later, we prepare for 5.4.1, we release in meantime: 5.4.1.*0, and so on... So, I propose to keep inside QVersion only segments and index of the preliminary segment, and drop suffix. I do think your approach has its merits but it makes too many assumptions about how the suffix is structured. Check out Semantic Versioning ( http://www.semver.org) and compare how they structure their suffixes to some of your assumptions. I want to emphasize the examples in Rule 10 show how crazy the suffixes can be and how some of the content cannot be used in ordering. You do bring up some good points and I will need to think on them for a bit. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
On Sat, May 31, 2014 at 2:00 PM, Thiago Macieira thiago.macie...@intel.com wrote: Em sex 09 maio 2014, às 11:36:08, Keith Gardner escreveu: I have been working on adding a class to QtCore (QVersion) to support storing version numbers, convert to/from QString, and having comparison operators. My goal was to provide an API to assist in the following use cases: - Plugin loading where there are multiple versions on the same system. - File format validation. - Executing an already installed command line application where the behavior is dependent on the called application's version. - Performing software installations and updates. - QMake support for version number comparisons. Please share other potential use cases where this might be useful. Ok, since we can't seem to agree, let's settle on the maximum common denominator: QVersion will only compare the numeric part of a version number. By default, two versions with the same numeric part will compare equally, regardless of any suffixes that may be present. Therefore, by default, given: QVersion a(5.3.0); QVersion b(5.3.0pl1); QVersion c(5.3.0beta1); a != b != c;// since they aren't equal QVersion::compare(a, b) == 0; QVersion::compare(b, c) == 0; In the review of the change, a potential issue with this form of compare with the operators when using QVersion as the key in a QMap. Here is the scenario: QVersion a(5.3.0alpha); QVersion b(5.3.0beta); a != b; //true a b; // false QMapQVersion, QFoo map; map[a] = foo1; map[b] = foo2; With the example, map[a] now is set to foo2 which is incorrect since 'a' != 'b'. This is not an issue with QHashQVersion, QFoo since the suffix is included into the hashing of a QVersion. How should we resolve this conflict with ordering without applying a semantic compare to the suffix? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
On Thu, Jul 10, 2014 at 7:31 AM, Olivier Goffart oliv...@woboq.com wrote: On Monday 02 June 2014 13:24:55 Richard Moore wrote: On 2 June 2014 13:12, Keith Gardner kreios4...@gmail.com wrote: On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann simon.hausm...@digia.com wrote: I suggest a name that is more centric towards the _function_ of the class, comparison of different software versions. QVersionInformation was also proposed as a name in the code review. I don't have a problem with changing the name other than it is really long for a simple class. How about QVersionComparator? How about qVersionCompare(const QString, const QString)? Yes, that's a function. Is there really the need for a class to hold just a version string? And there could be an overload with a SuffixComparator. (or is qCompareVersion an even better name?) Currently, the QVersion::compare has an overload to pass a functor that performs the suffix comparison. Are you suggesting having a default in the operators that can be overwritten? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann simon.hausm...@digia.com wrote: On Saturday 31. May 2014 15.02.49 Keith Gardner wrote: [...] And then you'd use: QVersion::compare(a, b, myCompare); Big +1 to everything. This approach should serve everyones' use cases; let's get this integration rolling. I can agree to that. I will have an update this weekend with this spec. On the topic of this new class, I'd like to suggest a name different from QVersion. We have had a global function qVersion() for a long time and I'm worried that a class name QVersion (as it appears in code completions, etc.) might mislead users to thinking that it is related to the version of Qt, which it isn't. I suggest a name that is more centric towards the _function_ of the class, comparison of different software versions. QVersionInformation was also proposed as a name in the code review. I don't have a problem with changing the name other than it is really long for a simple class. As for the qVersion() function, I was thinking of adding some static functions to get a QVersion of the compiled version compiled and runtime versions of Qt. I was planning on adding these two functions in a new patch because of the duplication of functionality would have its own discussion. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
On Mon, Jun 2, 2014 at 7:33 AM, Jake Petroules jake.petrou...@petroules.com wrote: On 2014-06-02, at 08:24 AM, Richard Moore r...@kde.org wrote: On 2 June 2014 13:12, Keith Gardner kreios4...@gmail.com wrote: On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann simon.hausm...@digia.com wrote: I suggest a name that is more centric towards the _function_ of the class, comparison of different software versions. QVersionInformation was also proposed as a name in the code review. I don't have a problem with changing the name other than it is really long for a simple class. How about QVersionComparator? QVersionComparator sounds like something you'd pass to a QVersion in order to customize the comparison algorithm. QVersion is an object which represents a version; comparison is an auxiliary function to its identity. I agree with Jake. The class is a container first and then it has comparison operators. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
On Sat, May 31, 2014 at 2:09 PM, Jake Petroules
jake.petrou...@petroules.com wrote:
On 2014-05-31, at 03:00 PM, Thiago Macieira thiago.macie...@intel.com
wrote:
Em sex 09 maio 2014, às 11:36:08, Keith Gardner escreveu:
I have been working on adding a class to QtCore (QVersion) to support
storing version numbers, convert to/from QString, and having comparison
operators. My goal was to provide an API to assist in the following use
cases:
- Plugin loading where there are multiple versions on the same system.
- File format validation.
- Executing an already installed command line application where the
behavior is dependent on the called application's version.
- Performing software installations and updates.
- QMake support for version number comparisons.
Please share other potential use cases where this might be useful.
Ok, since we can't seem to agree, let's settle on the maximum common
denominator: QVersion will only compare the numeric part of a version
number.
By default, two versions with the same numeric part will compare equally,
regardless of any suffixes that may be present.
Therefore, by default, given:
QVersion a(5.3.0);
QVersion b(5.3.0pl1);
QVersion c(5.3.0beta1);
a != b != c; // since they aren't equal
This seems to contradict your previous statement, unless you're speaking
conceptually here.
To confirm, as far as the code goes, ((QVersion(5.3.0pl1) ==
QVersion(5.3.0beta1)) === true), yes?
QVersion::compare(a, b) == 0;
QVersion::compare(b, c) == 0;
We will also provide an overload for the QVersion::compare function taking
a
functor:
template typename SuffixCompare static inline int
compare(const QVersion a, const QVersion b, SuffixCompare suffixCompare)
{
int cmp = compare(a, b);
if (cmp)
return cmp;
return suffixCompare(a.suffix(), b.suffix());
}
Thus, if you want to implement a comparison like OpenSSL's, you can do:
QVersion::compare(a, b,
[](auto a, auto b) {
return QString::compare(a, b, Qt::CaseInsensitive);
});
If you want a more complex comparison like I had wanted, you'd do:
static int priorityOrder(const QString suffix)
{
if (suffix.isEmpty())
return 0;
return suffix.startsWith(alpha) || suffix.startsWith(beta) ||
suffix.startsWith(rc) ? -1 : 1;
}
static int myCompare(const QString a, const QString b)
{
int a_prio = priorityOrder(a);
int b_prio = priorityOrder(b);
if (a_prio != b_prio || a_prio == 0)
return a_prio - b_prio;
return QString::compare(a, b, Qt::CaseInsensitive);
}
And then you'd use: QVersion::compare(a, b, myCompare);
Big +1 to everything. This approach should serve everyones' use cases;
let's get this integration rolling.
I can agree to that. I will have an update this weekend with this spec.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
1. Numerical groupings should be compared integers instead of characters in order to properly allow for alpha2 alpha11. 2. Delimiters should only be used to denote groups of content but be skipped during the compare. alpha == -alpha == ~alpha == .alpha 1. Can be restricted to the first character if this is too broad. Given that we're numbering things, your last point would probably be better- numbered 3 instead of 1 again, right? It was actually suppose to be a sub item to 2 but it looks like the tabbing was lost. Note also that version number schemes for particular software are not constant over time. https://blog.qt.digia.com/blog/2009/09/03/qt-4th-edition-feature-pack-7/ Are Windows versions in scope? Are you referencing kernel versions or how the OS embeds version numbers into binaries? If it is the latter, support is there since they are strictly four numerical segments. I changed grantlee versions to drop a 'v' at some point. http://www.grantlee.org/downloads/ I'm sure there are other examples in the past and in the future. I didn't read closely enough to see if that affects your proposal at all. At this moment, the 'v' is optional and if present, will be ignored. My bikeshed color is that a version comparator should only do 'component-wise numeric comparison' and shouldn't also try to handle prefixes and suffixes etc. I'm just adding that because I don't really support any side of this discussion beyond bikeshedding. I like the color of your bikeshed. I personally think prefixes are the most ambiguous out of all the potential parts to a version number and I would prefer to not include them. Suffixes were initially not on my radar but others responses have convinced me that the desire to have them is there. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
Well, if you use a virtual, you'd simply subclass to handle the specific format for your project. I haven't thought about using inheritance to simplify the compare but I think that would provide the best compromise. What are your thoughts about comparing a QVersion to a QSpecializedVersion or a QSpecialized1Version to a QSpecialized2Version since both would have different isNonNumericalSectionLessThan functions? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
but then there is also the semantical perspective. keith's last proposal i saw considered only numerical segments specially. Did you intend to say suffix? What I wrote on May 11th spoke specifically to the suffix compare: From what I have found, there are some key words that can be used to identify if a suffix is a pre-release (alpha, beta, ...). I would propose that the existence of these words be used to identify this suffix but still perform the compare lexicographically. Also, we should not support the abbreviated forms since the abbreviated forms collide with single letter release suffix. Since the checking for the existence for some keywords could be expensive, I was thinking about checking for the words when the suffix is being set and not in the compare operation itself. This would allow for multiple compares to occur without the overhead of rechecking the same string. For release versions, I cannot determine any notation that clearly defines a release suffix other than not containing the list of keywords mentioned above. Other comparison rules: 1. Numerical groupings should be compared integers instead of characters in order to properly allow for alpha2 alpha11. 2. Delimiters should only be used to denote groups of content but be skipped during the compare. alpha == -alpha == ~alpha == .alpha 1. Can be restricted to the first character if this is too broad. Here is an opinion that I think should be made a rule: lexicographical compares should be case insensitive. I don't know of any projects that use case to denote a specific version but I have seen case change for the same version. The biggest example is rc where it has been RC in some documentation but delivered as rc. I think this would be a good idea, but changing it to case sensitive would be trivial. Even with numerical segments, the current implementation supports decimal, hexadecimal, and octal. Even with Semantic Versioning, numerical segments by definition can only contain numbers, anything else will be included in the suffix. but some versioning schemes may treat letters in a numeric way (aa z). heck, there are projects which use hexadecimal notation. there is just no way to make an universal internal representation of that, which means the class' main purpose (comparing versions) cannot be satisfied. I also stated I am not proposing that we support every version number policy out there but what is the most common cases so that we can cover the majority. There are a lot of semantics out there that contradict each other and only those projects can compare their own version numbers perfectly. There is also the detection of pre-release versus release that needs to be dealt with. I proposed a way of handling that in a way that is generic and covers the majority of the software. Beyond that, we cannot know the weird policies that the project is using, so we need to provide a comparing mechanism that can deal with the majority. There is no issue in saying that if a developer cannot use this class for a niche versioning semantic, they are welcome to use a different solution. This is true about threading, networking, dbus, etc... Also, keep in mind that the numerical segments have a higher priority in the compare than the suffix. This issue is a specific case where the numerical segments are deemed equal and need to check the suffixes to complete the compare. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
On Tue, May 13, 2014 at 3:06 PM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: On Tue, May 13, 2014 at 12:59:10PM -0500, Keith Gardner wrote: but then there is also the semantical perspective. keith's last proposal i saw considered only numerical segments specially. Did you intend to say suffix? What I wrote on May 11th spoke specifically to the suffix compare: i mean much more than suffixes: post-3.5.1 (fail, everything's a suffix) There has to be some restrictions on tokenizing a version number. Except using this format in a conversation context, can you provide an example of it used as an application or library's version number. I am not trying to be argumentative, I want to understand your perspective in context. I have never seen it before. 4:2.4.5 (fail, colon was not a valid number separator last time i checked) This one has been requested by Thiago and Sune. Thiago said to skip it if it will clutter the API but I can add it since it is a part of two different specs (rpmver and dpkg). r12345 (fail, you hardcoded only 'v' as a skippable prefix) Does r stand for release version or revision? In this case, there is not enough context to determine the intent behind the use of 'r'. In the case of 'v', there is less ambiguity. and these are just the examples i'd call sane. my point is that this class is becoming unreasonably complex for a rather trivial thing, which only a fraction of the applications will use. Your argument is backwards, the problem is complex and the approach is simple. You have spent many emails arguing that there are many different methods of version numbers and that we cannot satisfy all of them. I agree that only a fraction of the applications will use this API, but that is still greater than zero. In my applications, I heavily rely on version number comparisons. imo, the cases which are fully under the user's control (internal version checking) should be handled solely numerically (even without considering any pre-releases), which basically means a minimalistic semver(-like) implementation which can be fully inline (or even just a collection of macros). in this segment, it is entirely unreasonable to try to support existing users with bizarre versioning schemes, because they most likely already have their own solutions. and new users can be told to use the straight-forward system. With that perspective, we can accomplish that now by just dropping the suffix, which was what my initial proposal for QVersion was. The request to include suffix information came from the reviewers and this mailing list. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
- Plugin loading where there are multiple versions on the same system. - File format validation. - Executing an already installed command line application where the behavior is dependent on the called application's version. - Performing software installations and updates. - QMake support for version number comparisons. Four of the five of those require parsing input that other people create. this is rather obviously a no-win situation. the only use case for an actual class i buy is the first one (and maybe the fourth one), which can be cleanly implemented with a minimalistic implementation of semver. I would say that scenario two does exist but it is a rare one. Scenario three has come up more than once for my own projects. It also ties in closely with scenario 5. For example, I want to enable c++11 features in gcc if the version number is 4.4 or greater and c++1y features in versions 4.8 or greater. First, you have to call gcc --version and parse the result. Then you have to manually perform the version comparisons in an unreliable fashion. I have done this in CMake easily since it has limited version number comparison functionality but the features are lacking in QMake. Scenario four applies to the Qt Installer Framework very pointedly. independently from that, we can implement a plain natural compare function for strings (which treats groups of digits as numbers, not as unicode values). This would depend on if the normal use case is to compare pre-release versions against released versions. If this is, we need to hear it on the mailing list. So far, at least four developers have shown a desire for this use case. any a-priori transformations needed to make it actually work with random versioning schemes are highly specific, and should therefore be left to the user. arbitrary policies totally do not belong into a generic low-level class in qtcore. Could you please describe specifically what parts from my previous email are deemed random. I would agree that the one labeled my opinion could be deemed random and if there was a strong disagreement with it, I would be willing to compromise. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
1. Usually more condensed than the pre-release. 2. Some projects experience multiple releases with the same version of software (1.0.0-2). 3. Libjpeg and OpenSSL use a single letter to represent a level of security for some software (1.0.0g). openssl actually use a multi-letter suffix once it gets high enough. The next version of openssl 0.9.8 will be 0.9.8za. From what I have found, there are some key words that can be used to identify if a suffix is a pre-release (alpha, beta, ...). I would propose that the existence of these words be used to identify this suffix but still perform the compare lexicographically. Also, we should not support the abbreviated forms since the abbreviated forms collide with single letter release suffix. Since the checking for the existence for some keywords could be expensive, I was thinking about checking for the words when the suffix is being set and not in the compare operation itself. This would allow for multiple compares to occur without the overhead of rechecking the same string. For release versions, I cannot determine any notation that clearly defines a release suffix other than not containing the list of keywords mentioned above. Other comparison rules: 1. Numerical groupings should be compared integers instead of characters in order to properly allow for alpha2 alpha11. 2. Delimiters should only be used to denote groups of content but be skipped during the compare. alpha == -alpha == ~alpha == .alpha 1. Can be restricted to the first character if this is too broad. Here is an opinion that I think should be made a rule: lexicographical compares should be case insensitive. I don't know of any projects that use case to denote a specific version but I have seen case change for the same version. The biggest example is rc where it has been RC in some documentation but delivered as rc. I think this would be a good idea, but changing it to case sensitive would be trivial. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
Let's not make it that complicated. If the suffix is one character, assume that it stands for a released version. If the suffix is greater than one character, assume it references a pre-released version. With this rule, comparisons will work properly. 1.0.0beta 1.0.0 1.0.0b. On Sat, May 10, 2014 at 1:18 PM, Jake Petroules jake.petrou...@petroules.com wrote: On 2014-05-10, at 02:11 PM, Thiago Macieira thiago.macie...@intel.com wrote: Em sáb 10 maio 2014, às 14:03:10, Jake Petroules escreveu: With all the debate, I'm beginning to think that having distinct formats available to conform to might not be such a bad idea after all (SemVer, RpmVer, Dpkg, Freeform, etc...). So how do you mean 1.0.0b compare greater than 1.0.0? (OpenSSL) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development OK, if suffix begins with '-', compare empty, else, compare empty. -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation ___ 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] Adding support for version number comparisons
On Sat, May 10, 2014 at 2:28 PM, Jake Petroules jake.petrou...@petroules.com wrote: And what about 1.0.0b2? Wouldn't you expect that to be greater than 1.0.0b? The problem with trying to implement one comparison algorithm is that there are so many different versioning formats in use (at least, within the suffix part) that it's nearly impossible to do something that works reasonably well for all of them at the same time. At the absolute least we should have some means to use a custom suffix comparison (compare() overload that takes a function as a parameter?). Correct me if I am wrong but it sounds like there needs to be some additional information to perform the compare. It looks like the suffix needs to be labeled as pre-release or release for each version. Instead of putting that into the compare, it could be a member variable for the QVersion. This would allow for 1.0.0b2 to compare properly with 1.0.0beta without providing extra flags and the label will follow the instance of QVersion. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
Anyway, given that this is going to be complex, I propose we make up our own list and *document* it. I think that to come up with our own list, we need to identify the tree different types of suffixes that we are talking about: pre-release, null, and release. The null suffix is obvious, 1.0.0, but we should define what the pre-release and release ones look like. Below are my thoughts about some characteristics for the two difficult types. Pre-release Suffixes: 1. Usually has some keywords identify it: alpha, beta, gamma, and rc. 2. These keywords can be anywhere in the suffix and can potentially be abbreviated to a single character [1]. 3. These keywords can have an optional numerical index. 4. Some projects use repository identifiers: svn commit number, git SHA, build ID. 5. As seen in this email chain, there are many different types of delimiters (- ~ .). Release Suffixes: 1. Usually more condensed than the pre-release. 2. Some projects experience multiple releases with the same version of software (1.0.0-2). 3. Libjpeg and OpenSSL use a single letter to represent a level of security for some software (1.0.0g). 4. Repository identifiers also are used, i.e. XCode's clang copy. 5. Multiple types of delimiters are used as well. What am I missing in these lists and how should we go about supporting them? I am not proposing that we support every version number policy out there but what is the most common cases so that we can cover the majority. [1] http://en.wikipedia.org/wiki/Software_versioning#Pre-release_versions Thanks, Keith ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Adding support for version number comparisons
Greetings, I have been working on adding a class to QtCore (QVersion) to support storing version numbers, convert to/from QString, and having comparison operators. My goal was to provide an API to assist in the following use cases: - Plugin loading where there are multiple versions on the same system. - File format validation. - Executing an already installed command line application where the behavior is dependent on the called application's version. - Performing software installations and updates. - QMake support for version number comparisons. Please share other potential use cases where this might be useful. I am not restring the use of this class for just Qt's needs and that is where a lot of discussion about functionality has come up. You can see the progress for this patch at https://codereview.qt-project.org/82170. The current implementation supports 0 to N numerical segments and a QString suffix. Currently, the restrictions for numerical segments are that they cannot be negative. The restrictions for the suffix are that it cannot start with a number and it cannot contain any white space. Beyond that, there are some things that need to be defined: 1. What level of support for Semantic Versioning 2.0.0 ( http://www.semver.org) should be supported? 2. What semantics should be used for version comparisons? Numerical segments are more clearly defined but when introducing a non-null suffix, many different methods are being proposed. 1. Should suffixes be compared purely lexicographically? Case sensitive or insensitive? 1. e.g. 1.0-beta11 1.0-beta2 1.0-Beta2 2. Should numerical portions in a suffix be pulled out compared differently? 1. e.g. 1.0-beta2 1.0-beta11 3. Should the suffix be checked for key words to assist in comparisons? 1. alpha 2. beta 3. gamma 4. rc 4. Should there be a special case where single character suffixes have a higher precedent to multi-character suffixes? 1. e.g. 1.0alpha 1.0 1.0a 3. Are there any other versioning semantics that should be supported? The biggest question of all, should this even be included in QtCore? Thanks, Keith ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Request] Add Info to QDebug
On Mon, Dec 23, 2013 at 7:42 AM, Thiago Macieira thiago.macie...@intel.comwrote: On segunda-feira, 23 de dezembro de 2013 14:06:07, Kurt Pattyn wrote: - Warning: is a notice that something went wrong, but it might not affect the application. You can disable it with QT_NO_WARNING_OUTPUT since is not that important. Warnings are not errors, and do not require immediate action; example: file system is 80% full. They normally indicate that something might go wrong in the future if no action is taken. True, but that's now how we use them in Qt. We use them as programmer error, parameters are invalid or unknown condition happened, but stuff that we managed to continue from. The proposal is not to mimic the syslog events, but at least to have a more fine-grained control over the log messages. Most logging systems have the info and error severity levels. Here is a small overview together with a potential mapping to qDebug, qInfo, …: I see arguments for and against a qError, but I haven't seen an argument against qInfo. I believe that regardless of the outcome for qError, I think the addition of a qInfo would be greatly welcomed. I would like to present to the user some runtime information that is not intended for debugging but could be some good metrics about how the application is performing. This also flows nicely with the logging framework as well. Keith ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Clang (trunk) no longer builds Qt applications
On Tue, Oct 22, 2013 at 8:15 AM, Tobias Hunger tobias.hun...@digia.comwrote:
Hello,
I just noticed that clang from trunk is no longer able to build Qt
applications. This is due to a change which makes clang consider break
statements outside of a loop body or switch statement illegal.
Unfortunately this triggers on each Q_FOREACH/foreach used by Qt
applications!
The following code:
QListQObject * m_components obj1 obj2;
foreach (QObject *component, m_components) {
...
}
will get expanded to:
for (QForeachContainer__typeof__(m_components)
_container_(m_components); !_container_.brk _container_.i !=
_container_.e; __extension__ ({ ++_container_.brk; ++_container_.i; }))
for (QObject *component = *_container_.i;; __extension__
({--_container_.brk; break;})) {
...
}
which Clang now considers an error and will produce the following message
error: 'break' statement not in loop or switch statement body
stopping the build.
Apparently that is exactly what the C++ standard requires. Based on my
limited understanding of the details of the standard the condition in
the for statement is not part of the loop body. Is there somebody with a
deeper knowledge of the standard that can provide some insights here?
http://llvm.org/viewvc/llvm-project?view=revisionrevision=193073 is the
relevant change that introduced this diagnosis into clang.
http://llvm.org/bugs/show_bug.cgi?id=17650 is the bug I just filed with
Clang, making them aware that they broke the build of basically all Qt
applications out there. The commit massage states that gcc rejects the
code -- which is wrong as I can build QtC fine using gcc.
I hope the clang project will consider to disable this patch (or at
least have a switch to turn it off again).
But IMHO we need to address this in Qt, too.
Best Regards,
Tobias
Couldn't Q_FOREACH/foreach use the range based for loops if the compiler
supports it? This way, there is no C++ trickery to enable the feature.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Conditional Deprecation Warnings
The Q_DECL_DEPRECATED_CONDITIONAL turned out to be more limited than I was anticipating. I think using Q_DECL_DEPRECATED_X surrounded by ifdefs would be more explicit and accurate. On Wed, Oct 16, 2013 at 8:36 AM, Olivier Goffart oliv...@woboq.com wrote: On Saturday 12 October 2013 18:33:00 Keith Gardner wrote: I had an idea about making conditional deprecation warnings for functions in Qt based on the destination platform. That might be useful, actually. But not for this case. Trying to call nativeArguments() on a non-Windows platform already signals the problem with a full error. It's impossible to ignore this. Here are my changes: Added Q_DECL_DEPRECATED_X(text) https://codereview.qt-project.org/#change,68028 Maybe there should also be a QT_DEPRECATED_X to go with QT_DEPRECATED and we should use QT_DEPRECATED_X ourselfs. Added Q_DECL_DEPRECATED_CONDITIONAL(conditional, text) https://codereview.qt-project.org/#change,68040 Is there really an advantage of using this, which cannot work with complex expression vs. #ifdef Q_OS_WIN Q_DECL_DEPRECATED_X(Not avaialble on windows) #endif void myFunction(); -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 Testing (System tray)
It looks like they are trying to create their own QPA plugin for Qt5. For the appmenu changes, they reference the changes they made to the Qt4 source code and are porting to a Qt5 QPA plugin. I would assume that changes for the system tray icon would also be included in the plugin. https://bugs.launchpad.net/appmenu-qt/+bug/1157213 On Mon, Oct 14, 2013 at 11:17 AM, Jiergir Ogoerg f35f22...@gmail.comwrote: I see, you guys don't have time (motivation or whatever) to look closer into this issue. At least I tried. As to Ubuntu's popularity - I don't like Canonical nor Ubuntu - but I have to use it cause it sucks less than other distros I tried out and regardless of the platitudes about popularity we can get into - it's clear that Ubuntu is so popular that Qt's devs shouldn't leave this issue uninvestigated, since the source code for Ubuntu's Qt4 version is open source and available you guys could check if you wanted. On Mon, Oct 14, 2013 at 7:05 PM, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 14 de outubro de 2013 18:55:56, Jiergir Ogoerg wrote: To test qt4 I did sudo apt-get install libqt4-dev, that is, the libs that come with Ubuntu. I'm not a Qt developer so I hope you guys figure out why (Ubuntu's) Qt4 works and (the offline version of) Qt5.2 beta doesn't. Since Ubuntu is the most popular distro I would guess it's worth spending some time investigating this issue, I'm just a Qt user so I don't know how Qt works underneath. If they patch Qt, we can't do much. I hope their packagers are around the mailing list to answer. PS: Ubuntu being the most popular depends on your criteria for defining what popular means. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
[snip] According to: http://en.wikipedia.org/wiki/Android_(operating_system) Android is a Linux-based operating system ... but on the same page says: Android does not have a native X Window System by default nor does it support the full set of standard GNU libraries, and this makes it difficult to port existing Linux applications or libraries to Android. According to Qt's wiki page Licensing Talk about Mobile Platforms, Android is defined as the following: The Google Android operating system is based on Embedded Linux. Therefore it is permitted as an application deployment platform, as long as the developer has an Embedded Linux license. http://qt-project.org/wiki/Licensing-talk-about-mobile-platforms To point out, this decision has implications on licensing Qt. Keith ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: OpenGL session notes
Why don't you make an OpenGL middleware driver? Then your application will always be an OpenGL application and the middleware driver will take all of the OpenGL calls in place of the system's driver and do the translation there? The middleware driver will then contain the ANGLE code and the application will be none the wiser. -Original Message- From: development-bounces+kgardner=zebraimaging@qt-project.org [mailto:development-bounces+kgardner=zebraimaging@qt-project.org] On Behalf Of Samuel Rødal Sent: Monday, July 02, 2012 5:11 AM To: Storm-Olsen Marius (Nokia-MP/Austin) Cc: development@qt-project.org Subject: Re: [Development] QtCS: OpenGL session notes On 06/28/2012 01:46 PM, Storm-Olsen Marius (Nokia-MP/Austin) wrote: On 28/06/2012 01:59, ext Samuel Rødal wrote: On 06/27/2012 06:30 PM, ext marius.storm-ol...@nokia.com wrote: In theory we could even support both options in the windows platform plugin, and choose either depending on what the QSurfaceFormat asks for. OpenGL ES 2 via ANGLE, and desktop OpenGL 2 and above via the native OpenGL drivers. Are you sure that would be possible? The ANGLE project is about translating OpenGL calls to DirectX, so it might be hard to support both at the same time? Or do you mean that we would have two different plugins, where we link ANGLE to just one of them? Well, I guess it's not possible to link against the ANGLE OpenGL library and native OpenGL libraries at the same time, so maybe this wouldn't work out in practice, unless we do a lot of runtime resolving magic... Not talking about using different plugins, since QtGui itself nedes to link against OpenGL. If so, where you planning on mixed usage (OpenGL ES2 and OpenGL 2 usage at the same time)? Nope, just for an application to be able to explicitly use desktop OpenGL if so desired. At best we could hope to support using OpenGL ES 2 for one QWindow and desktop OpenGL for another, but definitely not mixing the two within the same context. -- Samuel ___ 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] QStringRef conversion functions
Sorry to backtrack this thread, but I have some performance information. Just FYI, I haven't made any code changes to Qt, yet. To give some background information, I am parsing a single xml file with 88,704 floating point values using the QXmlStreamReader. I am running in Windows 7 x64 and am using an SSD to store the file. My compiler is Visual Studio 2010 with a Win32 configuration. I would take the QStringRef for the argument, convert it to a string using the toString() function and then use toFloat(). This method would parse the entire document in 608 milliseconds in release mode. stringRef.toString().toFloat() Changing that code to use wcstod on the QStringRef resulted in parsing the document in 467 millesconds. wcstod((const wchar_t*)stringref.unicode(),0); In debug mode, this goes from 2814 milliseconds down to 1850 milliseconds. I would say that there is a big payout with changing what we currently have. Thanks, Keith -Original Message- From: Girish Ramakrishnan [mailto:gir...@forwardbias.in] Sent: Monday, June 11, 2012 4:55 PM To: Keith Gardner Cc: development@qt-project.org Subject: Re: [Development] QStringRef conversion functions Hi, On Mon, Jun 11, 2012 at 11:38 AM, Keith Gardner kgard...@zebraimaging.com wrote: I was wondering if there would be a possibility of getting some of the conversion functions that are in QString implemented in QStringRef (toInt, toFloat, etc...). The reasoning behind this is that I am using the QXMLStreamReader to parse an XML file with over 88,704 floating point values. I am trying to improve the speed at which the file is parsed and I believe one of the bottlenecks is taking an attribute of QStringRef and copying its data into a QString in order to convert to a float. I would prefer that the copy never happen but that would require some more intelligence be added into the QStringRef class. I am tempted to say it's 5.1 material but it would be nice to see how much gains you are getting out of these new apis and how intrusive the new code is. Can you push your change to gerrit ? Thanks, Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QStringRef conversion functions
I was wondering if there would be a possibility of getting some of the conversion functions that are in QString implemented in QStringRef (toInt, toFloat, etc...). The reasoning behind this is that I am using the QXMLStreamReader to parse an XML file with over 88,704 floating point values. I am trying to improve the speed at which the file is parsed and I believe one of the bottlenecks is taking an attribute of QStringRef and copying its data into a QString in order to convert to a float. I would prefer that the copy never happen but that would require some more intelligence be added into the QStringRef class. Would this be possible to add this in time for the Qt 5.0 release? If not, would it be possible to add this for Qt 5.1 release? Keith Gardner Software Engineer Zebra Imaging 9801 Metric Blvd., Suite 200 Austin, TX 78758 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
Couldn't you have the log fill a QIODevice (file or socket) and make a QLogFile class that would perform the log file rotation? -Original Message- From: development-bounces+kgardner=zebraimaging@qt-project.org [mailto:development-bounces+kgardner=zebraimaging@qt-project.org] On Behalf Of shane.kea...@accenture.com Sent: Tuesday, January 31, 2012 4:57 AM To: pisoengra...@gmail.com; wolfgang.b...@nokia.com Cc: development@qt-project.org Subject: Re: [Development] QLog ( Work on qDebug and friends) +1 from me - Crazy idea : allow logging to a socket ? ( remote log/debug ) - More than one logging file ? One file for every category / group of categories - Log File rotation Just my 2 cents. Not that crazy an idea - I normally use USB to catch the live debug log from phones. But this is done on the system level rather than Qt. The problem is you can't use QTcpSocket to do it, because QtNetwork might itself be printing QDebug messages. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
