Re: [Development] Buddy group to help new contributors
Hi, On 05/01/2024 08:21, Elias Steurer via Development wrote: > git for windows comes with perl Is this new? Because my installation does not have it. I just checked, and the folder my env path points to only contains git.exe, git-gui.exe, and no Perl. This is not new - it has (to my knowledge) always been there. If you check the Git installation folder you'll find a .../usr directory and a .../usr/bin inside - that one contains Perl as well as hundreds of other Unix utilities. If you add this to your PATH variable you will have access to all of them. Git on Windows replicates a bit of the Unix hierarchy in its installation folder. But it only exposes a small subset to the Windows command line through the .../bin or .../cmd folders. Konrad OpenPGP_0xBE96A6EE776FE5D0.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt code browser url changed (cgit <-> cgit.cgi)?
Hi, Oh, yes, that works too. I originally just used the first working URL I could infer from the web page. It would be really super if cgit could show a proper clone URL. Konrad On 27/03/2023 15:31, Jukka Jokiniva via Development wrote: Hi, Should the repository url be without the “cgit”, like 'https://code.qt.io/qt/qt3d.git' ? “git clone https://code.qt.io/qt/qt3d.git” works for me. --Jukka OpenPGP_0xBE96A6EE776FE5D0.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt code browser url changed (cgit <-> cgit.cgi)?
On 26/03/2023 23:05, Andrey Leman wrote: Hi, Yes, the server has been upgraded to new version. Could you please test if it works as before now? e.g https://code.qt.io/cgit/... Nope, still getting errors on fetch: cd qt3d.git git fetch --all --tags Fetching origin fatal: repository 'https://code.qt.io/cgit/qt/qt3d.git/' not found error: could not fetch origin Konrad OpenPGP_0xBE96A6EE776FE5D0.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt code browser url changed (cgit <-> cgit.cgi)?
Hi, On 26/03/2023 14:16, Christian Ehrlicher wrote: today there was a thread on stackoverflow which mentions that the links to the examples don't work anymore. The links in the docs (and also in the source repo) are https://code.qt.io/cgit/qt/qtbase.git/tree/examples/widgets/... But it needs to be https://code.qt.io/cgit.cgi/qt/qtbase.git/tree/examples/... Did something changed recently wrt this? Do you need a bug report for it? It changed some time before or around noon on March 25th. I have a regular git pull job running in the background and it failed since the afternoon of that day. My guess would be that someone did maintenance or installed a new version and some minor mayhem was overseen... Question to the admins: will you fix the cgit URLs or does everybody else need to fix their links? Konrad OpenPGP_0xBE96A6EE776FE5D0.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] MaintenanceTool and/or InstallerFramework horribly insecure?
Hi Kai, thanks for looking into this. One more discovery: the Qt Account credentials are also stored with 0557 permissions - they really should be 0600 for the file and 0700 or 0755 for the directory. Credential storage permissions should always be overridden anyway and not be left to some automatic mechanism, like umask. In case this is of interest: my umask is 0022. In an ideal world it would even ask permission to store credentials in the first place, even better it could use a system service for storing them securely (kwallet, Gnome Keyring, Windows credentials store, ...). Wishful thinking... On 2020-05-23 06:13, Kai Köhne wrote: > thanks for the report. Volker forwarded it to the qt-project security mailing > list. Feel free to send further security related issues there. Thanks & I put it on Cc now. >> When I call MaintenanceTool to install another version of Qt it wants to >> sudo into root when it starts to download Qt components. It still asks >> for the sudo password if I quit while selecting components! > I assume you start a new installer here (not the MaintenanceTool of an > existing installation). Is that really during the download, or in the > extractio phase? Can you maybe create a bug report and attach the > installation log (you can start the installer with --verbose)? No, that was an existing MaintenanceTool, which first updated itself and then restarted into normal updates. It switches into root as soon as you leave the package selection screen. Regardless of variant: it should never set insecure permissions, it should correct insecure permissions when it encounters them on crucial files/directories and it should not elevate its privileges unless absolutely necessary - and then it should ask. (According to RFC2119 this "should" should really be "must"... ;-) ) BTW: it still has the bug that the default selection is "remove All" - after discovering those bugs I granted that wish, killed it and installed from source. So sadly no traces of MaintenanceTool or its logs are left on this machine. As far as I could see at the time there were no usable hints about this directory or permissions in this log, I'm not sure about starting the root process. If I have excessive amounts of time next week, I might retry this on my work machine - but I really have strong feelings about exposing it to such security nightmares. >> Worse, if I normally have sudo set to NOPASSWD then it does not even ask, it >> just switches! > This is now tracked in https://bugreports.qt.io/browse/QTIFW-1794 Thanks! As I wrote in my first mail: I highly recommend TQtC invests in a security audit for this tool - it is a crucial component that potentially exposes a lot of paying customers. The presence of bugs like the above seems to suggest that there may be more bad practices hidden inside. E.g. is the network transfer really secure against MITM? From my own experience: to have an audit performed on your code can be a pain in the behind, but it is worth it - the code is significantly improved. Konrad signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] MaintenanceTool and/or InstallerFramework horribly insecure?
Hi, I thought what the heck, lets update the pre-compiled Qt components on my computer. Apart from making me jump through the Qt Account hoop, I'm not sure whether this is deliberate (nefariously or incompetently) or just broken (please tell me it is a simple bug!): OS: Linux, Debian (testing), amd64 Installation-Directory of Qt: $HOME/Qt of the user running MaintenanceTool MaintenanceTool version: 3.2.2-0-202003121118 When I call MaintenanceTool to install another version of Qt it wants to sudo into root when it starts to download Qt components. It still asks for the sudo password if I quit while selecting components! Worse, if I normally have sudo set to NOPASSWD then it does not even ask, it just switches! The temporary directory installerResources has access rights 0557. Other directories are group-writable. I view those as severe security issues: - the installer (actually no tool whatsoever) should switch to root unless absolutely necessary, to prevent escalation of other security issues - no interactive tool should switch to root without informing the user - the installer must not make any directories or files writable for anyone but the user running that tool - otherwise other users are able to attack by inserting malicious code I have the bad feeling that someone should perform a security audit on MaintenanceTool and installer framework. Konrad signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
On 2020-02-03 15:04, Vitaly Fanaskov wrote: We don't need this method at all if everything is implemented with using smart pointers. What about the case when I want to delete a Widget from my window without closing the window? I often use deleteLater() because it is much easier than remembering a dozen layers of layouts and widgets that simply serve some layouting-purpose. Konrad ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
On 2020-01-29 17:02, Volker Hilsheimer wrote: You obviously don’t trust that TQtC will treat the data the online-installer either demands or requires with the appropriate confidence. So, shouldn't you build Qt from sources? Your IP address is PII, after all. Why did you trust that The Qt Company didn’t collect personal data from you previously - just because you didn’t have to enter your email address? There is quite a difference between an IP address and my mail address: the IP address gets assigned to someone else soon and you need a court order to get my name (at least in Germany). My mail address enables you to spam me. This, and a lot of what TQC employees are saying on these changes, does sound like the famous sentence from Don Mattrick about the Xbox One: "We have a product for people who aren't able to get some form of connectivity; it's called Xbox 360." Back to the topic, I have a Qt account, I do NOT want to use it to install Qt. I am pretty sure we will have community provided offline, and even maybe online, installers soon enough. I wonder where all this love for the Qt installer comes from. I personally consider “sudo apt-get install -y qtcreator” or “brew install qt-creator” or “choco install qtcreator" to be vastly superior to using the installer UI, and very easily integrated in VM provisioning. Any energy spent on making sure that the versions we get from those package repos is up-to-date would be worth a lot more (to me) than building another installer. I can only respond for myself: I don't love the installer, I find dpkg/apt/tar/zip much better myself, I merely tolerate the installer. But the fact is TQC does not provide Debian packages, so: a) if I really care about Qt and want "official" + "choice" I use the installer. b) If the installer puts an undue burden on me I'll settle for just "choice" as long as somebody else provides it. c) If that fails I'll build myself. d) And if this is too much of a bother for that package I'll skip "choice" as well and use whatever Debian is providing (most of the time I feel like this about GCC, various databases, Apache, etc.). It is a question of convenience and the amount of "giving a damn"... Konrad ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
Hi, On 2020-01-29 09:52, Cristián Maureira-Fredes wrote: I understand the video is an exaggeration, Is it? I found it was pretty much bang on. Even for Qt: I just counted - it took me 5 clicks, most of them not very intuitive, to download the Qt installer I currently need (Linux 32bit on a 64bit host). With the proposed changes Qt ventures eerily close to the video... Thankfully it did not ask for my name, date of birth, email address, mothers maiden name etc. - none of which is any of TQCs damn business. For comparison: the typical Open Source download is 2 very intuitive clicks - click the "Download" link, get a nice long list of available and supported packages, click the one I need, use the system installer or tar to install the package. but in any case, there is something I really need to understand: Currently, you can create a Qt Account with your email and a password, when you received the email, you confirm by clicking on the link, and then you can optionally enter your information. Yes, and currently (thankfully) I normally do not need it. I certainly do not remember the password I used, nor do I remember where I stored it (it's ... somewhere...). Should I find another bug, I'll dig it out and then log in... or request a password reset... ...though I'd prefer to not need it then - e.g. I can report Debian bugs without a password by simply sending a mail or using a script that asks for the relevant info. I certainly will not bother with this for a simple download. Doing that, now I have access to the future installer, I can manage my Qt downloads, install the binaries, remove components if I will not use and everything else. Which basically means I will stop messing with the web page and use the GIT source tree to compile Qt, while my colleagues, who I wanted to convert, will continue merrily with C# (the horror!). I'm already planning for a simple Jenkins job on my home server that will check for new Qt releases and automatically build them for me in a Docker container while I sleep... How different is this process from registering to this mailing list for example? IIRC I entered my email, my name, and a password, then I got an email, clicked on the link, verified my name again, and then I was welcomed to the mailing list. Very. The mail list was fire and forget. I didn't even enter a password, the mail list software assigned one (AFAIR). I will never need the password ever again until I unsubscribe. But sure, the mailing list is not software, but a service to communicate with others. Since the installer is a service that TQtC provides, for me is really not difficult to understand that I will require an account, after all TQtC is responsible of having a working CI that can generate those binaries for your convenience. Sure, this was not there before, but is it really so strange? and rude? Strange, if you come from the Open Source world: yes! Rude? Depends on how radical you are behind this GDPR thingy... I see it like this: the CI exists for two reasons - to help the developers do better code and to assure paying customers that Qt has quality standards. Building the binaries on the CI is just more convenient than doing it by hand. So I don't see a direct connection between the two. Besides, as an Open Source user I do not care about either one. (As a developer I do care about the first one.) From my point of view providing binaries is something you do to convince passers-by to become users. Making it more difficult is something to make sure you are not disturbed by pesky users. Remember, it is already quite difficult now... May I humbly suggest you try to convert users into customers after they have been converted from passers-by to user? BTW: in the past I would have convinced one of my customers to buy support for the Open Source version if it had been available. If there was a simple possibility to buy a single support incident (say, for 100Euros) I would even do this occassionally as a private Open Source user when I come across a problem I can't or don't want to solve myself! Regarding the LTS decision, you can take it from another point of view: 5.15 will only have 2 or 3 bug fixing releases, and so will all the LTS versions in the future. Since TQtC has commercial costumers, Cool! What kinds of costumes do you do? Can I dress up as the Grinch? [SCNR] :) we will internally fork the latest bug fix release, and will start adding patches on top of that on request of the costumers, but hey! all those patches will be on Gerrit, so if they are important for your work, you can just cherry pick them to your local Qt and re-build. Nice. If as an Open Source user I would stay with LTS, then I don't have time to even research what bug fixes I need. If I had the time I would have ported to a newer version of Qt. So this argument is a non-starter. Someone will hopefully create an Open Source branch for the LTS release
Re: [Development] QtCS2019 Notes: QtCore
Hi, On 11/23/19 9:47 AM, André Pönitz wrote: qsizetype QContainer::size() int QContainer::count() const Please no! This will forever flood the interest mail list with questions about what the difference between the two methods is. It will also introduce a lot of subtle little misbehaviors when people mix the methods without thinking. From time to time you'll see them surface with questions like "Why does QByteArray give me the wrong byte?" I'd rather have the compiler tell me that I need to change my code than hide it from me. Warnings are there for a good reason. The only way to do this with this proposal is to make count() deprecated from the start! So, why bother with duplicated API in the first place? Konrad ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi, On 6/27/19 3:47 AM, Lars Knoll wrote: > > Yes, Webengine uses some memory. But is that really a problem on developer > machines? It is a problem, but IMHO not the main problem. The main problem is that WebEngine is not available on all platforms that are supported (as a development host) by Qt. Just to make sure I just installed Qt 5.13 for MinGW 7.3 on my Windows VM - WebEngine is nowhere to be seen. (Sorry, I don't have enough capacity to check whether I might be able to compile it myself using clang.) Please also keep in mind that a fair number of developers use the same tool-chain (qdoc, assistant, QtHelp) to generate their own documentation - this means that assistant gets redistributed. One of my biggest Applications is 15MB on its own, 74MB including Qt and all remotely necessary plugins. Adding WebEngine adds 115MB, assistant itself is a mere 18MB. Please do not expect me to like this, having to accept it is enough... > People propose adding functionality to QTextBrowser instead. I do not thing > that’s a viable solution (we’ve tried that in the past and our technical > writers hit the next issue some weeks/months later). The problem is not that > one could not add support for one or two new features to QTextBrowser, it is > that we do not know what features we will need in our docs in the future. ...as I wrote earlier - none of the possible solutions are ideal. Someone has to invest some work somewhere. QTextBrowser, WebEngine or Technical Writing - make a choice. Chose wisely! ;) Konrad ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi, On 6/25/19 9:59 PM, Tor Arne Vestbø wrote: > On 25 Jun 2019, at 21:30, Konrad Rosenbaum wrote: >> Pardon my lingo, > You should be able to communicate your points without that kind of lingo. Try > better. > >> It is documentation for developers for crying out loud! Its purpose is not >> to win any design prices, but to educate the developers. > Please stop putting up straw-men, it’s not helping this discussion at all. Okay, let's formulate this in a way that hopefully doesn't offend you and doesn't seem like a straw-man to you. Qt6 has a couple of options for documentation, none of them are ideal: Option 1: leave everything as is with a QTextBrowser based assistant and some tweaks in the qch files. Pros: no additional work required; all current features and use cases stay supported; good enough for a lot of developers Con: looks ugly enough to actually offend visually sensitive developers. Option 2: put some elbow grease into QTextBrowser and make it understand some more tags and more CSS. Pros: documentation becomes visually more pleasing; minimal dependencies by assistant - easy to build and easy to bundle with applications; embedding in Creator or KDevelop etc. stays easy to do Positive side effect: users will love it, since it becomes much easier and flexible to use QTextBrowser in their own applications Con: someone actually has to put in the work Option 3: bring back WebKit Pros: looks beautiful; uses up less memory than WebEngine Cons: someone has to put up lots of work to actually support WebKit; uses up lots more memory than QTextBrowser; adds a dependency to assistant (makes it less useful for redistribution); embedding in IDEs is slightly more complex and adds a dependency Option 4: convert to WebEngine Pros: looks great; currently supported browser engine, only little porting work Cons: horrible memory footprint; acute terminal featuritis; adds lots of dependencies (disqualifies it for most/many people redistributing it); does not work on all platforms supported by Qt (makes assistant less useful or even useless to those users); embedding in IDEs becomes much more difficult (dependencies and #ifdef's for unsupported platforms) Option 5: use WebView Pros: might look good Cons: either looks bad or adds whatever component WebView wants to use as a dependency; unpredictable results Option 6: use plain platform browser to show local files Pros: minimal footprint; assistant can be retired; guaranteed good rendering Cons: you never know which browser the user installs; abandon QCH format; implementing search becomes a horrible mess of JS and other files - requires extensive tool support to generate this - doubtful that it will always work; forget embedded viewers - this would require WebEngine or WebKit again; some users will hate the fact that assistant is missing or at least unsupported Option 7: platform browser plus server process to deliver help via local HTTP Pros: like Option 6, but search becomes easier to implement Cons: like Option 6, except search; someone needs to implement a simple HTTP server (not that hard, but requires some work) and a search engine (slightly harder, but solvable) My personal favorite would be Option 2 (better QTextBrowser), followed by Options 1 (status quo) and 3 (WebKit) in no particular order. But since I'm not willing to put in any serious work or pay for it - my vote does not count - I'm just a user. ;) Feel free to correct/critique my assessment and to add more options if you see any. Otherwise: chose your poison. Konrad pEpkey.asc Description: application/pgp-keys ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi, ...my 2 cents or so... On 6/25/19 4:30 PM, Palaraja, Kavindra wrote: > No, parity isn't Google's search box. There's already a search feature in > Creator. > > No, not "The Qt Company is hiring" either. > > The idea is to have parity in the sense of 1:1 appearance of how the > documentation looks like. Pardon my lingo, but I do not give a rats furry behind about how it looks and whether it is on full parity with the way it is shown in a browser as long as I have all the content. It is documentation for developers for crying out loud! Its purpose is not to win any design prices, but to educate the developers. > Here's a ticket that hasn't gone very far: > > https://bugreports.qt.io/browse/QTCREATORBUG-15887 > > Can we keep the personal attacks out of this and perhaps stick to the issue? > I'm definitely not lying. I don't see any tables being rendered the way > tables should be rendered in HTML. Unless I'm losing my eyesight? Sorry, but I just tried a very simple example with QTextBrowser: In my book this is exactly like a table should be rendered. Granted it is not very flashy looking, but it is definitely a table and it has borders. Source: #include #include int main(int ac,char**av) { QApplication a(ac,av); QTextBrowser tb; tb.setHtml("helloworldwoohoo!"); tb.show(); return a.exec(); } (embedding
Re: [Development] Assistant WebKit/WebEngine support
Hi, On 6/24/19 2:43 PM, Simon Hausmann wrote: > We've had this situation for a long time now and I think that we should > finally move forward and give our users better quality at the expense of > their disk space, memory consumption and download size. ...at the risk of making enemies: so the platform issues(*) will be solved till Qt 6.0? So, even if I try to compile Qt myself on, say MinGW or 32bit MacOS - I will end up with a (fully?) functional Assistant? (*)https://doc.qt.io/qt-5/qtwebengine-platform-notes.html Konrad pEpkey.asc Description: application/pgp-keys ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing CMake as build tool for Qt 6
On 6/17/19 5:09 PM, Thiago Macieira wrote: That's assistant. But do we need a standalone qch viewer application? Yes please. There is at least one user who loves Qt and dislikes QtCreator. While it is possible to view Qt Help in a browser, it is more comfortable to use Assistant with its specialized search. Konrad ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt branches & proposal how to continue with those
On Tue, January 30, 2018 00:18, Kevin Kofler wrote: > I would on the contrary expect users to want new features sooner rather > than > later, [...] Please keep in mind that there are several classes of Qt users: Mobile: moving fast and furious. Depend on novelty. General Desktop: moving somewhat fast. Prefer novelty. Offices w/ IT admins: move much slower. Prefer stability over novelty. Industrial, regulated and embedded: move extremely slow. Depend on stability. I've been in projects that jumped ship every time someone invented a new buzz word and in projects where I had to compile my own GCC and X11 libraries because no supported version of Qt would compile with the one(s) in the target OS. Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)
On Mon, October 2, 2017 11:54, René J. V. Bertin wrote: > Konrad Rosenbaum wrote: >> Whenever a QueuedConnection triggers the sending object generates an >> event >> and delivers it to the event queue of the thread that owns the target >> slot's > > So the sending object knows that the nature of each connection to it? The code behind the signal knows about it and how to deliver itself. >>> Can I assume >>> there's some kind of fifo that ensures signals are delivered in order >>> of >> >> Never assume order. > > Ok. From your other reactions I infer there is something like a > mostly-fifo with > a mutex that protects pushing and popping :) More or less: yes. The input is thread safe and FIFO (or as FIFO as you can get in a multi-threaded environment), the output has priorities and filters. >> deterministic or in order. Threads execute in a (seemingly) random order >> and >> can interrupt or race each other. > > And one cannot even rely on mutexes to "fix" or prevent that? If you use Mutexes right you can rely on them to serialize the code that blocks on the same Mutex, i.e. only one blocking code block is executed at the same time. You cannot predict which thread gets the Mutex first or last. Since Mutexes are a special case of semaphores, the same is true for semaphores (again: if you use them right). The OS can interrupt your thread at any time and give the CPU to another thread or process that is ready to run (a thread waiting for a blocked Mutex is not ready). It may also interrupt your thread and run a signal handler in the same thread! On the other hand if your machine has multiple CPU cores the OS may let several threads run happily at the same time on different cores. Depending on hardware timings and bus congestion these threads may race each other. >> important or less important than others - e.g. the deleteLater event is >> normally only handled at the top level of the event loop to prevent >> crashes >> caused by less then absolutely ingenious programmers using >> QueuedConnection, >> deleteLater and QEventLoop (that fact saved my bacon a few times). > > Sounds like the situation that ObjC/Apple addressed by using refcounting > instead > of direct deletion. If by "problem" you mean programmer stupidity (or if you prefer: naturally limited cognitive capacity): yes. ;-) > Anyway, order isn't crucial in the particular application I'm working on > here. > The only thing that matters is that signals are delivered in an acceptable > time- > frame after having been sent. And that should be the case (my initial > reason for > getting involved with this was to keep the main event loop from being > blocked). If by "acceptable" you mean "fast enough for a human being", then yes - QueuedConnection will do this for you reliably enough. With Qt there are some simple rules: If there is the slightest chance that a QObject is used/called across threads - use deleteLater instead of delete. For calls across threads use QueuedConnection explicitly. (In most cases Qt detects this automatically, but there are some special cases usually involving moveToThread().) Do not feed pointers or references into signal-slot-connections. Avoid sharing pointers/references between threads. Do not make any assumptions about the order of signals or slots. Try to avoid the assumption that a signal only returns after the slot has been executed (or that it returns immediately) - you'll mess with connection settings soon enough after you forgot that you rely on it. Regard signals as fire-and-forget-but-maybe-take-some-time-with-unknown-effects. The combination of these will ensure that your application behaves in an acceptable manner. QueuedConnection and deleteLater use the same event queue, so Qt is able to detect if an object disappears while delivering a signal. If you absolutely, positively have to share pointers between threads: a) try to refactor, if that fails: b) make 100% positively sure that the object lives longer than the sharing; use QPointer (makes debugging easier); write twice as many lines of comments as you write code so you cannot forget. If you have to block on signals: try to use multiple signals instead of a hard block; document! Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)
Hi, On Saturday 30 September 2017 16:24:57 René J. V. Bertin wrote: > Konrad Rosenbaum wrote: > > Apart from this I'd suspect you will still get the SEGV if you do not > > block - even if the frequency changes. > > As in when emitting the signal too frequently from multiple threads? No. as in how many times out of the total signals delivered it actually crashes. When dealing with threads and signals between them determinism flies out the window and the tiniest change in timing can change behavior radically. > For my personal education, what happens behind the scenes when a signal is > sent from one thread to a slot in a different thread? Whenever a QueuedConnection triggers the sending object generates an event and delivers it to the event queue of the thread that owns the target slot's object. Whenever that thread's event loop is called again it will start to work on those events > Can I assume > there's some kind of fifo that ensures signals are delivered in order of Never assume order. > being sent and such that producer and consumer don't try to modify > (access) the queue concurrently? Kind of. The receiving end of the event queue is of course programmed in a thread safe way. And new events are usually queued towards the end of that queue. BUT. There are complications: for one, and this cannot be stressed enough, if you are dealing with threads you cannot assume anything to be completely deterministic or in order. Threads execute in a (seemingly) random order and can interrupt or race each other. For another: some events are more important or less important than others - e.g. the deleteLater event is normally only handled at the top level of the event loop to prevent crashes caused by less then absolutely ingenious programmers using QueuedConnection, deleteLater and QEventLoop (that fact saved my bacon a few times). So, the order of events is not 100% guaranteed. Most of the time events will be received and handled in the order they were sent, but there are exceptions. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)
On Saturday 30 September 2017 11:31:13 René J. V. Bertin wrote: > Thiago Macieira wrote: [about internal mutex] > > You cannot, because neither the kqueue, inotify or poll backends do > > that. > > Those three have no mutexes at all. You have to block the event loop of > > the thread they were created on. > > That all applies to multithreaded usage, right? What happens when a change > is signalled while an item is being added *on the same thread*? At least > the kqueue and inotify backends are written around an API that sends > asynchronous notifications, no? You do know what a thread is - right? ;-) A quick google search tells me that inotify and kqueue work by signaling file events through the normal mechanism of the event loop. This means the change is appended to the event queue and handled the next time this thread is idle or explicitly calls the event loop. It is impossible for the change event to interrupt the add method or vice versa. The only mechanism that can do this in the same thread is a signal handler. Sorry, I'm too lazy/busy to read the source right now to make sure that no signal handlers are used here. > I'm now investigating the idea of sending a signal from the dirlister > thread, connected to a slot in the main thread with Qt::QueuedConnection > . After some initial success I'm now getting a SEGV that I don't yet > understand. I'm beginning to wonder if one shouldn't use a blocking > QueuedConnection... BlockingQueuedConnections should only be used if you really need the result, there is no asynchronous way of transmitting the result and you can make sure that there will not be a deadlock. Apart from this I'd suspect you will still get the SEGV if you do not block - even if the frequency changes. This points to you using some kind of pointer that is not properly controlled (e.g. sending a signal to a QFSW that is already deleted). Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)
Hi, On Fri, September 29, 2017 11:35, René J.V. Bertin wrote: > I've been running into issues using adding and removing entries from QFSW > in concurrent threads. [cut] > The QFSW documentation only mentions the class is reentrant. Is QFSW > supposed to be thread-safe (at least at the class level), on all > platforms? Or do we have to provide our own protection mechanisms if we > want to use the class this way? In the Qt documentation (and most other sane docu) "reentrant" means the class can be used on different threads, but each instance must be restricted to a single thread. You can have different instances on different threads. Actually documenting it as "thread safe" would imply that even instances can be shared across threads. This is much harder to implement for (I believe) obvious reasons. This is why you were able to solve the problem with a Mutex: you ensured that the instance was only used by one instance at a time. Another way is to explicitly use Qt::QueuedConnection to feed the QFSW or to untangle your code to ensure each QSFW is only visible from one thread. Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OT: English phonetic spelling (was: QList)
[quite OT, but I'll pile on... - just for fun] On Mon, March 27, 2017 17:43, Matthew Woehlke wrote: > Iä, thät güst lûks wråŋ. Yf wi wÿr tu ëvÿr du süch thyŋz, ai wûd müch Let me propose the more "Jusfull" "Jäh" - which is somewhat easier to read. > räthÿr swytch holsel tu ü kümplitli fünëtyk spëlyŋ üf ëvrithyŋ. Ai häpyn > tu lüik thys systûm wych ai ëm dëmünstretyŋ hir ;-). Are you using Gaelic pronunciation on "lüik"? The only way my tongue seems able to pronounce this is with an almost silent "i". > On 2017-03-27 03:43, Marc Mutz wrote: >> Been there, done that. Delphin is now spelled Delfin in German. For - >> what - >> 20 years now? It still looks wrong. Oh, and the public outcry back then. >> And >> the economic damage caused by having to re-proofread, re-edit and >> re-print a >> ton of Flipper books... > > ...and, correct me if I'm wrong, but German is generally spelled how it > is pronounced, yes? Yes, German is almost completely phonetic - except for very few loan words that have not completely assimilated yet. But there are efforts under way to send them on an integration and language course, now that they've gained asylum and are proven to be mostly harmless. The perceived "problem" they tried to solve with the reform was that several phonemes have more than one possible spelling (e.g. "f" and "ph" as demonstrated above) and there were some minor exceptions to grammatical rules (e.g. conversion between "ss" and "ß" is not entirely logical all the time). ...while all of this supposedly made things easier for young students, it's hell for scientifically minded adults - it's called "Telefon" now, but the "f" in there is still a quite foreign "Phonem" (both derived from the greek word for sound), while the aficionado of ancient greek in the other room insists that "this is not how you spell greek words! It's the wrong alphabet(*)." :-( (*) or is this Alfabet now - I can never remember this one In short: even completely phonetic languages with reforms that make the language even more logical and phonetic provide ample opportunity to screw up the spelling of several generations while also providing for futile, but heated, discussions and some bloody noses. Please keep English weird! That makes it likeable. Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Containers member functions for algorithm
On Thursday, March 23, 2017 10:36:06 Marc Mutz wrote: > There're > proposals floating around for years to make o.f() fall back to f(o) for std > C++. Those are a lot more pain than you'd think! This construct already exists in C# (static extension classes/methods) and it is causing major headaches there - depending on your using statements (equiv. of #include) what looks like a simple method call can mean totally different things or not work at all! A change in a different section of the class that necessitates an additional using directive may cause all kinds of mayhem. It is a nightmare if you have to diagnose problems. In short: the recommendation in the C# world is: "do not use them unless you absolutely positively have no other choice." We should take that as a warning. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
On Mon, March 20, 2017 15:19, Marc Mutz wrote: > Well, seriously. My answer is the same: Time has only one direction. Qt > source > and binary compatibility only has one direction. If you want to use Qt in > a > way it was not intended to be used, then you need to pay the prize, and > not > ask the community to do so for you. > > You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt > 6. > You can define your own MyQListOrQVector type alias. Or you can #ifdef. > It's > up to you. Marc, please do not underestimate the impact of laziness! Whether we admit it or not: most of us became computer scientists because we're lazy - we want to let the machine work for us! ;-) Everybody else at least works for for someone who is quite tight-fisted with the budget. In other words: if Qt 6 forces me to do any significant amount of porting, then I'll stay with Qt 5. I was able to port my biggest Qt 4 application to Qt 5 because I could promise my client it'd be done in a couple of days and he'd gain lots of features too. If I have to replace every single occurrence of QList with QVector or auto for it to continue working with Qt 6, then I will not get a budget for that. The community will pay for my laziness by having to support an outdated framework for much longer. Lazy people are great at externalizing... :-P Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Wishes for C++ standard or compilers
Hi, On Mon, March 20, 2017 08:20, Olivier Goffart wrote: > On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote: >> The name is necessary for compatiblity iwth other languages. > > Can you elaborate? > In QtScript or QtQml, the name is only used for error message, or for > compatibility before the QMetaObject was in the QMetaType. > Types that can be used directly needs to be registered with functions such > as > qmlRegisterMetaType > > I see many use in QtDBus but I suppose if it falls in the category of > types > used for signals and slot which could be registered by moc. There are more bindings than just QtScript and QML. Any dynamic binding that does not want to force the user to register again(!) every single type that could possibly appear somewhere in the API needs to know the name. At least if it wants to be compatible with itself between versions and platforms. Type IDs can change in between versions of a program or even if only an underlying library is updated. For example: I'm currently writing a utility that taps into a Qt program without modifying the program itself and allows to inspect objects and properties (something technically similar to GammaRay). In order to serialize and deserialize the properties of objects I need to be able to reliably determine the type of those properties on both sides and be able to reconstruct them, or at least to be able to determine whether I need to fall back to a string representation. For user types the name is much more reliable than the ID. In other projects I've used the MetaType system to expose type names of data stored in a QVariant to Tcl based scripts, a formula parser with dynamic typing, a template rendering system, or debugger utilities. The common theme among those was that I did not know what types my utility would face at the time I wrote the utility accessing QVariant. And those utilities usually work rather invisible to the libraries originating the types used in them and vice versa. In short: being able to get both an ID and a name for a type stored in QVariant makes a lot of magic possible that would otherwise require major blobs of glue code or it would otherwise simply be so inconvenient to use that it wouldn't be worth bothering. Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] syncqt.pl in C++
Hi, On Wed, March 8, 2017 21:23, Jake Petroules wrote: > Personally, I also prefer a build process never touch the network, but the > average developer isn't that picky and just wants to Get Things Done. The average test engineer is that picky and even worse! A test engineer expects to save a minimal VM of the build system, boot it up a year later in a completely isolated environment (i.e. no network or access to external repositories) and then it should build the exact same binaries bit for bit (minus the file create time). Also: I've worked in environments in which a network connection for build scripts would have been quite difficult to accomplish if not impossible (e.g. isolated servers with no access to the web proxy or proxies with rather strange setups). Every little dependency had to be downloaded manually (sometimes from a completely different network) and transferred into the build environment over several stages - that's especially funny if you're building from source because the pre-built binaries don't run because they require a newer system. No, those environments are exceedingly common in industry. If you want to keep the Qt build process as flexible as possible: 1) minimal dependencies (i.e. compiler, maybe one or two simple tools) 2) no network access 3) can be built completely from sources, no binaries in the archive 4) no self-dependency (i.e. does not require binaries of itself to build) otherwise: expect complaints from people living what is jokingly called "real life". ;-) Do NOT expect modern connected systems at the user's side! Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Windows: Trying to join to a multicast group as a receiver with specific interface always uses default interface
Hi Thiago, On Fri, January 27, 2017 04:49, Thiago Macieira wrote: > If it is IPv4, the priority for your issue has just dropped to the floor. > I > won't debug IPv4 multicast on Windows, on principle. > I will review IPv4 patches, but I will not lift a finger to test them. I'm not sure whether this argument is persuasive for you: industry will stay on IPv4 private networks (192.168.*, 10.*, 172.16.*, etc.) for a LONG time. The networks are working, the infrastructure is known to every admin out there, and lots of software has problems with IPv6 if it supports it at all! In fact quite a few of my colleagues will not recognize 2001:db8::42 as a valid IP address... In short: IPv4 (including multicast, which is used for "message buses") has to work well for the foreseeable future. Even on an OS that we both would not recommend for production use... ;-) Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds
Hi, On Monday 28 November 2016 17:11:19 Konstantin Tokarev wrote: > Currently, MinGW builds in Coin use -system-zlib configuration. It happens > because MinGW is shipped with zlib headers and libz.a. However, linking zlib > to several Qt modules (at least, QtCore, QtGui, QtNetwork, and QtSvg) is > suboptimal, while with -system-zlib one copy in QtCore is shared between > all modules. Please be aware that there are quite a few Applications out there that use zlib independently of Qt - e.g. to encode/decode ZIP files. Unfortunately Qt does not expose its internal zlib headers, nor does it wrap all functionality of zlib. So at the very least qt-zlib needs to be linked in a way that allows an additional version of zlib to be linked. Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] linuxdeployqt
Hi, On Wed, September 21, 2016 10:11, probono wrote: > 2016-09-19 16:45 GMT+02:00 Louai Al-Khanji : >> From a quick look it seems to be mostly well written. I do wonder >> whether it might be better to use a tool other than ldd to find the >> library dependencies. objdump -p provides the same information, and also >> works for cross-compiles. > > ldd not only provides the name of the libraries to be loaded, but also > the paths to the locations where they are loaded from. How would I get > this information without using ldd? By implementing the same algorithm? It's pretty simple actually: * go through $LD_LIBRARY_PATH * go through RPath * go through /etc/ld.so.config (I think there are 1 or 2 more, look it up, it's documented) RPath may be a bit tricky: normally Qt compiles it's lib path into RPath, but with a deploy script you do not want that RPath anymore, instead you'd want to change it to $ORIGIN (literally, not the value of a variable). So you may have to check the location of linuxdeployqt and derive the original lib path from there. For each path that is being checked: find a file that matches the name, check that it has the correct ELF platform (x86, amd64, x32, arm, etc.) - if it matches, take it and add its dependencies to the list. Ldd has several downsides: * it may not be available on some platforms (e.g. some embedded devices) * its output format may change without warning * it cannot check programs for platforms that do not run on your host (anything that is cross-compiled, or if the binary loader is missing or broken) * it is unsafe (although we'll assume that you will not compile and deploy a program that sabotages your own System) Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why is QVariant::data() \internal?
Hi, On Monday 18 July 2016 07:59:21 Jędrzej Nowacki wrote: > On Saturday 16 of July 2016 13:56:00 Konrad Rosenbaum wrote: > > I am currently interfacing two libraries that only have QVariant in > > common, most of the (value) types getting exchanged are either Qt > > containers or Q_GADGETs. > > > > I was relatively quick to realize that I needed the QMetaType and > > QMetaObject of these objects, but it took me pretty long to find out > > that I can use QVariant::data() to get at the void* that I need to > > access properties and Q_INVOKABLEs. > > > > Is there a particular reason that QVariant::data() is classified as > > \internal or would a documentation patch be accepted? > Mostly because it should not be needed. I can see why it should not be needed in 95% of situations. But there is this tiny little fraction of cases in which QVariant is the only commonality between interfaces. Esp. if those interfaces are supposed to be generic, non-related and exchangeable. I'd argue it is needed often enough to merit some documentation with a big fat warning for the other 95% of cases. > Why can't you use https://doc.qt.io/qt-5/qvariant.html#value or > https://doc.qt.io/qt-5/qvariant.html#qvariant_cast ? The library that is looking into the QVariant is a generic calculation/templating engine that uses QVariant to exchange data with whatever outside caller is using its services. It does not know what kind of data types the calling code uses - all it can assume is that it gets property names to find the values it is really looking for. It does not even know why it is being used. The data source may be the calling code or it may be a completely unrelated library. Example: Lets assume the engine is configured to work on strings and it gets the formula {'I am ' + my1.name} and "my1" is configured to be a pointer to a QObject-derived class or a Q_GADGET. The formula itself will usually come from some kind of configuration (otherwise: what's the point!). What the library code does is parse the formula, delve into the QObject or gadget behind "my1" and retrieve the property "name". For some use cases demanding that structured types are QObject is simply not feasible since the remainder of the use case may demand value logic (in my current specific case it represents data exchanged over the network). Writing a formula parser is complex enough for me to definitely not wanting to tie it to one specific application - hence I do not want it to know the specific structured types - I want it to explore those types through some kind of reflection - turns out QMetaType/QMetaObject is a wonderful way of doing this. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Why is QVariant::data() \internal?
Hi, I am currently interfacing two libraries that only have QVariant in common, most of the (value) types getting exchanged are either Qt containers or Q_GADGETs. I was relatively quick to realize that I needed the QMetaType and QMetaObject of these objects, but it took me pretty long to find out that I can use QVariant::data() to get at the void* that I need to access properties and Q_INVOKABLEs. Is there a particular reason that QVariant::data() is classified as \internal or would a documentation patch be accepted? Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
On Friday 10 July 2015 17:01:04 Smith Martin wrote: > And apparently QVector has the same API as QList now, so why don't we > deprecate QList. Let it always create a QVector. Do you mean deprecate for use inside Qt? Maybe in Qt 6 or 7. In general? For user code as well? HELL NO! (sorry for the shouting...) Thiago listed a few exceptions under which the use of lists is legitimate. These situations exist - more frequently than some of you seem to believe. At least in code that was not written under ideal circumstances (which in my sad little corner of industry is about 99.5% of all code). Believe it or not - I've got plenty of code in which I frequently and dynamically change the size of lists of complex objects. Doing this with QVector would create its own kind of re-allocation hell. And no, for most of these instances it's impossible to predict how large the list will be before it is complete - it often depends on data that first needs to be parsed, analysed, requested, or otherwise pulled piecewise out of some remote process' tight grasp. If Qt deprecated QList I would have to convert a lot of legacy code to std::list; neither QVector (allocation hell) nor QLinkedList (slow retrieval with large data sets) are serious alternatives. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Avoid overloading of 'error'
On Thursday 11 June 2015 07:29:51 Smith Martin wrote: > onError is immediately understood by all sentient beings in the universe. So, apparently either Germans are not sentient or from outside this universe. Might explain a lot about me... At the very least I disagree with your use of "immediately". The phrase "on error" has no immediate translation in some languages - e.g. in German it has to be translated to "nach Fehler" ("after error") instead of the more literal "auf Fehler" ("on-top-of error") or the intuitive (but very wrong) "an Fehler" ("at/next-to error"). On the other hand "onSuccess" always sounds like a toast to me ("Auf den Erfolg!" - "To success!") and it takes me a while to understand why a program would believe in performing rituals for good luck. It might be this oddity of my language, but I really hate this whole "onSomething" style - it reeks of hungarian notation and seems completely superfluous. Either way, since I don't care much about QML/JS - do whatever you like there. But PLEASE do not ruin it for the C++ side! Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Thursday 17 July 2014 21:31:31 André Pönitz wrote: > PS: Random side-track question: How comparable are values of type 'int' > and 'QUrl' if one applies 'common sense'? I even accept answer related > to non-0 int values only. The trouble with common sense is that it is not very common in any sense - neither do a lot of people have it, nor do the remainder share a common vision of it... ;-) I'll try anyway... Intuitive answer without a specific use case in mind: they are not comparable at all - an int is a completely different beast from a URL. Answer with weird use cases in mind: the int could represent the path of a relative URL. E.g. I could create a cache directory in which I enumerate my resources with a simple int counter (cyrus IMAPd does something similar for mail storage) and finally express this as a relative URL - as a transient conversion int->string->URL. I could also imagine the int representing the host (IPv4 address) or port of the URL, but it gets really weird once you attempt to go there with automatic conversions and try to reconcile the result with RFC3986. In short: an int is just too ambiguous in relation to a URL to justify an automatic conversion. Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Wednesday 16 July 2014 08:41:07 Poenitz Andre wrote: > Olivier Goffart wrote: > > It's always a dilemma. We have to look at how likely we are to break > > applications and I don't think adding a conversion is likely to cause > > breakages. > > Type safety is a safety net that catches errors very early in the > software production and deployment cycle, and one of the features > that makes a programming language usable for the development > of large applications at a reasonable pace. I feel I need to clear up some misconceptions here: the kind of type safety offered by C++ is a possibility, but not a necessity for fast and safe development of large applications. I've done Smalltalk for quite some time - it does not have a static type system like C++ and development is still faster than in most C++ based environments - I'd even go as far as saying it is slightly faster to develop with Smalltalk than it is to develop with Qt (I still prefer Qt for its more modern API). The key is usually great documentation, good tooling, good APIs and fast turn-around from adding a few lines to seeing them in action (in the last point C++ can't even hope to compete with Smalltalk, the other three are quite good with Qt). > Implicit type conversions kill type safety. This is widely recognized > as a bad thing. In case of C++ some are "unavoidable" due to the > C legacy, but e.g. for user-defined conversion operators we now got > "explicit", _because_ people learned the hard way that implicit > conversions are causing more trouble than wanted. Let's not mix up too much here: type conversions are necessitated by the fact that C++ has static typing - otherwise you would not get much done with it - from the Smalltalk point of view C++ is not polymorphic. Implicit type conversions are necessitated by the fact that programmers (like me) are lazy bastards and don't like to read lines which are longer than a couple of words. The explicit keyword is just a way of telling the compiler that a constructor is NOT a type conversion - however, I'm not entirely sure whether it was such a brilliant idea to have two kinds of implicit user defined conversion (constructors and type operators). So, just get used to the idea of prefixing each constructor with an "explicit" and only consider removing it again afterwards. > This is a kind of "convenience" I don't need, and I pretty much prefer > the inconvenience of having to spell out type conversions explicitly. Reminds me of the early days of Java - almost every cast was explicit and you wrote endless lines of casts just to get a very simple resource. Thanks, but no thanks. In short: you need a certain amount of convenience to not hinder the programmer. Too much magic in the background and it is just as bad. The difficulty seems to be to define the ideal point between convenience and shooting yourself into the foot all the time. As long as QVariant mirrors the abilities of C++ (i.e. only using implicit conversions that are also available in plain C++, plus maybe a few very obvious ones, like toString) we are fine. More and we'll get weird bug reports, less and programmers will constantly bitch about it. BTW: you can already implicitly cast QByteArray->QString, so why not allow it through QVariant? Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Managing the Addition of New SSL Backends
On Saturday 03 May 2014, Richard Moore wrote: > Support for QNAM > > > It's obvious that to be useful, a backend must allow QNAM to make SSL > requests. It need not support the more advanced features such as > client certs, custom CAs, custom cipher suites etc. > > In order to handle user exceptions, we need a way to signal the > errors. This means that QSslError would be required. Another option > might be to offer some pre-built UI component for this, but that has > the issue that a single component would probably not be a good fit to > many UIs. A pre-built dialog to show certificates (like QFileDialog does for directories/files) would be great! BUT: please do not remove the QSslError API!! Don't even consider replacing it with a default dialog or otherwise making it optional! Many applications need to be able to store SSL-Exceptions in their configuration and NEVER prompt the user about them. For example one of my bigger projects is a point-of-sales application for theaters that communicates with an HTTPS server. Explaining to my users that the name of their spouses did not make a good password - even if they don't tell anyone - was so exhausting and unsuccessful that I had to add another layer of security to the program to limit the potential damage. I shudder to think about explaining SSL certificates and possible error conditions to them! > Another issue is displaying the certificate to the user. The > QSslCertificate API is large, and whilst I think most backends would > be able to provide most (if not all) of the facilities this is still a > significant barrier. Instead, how about we allow QSslCertificate to be > used as an opaque type for most apps? This could be done by providing > access to the platform native (or a Qt provided) certificate > dialog. This would reduce the requirements for the backend > substantially. The very least you need from it is the acceptable domains (subject (alternative) names) and the fingerprint. Otherwise you won't be able to distinguish them. It would also be quite helpful to get the issuer cert somehow for scenarios that care more about the CA than the cert itself. To make things really workable you'd need to be able to store the cert somehow. In short: I don't think you can reduce the API much without making it useless. > Simplifying the Cipher API > == > > Currently, the QSslCipher API is pretty large. It's not simply the > code in the QSslCipher class itself, but also all the stuff in the > QSslConfiguration that defines the preferences. Instead, we could > offer a simplified API that all backends must offer. So, for example > we could have something as simple as High, Medium and Low! After all, > most people (including developers) don't know the trade-offs of the > different cipher suites anyway. We could also have a flag for perfect > forward secrecy since that is independent of the strength. It would > also be possible to have a setting like FIPS for people who care about > that. I hope you realize that there are several levels of FIPS. And to give you a distincly non-American perspective: there are several levels of German, Japanese, Russian, etc. standards - all with differing requirements and their own sets of ciphers... Do you really want to go there? Create flags for practical features, like: * disabling insecure and obsolete ciphers (RC4, DES, 3DES, IDEA, MD5) * enforcing Forward Secrecy * enforcing newer versions of TLS (some apps may need TLS 1.2, while most web servers still use TLS 1.0) If this is done right the flags could be quite opaque and easy to extend without changing the app. If the backend supports it leave the users the freedom to select their own cipher suites - if they feel the need to do so, they'll have a standard printout lying next to them that tells them which ciphers to chose. If you want to include lists of ciphers required by specific standards, you'll be trapped in a support hell - there are dozens of standards and they constantly change. > Simplifying the Certificate API > === > > Most applications only need minimal information from certificates - in > fact in many cases the only direct usage is to show the certificate to > the user. We could allow applications to do this by proving a method > to show a certificate dialog given a list of QSslCertificates, this > could either be the platform certificate dialog or one provided by the > Qt backend. If we did this then a backend could simply have stubs for > the current accessors (or we could define a minimal subset they should > provide). I like the idea of having a default dialog to show certificates (it was a major pain to come up with one myself). But a minimal subset of cert information is mandatory or you can't interact with them without involving a probably clueless user. (And why should a user have a clue about this arcane stuff in the first place? If a
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
On Wednesday, Wednesday 12 February 2014 at 08:01, Kurt Pattyn wrote: > On 11 Feb 2014, at 19:14, Thiago Macieira wrote: > > Em ter 11 fev 2014, às 16:26:44, Tony Van Eerd escreveu: > >> http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful > > > > No doubt. And we should have a more secure generator, at least until we > > can rely on std::random. > > We can always 'duplicate' some code from the std::random library :-) > How 'secure' should this be? Is a Mersenne-Twister for instance 'secure' > enough? Secure enough for a simple Monte-Carlo style simulation? Yes, definitely, that's what it was designed for. Secure enough for the initial WebSocket implementation in Qt 5.3? Well, not really, but let's go with it (qrand) and fix it in 5.4. Secure enough for cryptography? Hell no! > > Anyone up for creating a nice function for Qt 5.4? Ping me when the reviews are due. I'm very interested in it, but lack time for programming it. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
Hi, On Tuesday, Tuesday 11 February 2014 at 00:03, Kurt Pattyn wrote: > On 10 Feb 2014, at 20:17, Thiago Macieira wrote: > > Em seg 10 fev 2014, às 19:54:18, Kurt Pattyn escreveu: > >> Well, this is what I propose: use a delegate class that handles the > >> creation of a random 32-bit number. This would avoid having to subclass > >> QWebSocket just to overwrite the randomiser. > > > > I don't think we need a class. We just need to make qrand() better. Please don't go there. AFAIK qrand() is a function meant to be equivalent to the ANSI-C rand() function. I.e. it is supposed to be used by simple simulations, be fast and produce reproducable random numbers when seeded with the same value. The requirements for secure random are different: supposed to be used by paranoid functions, be cryptographically secure, "fast" is defined as "just not so slow your key generation takes hours", and ideally never generate reproducable random numbers. It is generally not a good idea to mix those two kinds of random in one function. > I suppose you mean in Qt. I will use the following (fixed) implementation > for QWebSocket, leaving the option open to add virtual methods or > delegates or whatever in a later version (if ever needed). > All in all, by running QWebSocket over SSL, then this potential problem > does not occur. I'm not sure whether I understand you right here. You need to add the "virtual" function in the first release, adding it later would break binary compatibility. > //initialization > #ifdef Q_CC_MINGW > //cannot rely on the entropy method > //clang and gcc always return 0 even though the device is > non-deterministic //Visual Studio always returns 32 > //MingW gcc4.8 always returns 0; it uses rand() instead of the Windows > CryptoAPI //(this is a bug) > //if (randomDevice.entropy() < 0.5) { > std::srand(std::time(0)); > auto seeder = std::rand; > //} > #else > std::random_device randomDevice; > auto seeder = std::ref(randomDevice); > #endif > std::array seed_data; > std::generate_n(seed_data.data(), seed_data.size(), seeder); > std::seed_seq seq(std::begin(seed_data), std::end(seed_data)); > > std::mt19937 randomizer(seq); > > //effective use >quint32 randomNumber = randomizer(); Fair enough. We can improve it later. > I also added the following warning in the documentation: > > \warning To generated masks, this implementation of WebSockets uses a > \l {http://en.wikipedia.org/wiki/Mersenne_twister}{Mersenne Twister > 19937} pseudo random number generator, seeded by a sequence of numbers > generated by a true random number generator. It uses the \l Lose the bit about seeding. With a non-cryptographic RNG a secure seeder is just icing on the cake (it is just easier than compiling 32 bits of entropy yourself). > {http://en.cppreference.com/w/cpp/numeric/random} {std C++11 random number > generation facilities} and more specific \l > {http://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine} > {std::mt19937} and \l > {http://en.cppreference.com/w/cpp/numeric/random/random_device} > {std::random_device}. If a random device is not present or if its entropy > is lower than 0.5, it reverts to the cryptographically weaker \e That should be "cryptographically insecure" - "weak" would imply that it offers at least a bit of resistance against attack. > std::rand() function. For more information about the importance of good > masking, > see \l {http://w2spconf.com/2011/papers/websocket.pdf}. > The best measure against attacks mentioned in the document above, > is to use QWebSocket over a secure connection (\e wss://). > In general, always be careful to have 3rd party script access to > a QWebSocket in your application. I think that should be "careful to NOT have 3rd party script acceess"? > Konrad, for people that are really paranoid, they can use SSL and disallow > third-party scripts. Wouldn’t this be sufficient for now, knowing that we > can always add functionality in a later version (when ever required)? Absolutely correct. Just make sure we don't have to break BC for that improvement (i.e. put all the "virtual"s in place). I actually liked the idea with the QRng class, but I also think it could be improved by using a std::function instead: class WebSocket{ //... typedef std::functionRandomFunction; void setRandomFunction(RandomFunction); }; WebSocket mysock; mysock.setRandomFunction([]{return 4;/*was a fair dice roll*/} Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
Hi, I'll have to read and analyze this code in more detail to give you a qualified opinion. I'll do this later... On the surface it looks a bit complicated and I'm not entirely sure about the seeding, but I'll have to study the API first to make sure. On Sunday, Sunday 09 February 2014 at 22:40, Kurt Pattyn wrote: > If the above implementation suffices, then a virtual method would not be > needed anymore. Please use the virtual method anyway. Yes, it adds about two more instructions and a memory access for every call to this method, but security-wise it is worth it. You can never assume code to be absolutely secure, just secure enough for a particular purpose that you can envision under the constraints of the knowledge you currently possess. Providing an overridable virtual method gives users with stronger requirements (or with more paranoid bosses) sufficient freedom to implement those requirements. Incidentally it gives you an excuse to cop out of security discussions... ;-) > Should I fall back to the ordinary qrand() when the other methods fail? Yes. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
Hi Richard, On Wednesday, Wednesday 29 January 2014 at 21:25, Richard Moore wrote: > Sorry but most of this is irrelevant to Qt. Qt applications and QML > applications are not like Javascript in a browser - they're already > trusted and not sandboxed at all. I know a few Qt applications that match exactly the scenario that masking is supposed to help against, to name just two obvious ones: Konqueror, Snowshoe A few of my own apps, while not browsers, allow user generated scripts (not necessarily JavaScript) and allow the scripts some access to HTTP. Some of those scripts are not fully trusted either - they have severe limits in what they can do. > For Qt, we just need to ensure that > the masking works (ie prevents a non-malicious app accidentally > triggering a buggy proxy). I am not overly concerned with QML and scripts programmed by the same people who did the C++ work. You can't defend against them anyway (except by not using the app). I am concerned with user generated content that has access to HTTP and Websockets in some scripted way. But I would agree that the percentage of Qt applications for whicht this is critical is very low and I would not waste too much effort on this for the initial release. It might even be argued that the effort should be shifted to apps that actually need secure random by implementing a weak virtual function and allowing the user to override it. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
Hi, On Wednesday, Wednesday 29 January 2014 at 11:02, Koehne Kai wrote: > > -Original Message- > > From: development-bounces+kai.koehne=digia@qt-project.org > > [...] > > Later on: when a plan has been found to expose the low-level OpenSSL API > > to Qt this implementation could be changed to use OpenSSL and fall back > > to qrand if it is not available. > > How about just making this plan A? > > Maybe I'm naïve, but that would just require that > - qtwebsockets link against openssl directly (see e.g. > qtbase/src/network/ssl/ssl.pri) The first problem I could see with this: is it binary compatible to later on relax this requirement? Direct linking may also cause problems if QSslSocket for some strange reason then tries to load a different version of OpenSSL later on... After reading myself a bit into the API: I don't think a fast start on this is a particularly great idea. OpenSSL is not thread-safe per default and needs some specific initialization for thread safety. This initialization needs to be done EXACTLY once. In short: we need a unified interface into OpenSSL for Qt before we attempt to do this. > - Use the API described in > http://wiki.openssl.org/index.php/Random_Numbers to generate the random > number. > > I also don't think you even need the 'no-openssl available' use case. While OpenSSL is commonly available on most systems. It may not be available on all embedded platforms and it may not be the expected version. I can see scenarios in which Websockets are needed, but OpenSSL is not available or not desired by the user (e.g. embedded industrial apps that need to access some networked resource with a very strange protocol[tm] while the boss insists that he would run into export restrictions if he allowed OpenSSL). Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
Hi, [Warning: this mail is kind of lengthy] I read the RFC for WebSockets and some of the material describing the attacks that masking is supposed to mitigate. Now that I'm through I'm quite disappointed: it was less funny than I thought. The RFC is just not very good at explaining the security background of seemingly strange specs. I now also understand why masking needs strong random. Sadly. One piece of strangeness remains: I can't for the life of me figure out why the handshake has to use a cryptographic hash algorithm, when a simple header value would have sufficed. On the part of the paper (link below) I guess it is typical of cryptographers to use cryptographic tools to the exclusion of simpler tools, on the part of the RFC authors ... I don't know...? On Monday, Monday 27 January 2014 at 11:12, Konrad Rosenbaum wrote: > On Sunday, Sunday 26 January 2014 at 23:46, Richard Moore wrote: > > The aim of the masking is to prevent request splitting and smuggling > > attacks when going through proxies. It prevents an application from > > being to trick proxies into beginning a new request that does > > something different to the one intended. > > > > https://www.owasp.org/index.php/HTTP_Request_Smuggling > > Thanks for the link, this is an interesting attack on faulty proxies. The original paper on how these attacks relate to websockets: http://w2spconf.com/2011/papers/websocket.pdf Let's formulate a more understandable threat model than was done in the RFC: The masking is supposed to protect explicitly configured and transparent proxies (some of which are badly broken and vulnerable, ie. the normal deployment for many large corporations) from malicious active web content. Specifically against various attempts of cache poisoning (in which the proxy is made to cache the wrong content for a URL) and IP hijacking (in which the proxy briefly redirects a request to the wrong server). In laymans terms: The conclusion of the paper was that if the script or flash/java applet running in the browser is able to control any part of the content that is sent over the wire enough to inject something that looks like an HTTP header (even if it is technically at the wrong position in the stream) then some proxies are idiotic enough to actually interpret these as part of an HTTP exchange, sometimes redirecting the traffic, sometimes just accepting anything at face value. The rest of the company now will get an attack kit delivered instead of their morning news or the browser may be tricked into allowing an attack applet that it should not have allowed (one which comes from the wrong server, but still gets access to the open tab and its content). To be explicit about it: the masking does not (as we assumed) try to protect the data that is being transmitted from eavesdroppers. Instead it tries to protect badly maintained infrastructure (and different users on the same badly maintained network) from malicious scripts run in an usually trusted program. In other words: the WebSocket spec tries to clean up after lazy and idiotic proxy programmers and admins (sorry, I don't have a better term for them). The masking does explicitly not defend against stand-alone applications that the user starts outside the browser. This kind of magic is beyond the mere use of bits... Consequently it does also not defend against malicious browsers. Which are a kind of application after all... Let's translate this into scenarios which are relevant for Websockets in Qt: Someone creates a browser with Qt (it has been rumored to have happened) and uses this Websocket implementation to give scripts access to their servers. Earlier or later some weird script (embedded in some flaky advertisement for unsavory products) decides to poison the local proxie's cache. This can be generalized to: any Qt based application that uses Websockets and allows content from outside the app to control such a socket can be used to mount this attack against a vulnerable proxy. A local user scripting his app may be less likely to screw up his own environment... On second thought: consider local users as good a conductor for malware as copper is for electricity. So: any app that allows networked and/or user generated content to control the websocket can be used as an attack tool against (explicit or transparent) web proxies. Masking is one way of defending against this: it makes it very hard for the malicious script to control what actually goes over the wire. The paper already showed a few mitigation strategies, only one made it into the RFC in a very washed down way (the paper proposed a stream cipher as masking). There are several additional strategies, which should be employed in my not so humble opinion: 1) create a fresh TCP connection for each Websocket, this way it is not possible to combine a previous HTTP reques
Re: [Development] Prettier printing of Unicode strings
On Monday, Monday 27 January 2014 at 09:06, Knoll Lars wrote: > >With my change as it is, you'd see: > >Actual (s1): Thiago Jos\u00E9 Macieira / Lars Knoll > >Expected (s2): Thiago Jose\u0301 Macieira \u2215 L\u0430rs Knoll > > I know that, but we’re usually not writing our auto tests to try and > trick someone. Just saying that for many use cases utf8 output makes the > issue easier to spot. How about an environment variable to turn off > escaping? Neither do I, but as a user of Qt I've inadvertently tricked myself often enough with additional trailing spaces (please highlight those as well!), using production data for tests, complex conversions performed by other system components that I don't control directly, etc. In short: Thiago's change would be a huge boon to my testing efforts. Don't assume a perfect test environment where data is specially crafted to fit the test purpose, where tests are designed from the beginning of the project, and where engineers know what they are doing. Often enough none of those is true in reality. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
On Sunday, Sunday 26 January 2014 at 23:46, Richard Moore wrote: > The aim of the masking is to prevent request splitting and smuggling > attacks when going through proxies. It prevents an application from > being to trick proxies into beginning a new request that does > something different to the one intended. > > https://www.owasp.org/index.php/HTTP_Request_Smuggling Thanks for the link, this is an interesting attack on faulty proxies. Masking does not solve this attack completely. Only for browsers (in which case the "application" cannot control the mask) and scripts that don't have much time to mount their attack. 32 bits is not exactly a big obstacle, even if they consist of good random (however they are a big enough obstacle if the attacker does not control hundreds or thousands of browsers for a long enough time to attack the same target). And there remain enough attack surfaces outside websockets... As far as I can see all request smuggling attacks rely on the attacker being able to inject Content-Length headers to confuse the proxy. I've read only the first 3 chapters of the RFC yet, but as far as I can see a Content-Length header should not be generated at all in a Websocket handshake (if we receive one: ignore the data and complain loudly with qWarning, if we receive more than one: panic and close the TCP connection immediately). Are the following assumptions correct? 1) Websockets in Qt use different TCP connections than normal HTTP connections (QNAM for clients, and whatever is used as a HTTP server equivalent) 2) The Websocket implementation does not allow to manipulate/inject headers during handshake, esp. Content-Length (setting some pre-defined headers, like cookies and Sec-Websocket-Protocol is fine if the values are sanitized - remove newlines!) 3) the client side implementation always uses a fresh TCP connection and the CONNECT method (not GET) when faced with a proxy - even broken proxies should not care about content after CONNECT is successful 4) the first data packets are queued until the handshake is complete and only transmitted after a successful handshake In that case we do not need to worry about "secure masking". If not, we may have to rethink the design and/or strong random (if we also care about corporations using outdated and broken proxies)... Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
Hi, [wow, I had a good laugh!] On Sunday 26 January 2014, Kurt Pattyn wrote: > On 26 Jan 2014, at 11:31, Konrad Rosenbaum wrote: > > Depends. What is it used for? Is it just obfuscation or is it supposed > > to be real security? > > Well, there are 2 places where random numbers are used: > 1. During the handshake phase > Client sends a handshake request containing a 128-bit random number > converted to a string hex representation (Sec-WebSocket-Key). The server > appends a well-known UUID (published in the RFC) to that number and > calculates a SHA-1 hash. This hash in sent to the client, which in its > turn appends the same UUID to the random number it sent before, and > calculates a SHA-1 hash. If both the server-sent hash and the client > calculated hash match, the handshake succeeds. And this is sent in the open? On an unsecured connection? This is the most elaborate scheme of a not-so-secret handshake that I've read so far! The only thing that is more hilarious is the Big Bang Theory scene in which Sheldon lectures his friends on the "secret knock" before Leonard's birthday party... My personal opinion on unencrypted connections: don't sweat it. Use whatever is available. qrand is as secure as the rest of the connection (i.e. not secure at all). Using secure random does not change a thing in this case (only CPU cycles wasted on the client). On encrypted (SSL) connections: if this covers several HTTP(S) requests and not a simple non-interrupted socket then this should better be some secure 128 bits. Although it is beyond me why you would hash them again and again - they could be used as a cookie... [See bottom of my response for some more elaborate argument on this.] > 2. When sending data from client to server (not the other way) > The client generates a 32-bit random number. > This random number is stored in plain text in the header of each frame. > The data is XOR-ed with that 32-bit random number. > > The server takes the 32-bit random number from the header and XORs it > with the payload to get to the original data. > > I really fail to see what the intention is of this mechanism. I really > fail to see what could make this communication ‘secure’. I seem to remember that a certain Julius Caesar had a similarly clever idea for securing his correspondence. Of course Julius had the excuse that advanced math-based cryptography was not available in his time... (https://en.wikipedia.org/wiki/Caesar_cipher) > "The masking key needs to > be unpredictable; thus, the masking key MUST be derived from a strong > source of entropy, and the masking key for a given frame MUST NOT > make it simple for a server/proxy to predict the masking key for a > subsequent frame. The unpredictability of the masking key is > essential to prevent authors of malicious applications from selecting > the bytes that appear on the wire.” My above statement about the handshake was wrong. Enormously so. This statement tops all the comedy in in my sizable DVD collection! > Why should the masking key be unpredictable if it is send unencrypted > along with the masked data? Why would a server/proxy predict the masking > key if it can just fetch it from the header? To me it looks like having > a locked door with the key in the keyhole. Why would a burglar use a > crowbar if he has the key? Exactly. This toy-cipher and its description is equivalent to triple-ROT13 (triple for more "security"...) #-( > > If the latter: is it the only way to generate security? (If so: in all > > likelyhood you are affixed by an inclined plane wrapped helicly around > > an axis. In laymans terms: screwed.) > > > > If the former: unless it is absolutely necessary for understanding the > > other side of the communication channel - don't bother implementing > > it. Obscurity is no security. > > Well, the standard requires the frames that go from client to server to > be masked. So yes, it is absolutely necessary, but in my opinion > complete overkill. I agree with you. The only thing this defends against is absolutely clueless IT people (pointy haired boss types) who have read access to network logs, but whose 8 year old kids refuse to help with a simple script. Use any source of (weak) random (e.g. qrand) and ignore this bullshit about "strong source of entropy". If anyone asks you why you are using insecure random: a) on unsecured connections it is pointless to get secure random and then transmit it in the open together with the data. Revealing secure random to the open makes it magically insecure. You might as well not try to conceal the data at all. b) on secured (SSL) connections it is pointless to implement a toy encryption when SSL is already doing an adequate job of doing real encr
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
On Sunday 26 January 2014, Kurt Pattyn wrote: > On 17 Jan 2014, at 19:46, Frederik Gladhorn wrote: > > Just another remark which I'm not sure about: > > In section 5.2 of rfc 6455 randomness is mentioned. I didn't read up on > > the background but currently there is only a call to initialize qsrand > > with > > > > QDateTime::currentMSecsSinceEpoch() which is probably not quite according to: > > The masking key needs to > > be unpredictable; thus, the masking key MUST be derived from a strong > > source of entropy, and the masking key for a given frame MUST NOT > > make it simple for a server/proxy to predict the masking key for a > > subsequent frame. The unpredictability of the masking key is > > essential to prevent authors of malicious applications from selecting > > the bytes that appear on the wire. > > Date and time are quite predictable :-) > Creating random numbers with a high entropy is quite expensive (if not > cached beforehand). This can be problematic, as a new mask has to be > calculated for every frame. > > What I do find strange though, is that the masking key is sent along > unencrypted with the frame header and is thus readable by everyone (if > not sent over secure websockets). The messages can thus be perfectly > decoded, and as the server is not checking for the source, a malicious > application can invent his own masking keys or intercept the message and > repackage it (the server just takes whatever masking key that is in the > header). I honestly don’t see how this mechanism can protect against > malicious applications. > > So, I wonder if it is worth the effort. Depends. What is it used for? Is it just obfuscation or is it supposed to be real security? If the latter: is it the only way to generate security? (If so: in all likelyhood you are affixed by an inclined plane wrapped helicly around an axis. In laymans terms: screwed.) If the former: unless it is absolutely necessary for understanding the other side of the communication channel - don't bother implementing it. Obscurity is no security. > > I'd like others with more experience in this area to chime in though. Getting milliseconds since Epoch gives you less than one bit of random (entropy), if and only if nobody can predict precisely when you'll call for the current time. Calling it several times does not increase entropy unless there are sufficiently random intervals between calls and nobody can observe you calling (i.e. you are working on a perfectly secured system). Micro- and Nano-Seconds are slightly more random, but not much (fractions of bits). You need about 128 bits of entropy for good security. After you've got that you can stretch those with a secure random number generator. The q(s)rand functions can be safely assumed to be completely insecure on most operating systems and inadequate on all the others. Don't use them for security. I would not recommend trying to implement your own PRNG either - getting it right is horribly difficult. Getting the entropy gathering right in a cross- platform way is much worse effort... I wonder whether it would be possible to expose the low-level APIs of OpenSSL to Qt, it has quite a good random number generator and it is used for QSslSocket already. Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM
On Friday 27 December 2013, Mandeep Sandhu wrote: > Got it. If there's some content in the 'body' part of the response and > it points to the same server which sent a redirect, then we could > reuse the existing connection. > > Though it might be a rare case where the redirects will have a 'body' > associated with it. I've mostly seen redirects used by URL shortening > services and CDNs where there's no body in the redirect resp. CMIIW. Maybe rare for URL shorteners. Internal redirects inside a web site or group of sites are a different matter: call me an old-grumpy-Mosaic-user if you like, but I usually add a body of the "if you are not redirected automatically click here" -type when I program redirects, I usually even include a meta tag - you never know how stupid the configuration on the server is where your script runs. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML, Widgets, and setParent
On Tuesday 05 November 2013 06:48:11 Alan Alpert wrote: > I'm surprised this works. There's implicit QObject parenting built > into the language, for example: > QtObject { > id: foo > property Widget bar: Widget{} > } > > Will automatically make foo the qobject parent of bar. Correct, this example aborts. But not where you expect: it is caught in the DeclarativeWidgets lib itself. $ ./declarativewidgets test.qml Root Element is neither an AbstractDeclarativeObject nor a widget Aborted > I'm not certain, but I think this happens before it gets assigned to > the property which might make any declarative widgets example using > layouts crash in debug builds... There is a lot of code handling layouts specially. If I reformat your example thusly: import QtWidgets 1.0 Widget { HBoxLayout { id: foo property Widget bar: Label{ text: "hello" } Label { text: "world" } } } The "world" label shows up, while the "hello" widget is ignored by the layout (the outer Widget is necessary because layouts cannot be shown on their own). Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [Increasingly OT] Re: Qt 4.8.6 Release Plans
Hi, IANAL, or: this is the increasingly hypothetical mail thread in which two blind men discuss whether black or red robes look better on judges. :-) On Monday 04 November 2013 16:52:36 Oswald Buddenhagen wrote: > well, he can sue us. > and then we sue his arse off for frivolous complaining, and he'll pay > the bills. Well, this hypothetical he would pay the bills ten years later after costing millions of dollars (euros, pounds, take your pick). That is if any money is left, he'd pay it. Theoretically. I'm reminded of SCO, whenever I hear righteous arguments like these... they held up three courts and half a dozen companies for ten years, not a dime left for restitution. > you don't need to be afraid of such stuff if you have the financial > backing. You mean, if you are Google, Novell, or IBM. Right? > also, no sane judge would issue an injunction because of a three-liner, > so the risk of noteworthy disruption is practically zero. Enter Oracle vs. Android: if memory serves correctly, the final discussion was about nine lines of code among several million lines. Google was lucky: the judge had learned how to code before he decided on judgement and came to the conclusion that he could write those 9 lines himself without special training. And I think he was quite upset that a few thousand times as many lines of legal documents were produced to prove that, while he had more important cases pending (serious crime). > also, these considerations are completely hypothetical anyway. In a way: correct, he'll probably be a nice guy. In another way: law is a matter of principle. Unfortunately the principle is not clear to the layman most of the time. Worth a read: http://qt-project.org/legal.html#practices > we are > talking about some oss guy who'd most probably be quite happy to see his > patches taken in (how about asking?), Absofragginlutely correct! How about asking him to submit it to Gerrit? Once it is there (even if it is on the wrong branch): he has signed the Contributors Agreement and put the patch under it. Now you can change the patch to your heart's content. > and even for bigger stuff we could > just do that if the license was ok (on the site it seems to be CC-BY 2.5 > by default - i have no clue whether that would be ok). most of the > patches appear to be cherry-picks anyway. I'm not sure whether any CC license is compatible enough. You'd have to ask a lawyer. (Ooops.) Even though the license of the text on a site says absolutely nothing about the code hosted on that side. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.6 Release Plans
On Monday 04 November 2013 11:46:35 Oswald Buddenhagen wrote: > On Sun, Nov 03, 2013 at 06:49:17AM -0800, Thiago Macieira wrote: > > We can't even click the link. If we read their patches, we can't write > > the same later. > > that's nonsense. any simple patch is not subject to copyright (though > it's still good tone to credit the investigator). and anything complex > enough is likely to produce a slightly different patch anyway, even > after seeing the other patch. that's what copyright is about in the > first place: protecting *creative* works. I hate to be so negative, but... Oswald what you are describing is the spirit of copyright. How it is supposed to work. What Thiago is describing is how it works (or often doesn't) in reality. As soon as you see a copyright lawyer in the room: run like hell! It won't help, but it gives you a nice fuzzy feeling of being ahead one step... ;-) (IANAL) Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML, Widgets, and setParent
On Saturday 02 November 2013, Kevin Krammer wrote: > The Qt4 code does not call setParent if the object is a widget and the > parent is not, e.g. if the parent is a layout. Still seems to work quite > well. > > Maybe it would still work if the Qt5 code did something like this: > > if (!o->isWidgetType) > QQml_setParent_noEvent(o, parent); wow! You are absolutely correct. It works now. > > The code of QObject::setParent itself is absolutely identical (I didn't > > check all the lines of QObjectPrivate::setParent_helper though). Qt4 > > contains the same Q_ASSERT. > > Sure, what I was saying is that maybe it "works for me" because I am > using a release built Qt4. Q_ASSERT is not part of release build object > code. No, I'm using a debug build of Qt4 and it works with that too. The idea above was the one that hit it. I basically restored Qt4 behavior to Qt5, but with a plugin to avoid the QtWidgets dependency. > The thing is that the widgets wouldn't have non-Widget parents, at least > not in DeclarativeWidgets. The parent is either a widget or, most of the > times, a layout. The layouts' addWidget methods reparent to their parent > widget. > > Therefore one option might be to just not call set parent on widget > objects and let the list property code deal with reparenting. Yepp. That's it. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML, Widgets, and setParent
Hi, On Saturday 02 November 2013, Kevin Krammer wrote: > On Thursday, 2013-10-31, 20:17:43, Konrad Rosenbaum wrote: > > I've got it running > > for trivial QML files, however as soon as there are child widgets the > > running program aborts. > > > > The abort is caused by QObject::setParent, which contains this little > > gem: Q_ASSERT(!d->isWidget); > > Hmm. The same code is in Qt4. I think it "works for me/us" because we are > building against our distribution's Qt packages which are release builds > and thus doesn't have the Q_ASSERT. No, it works for you because the Qt4 QML code (qqmlvme.cpp) contains special code to handle Widgets - in Qt5 it was deactivated to remove the dependency on the QtWidget module. The code of QObject::setParent itself is absolutely identical (I didn't check all the lines of QObjectPrivate::setParent_helper though). Qt4 contains the same Q_ASSERT. > > I kind of ran out of ideas on how to solve this. Should I consider > > setParent, qqmlvme or the direct use of QWidgets as a bug? > > I agree with Alan on setParent() being in error, the problem is some > other areas rely on that. E.g. QWidget::parentWidget() does a > static_cast of parent() to QWidget* Upon reading the code of QWidget a bit more I must conclude that this was done deliberately (both in Qt4 and Qt5). If widgets are supposed to be able to have non-widget parents, then this is one hell of a design bug that can't be easily fixed inside a single minor release. I'm coming to the conclusion that I have only three options: 1) give up - I must say, I don't like this one ;-) 2) do a work-around by giving all widget classes a QObject based wrapper in the framework: on the plus side this would need no changes to Qt, on the down side this would make it slower and use up significantly more memory 3) fix qqmlvme.cpp somehow: the trickiest one, since reintroducing a dependency on QtWidgets is not an option; the solution would probably involve a plugin that is loaded if/when a widget is encountered there Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QML, Widgets, and setParent
Hi, I'm trying to port KDAB's DeclarativeWidgets[1] to Qt5. I've got it running for trivial QML files, however as soon as there are child widgets the running program aborts. The abort is caused by QObject::setParent, which contains this little gem: Q_ASSERT(!d->isWidget); Apart from not understanding why there is a significant difference between QObjects and QWidgets in regards to parenting... There used to be code that handled this in qqmlvme.cpp[2], but it has been disabled by an #if 0 . Apparently to remove dependencies on QtWidgets from QtQml. I kind of ran out of ideas on how to solve this. Should I consider setParent, qqmlvme or the direct use of QWidgets as a bug? Konrad [1] It enables you to create widget based GUIs using QML. git://github.com/KDAB/DeclarativeWidgets [2] In 5.2 beta this is line 627 in qqmlvme.cpp. It's Halloween. Go ahead, look at scary code! ;-) signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Higher-Level Docs, possibly Qt-related (was: Re: Qt 4.8.6 Release Plans)
Hi, On Wednesday 30 October 2013 14:36:23 Charley Bay wrote: > This is an outstanding (and thorough/exhaustive/detailed) post on this > topic. Thanks! I was aiming for thorogh... > Where can we put this in the Qt Docs or "Guidance-Help" for future users, > and future Qt-internals-implementors? (I'd really like this > "saved-for-posterity" so as to refer back to it in the future, and it seems > like these are "guiding principles" to which the Qt internals should be > able to "refer" in future discussions to justify design/behavior.) I know of no part of the docu that would be specifically suited to such auxiliary topics. But I could be wrong here. > I think any of those would be fun-books-to-write, and I'm sure there are a > number of people on this list highly qualified to do so. IMHO, most of the > development shops really need to read those books, whether-or-not they use > Qt (a shame these books don't exist at present.) How about reviving "Qt Quarterly"? I would be willing to donate a few articles to it, if others are willing to keep it running. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.6 Release Plans
Hi, On Wednesday 30 October 2013 00:58:05 Calogero Mauceri wrote: > The Qt documentation states that QDir::currentPath() returns "The > application working directory". Shouldn't the workind directory be > initialized with the path the application was launched from? If that's > not the case, which is the right way to obtain the working directory? > (not the executable path as the QApplication::applicationDirPath() is > returning) The current working directory is the directory the application is currently working in (I know, it sounds like a tautology). Or in other words: if you open a file with a relative path name, the current working dir is the one in which your program looks for the file: QFile file("myfile"); file.open(QIODevice::ReadOnly); is equivalent to: QFile file(QDir::current()+"/myfile"); file.open(QIODevice::ReadOnly); You can change it with QDir::setCurrent or the underlying OS function chdir. At application startup the current working directory is the exact same directory that the parent was in when it spawned your process (this is somewhat simplified). This is the same behavior over all desktop OSes. The parent application is free to chose: it can simply refuse to care (result: your CWD is more or less random from your programs perspective; this is why an app started from a KDE desktop is almost always in $HOME, but sometimes somewhere else); it can assume you are a command line tool and want to work in the same place the shell is in (that's what happens if you start anything from a shell); it can try to be "helpful" and switch to the directory the binary is in (apparently what Mac used to do); or it can try to make things consistent by switching to the root directory (apparently what 10.9 does). In short: relying on the CWD at startup is misguided for most GUI apps. If you need to be in a specific directory: use some other mechanism to find it and then switch there, do not rely on being placed there by magic. Places you may want to be: * somewhere relative to your binary: use QApplication::applicationDirPath() - I do this in apps that have complex trees of files with data needed at runtime, apps that work in their own little "universe" * in the users home directory: QDir::setCurrent(QDir::homePath()) - desktop apps that interact with user files * in the exact same place you were started from: don't move - this is true for most command line tools (like qmake, moc, ...) * in the root directory - true for most server processes (daemons, middleware, ...) * in the temp dir: use QDir::setCurrent(QDir::tempPath()) - e.g. simulations that create some throw-away data only * in some dir that was configured by the user: read the config then switch - true for other server-like processes (e.g. automation software, ...) The tricky question we're trying to coax out of you: does QDir.current() really return an empty string "" or the root directory "/"? The former may indicate a bug on Apple's part, the latter is a perfectly valid place to be in. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Policy: supplying the preferred format for modifications for everything we ship
On Sunday 29 September 2013 22:26:41 Olivier Goffart wrote: > As we do not modify those files, but take them from upstream, having a > README that say where the file are from is enough. > I don't see why it should be part of the tarball. (and especially they > should not be in the git repositories) The "problem" is that (L)GPL requires to offer the _exact_ _same_ sources that were used to build the binary (or intermediate source). Just pointing to a URL usually gives the user access to the _current_ upstream sources - speaking as a user: it is no fun trying to compile (legacy) stuff for hours only to find out that one of the first support libraries was an incompatible version and not the one I needed. In short: providing the tarballs of the _exact_ upstream sources that were used along the Qt tarballs is the easiest way of ensuring we fulfill our obligations under (L)GPL and making sure users have what they need. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QValidator in QtCore
Hi, On Monday 23 September 2013 09:45:51 Olivier Goffart wrote: > On Sunday 22 September 2013 16:25:25 Thiago Macieira wrote: > > Right now, we allow them and I don't like the idea of forbidding forward > > declarations. > > > > Therefore, doing anything that breaks them is source-incompatible and > > should not be permitted until Qt 6. > > Yes, but as stated, using macro as it was done for QXmlStreamWriter does > not break source or binary compatibility. Hence it is possible to move a > class from one module to a lower module. I beg to differ! --snip: header-- class QXmlStreamWriter; class MyClass { public: MyClass(); //...etc. private: QXmlStreamWriter*m_output; }; --snap: source-- #include MyClass::MyClass() :m_output(new QXmlStreamWriter) {} --the end-- Before the change: the code worked as expected. After the change: it does not compile because the forward-declaration declares a different class than what should have been used and the compiler fails with incompatible pointers. I do this all the time to speed up my compiler. (You start to notice the compiler once you have more than just a couple of C++ files and you are limited to a small share of an already underperforming machine.) In other words: broken source compatibility. Period. Whenever that happens a certain Teutonic programmer forgets that little invention called "civilization", grabs his battle hammer and screams bloody murder... ;-) Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RPATH in libraries
Hi, On Tuesday 06 August 2013 17:10:31 Thiago Macieira wrote: > On terça-feira, 6 de agosto de 2013 15:41:21, Konrad Rosenbaum wrote: > > On Sunday 04 August 2013 18:51:10 Thiago Macieira wrote: > > > On domingo, 4 de agosto de 2013 10:20:51, Dmitry Ashkadov wrote: > > > > LDD finds library using RPATH first of all, so, for local installed > > > > Qt5 > > > > > > That's why RPATH was deprecated and replaced with RUNPATH. > > > > Stupid question: is there a reason the default Makefile generated by > > qmake does not include this: > > QMAKE_LFLAGS += -Wl,--enable-new-dtags Ok, I found the answer to my own question: DT_RUNPATH is radically different from DT_RPATH - if it was only evaluated after $LD_LIBRARY_PATH it would not be a problem, but it also does not apply to libraries loaded by the libraries I found in this RUNPATH. So if I open a plugin that does not have RUNPATH set, but requires Qt it will attempt to load Qt not from my RUNPATH, but from the system directories. This will likely crash my application. See: http://blog.qt.digia.com/blog/2011/10/28/rpath-and-runpath/ > Yes. It's not our job to do that. We should assume a decent linker from the > system. After reading through lots of mostly half-complete documentation I find that I define "decent" differently from what I thought a few hours ago. > The question is: why does your system linker not enable the new dtags from > 10-15 years ago? That would be a question for the Debian maintainers. Or probably the binutils maintainers (Debian seems to tend to stay with upstream in this case, I didn't check very thoroughly though). Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RPATH in libraries
On Sunday 04 August 2013 18:51:10 Thiago Macieira wrote: > On domingo, 4 de agosto de 2013 10:20:51, Dmitry Ashkadov wrote: > > LDD finds library using RPATH first of all, so, for local installed Qt5 > > That's why RPATH was deprecated and replaced with RUNPATH. Stupid question: is there a reason the default Makefile generated by qmake does not include this: QMAKE_LFLAGS += -Wl,--enable-new-dtags This would generate DT_RPATH as well as an identical DT_RUNPATH, which would lead to more useful binaries on modern (as in: less than 10 years old) ELF systems, because RUNPATH behavior takes precedence over RPATH if the system understands it (according to man ld). Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Taking the new download system into production
On Thursday 11 April 2013 13:02:07 Turunen Tuukka wrote: > PS. Torrents are still under study. Most likely they can be quite easily > enabled, we'll see in the near future. Personally I am non convinced of > their benefits, but maybe that is just me ;) The benefits of torrents are not visible if you have a fast and reliable internet connection and the CDN has a node close to you. Torrents are better if you have a flaky connection, you are far from the main site/CDN, or you have to break your connection frequently for some reason (e.g. running to the next meeting). My guess would be that you won't see an appreciable drop in traffic, but torrents would help users with bad or slow connections. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal - QtSerialPort graduation from the Playground
On Saturday 26 January 2013, Laszlo Papp wrote: > On Fri, Jan 25, 2013 at 9:05 PM, Knoll Lars wrote: > > And a question: There's no auto tests. I know that testing serial > > ports > > can't really be done in an automated fashion, but is there anything we > > can do to cover the module? > * The CI machines could be using a loopback cable, and test it that way. > It would be even better to use a pandaboard or raspberry pi (with > gserial in that case). The board could be used for receiving and sending > data back for instance, but this requires a special hardware setup. > > Perhaps, there are other alternatives to address this, but these have > just come to my mind for the moment. Actually it is rather easy - unfortunately the recipes are very different for different platforms. Linux: all terminals behave essentially like serial ports. You simply need a small program that allocates two PTYs, connects them in a virtual loop and exposes the two corresponding TTYs to the test case. You cannot test speed directly (PTYs ignore their speed parameter), but you can ask the port for what speed it has set. I'm not sure about the non-data lines in serial ports, since I have never used them. Windows: there are several projects on Sourceforge that emulate serial interfaces. I've used com0com to simulate loops. I have never done serial work on Mac, but I'd guess it is similar to Linux, being a kind of mock-Unix. ;-) The CI machines would simply have to have these virtual loops installed and they'd need some kind of configuration that shows which ports to use (Linux /dev/pts/*, Windows: COM?). Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replacing Cleanlooks and Plastique
Hi, On Monday 15 October 2012 15:56:23 Bache-Wiig Jens wrote: > The main focus of Qt on the desktop is to provide a native look and feel on > all platforms. Until now, Qt has come bundled with a few extra styles that > were not used intentionally anywhere. Historically plastique was designed > to blend with KDE 3.0 and cleanlooks in early Gnome environments. They > have long since been replaced by Oxygen and GTK+ styles on these platforms > but have been left in our repository for historical and compatibility > reasons. We certainly don't need multiple non-native looks and feels > included in every build of Qt so I think we should clean it up a bit now > that we have the opportunity. Those are not obsolete. They still ship with KDE 4, it just uses Oxygen by default. So I wouldn't call then "non-native", just "less common". Call me a hopeless case, but the first thing I do on a fresh KDE is changing the style to one of those two because I find them more visually aiding than Oxygen (they have better contrast and are less "flashy"). > There are still a few use cases where including a non-native theme is > useful. This can be on platforms that don't have a desktop environment or > if an application wants to customise the colours of certain widgets. Changing color is not the only reason to change the style. There are other subtle differences - e.g. Cleanlooks displays labels on menu separators and looks almost completely native on Windows (I use it for exactly those reasons in one of my applications). If I just wanted to change colors, I'd use a style sheet. > I expect it to have some more visual tweaks, but unless there are loud > protests, I would like to have this change in before the next beta. Does this count as loud protest? Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods
On Friday 03 August 2012 15:42:49 marius.storm-ol...@nokia.com wrote: > On 03/08/2012 07:49, ext Thiago Macieira wrote: > > And operator== can't change incompatibly. > > Does this mean that we should have an > bool QDateTime::isIdentical(const QDateTime &dt) > function too (effectively an operator===), allowing you to easily check > if two dates refer to the same time in the same TZ? It might be a good idea. But don't rush it - there is time for this in Qt5.1. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods
On Thursday 02 August 2012 23:01:55 you wrote: > On Thursday August 2 2012, Konrad Rosenbaum wrote: > > On Thursday 02 August 2012, Thiago Macieira wrote: > > > On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote: > > > > Where is qHash(QDateTime) defined? It doesn't seem to be where I > > > > expected it (qhash.* or qdatetime.*). > > > > > > qdatetime.{h,cpp} > > > > Ok, found it - had the wrong branch checked out for some odd reason. This > > has a high likelyhood of causing allocations if time zones, calenders or > > anything fancy is active: it causes time zone calculations, which > > potentially cause allocations. > > That begs the question whether this is what should happen for a _hash_, > which is supposed to be _fast_ :) All three (QDate, QTime, QDateTime) take the somewhat obvious route of converting to a linear measure of time (julian day, msecs since midnight, msecs since epoch) that is then fed to qHash(qint64 time,int seed). For QTime and QDate this is uncritical - these are the native storage format, although a few methods would have to be marked noexcept as well. For QDateTime this potentially involves heavy calculations. The upside of this is that this guarantees unchanged hashes even if the internal representation of QDateTime changes. How hard is the requirement to create the same hash over several versions of Qt? Alternative 1: the hash for QDateTime could be calculated from other internal details: the hashes of the QDate and QTime objects making up the QDateTime plus TimeSpec, UTC-offset, and later on a reference to the time zone. If we do this it means the generated hashes will change in Qt 5.1! Alternative 2: the hash for QDateTime is calculated solely from the hashes of QDate and QTime. Upside: they do not change, they are easy and fast to calculate, we already know the sources are noexcept. Trade: we trade equivalence of the exact same time relative to Epoch across time zones (currently the hash of "2012-08-03 9:54:00 +200" equals the hash of "2012-08-03 7:54:00 UTC") for equivalence of the exact same numeric time over time zones (hash of "2012-08-03 9:54:00 +200" equals the hash of "2012-08-03 9:54:00 UTC") - I view both as equivalent for the most common case of using local time only. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods
On Thursday 02 August 2012, Thiago Macieira wrote: > On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote: > > Where is qHash(QDateTime) defined? It doesn't seem to be where I > > expected it (qhash.* or qdatetime.*). > > qdatetime.{h,cpp} Ok, found it - had the wrong branch checked out for some odd reason. This has a high likelyhood of causing allocations if time zones, calenders or anything fancy is active: it causes time zone calculations, which potentially cause allocations. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods
Hi, On Thursday 02 August 2012 15:27:03 Thiago Macieira wrote: > For example, in when I was just now adding it to qHash for QDateTime, I > realised it does complex operations. Right now, none of those operations > allocate memory, but it's actually very close to doing that. QDateTime has > a d pointer and the hash function does some manipulation of the data. If I > add it now, it means it cannot allocate memory, ever, in Qt 5. For that > reason, I'm not sure I can do it: what if the implementation for QDateTime > when timezones are taken into account needs to new? Where is qHash(QDateTime) defined? It doesn't seem to be where I expected it (qhash.* or qdatetime.*). Anyway, Timezones can do rather complex calculations that may require memory- allocations, but only when the QDateTime actually does calculations: * add or subtract some time to/from the QDateTime (addSecs, addMSecs) * convert to a different time zone (toUtc, toLocalTime, toTimeZone(x)) * convert to or from time_t Any of those operations needs a search of the time zone for the offset valid at the time to be converted, if we are lucky the offset is already in memory, if not we need to retrieve it from a file, or worse to calculate it from a POSIX-style rule (and then cache it for later). When converting to another zone things get worse. Depending on the implementation that will end up in Qt the actual lookup for which time zone is being used may have side effects too. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTimeScheme for Qt - 5.0 or 5.1?
On Wednesday 15 February 2012, Stephen Kelly wrote: > On Wednesday, February 15, 2012 21:55:54 Konrad Rosenbaum wrote: > > The > > > > calculation results are almost identical. Almost. > > Is that enough? > > John Layt mentioned the existence of such a mapping too. It depends on how you define "enough". Both systems yield the same time for the richer countries (US, central Europe, Japan) as long as you stay within the limits of the last 30 years or so. Beyond that Olson tends to have more accurate data on time shifts. This means that the time returned by Windows and Olson DB can differ by one or two hours for dates further in the past and for some countries that are "less important" for Microsoft. I'd actually recommend three engines: a) the default engine is basically what we have in Qt4 - it just knows "local" and "UTC" - its backend uses the system functions b) OlsonDB would be the first advanced engine c) Windows could come later to have one that is identical to the default engine for the local zone on Windows > > *it is not always clear which time spec is standard and which one is > > DST > > I'm not certain what you mean. The definition of time zones is unfortunately up to politicians, so it does get fuzzy around the edges: while most countries either do not observe DST or have standard time in (local) summer and DST in winter, there are countries that have standard time in (local) winter and some kind of Anti- DST in summer. At times countries do not switch off the time spec they happen to be on for several years (e.g. during World War II several countries remained on DST and called it War Time). Over the years I found out that if you really want to confuse yourself, just try to find the specifics of any aspect of how mankind measures time. The scale does not matter - the confusion is fractal. ;-) Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTimeScheme for Qt - 5.0 or 5.1?
Hi, On Wednesday 01 February 2012 01:59:49 Stephen Kelly wrote: > On Tuesday, January 31, 2012 22:50:51 you wrote: > > * I'd prefer if we don't have to ship the database. As noted it can > > change easily > > and a compiled in database would get out of sync. Look for the system database - on systems that are based on Olson DB it's always on very few specific locations. For the others ship a backup resource file or plugin. > > * ICU has timezone support as well. Something that could simplify our > > life? > > Wouldn't that be out of sync too? What is the ICU timezone support? ICU ships a copy of the Olson DB. > > * Do we need to support both the Windows and Unix format, or could we get > > away with Unix only in a first version (if e.g. ICU provides the data)? > > I think this is 5.x material anyway. I think it would need somewhat more > involved discussion. Windows names can be mapped to Olson names - there are lists on the web. The calculation results are almost identical. Almost. A parser for Olson DB files is not overly complex to write - I did that within a weekend. git://silmor.de/konrad/tzone.git I haven't completely checked Stephen's interface, but I had the distinct feeling that it underestimates the complexity of time zones: *the definition of standard time and/or DST can change for any time zone at any time *there can be 1 or up to 3 different time specs in a year (under exceptional circumstances even more) *it is not always clear which time spec is standard and which one is DST Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development