<div><div></div><div class="h5">On Thu, Sep 9, 2010 at 5:32 PM, MinRK &lt;<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Sep 9, 2010 at 17:21, Evan Patterson &lt;<a href="mailto:epatters@enthought.com">epatters@enthought.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Thu, Sep 9, 2010 at 3:58 PM, MinRK &lt;<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; Hello,<br>
&gt;&gt; &gt; In order to connect a second ipythonqt frontend to an existing kernel, I<br>
&gt;&gt; &gt; must specify by hand all 4 ports at the command-line. This really<br>
&gt;&gt; &gt; shouldn&#39;t<br>
&gt;&gt; &gt; be the case, especially since the default behavior is to have the ports<br>
&gt;&gt; &gt; ordered sequentially.<br>
&gt;&gt;<br>
&gt;&gt; That may be the default behavior of your OS, but that&#39;s not the<br>
&gt;&gt; default behavior in general. Random port is selection is currently<br>
&gt;&gt; left entirely up to the OS (as it should be), and on some systems this<br>
&gt;&gt; means that you get ports that appear to be totally random.<br>
&gt;<br>
&gt; Good point, that makes a two-stage connect even more important, since you<br>
&gt; can&#39;t expect the relationship between the port numbers to be well behaved.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; Guaranteeing that the ports are in consecutive order requires ugly<br>
&gt;&gt; code (a while loop that keeps binding a port until you find one that<br>
&gt;&gt; has three consecutive ports that are also open). Frankly, I think that<br>
&gt;&gt; if you care what the ports are, you should just pass them when<br>
&gt;&gt; launching the kernel in the first place.<br>
&gt;<br>
&gt; The problem is not that I care what the ports are, quite the opposite. I<br>
&gt; don&#39;t want to care what the ports are, but the current state requires me to<br>
&gt; track a new set of 4 every time. This is quite unpleasant for launching<br>
&gt; multiple clients on a kernel, in addition to being unnecessary.<br>
&gt; It should be very easy to connect additional clients to a running kernel,<br>
&gt; and specifying every port by hand does not qualify.<br>
&gt; $&gt; ipythonqt -e<br>
&gt; should successfully connect to a kernel started with:<br>
&gt; $&gt; ipythonqt<br>
&gt; At the _very worst_, a single port (or file) should have to be specified to<br>
&gt; connect to a kernel launched with defaults.<br>
&gt; This can be done, as it was in Twisted code, via a file in IPYTHON_DIR, or<br>
&gt; even better with a two-stage connect.<br>
<br>
</div></div>I see your point; something does have to be done about this. That<br>
being said, it&#39;s important to keep in mind that ipythonqt is currently<br>
not so much an application as a tech demo, so there are definitely<br>
some usability issues to be worked out. The Qt widget itself is<br>
becoming fairly polished, but the application needs some work.<br></blockquote><div><br></div><div>Certainly, this sort of thing falls in priority well behind polishing the already super cool qtwidget functionality (well done on that, by the way). I just noticed that it requires more information than it should when I tried testing using raw_input with multiple clients, and I had to tyep it out several times, since the current raw_input is sufficiently broken that I had to start many fresh frontends, rather than just killing the kernel.</div>