Feature request - canonical uri button.

[Zachary Storer]

Hello,

I wish that there was a more intelligent [import] button that could link to external images without the need

for manually inserting the _canonical_uri field. This is a feature request(?). I don't know how difficult it would

be to add this. Perhaps I can learn some JavaScript and make a plugin for it, or perhaps there already is a plugin?

-

Zak

[TonyM]

Zak,

Good idea, perhaps we could stop describing it in such obscure technical terms.

Eg the "External Image Address" is stored in the _canonical_uri of a tiddler.

Regards

Tony

[TonyM]

On Further thought,

What if we had a button to insert file/folder addresses of any kind into a named field. Ideally it would allow a file spec such as *.jpg *.png as well.

 Then a variation of this button  (preset variables) before Calling the button would give the one you ask for.

However it can be used elsewhere.

Regards

Tony

On Wednesday, May 16, 2018 at 9:32:08 AM UTC+10, Zachary Storer wrote:

[Mark S.]

We've been told that the full path is unavailable, and that's why it can't make an external link on the fly.

It seems to me that TW must have available the plain file name. So if you could provide the path to the file via a configuration tiddler, then a complete uri could be formed. Maybe could overwrite the existing "import" button (the one you see after the drag-n-drop) so that it creates a canonical uri tiddler rather than actually importing the source.

-- Mark

[TonyM]

Mark,

I would not be surprised if pointing only supplied part of the path and or only the filename as you say.

Good idea enhancing the import screen, so drag and drop work as well.

If the user provides the source folder name to one field eg; \images then the file open dialogue selects the filename from said path then selecting the filename is sufficient to build the relative path \images\52346346.jpg

This would be further enhanced if we can use the Operating systems Preview features to help select the correct image file.

It does not seem to be rocket science to simplify the process as much as possible. If we just and try and attach an image we quickly see the opportunities available to make this easy even in the face of impediments.

Thanks

Tony

[Zachary Storer]

Should I add a feature request for this on GitHub?

[Mat]

Hi all, I posted this closely related issue on github some time ago. Please go there and support it.

Sniff file ext to infer type for _canonical_uri tids

<:-)

[Ste Wilson]

in my role as the village idiot....
What is a canonical URI? Who is Uri?

[Mark S.]

Uri is the guy in charge of the TW cannon works. Whenever the unicorns start to stampede the tiddlers, he comes out and fires on them. It's quite a sight.

Just as described in the docs:

https://tiddlywiki.com/#ExternalImages

HTH
-- Mark

[ste...@gmail.com]

Hi,

On Wednesday, May 16, 2018 at 1:32:08 AM UTC+2, Zachary Storer wrote:

I wish that there was a more intelligent [import] button that could link to external images without the need

for manually inserting the _canonical_uri field. 

With the following code, a JPEG image from a web location can be dragged into an area marked "Drop JPEG Image Here", and a tiddler containing the _canonical_uri of the image is automatically created:

\define embedded-image-actions()

<$wikify name="tiddlercontent2" mode="inline" text='<<actionTiddler>>'>

<$action-createtiddler $basetitle="New Image" _canonical_uri=<<tiddlercontent2>> type="image/jpeg"  $savetitle="Embed JPEG!!tiddlertitle"/>

<$action-navigate $to={{Embed JPEG!!tiddlertitle}}/>

</$wikify>

\end

<$droppable actions=<<embedded-image-actions>>>

<div style="height:2em;">

<div style="border:1px dotted; width:15em;padding:0.7em;border-radius:5px;text-align:center;">Drop JPEG Image Here</div></div>

</$droppable>

Downside: I believe that a separate tiddler/drop area needs to be created for other image types, e.g. PNG. 

Cheers,

Stef

[BurningTreeC]

With the following code, a JPEG image from a web location can be dragged into an area marked "Drop JPEG Image Here", and a tiddler containing the _canonical_uri of the image is automatically created:

\define embedded-image-actions()

