Re: [Fenfire-dev] PEG vob_event_action--mudyc

[Matti Katila]

On Tue, 30 Sep 2003, Tuomas Lukka wrote:
> On Mon, Sep 29, 2003 at 09:55:55PM +0300, Matti Katila wrote:
> > On Mon, 29 Sep 2003, Tuomas Lukka wrote:
> > > On Fri, Sep 26, 2003 at 05:44:41PM +0300, Matti Katila wrote:
...
> > > > Create a new abstract Vob which can react to following events:
> > > > 
> > > >     1) select down(pre selection, event pressed but no released), 
> > > >     2) select up(no events, mostly this is the normal mode before 
> > > > events) 
> > > > and 
> > > >     3) selection selected(post selection, event pressed and released).
> > > 
> > > Are these standard terms? You might want to look at, e.g., swing to see
> > > what words are used there.
> > > 
> > > ISSUE: Should we support an inactive state?

I forgot to ask, what do you mean with inactive state? 

Inactive buttons makes you angry since they can not tell why can't them be 
used. Inactive is used in cases where something is already broken in UI 
level.

> > There are many terms used, like:
> >     - canceled, released, pressed, selected, deselected and armed.
> > I think normal, preSelect ant postSelect are good enough if these are the 
> > 3 possible states.
> 
> Sorry, I don't follow your reasoning there.  
> Are you saying that if we *a priori* decide there will be three, then
> these would be good, or what?
> 
> How about
> normal, highlighted, clicked?

Yes, what ever. Everyone would understand those you named.

> Actually, for highlighting, should we have a separate version of this?
> Namely, we want to highlight buoys that the mouse is on currently
> and this might be the right place to do that, too...

We can separate the selectable interface but...

There's no sense of highlight buoys because buoy is not 
GL.Renderable1JavaObject. There are no common semantics between button 
object and buoy object.

Ok, this is a problem which we need to solve.
 
> > > ISSUE: What should be the name for the vob that has the three button-like
> > > states and an input to that?

What you mean with input? Events or something else?

> > > How about "ButtonVob"? "ActiveButton"?
> > 
> > Actually in our system this is not that easy. Let's say we have found 
> > something from previous VobScene:
> > 
> > cs = prevVS.getCSAt(0, ev.x, ev.y, None)
> > key = prevVS.matcher.getKey(cs)
> > 
> > What should we do now when we have the object?
> > Of course we can say something like:
> > 
> > if isinstance(key, vob.vobs.Selectable):
> >     if ev.getId() == vob.mouse.MOUSE_PRESSED:
> >         key.setPreSelect()
> >     elif ev.getId() == vob.mouse.MouseMultiplexer.MOUSE_CLICKED:
> >         key.setPostSelect()
> >         key.performAction()
> > 
> > or
> > 
> > if isinstance(key, vob.vobs.Selectable):
> >     key.doWhatEverYouWant(ev)
> 
> I don't understand your answer. How it is related to the question?

As I said - "Houston we have a problem". What's the answer for:

   *Any visual object should be selectable*

We haven't solved this yet.

   At first you were talking about buttons and menu (or was it me?-)
   to be selectable. Now we have that everything should be selectable.

Currently there are no model for button and menu like objects.
Actually, "in some sense", there are no common model to any event -> 
action code in our code base.

For example, can you look at(cvs): vob/demo/mouse/mover.py, 
where I tried to use matching keys to put a moveable vob in vs.

> > > SelectVob is something I'd like to reserve to a lower-level construct
> > > that, on the C++ side, selects one of the given vobs based
> > > on a coordinate system.
> > > 
> > > You *are* separating these, aren't you?
> > 
> > I read this five times and I didn't undestand it. Can you say this with 
> > other words?
> 
> Sorry.
> 
> I meant this in connection with the name. The "SelectVob" is a name
> that should go to the low-level C++ thing that selects one of 
> the vobs, and the Java-level thing that takes button clicks and highlights
> things should maybe be something else?

Of course :)

> > > You might want to change the color of the text or whatever.
> > It would not be possible because of immutable object.
> > If this is something what is really needed I need to rethink this.
> 
> I meant: it might also make sense to generalize: have 3 state vobs and 
> then 1 "anystate" vob. Then it's customizable: if you want the color to 
> change, you just put the text into the state vob too.

Sorry, I don't understand. Perhaps we can continue this in irc.
 
> > > Why is this abstract? When you define an abstract class, there should
> > > be a clear idea of what the implementation should be like; I don't have
> > > a good idea now.
> > 
> > I do have it very clearly in my mind ;)
> > 
> > I think the problem is that you have a model in your head what's different 
> > than what I propose and can't say it with right words.
> 
> Well, can you give me examples of implementations of AbstractSelectVob?

It's in my tla tree ;)   vob/demo/mouse/mousemenu.py has example demo. 
 
> Also, maybe you should make an interface out of it, not just an 
> Abstract class?

Ok


   -Matti