Extension requires moving to Git

(In reply to comment #1)

Extension requires moving to Git

Okay, copying Chad about that.

A demonstration is currently available here: https://toolserver.org/~brion/svg-edit/svg-editor.html. Looks pretty neat!

(In reply to comment #2)

(In reply to comment #1)

Extension requires moving to Git

Okay, copying Chad about that.

Chad, is this in the queue?
Also cc'ing Harry because I don't understand how this would interact with TranslateSVG and he probably has some insights to share.

Well, interaction with TranslateSvg *per se* shouldn't be a problem, the issue is really its (by which I mean SVGEdit and not the extension) support for certain parts of the SVG1.1 specification on which TranslateSvg relies (namely <switch> tags).

At the moment, if you dump in a <switch> tag, it will render it correctly, which is nice. However, the text is not editable, and the thing isn't movable.

If you add a group around it, it becomes movable.

In other words, I think this is a fixable issue - SVGEdit *can* handle <switch>, it just doesn't think it can.

SVGEdit is written in JS, right? In which case, I could probably take a look myself at some point.

(In reply to comment #3)

(In reply to comment #2)

(In reply to comment #1)

Extension requires moving to Git

Okay, copying Chad about that.

Chad, is this in the queue?

It's already been done in the last round of moves.

https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/SVGEdit.git

(Removing myself from the CC list again since the part I need to do is done and I don't really care about SVGs)

sumanah wrote:

Harry (Jarry1250), do you have time to look at this soon? Thanks.

(In reply to comment #6)

Harry (Jarry1250), do you have time to look at this soon? Thanks.

Yeah, I can probably take a look tomorrow. I'd be more certain except someone tried to SQL-inject one of my websites today.

Upstream bug filed: https://code.google.com/p/svg-edit/issues/detail?id=1006 . Probably shouldn't block this, except perhaps from the perspective of svg-edit "sanitizing" an SVG and thereby breaking it, which could be confusing for the user.

sumanah wrote:

Since this is user-facing, then it looks like SVGEdit awaits a design review https://www.mediawiki.org/wiki/WMF_Project_Design_Review_Process before we can move forward with deploying it on Wikimedia sites. Would Harry, Brion, or someone else like to lead that?

Thanks.

(In reply to comment #9)

Since this is user-facing, then it looks like SVGEdit awaits a design review
https://www.mediawiki.org/wiki/WMF_Project_Design_Review_Process before we can
move forward with deploying it on Wikimedia sites. Would Harry, Brion, or
someone else like to lead that?

You're citing a draft of a page that was written in a single edit in April 2011 (about sixteen months ago). I find it difficult to believe that the page is authoritative or that anyone intended it to be.

sumanah wrote:

I'm inferring from http://lists.wikimedia.org/pipermail/design/2012-September/000138.html that Brandon wants folks to follow the process as outlined at https://www.mediawiki.org/wiki/WMF_Project_Design_Review_Process -- cc'ing Brandon to check.

marc wrote:

December 4th, 2012, there will be a community conference call. One of the topics is "SVG-edit on Wikipedia: What are the steps to get there?"

Looking forward to it:
https://code.google.com/p/svg-edit/wiki/CommunityConferenceCall#Wikipedia

Thanks!

Marc Laporte
SVG-edit

(In reply to comment #12)

December 4th, 2012, there will be a community conference call. One of the
topics is "SVG-edit on Wikipedia: What are the steps to get there?"

You should probably announce it on [[mw:Meetings]] etc.

I'll be on the call, unless my jury duty interferes. :P

marc wrote:

(In reply to comment #13)

(In reply to comment #12)

December 4th, 2012, there will be a community conference call. One of the
topics is "SVG-edit on Wikipedia: What are the steps to get there?"

You should probably announce it on [[mw:Meetings]] etc.

Done
https://www.mediawiki.org/wiki/Meetings/2012-12-05

Okay, so I was on the call today. What I took away from:

• svg-edit has a large body of diverse users and contributors. There are many use cases out there.
• many users have to hack the UI to get it a little more user friendly, but there does seem to be progress in this area. For example, CWM-tool is an open source attempt make a very simple GUI
• another caller, Emmanuel, said he was going to be trying out the existing extension for his new project.

In short, it's a very cool project. For my money, the choice is between jumping in now or jumping in later. I don't think it's very practical at present to have us reskinning--as some of the callers said, they were scared that because they'd hacked it, if they tried to update all they'd end up with was a horrible mess. Updatability > skinning for us, I suspect, especially if better skinning support comes soon.

Overall, I think we ought to consider a Labs deployment for svg-edit, and I'll look into getting that bug with <switch> support fixed.

marc wrote:

Hi!

Thanks for being on the call today. We had over 30 people, and the meeting lasted over 3 hours!

Notes and a link to the recording are here:
https://code.google.com/p/svg-edit/wiki/CommunityConferenceCall

Harry and Brion have commit access. We look forward to fixes for anything blocking progress towards this high-priority goal.

Best regards,

M ;-)

(In reply to comment #16)

For example, CWM-tool is an open source attempt make a very simple GUI

TO save someone else the googling: the name is actually CWM Draw Tool: http://code.google.com/p/cwm-drawtool/

marc wrote:

The next SVG-edit community conference call is on 2013-02-12:

And one of the main topics is Wikipedia & the round-trip test suite:
https://code.google.com/p/svg-edit/wiki/CommunityConferenceCall2#Wikipedia

Thanks!

Marc / Brion (bug assignee): Is there anything that volunteers can help with to get this forward? Was there any outcome from the community conference call?

The main thing we want to do is get compatibility testing automated -- round-tripping problems when editing existing files is the biggest problem with SVG-Edit for Wikipedia potential usage.

I have a proof-of-concept:
https://github.com/brion/svg-edit-test

(this currently only runs in Firefox because other browsers taint <canvas>es that have SVGs drawn to them.)

Needs some more work:

• add a back-end data store to save original files, round-tripped files, renderings, and subtractive comparison images
• add a front-end test runner that automatically churns through thousands of images
• add a front-end dashboard that shows images with large difference scores and allows easy searching

Probably we want to set this up on a Wikimedia Labs instance.

Then we can start identifying round-trip failures cases and seeing about fixing them.

In addition or as an alternative, we could update SVGEdit extension to current code and either limit it to new files or files that were created with SVGEdit, or add a warning that editing may damage files.

marc wrote:

Hi!

The SVG-edit testing suite has already lead to a first bug fix!

We have 9 new committers in the last 2 months:
http://www.ohloh.net/p/svg-edit/contributors?query=&sort=newest

I think it's a great time to have clear objectives which will come from this dashboard. And for all the 'old' committers, once we have a dashboard, I will write to all of them to ask them to help.

Best regards,

M ;-)

marc wrote:

The 3rd SVG-edit 'Community Conference Call' is confirmed for April 9th, 2013 16h00 UTC: http://code.google.com/p/svg-edit/wiki/CommunityConferenceCall3

Wikipedia / dashboard is one the agenda.

Thanks!

M ;-)

This feature request is being proposed at

https://www.mediawiki.org/wiki/Talk:Mentorship_programs/Possible_projects#Polishing_this_list_for_GSOC.2713_24957

and I'm considering whether to add it or not to

https://www.mediawiki.org/wiki/Summer_of_Code_2013#Project_ideas

If you think this is worth a try, I have some questions:

Could someone post a description of the work that needs to be done at http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects ?

Is there a potential mentor willing to help potential students interested in
this project?

Is there a reasonable support from the Commons community to
incorporate this feature if it's developed and meets the quality criteria?

marc wrote:

Some very interesting progress by Mike Baynton:

Please see comments here:
https://code.google.com/p/svg-edit/wiki/Wikipedia

And: http://home.mbaynton.com/svg-edit-test/svg-edit-test/launcher.php

Best regards,

M ;-)

Question: is SVG scripting (mentioned in https://strategy.wikimedia.org/wiki/Proposal:Inline_SVG_preference) in scope for this bug? If not, can someone please create a separate ticket for that in the most relevant component? Thanks.

(In reply to comment #26)

Question: is SVG scripting (mentioned in
https://strategy.wikimedia.org/wiki/Proposal:Inline_SVG_preference) in
scope
for this bug? If not, can someone please create a separate ticket for that in
the most relevant component? Thanks.

Its not. (Also it seems very unlikely we would ever allow scripted svgs [scary security issues]. Declaritive animation with smil seems at face value more likely to be a possibility, but would still have a lot of issues to go through)

Note there are some security issues reported recently with the base svg-edit (in the embedding API and in the editor itself); let's make sure those get fixed!

marc wrote:

SVG-edit 4th 'Community Conference Call' confirmed for October 10th, 2013 16h00 UTC: https://code.google.com/p/svg-edit/wiki/CommunityConferenceCall4

A major topic for Wikipedia is the recent progress on Round-Trip tests:
https://code.google.com/p/svg-edit/wiki/RoundtripTests

Thanks!

marc wrote:

The call recording is available at:
http://code.google.com/p/svg-edit/wiki/CommunityConferenceCall4

Many topics were discussed, but with respect to Wikipedia, next steps:

1- Security concerns must be addressed
2- SVG-edit could first be added for new drawings (until we have a reliable way to deal with existing drawings)
3- We should get the Multimedia list involved
http://lists.wikimedia.org/pipermail/multimedia/2013-July/000000.html

Thanks!

• Bug 62562 has been marked as a duplicate of this bug. ***

As far as item #1 on "Security concerns must be addressed", all issues on SVG-Edit should now be addressed in trunk, but I haven't gotten any takers to do testing yet.

I can test it once its deployed:-)

Trunk is deployed live on the SVG Edit site, albeit not as part of any MW extension there:

http://svg-edit.googlecode.com/svn/trunk/editor/svg-editor.html
http://svg-edit.googlecode.com/svn/trunk/editor/embedapi.html

(Note that the dialog about cookies can be avoided)

Version 2.7 of SVG Edit is now released.

I must note that on Commons exist another "new" JavaScipt SVG codeeditor by @Rillke: SVGedit.js

In T40271#1310750, @Perhelion wrote:

I must note that on Commons exist another "new" JavaScipt SVG codeeditor by @Rillke: SVGedit.js

Which is rather hacky and just for editing SVG source code while the extension this bug is about is a fully-featured WYSIWYG editor.

I've just released svgedit version 3.0.0 on npm. It includes some security fixes (for the Imagelib extension). There are no other known security issues remaining.

The former core developers are no longer active, and in my case, I have focused primarily on these security issues and mostly on refactoring for modern development, such as employing ES6, along with use of ES6 modules in source, as well as applying ESLint and documentation, and a few fixes and enhancements pulled in along the way.

svgedit is a popular tool, but we could really use some new core contributors. Hopefully the recent changes may make this easier for people to join and get involved.

And it'd be great to know if there may be any consideration by Wikimedia for moving this task of integration forward (though the latest version has some breaking changes which the extension would presumably need to overcome).

Thanks!

In T40271#4683545, @Brettz95 wrote:

I've just released svgedit version 3.0.0 on npm. It includes some security fixes (for the Imagelib extension). There are no other known security issues remaining.

The former core developers are no longer active, and in my case, I have focused primarily on these security issues and mostly on refactoring for modern development, such as employing ES6, along with use of ES6 modules in source, as well as applying ESLint and documentation, and a few fixes and enhancements pulled in along the way.

svgedit is a popular tool, but we could really use some new core contributors. Hopefully the recent changes may make this easier for people to join and get involved.

And it'd be great to know if there may be any consideration by Wikimedia for moving this task of integration forward (though the latest version has some breaking changes which the extension would presumably need to overcome).

Thanks!

I think basically no one is championing this task (Note, while typically extension champions are people that work for WMF, that is not a requirement, anyone can be an extension champion). I don't think there are any objections to the extension per se, but without someone maintaining the MediaWiki extension, and pushing it forward through the review process, its unlikely to go anywhere.

Still think this'd be a great base for us to work on, should there be time and energy to spend on it.

I've made some updates to the extension in git to fix it (it was totally broken for, like a couple years) and pull in a local copy of the web app, which'll need to be cut down for deployment sanity (there's some duplication between dist/ and editor/ and the default dist includes some .php files I'm not sure we want for processing file uploads in what I think is a pre-FileReader browser compat thing :D)

https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/SVGEdit/+/567304/

Yeah, our quick-and-dirty solution to ensure relative paths continued to work. :-)

While the original geniuses who put svgedit together have moved own, I have been trying to keep the fires burning by fielding occasional PRs and improving docs and what not. I'm happy to try to help as possible, as it'd be wonderful to see such an integration.