<$wikify name="tiddlercontent2" mode="inline" text='<<actionTiddler>>'>

<$action-createtiddler $basetitle="New Image" _canonical_uri=<<tiddlercontent2>> type="image/jpeg"  $savetitle="Embed JPEG!!tiddlertitle"/>

<$action-navigate $to={{Embed JPEG!!tiddlertitle}}/>

</$wikify>

\end

<$droppable actions=<<embedded-image-actions>>>

<div style="height:2em;">

<div style="border:1px dotted; width:15em;padding:0.7em;border-radius:5px;text-align:center;">Drop JPEG Image Here</div></div>

</$droppable>

Hi @Stef ,

I believe this could make it work for more types: 

\define embedded-image-actions()

<$wikify name="tiddlercontent2" mode="inline" text='<<actionTiddler>>'>

<$vars imageType={{{ [<tiddlercontent2>>suffix[.jpg]addprefix[image/jpeg]removesuffix<tiddlercontent2>] [<tiddlercontent2>>suffix[.jpeg]addprefix[image/jpeg]removesuffix<tiddlercontent2>][<tiddlercontent2>>suffix[.png]addprefix[image/png]removesuffix<tiddlercontent2>] }}}>

<$action-createtiddler $basetitle="New Image" _canonical_uri=<<tiddlercontent2>> type=<<imageType>>  $savetitle="Embed JPEG!!tiddlertitle"/>

<$action-navigate $to={{Embed JPEG!!tiddlertitle}}/>

</$vars>

[Mark S.]

Neat. Hmmm. I guess if you know that you're always dragging/dropping from a particular path then you could strip off one prefix and add another. That allows you to create a relative path _canoncal_uri tiddler. Like this (for just the macro part of your code) :

\define embedded-image-actions()
<$set name="tiddlercontent2" mode="inline" filter="[<actionTiddler>removeprefix[file:///C:/Users/Mark/Downloads/]]">

<$action-createtiddler $basetitle="New Image" _canonical_uri=<<tiddlercontent2>> type="image/jpeg"  $savetitle="Embed JPEG!!tiddlertitle"/>
<$action-navigate $to={{Embed JPEG!!tiddlertitle}}/>

</$set>
\end

This lets you drag and drop from a local directory (browsed in your browser) into a local tw and instantly create a _canonical_uri tiddler. The only thing that would be better is if you could drag from explorer or some other file browser.

Thanks!
Mark

[TonyM]

This thread is moving somewhere useful, using alternate Drop Zones for different responses to drag and drop.

If I may make a small brain dump for consideration.

I do not yet have the skills to do so but it seems to me we need to generalise this somewhat. You could think of it as providing a drop zone for a number of importers that respond differently. Alternatively and even better would be if we could open a drop importer in its own window, so that onscreen we place this window next to our filemanger to collect and import all the files we want, if necessary supplying the folder path seperately.

Personally I can imagine opening a tiddler full screen perhaps called the drop importer which would have a number of coloured tiles with the different importer methods as the title. Including custom importers such as anything you drop here will be tagged foo as well as imported. The importers could simply import a link, create the canonical URI, drop the filename only, import the item by filetype etc... A custom value would allow one to specify a path eg; /images such that if one drags a set of filenames into tiddlywiki it will import the filename such that it can be combined with the path to point to the file(s) folder. This requires the files are intentionally placed in the /images folder by the user but this is trivial to not being able to drop references to the files in tiddlywiki (or has this already being solved?)

Every drop importer should have a matching Importer for the Import button as well, and being able to set a filter for the files you can select say to "images only" would be helpful to make it clear what can be imported via that importer.

I would like to create importers to drag and drop say .bat and .cmd files and have them tagged WindowsBatch for example. Or .php files, tagged wordPressPHP

