Default avatar image is not the official ownCloud default avatar image about documents HOT 16 CLOSED

Please review the profile picture pull request which will give us proper avatars: owncloud/core#4506
When there’s no profile picture, there will be a placeholder generated, which is a colored square with the first letter of the user in it.

Maybe @Kondou-ger or @kabum can help with implementing that in Documents? :)

from documents.

@jancborchardt
this is done to some extent de08e8c
and stable5? ;)

from documents.

Well … The "official" defaultavatar for owncloud is the $().placeholder() jquery widget developed by @kabum.

And as I already mentioned, avatars will need a bit of work in here, as the way @VicDeo did it is a bit old.

from documents.

@Kondou-ger I'm tracking the discussions in your PR and don't want to change anything until it is finally merged 🌵
In addition we need avatars for all users working on the current documents, not for current user only
$.() won't work in the current WebODF state as it expects an URL, not js-callback

from documents.

Then you won't get any defaultavatars though, as defaultavatars are pure JS …

from documents.

"defaultavatars are pure JS" means what exactly? Is that one-time-run JS which creates some image, or is that some html element which is drawn/updated by JS all the time? how would that pure JS be used, what does it do?

from documents.

@kossebau yes, it’s just a square div with a generated color and the first letter of the user inside it, in white. It’s used in the Music app as album art placeholder and for every user image placeholder. Performance and load-wise probably a much better solution than having those placeholders as images – especially because they are only needed in the web interface for now.

from documents.

@kossebau this is done as a jQuery plugin called on a specific node(s) that takes username and size as parameters:

$('#header').avatar(OC.currentUser, 32);
this produces HTML/CSS markup that consists of First letter of the username/some bg color generated by hashing the username (green bg with M on screenshot below):
https://f.cloud.github.com/assets/245432/1065729/87cc6a34-139c-11e3-88b4-97bf7a822896.png

from documents.

meh, that conflicts with the concepts implemented currently in webodf, where there is just metadata about users (or rather members of the editing session) delivered from the backend abstraction MemberList :( and "rendering" is done in custom ways, using that metadata, so not some html elements.
owncloud needs to improve here ;) I think there should be two layers, pure avatar/user data and convenience renderers.
Nothing that can be fixed quickly, without hacking webodf to some degree :( I have some idea how to solve that upstream so in Documents app that custom rendering could be hooked in, but that would take a couple of days to implement properly.
So for now/first releases we might just disable the memberlistview and the avatar flag of all cursors, to not be inconsistent with the rest of ownCloud?

from documents.

@kossebau I’d say use names and colors only for now, without avatars. No member list at all would also be strange.

from documents.

@kossebau @jancborchardt As a temporary stub I can pass a plain color background as an avatar.

from documents.

Ok, the avatars and placeholder stuff is now in core, can we have that in Documents? cc @kabum @Kondou-ger

from documents.

@jancborchardt we have it.
f3bd8aa

Currently WebODF can use link to avatar only (or data-uri).
Funky html markup done by js won't work.

from documents.

If there is no avatar defined by the user then the smilie should not be used. There should be no image at all there in that case, only the name and color.

from documents.

ok, fixed #51 and this one by patching upstream code

from documents.

thx

from documents.