[Pipet Devel] loci] GMS

[Jarl van Katwijk]

| Hi Jarl!  It's good to hear from you.  I've been meaning to write to you
| since I saw the comment on Gnotices about GMS.  We (Loci) are talking with
| the Overflow people about a collaboration, and I thought perhaps GMS would
| like to join the party.


Hi again,
I've been searching a long time for similair projects and now there're two at once..
nice-n-sweet luxory. I've also checked out UML (mentioned on the news.gnome.org
discussion)
which has several interesting features. I recommend reading this, and in particulair
Booch.


>
> I just recenly rewrote the GUI to be an seperate application communicating trough
> Corba with the main engine, and the next phase is coding a better GUI.
> Now that I seem Loci I'm considering the possibilities of integrating the GUI into
> GMS. This will mean I have to port the python code to C.

| Hmmm.  I'm not sure what you mean by 'integrating the GUI'.  Are you
| interested in getting GMS to work with Loci's actual GUI, or are you looking
| to make something like it in C?
Yes and no.. a GUI for gms only needs to 'speak' to the CORBA api the 'core' exports
and must offer a corba api to the same core for displaying dialogs etc. (a gms
core-gui
couple has 2 corba communication lines) The speed and portability of C makes it a
good candidate, but probably Python will be good enough. As long as Python has good
gtk- and corba bindings.

> I want to know whether the Loci GUI is mainly finished, or should I wait till it's
> more mature,cq untill all planned features are done?

| The design/plan for the GUI is pretty well thought out.  We have only to put
| more of our ideas into code.  Again, what were you hoping to do?
I'm hoping it will be easy to rewrite the Loci gui to the gms ADM-DFP communication
api and to replace Loci's Class-system by gms's MO's. As you can see on the gms site
my gui is quite simple, it uses listing instead of a nice canvas window. But you
already got
the graphics and code done, I wanna use that part.

| (BTW, are you subscribed to this list?)
yes :)

| Jarl, looking at GMS, it appears you have accomplished much of what we haven't
| even touched yet: Developing an API for getting independent programs to talk
| nice to each other and the core.
Version 0.4.0pre6 (allmost done) will have the final plugin-registration API. I still

need to spend much more time into the security\authentication code though.

| On the other hand, we have been concentrating on developing a nice GUI plus an
| API for getting several different GUIs to talk to our core.
Hmm.. sounds tempting :)
I didn't got the opportunity to have a detailed look at your sources, will do this
evening.

| Perhaps we can merge projects.  Brad (who has been developing our core) would
| kill me if we had to scrap Loci's own core, but why don't we take a look at
| each other's designs and see where we can meet?
It sounds like the logical thing to do, but there seems to be one mayor disign diff.
between
the two projects: the system's objects. Gms uses a 'situation-oriented' object, every
object
stores\processes\filters\etc data, depending on the function\situation of the object.
Loci
seems to use a 'function-orientation' why of implementing objects, a 'special'
store-object,
etc.
Why did you choose this approach? Or am I totally wrong in the way I think Loci
works?


| As I mentioned, Python is written in C and has language bindings to it, so we
| may be able to make a Python wrapper for your core that will allow us to make
| Python interfaces.  And not just GUI interfaces: We were planning on making a
| natural language interface that will let the user 'talk' to Loci.
Ic. nice feature. What do you think about my idead to attach a GAP to GMS which is
using
the regulair GUI\client API but is in fact a engine which detects high fitness
structures
and applies those to other instances of gms tunning around the inet?
This would solve the biggest problem that Loci and gms will have once they reach
production
phase, which is that 'regulair' user wont be able to configure the dataflow-diagram,
it would
just be too complicated for them.

| A C core would be faster, which is an advantage to us.  And Python interfaces
| are easier to make than those in C, which would be an advantage to you.
| What do you think?  Again, Loci has a very well thought out design, but I
| think we may be able to reach a middle ground.
One thing: what are Loci's? Are they binairies, or scripts? GMS uses dynamic loadable

binairies, for speed reasons mainly.