Further, I have raised the use of iFrames for inter Wiki tiddler transfer here https://groups.google.com/forum/?hl=en#!topic/tiddlywikidev/xauAqz1Eu0w It would great if such importers would include dropzones that are in fact windows to other wikis so lets say I dropped a plugin into an importer called "CorePlugins" the plugin would effectively be dropped on the External Wiki called "CorePlugins"which is my plugin repository, if we could only have the target wiki not ask to confirm import this would be helpful (but not essential). Even better would be an importer that imports the plugin here and into CorePlugins in one step.

Another type that would be helpful is to select a folder name and or path (if Possible) to save in a tiddler. Whilst this could be used to say set the images location it could also be used to point to a folder containing other wikis, or to a wiki file itself.

Also as you may guess I would think every importer should have a matching exporter. I would love to be able to provide a button that exports a .bat .cmd .php file as a .bat  .cmd or .php file. Thus TiddlyWiki can be an integrated tool for documenting and generating scripts in multiple formats, especially where the content is effectively plain-text. For the security concerned remember I have to use the interactive export/save dialogue so such files can not be installed surreptitiously. However allowing (sometimes small) executables would also be helpful, so that tiddlywiki could become an interactive set up and install platform. Imagine if TiddlyServers settings.json could be automated in tiddlywiki with the result exported (Jed does something like this in Bob).

I believe there are no technical limitations to getting the above, only a need for a clarity of purpose.

Regards

Tony

[Mat]

Regarding these latter code samples;

Maybe there can be a list of the various image types, and other file types for that matter, which some listwidget runs through as part of the actions? (The list could be e.g in a dictionary).

<:-)

[Ste Wilson]

Cheers Mark S for the explanation :D

