[Top][All Lists]

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

Re: [Fenfire-dev] Proposed change to VobCoorder.RenderInfo

From: Benja Fallenstein
Subject: Re: [Fenfire-dev] Proposed change to VobCoorder.RenderInfo
Date: Sat, 03 Jul 2004 14:26:18 +0200
User-agent: Mozilla Thunderbird 0.6 (X11/20040605)

Hash: SHA1

Matti Katila wrote:
| I think it would be nice if you could use your own branch and after
| audit merge. It's easy for me to get your changes and revert them with
| undo after audit if necessary. It's also easy to make a new branches. And
| of course it would be nice to get only the best changes in main branch.

It seems to me that having all those different branches leads to lots of
work on different branches that doesn't get integrated, and I don't like
that. That's also why I think it would be nicer to return to a more
CVS-like way of doing things, where auditing happens after the commit
and if it doesn't happen at least the new work is in the main repository...

And while it is easy to make new branches, I find it hard to get all
those branches on my system and make sense of them. E.g. I don't know
where you put the Berkeley DB work, and if it was on the main branch, I
might already have looked at it and finished it, but this way I think
"oh, I have to search for that branch and figure out how to get it and
that's going to be stupid boring work, so it's easier to just do some
other work..."

| For example the other can say simply that "please make the
| documentation more readable" or something. Because those are usually
| cases where we are lazy ;)
| And the most important point (for me, at least) is to get *feedback*.
| Please say if you don't like it =)

I understand your points, but in the best case these would still happen
if we commit to the main branch (reading the commits lists or posts to
the dev list) and in the worst case I'd rather have the un-audited work
on the main branch than having it forgotten on some branch...

Maybe I'm overreacting, but I'm really unhappy with the current
situation where I have my branches and you have yours and it seems like
a lot of work to me to pull them together and integrate them and where
that hasn't happened in the last few months.

| I think the change is ok because in AWT everything is basically just
| rectangles.


| Only one thing comes in mind, that is in some cases you want
| use rectangles "as stack". It's more easy to say an example with color
| Color putColorInStack = info1.getCurrentColor();
| info1.setCurrentColor(forThisRender);
| // draw something
| // and finally
| info1.setCurrentColor(putColorInStack);

This should read:

Color oldColor = g.getColor();
// ...

where g is a java.awt.Graphics object.

But I don't really understand in what kind of case you would do
something like this with rectangles, in a Vob... (except for clipping,
but clipping shouldn't be handled inside the vobs.)

| Where is that mysterious invert used?


| scaleXY are ok definitely (though text doesn't stretch with awt?).

It scales, but it doesn't stretch in the sense that if scaleX != scaleY,
the aspect ratio of the text doesn't change.

Tuomas wanted to have coordinate systems where X scales different from
Y, even though the text can't stretch like that. I think it may have
been because of the way he intended box coordinate systems to work;
since we have explicit 'box' coordinate systems now, I guess we could
also remove this and have only one scale parameter. What do you think?

|>I think that then, they should be replaced by the following two methods:
|>|    public int x(float px) { return (int)(x + scaleX*px); }
|>|    public int y(float py) { return (int)(y + scaleY*py); }
| ok

Actually, the xform methods aren't used like that (argh); rather, they
work like:

|    public int box_x(float px) { return (int)(x + scaleX*width*px); }
|    public int box_y(float py) { return (int)(y + scaleY*height*py); }

so you can use {box_x(.5), box_y(.5)} to get the middle of the box, etc.
SimpleConnection and PinStub use this.

So maybe we should have box_x() and box_y() rather than x() and y().

|>I also think that the inverse() function, which then is a pure
|>convenience function, isn't really needed and can be removed.
| What it does?

Basically, if we had inv_x() and inv_y() rather than inverse(), we would
have the following equations:

|    forall x. inv_x(box_x(x)) = x
|    forall y. inv_y(box_y(y)) = y

But since it isn't used anywhere, we can just remove it.

- - Benja
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


reply via email to

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