[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Matti Katila
Subject: Re: [Fenfire-dev] PEG vob_event_action--mudyc
Date: Mon, 29 Sep 2003 21:55:55 +0300 (EEST)

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.
> 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:
    elif ev.getId() == vob.mouse.MouseMultiplexer.MOUSE_CLICKED:


if isinstance(key, vob.vobs.Selectable):

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

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

> You have to be careful not to lock anything too strictly in this abstraction.

Hm, ok.
> > 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.

> >             public AbstractSelectVob(
> >         org.nongnu.libvob.lava.placeable.Placeable mask,
> >         Vob normalVob, Vob preSelectVob, Vob postActivatedVob)
> >         {
> >         this.mask = mask;
> >                 this.normal = normalVob;
> >             this.pre = preSelectVob;
> >             this.post = postActivatedVob;
> >         }
> Could you remove the implementation part from the PEG? The PEG is about
> the interface and the semantics and actual code makes it harder to read
> those.

Yeah, sure.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]