Re: [Development] Danger when excluding auto tests with pre-processor macro.
Olivier Goffart wrote: In the paragraph Use appropriate mechanisms to exclude inapplicable tests of https://qt-project.org/wiki/Writing_Unit_Tests the policy to exclude tests depending on platforms or compiler features is to use pre-processor #ifdef. I just eddited that page to add a Warning there. the MOC does not know all the built-ins defined by the compiler. And as a result, disabling a test based on one of those define actually disable the test all the time, since the moc will not generate the slot for it so the test system don't call that function. I write that now because I just saw many changes recently that effectively just remove tests on all platform. For example, I don't think QT_OS_WIN is visible to moc, and i'm pretty sure QT_COMPILER_* is not visible So in effect, all those recent commit just disabled some tests that should probably not be disabled. For a while now, the general recommendation has been to have tests compile and run on all platforms and to use QSKIP on those configurations where the test doesn't apply. So, #ifdefs should go inside the function definition, and stay out of MOC's way. At some point Jason McDonald was going over all the tests and fixing this, but maybe someone needs to take a second round now... Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Request for a new playground project
Jarkko Laitinen wrote: I have been developing a cloud integration module for Qt. The working name for the project is QCloud. It provides an API to do requests to Amazons S3 and Windows Azure. This has been my masters thesis project and it has been done with consultation from Digia. The project is in that kind of a state that it could be uploaded to playground. I am not sure what the project should contain when it is uploaded to the playground, documentation is almost done but tests are still incomplete. I will include a readme that helps with the installation and the documentation should provide enough information for the developers on how to use the module. I am happy to answer more questions if there are any. What are your plans for this project going forward? João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Time to decide what security policy the Qt Project will use (not Trolltech/Nokia/Digia)
Dear d3fault, d3fault wrote: Nah. WILL is too strong a statement. More like: very very very very likely ;-) Cras in mi ut mi auctor tincidunt. Vestibulum volutpat lorem eget ligula egestas vehicula. Mauris in nisi et ligula accumsan accumsan vitae at erat. Etiam vitae leo risus. Vivamus placerat turpis lectus, eget gravida neque. Suspendisse id nunc ipsum, vel pellentesque dolor. Nam in lorem eu sapien tincidunt mollis. Nullam nec massa id risus commodo blandit. The number isn't very relevant because they are crackers instead of script kiddies. The number of crackers is also a question mark. You simply cannot know how many crackers have gained access to the information. It's better to know that everyone knows than to think* you and your peers are the only ones who know (and to keep the rest of us in the dark). You do not have to fear the script kiddies a single bit if you are armed with the same information as them (because you shut down). Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Sed viverra aliquet mauris nec rutrum. Donec faucibus leo sit amet ligula convallis dignissim. Nam eu mattis metus. Ut egestas turpis ut dui bibendum convallis. Vivamus sed arcu sem, vel pretium arcu. Mauris lacinia consectetur lectus. Fusce sit amet ultricies felis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam tortor quam, congue ut posuere sed, sagittis sed urna. Nunc adipiscing, tortor at congue lacinia, felis nunc tincidunt mauris, in faucibus mauris neque at ligula. * = erroneously Praesent non risus nisi, cursus euismod nibh. Sed vel nisi ut lorem tristique tristique eget eget velit. Praesent eu neque ut orci consectetur molestie. Praesent sit amet arcu vel eros gravida ullamcorper at vel lacus. Duis libero nisi, tempor sit amet accumsan vel, auctor sed nibh. Cras euismod consectetur mollis. In dignissim purus eget lacus hendrerit sed suscipit magna egestas. Fusce faucibus est lobortis dui ullamcorper quis vehicula orci commodo. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Suspendisse nibh mauris, condimentum id mattis bibendum, porta pulvinar tellus. Etiam sem nulla, pretium quis imperdiet tristique, faucibus sed mauris. Vestibulum ut leo vitae elit vulputate tincidunt. Etiam pellentesque orci a augue luctus mollis. In eget eros nibh, eget aliquet mi. Proin augue massa, placerat id elementum a, pretium ac sapien. EXACTLY. -A few crackers armed with knowledge you don't have -A ton of script kiddies with knowledge you also have Aenean mauris augue, ornare dignissim tempor quis, fermentum vestibulum nisl. Nam ipsum augue, hendrerit sed venenatis a, vestibulum vitae tortor. Duis rhoncus mi ut odio rutrum ullamcorper fermentum diam tempor. Fusce sed velit purus. Pellentesque eget nisl mi, sed posuere eros. Maecenas vitae turpis augue. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Pellentesque tortor dui, volutpat non tempor eu, mollis sed justo. Donec facilisis neque ac est dictum id euismod nibh adipiscing. Mauris suscipit, urna non sodales auctor, diam mauris pulvinar elit, id condimentum ligula dolor ut nibh. Nullam viverra orci non urna pretium non porta diam luctus. Pellentesque sem enim, cursus in tempus ut, varius id est. The lesser of two evils is the latter. Aenean eu metus turpis. Donec rhoncus leo non nibh mattis ut vestibulum sapien mattis. Fusce quis massa eu enim consequat porttitor ut vel erat. Vivamus vitae tortor turpis, quis pulvinar ligula. Donec commodo consectetur lorem quis adipiscing. Pellentesque pellentesque fringilla mi at egestas. Sed vitae dui a augue tempus gravida. Nam sapien sem, adipiscing eu placerat at, lacinia ut nibh. BECAUSE *copies from above*: You do not have to fear the script kiddies a single bit if you are armed with the same information as them (because you shut down). Morbi non semper purus. In turpis leo, lacinia sit amet consequat id, mattis vel eros. Proin auctor lobortis est, vel elementum dui convallis id. Cras nec felis lorem. Proin porttitor, mi vitae tristique laoreet, nisl libero rhoncus mauris, vitae euismod urna mi sed nunc. Cras fermentum mauris non neque venenatis ut facilisis metus fermentum. Donec id eros orci. Praesent volutpat sodales faucibus. Sed commodo rutrum neque, in blandit diam aliquam at. Curabitur ante quam, malesuada sed gravida eu, lobortis vitae massa. Mauris tempor, nulla at lobortis lacinia, turpis neque molestie justo, at posuere erat eros vitae libero. If I can convince you then you might be able to convince him. Since, you know, he actually respects you and all (brought that upon myself xD). Quisque mollis laoreet malesuada. Mauris magna mauris, adipiscing sed vehicula eget, lobortis eu ligula. Nam et tortor quis turpis semper hendrerit. Ut consectetur porttitor purus a fringilla. Curabitur elementum sodales luctus. Proin bibendum magna nec lacus placerat fermentum.
Re: [Development] Perf about loading one 240x320 png image
Diego Iastrubni wrote: My experience is with Qt4... but I do see that QFile was slow for me. I needed to parse a simple text file from a real disk (~10mb size, simple state machine, no regex, application run several times for disk IO to get working thus reducing the impact of HW). My first try was using QFile::readLine, and using QString. I then ported it to use ANSI C and char* (only for the parsing, the rest of the project was still using Qt4 classes). This simple refactoring (QFile - fopen()) changed loading time (on windows): file1.txt: 515msec to 230msec file2.txt: 420msec to 155msec On linux (the same HW, double booting) the Qt QIO classes were not that slow, but the standard C functions were also faster. Is anyone seeing similar things? There are places where QFile can be optimized. One of them is continuing with the removal of the QAbstractFileEngine abstraction, as was done for QFileInfo, QDir and QDirIterator in Qt 4.8. I suppose a few percentual points on select use cases can be recouped by optimizing the code itself even after that. Still, at the end of the day, Qt I/O APIs, as they exist today, will always add overhead over the native APIs. The overhead is inherent to the design: Qt wraps low-level native APIs in another low-level cross-platform API. As the interface mostly remains at the same level it is wrapping, this means one gets Qt's wrapper overhead at every single native API call. Or mostly so. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Community effort in updating Qt5 docs -- QThread focus
Chris Meyer wrote: The documentation promotes the idea of using 'moveToThread' as a preferred threading mechanism. However, we've found that moveToThread is full of pitfalls. Particularly, an object must be deleted on the thread on which it resides. This makes it difficult to manage the lifetime of objects that have been moved to a thread via moveToThread. You need to configure an independent mechanism to delete objects that have been moved to thread (i.e. send a signal to the thread that it's about to shutdown and allow the objects to deleteLater within the thread, which also implies that you need to keep track of the objects that are within the thread, which somewhat defeats the apparent simplicity of moveToThread). Also, you cannot use the finished signal from the thread since the thread will already be gone by then. Since Qt 4.8 you can connect QThread::finished to QObject::deleteLater and it should do the right thing in the appropriate thread. The bug will show up intermittently and differently on various platforms and is difficult to debug if you don't know about the problem. You'll just end up with spurious crashes (typically at quit time), especially for networking objects. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Community effort in updating Qt5 docs -- QThread focus
João Abecasis wrote: Chris Meyer wrote: The documentation promotes the idea of using 'moveToThread' as a preferred threading mechanism. However, we've found that moveToThread is full of pitfalls. Particularly, an object must be deleted on the thread on which it resides. This makes it difficult to manage the lifetime of objects that have been moved to a thread via moveToThread. You need to configure an independent mechanism to delete objects that have been moved to thread (i.e. send a signal to the thread that it's about to shutdown and allow the objects to deleteLater within the thread, which also implies that you need to keep track of the objects that are within the thread, which somewhat defeats the apparent simplicity of moveToThread). Also, you cannot use the finished signal from the thread since the thread will already be gone by then. Since Qt 4.8 you can connect QThread::finished to QObject::deleteLater and it should do the right thing in the appropriate thread. For reference, here's a link to the commit implementing this: http://qt.gitorious.org/qt/qt/commit/0c643b179c5154c50b61dba421016b7b48794720 The bug will show up intermittently and differently on various platforms and is difficult to debug if you don't know about the problem. You'll just end up with spurious crashes (typically at quit time), especially for networking objects. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Branching for Qt 5 repositories
Laszlo Papp wrote: No, I really do and those qualifiers are required, but note that they apply to each feature individually. That is, if you want to merge the command-line parser, it needs to be feature-complete, working, documented, tested and a few more qualifiers (cf. Qt Project's Technical Fit) before I or anyone else should click that +2. If those all fully apply, I would call it release since there is nothing to fix anymore or stabilize since it is completely. My point is that there may be bugs on certain platforms where it is not well tested, or the documentation is written and approved by developers and cannot get better until it is released to the public for further feedback and improvement. No it is not a release. The point is features are developed outside shared branches until the point where they are ready for wider exposure. It doesn't mean they won't change. But it does mean the feature does something useful (i.e., is not half-broken, doesn't break the build), has tests for the functionality it offers that will be run by the CI gate, has minimal documentation to make it useful to developers wanting to try out or review the feature. Merging a feature to a shared branch means you are publishing it for others to try out and see. The fact that the initial branch is still a development branch means the API/ABI is not immediately set, so it can change. Typically, documentation can be incrementally improved from then on, but it's important to have something to begin with. As much as possible, break big features into smaller incremental ones that can be taken in one at a time and built upon. Again, complete is not the same as frozen. And releasing to a shared branch is still meant to gather feedback and improve. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Is overriding an existing virtual method 'BC' in Qt 4?
Thiago Macieira wrote: But note that there's one stricter requirement: the forwards compatibility that applies within a patch series. Adding this new virtual within the same patch series means a new, public symbol, which could get used in applications. I don't know how to fix this, but is there a hard technical reason why the reimplementation of a virtual function needs to be *exported*? Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Nominating Andy Shaw for Approver
Hi, I'd like to nominate Andy Shaw for Approver status. Andy's history with Qt is longer than my own, having catered to commercial customers in Trolltech, Nokia and Digia. Looking over the main repositories, I count 150 commits in the 4.x public timeline. 31 so far in Qt 5's qtbase -- I did not look into other modules, but I'm sure I'd find commits from him scattered all over the place. Personally, I've seen him dive deep into the file stack with particular attention to our Windows users, and I'm going to need his +2s there! :-) Anyway, I can only expect Andy's focus on stability, bug-fixing and the end user will keep making Qt a better product. Finally, his dashboard: https://codereview.qt-project.org/#dashboard,1000338 Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QFile::encodeName/decodeName
Thiago Macieira wrote: I won't de-inline the encodeName and decodeName functions. I have no interest in changing them. I'm fine with leaving them as they are, if you think it is too much hassle (compatibility issues and such) to remove altogether. I don't think they are the solution to the problem as I see it. I would add file:// parsing directly as a feature of QFileSystemEntry, with no additional public API. This can be done for 5.1. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] About pcre in qt5
Giuseppe D'Angelo wrote: On 11 June 2012 00:49, tasuku.suz...@nokia.com wrote: Disabling PCRE makes sense for me. As we have QT_NO_REGEXP already, add it to feature list and fix the build. To be ultra pedantic, perhaps QT_NO_REGEXP should be renamed into samething like QT_NO_REGULAREXPRESSION for selectively disabling PCRE+QRegularExpression (butkeeping QRegExp)? I'm not sure we should allow QRegExp to be used when there is no QRegularExpression, as we want code to move over to using QRegularExpression, not the other way around. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
Thiago Macieira wrote: Following Olivier's suggestion I think it might be beneficial to have alloc unconditionally in the base class, even if it is not being used at times. If nothing else, it saves padding. Additionally, deleter function and token would be more generally useful if they can be used with the alloc member. Yes, if we move the alloc member to the main struct, then it will simply occupy the space currently used for padding. The total overhead for an allocation would be 24 bytes on 64-bit systems. Since glibc's allocator is 16- byte aligned, this means our data is always 8 bytes off. In my opinion, that's actually worse than having a larger header. But that's what we currently have and wouldn't change with you suggestion above, right? Would it be worth to set the minimum alignment for the data as 16-bytes, at the expense of padding we explicitly add in QArrayData::allocate? (Since this decision can be done inside that function it would have no impact on ABI) Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
Thiago Macieira wrote:
Ok, I see. You're splitting the deleter from the immutability. Since we do
have a flag for immutability, we can serve WebKit's use-case, but also do in-
place modifications.
Yes.
I find that a nice use-case.
You're going further and suggesting that we could also tell the container how
much memory was reserved externally, so it could grow around without
reallocating. I think that's your reason for keeping the alloc member
together
with the notify function.
Yes.
However, I don't think that's going to be a very useful use-case. I already
think that in-place modification of externally-allocated data is a stretch
use-
case, but one that could be eventually useful. Allowing the container to use
memory around that is too much, IMHO.
Heh, mpeterss just walked into my office with a QIODevicePrivateLinearBuffer
issue...
There, QIODevice manages a read cache. When you call readAll on that, it copies
all the data to QByteArray and resets its data:
QByteArray readAll()
{
char* data = first;
int length = len;
QByteArray retVal(data, length);
clear();
return retVal;
}
Depending on length, it'd be good to relinquish your buffer to QIODevice and
allocate a new one. Saves the memcpy(): Here you go, do what you like with it
but call free() when you're done playing.
In this use case mutability might not be the most important thing, but then why
limit how the buffer can be used if the original owner no longer requires any
restrictions?
Anyway, I don't think this is a stretch as long as we don't allow these
decisions to be made implicitly for the user. For instance, we shouldn't be
changing the semantics of fromRawData as it exists today, but we could enable
users to be explicit about what's in the raw buffer and how it can be used.
Say, Hey QString, here's a UTF-16 string *and* it's already null-terminated --
just don't change it :-)
Cheers,
João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
Thiago Macieira wrote:
On segunda-feira, 11 de junho de 2012 16.00.58, João Abecasis wrote:
Thiago Macieira wrote:
Following Olivier's suggestion I think it might be beneficial to have
alloc
unconditionally in the base class, even if it is not being used at times.
If nothing else, it saves padding. Additionally, deleter function and
token
would be more generally useful if they can be used with the alloc member.
Yes, if we move the alloc member to the main struct, then it will simply
occupy the space currently used for padding. The total overhead for an
allocation would be 24 bytes on 64-bit systems. Since glibc's allocator is
16- byte aligned, this means our data is always 8 bytes off.
In my opinion, that's actually worse than having a larger header.
But that's what we currently have and wouldn't change with you suggestion
above, right?
We currently have 24 bytes. With my changes, it goes to 32 bytes, which is
the
second most ideal value. The ideal one would be 16 bytes.
The proposed QArrayAllocatedData is 32-bytes in size, but at the cost of two
4-byte padding holes. That's not that much different from a 24-byte header with
no holes -- you can always add padding at the end ;-)
With a 32-byte default header you get the prepend optimization for free:
struct QArrayData
{
qptrdiff offset;
uint size;
QtPrivate::RefCount ref;
uint flags;
uint alloc;
qptrdiff beginOffset;
};
24/32 bytes. (16/24 bytes if we move offset and size out)
Did you mean something else?
Would it be worth to set the minimum alignment for the data as 16-bytes, at
the expense of padding we explicitly add in QArrayData::allocate? (Since
this decision can be done inside that function it would have no impact on
ABI)
QArrayData::allocate can take that decision. In fact, that was in my plans
for
some future improvement.
But that means we'll use 32 bytes anyway for all allocations, in any platform.
The decision can still be made conditional on the architecture or so.
João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QFile::encodeName/decodeName
Thiago Macieira wrote: On the other hand we already have Qt-only paths in resource files and QDir::searchPaths(). We could easily use a well-known prefix for the special paths: url-encoded:/usr/joao/R%E9sum%E9.txt, which only supports absolute paths, but would already enable all items in my wish list. As you can see, I didn't come up with this today. I've known these alternatives for years. I don't think they're worth our time. Search paths and the filesystem engines are misfeatures. One is gone, the other not yet. They are potential security issues too. They're potentially security issues, but they're not gone in any way. True, you can no longer use public API to introduce custom file engines. I don't expect resource files to disappear any time soon, though, and those go with a :/ prefix. Anyway, what I recommend for now: 1) immediately, de-inline QFile::decodeName and QFile::encodeName 2) un-deprecate them and update the text in changes-5.0.0 As I said before, while I think these functions supported a real problem, they or their implementation are the wrong solution. I'm happy to make them internal and remove them from the API completely. What I was asking for, and I thought I was clear on that, is that we recognize where we regressed in functionality (we did!) and plan to cover the gap in the future. There's no need to rush. 3) make QProcess use QFile::encodeName for its arguments (no-op right now) 4) make QCoreApplication parse its arguments using QFile::decodeName (no-op right now) 5) idem for Laszlo's command-line parser class As pointed out by Oswald, this is the wrong solution. The interface where this needs to be handled is as close as possible to the OS-specific filesystem layer. Currently, the best place for this is QFileSystemEntry that keeps a real native path, besides a QString interpretation. Names obtained from the file system need to be decoded and all QStrings need to be encoded before being passed to filesystem functions. This can be done transparently. There's no point in forcing the user to consider this any further. Later, we can decide whether to add escaping to those functions. Yes, let's not rush into escaping. I actually think a satisfactory solution would be to add limited support for file:// local path URLs, where percent encoding would be fully supported as per URL rules. This would only support absolute paths, but would already enable everything in my wish list. For paths generated inside Qt, URL-style paths would only be used where the path couldn't otherwise be decoded to QString. However, I cannot agree with bringing the setter functions back. I do agree with removing them completely, though. Go for it, already! João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QFile::encodeName/decodeName
Thiago Macieira wrote: Later, we can decide whether to add escaping to those functions. However, I cannot agree with bringing the setter functions back. I do agree with removing them completely, though. Lars Knoll wrote: Yes. No setters for the encode/decode functions. Either we handle this properly in Qt (giving full roundtrip conversions for arbitrary 8bit sequences), or not at all. ^^ This! João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QFile::encodeName/decodeName
Thiago Macieira wrote: On quinta-feira, 7 de junho de 2012 10.06.31, Oswald Buddenhagen wrote: it's not a no-op as soon as we actually implement some escaping mechanism. as joao pointed out, it is all about applying the decoding and escaping at the right layer - which is exactly when using posix file i/o functions, and nowhere else. as soon as you start doing it with cmdline args and the environment you are in workaround land, and that only increases the mess (because you don't know what encoding the other side uses - the only reasonable assumption is that it wants locale encoding (because that would be the right thing to do)). So you're saying that we don't need to pass these file names with broken encoding to other applications, nor do we need to accept them in the command- line. We're saying that if you rely on knowing what is a file name and what isn't when processing command line arguments, QProcess arguments and whatnot you've lost the game. You'll be preventively sprinkling these functions all over the place ensuring that the impact is much wider than file names and setting us up for failure in finding an escaping mechanism that works. Whatever mechanism we come up with must survive the QString - local 8-bit conversion, otherwise it doesn't help. It forces *ALL* application developers to consider them for the functionality to be useful. Careful use of setEncoding/DecodingFuncion may enable ONE application to be written that supports the funny paths (mostly on Linux). It doesn't solve the general problem. It doesn't help everyone. This is the sort of API that while useful (it has a use), hurts more than it helps in the wider ecosystem. You'd need the world to behave to claim the feature as part of Qt. Maybe you'll want to revert this then: https://codereview.qt-project.org/#change,22854 Yes, I think that is the wrong fix. I +1'd because it would work by default and fix a real issue for the time being. As I was going away on extended leave I didn't want to be blocking the discussion, but did leave comments. The change doesn't need to be reverted. Only the use of encodeName needs to be removed and NFD normalization added on Mac. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QFile::encodeName/decodeName
Thiago Macieira wrote: the lesser evil is imo assuming correct locale encoding when actually interpreting external input, being consistent within the qt realm when dealing with i/o functions, and having functions for 8-bit pass-through when dealing with external things which are just passed along (qprocessenvironment already has this; it should be possible to do the same for cmdline args by having laszlo's work integrate with qprocess as well). I agree on that too. Which is why I am telling João that the idea that filesystem encoding != locale encoding is insane. It simply cannot be implemented properly. We're not discussing whether it's sane or not. I'm interested in enabling the user to act on broken files from within Qt applications. Qt is a general purpose toolkit, it should not unnecessarily limit what you can do, even if it makes you jump through hoops in some cases. Qt can see these broken file names and will point them out with a healthy dose of '?'. How do application developers explain to their users that the files they see they don't really? Yeah, just ignore those, your filesystem is corrupted. There are plenty other files you can play with. Here, have a balloon! As I see it, enabling command-line arguments to be treated as random 8-bit gibberish is a separate and specific problem. I don't think encode/decodeName is the right concept to use there, though we could very well have an encode/decodeCmdLineArg pair. It might suffer from the same shortcomings of current encode/decodeName in terms of portability, though. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QFile::encodeName/decodeName
Thiago Macieira wrote: On sexta-feira, 8 de junho de 2012 10.44.37, João Abecasis wrote: I actually think a satisfactory solution would be to add limited support for file:// local path URLs, where percent encoding would be fully supported as per URL rules. This would only support absolute paths, but would already enable everything in my wish list. For paths generated inside Qt, URL-style paths would only be used where the path couldn't otherwise be decoded to QString. Hmm... that's actually not a bad idea. We're getting somewhere! :-) By doing this, we'd be making it impossible to have a filename whose name starts with file:///. That's a problem we need to document if we do it (note that such a file cannot exist on windows in the first place). However, such files already *do* pose problems, since many applications will try to decode a URL if they find one, falling back to a path otherwise. See the discussion on QUrl's constructor and the example of KUrl's and KUrl::fromPathOrUrl. A file whose name starts with file:/// could still be fully understood by prefixing it with ./. This is not very different from what a user needs to do to ensure a file name is not confused with a command line option (when passing it in the command line, that is). Security issues can me minimized by requiring absolute paths where this is a concern. However, I cannot agree with bringing the setter functions back. I do agree with removing them completely, though. Go for it, already! You're the one who wants this. I'm perfectly happy leaving them as it is :-) I thought this was feedback you already got in the review of your patch :-p Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QFile::encodeName/decodeName
Thiago Macieira wrote: On terça-feira, 5 de junho de 2012 16.48.58, João Abecasis wrote: Thiago Macieira wrote: On terça-feira, 5 de junho de 2012 13.20.36, João Abecasis wrote: I would not go as far as saying that the concept is broken, but it definitely isn't portable. One big issue is that nowadays we don't use an 8-bit encoding on Windows and those functions assume QString - QByteArray conversions. I called it broken due to the ambiguity when it comes to interpreting data that may or may not contain file names, like command-line arguments. See the next paragraph of what I had written. Codecs must never be used in a situation where there's an ambiguity on what the encoding is. That will lead to mojibake sooner or later. That's the whole point, you shouldn't treat file names differently when processing the command line or configuration files. Those should be interpreted using their specific rules: command line goes according to locale, configuration goes according to established convention (say, UTF-8). So you're asking that filenames be passed on the locale encoding (say, UTF-8) on the command-line, regardless of what the filesystem encoding is? I see no other sane way, unless your application is able to take the byte sequences it gets without additional processing. In Qt, strings are 16-bit, so 8-bit strings typically need conversion. That is a possible solution, it requires that all tools be taught to do that, including the ones that currently couldn't care less about encodings. Many shell tools assume that the file name can be copied verbatim from the DIR* entry (from readdir(2)) to the screen. I think phrasing the problem as such that we require all tools [to] be taught a new trick doesn't really help. We're obviously not going to be able to force every other tool out there to change. Not any time soon, anyway. Still, some of the same tools you want be taught a new trick don't have a problem to begin with, as they're quite capable of reading and writing files with funny names. Tools that do all processing in 8-bit can just wait for system calls to error out, they don't really need to interpret encodings the same way Qt does. Qt has a problem and it's one that allows it to show files with funny names in file dialogs and through QDir(Iterator), but will prevent most attempts to interact with those files in practice. Again, encode/decodeName enabled application developers to handle these issues. I don't see that happening any more than I see any of the other solutions. The only pragmatic solution is to enforce filesystem encoding == locale encoding. Locales change, either between users or because some users switch locales. Unless you can enforce that all locales use the same encoding (nowadays much less of a problem, granted) using user locale is just wrong. Even if not on the same computer, USB sticks are still a source of files with funny names. In fact, there is one more possible solution which stands a chance: forcing the problem onto the kernel. Make the entire userspace API be UTF-8 and have the kernel recode to the filesystem encoding as necessary. The problem with this solution is that it a) will suffer extreme resistance from kernel developers and other people who think of file names as binary data instead of human-readable text; and b) is no different from the other solution of enforcing the encoding. Forcing this onto the Linux kernel would in the long term make the situation better for Linux users that don't receive files from any other OSs or kernel versions. It doesn't help everyone. [snip] QtGit commit -m $'R\xc3\xa9sum\xc3\xa9' 'R%E9sum%E9.txt' Bash enables you to pass around byte sequences it doesn't understand. That would help in getting UTF-8 into the application but would not help pass in Latin1, as the application would (correctly) flag it as an invalid UTF-8 sequence and replace 'é' with '?'. Instead, we need to escape the file name in a way that will not be misinterpreted by bash or command line processing, giving code that actually expects a path (say, QFile, encodeName or QFileSystemEntry) a chance to interpret it. For this to work, command line parsing need not understand more than UTF-8, but encodeName would then be able to convert those \xHH sequences to the proper Latin1-encoded Résumé and retrieve the right file from the file system. You used %HH instead of \xHH in your example, which is the URL encoding and for which there are well-defined rules. I'd prefer that. Indeed, my mistake mixing the two. That's what I get for going back and partially editing the e-mail ;-) For the record, this was meant as simple contrived example, not to propose a final solution. If escaping is something we'd want to support we would need to spend some time looking at it. We're talking about the edge cases, right? 99% of uses will work with or without the need for encode/decodeName
Re: [Development] Maintainer TrustMes
On 2. apr. 2012, at 15.22, ext Thiago Macieira wrote: One of the duties of a maintainer is to ensure that every contribution to the code he/she maintains is being reviewed. That is, if no one else approves or rejects, the maintainer has the duty to make that happen. I've done this in the past and approved based on +1 given by other people, or by reviewing stuff myself. What are we supposed to do when no one else approves or rejects a commit that we created ourselves? Or worse, when no one reviews at all? My question applies mostly to QtDBus, since I don't expect most people will know anything about that module. I've (ab)used Stephen's goodwill to review simple things, but I don't expect him to understand the message delivery path for example. What is the suggested procedure? Code reviews, in general, are good. Even by people that don't necessarily know the code. I think it would be fine to +2 yourself after you gathered +1s, if you can't get +2s in any other way. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] containers branch to merge into api_changes soon
Hello everyone,
The containers branch has reached a point where it would be beneficial
to have it merged with api_changes (and then master, from there). The
branch has already been tracking master closely.
The plan now is to merge api_changes once more into containers and have
that go through CI. Assuming that goes well, then coordinate with our CI
overlords to have a merge of the branch into api_changes be prioritized
over other integrations.
A short list of changes brought in by the branch follows. All reviewed
and CI-tested, as with master and api_changes. (You can safely skip to
the greeting at the end if you're not interested or already know what's
coming ;-)
* QArrayData
This is a new class that is meant to unify QByteArrayData, QStringData
and QVectorData; so far, those structures have been updated to share the
same layout, but technically they're not the same at this point.
The new layout also fixes some gcc optimization bugs due to the use of
arrays of size 1 in QVector.
* QtPrivate::RefCount
The struct was made POD and no longer offers constructors,
assignment or int conversion operators. Despite the actual atomic
reference count being public (required for POD-ness), explicit (or
verbose) API is provided instead so that users don't need to know or
care about individual ref-count values.
It now offers support for setSharable() together with traditional
reference counting. QVector and QList were updated to use this.
* QConst{ByteArray,String}Data renamed to QStatic{ByteArray,String}Data
... and the const qualification in their data members dropped. This made
those structs technically non-POD and this was generating warnings with
the Intel compiler and qmake crashes with Visual Studio 2010.
* New moc revision and meta-object data format
In the new format, method names and type information is stored directly.
The motivation for the change is to enable direct access to method names
and type information (avoiding string-based lookup for types if
possible), since that's typically the information language bindings
(e.g. QML) need.
QMetaMethod::signature() has been renamed to methodSignature() and
returns a QByteArray, since the signature is generated on the fly from
the name and type information, rather than stored verbatim in the
meta-object
New APIs QMetaMethod::name(), parameterCount(), parameterType() and
returnType(), make it more convenient to introspect methods.
* QMetaType::UnknownType
This new enum value is used by the meta-type system to indicate, well,
unknown types. QMetaType::Void was previously used for this purpose,
making it ambiguous, for instance, when used to represent the return
type for a function.
* Assorted bug-fixes and cleanups
These shouldn't impact SC or BC any more than bug fixes going into other
branches ;-)
That is all for now.
Cheers,
João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
Boudewijn Rempt wrote: Well, Qt is a library, a platform -- and that means that you cannot predict how and when classes and things like qreal will be used, and that if something is changed there, it _will_ mean a porting effort, potentially a big one. Heck, we haven't even really recovered from the previous porting from Qt3 to Qt4! Hence my suggestion: Drop qreal entirely, don't deprecate it and don't try to figure out what it should mean. We realized it was a broken concept and it plays against the C++ language we depend on. What's the porting effort for applications that use and depend on qreal? Application developers have to decide exactly what qreal was supposed to mean for them and typedef it to what's appropriate. It's a one-line change. They can patch Qt's qglobal.h if they ship their version of Qt, or they can add the typedef in their own code. Libraries that depend on Qt will have to analyze the issue and make their own decision: a) jump to double or float or b) provide their own AwesomeReal, if that makes sense in their context. It's not even a surprise or unexpected outcome if we document the issue or make sure a meaningful error is generated upon use of qreal. The bigger porting effort doesn't come from the disappearance of qreal itselft, but from changing Qt itself to not use it as users will no longer be able to assume QRectF and whatnot use double on their platform. And no one seems to be against that. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Dropping QT_NO_STL (was: The future of QtAlgorithms)
On 30. jan. 2012, at 23.03, ext Thiago Macieira wrote: On Monday, 30 de January de 2012 18.38.56, João Abecasis wrote: On 30. jan. 2012, at 17.25, ext Thiago Macieira wrote: My point here and below with the containers themselves is that we don't want to use those containers in our code nor in our API. What's wrong with using them in our code, as long as they stay out of the API/ABI? std::vector is perfectly fine for a non-shared dynamically allocated array. I'd like our containers to be good enough for that, to be honest. And avoid subtle mistakes if the behaviour differs. But where it makes sense, sure. Roberto used STL in the his C++ parser. Just avoid template bloat: out-of-line copies of identical code because the compiler can't figure out two functions do the same. It's hard to measure. Fair point. João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Dropping QT_NO_STL (was: The future of QtAlgorithms)
On 30. jan. 2012, at 17.25, ext Thiago Macieira wrote: My point here and below with the containers themselves is that we don't want to use those containers in our code nor in our API. What's wrong with using them in our code, as long as they stay out of the API/ABI? std::vector is perfectly fine for a non-shared dynamically allocated array. João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QtAlgorithms
Robin Burchell wrote:
2012/1/27 João Abecasis joao.abeca...@nokia.com:
- Provide standard-compliant implementations of the algorithms in
QtAlgorithms (no 'q' prefixes, no camel casing -- sorry!) and
selectively import those into a known namespace when QT_NO_STL is
defined:
namespace QtPrivateStd {
#ifdef QT_NO_STL
using namespace std;
#else
using namespace QtPrivateStlImpl::std;
#endif
}
I think you mean #ifndef there, but anyway.
Heh. That's what you get for posting untested code ;-)
So code using this would be using QtPrivateStd::sort(a.begin(),
a.end()); sort of stuff? Sounds good to me. Why is this being kept
private, though? It means that application developers can't make the
same QT_NO_STL choice, doesn't it?
I think some finer details of the proposal still need to be hammered
down and explored. Ideally, code should be written to use std::sort
directly and we somehow bring namespace QtPrivateStd into scope when
QT_NO_STL is defined.
So let me try again, but with tested code, this time :-)
#include stdio.h
#ifndef QT_NO_STL
#include algorithm
#endif
namespace QtPrivateStd { namespace std {
template class T
void swap(T a, T b)
{
puts(Using QtPrivateStd);
T tmp = a;
a = b;
b = tmp;
}
template class Iter
void sort(Iter begin, Iter end)
{
puts(Using QtPrivateStd; not actually implemented);
}
}} // namespace QtPrivateStd::std
#ifdef QT_NO_STL
using namespace QtPrivateStd;
#endif
void test1()
{
int a = 5, b = 3;
using std::swap;
swap(a, b);
printf(a = %i, b = %i\n, a, b);
}
void test2()
{
int array[5] = { 5, 4, 3, 2, 1 };
std::sort(array, array + 5);
printf(array = { %i, %i, %i, %i, %i }\n,
array[0], array[1], array[2], array[3], array[4]);
}
int main()
{
test1();
test2();
}
Thoughts? Comments?
Having already started trying to butcher QtAlgorithms, I may be
biased, but well.. can I propose another new gerrit review level: +3
give this guy a payrise? :-)
;-)
João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
On 6. jan. 2012, at 21.27, ext David Faure wrote: On Friday 06 January 2012 11:41:05 =?ISO-8859-1?Q?Jo=E3o?= Abecasis wrote: I don't support putting this in QFile as has been suggested as, from my experience with it, this will open a can of worms in maintenance and subtle issues cropping up in user code such as the ones being discussed: what's fileName()? Does it exists() before commit? What do remove() and rename(newName) do? If we go towards the idea that the temp file is really internal (as the idea of a mode flag would point to), then fileName() can keep being the target file, exists() will only be true if it already existed before starting to write. If it didn't exist before, then f.open(); f.write(); f.exists() is very fragile anyway, isn't it? It sounds like the result depends on whether OS flushed it to disk or not... So this doesn't seem like a valid use case anyway. If your argument that deriving or adding functionality to QFile is that we'll be able to use the transactional feature with old code, then we need to consider cases that previously were valid because there is code doing a lot of interesting things out there. Adding something that we know no one is using because it didn't exist before allows us to focus on the features and use cases we want to support. When it comes to remove and rename, they are already documented to close the file first, so this would finish the writing operation, and no surprises will happen to the user calling them. No issue of which file is it about, there is only one file after close() anyway. I'm coming to think that relying on close (explicit or implicit) to mean commit is a really bad idea. Particularly when interacting with legacy codebases that were not written with that assumption. I think if we think of the tempfile as an internal buffering mechanism rather than a second file exposed via the qfile api, then all these issues of which file is this about now don't happen at all. I think we would be well served by an API that exposes a QIODevice interface plus additional interface for commit/rollback. This represents more porting effort for the application developer. I have seen it in KDE in the past, where having to manage one more object, but only in writing mode, not in reading mode, and making sure to call commit/rollback on it, was a lot of trouble, compared to the initial code that was simply using a QFile for all that. Enabling a flag on that QFile would have been s much easier. If it's a QIODevice, it can handle reading and writing, but I'm not sure it's relevant in this context. Who are the readers and would they be reading a half-written version of the file? (Why?) If readers only care about fully written versions, they already need a separate object. And whatever we do they won't magically know that a new version has been written to disk. Most likely they have to discard caches and read/load again from disk. The other question is, would one have to call commit/rollback explicitely, or should QFile::close() (and the dtor) do the committing? I think commit should require explicit action, for instance, by explicitly calling close(). I don't like having the destructor automatically commit (even if it calls close) though. QFile's destructor has always called close(), that's in everyone's mind, so I don't think we want explicit and implicit close to work differently, that would be very confusing. I'm leaning towards not overloading close's meaning. In particular if you intend this to interact with legacy code bases. When writing to a file, you normally don't have to confirm yes I want to commit my changes. So the safer use of a temp file shouldn't require this either, others have convinced me in this thread. Because normally you don't get the transaction guarantee we'll be getting with your feature and normally you're not throwing away a good complete copy of your thesis ;-) [snip, discussion ongoing in separate e-mails in this thread] What happens to writes happening after a commit, though? This problem doesn't happen if commit == close(). You can't write after closing, that much is obvious to everyone. This goes with my idea that closed QIODevices should not exist... Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] This week in Qt 5 development (week 49)
Hi Stephen, Stephen Kelly wrote: This week: == QSound removed == == Talk of removing QWorkspace == == QTemporaryDir arrives == == Building v8 on MIPS == == -bsymbolic-functions used by default == == Extend the API for touch events == == On screen keyboard and better Input Methods == == Some build-time tools separate from QtBase == == Marketing == [... snip ...] I think this sort of weekly summary (including the commentary I snipped) is a very welcome addition to the Qt project. It is useful for everyone working on Qt. Before you posted this I was wondering how to aggregate and distribute the information, but you seem to have it rolling quite nicely already. I would like to encourage you to keep doing it and posting it to this list, as time and availability allows. Pretty please! :-) Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt5-feedback] A micro API review: for V3(md5) and V5(sha1) in QUuid
Lars wrote:
On 12/9/11 12:28 PM, ext liang...@nokia.com liang...@nokia.com wrote:
The original task is:
http://bugreports.qt.nokia.com/browse/QTBUG-23071
And the change is:
http://codereview.qt-project.org/10803
For the API name, we need a micro API review:
Set 1:
createUuidMd5()
createUuidSha1()
or
createUuidMd5OrSha1()
Set2:
createUuidV3()
createUuidV5()
or
createUuidV3OrV5()
Any other suggestion is also welcome.
These names look ugly. Why not simply QUuid::createUuid(const QUuid ns,
const QByteArray baseData, Version v); ?
I don't like that one since the namespace and name version only makes sense for
v3(Md5) and v5(Sha1), making all other options useless. I would prefer one name
that makes explicit either the version (v3/v5), the approach (fromName) or the
hash function (Md5, Sha1).
This has my vote:
QUuid QUuid::createFromNameV3(const QUuid , const QByteArray );
QUuid QUuid::createFromNameV5(const QUuid , const QByteArray );
inline QUuid QUuid::createFromName(const QUuid ns, const QByteArray name)
{
// SHA1 (v5) is recommended
return createFromNameV5(ns, name);
}
inline QUuid QUuid::createFromName(const QUuid ns, const QString name)
{
return createFromName(ns, name.toUtf8());
}
Cheers,
João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt5-feedback] A micro API review: for V3(md5) and V5(sha1) in QUuid
On 9. des. 2011, at 13.27, João Abecasis wrote:
Lars wrote:
On 12/9/11 12:28 PM, ext liang...@nokia.com liang...@nokia.com wrote:
The original task is:
http://bugreports.qt.nokia.com/browse/QTBUG-23071
And the change is:
http://codereview.qt-project.org/10803
For the API name, we need a micro API review:
Set 1:
createUuidMd5()
createUuidSha1()
or
createUuidMd5OrSha1()
Set2:
createUuidV3()
createUuidV5()
or
createUuidV3OrV5()
Any other suggestion is also welcome.
These names look ugly. Why not simply QUuid::createUuid(const QUuid ns,
const QByteArray baseData, Version v); ?
I don't like that one since the namespace and name version only makes sense
for v3(Md5) and v5(Sha1), making all other options useless. I would prefer
one name that makes explicit either the version (v3/v5), the approach
(fromName) or the hash function (Md5, Sha1).
This has my vote:
QUuid QUuid::createFromNameV3(const QUuid , const QByteArray );
QUuid QUuid::createFromNameV5(const QUuid , const QByteArray );
Thinking over it some more, the two function names above could instead be
createUuidV3 and createUuidV5.
In that vein, we could introduce overloads for v1, v2 and v4 taking no
arguments. We currently have an implementation for v4, with
QUuid::createUuid(), making that trivial to implement:
static inline QUuid createUuidV4()
{
return QUuid::createUuid();
}
The other overloads,
inline QUuid QUuid::createFromName(const QUuid ns, const QByteArray name)
{
// SHA1 (v5) is recommended
return createFromNameV5(ns, name);
}
inline QUuid QUuid::createFromName(const QUuid ns, const QString name)
{
return createFromName(ns, name.toUtf8());
}
would only be updated to call the right implementations, as appropriate.
Cheers,
João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt5-feedback] A micro API review: for V3(md5) and V5(sha1) in QUuid
On 9. des. 2011, at 17.10, ext Denis Dzyubenko wrote:
2011/12/9 João Abecasis joao.abeca...@nokia.com:
This has my vote:
QUuid QUuid::createFromNameV3(const QUuid , const QByteArray );
QUuid QUuid::createFromNameV5(const QUuid , const QByteArray );
inline QUuid QUuid::createFromName(const QUuid ns, const QByteArray
name)
{
// SHA1 (v5) is recommended
return createFromNameV5(ns, name);
}
inline QUuid QUuid::createFromName(const QUuid ns, const QString name)
{
return createFromName(ns, name.toUtf8());
}
I like names createFromNameV3() ! I also think we should have api that
takes QString (i.e. operates on utf-16 data) and QByteArray (i.e. raw
data), and maybe even an overload that takes const char * and int size
- for passing raw data.
Above, I already suggest versions taking QByteArray and that operate on the
byte data, or did you mean something different?
And what's wrong with QByteArray::fromRawData(const char *data, int size)? (Can
we do something in QByteArray improve it, for instance? That would keep
everyone from having to add that one extra overload...)
Cheers,
João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform / compiler support
Dr Craig Scott wrote: On 08/11/2011, at 1:31 AM, João Abecasis wrote: At the bare minimum, I think we should strive to support these compilers: - GCC 4.2 and up - MSVC 2008 and later - Clang (trunk) On the page above I also put in a list of platforms, splitting them between Desktop, Embedded and Mobile. The latter two categories only have a placeholder row, while for Desktop I put in the following platform-compiler mappings: - Linux: gcc 4.4 (Debian stable) - Microsoft Windows 7: MSVC 2008 - Mac OS X Lion: gcc 4.2, clang 2.9 I would strongly suggest that the LSB makes an appearance somewhere in the supported platform/compiler listing. To my knowledge, it is the only truly cross-distribution standard that exists for Linux. Does the LSB specify a compiler? Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform / compiler support
Friedemann Kleint wrote: Well, so far, no compiler has been suggested that doesn't support variadic macros :-) MSVC2010 does not support that (see b256d7b3bbe5ff6d3405255f0077e6b9635c8e7e in qtbase). Not all the world is g++ ;-) . MSVC actually supports variadic macros starting from VS 2005: http://msdn.microsoft.com/en-us/library/ms177415(v=vs.80).aspx Possibly not all gcc extensions to that are supported, but that's a different issue. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
