Forgive me if this has been broached before (I’d appreciate a reference if so) but I’ve been unable to find this here in the forums.
It seems to me that Scapple would greatly benefit from the ability to open each individual element in the appropriate app of the user’s choice. This would enable, for example, fully fledged wordprocessing of separate paragraphs and detailed picture editing of embedded graphics.
I appreciate that this may not be a trivial exercise technically, as Scrapple would have to support whatever format the external app delivers on completion (or provide seamless format conversion, or at least a user-friendly denial mechanism), but perhaps the QuickLook framework is useful here.
Many thanks to anyone who can give me a technical sanity-check on this question.
I’m not sure about opening each element, that would seem to me to require going beyond Scapple’s ideal simplicity, but to open those that you decide really need it can easily be done with a link. I used to do this a lot: e.g. short note in Scapple linked to larger note in WriteRoom.
Thanks, Dr Dog. Of course “simplicity” is relative - an app that makes things simple for the user may be internally far from trivial; whereas a “simple app” may require a ton of skullduggery on the part of the user to get stuff done.
I’ve been exploring this link idea, and it seems to fall into the latter category. I can drop a local file (a jpg, say) into the Link Destination dialogue box, to produce its path, but when I click the resulting link I don’t see the picture. I get an invitation to Choose an Application (Photoshop, say), but for some reason I don’t understand this brings up Photoshop but not the picture.
This suggests to me that this isn’t what Scapple’s link mechanism is designed for (the manual is terse on this point). There may be a way of kluging the link so that it works as I expect - a path to evoke Photoshop with the picture path as a parameter, perhaps, but I haven’t worked out how to do this.
I hoped it was clear from my initial posting that I knew that what I was asking wouldn’t necessarily be trivial to engineer. It’s from the user’s point of view that I was hoping to adhere to the KISS principle.
Maybe I misunderstood. I meant Scapple links created with the CMD-L which enables you to link to another file. I’ve only tried text links: Scapple to me is a simple flexible whiteboard which I have come to depend on at the beginning of every day (a Scapple a day, to re-use an old phrase) and I use other programmes for more permanent constructions.
You only need to bother with making a link manually to things like text, pictures and PDF graphics, because Scapple has native support for displaying them on the board somehow, either through conversion or embedding. For all other file types you can just drag the file right into the board. You may want to edit the link text after doing so, but you don’t have to bother with the URL. Take a look at one though, to see how it is done—you might be missing the “file://” part in front of the jpg’s path.
@DrDog The idea of being able to click (or right click) on an item to open it in an appropriate editor doesn’t seem to me complicated. You might, for example, want to crop a picture you’ve dropped into Scapple. Or open a table into a spreadsheet for modification.
The Scrapple surface shows an appearance of the item (in the case of text, an appearance capable of simple in situ edits). To accomplish what I see as an intuitive user requirement, each appearance only need remember its operating system association with the relevant editor - or at least just know where to look that up - and be able to return an appearance of the result in place of the original appearance.
@AmberV If you drop (say) a jpg into the Link Destination dialogue box as I suggest above, all you get there is the full file path. Prefixing this with “file://” doesn’t help, unless I’m missing something. Is this what you meant?
Well, see that’s where it gets complicated. Right now Scapple is a simple plain-text editor (there are some basic things like italics and links, but this isn’t true rich text), and you’re asking for something that renders a wide variety of file formats, many proprietary and complicated, like spreadsheets and Word documents. Even Quick Look with its sole purpose of doing just that isn’t terribly good at it and requires the collaboration of other developers to be done well.
The full file path is exactly what you want, that is what makes a valid file:// link. It does not load the JPEG in your default editor when you click on the link? That might be an association problem—I’d check the original file and make sure it loads when you double-click on it. In my test the JPEG popped right up in Photoshop.