<?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: On enhancements which need changes to the EWMH</title>
	<atom:link href="http://blogs.gnome.org/metacity/2009/03/16/ewmh/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/metacity/2009/03/16/ewmh/</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.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Bug of the day: maximise across windows - …for the adult in you</title>
		<link>http://blogs.gnome.org/metacity/2009/03/16/ewmh/comment-page-1/#comment-936</link>
		<dc:creator>Bug of the day: maximise across windows - …for the adult in you</dc:creator>
		<pubDate>Mon, 23 Mar 2009 00:05:07 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=497#comment-936</guid>
		<description>[...] this is a new window state, it would require a change to the EWMH, which makes it [...]</description>
		<content:encoded><![CDATA[<p>[...] this is a new window state, it would require a change to the EWMH, which makes it [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Squib of the day: Window paths - …for the adult in you</title>
		<link>http://blogs.gnome.org/metacity/2009/03/16/ewmh/comment-page-1/#comment-929</link>
		<dc:creator>Squib of the day: Window paths - …for the adult in you</dc:creator>
		<pubDate>Fri, 20 Mar 2009 00:02:30 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=497#comment-929</guid>
		<description>[...] This would require a new window hint in order to work. It would replicate behaviour that is generally the province of toolbars and appears to have WONTFIX written all over it. [...]</description>
		<content:encoded><![CDATA[<p>[...] This would require a new window hint in order to work. It would replicate behaviour that is generally the province of toolbars and appears to have WONTFIX written all over it. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ka-Hing Cheung</title>
		<link>http://blogs.gnome.org/metacity/2009/03/16/ewmh/comment-page-1/#comment-913</link>
		<dc:creator>Ka-Hing Cheung</dc:creator>
		<pubDate>Mon, 16 Mar 2009 22:39:17 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=497#comment-913</guid>
		<description>I still don&#039;t see why drag and drop requires that the drag not to raise the source window.

Either way you have 2 windows, the current behavior is that the source window is raised which may obscure the target window, so to make it work you need to make sure even with the source window on top, the drop target is still visible. Or that you can somehow get the target window to raise after the drag has been initiated [1].

Suppose a EWMH flag is added so that the drag no longer raises the source window, how will one perform a drag and drop operation then? The only time this flag is useful is when the target window is on above the source window already, which means the drag source cannot be obscured by target window.

So adding the flag changes the requirement from:

a) the drop target cannot be obscured by the source window

to:

b) the drag source cannot be obscured by the target window

And I just don&#039;t see how b) is better than a).

[1]: currently you can do that by dragging it to the window list, which will raise the target window. It&#039;s unfortunate that normal keyboard shortcuts like alt-tab (and other workspace switching shortcuts too) don&#039;t work after a drag has been initiated.</description>
		<content:encoded><![CDATA[<p>I still don&#8217;t see why drag and drop requires that the drag not to raise the source window.</p>
<p>Either way you have 2 windows, the current behavior is that the source window is raised which may obscure the target window, so to make it work you need to make sure even with the source window on top, the drop target is still visible. Or that you can somehow get the target window to raise after the drag has been initiated [1].</p>
<p>Suppose a EWMH flag is added so that the drag no longer raises the source window, how will one perform a drag and drop operation then? The only time this flag is useful is when the target window is on above the source window already, which means the drag source cannot be obscured by target window.</p>
<p>So adding the flag changes the requirement from:</p>
<p>a) the drop target cannot be obscured by the source window</p>
<p>to:</p>
<p>b) the drag source cannot be obscured by the target window</p>
<p>And I just don&#8217;t see how b) is better than a).</p>
<p>[1]: currently you can do that by dragging it to the window list, which will raise the target window. It&#8217;s unfortunate that normal keyboard shortcuts like alt-tab (and other workspace switching shortcuts too) don&#8217;t work after a drag has been initiated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Squib of the day: Drag and drop should work properly - …for the adult in you</title>
		<link>http://blogs.gnome.org/metacity/2009/03/16/ewmh/comment-page-1/#comment-912</link>
		<dc:creator>Squib of the day: Drag and drop should work properly - …for the adult in you</dc:creator>
		<pubDate>Mon, 16 Mar 2009 03:03:04 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=497#comment-912</guid>
		<description>[...] correct answer is fixing this in the EWMH.  Luboš had an idea about this back in 2004 called _NET_WM_TAKE_ACTIVITY, and Elijah improved on [...]</description>
		<content:encoded><![CDATA[<p>[...] correct answer is fixing this in the EWMH.  Luboš had an idea about this back in 2004 called _NET_WM_TAKE_ACTIVITY, and Elijah improved on [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Squib of the day: Special frame style for warning dialogues - …for the adult in you</title>
		<link>http://blogs.gnome.org/metacity/2009/03/16/ewmh/comment-page-1/#comment-911</link>
		<dc:creator>Squib of the day: Special frame style for warning dialogues - …for the adult in you</dc:creator>
		<pubDate>Mon, 16 Mar 2009 03:02:12 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=497#comment-911</guid>
		<description>[...] …for the adult in you &#8220;Many window managers are like Marshmallow Froot Loops; Metacity is like Cheerios.&#8221;   Skip to content      &#171; Squib of the Day: Maximise to the edge of the screen On enhancements which need changes to the EWMH &#187; [...]</description>
		<content:encoded><![CDATA[<p>[...] …for the adult in you &#8220;Many window managers are like Marshmallow Froot Loops; Metacity is like Cheerios.&#8221;   Skip to content      &laquo; Squib of the Day: Maximise to the edge of the screen On enhancements which need changes to the EWMH &raquo; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dragging the window icon - …for the adult in you</title>
		<link>http://blogs.gnome.org/metacity/2009/03/16/ewmh/comment-page-1/#comment-910</link>
		<dc:creator>Dragging the window icon - …for the adult in you</dc:creator>
		<pubDate>Mon, 16 Mar 2009 02:58:48 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=497#comment-910</guid>
		<description>[...] other things, but the actual content is the business of the application.  So you need to invent a way for the WM to tell the application that a drag is happening, and for the application to tell the WM what the data [...]</description>
		<content:encoded><![CDATA[<p>[...] other things, but the actual content is the business of the application.  So you need to invent a way for the WM to tell the application that a drag is happening, and for the application to tell the WM what the data [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
