[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:
key.setPreSelect()
elif ev.getId() == vob.mouse.MouseMultiplexer.MOUSE_CLICKED:
key.setPostSelect()
key.performAction()
or
if isinstance(key, vob.vobs.Selectable):
key.doWhatEverYouWant(ev)
> 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.
-Matti