<?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: More CSS thoughts</title>
	<atom:link href="http://blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/</link>
	<description>"Many window managers are like Marshmallow Froot Loops; Metacity is like Cheerios."</description>
	<lastBuildDate>Sun, 26 Sep 2010 15:08:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Thomas Thurman</title>
		<link>http://blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/comment-page-1/#comment-1142</link>
		<dc:creator>Thomas Thurman</dc:creator>
		<pubDate>Thu, 29 Oct 2009 19:24:24 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=627#comment-1142</guid>
		<description>@Frans

I think that&#039;s an excellent idea.</description>
		<content:encoded><![CDATA[<p>@Frans</p>
<p>I think that&#8217;s an excellent idea.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Frans</title>
		<link>http://blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/comment-page-1/#comment-1140</link>
		<dc:creator>Frans</dc:creator>
		<pubDate>Thu, 22 Oct 2009 16:05:49 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=627#comment-1140</guid>
		<description>Have you thought of applying it to things other than window decoration as well? One thing that comes to mind (don&#039;t mind the ID names etc):

app-switcher.app-title {
display: list-item
}
app-switcher.app-title:before {
content: counter(app-number) &quot; &quot;;
counter-increment: app-number;
}</description>
		<content:encoded><![CDATA[<p>Have you thought of applying it to things other than window decoration as well? One thing that comes to mind (don&#8217;t mind the ID names etc):</p>
<p>app-switcher.app-title {<br />
display: list-item<br />
}<br />
app-switcher.app-title:before {<br />
content: counter(app-number) &#8221; &#8220;;<br />
counter-increment: app-number;<br />
}</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Apologia for CSS - …for the adult in you</title>
		<link>http://blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/comment-page-1/#comment-1082</link>
		<dc:creator>Apologia for CSS - …for the adult in you</dc:creator>
		<pubDate>Mon, 20 Jul 2009 19:06:33 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=627#comment-1082</guid>
		<description>[...] Some complain that the lists we gave of things we would need to ignore and things which would need to be added proved that there was a [...]</description>
		<content:encoded><![CDATA[<p>[...] Some complain that the lists we gave of things we would need to ignore and things which would need to be added proved that there was a [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Charles L</title>
		<link>http://blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/comment-page-1/#comment-1078</link>
		<dc:creator>Charles L</dc:creator>
		<pubDate>Mon, 20 Jul 2009 03:42:20 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=627#comment-1078</guid>
		<description>@Thomas

This is where CSS could really come into its own. You give the themes *complete* control, yet at the same time if the user wishes to force any particular element to have a certain style, that could still take precedence by using an (implicit?) !important on any of the settings.</description>
		<content:encoded><![CDATA[<p>@Thomas</p>
<p>This is where CSS could really come into its own. You give the themes *complete* control, yet at the same time if the user wishes to force any particular element to have a certain style, that could still take precedence by using an (implicit?) !important on any of the settings.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thomas Thurman</title>
		<link>http://blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/comment-page-1/#comment-1076</link>
		<dc:creator>Thomas Thurman</dc:creator>
		<pubDate>Sun, 19 Jul 2009 20:30:29 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=627#comment-1076</guid>
		<description>@Ray:

We need to find a balance between giving power to themes and giving power to users.  Some things should be under theme control and some under user control, but it&#039;s not trivial to decide which.  Here are some examples:

* Justification of the text on the titlebar.  Currently this is entirely under theme control; the user can&#039;t change it.  &lt;a href=&quot;http://blogs.gnome.org/metacity/2008/05/31/justifying-window-titles/&quot; rel=&quot;nofollow&quot;&gt;Some people would like this to change.&lt;/a&gt;

* The arrangement of buttons on the titlebar: which are on the left, which are on the right, and which aren&#039;t shown at all.  This is currently entirely under user control; the theme can&#039;t change it.  (This means that &lt;a href=&quot;http://www.gnome-look.org/content/show.php/OSX-Tiger+theme?content=56577&quot; rel=&quot;nofollow&quot;&gt;themes which attempt to look like OS X&lt;/a&gt; have to ask you to reorder your buttons so that close is on the left, since they can&#039;t do it themselves.)

* The font on the titlebar.  Currently this is entirely under user control; the theme can&#039;t change it.  This is something we&#039;d need to reexamine with a CSS theming engine.

It &lt;em&gt;may be&lt;/em&gt; true that windows should have a more flexible structure, and the ability to have the titlebar elsewhere is certainly &lt;a href=&quot;http://blogs.gnome.org/metacity/2008/12/28/the-letters-page/#comment-658&quot; rel=&quot;nofollow&quot;&gt;something that&#039;s been asked for&lt;/a&gt; from time to time.  But assuming we should add such abilities, should the decision to use them be made by the theme, or should it be something selectable by the user in the control panel?  These are deep questions.

I think this comment could become a separate post in itself.</description>
		<content:encoded><![CDATA[<p>@Ray:</p>
<p>We need to find a balance between giving power to themes and giving power to users.  Some things should be under theme control and some under user control, but it&#8217;s not trivial to decide which.  Here are some examples:</p>
<p>* Justification of the text on the titlebar.  Currently this is entirely under theme control; the user can&#8217;t change it.  <a href="http://blogs.gnome.org/metacity/2008/05/31/justifying-window-titles/" rel="nofollow">Some people would like this to change.</a></p>
<p>* The arrangement of buttons on the titlebar: which are on the left, which are on the right, and which aren&#8217;t shown at all.  This is currently entirely under user control; the theme can&#8217;t change it.  (This means that <a href="http://www.gnome-look.org/content/show.php/OSX-Tiger+theme?content=56577" rel="nofollow">themes which attempt to look like OS X</a> have to ask you to reorder your buttons so that close is on the left, since they can&#8217;t do it themselves.)</p>
<p>* The font on the titlebar.  Currently this is entirely under user control; the theme can&#8217;t change it.  This is something we&#8217;d need to reexamine with a CSS theming engine.</p>
<p>It <em>may be</em> true that windows should have a more flexible structure, and the ability to have the titlebar elsewhere is certainly <a href="http://blogs.gnome.org/metacity/2008/12/28/the-letters-page/#comment-658" rel="nofollow">something that&#8217;s been asked for</a> from time to time.  But assuming we should add such abilities, should the decision to use them be made by the theme, or should it be something selectable by the user in the control panel?  These are deep questions.</p>
<p>I think this comment could become a separate post in itself.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thomas Thurman</title>
		<link>http://blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/comment-page-1/#comment-1075</link>
		<dc:creator>Thomas Thurman</dc:creator>
		<pubDate>Sun, 19 Jul 2009 20:18:21 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=627#comment-1075</guid>
		<description>@Oliver:

I like that idea.  I can imagine a user stylesheet, for example, to turn off window decorations entirely for the Gimp:

titlebar[role&#124;=&quot;gimp&quot;] {
display: none;
}

I&#039;m not sure how generally useful this might be, but it&#039;s nifty that the design can support it so well.</description>
		<content:encoded><![CDATA[<p>@Oliver:</p>
<p>I like that idea.  I can imagine a user stylesheet, for example, to turn off window decorations entirely for the Gimp:</p>
<p>titlebar[role|="gimp"] {<br />
display: none;<br />
}</p>
<p>I&#8217;m not sure how generally useful this might be, but it&#8217;s nifty that the design can support it so well.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Olivier Samyn</title>
		<link>http://blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/comment-page-1/#comment-1074</link>
		<dc:creator>Olivier Samyn</dc:creator>
		<pubDate>Sun, 19 Jul 2009 20:05:53 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=627#comment-1074</guid>
		<description>&quot;There are no attributes on any element.  Attempts to select on attributes will fail.  The class is written as an attribute only for notational convenience: hence the italics.&quot;

And now I&#039;m thinking about adding a link to the whole window matching stuff. 
Shouldn&#039;t the window role or name be an attribute of the pseudo XML document, so that we may have different styling depending on some window attribute ? In fact, exposing WM and NET_WM properties as frame attributes will allow many customizations...</description>
		<content:encoded><![CDATA[<p>&#8220;There are no attributes on any element.  Attempts to select on attributes will fail.  The class is written as an attribute only for notational convenience: hence the italics.&#8221;</p>
<p>And now I&#8217;m thinking about adding a link to the whole window matching stuff.<br />
Shouldn&#8217;t the window role or name be an attribute of the pseudo XML document, so that we may have different styling depending on some window attribute ? In fact, exposing WM and NET_WM properties as frame attributes will allow many customizations&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: person</title>
		<link>http://blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/comment-page-1/#comment-1073</link>
		<dc:creator>person</dc:creator>
		<pubDate>Sun, 19 Jul 2009 18:05:19 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=627#comment-1073</guid>
		<description>While you may be wary of including a &quot;web browser&quot; into your code as a reflex, I&#039;d say you should give it deeper consideration and a real technical run-through.
Consider that webkit is fairly light and fast.
It&#039;s NOT a browser, it&#039;s a rendering engine which many browsers are built around. There are controls for it in several toolkits (ie qt, wxWidgets, gtk?) for brainless embedding into an application.
You get lots of raw power for free, there&#039;s no way it&#039;s going to be abandoned in the near or far future, and it should continue to serve you well into Mutter 2, 3 and beyond, no matter what features you need to add.</description>
		<content:encoded><![CDATA[<p>While you may be wary of including a &#8220;web browser&#8221; into your code as a reflex, I&#8217;d say you should give it deeper consideration and a real technical run-through.<br />
Consider that webkit is fairly light and fast.<br />
It&#8217;s NOT a browser, it&#8217;s a rendering engine which many browsers are built around. There are controls for it in several toolkits (ie qt, wxWidgets, gtk?) for brainless embedding into an application.<br />
You get lots of raw power for free, there&#8217;s no way it&#8217;s going to be abandoned in the near or far future, and it should continue to serve you well into Mutter 2, 3 and beyond, no matter what features you need to add.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: WebKit question &#171; ᛏᚦ</title>
		<link>http://blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/comment-page-1/#comment-1072</link>
		<dc:creator>WebKit question &#171; ᛏᚦ</dc:creator>
		<pubDate>Sun, 19 Jul 2009 15:12:24 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=627#comment-1072</guid>
		<description>[...] to my earlier post, there has been some more talk over at the Metacity blog about styling windows with CSS.  There seem to be a few possible ways to implement [...]</description>
		<content:encoded><![CDATA[<p>[...] to my earlier post, there has been some more talk over at the Metacity blog about styling windows with CSS.  There seem to be a few possible ways to implement [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jan Becvar</title>
		<link>http://blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/comment-page-1/#comment-1069</link>
		<dc:creator>Jan Becvar</dc:creator>
		<pubDate>Sun, 19 Jul 2009 10:56:01 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/metacity/?p=627#comment-1069</guid>
		<description>I&#039;m currently converting MiG Layout (http://www.miglayout.com/) to Vala/GObject system. It could be potentially used for declarative description of window layout (with constraints placed in CSS or in &quot;Document structure&quot;)...


Introducing MigLayout. The One Layout Manager to Rule Them All: http://www.javalobby.org/articles/miglayout/</description>
		<content:encoded><![CDATA[<p>I&#8217;m currently converting MiG Layout (<a href="http://www.miglayout.com/" rel="nofollow">http://www.miglayout.com/</a>) to Vala/GObject system. It could be potentially used for declarative description of window layout (with constraints placed in CSS or in &#8220;Document structure&#8221;)&#8230;</p>
<p>Introducing MigLayout. The One Layout Manager to Rule Them All: <a href="http://www.javalobby.org/articles/miglayout/" rel="nofollow">http://www.javalobby.org/articles/miglayout/</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- This Quick Cache file was built for (  blogs.gnome.org/metacity/2009/07/18/more-css-thoughts/feed/ ) in 0.19408 seconds, on Feb 10th, 2012 at 4:08 pm UTC. -->
<!-- This Quick Cache file will automatically expire ( and be re-built automatically ) on Feb 10th, 2012 at 5:08 pm UTC -->
