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: Tue, 30 Sep 2003 12:23:54 +0300
User-agent: Mutt/1.5.4i

On Tue, Sep 30, 2003 at 11:30:12AM +0300, Matti Katila wrote:
> 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? 

Grayed out.

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

Supporting something that's a bad idea doesn't mean that it should be used.
But the decision should be the programmer's...

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

Yes there are. There's the semantics of:

- when the mouse is over it, it should look active
- when the mouse is not over it, it should not look active

> Ok, this is a problem which we need to solve.

I'd see it done as putting the conditional into the irregu rendering,
changing the edge color.

So yes, this is somethign where flexibility is needed.

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

Yes, events. Or something else ;)

The user-level thing.

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

Yes, after I realized that actually what we have is a chance to solve
the more general problem we've outlined for future evolution of FenPDF.
If we can solve the general problem and buttons and menus fall out of that
gracefully, it'd be *great*.

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

Too much code to read without comments for it to be an enlightening example, 
sorry.
Could you put in comments as to what the actual responsibilities of each object 
are?

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

Any time.

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

No, not concretely but explain in two sentences how that implementation 
specializes
the class.

        Tuomas




reply via email to

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