Re: [Fenfire-dev] PEG animation_api--mudyc: Animation Layer API

[Tuomas Lukka]

On Wed, Oct 22, 2003 at 12:38:32PM +0300, Matti Katila wrote:
> On Tue, 21 Oct 2003, Tuomas Lukka wrote:
> > On Sun, Oct 19, 2003 at 08:11:34PM +0300, Matti Katila wrote:
> > > I abandon this peg because of count of unresolved issues and the 
> > > misunderstanding of the idea between developers.
> ...
> > Please don't abandon it now - I do see it as a really worthwhile 
> > thing to do.  I know it can be difficult to reach understanding
> > of all the details of it, but it's important to do this to advance
> > the state of the APIs. And that's the reason we **have** PEGs: 
> > with all complicated systems, there *will* be lots of issues.
> > Nothing is as simple as anyone'd think it is. That's why the issues
> > need to be made explicit and discussed.
> > 
> > I'm really sorry if you've felt my tone being too adversarial in
> > this discussion: remember that for PEGs, the role of the others
> > is to be devil's advocate.
> 
> Hmm, my reason for abandoning was that I coudn't keep all the issues in my 
> hands anymore to enlarge the scope of the peg to fulfill the idea which (I 
> think) you were pushing it towards.

Ok, that's a valid reason but then you should have said so ;)

Because yes, we do need a new design there, no question.

> I still think that PEGs as any other programming product should be very 
> small "patches". That's the way to go to get stabel software.

Small "patches" for design are called "incremental refactorings".
I quite agree, that can work here.

On the other hand, this is a core API and it's good at the same time
to look above and below.

> > Even if I somewhat agree with something
> > but just have some doubts about some part of a thing, I must 
> > fight to get those doubts resolved instead of burying them.
> 
> I do understand this and it's not a problem for me. Problem is that
> I like small changes and I didn't have the whole picture of the api
> with all levels in issues.

Yes, and that's what the issues are for: for making sure everyone does
get the whole picture.

> Variables in the peg:
> 
> VobScene
> Windows
> Timing
> 
> I tried to keep the peg about what we currently see, i.e., 
> VobScene and 1 window because we have irregular edge.

Yes, and I quite agree to keeping e.g. timing and windows out of it.
This is exactly what you need to spell out in the PEG. What's
it's relation to other changes.

> If there's multiple windows there's multiple vobscenes and various 
> timings, urgh.

Well, the thing about multiple windows is that there's still only one user...
The timings can't be that different from the single-window case since the user
doesn't distinguish between looking at one window or two windows..

> So I didn't really find out how to keep all of animation parts
> *without* meddling with multiple windows.

Actually, you did that quite well, as the interface you propose
works well with a single window, and for more than one window we'd
have more instances of that API, right?

> Animation layers(in my view of point):
> 
> PEG's layer                    windows layer           low-level
> ----------------------------------------------------------------------        
>    
>  1 window and VobScene  --->   Multiple windows --->  UpdateManager
>  (timing will be added later?)   (+ timing?)                

Ok, I think I could well live with this; why don't you put this in the 
PEG as well and I think we could take it almost as it stands.

> Also, I think it was quite hard for others to understand this PEG and 
> interface because of it was not connected to any current interface. 
> Setting a new interface in the air is just a bit strange.

Yes, examples of its use would be really good. That's one of the main
problems I had with that PEG - I didn't really understand what
parts were to be done how.

> Either, I didn't find how AbstractUpdateManager method's would be hided if
> not all variables are used, i.e., multiple windows and problems with them.

If you propose this as an interface to allow *future* reorganization
of the UpdateManager layer, I'm all for it: it would give me more freedom
to muck about in there.

> Well, I think it's not right time to write howto and examples into
> the java-doc. I can do it separately when we publish libvob 1.0.

Examples should be in the PEG, definitely, and examples in a Javadoc
are never a bad idea. Which one would you rather read, one without examples
or one with examples?

> > 2) If there are problems (as with arch, or PEGs),
> > I really want to help change things so that they won't make you feel bad,
> 
> I see some problems with arch:
> 
> - I enjoy of reading other developers code (I'm still very trainee 
>   programmer). But reading it like old news isn't fun, so reading 
>   cvscommits doesn't help ;)  

Yes, I asked Tuukka if he could mod archbot to get diffs sent to a mailing
list immediately. Would that help?

>   Also, it would be good to say just in time:
>   "Hey, wait a minute - what does that code do? - document it, please" or
>   "Hmm, I think you have bug over there" or "Have you got nuts to commit 
>   that code?-)"

;) Heh, that's exactly why I wanted arch - so I can do this for the main 
address@hidden branch.

> - looking backward of the changes is not possible as easy as with cvs:
>  
> http://savannah.nongnu.org/cgi-bin/viewcvs/fenfire/fenfire/org/fenfire/Fen.java

Agreed - we do need that functionality. Arch is gaining popularity and I think
soon someone will make something like that, if not already.

There's the possibility of the version cache with linked files - a simple CGI
for diffing between them would do the trick. Tuukkah?

> - archbot should notice merges from mainline and not print them out.

If we always use the message "Merge", it's pretty easy to see. I'm not sure
if it would be good to add special code to archbot for that.

> > 3) The animation API is a good idea that just has a lot of details
> > to be worked out.
> 
> I try to think how can I represent it to other developers with 
> acceptance.

What you explained above already helps a lot. Say the same things in the PEG
itself, please ;)

        Tuomas