Re: [Development] Buddy group to help new contributors

[Konrad Rosenbaum]

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)?

[Konrad Rosenbaum]

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)?

[Konrad Rosenbaum]

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)?

[Konrad Rosenbaum]

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?

[Konrad Rosenbaum]

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?

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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 

Re: [Development] QtCS2019 Notes: QtCore

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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)

[Konrad Rosenbaum]

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)

[Konrad Rosenbaum]

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)

[Konrad Rosenbaum]

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)

[Konrad Rosenbaum]

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)

[Konrad Rosenbaum]

[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 thyz, 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

[Konrad Rosenbaum]

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] syncqt.pl in C++

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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?

[Konrad Rosenbaum]

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?

[Konrad Rosenbaum]

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] Avoid overloading of 'error'

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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 any of my users - except for admins - is 

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Konrad Rosenbaum]

On Wednesday, Wednesday 12 February 2014 at 08:01, Kurt Pattyn wrote:
 On 11 Feb 2014, at 19:14, Thiago Macieira thiago.macie...@intel.com 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...)

[Konrad Rosenbaum]

Hi,

On Tuesday, Tuesday 11 February 2014 at 00:03, Kurt Pattyn wrote:
 On 10 Feb 2014, at 20:17, Thiago Macieira thiago.macie...@intel.com 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::arrayint, std::mt19937::state_size 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 virtuals 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::functionquint32()RandomFunction;
 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...)

[Konrad Rosenbaum]

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...)

[Konrad Rosenbaum]

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...)

[Konrad Rosenbaum]

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 request and a socket in an attack; 
consequently: if the handshake fails: terminate the TCP connection!

2) when

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Konrad Rosenbaum]

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...)

[Konrad Rosenbaum]

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] Prettier printing of Unicode strings

[Konrad Rosenbaum]

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...)

[Konrad Rosenbaum]

On Sunday 26 January 2014, Kurt Pattyn wrote:
 On 17 Jan 2014, at 19:46, Frederik Gladhorn frederik.gladh...@digia.com 
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] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Konrad Rosenbaum]

Hi,

[wow, I had a good laugh!]


On Sunday 26 January 2014, Kurt Pattyn wrote:
 On 26 Jan 2014, at 11:31, Konrad Rosenbaum kon...@silmor.de 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 
encryption designed by real cryptographers. 

c) Or the social argument: anyone clever enough to crack an SSL secured 
connection might fall off their chair laughing hard when after spending days 
or decades cracking the SSL-shell-of-encryption and they see secure random

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

Re: [Development] Qt 4.8.6 Release Plans

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

Re: [Development] QML, Widgets, and setParent

[Konrad Rosenbaum]

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

[Development] QML, Widgets, and setParent

[Konrad Rosenbaum]

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] Qt 4.8.6 Release Plans

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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 QXmlStreamWriter

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] Taking the new download system into production

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

On Saturday 26 January 2013, Laszlo Papp wrote:
 On Fri, Jan 25, 2013 at 9:05 PM, Knoll Lars lars.kn...@digia.com 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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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

[Konrad Rosenbaum]

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] Proposal: adding Q_DECL_NOEXCEPT to many methods

[Konrad Rosenbaum]

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] QTimeScheme for Qt - 5.0 or 5.1?

[Konrad Rosenbaum]

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