owncloud-archive / documents Goto Github PK

The editor is not loaded anymore if used with current core master. Probably the most recent restructurings broke something?

In a long run switch to core template manager (available in core since OC6)

User should be able to set it in Personal
Created if not exists.

to implement

With master. Just the grey background and spinner. I get this PHP error:

PHP Strict Standards:  Non-static method OCA\\Documents\\Db::buildPlaceholders() should not be called statically in /home/user/owncloud/apps/documents/lib/session.php on line 94, referer: http://127.0.0.1/owncloud/index.php/apps/documents

@VicDeo

resources/font/fonts.css references font-files:

src: url("/owncloud/apps/documents/resources/fonts/LiberationSans-Regular.ttf") format("truetype");

The URL is currently hardcoded/absolute. This needs to be fixed by either some dynamic generation of the fonts.css file or perhaps there is a way to use relative links
so that it still works from all places that might use it (font chooser and actual rendering).

double click on close button raises an assertion...
(tried to unsubscribe unknown callback...)
"closing" state needs to be tracked to prevent this.

Currently, there is a big popover with my user picture where my cursor is in the text. This is not needed for the person itself, only to show the location of the other participants.

Previews are not used for documents on master any more

Currently the editor is shown embedded in the ownCloud shell.

Citing @jancborchardt:
"When a file is opened, it should fill the whole viewport much like the
Pictures slideshow component."

There are two different systems for handling i18n of UI strings in the WebODF Editor: one custom for WebODF and one for those for the used Dojo classes.

The WebODF one is a manual system WRT to the creation: the used UI strings are manually added to the file "js/editor/nls/myResources.js", translations are manually added to files "js/editor/nls/$lc/myResources.js". On runtime the matching myResources.js file is included via Dojo's require system, by the id magic "dojo/i18n!webodf/editor/nls/myResources"
(still to research: from where the actual language id to use is fetched at runtime).

Besides that there is an amalgation with all existing translations for the Dojo classes, fetched and composed from the Dojo servers by some clever script of Tobias (no clue about that myself), but only for ru and de (for legacy reasons). For some reason both in the file "js/editor/nls/dojobundle.js" and "js/dojo-amalgamation.js", not sure why.

In Berlin I already talked about that with Thomas(?) but since then forgot half of the proposed solutions. But I think the idea was to do the integration like this for now:
WebODF does not change its code. Instead the scripts to integrate with transiflex are extended to

• read out the js/editor/nls/myResources.js and turn it into the proper format used by transiflex
• create the proper js/editor/nls/$lc/myResources.js files from the returned po files (and add the lc entries to js/editor/nls/myResources.js)

Something similar would be done for the Dojo strings. But for that possibly the script to create the dojo amalgamation has be adapted slightly, to have the general strings resource file as well as the individual translations easier accessable. No ideas from my side for that, left to Thomas(?) and Tobias for now.

Seems there is no official ownCloud default avatar ATM. So Documents is using its own default avatar image for now, until there is an official ownCloud one.

Avatar image is is a smiley from tango icon set.

If you press in Firefox enter the cursor moves to a new line, but isn't in the right position. After starting typing all is fine.

I use Firefox 23.0.1 on Linux

On leaving the session in any way except the 'Close' button

That’s the error I get trying to open a document. How can I fix it? And can we make it so that this never appears and whatever I need to do happens automatically? (I assume it’s not done yet ;)

Getting this after activating documents:

{"app":"core","message":"An exception occurred while executing 'COMMENT ON COLUMN "oc_documents_revisions".save_hash IS 'used to lookup revision in documents folder of member, eg '{hash}.odt''':\n\nSQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "{"\nLINE 1: ...ookup revision in documents folder of member, eg '{hash}.odt...\n ^","level":3,"time":"2013-09-14T20:16:54+00:00"}

Sessions should be closed if the last member leaves. This does not happen currently.

Drawback is that this also means that the whole stack of operations created is kept around as well as the copy of the original document, so using storage in db and filesystem.
Additionally the startup of the session is taking longer and longer by the time, because all ops ever created have to be replayed, due to the current design.

The Invite-Button should output a URL pointing to the editing session.

For oc5-milestone:

• good enough if the URL works for authenticated users only
• also good enough to assume the genesis document is shared already

For oc6-milestone:

• public invite links
• creating an invite-link shall take care of sharing the document

Currently still a copy of the one of the Files app.
Assigning jan as he once stated: "Will also make a new icon for it." :)

