diff options
author | Norwegian Rock Cat <qt-info@nokia.com> | 2009-03-30 13:26:05 (GMT) |
---|---|---|
committer | Norwegian Rock Cat <qt-info@nokia.com> | 2009-03-30 13:26:05 (GMT) |
commit | 93a69b9cec71ca7e0140f83aeb4e31537eb9753e (patch) | |
tree | a50db5bbaca6d4fe1833602a3cab921170fbd5e0 /src/gui/kernel/qeventdispatcher_qws_p.h | |
parent | 13d2c268b732ce07c249f341a6e1b9e1ff63e71d (diff) | |
download | Qt-93a69b9cec71ca7e0140f83aeb4e31537eb9753e.zip Qt-93a69b9cec71ca7e0140f83aeb4e31537eb9753e.tar.gz Qt-93a69b9cec71ca7e0140f83aeb4e31537eb9753e.tar.bz2 |
Don't send QFileOpenEvents for items on the command-line
Cocoa actually has a nice feature that if you pass arguments on the
command-line, Cocoa will pass those along as Open events later. This is
probably how we should have handled things inside of Qt as it would have
unified the file opening code. Unfortunately, we can't turn back time on
this, so we need to prevent it because people probably aren't expecting
it (i.e., they expect to do the parsing themselves, and not to get
events later). This also means that we can send the event immediately
instead of posting it, because the race that we had before no longer
exists. We only do this check during launch time because that's the only
time we may get bitten by it (people usually only parse the arguments
once).
Someday, people may actually WANT this functionality though. When that
comes along, we should make it an application attribute.
Task-number: 249553
Reviewed-by: Richard Moe Gustavsen
Diffstat (limited to 'src/gui/kernel/qeventdispatcher_qws_p.h')
0 files changed, 0 insertions, 0 deletions