[Pipet Devel] updated model

[Konrad Hinsen]

> There are four classes of TULIP tools:
...
Looks good.

> I though Expect worked with stdio?  Doesn't it?  Thomas, you've worked with it
> quite a bit, right?  Am I wrong?

Expect goes beyond stdio, it simulates a Unix terminal. This is for
programs that don't simply read from stdio, but require more precise
control over input.

To give an example: telnet. You can't just write "telnet this.machine < text"
and expect the text to be sent as commands to another machine. But
you can do something similar with Expect.

> "We" is the key.  I don't want to modify every non-core tool myself.  I want
> something simple that the non-core tool authors can figure out.  I think we

Sounds good, but it means we have to convince them that they should
do it!

> agree that CORBA is about 10 times more difficult to implement than an I/O
> resembling HTML...Can anyone think of something simpler than HTML/XML?

Plain text, for simple cases. If some program needs nothing else than
a file name, for example, XML would be overkill.

> > Yes, as a worst case. Maybe we should keep the discussion more
> > pragmatic and consider specific examples for each case; if we
> > can't find an example, we might just as well forget about it...
> 
> Forget about what, the whole TULIP project or GUI's with no modifications? ;-)

Forget about the case for which we can't find an example!

> > Interactive manipulation is the hardest part... Lots of GUI programming...
> 
> Do you think we can use parts of the MMTK, and port it to GTK?

There's nothing to port, MMTK does not deal with user interfaces. MMTK
is just the library for the computational stuff. I'd like to see TULIP
evolve as a complement of MMTK. MMTK handles operations on
macromolecular structures, but there will be non-structural operations
as well, which should be implemented in a similar kind of low-level
library. And then there would be the end-user programs on top of all
that, which is where GTK comes into play. So TULIP would be both for
end users and for developers. Or perhaps it might be better to
separate these two tasks and use different names - but that's not an
urgent decision.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------