linergrand.blogg.se - Owncloud providers

Required information for the registry are: So an update of the registry entries is only needed, when the sync root changes. We do not need to worry about the individual folders that are synced for the account, as all of them are located in the same sync root. Basically, it allows Windows to query who is responsible for this directory. This marks the directory where the account is synced to and associates it with ownCloud. Windows needs one sync root provider per account. The branding-related things (in this case only the client name and the icon location) could be passed through the socket on these rare events. the integration into the navigation paneĪll of this is done through the registry, and requires updates only when sync roots change or the client is uninstalled.a sync root provider for every owncloud account.Unfortunately, I cannot allocate time to help out on this one. Another advantage of favorites is that the correct path appears in the address bar, while a Navigation Pane namespace creates hides the path on disk and shows itself as a logical root. So unless you see other benefits than having an icon to adding ownCloud to the root level of the Navigation Pane, I think we should stick with favorite links. This works well, we can have one icon for every sync root and the users can edit them as they wish. This is what I'm currently going for in #2446. Just keep using Quick Access folders like we already do This means that the root folder would be empty when the client is not running, unlike Dropbox or OneDrive namespaces which still work perfectly fine when their sync client isn't running.

The problem is that we'd probably put this in the same DLLs as the overlay icons and context menu extensions, and this means that the only way to fetch the list of root folder would be through the SocketAPI (since it's the same binary for every branding). This could be a nice solution if it's possible to create a shell extension to handle only the root folder, allowing us to delegate to regular Shell Instance Objects for each sync root. Implement a custom Shell Namespace Extensions to show a tree of accounts/folders registered This would make it easier and would be fine for most users but would be an incomplete solution and still not trivial to implement and maintain. Only add the first folder connection as a namespace

The only way it seems to be possible is by editing the registry so we'd need to somehow allow the user to customize this through the client's interface

This will clutter the explorer view of the user when using multiple accounts or folder connections.

Re-installing (when updating) would also need to re-add all those entries by parsing the existing config.

This solution would make it difficult to remove everything when we uninstall, we'd need to add complex logic to the uninstaller to walk over all namespaces and look for something that binds them to the client being uninstalled.

I've thought of the following solutions: Add a namespace icon at the root of the explorer tree for every folder connection But in our case this makes things quite complicated. OneDriver and Dropbox, for example, only seem to support a single sync folder and account, so it's pretty straightforward.

We're not cluttering explorer by adding a root namespace for every account+folder.

Uninstalling the client will remove all the namespace icon from Explorer's root.

I've been looking at implementing this but the fact that we support multiple accounts and folders makes this difficult to implement while making sure that: