| Thread Previous • Date Previous • Date Next • Thread Next |
Hi Marc,
>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?
From what I experienced, it only happened after the merge. But considering that until now I just did a straight merge, I was actually surprised that things still worked that well.
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...
I think that will solve most of the problems.
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.
Thanks for the pointers. I'll keep that in mind when I try to find the problem.
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.
Upps, I think that was my fault. I just didn't get the idea. I started with a presentation with only one slide and got a small rectangle in the right hand corner as the progress bar. Then I added a second slide and suddenly it was in the left corner on the second slide. With the addition of a third slide it filled the whole width of the screen when I changed to the second slide. But thinking about it again (and adding a fourth slide, it makes perfect sense. The small rectangles indicate the first and last slides (which you mentioned to me at some point were excluded from the calculation). The "real" progress bar only come into play starting with the third slide. Then of course it fills the whole screen, as it is the only slide that "counts". With the addition of a fourth slide, I see a bar filling the right half of the screen for the second slide and a bar filling the left side for the third slide. Exactly as I would expect. So the progress bar works fine.
Cheers, Hannes
| Thread Previous • Date Previous • Date Next • Thread Next |
