The goal is to avoid confusion described in issue #6422 by removing
duplicates between the Theme and owncloudTheme.
- Use the about from ownCloudTheme everywhere
- Create default applicationIcons() and condifFileName() that should work
everywhere
- trayFolderIcon was removed as it is not used
- the helpUrl from the default Theme now points to the owncloud client
documentation. Before there was no help entry by default for branded
client if the function was not overriden.
- Do not merge functions that would otherwise break compatibility with
theme that did not override them. For example colors or customMedia.
OCC::FolderStatusModel::slotUpdateDirectories: ASSERT: "parentInfo->_fetching" in file /home/olivier/kdegit/owncloud/mirall/src/gui/folderstatusmodel.cpp, line 599
This can happen if the structure of a folder is change while the user
expands the root folder. In this case, resetSubs() is called which
resets _fetching to false.
Instead, we need to keep a pointer to the job so we can abort it by
deleting it.
We otherwise normalize all path in the C form, so we must have
the Folder's path normalized the same. Or all comparizon will fail
(such as knowing if a file from the SocketAPI or the FilesystemWatcher
are part of the folder)
Issue #4424
If the SyncResult incorrectly believes that there are no conflicts, the
tray icon won't be correct and there will be no warning about unresolved
conflicts on the account.
Nevertheless, it's pretty awkward that the IssuesWidget is better
informed about pending conflicts than the Folder itself. This kind of
backwards data flow is very confusing.
Unfortunately the only alternative I see is to either keep track of
this information in two places (also in Folder), or create a common
data-holding class that can serve as a model instance for the issues
view as well as provide data directly to the Folder - which would
have been a much larger change.
Everything is invalidated later: after discovery, not before. In
addition entries that should only be invalidated when new local
discovery is done have that behavior now.
The AbstractNetworkJob already has a sensible timeout that depends
on an environment variable.
No need to overwrite that with some arbitrary value. (The connection
validator does that because it could cause problems if two connection
validator were to run at the same time. Not a problem here)
Since the release package will be build with unit test, we don't
want to query the env variable at every call to fsCasePreserving.
So only test the env variable at startup.
And the testutility can still change the value.
(The env variable is still used from t8.pl and maybe smashbox)
Issue #6318
