Re: [swarm-hackers] Re: Host platform dependence (was Naming conventions)

[Bill Northcott]

On 19/11/2009, at 2:03 PM, Scott Christley wrote:
> Okay, so I think I understand your point, and I agree with it to a certain 
> point.  Yes, I did a lot of work to separate the underlying scheduling 
> engine, what you are thinking of as the "model source" from the GUI.  This 
> has allowed Swarm to be exactly what you are suggesting with R, that is there 
> is a core Swarm model, and then there is an "integration piece" with that 
> Swarm model and the GUI.

Don't you hate this word 'model'.  It means all things to all people, and 
creates endless confusion.  In my discussion nothing in the Swarm library is 
part of the model.  The model is the code written by the modeller to model some 
reality she wants to investigate.  That model code should be written using only 
the Objective-C (or Java?) APIs documented in the Swarm reference manuals.  The 
implementation of those APIs is the Swarm library, the code for which is 
platform/GUI dependent, and may be any mishmash of tcl/tk, 
Openstep/Cocoa/Python/.Net or whatever

I am confused by your reference to 'integration piece.'  Is the integration 
part of the modeller's model or the Swarm Library? I really think the interface 
between the two needs to be clearly defined.
> 
> But one of your underlying assumptions is false, which is that the 
> "integration piece" required to use the tcl/tk/blt GUI is somehow very 
> similar to the "integration piece" required to use the OpenStep GUI.  That 
> just isn't true, in fact they are very different and it necessitates a 
> different interaction between a core Swarm model and the GUI.

Hence this does not makes sense to me.  I am certainly not assuming that the 
code within the Swarm library to implement the GUI Swarm APIs is in any way 
similar for tcl/tk/blt and Cocoa/Narrative.
> 
> Does that mean it prevents the core Swarm model (identical model source code) 
> from having both an OpenStep GUI and a tcl/tk/blt GUI?  Absolutely not, it 
> just means you have to write two "integration pieces", one for each GUI.

This also confuses me.  The modeller's model has neither a tcl/tk or OpenStep 
GUI.  If it a is a GUI model then it will create a Control Widget and if it 
defines probes, graphs or spaces these will create displays.  How that is done 
beneath the hood is not the concern of the modeller.
> 
> Now you do make the point about putting Cocoa code in the library which 
> supports standard Heatbugs model and etc.  I'm okay with that for some core 
> things like EZGraph, probes and etc.  But note that this still requires 
> writing two "integration pieces", they just happen to be provided by Swarm.  
> And this goes back to the point of how the two GUI have very different 
> interaction models, the current design of Swarm is based upon the tcl/tk/blt 
> interaction model, and that just may not be "doable" identically with 
> OpenStep.  It requires more study, but when I looked at this more carefully 
> in the past, I'm fairly confident that it would require significant changes, 
> i.e. its not possible to "squeeze" OpenStep into the tcl/tk/blt interaction 
> model.  This is why OpenStep Swarm is using multiple threads and a specific 
> interaction between the GUI and the model, etc.  That begs the question then 
> of what is the best design that can support multiple GUIs, not an easy 
> question.
> 
'
'Interaction models' : it is that word again.  Can we call this 'UI paradigm' 
or whatever to avoid confusion with the modeller's model?  The interaction 
between user and GUI at the level of control detail is not part of the model in 
my parlance.

> As for the point of core Swarm models *not* using Cocoa stuff.  Well in my 
> opinion that is purely up to the user.  If there is some cool, I need to use 
> API in Cocoa, and you are willing to give up using that model on Windows 
> under tcl/tk/blt or whatever, then go for it.  The purpose of Swarm isn't to 
> limit what people can do.  If users want to write a highly portable core 
> Swarm model, that can be easily done.

Of course any user can do what they like.  It is GPL code.  However, it greatly 
restricts communication if models produced by one modeller cannot be run by 
another.  We need to be able to write unambiguous documentation for modellers.  
What programmers think is cool, easily becomes a modellers confusing 
complication.

Cheers
Bill

smime.p7s
Description: S/MIME cryptographic signature