fenfire-dev
[Top][All Lists]
Advanced

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

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


From: Tuomas Lukka
Subject: Re: [Fenfire-dev] PEG vob_event_action--mudyc
Date: Mon, 29 Sep 2003 11:32:00 +0300
User-agent: Mutt/1.5.4i

On Fri, Sep 26, 2003 at 05:44:41PM +0300, Matti Katila wrote:
> 
> ====================================================
> PEG vob_event_action--mudyc: A Vob, Event and Action 
> ====================================================
> 
> :Authors:  Matti J. Katila
> :Date-Created: 2003-09-08
> :Last-Modified: $Date: 2003/09/18 11:13:12 $
> :Revision: $Revision: 1.3 $
> :Status:   Current
> :Stakeholders: mudyc, tjl
> :Scope:    Minor
> :Type:     Architecture
> 
> 
> 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?

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

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?

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

You might want to change the color of the text or whatever.
You have to be careful not to lock anything too strictly in this abstraction.

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

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

        Tuomas




reply via email to

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