Peter Dolanjski [:pdol] Reporter
	Description • 12 years ago

UCID: VideoPlay-027

User Story:
As a user, from the Video application, I want to be able to send video files to another mobile device or computer using Bluetooth to make it easier to share content.

	Casey Yee
	Comment 1 • 12 years ago

Spec here for sending file via Bluetooth:
https://www.dropbox.com/s/ew8fw4u4b668ue0/video-sharing-v1-0204.pdf

Bluetooth file transfer progress implements the progress as per page 3 of the existing spec:
https://www.dropbox.com/s/i1ls7vqt0bfm1qe/Bluetooth-Sharing.pdf

cc. Rob

	Casey Yee
	Comment 2 • 12 years ago

I Also had a discussion with ericchou and he mentions that there will be support for multiple file transfers supported for 1.1.   If this is the case we'll want to include the support to select multiple files in the share interface.

	Joe Cheng [:jcheng] (please needinfo)
	Comment 3 • 12 years ago

description says sharing from Video app. From Casey's spec, it seems to be sharing from Gallery app.

It seems to make sense for both apps to support video sharing? thanks

	Peter Dolanjski [:pdol] Reporter
	Comment 4 • 12 years ago

Casey/Josh, what was the decision that was made in 1.0 regarding video in the Gallery app?  If we are showing video in the Gallery app, then I agree with Joe, it makes sense to share via BT from both apps.

	Dylan Oliver [:doliver]
	Comment 5 • 12 years ago

Sharing videos from Gallery already works in v1.0.1 -- this story is about enabling it from the Video app, where right now the only actions you can take are press to watch and long press to delete. The first link in comment #1 looks like the right spec.

	Casey Yee
	Comment 6 • 12 years ago