With master and ownCloud master. The button stays with the active color, there’s no errors in the console but this PHP error:

[error] [client 127.0.0.1] PHP Strict Standards:  Non-static method OCA\\Documents\\Db::buildPlaceholders() should not be called statically in /home/user/owncloud/apps/documents/lib/member.php on line 51, referer: http://127.0.0.1/owncloud/index.php/apps/documents

@VicDeo @kossebau @thz

For 'normal' files

• write permission to the file when starting a session
• write permission to the file when joining a session
• read permission to the file when fetching the ops
• write permission to the file when saving a session
• read permission to the file when joining a session in 'view' mode?

For shared files (to user, to group & via public link)

• write permission to the shared file when starting a session
• write permission to the shared file when joining a session
• read permission to the shared file when fetching the ops
• write permission to the shared file when saving a session
• read permission to the shared file when joining a session in 'view' mode?

For files on external storage

• write permission to the file on external storage when starting a session
• write permission to the file on external storage when joining a session
• read permission to the file on external storage when fetching the ops
• write permission to the file on external storage when saving a session
• read permission to the file on external storage when joining a session in 'view' mode?

For shared files on external storage (to user, to group & via public link)

• write permission to the shared file on external storage when starting a session
• write permission to the shared file on external storage when joining a session
• read permission to the shared file on external storage when fetching the ops
• write permission to the shared file on external storage when saving a session
• read permission to the shared file on external storage when joining a session in 'view' mode?

Seems the fullscreen mode of the Editor is slightly too wide, I get a horizontal scrollbar below the editor element (Firefox/Chromium) with which I can scroll the complete editor a few pixels left/right.

When the Editor is shown and the user clicks on any link (e.g. to configure his/her account settings or simply a browser bookmark), then currently the cursor is not removed and the editing session is not left from the server POV.
While the server will drop the cursor and the member from the session after a while, if the user returns to the session quickly enough he/she will see the own old cursor still in the session, additionally to the new/current one.

Because the design of WebODF explicitely supports the concept of having multiple cursors from the same user in the document, simply reassigning any existing cursor to the same user on session entering is no option.

Instead the webpage with the Editor running has to try to trigger the cursor removal and the session leaving on the page unload as good as it can.

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

For the version after ownCloud 6 we should look into using something like

• Medium Editor: http://daviferreira.github.io/medium-editor/
• Hallo.js: http://hallojs.org/

What I mean specifically is the toolbar which pops open directly near the text when you select some part. Only when you need it.

cc @thz @kossebau @VicDeo

Readme or something else on how to install the fonts is necessary.

The paragraph style selector e.g. is completely covered by the div when I make the browser window half as wide as my screen
@VicDeo

double click on close button raises an assertion...
(tried to unsubscribe unknown callback...)
"closing" state needs to be tracked to prevent this.

It should be possible to create a new document from the Documents app to directly start writing. Currently you need to upload an existing one or create a new one from the Files app. @VicDeo @kossebau

Interface-wise, the upload button should simple be split in 2: top for uploading, bottom for creating a new document. I’ll take care of that though. ;)

Think it would be better to have it displayed somewhere.

But where? Browser window title? Toolbar? ...?

ODF files also have an own title. But WebODF does not yet support editing it, so we better also do not show it ;)

Browser log shows lots of
GET http://localhost/owncloud/index.php/apps/avatar-joe.png 404 (Not Found)

Perhaps I'm missing something but how can I invite someone to edit a document together with me? Wasn't there an invite button once?
I can't see it with core master and documents master.
@VicDeo

double click on close button raises an assertion,
because of 2nd click tries to close while already "closing"...
(tried to unsubscribe unknown callback...)
"closing" state needs to be tracked to prevent this.

