Created attachment 139917 [details] [review]
Patch to parse _NET_WM_APP_CONTROLS ATOM

You will need to make a case for doing this, at least for two reasons:

1. There is no _NET_WM_APP_CONTROLS atom in the current EWMH spec. If this is intended for future version of the spec, then please include the proposed specification for this property; I have no idea what this is meant to be for, and neither seems to google.

2. From the patch, I do not see why the WM should care about this property. Is there some WM functionality that is to depend on it ? If it is just for something you want to do in the plugin that does not have direct bearing on window management per se, it should be done in the plugin, that's what the plugin is for.

On the patch itself, no g_print()s please; for any debugging output, we have a bunch of metacity specific functions.

Hey Tomas -

This is a patch I asked Dave to file here for work he's doing on a gnome-shell SOC project. We aren't really to land this in Mutter just yet - as you say it would have to be proposed as an EWMH addition, and some experience needs to gained with the user interface ... but I wanted some permanent place to be able to track the work.

As for what it does: the intent is to allow an application to expose information about it's different tabs to the window manager and allow direct switching to tabs through the window management interface. [There is also some idea that we might want to allow access to arbitrary "controls" that aren't tabs - like a "play" button a music player.] While certainly parsing such a property could be done outside of Mutter, I think (assuming standardization) it does make sense in Mutter for a couple of reasons:

 - Mutter has good infrastructure for property-on-a-window handling that would be considerably more work to replicate elsewhere
 - Different plugins would likely want to use this property - so it's code that we'd want to share

(In reply to comment #3)
>  - Mutter has good infrastructure for property-on-a-window handling that would
> be considerably more work to replicate elsewhere
>  - Different plugins would likely want to use this property - so it's code that
> we'd want to share

Cool, that makes sense, let's see where it leads.

Created attachment 139945 [details] [review]
Parse _NET_WM_APP_CONTROLS properties

- Removed trailing whitespace from the ends of lines
 - Fixed the commit message to say 'property' rather than 'atom'

The last patch is just your patch rebased to git master and with the commented small tweeks (somehow my git-bz tool messed up my comment a bit, need to debug that :-)

Created attachment 139968 [details] [review]
Rename AppAwareControlItem/Element to MetaAppControl..., move to a public header

We can't include a private header like window-private.h from a public
header like xprops.h, so move AppAwareControlItem and AppAwareControlElement
to the xprops.

Also rename them so they fit into the overall "Meta" namespace

Created attachment 139969 [details] [review]
Remove meta_prop_get_app_controls_with_atom_type()

The app controls property always has the type

 _NET_WM_APP_CONTROLS

So we don't need a separate public function to load it and look for
a different type.

Created attachment 139970 [details] [review]
Turn MetaAppControlElement into a flat list rather than a tree

The tree structure with MetaAppControl will be hard to access from
Javascript. Rather than having MetaAppControlElement have pointers
to other MetaAppControlElement, have integer indexes referring to
the child and next app control elements in a flat list.

Merge MetaAppControlElement and MetaAppControlItem together for
simplicity.

Created attachment 139971 [details] [review]
Add memory management for MetaAppControl

- Register MetaAppControl as a boxed type
- Add a function to free an array of meta_app_control and use that
  to free the app_controls of MetaWindow as appropriate.

Created attachment 139972 [details] [review]
Remove debug g_prints in app-controls code

Remove a debug g_print() and replace some others with a more
complete meta_verbose() dump of the new app controls set for
a window.

Created attachment 139973 [details] [review]
Create a separate app-control.h

In preparation for exposing a MetaAppControl getter on MetaWindow,
move MetaAppControl to a separate public header file. (xprops.h isn't
fully public - it's in the public header directory, but isn't scanned
as part of the build process for introspection data.)

Created attachment 139974 [details] [review]
Export meta_app_control_copy()/meta_app_control_free()

Make meta_app_control_copy() and free() public to easily allow constructing
or freeing a list of MetaAppControl from C code.

Created attachment 139975 [details] [review]
Add meta_window_get_app_controls() and a signal for change notification

Add a function to get the list of app controls for a window, and add
a signal that is emitted when the list of app controls changes.

The attached set of patches gets things to the point where you can:

 A) Get the list of "controls" for a MetaWindow from Javascript using window.get_app_controls()
 B) Get change notification when the set of controls changes by connecting to the 'app-controls-changed' signal

That should be sufficient to start trying to create a Javascript user interface.

To get a copy of mutter with all of the patches, the easiest thing to do is to use my 'git-bz' tool from:

 http://git.fishsoup.net/cgit/git-bz/plain/git-bz

Save that file to a place in your path (~/bin/ normally) and make it executable.

Then create a clean branch of mutter. In the mutter directory:

 git fetch # get the latest code
 git checkout -b app-controls origin/master # create a new branch & switch to it
 
 # Interactively apply all the patches attached here
 git bz apply http://bugzilla.gnome.org/show_bug.cgi?id=590787
 
I'll attach a tiny patch for gnome-shell here that just demonstrates how to use get_app_controls() - it doesn't to anything useful, but just dumps the app controls for each window as the window is added to the overlay.

Created attachment 139976 [details] [review]
Demo patch for gnome-shell

The patch that removes the g_prints seems to have missed one in reload_net_wm_app_controls(), and the patch adds the signal is referring to the wrong vfunction in the G_STRUCT_OFFSET() macro. Other than that, I am happy with this to be pushed.

Created attachment 140698 [details] [review]
Add meta_window_get_app_controls() and a signal for change notification

Add a function to get the list of app controls for a window, and add
a signal that is emitted when the list of app controls changes.

This is a patch from comment #14 rebased to the latest on master.

Created attachment 140810 [details] [review]
Adds a function to notify an app if we've selected a control

Created attachment 140811 [details] [review]
adds a ui to select tabs in the overlay

Created attachment 140813 [details]
a test application for _NET_WM_APP_CONTROL

This application makes an _NET_WM_APP_CONTROLS atom and changes the window title to match the tab selected via the window manager.

Just curious, are there any plans to push the Mutter part of this effort? Seems useful enough not to let it bit rot.

+1, please dont let this project die :(

With the GApplication's actions, is it still necessary to expose "controls" to the shell ?
It could instead activates a set of well-know actions for an application type ("open", "next-track" "pause"... for music players, "go-fullscreen"...). 
A set of those "standardized" action could be defined somewhere in a spec.

Regarding the tabs exposition in the alt-tab switcher, shouldn't that be done in a windowing system-agnostic way ?
ex, a Dbus interface exposed by Applications with:
- a method returning a set of pixmaps (or preferably a pointer/socket) (org.gnome.epiphany/MultiWindowed::getPixmaps or whatever)
- a method (or a GApplication action) parametrized with the id of the user-selected pixmap MultiWindowed::activate(pix_id). Then the client can switch to the right tab 

That would make the eventual switch to another windowing system (ie. Wayland) easier.

What's you opinion ?

Small video mockup demonstrating how ephy tabs could be integrated in switcher.
Need input from the design team, of course

http://people.igalia.com/amazari/ephy-tabs-in-switcher.webm

I'm going to assume _NET_WM_APP_CONTROLS is a bit dead in the water. If somebody really wants this feature, feel free to re-open (though it should be over D-Bus).