(In reply to Peter Dolanjski [:pdol] from comment #4)
> Casey/Josh, what was the decision that was made in 1.0 regarding video in
> the Gallery app?  If we are showing video in the Gallery app, then I agree
> with Joe, it makes sense to share via BT from both apps.

We are showing videos shot by the camera in the video app as well as in the gallery.

Any videos copied by BT or USB should only show up within the video app.


(In reply to Dylan Oliver [:doliver] from comment #5)
> Sharing videos from Gallery already works in v1.0.1 -- this story is about
> enabling it from the Video app, where right now the only actions you can
> take are press to watch and long press to delete. The first link in comment
> #1 looks like the right spec.

We will need to write up some UX spec for this.  The design will be the as it is with gallery app:
- Addition of a bottom bar with a selection button (dotted box icon).  The button on it's own will be a little lonely so it also might make sense to put a camera button in that directly launches into video mode.
- When user enters selection mode and chooses a video, the bottom action menu will have options to delete and share the video.
- Remove the long-press to delete video (since this can be now done through the select->delete operation)

	Chris Lee [:clee]
	Comment 7 • 12 years ago

Dale, I know you about to start on this bug.  Can you provide an update if you're concerned about completing this for next Friday?  Thanks.

	Dale Harvey (:daleharvey)
	Comment 8 • 12 years ago

I am on PTO this week, was planning to have it implemented by last friday but other work got in the way. I should be able to get this finished on the plane but to be safe probably bet to get someone else to own it in case.

	Dylan Oliver [:doliver]
	Comment 9 • 12 years ago

James will try to pick this one up if Dale isn't able to code it from his tray table.

	Kai-Chih Hu [:khu]
	Comment 10 • 12 years ago

Hi, Tim, do you think if there has anyone from your team can help this case? Thanks!

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 11 • 12 years ago

(In reply to khu from comment #10)
> Hi, Tim, do you think if there has anyone from your team can help this case?
> Thanks!

This bug involves implementing selection view from the main view. It will be safer for original owners to work on it.

Dale, do you have any work-in-progress branch that you could put online?

Fred, Yuren, can any of you take this bug?

	gasolin@mozilla.com Assignee
	Comment 12 • 12 years ago

Sure, I'll take it

	gasolin@mozilla.com Assignee
	Comment 13 • 12 years ago

After some initial check, I can share file with other device in video.app. But UI still need tweaking.

I found video.app does not have the pageview concept as gallery.app.
So if we want to support more views (ex: multiple selection), it will need more time to refactor video.app to a maintainable structure.

	Arun Balachandran Ganesan [:abc]
	Comment 14 • 12 years ago

Guys:

You can find the specs here
https://www.dropbox.com/s/h89kj0xrwygfj1n/Sharing-videos-via-bluetooth.pdf

Let me know if there are any questions.

Cheers,
Arun

	Dylan Oliver [:doliver]
	Comment 15 • 12 years ago

Fred, can you post your work in progress so Dale can take a look at it when he returns from vacation tomorrow? Maybe the two of you can decide who's in the best position to get this one finished up.

	gasolin@mozilla.com Assignee
	Comment 16 • 12 years ago

Last Friday I do some early stage check about video.app source,
validated that the video file can be get and shared via Bluetooth successfully.

Then I try to add some style sheets and bottom layout from gallery.app and make button clickable to call related functions (at same page, and not consider hide unrelated actions yet).

Currently the side effect is soon the app become unstable after play video for a while (within 10s?). So I'd dive deeper to see what's going on.

As I mentioned video.app does not have the pageview concept as gallery.app. It needs some refactory work before implement the Sharing-videos-via-bluetooth spec.

	gasolin@mozilla.com Assignee
	Comment 17 • 12 years ago

Arun,

Thanks for the new spec. I've compare the activities in gallery.app for consistency
and like to check which are preferred way for several components.

page3,

In 7,8,9 is an action menu. In Current gallery.app for video sharing, there's only the direct bluetooth transfer dialog instead of an action menu. (just found root cause is Email not support video(.3gp) attachment via 'share' web activity)

In 14 not found similar 'file transfer via Bluetooth has been initiated' pop message bar in gallery.app. (but did have 'been completed' bar)

In 13,17,18 currently gallery and video are fullscreen app, not able to swipe down from top


Here are some features needs to be implemented according to the spec (maybe split to other issue?):

* video button to open a video screen and shot a video
* multiple selection page (should be done before this issue)
* share via web activity (for any supported sender includes bluetooth, directly relate to this issue)
* support video attachment in Email app
* system 'file transfer via Bluetooth has been initiated' pop bar
* find a way to swipe utility tray in fullscreen app

	gasolin@mozilla.com Assignee
	Comment 18 • 12 years ago

Bug 838008 is * support video attachment in Email app

	Arun Balachandran Ganesan [:abc]
	Comment 19 • 12 years ago

Thanks, Fred. My comments inline.

> 
> In 7,8,9 is an action menu. In Current gallery.app for video sharing,
> there's only the direct Bluetooth transfer dialog instead of an action menu.
> (just found root cause is Email not support video(.3gp) attachment via
> 'share' web activity)

Yes, even when Bluetooth is not supported the action menu has to be there. While it's not the best way to communicate that only one file can be sent via Bluetooth, it is one that works with the existing design patterns.

> In 14 not found similar 'file transfer via Bluetooth has been initiated' pop
> message bar in gallery.app. (but did have 'been completed' bar)

Yes, if it is not a lot of work, it would be good to have this. It provides feedback to the user to let him know that the Bluetooth transfer is being started.

> In 13,17,18 currently gallery and video are full screen app, not able to
> swipe down from top

Wow :O Are you saying that we cannot access the utility tray for any of the full screen apps?

	gasolin@mozilla.com Assignee
	Comment 20 • 12 years ago

> Wow :O Are you saying that we cannot access the utility tray for any of the full 
> screen apps?

For build-in apps, I saw Gallery, Video, and Camera app are fullscreen and not able to access the utility tray.

	gasolin@mozilla.com Assignee
	Comment 21 • 12 years ago

Hi I'll take PTO today, here is my WIP for reference
https://github.com/mozilla-b2g/gaia/pull/8719

current status:

* Refactored and wrap elements into viewpages.
* have bottom bar and can switch between list/select/player page.

lack:

* multiple select for delete and share actions
* i10n strings for 'select' message
* button action (and screen) to shot a video

	Arun Balachandran Ganesan [:abc]
	Comment 22 • 12 years ago

Thanks, Fred. 

If there is a progress bar within the video app UI, would it work? Would it continue to work even if the user switches apps and gets back? Will the Bluetooth transfer happen in the background even if I am using another app?

Cheers,
Arun

	Arun Balachandran Ganesan [:abc]
	Comment 23 • 12 years ago

> > In 13,17,18 currently gallery and video are full screen app, not able to
> > swipe down from top

I tried it on my mobile and it works fine. I can access the utility tray in the list of videos (and it's not in full screen mode while the list of videos is the view!)

Can you please specifically tell me which screens in the specs there seems to be trouble with, if it still seems to be the case? Thank you!

Cheers,
Arun

	gasolin@mozilla.com Assignee
	Comment 24 • 12 years ago

After double check with the base version, I found video.app can access the utility tray. So extra progress bar may not necessary.

(but the other two apps are still can't access utility tray)

My apologies for providing the wrong info.

	Arun Balachandran Ganesan [:abc]
	Comment 25 • 12 years ago

No problem, Fred. Can you confirm that no more UX work is required for this bug? Thank you!

Cheers,
Arun

	gasolin@mozilla.com Assignee
	Comment 26 • 12 years ago

Arun, 

one thing I'd like to know is if the share button will show on right top of video player(play a video) screen (like delete button did)?

	Arun Balachandran Ganesan [:abc]
	Comment 27 • 12 years ago

Fred:

Does the delete button work? (it does not work for me)

I guess I need to think about it – there's not a lot of room there. I personally prefer the pattern used in the gallery app. Let me check with the team and get back to you.

Cheers,
Arun

	gasolin@mozilla.com Assignee
	Comment 28 • 12 years ago

done:

* i10n strings for 'select' message
* button action (and screen) to shot a video

side issue: camera did not support open directly with video mode


lack:
* multiple select 
* connect select to delete and share actions

	gasolin@mozilla.com Assignee
	Comment 29 • 12 years ago

Arun,

on my phone delete button in fullscreen works.

I found an issue about 'shot a video' function. 
Since shot a video is call camera app to record video. 
And camera app only have 'photo album'(go to gallery.app) icon near the 'shot' icon. 
There's no way to turn back to video.app from camera.app. (or take a shot and go to gallery app is good enough?)

It might be need some extra UX work to clarify the transition between video.app and camera.app

	gasolin@mozilla.com Assignee
	Comment 30 • 12 years ago

offload the 'take a shot' related integration issue to Bug 853349

	gasolin@mozilla.com Assignee
	Comment 31 • 12 years ago

Hi Dale,

I've got some progress and near the final stage.
 
Since this is a huge change of video.app. 
Can you give me some advice if my approach is appropriate? https://github.com/mozilla-b2g/gaia/pull/8719 (work in progress)

	Jason Smith [:jsmith]
	Comment 32 • 12 years ago

John - I think you added test coverage for this, right?

	Arun Balachandran Ganesan [:abc]
	Comment 33 • 12 years ago

> on my phone delete button in fullscreen works. 
> I found an issue about 'shot a video' function. 
> Since shot a video is call camera app to record video. 
> And camera app only have 'photo album'(go to gallery.app) icon near the
> 'shot' icon. 
> There's no way to turn back to video.app from camera.app. (or take a shot
> and go to gallery app is good enough?)

Yes, it should be fine for now. (Isn't that how the camera button in gallery app works too?) That said, I definitely think we should fix it for the later versions.

> It might be need some extra UX work to clarify the transition between
> video.app and camera.app


Is there something else that needs clarification? I have updated the specs, and waiting for UX feedback before posting them here.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 34 • 12 years ago

Hi,
If UX strongly wants the feature "pull down utility tray when in fullscreen", please file another bug.
IMO this one is not implementable now. Except that we could make touch event fired through mozbrowser iframe to system app.(should we do this? No I think.)

	gasolin@mozilla.com Assignee
	Comment 35 • 12 years ago

Just have a functional version that fulfill the user story and basic spec. 
Since the spec request many changes from the current app, side effect and limitations will be addressed in another post.

Features Add

* (refactor for improvement) wrap current list and player view in sections(viewpage). 
* add bottom bar with 'take a shot' and 'select' functions
* add select page that support multiple selection
* add 'share via bluetooth' function in select page
* support delete multiple files in select page

Features Remove 
* remove long click delete function from main video selection page

	gasolin@mozilla.com Assignee
	Comment 36 • 12 years ago

side effect and limitations addressed here:

* Bluetooth only support single file sharing, thus if user select 2+ videos in selection page, will popup an dialog says 'not provide this function'. 
(checked and consulted with ian)

actions:
1. correct message wording should be provided
2. file another feature request for support share multiple file via bluetooth (not sure if it works) ?

* Fullscreen mode not support swiping up and down the utility tray. We saw that works in some builds but its not a normal behavior... (consulted with alive and ian)

actions:
3. file another issue to discuss about the right way for system wise utility tray behavior with fullscreen view

* It's not an easy work to integrate bluetooth transfer status in video.app.

actions:
4. Fire another issue and consider to take gallery.app in the same manner
(consulted with ian)

	Arun Balachandran Ganesan [:abc]
	Comment 40 • 12 years ago

(In reply to Alive Kuo [:alive] (PTO during 3/27~4/7) from comment #34)
> Hi,
> If UX strongly wants the feature "pull down utility tray when in
> fullscreen", please file another bug.
> IMO this one is not implementable now. Except that we could make touch event
> fired through mozbrowser iframe to system app.(should we do this? No I
> think.)

Alive:

Please read my comments above. I'm not advocating to have utility tray work in full screen — I currently don't have any thoughts to add there. But, it does not matter as the 'list of videos' view is NOT in full screen mode. Thanks!

Cheers,
Arun

	Arun Balachandran Ganesan [:abc]
	Comment 41 • 12 years ago

(In reply to Fred Lin [:gasolin] from comment #39)
> Created attachment 728036 [details]
> can't share message (get from gallery app)

Hey Fred:

Which file formats do we support? Also, if a file format is not supported for Bluetooth transfer, is it always the case that it is ALSO not supported for any other way/method of file transfer like email? Thanks!

Arun

	David Flanagan [:djf]
	Comment 42 • 12 years ago

I've only had time to glance at the patch so far.  Some initial thoughts:

- you'll have to squash it all down into a single commit before landing, of course

- the patch currently includes commented out code that should just be deleted

- I'm not certain whether you should copy strings from the non-english locale files. I'm pretty sure those are not used in production builds anymore. It might be better to just leave the arabic, french and taiwanese strings out of the patch.

Also, I'm confused by the comment on github that says that patch lacks "multiple select event for delete and share".  What do you mean by that?

	Arun Balachandran Ganesan [:abc]
	Comment 43 • 12 years ago

Fred:

Here's the updated specs:
https://www.dropbox.com/s/n5tgyc6j1an2oew/Sharing-videos-via-bluetooth.pdf

Thoughts?

I will need more info (see comment 41) to create the specs for that scenario you have mentioned. Thanks!

	Dale Harvey (:daleharvey)
	Comment 44 • 12 years ago

I just realised I was needinfo on this, not r?, but I have taken a look and tested this. 

The patch looks good, above comments apply, I am not sure if we want to have VisDes take a look as the style matches gallery selection but feels awkward. (I couldnt find any specs)

	Arun Balachandran Ganesan [:abc]
	Comment 45 • 12 years ago

https://www.dropbox.com/s/akv713h6fmeptun/Sharing-videos-via-bluetooth.pdf 

Moved the specs to this location. 

Let me tag :pla (Peter La) for visual design review.


Cheers,
Arun

	Arun Balachandran Ganesan [:abc]
	Comment 46 • 12 years ago

https://www.dropbox.com/s/akv713h6fmeptun/Sharing-videos-via-bluetooth.pdf 

Moved the specs to this location. 

Let me tag :pla (Peter La) for visual design review.


Cheers,
Arun

	gasolin@mozilla.com Assignee
	Comment 47 • 12 years ago

reply comment 41 ,

Currently picture and video format are supported for sharing,
but now 'share' action only support share '1' file.

	gasolin@mozilla.com Assignee
	Comment 48 • 12 years ago

reply comment 42,

David,

thanks for check, I'll do point 1, 2 and remove locals for point 3.


update comment: can't share multiple videos (because bluetooth share not support that action)

	gasolin@mozilla.com Assignee
	Comment 49 • 12 years ago

reply comment 44,

Dale,

Glad to hear you are back. My colleague suggest me to ask :djf first to make some progress since you are in PTO. It's nice if you can help to review this patch?


In this patch I take styles from gallery.app, it still need some adjustment for UI styles.

	Arun Balachandran Ganesan [:abc]
	Comment 50 • 12 years ago

re: comment 39

Fred: What is this for?

Whatever file type the videos are in the video.app, the users can share right?

Thanks!
Arun

	gasolin@mozilla.com Assignee
	Comment 51 • 12 years ago

Arun,

The user can share 'one' video at a time due to the bluetooth share limitation.

If user select more than 1 video and click the share button, this dialog will be shown.

	Arun Balachandran Ganesan [:abc]
	Comment 52 • 12 years ago

(In reply to Fred Lin [:gasolin] from comment #51)
> Arun,
> 
> The user can share 'one' video at a time due to the bluetooth share
> limitation.
> 
> If user select more than 1 video and click the share button, this dialog
> will be shown.

Fred:

The message shown in this dialog does not convey 'why' the sharing does not work. Can you please refer to the specs (page 4) and check if it works? If there are any concerns with it, feel free to share them. Thanks!

Cheers,
Arun

	David Flanagan [:djf]
	Comment 53 • 12 years ago

I'm sorry I haven't reviewed this yet. I've looked quickly over the code, and it seems fine to me, but I have not tested it and I will not have time for a careful review until Thursday or Friday. If you need to land this more quickly perhaps Dale can help. I'd give a feedback+ here and am very comfortable having someone else complete the review so you can get this landed sooner.

Here are a couple of thoughts:

1) Since you're modifying camera/manifest.webapp to allow a record type of "video", it would be good to modify the camera app itself so that it launches to the video recorder when you use that activity.  That could be a separate bug, however.

2) The error message discussed above is displayed when there is no installed app that is able to handle the share request. Changing it is just a matter of changing a string in the locale file. If we expect that there are not other apps (like a youtube uploader app) that will accept multiple shared videos, you should consider using an error message that includes instructions to "Try sharing one video at a time". I suppose in this case, if no apps accept a multiple share, you could actually put a loop in the video app to share each selected item one at a time.   (It is probably too late to be making that kind of change, however).

	gasolin@mozilla.com Assignee
	Comment 54 • 12 years ago

David,

Thanks for feedback 

1. the issue was addressed in Bug 853349

2. I like the idea "Try sharing one video at a time". Currently string was changed to meet the new spec.

	gasolin@mozilla.com Assignee
	Comment 55 • 12 years ago

Comment on attachment 728026 [details]
revise video app to act similar to gallery.app

change r? to dale

	gasolin@mozilla.com Assignee
	Comment 56 • 12 years ago

The latest pull request is squished, 
changed string to 'Multiple videos cannot be sent in a single bluetooth transfer.' 
add the bottom bar in play mode to meet the new spec in comment #45

	Joe Cheng [:jcheng] (please needinfo)
	Comment 57 • 12 years ago

wonder what's the review progress on this bug? thanks

	Dale Harvey (:daleharvey)
	Comment 58 • 12 years ago

Very sorry, in the process of reviewing, I got side tracked previously, I havent found issues yet, will be done soon

	Dale Harvey (:daleharvey)
	Comment 59 • 12 years ago

Comment on attachment 728026 [details]
revise video app to act similar to gallery.app

Merged in: https://github.com/mozilla-b2g/gaia/commit/733e68c85acf60fe7029b11f72b08edd032c3720

Huge apologies for the delay on this

I found no issues with the code and if fixes a lot of things that separately needed fixed. 

I think UX should probably look at revising their specs, the stacked footers is a really terrible pattern but what was implented was to spec.

	jachen
	Comment 60 • 12 years ago

Casey will follow up today regarding the pattern.

	Dale Harvey (:daleharvey)
	Comment 61 • 12 years ago

Great, just for additional information users can share and delete videos from the listings page. The ability to do so in the play view isnt entirely necessary and although it may be convenient given no better alternative than stacking the toolbars I would suggest just removing the shortcut

	gasolin@mozilla.com Assignee
	Comment 62 • 12 years ago

Thanks Dave!

Add follow up (bug 853349) for camera.app related task.
(For the proper behavior when trigger camera with video type)

	Dale Harvey (:daleharvey)
	Comment 65 • 12 years ago

Asked to attach screenshots with and without the footer stacking

	Casey Yee
	Comment 66 • 12 years ago

Yikes!  That looks bad.   Let's remove the bottom bar with the share and delete buttons until visual design can make a pass at this.

We also want to prevent users from accidentally pressing the delete button when they intended to press play as well.

	Casey Yee
	Comment 67 • 12 years ago

Just had a chat with Arun about this.  He will be proposing alternate placement for the share button and possible removal of the delete option from the playback page.

	Arun Balachandran Ganesan [:abc]
	Comment 68 • 12 years ago

Dale:

I agree with you on the bottom bar (and share the same concerns that Casey has mentioned above) – we were trying to use existing patterns, without introducing new patterns. It was the option that was agreed to by everyone then. I just spoke with Casey and we decided to go with one of the other options that we were considering.

The delete option does not make sense and involves the risk of the user hitting it by accident (mainly given its current location right under the play button). However, the share function makes more sense to me to have it in the same screen – it's more likely for a user to share a video after watching it. Also, less likely for them to be sharing multiple videos (which also involves a current technical limitation we have). I earlier proposed putting a share icon on the right top corner (replacing the place which earlier had the delete icon in it). I will update my specs tomorrow to reflect that and post it here. If you have any thoughts, feel free to share. Thanks!

Cheers,
Arun

	Arun Balachandran Ganesan [:abc]
	Comment 69 • 12 years ago

Dale:

I agree with you on the bottom bar (and share the same concerns that Casey has mentioned above) – we were trying to use existing patterns, without introducing new patterns. It was the option that was agreed to by everyone then. I just spoke with Casey and we decided to go with one of the other options that we were considering.

The delete option does not make sense and involves the risk of the user hitting it by accident (mainly given its current location right under the play button). However, the share function makes more sense to me to have it in the same screen – it's more likely for a user to share a video after watching it. Also, less likely for them to be sharing multiple videos (which also involves a current technical limitation we have). I earlier proposed putting a share icon on the right top corner (replacing the place which earlier had the delete icon in it). I will update my specs tomorrow to reflect that and post it here. If you have any thoughts, feel free to share. Thanks!

Cheers,
Arun

	Arun Balachandran Ganesan [:abc]
	Comment 70 • 12 years ago

Oops. Sorry – mid-air collision.

	gasolin@mozilla.com Assignee
	Comment 71 • 12 years ago

r=dale, merged to gaia-master,
https://github.com/mozilla-b2g/gaia/commit/733e68c85acf60fe7029b11f72b08edd032c3720

	John Ford [:jhford] CET/CEST Berlin Time
	Comment 72 • 12 years ago

I was not able to uplift this bug to v1-train.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1-train, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1-train
  git cherry-pick -x -m1 733e68c85acf60fe7029b11f72b08edd032c3720
  <RESOLVE MERGE CONFLICTS>
  git commit

	gasolin@mozilla.com Assignee
	Comment 73 • 12 years ago

This is depend on bug 850574

compared with https://github.com/mozilla-b2g/gaia/commits/master/apps/video/js/video.js

	gasolin@mozilla.com Assignee
	Comment 74 • 12 years ago

bug 850574 commit hash is a864328909c542e31743c5f930e2f350c722f1ad

	gasolin@mozilla.com Assignee
	Comment 75 • 12 years ago

need to apply bug 850574 in v1-train before apply bug 838028

bug 850574 a864328909c542e31743c5f930e2f350c722f1ad
bug 838028 ef2e4e14712879b30de5215983175848b617b5ef

	gasolin@mozilla.com Assignee
	Comment 76 • 12 years ago

sorry,

bug 850574 is a864328909c542e31743c5f930e2f350c722f1ad
bug 838028 is 733e68c85acf60fe7029b11f72b08edd032c3720

	gasolin@mozilla.com Assignee
	Comment 77 • 12 years ago

Apply sequence will be 

bug 850574 a864328909c542e31743c5f930e2f350c722f1ad
bug 856798 f6ccd2f2bb52e3b0fba10410c2191585767cc13f
bug 830644 d67787040aec71b7a794ab24be5708fef685c187
bug 838028 733e68c85acf60fe7029b11f72b08edd032c3720

	John Ford [:jhford] CET/CEST Berlin Time
	Comment 78 • 12 years ago

I worked with Fred and we resolved the conflict.

v1-train: 2db4fb694c9d401aab833a127269f36a3561c4da