<?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: Squib of the day: named colours</title>
	<atom:link href="http://blogs.gnome.org/metacity/2009/03/27/squib-of-the-day-named-colours/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/metacity/2009/03/27/squib-of-the-day-named-colours/</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: Screwtape</title>
		<link>http://blogs.gnome.org/metacity/2009/03/27/squib-of-the-day-named-colours/comment-page-1/#comment-947</link>
		<dc:creator>Screwtape</dc:creator>
		<pubDate>Fri, 27 Mar 2009 03:38:10 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=548#comment-947</guid>
		<description>It&#039;s not really obvious exactly what the original bug filer wanted his Metacity themes to match. Matching various colours in the active GTK+ theme is &lt;a href=&quot;http://screwtape.jottit.com/colours_in_metacity_themes&quot; rel=&quot;nofollow&quot;&gt;pretty easy&lt;/a&gt;, although I don&#039;t believe you can access &lt;a href=&quot;http://live.gnome.org/GnomeArt/Tutorials/GtkThemes/SymbolicColors&quot; rel=&quot;nofollow&quot;&gt;GTK+ symbolic colours&lt;/a&gt; which might possibly be useful (I believe this is how the colour-pickers in Ubuntu&#039;s GTK theme editor work).

Alternatively, if the idea is to have multiple themes with the same base design and different accent colours, I think a better approach would be to add separate sub-theme files that allow colour-constants to be overridden. You could add a &#039;subtheme&#039; gconf key in parallel to the existing &#039;theme&#039; key, and older themes with no sub-themes would just ignore it. Likewise, older Metacity versions would ignore the sub-theme files in newer themes so compatibility would be preserved.

Another possibility is that this bug can be marked FIXED by the addition of colour constants to the V2 theme format - or even by the &quot;colorize&quot; attribute on the image draw_op.</description>
		<content:encoded><![CDATA[<p>It&#8217;s not really obvious exactly what the original bug filer wanted his Metacity themes to match. Matching various colours in the active GTK+ theme is <a href="http://screwtape.jottit.com/colours_in_metacity_themes" rel="nofollow">pretty easy</a>, although I don&#8217;t believe you can access <a href="http://live.gnome.org/GnomeArt/Tutorials/GtkThemes/SymbolicColors" rel="nofollow">GTK+ symbolic colours</a> which might possibly be useful (I believe this is how the colour-pickers in Ubuntu&#8217;s GTK theme editor work).</p>
<p>Alternatively, if the idea is to have multiple themes with the same base design and different accent colours, I think a better approach would be to add separate sub-theme files that allow colour-constants to be overridden. You could add a &#8217;subtheme&#8217; gconf key in parallel to the existing &#8216;theme&#8217; key, and older themes with no sub-themes would just ignore it. Likewise, older Metacity versions would ignore the sub-theme files in newer themes so compatibility would be preserved.</p>
<p>Another possibility is that this bug can be marked FIXED by the addition of colour constants to the V2 theme format &#8211; or even by the &#8220;colorize&#8221; attribute on the image draw_op.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
