wish list

Peter Volgyesi xvolgy at isis-server.isis.vanderbilt.edu
Tue Dec 17 16:33:53 CST 2002



----------
From: 	Peter Volgyesi[SMTP:XVOLGY at ISIS-SERVER.ISIS.VANDERBILT.EDU]
Sent: 	Tuesday, December 17, 2002 9:33:53 AM
To: 	GME Group
Subject: 	Re: wish list
Auto forwarded by a Rule

> Is there some way to get cut and paste to work across different
> instances of GME? I understand that there might be issues there: like
> paradigm constraints; if the FCO being pasted in to the target paradigm
> is allowed to be there or not. Or, if we are pasting a reference, does
> the referred FCO get copied as well? If so where would it be placed in
> the target model? If not, then how do we let the user know that the
> reference he/she just pasted is empty and needs to point to something? I
> can imagine that there's a whole can of worms associated with this, but
> it will be a swell thing to have :-)
Recently, I worked on this part of the code (especially in the Browser). You
can drag'n'drop between two separate GME processes. (Maybe, CTRL-C, CTRL-V
does not work, I will have to check it). Only copy is allowed (since the
Move operation has a special semantics in the GME project, and it only works
"in-process"). You have to use the latest internal release.

> Second, is it possible to speed up the response of GME to an Ctrl+Z? The
> time taken apparently depends on the size of the model rather than the
> size of the change. I understand that if I move around a model that
> contains many other FCOs with connections to various other entities in
> the model, it's naturally going to take time to undo that: it just has
> lots more things to (un)do. But if within a nested model, I move around
> an atom not connected to anything (e.g. a CScript atom nested in a
> primitive) should it take as much time?
Well, I don't know too much about these layers in GME (Core). What I know,
is that in the upper layers (GUI, ActiveX controls) the components  do a
complete reset of their memory after an UNDO event. This is because the UNDO
event is not "incremental": you won't know what has been changed (back). So
the only thing you can do safely, is to reread the model database. This is
one reason of the slowliness. For deeper info ask Miklos.

--
peter



More information about the gme-users mailing list