Client: Wizard: Create a new directory name, don't always use "ownCloud"

[guruz]

Only use "ownCloud" (or whatever $THEMENAME) for a new install, for existing installs we want users consciously decide that they really want to sync into an existing directory
(Especially now where we allow to sync same directory to multiple servers)

[phil-davis]

I agree, it could be too easy to accidentally put multiple sync connections mapped into the same local folder.
It would be possible to have logic so that if the "owncloud" folder is not yet used by any sync connection then it is made the default. But actually if someone already has 1 ormore sync connections that do not use the "owncloud" local folder, then probably when they add another sync connection they likely do not want to use the (unused) "owncloud" folder anyway.

[ckamm]

@guruz @phil-davis This applies to the folder wizard and the account wizard. Should we default to offer syncing to a previously non-existing folder? E.g. owncloud/, owncloud2/, owncloud3/, ... whatever doesn't exist yet.

[phil-davis]

I would find a rule like this to be reasonable:
1) If the existing accounts are all synced in the "default" home folder owncloud/, owncloud2/,... then offer the next owncloud_n_/ as the default for a new sync connection.
2) Otherwise (i.e. if there is any sync connection that the was explicitly chosen non-default in the past by the user) offer no default - so the user cannot "accidentally" click through and end up with what the (probably) do not want.

But such a rule might be a bit surprising to users who notice and ask about why a default was or wasn't presented.

[guruz]

Could even have ownCloud_$PARTOFHOSTNAME like ownCloud_UniversityOfBiesdorf or ownCloud_philscloud automagically

[phil-davis]

That sounds good. It might be a bit tricky depending on the domain name of the cloud instance.
1) Probably want to have the username in there also? Keep dots in usernames like "phil.davis"?
2) Some people will have a domain like davis.mycloudhoster.com and so you can grab the "davis" part. But others will have cloud.universityofxyz.edu and if you just grab "cloud" then that is of little use.

and if you take the whole thing (and maybe replace dots with "-" or "_"?) then you get long things like:
ownCloud_davis-mycloudhoster-com_phil-davis

Hmmm - is there a nice algorithm possible here?

[ckamm]

I'll take care of the first incremental step: Never default to a folder that is already in use.

For nicer defaults: How about we use the second level domain ("uni-abc", "mycloudhoster", ...), disambiguated by username if necessary? I'd not try to put magic into it.

Similar logic might want to be applied to our account display names.

[ckamm]

Pull request for first part: https://github.com/owncloud/client/pull/5638

[SamuAlfageme]

See #5756 for some related issue, otherwise is working as expected 👍

[ckamm]

@SamuAlfageme Why reopen?

[SamuAlfageme]

@ckamm I accidentally clicked on close, sorry.

I still want to test some branded scenarios and address some comments from @pmaier1 on the folder naming convention, nothing big.

[ckamm]

@SamuAlfageme Okay :)

[SamuAlfageme]

@pmaier1 we discussed this one a really long time ago. It was about using more clear names for the sync folders on the multiaccount scenario to distinguish. Only problem is the length of the names when not syncing the root (see example below)

If I understood correctly https://github.com/owncloud/client/issues/5295 that would be helpful to organize all the accounts in the client(s). Imagine the scenario with both a branded and unbranded client that displays 2 top-level dropdowns on the explorer's sidebar (1 per client):

• ownCloud (unbranded)
  
  
  
  • [email protected]
  
  
  • Photos - [email protected] - [when the root is not the folder to sync]
  
  
• testpilotCloud (branded client)
  
  
  
  • [email protected]
  
  

[ckamm]

@SamuAlfageme I think I'm missing context for your comment. If this is about further refinements for folder name selection in the wizard, I'd strongly recommend making a new ticket to not conflate it with the change we did for 2.4 here.

[guruz]

ACK, this is "good enough" now for 2.4.. :)