Remove unimplemented NOTIFY signals. Furthermore the signals must
be declared in the same class as the Q_PROPERTY (not in a base class):
Fix this in filefilteritems.h.
There is a hard limit on the number of file handles that can be open at one point per process on Mac OS X (e.g. it's 2560 on Mac OS X Snow Leopard Server, as shown by ulimit -a). Opening one or several .qmlproject's with a large number of directories to watch easily exceeds this. The results are crashes later on, e.g. when threads cannot be created any more.
This patch implements a heuristic that the file system watcher used for .qmlproject files never uses more than half the number of available file handles. It also increases the number from rlim_cur to rlim_max - the old code in main.cpp failed, see last section in
http://developer.apple.com/maac/library/documentation/Darwin/Reference/ManPages/man2/setrlimit.2.html
for details.
Reviewed-by: ckamm
Task-number: QTCREATORBUG-1487
Task-number: QTCREATORBUG-1486
When adding a new file, refreshing semantic errors in the open editor should
have worked. It now also works for removing existing files.
Done-with: Christian Kamm
Only watch directories, and not single files. Also, share one
FileSystemWatcher between projects & FileFilter items.
This fixes the issue that the process runs out of file handles e.g.
when loading a .qmlproject file containing all of qt examples & demos.
Basic implementation of FileSystemWatcher was copied from
ProjectExplorer::FileWatcher - however the FileWatcher is only
for files (and not directories), and also monitors the last
change date etc.
Instead of letting the list of files being a (comma separated) string
it's now a full JavaScript array. E.g.
paths: ["file1", "file2"]
This unifies it with e.g. the libraryPaths property
Check for the case that a new file to be added to a .qmlproject
is also automatically covered e.g. by a wildcard filter. In this
case we don't have to do anything.
Will be passed to qmlviewer with the "-L" option. Storing this in
the .qmlproject file format itself (and not in the .user file) is useful
in case the libraries are relative/part of the checkout that is shared
between users/computers.