So... I've been embedding external images with
[img[http://url.svg]]

But I could do this with canons and uri?

What are the advantages as, having had a look at the documentation, I'm still not massively clear...

[@TiddlyTweeter]

Ste Wilson wrote:

What are the advantages as, having had a look at the documentation, I'm still not massively clear...

On this, even if you are (Y)uri and clad according to Catholic Canon Law, you are in good company.

If you look back over the Google Marshes, you will see that how to handle images is one of the most recurrent questions and confusions.

Its NOT TW can't do it. It can do it well in a few different ways. Plus, additional complications arise because the server version (Tiddlers as ".tid") requires a specific method for external image handling.

I think the variant situations, even in basic setups, is already quite complicated to get your head round.

This is one area of documentation where someone who has a full overview could help us all by giving slightly more detailed notes and examples of the variant methods of instantiating imagery even at the out-of-the-box level.

Just MO
Josiah

[ste...@gmail.com]

Hi,

On Wednesday, May 23, 2018 at 10:50:24 PM UTC+2, BurningTreeC wrote:

I believe this could make it work for more types: 

Your code looks promising. However, it doesn't seem to work for me. When I try to import a .jpg image, no image type is detected, and I get the following error:

Trying to load external content from [URL]
If this message doesn't disappear, either the tiddler content type doesn't match the type of the external content, or you may be using a browser that doesn't support external content for wikis loaded as standalone files. See https://tiddlywiki.com/#ExternalText

Also, I'm not sure what to do about URLs that end e.g. like this: .png&f=1 (DuckDuckGo creates such URLs)

On the other hand, TiddlyWiki seems to render .png or .svg images properly even if I import them with the content type "image/jpeg". 

(I had tried to post this before, including the URLs of the images from Flickr and Wikipedia which I used, but my post was deleted - I guess I inadvertedly violated some forum rules by including the links.)

~Stef

[Mark S.]

The main advantage, and it's kind of weak, is that if you use the image in multiple places, but then need to change the directory, you will only have to change the one canonical URI address.

It's weak, because you can do much more with macros. With a macro and a configuration tiddler, you can change your image path depending on your platform. This is useful if you can't use a relative path on some platform. For instance, on Android you might need your TW to be in downloads directory for saving on an internal drive with limited space, but all your images are off on a sdcard where there is more space. Likewise, switching between Linux and Windows where the file pathing is completely different. The problem with macros is that they're not part of the standard core, and you'd have to rewrite all your image links like <<img "MyFavoriteFossaImage.jpg">>.

It would be great if all internal image links referenced a base image path configuration tiddler. Then you wouldn't have to use a macro to display images in a flexible manner. I suppose that would be a fun parser rework project.

-- Mark

[ste...@gmail.com]

On Wednesday, May 23, 2018 at 10:40:27 PM UTC+2, ste...@gmail.com wrote:

Downside: I believe that a separate tiddler/drop area needs to be created for other image types, e.g. PNG. 

Here is an updated version of my code which allows users to pre-select a file type (GIF, JPEG, PNG or SVG) before importing an image:

\define embedded-image-actions()
<$wikify name="tiddlercontent2" mode="inline" text='<<actionTiddler>>'>

<$action-createtiddler $basetitle="New Image" _canonical_uri=<<tiddlercontent2>> type={{Embed Image}} $savetitle="Embed Image!!tiddlertitle"/>
<$action-navigate $to={{Embed Image!!tiddlertitle}}/>
</$wikify>
\end


<$droppable actions=<<embedded-image-actions>>>
<div style="float:left;margin-right:1em;">
<div style="border:1px dotted; width:15em;padding:0.8em;border-radius:5px;text-align:center;">Drop image (<$list filter="[[Embed Image]get[text]]+[removeprefix[image/]]">{{!!title}}</$list>) here</div></div>
</$droppable>
<div style="height:2.5em;">
Image type: <br/>
<$select tiddler='Embed Image'>
<option value='image/gif'>GIF</option>
<option value='image/jpeg'>JPEG</option>
<option value='image/png'>PNG</option>
<option value='image/svg+xml'>SVG</option>
</$select></div>

Of course, automatic detection would be preferable.

Cheers,

Stef

[Zachary Storer]

Any progress with this?

[Jed Carty]

Zak,

There are security restrictions on browsers that prevent the browser from knowing the full path to local files. There isn't currently any way around this and if anyone found a way it would probably be patched quickly. I made the ServerImages plugin (https://github.com/OokTech/TW5-ServerImages) but it is very limited. It assumes that any media file imported is in a known folder and instead of importing the media file creates a tiddler with a _canonical_uri field pointing to that folder.

But it prevents you from being able to import media files normally and if you change the folder or have the file somewhere other than that one folder it won't work. And I don't know if it will work without Bob because you need to have a server serving the files.

[TonyM]

Jed,

Just a thought.

If I am running tiddlywiki locally I can always get a full local filepath and save it in TiddlyWiki in a tiddler. I could even build a way to import the whole folder tree and import it to tiddlywiki.

Once these folders are known in tiddlywiki I could do a lot of stuff. Its seems that while browsers now limit the process in the browser that collects such foldernames, such that if it were compromised It can not be used to access systems files etc... However surely we have the "right" to provide a given wiki with that data? and then use that data as we need?

The browser can surely know this because we provide it with the folder names by our own means?

Regards

Tony

[Jed Carty]

Tony,

The browser can know whatever you tell it yes, but when you drag and drop a file into the browser or import it another way the browser only gets the file name, not the path. You can give the browser the path if you want, but you have to do it manually that is how _canonical_uri fields work. So you can list all the folders you want in tiddlywiki, but it doesn't have a way to automatically associate a folder with an imported file.

And if you are going to talk about 'rights' of the browser vs the person using the browser in this context, the adversarial model used by browsers has a lot of problems, not as many as that of phone OS's, but there are plenty of problems. DRM and adtech are two big reasons but that is something that I shouldn't rant about here.

[TonyM]

Jed,

I understand that limitation, but once we have "manually" provided those folders we should be able to browse them and select images and use our own code to add a field containing the source folder.

I put quotes around "manually" because getting all folder names is like this in the windows commend prompt "dir /s /ad /b >result.txt" and I am sure similar on linux. Although we may restrict this to our images/pictures folders and subfolders in the image case.

Regards

Tony