xbl zoom and pan controls
Alex Fritze
news:aji0lo$8f...@ripley.netscape.com...
> svg:not(:root)
>
> Did I ever say :not() is one of the most awesome pseudo-classes ever
> made? :)
>
> I am using that to apply svgBindings.xml#svg:
Cool! I didn't even know it existed.
>
> Right off the bat, it seems I'll need to use an anonymous <g> element
> containing all the children and to implement transforms corresponding to
> zoom and pan, because it doesn't seem <svg> has a transform attribute
> (or at least instanceOfSVGSvgElement.transform in Moz is undefined...).
According to the dtd in the specs, I don't think it should have a transform
attribute. Correct me if I'm wrong.
> I see it done on <a>, so no biggie.
Good.
> But the two real issues an XBL implementation of this faces (other than
> the root element bug) are:
>
> 1. Indication of zoom/pan mode. ASV uses special cursors to indicate
> this, but last I tried (been a long time too), Mozilla still doesn't do
> cursor: url() (please correct me if I'm simply out of date). A rough
> implementation is fine without it, but I feel a complete SVG renderer
> should indicate this somehow.
I don't know about cursor:url(). Maybe some of the standard cursors will do.
I think mozilla has 'grab' and 'grabbing' for panning. For zooming I don't
know.
> 2. "Original View." ASV sticks this in their context menu. If this was
> XUL, I could hook up a nice context menu and it wouldn't be a problem,
> but right now, it wouldn't be easy. For my test bindings, I simply have
> it set to CTRL-right click (well, <handler event="contextmenu"
> modifiers="control">) and cancel the context menu, but I think this
> definitely needs to be changed if this is to be a part of the SVG
> implementation.
>
I don't quite understand what you mean here. Are you saying we can't have a
customized context menu?
>
> Also, SVGTransformList.prototype.consolidate() would make managing the
> transformations easier ;). Does getConsolidation() (some proprietary
> method I found in an IDL file) return the consolidated matrix, or is it
> just misleading?
>
It does return the consolidated matrix, as you say.
>
> If the former, wouldn't consolidate() be as easy as:
>
> SVGTransformList.prototype.consolidate = function() {
> var matrix =
this.createSVGTransformFromMatrix(this.getConsolidation());
> this.clear();
> this.appendItem(matrix);
> }
>
I guess so - the C++ equivalent anyway. I'll implement it for one of the
next builds.
> And after a gander at svgBindings.xml, I did notice a possible partial
> fix to problem #1. While setAttribute() would still fail, if you
> implemented the different sets presentation attributes as their own
> bindings, you could use <property> with setters and getters for them,
> and have the element bindings extend them to prevent writing the same
> thing over and over. And then instanceOfSVGElement.fill = 'somecolor'
> would work from Javascript.
But how would you map them into the style-attribute if setAttribute fails?
> Oh, and one last thing.
> http://www.w3.org/TR/SVG11/struct.html#SVGElement
> defines a "zoomAndPan" attribute with either "disable" or "magnify" as
> values. The attribute is never described anyway within the SVG 1.1 specs
> though, but it seems to me that if is has "disable", don't allow zooming
> or panning, but if it has magnify (or nothing, magnify is default
> value), allow zooming and panning?
> (Would like some confirmation...)
Yeah, I guess that's the right interpretation.
From the 1.1 specs:
"Magnification represents a complete, uniform transformation on an SVG
document fragment, where the magnify operation scales all graphical elements
by the same amount. A magnify operation has the effect of a supplemental
scale and translate transformation placed at the outermost level on the SVG
document fragment (i.e., outside the outermost 'svg' element).
Panning represents a translation (i.e., a shift) transformation on an SVG
document fragment in response to a user interface action.
SVG user agents that operate in interaction-capable user environments are
required to support the ability to magnify and pan.
The outermost 'svg' element in an SVG document fragment has attribute
zoomAndPan, which takes the possible values of disable and magnify, with the
default being magnify.
If disable, the user agent shall disable any magnification and panning
controls and not allow the user to magnify or pan on the given document
fragment.
If magnify, in environments that support user interactivity, the user agent
shall provide controls to allow the user to perform a "magnify" operation on
the document fragment.
If a zoomAndPan attribute is assigned to an inner 'svg' element, the
zoomAndPan setting on the inner 'svg' element will have no effect on the SVG
user agent."
BTW - it is probably best if you open a bug 'Implement zoomAndPan-controls'
on the SVG module and mark yourself as an owner. Then we can keep track of
the code and the dependecies on other bugs (e.g. #71191).
Alex
tobi
> According to the dtd in the specs, I don't think it should have a transform
> attribute. Correct me if I'm wrong.
Yes, the svg elemnt doesn't have one.
Tobi
Jason Davis
> I don't know about cursor:url(). Maybe some of the standard cursors will do.
> I think mozilla has 'grab' and 'grabbing' for panning. For zooming I don't
> know.
I'll look into the proprietary cursor: values...
>
>>2. "Original View." ASV sticks this in their context menu. If this was
>>XUL, I could hook up a nice context menu and it wouldn't be a problem,
>>but right now, it wouldn't be easy. For my test bindings, I simply have
>>it set to CTRL-right click (well, <handler event="contextmenu"
>>modifiers="control">) and cancel the context menu, but I think this
>>definitely needs to be changed if this is to be a part of the SVG
>>implementation.
>>
>
> I don't quite understand what you mean here. Are you saying we can't have a
> customized context menu?
I am currently unaware of a way to attach a contextmenu to non-XUL
elements? I'll invest a good deal of time in figuring that one out.
> BTW - it is probably best if you open a bug 'Implement zoomAndPan-controls'
> on the SVG module and mark yourself as an owner. Then we can keep track of
> the code and the dependecies on other bugs (e.g. #71191).
>
> Alex
http://bugzilla.mozilla.org/show_bug.cgi?id=163068
-Jason Davis
Jason Davis
currently, but panning is way too buggy right now (I am overlooking
something obvious, I know ;)).
If I don't have pan fixed later today (Monday), I'll throw up what I got
somewhere regardless and maybe (hopefully) someone can see what it wrong.
But here are the final limitations of this implementation:
1. No indication of zoom status due to no zoom in/out cursors
2. No SVG-aware context menu
#1 could be fixed by supporting cursor: url() (bug 38447), but I
wouldn't consider it a blocker. If URI values were supported, it would
be as simple as finding some nice, free zoom in/out cursors and sticking
them in the svg chrome directory.
#2 *might* be fixed though by some very tricky use of XUL. I have no
idea of what this might do, but perhaps I might be able to reparent the
<svg> element to an anonymous <xul:box> and assign a context menu for
the box element. I've never tried a standalone <box> outside of a XUL
document before, so I don't even know how feasible this is. And I still
feel iffy about using anonymous content to implement SVG features.
(think of possible disasters when using your own bindings on SVG
elements, only to find out there is already a binding attached and
anonymous content inserted...)
Ultimately, I hope a lot of the quick fixes done via XBL will eventually
converted to C++, but no rush until Mozilla releases are built with SVG
by default I suppose (which would imply Netscape releases as well? How
cool would a Netscape release with inline SVG support be? :)).
-Jason Davis
tobi
> How
> cool would a Netscape release with inline SVG support be? :)).
Incredibly cool.
I'm not fixated on inline, but a 100% complete and standards-conformant
*native* implementation supporting inline, embedded, and standalone SVG
is way cooler than "please download this plug-in" popups; best in
many/all browsers, on many/all platforms.
Please express your wish/requirement to the vendor(s);
contact data here:
http://www.pinkjuice.com/svg/browsers.xhtml#ask
For me, seeing SVG-enabled (as described above) default downloads of
regular releases of Mozilla would be great already; but for SVG (and for
all web developers), SVG-enabled Netscapes would/will be very important.
Tobi
Jason Davis
createEvent (and initEvent) then add in appropriate properties myself,
and dispatchEvent() it on the svg node, while also eval()-ing any onzoom
and onscroll attributes that may be specified.
The W3C SVG DOM doesn't provide an initSVGZoomEvent() method (I asked
about it in the SVG Mailing list before, and no one said anything - it
really seems to be a serious oversight in the SVG DOM....), so adding in
the properties myself after creating a generic Event seems to be the
only way for SVGZoomEvent.
Providing an XBL emulation of these events through the zoom and pan
controls may have consequences when these events are implemented for
real, nor would this really be a true event implementation...
Anyway, I'd like some input on this matter before I take the first steps
toward integrating it into the svg element binding or not. :)
-Jason Davis
Jason Davis
indication of what the finished product may be like, but it seems a few
people are interested in seeing what I've done so far, despite how
incomplete, but like I said, done or not, you can at least see what I've
done:
http://rdhtml.resource-locator.com/svg/mozilla/
Before replacing svgBindings.xml in
pathto/mozilla/bin/chome/svg.jar/content/svg/ you might want to copy the
original somewhere, like I forgot to do. :p
(I don't know if I broke anything because of that, but the only thing I
touched was svgBindings.xml#svg, so...)
svg.css didn't really change much, I just added a rule which applies the
bindings to svg elements that aren't root elements via the CSS selector
"svg:not(:root)"
Panning is badly broken it seems, but zoom in and out seems to work?
(Need some heavy duty comparisons to other viewers - ASV in IE6 seems to
zoom a few pixels differently, but nothing too different on my test)
CTRL+Click zooms in, CTRL+Shift+Click zooms out, and CTRL-contextmenu
resets to the original view (temp thing until I can figure out a context
menu, or at least something more logical). None of the SVG events I
mentioned previously are emulated either, and won't be until I get some
feedback on them.
And if you want to try the badly broken panning, ALT+Mousedown, then
move it around.
Anyway, anything I broke, a fix for pan, advice on the context menu, etc
etc - please tell. I'll continue working on panning (and fixing anything
wrong with zooming), but any comments may help. :)
-Jason Davis
tobi
> http://rdhtml.resource-locator.com/svg/mozilla/
>
> Before replacing svgBindings.xml in
> pathto/mozilla/bin/chome/svg.jar/content/svg/ you might want to copy the
> original somewhere, like I forgot to do. :p
I have
bin\chrome\svg.jar
this is a file; it can't contain directories
bin\chrome\svg\content\svg
these last three dirs have no content
svg.css is in bin\res, and svgBindings.xml can't befound.
Where is svgBindings.xm to backup and replace?
Tobi
Mike Lee
> Jason Davis wrote:
>
> I have
>
> bin\chrome\svg.jar
> this is a file; it can't contain directories
Jar file is just a renamed zip file. You can open it with any program
that support zip.
Regards
--
Mike Lee
Website: http://www.exitspace.net/mike
tobi
> Jar file is just a renamed zip file. You can open it with any program
> that support zip.
So do I replace bin\res\svg.css, or is there one in the JAR?
When I unzip svg.jar, do I replace svgBindings.xml then rezip?
Tobi
Mike Lee
> Mike Lee wrote:
>
>> Jar file is just a renamed zip file. You can open it with any program
>> that support zip.
>
> So do I replace bin\res\svg.css, or is there one in the JAR?
Yes, backup the file. Then replace it.
> When I unzip svg.jar, do I replace svgBindings.xml then rezip?
yes. Make sure you still got the right extension and directory structure :)
Another option is to open installed-chrome.txt and change the entry
"content,install,url,jar:resource:/chrome/svg.jar!/content/svg/"
to
"content,install,url,resource:/chrome/svg/content/svg/"
That way you can just leave things un-extracted. (I have this so i don't
have to rezip it everytime I did something to the file)
tobi
> Another option is to open installed-chrome.txt and change the entry
> "content,install,url,jar:resource:/chrome/svg.jar!/content/svg/"
> to
> "content,install,url,resource:/chrome/svg/content/svg/"
>
> That way you can just leave things un-extracted. (I have this so i don't
> have to rezip it everytime I did something to the file)
Alex, would that be an option for the builds? Then we could install
Jason's stuff more easily.
Tobi