[SciPy-user] Thoughts on GUI development

[Peter Wang]

On Aug 22, 2008, at 5:43 PM, Gael Varoquaux wrote:

> On Fri, Aug 22, 2008 at 04:12:24PM -0400, Barry Wark wrote:
>> I think what Stef is getting at is that effective scientific software
>> may need to match its user model to the user's world model. In other
>> words, the "workflow" matters. If the software requires the user
>> (scientist/engineer/etc.) to deal with data or process in a different
>> order than the order implied by their experiment, the software is not
>> as good as it could be. In my view, this is why we build UIs--so that
>> we can match the software model to the user's model such that the
>> software is "invisible" to the user in doing their work. I contend
>> that it is a rare case when a CLI interface is the *best* fit to the
>> user's world model.
>
> I agree, but I was talking about a CLI interface, not a notebook, or
> something else, and I guess my point was that if you go in GUIs, you
> should should get more than a nice-looking terminal, eg Matlab,  
> scilab.

This point cannot be stressed enough.  For scientific or engineering  
users, one of the major workflows *is* data exploration.  Although  
writing expressions and small procedural logic blocks is a fairly  
reasonable fit for some of that exploration, I think people stick to  
it out of habit.  Some scientists like to make fun of "business" users  
that do crazy, complex things in Excel, but we should make sure that  
the python/ipython/matlab/mathematica/ prompt does not become our  
little Excel. :)

In my mind, the purpose of integrating a command-line prompt with the  
GUI is to provide that familiar exploratory interface while at the  
same time providing nice visual interfaces for things that actually  
*do* have workflow to them.  Furthermore, if the data and object  
models behind the exploratory interface are easy to turn into a more  
workflow-oriented interface for non-expert users, then the entire lab  
benefits from this sharing of expertise.  It's a lofty and a difficult  
goal, but I think it's the right way to interface GUIs with something  
as creative and open-ended as scientific analysis.

> I am currently struggling with trying to define what is my model,  
> what is
> my view, what should sit where, ie how many processes we want. I am  
> now
> convinced that for a robust and powerful IDE with Python, we want  
> several
> processes communicating together. For instance, I think that the  
> editor,
> may it be written in Python, and not emacs or vim, or eclipse,  
> should be
> sitting in a different process, so that the calculation does not block
> the editor, nor crashes it.

It's not clear to me why you want "several processes communicating  
together".  Ease of coding (i.e. avoiding nasty multithreading  
issues)?  The GIL?  It's not obvious to me why the choice of Python  
over, say, C++ changes the decision making process here.  If I were  
tasked with writing a C++ IDE, my first inclination would be to avoid  
multi-process as much as possible...


-Peter