<?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/"
		>
<channel>
	<title>Comments on: Qt and the LGPL</title>
	<atom:link href="http://www.alexhudson.com/2009/01/18/qt-and-the-lgpl/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.alexhudson.com/2009/01/18/qt-and-the-lgpl/</link>
	<description>world of alex hudson</description>
	<lastBuildDate>Tue, 11 Oct 2011 19:36:44 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Alex</title>
		<link>http://www.alexhudson.com/2009/01/18/qt-and-the-lgpl/comment-page-1/#comment-26</link>
		<dc:creator>Alex</dc:creator>
		<pubDate>Mon, 19 Jan 2009 09:28:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.alexhudson.com/blog/?p=148#comment-26</guid>
		<description>Hi John, I appreciate your comments. You&#039;re absolutely right, of course, in that the sentiments expressed above are very much an &quot;ideal world&quot;, and there would be issues like look and feel. Something generic would probably end up kind of wxWidgety, but my feeling was more that for many apps the set of widget features you&#039;d be using would be that kind of subset.

HTML is interesting, but also has its problems - mainly that you can&#039;t easily &quot;push&quot; stuff to an HTML interface. As an example, I have a Gtk+ app I worked on which had some audio controls including a live volume meter: implementing that in HTML would be a nightmare. I think there are also various layout issues which make HTML less than ideal in many ways.

I do think there is a lot of interesting mileage in widget sets though, in terms of innovation: with stuff like Clutter appearing, it&#039;s clear that it&#039;s not a &quot;done deal&quot; by any means.</description>
		<content:encoded><![CDATA[<p>Hi John, I appreciate your comments. You&#8217;re absolutely right, of course, in that the sentiments expressed above are very much an &#8220;ideal world&#8221;, and there would be issues like look and feel. Something generic would probably end up kind of wxWidgety, but my feeling was more that for many apps the set of widget features you&#8217;d be using would be that kind of subset.</p>
<p>HTML is interesting, but also has its problems &#8211; mainly that you can&#8217;t easily &#8220;push&#8221; stuff to an HTML interface. As an example, I have a Gtk+ app I worked on which had some audio controls including a live volume meter: implementing that in HTML would be a nightmare. I think there are also various layout issues which make HTML less than ideal in many ways.</p>
<p>I do think there is a lot of interesting mileage in widget sets though, in terms of innovation: with stuff like Clutter appearing, it&#8217;s clear that it&#8217;s not a &#8220;done deal&#8221; by any means.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John (J5) Palmieri</title>
		<link>http://www.alexhudson.com/2009/01/18/qt-and-the-lgpl/comment-page-1/#comment-24</link>
		<dc:creator>John (J5) Palmieri</dc:creator>
		<pubDate>Mon, 19 Jan 2009 04:15:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.alexhudson.com/blog/?p=148#comment-24</guid>
		<description>I saw your post through the pingback on my site.  Just to be devils advocate here, the reason you wouldn&#039;t want to abstract away details of the toolkit is that you lose the cohesiveness that made each toolkit useful in the first place.  Basically each toolkit developer had a goal in mind and the look and feel basically came out of that goal.  Abstracting it away means that you are throwing away all the things that made that toolkit useful.  You might as well choose one at that point.  Put it this way, Java has a GTK look and feel module, you can still tell it is a Swing app.  You can configure GTK+ to look like the mac, it still feels like GTK+. So a toolkit is much more than just the code that runs, it is the philosophy of how applications should be developed which in turn translates into the look and feel of those applications that is very hard to duplicate.

If we want to get rid of the duplication everyone is going to have to agree on a look and feel goal.  Even in that highly unlikely scenario I doubt Qt is the answer.  In fact toolkits are quickly becoming obsolete by a standard that everyone already uses - HTML.  But that is another blog post for sometime in the future.</description>
		<content:encoded><![CDATA[<p>I saw your post through the pingback on my site.  Just to be devils advocate here, the reason you wouldn&#8217;t want to abstract away details of the toolkit is that you lose the cohesiveness that made each toolkit useful in the first place.  Basically each toolkit developer had a goal in mind and the look and feel basically came out of that goal.  Abstracting it away means that you are throwing away all the things that made that toolkit useful.  You might as well choose one at that point.  Put it this way, Java has a GTK look and feel module, you can still tell it is a Swing app.  You can configure GTK+ to look like the mac, it still feels like GTK+. So a toolkit is much more than just the code that runs, it is the philosophy of how applications should be developed which in turn translates into the look and feel of those applications that is very hard to duplicate.</p>
<p>If we want to get rid of the duplication everyone is going to have to agree on a look and feel goal.  Even in that highly unlikely scenario I doubt Qt is the answer.  In fact toolkits are quickly becoming obsolete by a standard that everyone already uses &#8211; HTML.  But that is another blog post for sometime in the future.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

