Do we need an "official" API or is something like

gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/Shell --method org.gnome.Shell.Eval 'Main.componentManager._allComponents.recorder._toggleRecorder();'

enough?

I'd say we should have an "official" API so one can write a screen casting app that uses the compositor for recording without having to rely on Eval.

Here is what I have been asked to support:

- start / stop
- specify the output file
- specify the recorded area/window
- control the quality (optional)

This sounds useful, but strikes me as having some security implications: 
  * which programs get to trigger a recording?
  * can other programs see the file that gets recorded?
  * does the user get visual feedback that a recording is in progress?

(In reply to comment #4)
> This sounds useful, but strikes me as having some security implications: 
>   * which programs get to trigger a recording?

Anyone that can access the session bus

>   * can other programs see the file that gets recorded?

Yes (apps are currently not sandboxed and can pretty much read all the files in your home directory).

>   * does the user get visual feedback that a recording is in progress?

Yes this is currently the case and I don't see a reason why we should remove the recording indicator for dbus triggered recordings.

Yes, as long as the user session is a single security domain without any sandboxing, this makes no difference one way or the other.

Apps can already take screenshots and read all of your home directory.

We have plans to improve this situation, and this D-Bus api will be updated to fit into them when the time comes.

(In reply to comment #6)
> Apps can already take screenshots and read all of your home directory.

... or take a screencast (either by synthesizing the existing keyboard shortcut, or grabbing pixels from the framebuffer themselves). Offering a DBus API for screencasting just adds convenience, it doesn't actually change what applications can do (see recordMyDesktop which works just fine without collaboration from the window manager).

Florian, any update ?

Created attachment 243809 [details] [review]
shell-recorder: Optionally return the filename of the recording

It is currently not always possible to predict the actual output filename
of a recording - the file-template does not necessarily use an absolute
path and may contain %d and %t escape sequences.
This is OK for fire-and-forget uses like the existing keyboard shortcut,
but we will soon expose the functionality on DBus and consumers of that
API might very well need to access the file after the recording. So do
the same as our screenshot API and add an optional (out) parameter to
record().

Created attachment 243810 [details] [review]
shell-recorder: Support specifying the recorded area

Currently we will always record the entire screen. It has been requested
to support recording a specified area analogous to the screenshot API as
well, so add a set_area() method which allows this.

Created attachment 243811 [details] [review]
shell-recorder: Make drawing the cursor optional

As with screenshots, showing the cursor in a recording may not be
desirable, so add a property to control whether the cursor is drawn
or not.

Created attachment 243812 [details] [review]
sessionMode: Add 'allowScreencast' property

Our built-in screen recorder is implemented as a component, so it will
just be disabled when the session mode doesn't allow screencasting.
However we will expose screencasting functionality on DBus as well, and
while it makes sense to restrict its availablity to the same modes as
the existing recorder, exporting/unexporting the service depending on
the session mode is not very consumer friendly.
For that reason, add an additional 'allowScreencast' property that for now
mirrors the availability of the 'recorder' component.

Created attachment 243813 [details] [review]
Expose screencast functionality via DBus

Like screenshots, the screen recorder can be a useful tool in other cases
than being triggered by a keyboard shortcut. To account for that, export
a Screencast DBus API similar to the existing Screenshot interface.

Review of attachment 243810 [details] [review]:

OK.

Review of attachment 243811 [details] [review]:

OK.

Review of attachment 243809 [details] [review]:

OK.

Review of attachment 243812 [details] [review]:

OK.

Review of attachment 243813 [details] [review]:

OK.

Attachment 243809 [details] pushed as 3b95560 - shell-recorder: Optionally return the filename of the recording
Attachment 243810 [details] pushed as c61573a - shell-recorder: Support specifying the recorded area
Attachment 243811 [details] pushed as dc3082e - shell-recorder: Make drawing the cursor optional
Attachment 243812 [details] pushed as d44d00f - sessionMode: Add 'allowScreencast' property
Attachment 243813 [details] pushed as 24c5306 - Expose screencast functionality via DBus

Thank you for implementing this, would it be possible to get it to Fedora 19?

(In reply to comment #20)
> Thank you for implementing this, would it be possible to get it to Fedora 19?

It's on the gnome-3-8 branch, and there'll be a 3.8.2 release later today or early tomorrow (we still have some unlanded stuff on the wishlist). So yes :-)