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

[Tuomas Lukka]

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:
> > > ====================================================
> > > PEG vob_event_action--mudyc: A Vob, Event and Action 
> > > ====================================================
> > > ...
> > > Our framework still lacks of good way to create button and
> > > menu like objects. These objects are different than
> > > most other objects, since usually Vob doesn't know anything
> > > about events and events don't know anything about Vobs. 
> > > Now it's time to take care that vobs and events
> > > meet eachother in a way that selectable objects
> > > can be created.
> > > 
> > > 
> > > Issues
> > > ======
> > > 
> > > ..
> > > 
> > > Changes
> > > =======
> > > 
> > > 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?
> 
> 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?

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...

> > ISSUE: What should be the name for the vob that has the three button-like
> > states and an input to that?
> > 
> > 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?

> > 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?

> > > These three selections, `selection modes`, are represent with 
> > > three Vobs. Because of efficiency (reusing vobscene), 
> > > the select Vob is immutable and all three Vobs must be given 
> > > in constructor. The current `selection mode` is shown by one of the Vobs
> > > at the bottom and then placeable object is placed over it, i.e. text.
> > 
> > Umm, why "placed over it"?
> 
> In z-coordinates. Like painting same wall twice and the second time is 
> when placing the placeable. I don't know good words.

Yes, that I understood.

> > 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.

> > > Switching between `selection modes` is done with second 
> > > coordinate system since it's the only way to do it with immutable object.
> > > 
> > > I propose the following abstraction for select Vob: ::
> > 
> > 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?

Also, maybe you should make an interface out of it, not just an Abstract class?

        Tuomas