Open GoogleCodeExporter opened 9 years ago
I'm not sure that I don't *prefer* the current behaviour. After all, editing the
source can make changes anywhere on the canvas, including locations that are
"off-screen" in the current zoom. And I would like to see the result of those
changes
when I click "Apply Changes".
Conversely, clicking "Cancel" does maintain the current zoom and canvas
position.
Which makes sense, since nothing "off-screen" (or "on-screen", for that matter)
changed.
Original comment by jacques....@gmail.com
on 20 Feb 2010 at 8:33
I strongly disagree.
I work with the zoom a lot, and of course, the canvas is then panned, and it is
really a pain to have to rezoom and repan after any manual change to the source.
Besides, if a change to the source is made, it should only apply to objects in
the
SVG (and eventually, to the canvas dimensions), and NOT to the zoom level or
"point
of view", which are NOT informations stored in the source.
Original comment by worms_...@yahoo.com
on 20 Feb 2010 at 9:42
I agree with wormsxulla here, I'd like to see this fixed.
Original comment by codedr...@gmail.com
on 20 Feb 2010 at 10:59
I'm kind of on the fence on this...the problem is that the source view can be
either
used for minor tweaks or as an alternate way of loading a new SVG file. I know
codedread has previously suggested we have an "Edit source" for single elements,
which would help things...
Wormsxulla, what are the kind of changes you usually find yourself making in the
source? Most, if not all editing should really be made easiest to do using the
interface (eventually).
Original comment by adeve...@gmail.com
on 10 Mar 2010 at 12:42
Does anyone still care about this "bug"?
I'm trying to get involved with svg-edit (and am also lobbying for an official
switch to Git/Github) and I've played around with fixes for this.
svgCanvas.setSvgString() explicitly resets the zoom to 1 by default, so if you
delete that line and then also pass in a multiplier of 1 to the "zoomImage()"
call in "saveSourceEditor" (from svg-editor.js) then the issue is resolved. The
only potential problem I see with this is that anyone who relies on
setSvgString() to reset the zoom would be out of luck.
Couple options to deal with that:
1. Refactor most of setSvgString() out into a separate function that DOESN'T
have the zoom reset. Then setSvgString() can reset the zoom and call that
function, for backwards compatibility, and saveSourceEditor() can call the new
function which does everything besides the zoom reset.
2. Pass a resetZoom boolean param to setSvgString() to optionally disable zoom
resetting
3. None of the above because you could make the case that setSvgString()
shouldn't reset the zoom in any scenario. Anyone who wants that functionality
should simply call setSvgString() followed by setZoom().
My personal vote is for #3 because I'm a fan of modularity as opposed to having
a master function that does a whole bunch of stuff that may be useful for
certain scenarios and harmful in others.
Thoughts?
Original comment by dan...@trydesignlab.com
on 29 Aug 2013 at 4:47
Original issue reported on code.google.com by
worms_...@yahoo.com
on 20 Feb 2010 at 8:03