Navigating between layers in separate SVG files should be possible!

[mairin]

(copy/paste from the etherpad :) )

The next() function needs to be able to link between SVG files, as well as layers in the current file. The way I do this in the old JS:

• build a directory/lookup table of all layers across all SVGs in the directory; each entry is a pair: a layer name and filename of the svg it resides in
• when the next() equivalent is called, look for the desired layer in the current file. if you find it, great.
• if you don't find it, load the svg it's in as per the lookup table and then load the desired layer

Will the above work in the new coffeescript magic mockup or is there a better way?

The rationale for why I need to move between SVG files:

http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/

I have different functional areas of these mockups split into separate SVG files because if it was one big SVG file, it would be a nightmare to collaborate with other designers via SparkleShare. We'd be running into git merge conflicts all the time.

[garrett]

I agree and will try to implement this soon.

Right now, there's the openSUSE conference happening, so my time this week is a little more stretched than usual. I'll try to get to it when possible (hopefully this week). It probably won't be difficult to implement.

Are you fine with specifying the external files directly? I guess I can try to load an external file as a lookup table, but I'm not sure if it will be as easy in the SVG XML DOM vs. the HTML DOM (which is what jQuery is optimized for). I think it will work, however.

What does the lookup look like? What would you like it to look like? (It may need to be a certain way based on technical requirements. However, I can try to make it how you want first, and then work from there.)

I'm thinking that it should be an external file, and we should make it optional. With that being the case, I think we'd absolutely need to have the files served from a webserver for this to work. (Although, I might be able to work around that, depending on the file format, if it's critical to work w/o a webserver for more than one file.) Being that it's so easy to even spin up a local webserver (with Python or Node.js (especially with http-server)), it shouldn't be much of an issue, right? Even still, I won't really know the technical issues until trying, as the DOMs are very similar, yet slightly different in ways. (I imagine it will work regardless.)

[garrett]

I think the rational of needing this can be summarized simply: * Inkscape doesn't support multi-page documents. (Key point) * It also allows multiple designers work on a mockup flow. (Ideally, one designer would create the flow for consistency, but if others want to work on refining another screen, then it can be done.)

(Yeah, what you said)

[garrett]

So, this is a little duplication & restating of the concept, but I think it's useful to simply state it here in the bug report:

Cross-document linking would be implemented in two different ways:

• Explicit, where the links are set as document#link
• Implicit, where links are #link, and if it's not found in the document, it:
  1. Attempts to load an external file with references
  2. Caches the directives (in case it isn't found, so it will be ready to go for other links)
  3. Visits the implied document#link

This will be implemented in the JavaScript, and it would be useful to have a simple command-line utility that builds the external file. However, if there's a command-line something that builds it, then how are duplications resolved?

For example:

document-2.svg has #foo document-3.svg has #foo

document-1.svg links to, but does not contain #foo: What happens? (I think the easiest thing to implement is make the last one take priority, if there are duplicates.)

If the file is made by hand, it shouldn't be an issue.

Also, if the IDs are unique across documents, then it also shouldn't be an issue.

[garrett]

As of git commit 668c47a4d2e0b6d1de2fa30a61fb09e19e28efb3, you can now navigate between documents. next=newdoc.svg#some-view should work as expected.

As a bonus, you now may use forward/backward history in your browser to navigate screens as you can also link to a specific page via URL.

As an even extra special bonus, if you make a SVG filter in Inkscape and call it "hover", it will apply that filter as a hover effect (on clickable elements) when hovering (which is fantastic for prelighting buttons).

I plan on adding implied .svg extension support next. After that, I'll look into scanning the documents and making a lookup table for links.