This seems to be a limitation of the GTK+. You can't force its file selector to do something it just can't currently do. Any applications that use the GTK+ file selector widget are going to have the same problems.
However applications that use the Qt equivalent (and therefore all KDE applications and many others), can open directly from HTTP links. I have tested this in Kate.
I'm not sure what solution you want here. You could probably spend some time hacking this into the relevant GTK library so that it functions like this in the future. You could then submit that upstream and it'd eventually be the default (if accepted).
But the quicker route for this is either:
- Using an application that uses QT (or another framework that does this)
- Find another workflow.
In the context a browser, no browsers that I have tested (including GTK and Qt widget based ones) were capable of opening a remote URI for a file selection.
As mentioned earlier, Qt is technically capable of this but in Rekonq (the Qt browser I tested) it seemed limited to local files only. This may be something that could be worked on. For the GTK+ browsers (most of them) work needs to be done at on GTK before they'll work.
In short, fixing this in the browser isn't going to be practical for anybody.
That said you might be able to create a FUSE-based filesystem that read from the clipboard and provided a fake filesystem that contained one file (which then streamed data from the URL using something like the python-requests
library).
You could then just select that file in the browser and it'd work like any other file.
This isn't a small project (hence the lack of code) but it would be quite achievable to somebody with a little bit of Python experience.
what I do, and I know this may seem slow but it's the "get it done approach", is I open the image in www.photopea.com or a locally installed editing app such as pinta or gimp.
Pinta : pinta
Gimp : gimp
Hit Ctrl+A, then Ctrl+C then I have it ready to paste as an image.
the plugin you mention is of 2016 and must have broken down in ubuntu 18+. you might have to signal a bug then wait for a new verison to come out or for another plugin to come out.
Xclip could get you what you wish in the meantime in a terminal-based approach :
xclip
xclip -selection clipboard -t image/png -i example.png
NOTE: Some research shows that you need xclip from SVN revision 81 (from April 2010) or later to have the required -t
option. Or apply the patches yourself.
sources :
Best Answer
Pasting paths into Nautilus' "address" bar
You can activate the "location" view with CTRL+L. To permanently show the path instead of "breadcrumbs" you will have to manually change a dconf key:
To revert the changes simply execute the following command:
Copying file paths in the Save/Open dialog with Nautilus 3.4.2
As @AliNa pointed out, it used to be that you could access the location of a file or folder in the save/open dialog in the same manner as you can in a regular Nautilus window
This feature has been abolished in recent Nautilus releases as part of GNOME's design philosophy.
However, you can still access the file and directory paths from the context menu:
It seems as though this method has been removed as well in more recent revisions of Nautilus (the ones that ship with Ubuntu >12.10)...
Sources:
How can I copy the current path from Nautilus?
Typing location path instead of clicking directory buttons in the file picker dialog?
How do I change dconf keys without a gui (for a post-install script)?