GNOME Bugzilla – Bug 613123
Framework for plugin-specific per-window hints
Last modified: 2010-05-14 11:23:37 UTC
Created attachment 156338 [details] [review] Patch for _MUTTER_HINTS property We found it useful in Moblin/MeeGo to facilitate custom per-window hints to allow applications to override some of the Moblin specific idioms, such as the automatic workspace creation; such hints are generally fairly experimental and idiosyncratic (e.g., not something you would want to be adding to the EWMH spec). The attached patch takes advantage of the neat Mutter infrastructure for dealing with properties, by adding a string property _MUTTER_HINTS which a plugin can use at will. Not sure whether something like this could be useful also for Gnome Shell; the Moblin patch is attached, see what you think.
Hmm, I think we either: * Need to define the contents of _MUTTER_HINTS in a way that can be shared (e.g., it's a list of keyvalue pairs with the keys namespaced "-meego-share-workspace=true...") * Instead of this allow plugins to create their own hints with their own definition of the contents. I don't think having _MUTTER_HINTS with unspecified contents really makes sense.
(In reply to comment #1) > Hmm, I think we either: > > * Need to define the contents of _MUTTER_HINTS in a way that can be shared > (e.g., it's a list of keyvalue pairs with the keys namespaced > "-meego-share-workspace=true...") I was thinking doing it along these lines; in Meego I use a colon separated list of key=value pairs, where the key currently starts with 'moblin-' prefix.
Review of attachment 156338 [details] [review]: With documentation of the format I think this is OK to land. Possibly if it is key/value, it really should be 'hint = meta_window_get_mutter_hint(window, key)', so we have unescaping logic in just one place, but not a blocker. ::: src/core/window-props.c @@ +529,3 @@ + gboolean initial) +{ + if (value->type != META_PROP_VALUE_INVALID) This doesn't properly handle the property being deleted. (Some of the other properties also have this issue, but they are usually for things like NET_WM_PID which are supposed to be set before map and left unchanged. Since mutter-hints is entirely unspecified, we can't assume that this will be the case for it.) @@ +1566,3 @@ { display->atom__NET_WM_STRUT, META_PROP_VALUE_INVALID, reload_struts, FALSE, FALSE }, { display->atom__NET_WM_STRUT_PARTIAL, META_PROP_VALUE_INVALID, reload_struts, FALSE, FALSE }, + { display->atom__MUTTER_HINTS, META_PROP_VALUE_TEXT_PROPERTY, reload_mutter_hints, TRUE, FALSE }, Since init is TRUE, this should be sorted higher - you'll notice that all the initially loaded properties come first. (Doesn't really matter that much, but keeping it tidy.) Do you really want override-redirect=false here? could mutter-hints also include compositor-only hints? ::: src/core/window.c @@ +231,3 @@ break; + case PROP_MUTTER_HINTS: + g_value_set_string (value, win->title); Typo - you mean win->mutter_hints. @@ +357,3 @@ + g_param_spec_string ("mutter-hints", + "_MUTTER_HINTS", + "_MUTTER_HINTS for this window", Maybe "Contents of the _MUTTER_HINTS property of this window" @@ +9102,3 @@ + * @window: a #MetaWindow + * + * Returns the current value of the _MUTTER_HINTS property. Needs to have a "Return value:" line as well for the doc comment. (Usually I say "Gets" rather than "Returns" for description since gtk-doc used to choke on descriptions with Returns in them.) The Return value: description should mention that it returns %NULL if no hints have been set on the window. Somewhere you need to document the format of _MUTTER_HINTS and the need for namespacing, this is probably as good as any.
The version of this patch that you attached to bug 613127 looks fine to commit to me.
(In reply to comment #4) > The version of this patch that you attached to bug 613127 looks fine to commit > to me. uh, sorry about that; committed as 28767c4d344ff61215a1b415e005cbfd20aee98c.