<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"	>
<channel>
	<title>Comments on: Thought experiments: plugins</title>
	<atom:link href="http://blogs.gnome.org/metacity/2008/08/01/mostly-about-curry-in-fact/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/metacity/2008/08/01/mostly-about-curry-in-fact/</link>
	<description>"Many window managers are like Marshmallow Froot Loops; Metacity is like Cheerios."</description>
	<lastBuildDate>Sun, 08 Nov 2009 05:22:41 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Andy</title>
		<link>http://blogs.gnome.org/metacity/2008/08/01/mostly-about-curry-in-fact/comment-page-1/#comment-419</link>
		<dc:creator>Andy</dc:creator>
		<pubDate>Fri, 01 Aug 2008 14:40:59 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/2008/08/01/mostly-about-curry-in-fact/#comment-419</guid>
		<description>Oooh, I&#039;d never heard of XEmbed before. I&#039;ll have to read a bit about it and let it sink in for a while.</description>
		<content:encoded><![CDATA[<p>Oooh, I&#8217;d never heard of XEmbed before. I&#8217;ll have to read a bit about it and let it sink in for a while.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thomas Thurman</title>
		<link>http://blogs.gnome.org/metacity/2008/08/01/mostly-about-curry-in-fact/comment-page-1/#comment-418</link>
		<dc:creator>Thomas Thurman</dc:creator>
		<pubDate>Fri, 01 Aug 2008 14:36:11 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/2008/08/01/mostly-about-curry-in-fact/#comment-418</guid>
		<description>Andy:
That&#039;s an interesting idea; there was someone around here wanted to embed the entire panel a few months ago.  Actually, it could be done using &lt;a href=&quot;http://standards.freedesktop.org/xembed-spec/xembed-spec-0.5.html&quot; rel=&quot;nofollow&quot;&gt;XEmbed&lt;/a&gt;; it&#039;s rather out of the scope of this particular thought-experiment, though there&#039;s no reason it shouldn&#039;t be one of its own.</description>
		<content:encoded><![CDATA[<p>Andy:<br />
That&#8217;s an interesting idea; there was someone around here wanted to embed the entire panel a few months ago.  Actually, it could be done using <a href="http://standards.freedesktop.org/xembed-spec/xembed-spec-0.5.html" rel="nofollow">XEmbed</a>; it&#8217;s rather out of the scope of this particular thought-experiment, though there&#8217;s no reason it shouldn&#8217;t be one of its own.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Markus Weißbacher</title>
		<link>http://blogs.gnome.org/metacity/2008/08/01/mostly-about-curry-in-fact/comment-page-1/#comment-417</link>
		<dc:creator>Markus Weißbacher</dc:creator>
		<pubDate>Fri, 01 Aug 2008 11:40:40 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/2008/08/01/mostly-about-curry-in-fact/#comment-417</guid>
		<description>I&#039;m not sure how useful it were to the mere user to be able to suspend processes right out of metacity.

However I thought the time was right to propose the idea, since I read about the upcoming release 3.0 which would make some api changes in gtk, so anything would be messed up anyway.

You are right that additional features would enlarge the menu, but I don&#039;t think this would be annoying. You could try metisse to see a well overloaded menu.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not sure how useful it were to the mere user to be able to suspend processes right out of metacity.</p>
<p>However I thought the time was right to propose the idea, since I read about the upcoming release 3.0 which would make some api changes in gtk, so anything would be messed up anyway.</p>
<p>You are right that additional features would enlarge the menu, but I don&#8217;t think this would be annoying. You could try metisse to see a well overloaded menu.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andy</title>
		<link>http://blogs.gnome.org/metacity/2008/08/01/mostly-about-curry-in-fact/comment-page-1/#comment-416</link>
		<dc:creator>Andy</dc:creator>
		<pubDate>Fri, 01 Aug 2008 03:59:58 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/2008/08/01/mostly-about-curry-in-fact/#comment-416</guid>
		<description>This is something that has been in the back of my mind for a while. I was thinking about pulse audio and how it has volume sliders for each application, but the way to access this is through some other program. I was thinking that for most cases, it would be more convenient to have a volume slider attached to the actual window (obviously, this breaks if the program making the sound doesn&#039;t have a window).

I&#039;ve kind of left this idea in the back of my head to simmer for a while because I&#039;m not sure exactly which programs need to change. I was imagining that the window manager could expose some sort of api to let a widget library draw stuff in the decorations (which is a bit more than just adding a menu item - but at least for this use, the best solution would be to have a volume slider, which doesn&#039;t translate that well into a menu item). But I don&#039;t know enough about the architecture of the big names, and whether doing this sort of thing would require one of the components to bring a new dependency (which would probably need a bit more justification than just volume sliders :))

So, if while you are thinking about it, you could be thinking about this as a possibility, then it would be cool.</description>
		<content:encoded><![CDATA[<p>This is something that has been in the back of my mind for a while. I was thinking about pulse audio and how it has volume sliders for each application, but the way to access this is through some other program. I was thinking that for most cases, it would be more convenient to have a volume slider attached to the actual window (obviously, this breaks if the program making the sound doesn&#8217;t have a window).</p>
<p>I&#8217;ve kind of left this idea in the back of my head to simmer for a while because I&#8217;m not sure exactly which programs need to change. I was imagining that the window manager could expose some sort of api to let a widget library draw stuff in the decorations (which is a bit more than just adding a menu item &#8211; but at least for this use, the best solution would be to have a volume slider, which doesn&#8217;t translate that well into a menu item). But I don&#8217;t know enough about the architecture of the big names, and whether doing this sort of thing would require one of the components to bring a new dependency (which would probably need a bit more justification than just volume sliders :))</p>
<p>So, if while you are thinking about it, you could be thinking about this as a possibility, then it would be cool.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
