<?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: Update on scsolver</title>
	<atom:link href="http://kohei.us/2008/09/06/update-on-scsolver/feed/" rel="self" type="application/rss+xml" />
	<link>http://kohei.us/2008/09/06/update-on-scsolver/</link>
	<description>Kohei Yoshida's Webspace</description>
	<lastBuildDate>Thu, 26 Aug 2010 12:59:58 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Kohei Yoshida</title>
		<link>http://kohei.us/2008/09/06/update-on-scsolver/comment-page-1/#comment-8401</link>
		<dc:creator>Kohei Yoshida</dc:creator>
		<pubDate>Tue, 09 Sep 2008 12:59:25 +0000</pubDate>
		<guid isPermaLink="false">http://kohei.us/?p=220#comment-8401</guid>
		<description>Hi Niklas,

Yes, I&#039;m aware of that.  But even with all the quirks of the AWT API, I still believe writing the UI is a vital part of my Solver development so that I can control the interaction between the front- and back-ends freely, and extend the UI if I need to.  Besides, introducing a UNO layer between the UI and the algorithms makes it difficult for the back-end algorithms to interact with each other, which often is necessary especially when solving non-linear models.

Hopefully we can extend the AWT API in the future to give it more power and flexibility that the internal UI API enjoys today.  That, to me, is a step in the right direction.</description>
		<content:encoded><![CDATA[<p>Hi Niklas,</p>
<p>Yes, I&#8217;m aware of that.  But even with all the quirks of the AWT API, I still believe writing the UI is a vital part of my Solver development so that I can control the interaction between the front- and back-ends freely, and extend the UI if I need to.  Besides, introducing a UNO layer between the UI and the algorithms makes it difficult for the back-end algorithms to interact with each other, which often is necessary especially when solving non-linear models.</p>
<p>Hopefully we can extend the AWT API in the future to give it more power and flexibility that the internal UI API enjoys today.  That, to me, is a step in the right direction.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Niklas Nebel</title>
		<link>http://kohei.us/2008/09/06/update-on-scsolver/comment-page-1/#comment-8399</link>
		<dc:creator>Niklas Nebel</dc:creator>
		<pubDate>Tue, 09 Sep 2008 08:32:24 +0000</pubDate>
		<guid isPermaLink="false">http://kohei.us/?p=220#comment-8399</guid>
		<description>Did you know that there is a framework for solver components that removes the need for an own UI, also providing per-component options? The default solver is just one implementation of the Solver UNO service. You can use the framework and dialog without touching it.</description>
		<content:encoded><![CDATA[<p>Did you know that there is a framework for solver components that removes the need for an own UI, also providing per-component options? The default solver is just one implementation of the Solver UNO service. You can use the framework and dialog without touching it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
