The libferris virtual filesystem gains another tentacle, this time being able to mount mediawiki sites. Some cool use cases right off the cuff:
To read a wiki page
$ fcat wiki://$server/mediawiki/index.php/SamplePage
To write to a wiki page:
$ date | ferris-redirect -T wiki://$server/mediawiki/index.php/Sampler22
For those who are unfamiliar, ferris-redirect takes its stdin and writes it to the file you name. The -T truncates the file first. So the above is sort of like " >| " from bash but you get to write from any application to any libferris filesystem without using FUSE.
To plomp an image up on mediawiki:
ferriscp -av /tmp/Apple.png wiki://$server/mediawiki/index.php/
Which is then available as:
http://$server/mediawiki/index.php/File:Apple.png
And perhaps the coolest little trick so far, which doesn't rely on FUSE or mounting and uses an unmodified vi binary:
$ fedit wiki://alkid/mediawiki/index.php/Sampler22
... modify the "file" ...
ZZ to write it back to the web.
Also, I have tramp hacks to allow this to work from emacs.
Of course, this all interacts with other things libferris can mount, so you can "cp" from your scanner or webcam right to a wiki page or grab text from a wiki and create a pdf or print it out directly.
Oh, and there are Fedora 16 packages now too on openSUSE build service. Just run the following to get it all onto your system.
# yum install libferris-suite
Showing posts with label filesystem. Show all posts
Showing posts with label filesystem. Show all posts
Tuesday, November 22, 2011
Tuesday, September 13, 2011
Bringing back /dev/pcm
Taking a peek in /dev/snd one might find device files for their sound card(s). Sequencers, Timers, midi, and pcm device files. I thought it might be interesting to apply a modern face lift to these devices; so now libferrris can mount pulseaudio and has write support for gstreamer.
What this means is you can write "audio" data to a virtual filesystem and have it play that back for you:
$ cat /tmp/sample.flac | ferris-redirect -T gstreamer://output/audio
ferris-redirect is like the shell pipe character but allows direct access to libferris filesystems without mount commands. The -T truncates, so it is like a ">|" bash redirection.
I also plan to make these output directories special. If you write to them like they are a file as in the above then it puts your data there. If you create a subfile and write to it you will be essentially writing to the output file itself. With that you could "cp" a directory of audio files to gstreamer://output/audio and they will play one at a time until you have copied them all to your speakers ;)
$ ferriscp -av /tmp/bongos-dir gstreamer://output/audio
Pulseaudio is available at pulseaudio:// or the shortcut pa://. The tree currently allows you to mute and alter the volume for playing streams and whole output devices. Reading a volume file will tell you the percentage that channel outputs at (or the average for volume-all). Writing a float to the volume files changes the volume to suit your request. The mute files similarly show if the audio is muted and allow you to set that by writing 1 or 0 to the file.
$ fls -0 pa://output/default
mute 0
volume-0 0.729996
volume-1 0.729996
volume-2 0.729996
volume-3 0.729996
volume-4 0.729996
volume-5 0.729996
volume-all 0.729996
$ echo 0.7 | ferris-redirect -T \
"pulseaudio://streams/amarok/Audio Stream/volume-all"
All this ferris-redirect stuff can have it's additional typing mitigated using a suitable inputrc.
For example:
$ cat ~/.inputrc
$include /etc/inputrc
">>>": "| ferris-redirect "
">>|": "| ferris-redirect -T "
This will be in the next libferris release tarball. Things slowly get closer for the libferris QML mobile audio app. You can already do index and search with libferris and get at the results as a QModel for use in QML, now you can also set volumes and "copy" sound to the earphones.
What this means is you can write "audio" data to a virtual filesystem and have it play that back for you:
$ cat /tmp/sample.flac | ferris-redirect -T gstreamer://output/audio
ferris-redirect is like the shell pipe character but allows direct access to libferris filesystems without mount commands. The -T truncates, so it is like a ">|" bash redirection.
I also plan to make these output directories special. If you write to them like they are a file as in the above then it puts your data there. If you create a subfile and write to it you will be essentially writing to the output file itself. With that you could "cp" a directory of audio files to gstreamer://output/audio and they will play one at a time until you have copied them all to your speakers ;)
$ ferriscp -av /tmp/bongos-dir gstreamer://output/audio
Pulseaudio is available at pulseaudio:// or the shortcut pa://. The tree currently allows you to mute and alter the volume for playing streams and whole output devices. Reading a volume file will tell you the percentage that channel outputs at (or the average for volume-all). Writing a float to the volume files changes the volume to suit your request. The mute files similarly show if the audio is muted and allow you to set that by writing 1 or 0 to the file.
$ fls -0 pa://output/default
mute 0
volume-0 0.729996
volume-1 0.729996
volume-2 0.729996
volume-3 0.729996
volume-4 0.729996
volume-5 0.729996
volume-all 0.729996
$ echo 0.7 | ferris-redirect -T \
"pulseaudio://streams/amarok/Audio Stream/volume-all"
All this ferris-redirect stuff can have it's additional typing mitigated using a suitable inputrc.
For example:
$ cat ~/.inputrc
$include /etc/inputrc
">>>": "| ferris-redirect "
">>|": "| ferris-redirect -T "
This will be in the next libferris release tarball. Things slowly get closer for the libferris QML mobile audio app. You can already do index and search with libferris and get at the results as a QModel for use in QML, now you can also set volumes and "copy" sound to the earphones.
Friday, April 29, 2011
Everything is a file? Spitting it out again...
After recently adding support for scanning through a virtual filesystem interface in libferris I thought I'd complete the cycle and add printer-as-filesystem too. This of course allows the neat trick to "copy" a document from your scanner and dumping it to a printer:
$ ferriscp scanner:///my-scanner/color/scan.png printer:///my-friends-printer/
Naturally the printer and scanner don't have to be in the same room etc. As you can see from the above, writing a picture to a file inside the printer's virtual directory prints that image to paper. By default images are smooth stretched to fit the entire page, not a huge issue if you scan and print at the same DPI.
Images can come from anywhere, to hard copy a webcam
$ ferriscp gstreamer://capture/webcam.jpg printer:///Ich-bin-ein-drucker/
If on the other hand you write a plain text file to the printer's directory it will be printed in an acceptable manner too. So something like this works
$ date | ferris-redirect -T printer://Cups-PDF/foo
In this case, you can expect a ~/Desktop/foo.pdf file which is a PDF document with the current date in it. One can think if ferris-redirect as the shell "|" but which natively knows about all the libferris filesystems. On the other hand, you could use FUSE to mount printer:// at some normal kernel location and just do
$ date >| ~/printer/Cups-PDF/foo
Of course, none of this is meant to replace programs which let you tweak how images are printed, format how text will appear, or select from the myriad of options your printer offers you. But if you want a piece of paper from a scanner to a printer, such a "copy" might be just the ticket.
$ ferriscp scanner:///my-scanner/color/scan.png printer:///my-friends-printer/
Naturally the printer and scanner don't have to be in the same room etc. As you can see from the above, writing a picture to a file inside the printer's virtual directory prints that image to paper. By default images are smooth stretched to fit the entire page, not a huge issue if you scan and print at the same DPI.
Images can come from anywhere, to hard copy a webcam
$ ferriscp gstreamer://capture/webcam.jpg printer:///Ich-bin-ein-drucker/
If on the other hand you write a plain text file to the printer's directory it will be printed in an acceptable manner too. So something like this works
$ date | ferris-redirect -T printer://Cups-PDF/foo
In this case, you can expect a ~/Desktop/foo.pdf file which is a PDF document with the current date in it. One can think if ferris-redirect as the shell "|" but which natively knows about all the libferris filesystems. On the other hand, you could use FUSE to mount printer:// at some normal kernel location and just do
$ date >| ~/printer/Cups-PDF/foo
Of course, none of this is meant to replace programs which let you tweak how images are printed, format how text will appear, or select from the myriad of options your printer offers you. But if you want a piece of paper from a scanner to a printer, such a "copy" might be just the ticket.
Tuesday, April 26, 2011
Blocking a nostril
I have been meaning to add sane support to libferris since I upgraded my scanner to something modern. I now also have an Automatic Document Feeder (ADF) so naturally that needs to be a filesystem too. A quick example of how this might be useful, to turn a document into something on screen quickly:
$ fcat sane:///my-scanner/color/scan.jpg | okular -
The trees under sane:// allow preconfigured scanning units and discovery. If you have setup my-scanner then no device listing is performed with sane, a good thing because discovery can be slow. When you configure a scanner you create one or more directories with specific configurations of how you want the scan to proceed. Incidentally, configuration is of course done with a filesystem. Inside ~/.ferris/sane you create a directory for your scanner, plomp the device name into scanner/device and create directories with scanning options for that scanner.
As well as scan.jpg there is a directory "adf" which chomps new things from the ADF for each file you read. Having this directory allows you to grab 20 documents by a normal looking posix like command such as:
$ ferriscp -av sane:///adf/gray-100/adf /tmp/
in this case, I made two trees, color-N and gray-N which scan in color or grayscale at a given DPI (100,300,600 etc). So I can get most of what I want by picking the right directory. "adf" is a softlink to my scanner (a local link in ~/.ferris/sane from adf to "my-scanner"). Using links like this means I can replace the hardware and scripts can still just ask for "the adf" scanner and get something.
One might wonder what happens for a scanner which is not known to the system. The ".discovery" configuration inside ~/.ferris/sane provides defaults for such devices, so you can have your color/gray DPI directories magically appear for discovered scanners too. Of course, most of the gray directories are similar, so softlinks are your friend except for the "resolution" file which you want to change per directory.
Discovery isn't performed for the above commands, because libferris uses short cut directory loading as it knows explicitly how to make the virtual filesystems for preconfigured scanners.
Some hints on configuration will be in dot-ferris/sane/dot-discovered which will be in libferris 1.5.6+ along with the code to actually make it happen.
$ fcat sane:///my-scanner/color/scan.jpg | okular -
The trees under sane:// allow preconfigured scanning units and discovery. If you have setup my-scanner then no device listing is performed with sane, a good thing because discovery can be slow. When you configure a scanner you create one or more directories with specific configurations of how you want the scan to proceed. Incidentally, configuration is of course done with a filesystem. Inside ~/.ferris/sane you create a directory for your scanner, plomp the device name into scanner/device and create directories with scanning options for that scanner.
As well as scan.jpg there is a directory "adf" which chomps new things from the ADF for each file you read. Having this directory allows you to grab 20 documents by a normal looking posix like command such as:
$ ferriscp -av sane:///adf/gray-100/adf /tmp/
in this case, I made two trees, color-N and gray-N which scan in color or grayscale at a given DPI (100,300,600 etc). So I can get most of what I want by picking the right directory. "adf" is a softlink to my scanner (a local link in ~/.ferris/sane from adf to "my-scanner"). Using links like this means I can replace the hardware and scripts can still just ask for "the adf" scanner and get something.
One might wonder what happens for a scanner which is not known to the system. The ".discovery" configuration inside ~/.ferris/sane provides defaults for such devices, so you can have your color/gray DPI directories magically appear for discovered scanners too. Of course, most of the gray directories are similar, so softlinks are your friend except for the "resolution" file which you want to change per directory.
Discovery isn't performed for the above commands, because libferris uses short cut directory loading as it knows explicitly how to make the virtual filesystems for preconfigured scanners.
Some hints on configuration will be in dot-ferris/sane/dot-discovered which will be in libferris 1.5.6+ along with the code to actually make it happen.
Friday, May 14, 2010
Plasma, libferris, and Google Spreadsheets
In my previous post I talked about how libferris now has a Plasma DataEngine which lets you get at the entire virtual filesystem (on demand) from plasmoids.
I've since extended things so that the DataEngine now includes a Service object, allowing plasmoids to write data too. Instead of tracking an XWindow, this time around I'll track a Google Spreadsheet and update it through the plasmoid. Doing this makes a mounted web service like GSpreads into a pastebin with access control applied. So you can share your clipboard with anyone in your "group" or company and stop others getting at it.
The two plasmoids show two spreadsheet cells, the top one is the top coloured cell and the bottom plasmoid is the lower, purple cell. The purple cell in the spreadsheet is the sum of the three cells in the column around the peachy cell above it.
First, updating the spreadsheet through the browser is reflected in the plasmoid. Towards the end I copy and paste a number into the top plasmoid, which updates the peach cell in the spreadsheet, which in turn causes the purple cell to update and so the lower plasmoid shows this updated sum. Of course, these two plasmoids don't have to be on the same machine. For tracking sums or other formulas, the ferris_graph might be more interesting if you are more interested in the trends than the current value.
I've since extended things so that the DataEngine now includes a Service object, allowing plasmoids to write data too. Instead of tracking an XWindow, this time around I'll track a Google Spreadsheet and update it through the plasmoid. Doing this makes a mounted web service like GSpreads into a pastebin with access control applied. So you can share your clipboard with anyone in your "group" or company and stop others getting at it.
The two plasmoids show two spreadsheet cells, the top one is the top coloured cell and the bottom plasmoid is the lower, purple cell. The purple cell in the spreadsheet is the sum of the three cells in the column around the peachy cell above it.
First, updating the spreadsheet through the browser is reflected in the plasmoid. Towards the end I copy and paste a number into the top plasmoid, which updates the peach cell in the spreadsheet, which in turn causes the purple cell to update and so the lower plasmoid shows this updated sum. Of course, these two plasmoids don't have to be on the same machine. For tracking sums or other formulas, the ferris_graph might be more interesting if you are more interested in the trends than the current value.
plasma-google-spread.avi from Ben Martin on Vimeo.
Thursday, May 6, 2010
Plasma: Tree Shaped Eyes
After digging into KDE4's plasma a little bit it smelt a bit like an old friend. In Plasma you have one or more data engines, and each engine can have many sources. Each source offers a list of key-value pairs, which are updated at a nominated interval.
Normally folks think of filesystems as directories and files. But these days, you have to consider the Extended Attribute (EA) interface that filesystems offer as well. This makes a filesystem much closer to a large XML repository than just a collection of files accessible through a tree namespace (the directories). In libferris, each EA key-value pair can also tell the developer/user what schema that value has. This closes the gap between what a filesystem is and what a plasma data engine is just a little bit more. In fact, one might think of a plasma data engine as a virtual filesystem with a touch of extra stuff to allow a plasmoid to poll the data engine easily. This is not to detract from plasma at all, saying its "just a filesystem" means it is like postgresql, xml, or emacs to me ;)
For example, to see some current weather using my ABOMiNation plasma data engine and libferris (dev trunk), I can see the wind and also what type of value that EA or data engine key-value is:
One major upshot of looking at plasma in this way is the major upshot of everything being a filesystem. I can "cat" values directly from a data engine and also use fls to inspect data engines and their values from the command line while developing. plasmaengineexplorer is very nice, but its a bit of a pain to use a GUI tool to test out if the data engine is working when you are in a compile, run test cycle. It is also really easy to pluck out data from plasma with libferris, for example, the above fls with a --xml on the command line will do what you imagine. And if you are a nepomuk fan, using fls --rdf will give you an RDF/XML file to enjoy.
I found a few of the data engines would crash if they are started with a QApplication that forces GUI to off. So I black list
s == "tasks" || s == "mouse" || s == "keystate"
in order to mount plasma at the moment. Also, I'm using the signal/slot callbacks to get at the source key-value hash because the immediate mode methods don't seem to want to work for me :/
Normally folks think of filesystems as directories and files. But these days, you have to consider the Extended Attribute (EA) interface that filesystems offer as well. This makes a filesystem much closer to a large XML repository than just a collection of files accessible through a tree namespace (the directories). In libferris, each EA key-value pair can also tell the developer/user what schema that value has. This closes the gap between what a filesystem is and what a plasma data engine is just a little bit more. In fact, one might think of a plasma data engine as a virtual filesystem with a touch of extra stuff to allow a plasmoid to poll the data engine easily. This is not to detract from plasma at all, saying its "just a filesystem" means it is like postgresql, xml, or emacs to me ;)
For example, to see some current weather using my ABOMiNation plasma data engine and libferris (dev trunk), I can see the wind and also what type of value that EA or data engine key-value is:
$ fls -l \
--show-ea=name,air-temp,wind-speed,wind-gust,schema:wind-gust \
plasma://abomination_observations/nnn1
nnn1 22 15 26 schema://xsd/attributes/decimal/integer/long/int
One major upshot of looking at plasma in this way is the major upshot of everything being a filesystem. I can "cat" values directly from a data engine and also use fls to inspect data engines and their values from the command line while developing. plasmaengineexplorer is very nice, but its a bit of a pain to use a GUI tool to test out if the data engine is working when you are in a compile, run test cycle. It is also really easy to pluck out data from plasma with libferris, for example, the above fls with a --xml on the command line will do what you imagine. And if you are a nepomuk fan, using fls --rdf will give you an RDF/XML file to enjoy.
I found a few of the data engines would crash if they are started with a QApplication that forces GUI to off. So I black list
s == "tasks" || s == "mouse" || s == "keystate"
in order to mount plasma at the moment. Also, I'm using the signal/slot callbacks to get at the source key-value hash because the immediate mode methods don't seem to want to work for me :/
Subscribe to:
Posts (Atom)