Hello barry,<br>We want screenshots! ^_^<br>Don&#39;t see if you saw my previous mail but i&#39;m really interested in your work because of the ipython1 compatibility + remote execution.<br>Here are two questions:<br>-Do you support ctrl+c (break in a loop)?<br>
-Do you support in loop stdout?:<br>I mean:<br>If (1):<br>&nbsp;&nbsp;&nbsp;&nbsp; print &quot;hello&quot;<br>Does it display lot of hello WHILE executing the loop?<br>-Do you support completion (althought it is not really important, &#39;cause must be easy no?)<br>
<br>If not, do you see any problem to implement this? I ask this because it was the hardest things i had to implement on my wx frontend.<br>And I want to be sure before switching ot ipython1 core not to loose these important features.<br>
<br>By the way, can you explain me difference between &#39;I wrote a delegate for the<br>
NSTextView&#39; and subclassing? (sorry)<br><br>Laurent<br><br><div class="gmail_quote">2008/6/5 Barry Wark &lt;<a href="mailto:barrywark@gmail.com">barrywark@gmail.com</a>&gt;:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br>
<br>
Following discussion of the last couple days, I thought I&#39;d update<br>
folks on the status of ipython1.frontend in the ipython1-cocoa branch.<br>
I&#39;ve made a first stab at the frontend.frontendbase module and have<br>
implemented a bare-bones Cocoa frontend for ipython1. I subclassed<br>
Cocoa&#39;s text view widget (well, actually I wrote a delegate for the<br>
NSTextView, but it could have been done as a subclass) and also<br>
subclassed frontend.frontendbase.FrontEndBase. Besides the code to<br>
handle the appropriate events/text layout etc. which are specific to<br>
Cocoa, my Cocoa frontend required about 200 lines of code. I think<br>
it&#39;s a pretty good start for similar endeavors in Qt or Wx etc.<br>
<br>
One issue that&#39;s come up is that the deferred result<br>
ipython1.kernel.engineservice.EngineService.execute has a string<br>
representation of the block&#39;s output (in result[&#39;display&#39;][&#39;pprint&#39;]),<br>
but there&#39;s no way to get the actual python object that generated that<br>
string. This prevents the frontend from e.g. rendering an image result<br>
inline. I realize this is because the engine may be remote, but in the<br>
case of (1) serializeable objects or (2) local engines, it seems that<br>
we might want to add an option to execute to return the actual result<br>
as well as its pprint/repr...<br>
<br>
Barry<br>
_______________________________________________<br>
IPython-user mailing list<br>
<a href="mailto:IPython-user@scipy.org">IPython-user@scipy.org</a><br>
<a href="http://lists.ipython.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://lists.ipython.scipy.org/mailman/listinfo/ipython-user</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Laurent Dufrechou<br>Hardware Engineering<br><br>Marport<br>16 Blv Abbé Louis LE CAM<br>56100 Lorient<br><br>Tél : +33(0)635028304<br>Fax : +33(0)297884812