Avatar

[karlitschek]

Can we use the user avatar picture instead of the smilie default image?
I'm testing core master and documents master here.
@VicDeo

[VicDeo]

@karlitschek yes, once you upload an avatar for your user (on "Personal" page)
duplicate of #22

[karlitschek]

But we have a nice "default" avatar. A colored box with the first letter of the name in it. Shoudn't this be used instead of a smilie?

[VicDeo]

@karlitschek #22 (comment)

[jancborchardt]

We probably need to think about the possibility of using these profile pictures outside of the browser (like in the mobile app) – and even the placeholders. Maybe it’s good if placeholder.js also has a component to render these placeholders as png? @kabum albeit I would make the pure HTML+CSS stuff still default and the rendering only in addition for now.

[DeepDiver1975]

Maybe it’s good if placeholder.js also has a component to render these placeholders as png? @kabum albeit I would make the pure HTML+CSS stuff still default and the rendering only in addition for now.

This will result in a full reimplementation of the placeholder code in php - meaning duplicate code and duplicate maintenance effort - generally speaking something we should try to avoid.

@VicDeo no chance to inject the html/css stuff into webodf? THX

[karlitschek]

It's cool to user html for that. Bu at the end of the day we need a real image for Desktop, Mobile and so on as Jan said. So we should provide a default image in the owncloud core. It's easy to do with php. @kabum

[MorrisJobke]

Should it hooked into the preview stuff (because it's nothing other than that) or should it extend the avatar stuff. Or does they already have something common?

[VicDeo]

@DeepDiver1975 there is nothing impossible at all. I avoid patching upstream as I don't want to create additional troubles with downstreaming in future. The other thing is that I foresee the pain of compiling WebODF on my own, but I think I can stand it.

[kossebau]

no chance to inject the html/css stuff into webodf?

In WebODF we have plans how to improve things to allow users of webodf.js complete customization of the rendering, not just by data. But that is not on the current agenda, so nothing to rely on for OC5/OC6 releases.

There are two places in webodf or rather webodf.js and the editor extensions where avatars are used: for the cursor flagging and in that member list view.

About cursor flagging:
By the issues #30 and #42 it seems the cursor flagging is not wanted anyway. That can be turned off, just that the control parameter is not yet exposed in the current official API of the WebODF Editor class. That could be fixed, either upstream or just by a simple patch in downstream.
For now I prefer the latter, until the set of parameters to expose has been thought about more.
Patch would be to set the parameter caretAvatarsInitiallyVisible of viewOptions in webodf/editor/Editor.js to false.

About Member List View:
that class is not compiled into webodf.js, but used as normal js file (compilation of editor module is still a TODO). So it might be a temporary solution to patch webodf/editor/MemberListView.js downstream, until there is proper image-only support implemented.
More, clicking the avatar of an member in that member list view toggles the visibility of the avatar flag on the cursor of that member. So that needs to be disabled then as well.

About patches & stuff:
To update the webodf code in Documents I wrote a small script which copies the relevant files from the build directory and then applies the current downstream patch, for "dojo/text!" + OC.filePath('documents', 'css', 'fonts.css'). I wonder if that could be just put somewhere in the Documents repo, so people other than me are able to easily update webodf from upstream. Where would I put the script and the downstream patches?

[VicDeo]

@kossebau Thanks a lot for your help.
Please push the script with patches to documents/src subdirectory, I already have some changes for upstream like 6700165 :)

[kossebau]

@VicDeo okay, will do tonight