jessyink-team team mailing list archive

[Marc Eberhard <eberhardma@xxxxxxxxxxxxxx>]

Dear all!

2009/6/14 Hannes Hochreiner <hannes@xxxxxxxxxxxxxx>

> I merged Marc's branch with the current trunk and put the result in a new
> branch that is owned by the JessyInk team (so all of us should be able to
> commit to it). Since there is quite some new code in this branch, this will
> give us an opportunity to iron out the last few things before we merge it
> into the trunk.
>

Great!


> From what I tested so far, things work quite well. One thing I found is
> that the transformations of the views are not applied to the lines that are
> drawn on the slides, but then again I haven't yet reviewed the integration
> of the views with the new code at all.


Does that happen with my original branch or after the integration with the
new zoom feature?

The path is added to "original_element" and "element":

slides[activeSlide]["original_element"].appendChild(mouse_original_path);
slides[activeSlide]["element"].appendChild(mouse_presentation_path);

You seem to copy the content of "element" into "viewGroup" in the
initialisation code:

slides[counter]["viewGroup"] = node.appendChild(newGroup);

So maybe the mouse path needs to be added to "viewGroup" instead of
"element"? I only quickly looked at the diff of the two branches, I must
admit...

Otherwise the critical bit is probably:

function calcCoord(e)
{
        var svgPoint = document.documentElement.createSVGPoint();
        svgPoint.x = e.clientX + window.pageXOffset;
        svgPoint.y = e.clientY + window.pageYOffset;
        var matrix = slides[activeSlide]["element"].getScreenCTM();
                                                     ****************
        svgPoint = svgPoint.matrixTransform(matrix.inverse());
        return svgPoint;
}

This function is used to convert the reported mouse coordinates in the event
to document coordinates for updating the path. It uses getScreenCTM() on the
currently displayed slide, which might be the wrong reference point. Maybe
"viewGroup" would be the right reference here?

Also, it appears that these coordinates are not just numbers, but a
combination of a number and type of coodinate (px, mm, % or whatever SVG
reports). It is quite possible that the coordinates returned are not in the
same units as the document coordinates and thus might scale differently. I'm
by no means an expert in SVG coordinate systems, so this function should
probably undergo some scrutiny... I concentrated all the screen to document
coordinate transformations into this one function, so I suspect that this is
the place to look for problems.

Also, there a funny things happening with the progress bar on new slides.
> Anyways, nothing too serious.


What exactly is the problem? I didn't notice anything. Adding a slide is
obviously increasing the total number of slides by one and thus the length
of the progress bar will shrink from (screen width / number of slides) to
(screen width / (number of slides + 1)). The location of the progress bar
will also update to reflect the position of the new slide within the set. As
far as I can tell, it is working this way at least on my machine.

The location of the new branch is:
> lp:~jessyink-team/jessyink/branch_marc


I'm pretty busy at the moment, but I try to have a look at it later this
week.

All the best,
Marc