As a user it's really annoying to have those fancy avatars right inside your text. You want to write and therefore you often need to read the sentence you currently writing. So the avatar is just annoying. I think it enough to have the color <-> user relationship on the left side. Maybe add a on hover effect - if the user hover over a avator in the sidebar the corresponding cursor in the text area gets expanded to the cursor with avatar (like it's now).

cc @jancborchardt

When going from the documents grid to the editor a scrollbar is added to the whole webpage. It is removed if closing the editor again.

The document grid uses the PNG file type icon, which makes it appear blurry. Instead, the SVG should be used. Same filename, except .svg extension.

I tried to change it myself but couldn’t find where it’s set. @VicDeo

Since the last updates from our side (webodf), the OCA\Documents\Controller\save() function is now called when the save-POST request comes in (which happens on last members close).
It does not save though.

save() does not follow the API/protocol. the POST body is the actual BLOB of the serialized document. Additional data is sent via HTTP headers (instead of current $_POST['es_id'], $_POST['member_id'], $_POST['content']).

Please get parameters from the following headers:
es_id from "webodf-session-id"
seq_head from "webodf-session-revision"
member_id from "webodf-member-id"

(We decided against use of "X-" prefixes for the HTTP headers in accordance with RFC6648.)

Also:
Documents app should introduce a new table oc_documents_revisions which links between revisions from editing sessions (based on operation sequences) and saved files (and their versions possibly). save() should insert a row into that new table: (es_id, seq_head, member_id, fileid, save_url, save_hash).

#34

Interface-wise, the upload button should simple be split in 2: top for uploading, bottom for creating a new document. I’ll take care of that though. ;)

WebODF currently replays all existing ops in the live DOM on startup (will be improved only in some future version). Ideally this is hidden from the user.

Setting the WebODF editor to just "display: none" does not work, because some logic depends on the rects on the screen (only solved in future versions of WebODF)

So there might be some full page overlay a top of the Editor element, showing a loading indicator, for better UX?

The Editor is ready to be used by the user in the callback passed to documentsMain.webodfEditorInstance.openSession(...), so right before or after
documentsMain.webodfEditorInstance.startEditing();
Does not really matter if before or after, that call more or less enables the toolbar, puts a cursor into the document and starts to turn keyboard/mouse input into operations, if focus is set. So perhaps after is better.

Because there are no anchors used for the documents, a refresh throws you back to the document overview. Instead, a refresh should also open the document again if one was open.

... needs to be implemented

If in grid view of documents/sessions, a double/multi click is not catched and results in multiple instances of the editor created (which results in broken state).

Delete the session and it's data if the original file is deleted

Just did a git pull, got an error page with this:

Failed to upgrade "documents".

#0 /home/user/owncloud/lib/app.php(94): OC_App::checkUpgrade('documents')
#1 /home/user/owncloud/lib/app.php(68): OC_App::loadApp('documents')
#2 /home/user/owncloud/lib/base.php(629): OC_App::loadApps()
#3 /home/user/owncloud/index.php(30): OC::handleRequest()
#4 {main}

@butonic @VicDeo @kossebau

core PR pending: owncloud/core#4207

Hi,
I'm using ownCloud version 5.0.10 and firefox 23.0 on Fedora 19. When I try to copy some text from text editor in ownCloud (text application that shows when clicking some text file), it doesn't work. Ctrl+c/v does work.
Is this a known problem, unknown problem or development decision? And is anyone else facing this issue?
Thanks,
mbartos

Currently the original file is overwritten in any case when there is a save trigger in the session (currently when somebody leaves the session after having edited the document).

At the Berlin OC Dev meeting @jancborchardt proposed to check if the sync client has overwritten the original file (seems there is some hook) and in that case create ourselve a new file, called "original name (conflict).odt" or like that, similar to what a certain app does (forgot which, possibly also the sync client in case it detects a conflict).
So the documents app would have to create itself that copy and continue to save to that, as if it was the original file.

Maybe something to look into for collaboration: https://togetherjs.com
cc @kossebau @thz @VicDeo @karlitschek @butonic