Last time I presented the work Adam Kidder did on Nepomuk virtual folders in the GSoC. Today the story continues with the work by Alessandro Sivieri, my second GSoC student.
Whenever we handle files on the computer we need to bother with folder structures and file names. We need to come up with good naming schemes which allow us to find our files. We need to decide several times a day in which folder a file should go – should it go into folder A or B or should I create a subfolder? In the end there is always a little bit of chaos, even with the most structured minds. Alessandro tried a different approach in his project: save and load documents based on meta data and annotations rather than file and folder names.
This is not an easy task but I dare say that he succeeded. Alessandro created two new dialogs for saving and loading documents (we do not talk about files anymore – way too technical). The saving dialog allows to create arbitrary annotations for the document using the Nepomuk annotation plugin system which also brings in Scribo text analysis features. The loading dialog on the other hand uses a fancy filter system to narrow down the list of documents to open.
Saving Documents
We start by looking at the document saving dialog. Our example is KWord from which we want to save a fancy little text document. (No, it is not a test document, I really wrote this, this is real data, I assure you! … Yeah, OK, I admit it, just random words…) Hitting the save button opens up the new smart save dialog as can be seen in the screenshot below.
Smart Saving of a KWord document
The first thing we notice is that there is no filename and no folder selection. Name and folder are selected by Nepomuk. However, we get to give the document a name (it makes things much easier for us later on) and a description (in a future version applications will be able to prefill these fields with some meaningful defaults). But the interesting part is the meta data. The dialog suggests certain possible annotations which we can approve). Below the recently used annotations we have the possiblity to add any annotation we want through the existing Nepomuk annotation system. Last but not least we can give the document a type. This type does not identify the document on a mime-type level but much more real-life oriented. The idea is that users either define their own types based on pimo:Document or use ontologies that provide them. Typical examples include invoices or letters or project descriptions. This way documents are saved on a much higher abstraction level than with the classical file chooser: instead of a text file we save an invoice.
Once we specified the meta data we want to apply to the new document and hit the save button the smart save dialog generates a folder and file name and saves the document. We do not need to care about the location.
(Hint: there are certainly situations in which we want to use the classic file chooser. That is why the smart save dialog allows to switch over to the old ways by the simple click of a button.)
Loading Documents
But if documents are saved in some random folder which we do not know, how do we find them again? Well, that is the real beauty of the new approach. The idea is that you tell the open dialog what you want to open by specifying some details that you remember.
Let us have a look at the smart open dialog as it opens from within Okular.
We see two main views: on the left hand side we see a list of filters and on the right hand side we see a long list of files/documents. This might look overwhelming in the beginning but wait until we specify the first detail about the document we want to open: we tell the dialog that the document has mime type image/png (Yes, in the future this will look less technical) and the file view changes only showing png images.
These are still way too many to search for the one we need, so we give more detail. We remember that we accessed the document sometime this week:
Again the list of files is changed and now after only choosing two filters we are down to seven documents to choose from. Although this would be enough we do one better just to show that the filter system obviously also includes manual annotations such as tags:
And after activating the tag filter we are down to a single document. Nice, isn’t it?
A Few Technical Details
There are a few technical aspects worth mentioning about Alessandro’s work.
First of all: he makes direct use of Adam’s work on the virtual folders. The file list on the right is a simple KDirModel listing a nepomuksearch:/?sparql=… query. I find this very nice as my two students shared knowledge and discussed their work to find good solutions to their problems.
The second thing I find important is the creation of the filter list. The list of filters is created dynamically based on the existing annotations of the files in the current selection. In essence the idea is to only show filters that would actually change the list of available files (as you can see in the last screenshot this does not work 100% yet but we are close).
The GUI is obviously a prototype and we hope that you will give feedback and ideas to improve its usability. As Adam, Alessandro will continue working on KDE and Nepomuk and the smart file dialog will evolve until KDE 4.4.
Try It
To test the smart file dialog you need three things:
- My kdelibs patch which makes the KFileDialog pluggable. This is actually a very simple one as the file dialog already loads the backend from a separate lib. While you are on it, please review the patch so it can get into KDE 4.4.
- The Nepomuk-KDE playground module which also contains the smart save dialog. I recommend installing the whole module as the smart save dialog makes use of pretty much every Nepomuk lib available.
- Tell KFileDialog to load the smartfilemodule instead of the default by adding “file module=smartfilemodule” into the “KFileDialog Settings” group of kdeglobals.
Obviously nepomuk needs to be enabled for it to work. Have fun.
Trueg's Blog 
This is a big change from current file-saving/loading. As a consequence this just must lead to flame-wars.
However I know enough people that are incapable of finding downloaded/saved documents by file-name. This is probably one of the reasons “Desktop” became so popular. They were finally able to find their stuff.
So as a conclusion: keep up the good work, even if you will (probably) get flamed to death ;)
I am ready for the flames for two reasons: 1. I am really convinced by this approach and 2. because of the little “go back to the olden days” button. :)
Great, this could really be useful. Especially considering that “normal” applications only support a given set of mimetypes, hence the default list would shrink quite a lot.
Hope this matures even more, looking forward to use it eventually!
Pingback: Chimaera & Bellerophon » Blog Archive » La fama mondiale si avvicina…
Organizing files using directories doesn’t work for me (most often I have two or more directories where the file belongs…).
This is exactly what I’ve been waiting for!
this is the end of times ! finally :-)
i do not have to care anymore in which folders to put the files
and keep rearranging them all the time to meet my ever changing needs
i use/enjoy that approach in Digikam. please have a look there and see the useful approach they use to manage images with Tags. (Search,filter,MetaData…)
beautiful work !
this is really great stuff !
Perhaps meta and file saving should be combined? People are used to save files into directory structures. So why not offer the possibility to choose a directory to save into with a filename as before, including tagging and describing the files?
The advantage was, that you can access these files much better with applications that do not support the meta-document-chooser. Or where can you find the automatically chosen nepomuk-directory and what is the file named like? It feels a little strange to trust a black box where the documents are put into.
But nevertheless it is a very interesting approach and maybe it is _the_ future way to handle content. But I have to get used to this a little bit.
Revolutionary. I really love this concept. As we progress and the amount of data we create/store increases, this seems so logical for management.
First of all congratulations and thank you very much to you and Alessandro!
I really do like this way of working, and not taking care of anything but the real work, but let me write some comments:
1. It is OK that you don’t use a filename anymore, but at least, every document has to have a Title, so if we introduce the title in a search box (or any words of it) it will automatically appear (or be sorted)
2. Instead of having 1000 mimetypes it will be better if we only have also tags as “Images”, “Videos”, “Music”, “Documents”… (This could be also applicable to the folderview plasmoid)
3. I would also like to have special folders automatically created in Dolphin, like when you use tags: “Yesterday”, or “Date”, or “Images”… in a fancy way.
And as flo says… get ready for the flamewars hehehehe! I think it is a very good and radical change that is very needed.
Nice work!
1. We have the name which is the same as a title. That is already searchable.
2. We already have these types in the NFO ontology. Currently the dialog shows both the mime type and the NFO type. But as mentioned in the blog we will improve this and make it more readable mostly relying on the NFO types rather than the mime types.
3. That is technically already possible. In KDE 4.3 you have three test folders with stuff like yesterday’s files. But with Adam’s work these are configurable. Thus, adding a folder with your images from last week will be very easy.
Oh this is great stuff!! Can’t wait to see it in action. Kudos of course to your students!
As for saving, I’d say solely automatically calculating the path without user input will cause problems. As users will always think in terms of “boxes” to put things in. And be it only high level boxes. E.g. you might have a highly sophisticated system for “saving” and finding all the things you have in your apartment so that you don’t have to think about it. But surely you don’t want your clothes to be put somewhere in the kitchen, your cups in the bathroom or your toilette paper in the living room. I think it would be good to able to combine the tagging with a self defined saving path. Think of a project, and for practical reasons you want everything of that project in a single directory. IMO putting things in boxes, be they wooden in the real world or folders on the harddisk, is somewhere deeply in us all. So ideally the new technology should be nicely integrated with “the old way” of storing things. And by that I don’t mean one XOR the other.
So default could be to generate the saving path under “~/Documents”. Alternatively the user could specify a different top level folder under which a path is created (e.g. I keep my pictures separate from “normal” documents, but don’t want to bother with the details of choosing a saving path). And finally the user might want to explicitly specify a folder to put the file in and still have the ability to add tags, description etc.
Well, you still have boxes, even more so files can be in more than one box. They can be in the images box and in the project X box and in the “files from last week” box all at the same time.
You just need to free yourself of the file system restrictions and also browse your files/documents in virtual folders.
Sure, I guess *I* can free myself of this, to a certain degree at least (see below). But there are real world restrictions that won’t. For instance there are lots of apps which have never heard of such weird things like tags :) And probably won’t in the near future, if at all. Think Emacs, gcc, latex or basically all other non KDE apps. You want to sync or version control your project? This is all just file and directory based. Also those apps will create random files with no tags at all. How are you going to find these?
And as I wrote, I consider it helpful to not have to think about paths. Still I would like to control organization at least at a coarse level. With boxes I meant “real” boxes i.e. directories. So with my example I would let nepomuk take care of how to store and retrieve my clothes. There might be virtual boxes like: Everything in my apartment that I need for a week of vacation, including clothes. But I’d really feel better if I know, the clothes are *all* in the big wardrobe in my sleeping room and not spread across the entire apartment ;)
Right, the situation I am referring to is indeed the “perfect” world where there is only KDE. ;)
In practice we will have to come up with a rather clean internal folder structure that is also user-readable.
Actually this is a topic that Sebastian Faubel is an expert in. Once he publishes his diploma thesis we will know more. For now I keep my mouth shut. :)
Even if there is only KDE, how do you find these files and folders when using terminal applications? I also think that combining file/directory structure with tag/metadata structure is the way to go.
There is always fuse-kio. ;)
This meta data system seems to be very useful. But does it allow hierarchical structure? For example, in file system, I may have a folder like “studies/computer_science/course_ABC123/exercise_2/”. Then, for example, if I need to know which courses are computer science courses I can look which folders are inside the folder computer_science. Can this be done with this meta data system?
This is trivial. Even using the most simple tag system you can tag files with “studies”, “computer science”, and so on. Then filter by one or multiple of those tags.
Since in Nepomuk we have much more than only tags it can all be done.
In tag system I can tag files as “computer science” files, but in my example I was looking for “computer science” folders, not files. So in corresponding tag system I would be looking for tags that are itself tagged as “computer science” tags. So do you mean that something like this can be done with Nepomuk, since it has more than only tags?
Yes, this is perfectly possible. All we need is a gui to allow it. Well, actually you can already do that. Search for the tag with the search kio slave and then tag that tag. Then you should be able to do something like “hastag:(hastag:foobar)” which should give you all files that are tagged with a tag that is tagged with “foobar”. However, this is not possible in the filter view yet.
This is certainly an interesting approach and one of the things which could really change the way we use a computer.
However, I think it needs some time to mature before it can really replace the existing system. For that, it would need to be able to deal with all kind of files and there should be a system/program which allows to open all kinds of documents (like Dolphin, but with a metadata based system).
One problem I see with this system is that it is really hard to delete documents you no longer need. With folders, I can go through the folders and decide for every file if I still need it. When I choose files based on metadata, it’s hard to get an overview of all files and to sort out the ones I don’t need anymore. However, I’m sure there are solutions for this problem, and if we can solve it, I’m really looking forward to using the new system.
Same answer as I gave to redm: you have virtual folders from which you can delete files just as easily. I really think that this problem is a virtual one based on the fact that we are so used to physical folders (although physical is not even true as the file system also stores the data anywhere and just presents to you some folder structure. This structure is not that different from the new one, except that the new one is more flexible.)
I think that a good system of virtual folders and a good application for browsing them can at least partially solve the problem. I still think that it is harder to go through the files if they are in virtual “boxes”, as you can never be sure of having seen all of them, as tags may be missing/faulty. It is possible that a file is in several boxes you are looking through, but it may also be possible that a file is in none of them (e.g. if you have clicked the save button too quickly without checking the metadata. For me it’s the same problem in applications like F-Spot, which rely on tags only. Some files might just not have the tags I expect them to have (same goes for music files) and thus pass under your radar when going through your files.
I am confident that these problems will be solved or at least minimised in the future (maybe with a virtual folder for files which could be lost). What we need next IMHO in order to really start using this way of saving/loading would be a document browser, where you can find all files stored by metadata, like the open dialog but not program specific.
Continue to rock!
What about files generated by apps which have no idea about tags? And you have no idea which files are generated either. With a search you’ll only find what you are looking for, which implies you have to know what you are looking for first. With a directory you can simply look into it and you’ll see *everything* in it, whether you know about it or not, whether you were looking for it or not.
So in reality it won’t ever be directories XOR tag, but both together. Ideally nicely integrated.
Well, Strigi still picks up those files and you can at least filter by dates and metadata embedded in the file.
hello!
I agree with the ideas of previous speakers. I think combining the two dialogs is much better!
But I have a interesting question: what happens if all my nepomuk data (e.g. ~/.kde4 folder) gets lost? This situation must be considered!!! Typically, files are backed up. But hidden folders not.
There are plans for a backup service which handles exactly this situation. Also at some point metadata should be backed up together with files. I did some experiments with that already using an rdf file on usb sticks when copying files. But nothing is mature yet. Help very welcome. :)
My proposal is somewhat similar to the one of Juan – it does go a bit fruther, however: I suggest using categories of mimetypes. E.g. there are “Images”, “Music”, “Videos”, “Documents”. Some programs would support only one of them (e.g. Gwenview only supports “Images”, while others would support 2 or more (Okular supports “Images” & “Documents”). The categories should be represented by buttons, arranged in a grid. Once you click on them, they slide to the left, a filter gets applied (e.g. “Images includes everything from .png to .tiff”) and the dialog presents you some sub-categories. You can then either use them or already select a file on the right. These categories could be:
Images: Filetype: gif, png, jpg, tiff, whatever / Resolution: (a slider you can drag to the right, ranging from 1 Megapixel ’till endless)
Music: Filetype: ogg, mp3, m3u, etc. / Length: (a slider you can drag to the right, range is 00:00 ’till endless)
Videos: 3gp, mp4, etc. / Length: (a slider you can drag to the right, range is 00:00 ’till endless)
Documents: Text (includes .odt, .doc as well as .txt & .pdf, if the program supports them (the program itself specifies only the file types it’s able to open, the dialog then adopts to it in a smart way, adding/omiting categories on the fly), Spreadsheet, Presentation, etc. / Author / Size (only shown after selecting a category like e.g. “Text”; allows the user to specify something along “10-15 pages”, “more than 20 slides” etc.)
The general idea is that as soon as you select a category, it fades out and one or multiple sub-categories are shown. If you select one of them (e.g. Text), it also fades out, possibly revealing other sub-categories while former sub-categories such as “Author” persist. hm, maybe a bit of drawing makes it clearer:
Document type
—
Music Videos
Documents Images
-> User clicks Documents
Documents
—
Text | Author
Presentation |
Spreadsheet |
–> User clicks Text
Documents
—
No. of pages: | Author
It might sound a bit complicated, but I’m convinced using it would be dead easy + damn fast :)
Hope that helps a bit, I really appreciate your work!
PS: Thanks for not making registration (or logging in) necessary for posting, I wouldn’t have commented otherwise (I don’t have OpenId nor do I have a WordPress account or whatever or do I want it).
This is very cool. But for it to truly shine, we need a fantastic GUI. This is one of the things Apple knows how to do right in my opinion (think: iPod (what makes it different from other mp3 players?), Time Machine (just another backup solution?) etc.).
I understand that the GUI comes later, but here are some suggestions for the open file dialog:
In my vision it’ll look clean and hide all technical details. It’ll offer two modes: search and browse.
Search mode – I want to be able to write “lab report from yesterday” and it’ll list the lab reports I edited yesterday. Or maybe “letter from Anna”, “Endlessly by Muse” etc. Most of the times I know what I want to open; it would be awesome if my computer understood it too.
The search field should receive focus by default, to make it fast for those who know how to use it. It could also offer an autocomplete/suggest feature.
Browse mode – Much like current “filters”, but easier to navigate. My idea is to have x columns of list views (where e.g. x = 3), much like this: http://dl.getdropbox.com/u/1218437/example.png (but nicer looking with icons etc.).
Note that the order is important – by selecting an item/items in the first list, you filter out possibilities from the other two lists. For example we could have something like
[Time modified][File type][Tag]
In your example I would choose “This week” -> [show only file types modified this week in 2nd column] -> “Image” -> [show only tags of images modified this week in 3rd column] -> “Nepomuk”.
While this approach offers slightly less power, I think it’ll look much nicer and make it easier for normal users. Rather than telling them “here are your options – do whatever you think you need to find the file” my approach guides the user: “so first you have to choose a time (or anytime), then a file type (or all file types) and […] and I’ll see if I can find it”.
There is not only tags. tags are just an example. There will be much more. So I doubt that multiple panels is the correct solution. However, the search field would be great.
I still think showing everything in a long list is bad – it’s hard to know where to start. Or do you have other solutions planned?
The list order I wrote above was just an example – the last list could contain all the “extra” filters. The idea is that most users wouldn’t need them – in most cases it should be possible to find the relevant file(s) in x steps*. Therefore I think it would be good to have x (or x+1) panels instead of one huge list.
–
[*] Has there been any research done on this? Seeing those “answer 20 questions and I can guess which object you thought of” toys, my guess is that we don’t need more than 4-5 steps to reduce the results to a sufficient short list.
It certainly it something to investigate. Trying it should be rather simple.
I think this is fantastic work, I know Siv was worried about the non professional look of the demo panel, but I think the people here can see past that compared to less technical reviewers who are going to be worried about the boxes not lining up.
An awful lot of people have learnt the unnatural save panel, that only allows one grouping (the folder/subdirectory), so they will fear using something new, even if it is a better way to work. But you have addressed the Luddites with the file/folder view button. At school you learn: get a piece of paper, daub paint on it and it leaves a pattern that is very hard to change or remove, then you leave it to dry, and you can take it home. This is why I’m saying the save panel is unnatural, and that the document should be continually saved as you work on it. The going back to a previous revision (that version control give you), the only real world metaphor, I can think of, is the edit marks on a document for the typist to correct for the new version.
I think the save panel is too late for making (some of) these meta data (or tags) decisions, as you edit the document, as you type stuff in, the tag list should be visible and being built. If the phone is ringing, I want to quickly save and answer the phone. Hopefully there is plenty of automatic meta data, such as file type, creation date, version – sometimes you remove a major section from a document, but still want to peek at the document before the removal.
As software improves, voice, music and scene recognition will add meta data (or tags) for you.
If you start thinking of groups in which the document belongs, instead of one folder which gives only one group (you could link the one document to another folder, but this is unnatural), the intersection of a number groups singles out the required document.
A group can still be represented by a virtual folder, and the sub-folder gives you the intersection, but it does not matter if you choose group/folder A first with group/folder B as a sub-folder, or group/folder B first, with group/folder A as a sub-folder – this is not easy/possible with a real file-system directory tree.
really can’t wait to have this default – never ever having to check if the drive is full :) just save where there is space …
Oh, btw, how do you backup your documents? Where are they stored?
@ sebastian Benitez ,
i think you will backup by Tags not by Directories then (as Directory is only another form of Tag with with 1:n Relation) Tags is nothing more than n:m Relation
My ideas:
1 Filter path instead of check list. I mean you select filter and it is added to dolphin-like path. I don’t know if nepomuksearch kio-slave supports subfilters as subfolders.
2 Set of folders (could be called file resources) at filter path beginning
3 support for external storage of metadata for selected repositories (e. g. for removable devices as well as digikam albums ore amarok collection)
4 Maybe create something like akonadi for files with (nepomuk-tagged local files as main resource) providing (2) and (3)
The idea is to move away from the folder idea which is not natural to begin with. We are just used to it. New computer users, however, are not and will find a system along the lines of the smart dialog much more intuitive.
I dont see why we would need to create something like Akonadi for files, except if you mean the support of multiple file sources. The latter would be very interesting, if it allowed to integrate meta data from all sources.
I’m not quite sure why you think folders are unnatural. I mean… you might be right that there are better ways but they seem quite natural to me. After all, at home, I also keep my stuff in drawers, boxes, cupboards, and so on. This seems very natural to me and the folder idea is just bringing this concept to the computer (weren’t folders called drawers in Amiga OS?).
Now if I had a nice little fairy at home that could always find what I’m just looking for, I would welcome it. But I would still try to keep my stuff organized as before because what if the fairy got ill or suddenly left?
Don’t get me wrong, if you manage to develop your ideas so generally that it will replace file systems and I can also access documents in this way from the shell (and other DEs and maybe even other OSes), then folders might really not be needed anymore. But until then, I’d keep the folder structure and just add to it with Nepomuk. Just my 2 cents, though.
IMHO the comparision to drawers and boxes does not work. First of all you never have hierarchies at home. New users are completely overwhelmed by that concept. Hence the typical usage of the desktop: just throw it all in there.
As for the fairy: like I said in other comments you can look at the virtual folders as you do at the current “physical” ones. They are just one abstraction layer above the abstraction from the bytes on the hard disk (which are also saved all over the place). But yes, you are right, as long as we do not have this system in all applications (including non-KDE) we need backwards compatibility. (I am still thinking of that fuse idea…)
Well, it depends how you look at it. I have cables in a blue box in the second drawer of my big cupboard in the living room. So if I look for an USB cable there is kind of a hierarchy: ~/livingRoom/bigCupboard/secondDrawer/blueBox/usbCable.
I admit that this might be an extreme example but I still think that hierarchies are natural to a certain degree. However I agree that it is good if tools like Nepomuk help us to keep the hierarchies flat and simple.
At work I’d love to have Nepomuk. We have lots of measurement data and measurement protocols and it is a real pain to keep these organized and find them again. We now use an Excel Sheet that implements kind of a tagging structure for the important documents. But even if I’d love to tag them, I still would want to save them to custom folders. Normally, the data is created by programs that will create files with certain special names because later scripts will analyze the data and these depend on special file names. Maybe there are other ways to do this but I don’t see how having all this data in a single folder for different measurements would bring me any benefit. So again I want the best of both worlds, folders and tagging. :)
My few ideas:
1 Filter path instead of check list. I mean you select filter and it is added to dolphin-like path. I don’t know if nepomuksearch kio-slave supports subfilters as subfolders.
2 Set of folders (could be called file resources) at filter path beginning
3 support for external storage of metadata for selected repositories (e. g. for removable devices as well as digikam albums ore amarok collection)
4 Maybe create something like akonadi for files with (nepomuk-tagged local files as main resource) providing (2) and (3)
Great work guys! I just have a proble with this approach: It requires (at least it seems to) a lot more user input to get to a file. Anyway, could you tell us what will be the naming scheme for new files? I am worried with the access from “nepomuk disabled” apps and the command line access to these files.
Just some untested ideas to generate metadata for “un-enlightened” ;) applications. It is possible to introduce a level of redirection as is proven by e.g. AppArmor. To save time in the short-term, even AppArmor itself might be used in complain-mode. The resulting files would then be parsed and turned into metadata such as lastUpdatedBy: referring to a pimo:Agent and lastUpdatedWith: referring to an application. This would leave a “paper trail” that would make it much easier to find and/or destroy information e.g. pertaining to a project. The overhead of AppArmor is said to be “negligible”, and it can be turned off as well. A less sophisticated application that would only provide the redirection could be even faster.
Once I submited something to KDE Brainstorm that wanted you to have a look:
Move/copy “Recently used documents” into “Places”
http://forum.kde.org/brainstorm.php#idea39046
The link does not work. Actually links to the forums never work for me and I have no idea how to search by id.
Second try:
http://forum.kde.org/brainstorm.php?mode=idea&i=39046
The idea is that as we would want to have virtual folders anywhere, would do their best job at the “Places” panel used by Dolphin and the file open dialog.
“But if documents are saved in some random folder which we do not know, how do we find them again?”
You go to Open file menu of you desired app and click “Used today” (mean last 24 hours) or “Latest used” virtual folder in the “Places” panel. That would be the fastest way to find a file 99% of the times.
That virtual folder would be a default in KDE and introduce many users to the power of Nepomuk. Then they could create other virtual folders based on their preferences.
Do you ever use KickOff Menu to find latest used documents? I’m sure the answer will be no. Being able to find latest used documents is great but is not placed in the right place. In the KickOff Menu you expect to find apps. You expect to find documents in Dolphin and the open file dialog.
Well, I wrote this months ago and didn’t knew about Well adding a link to “nepomuksearch:/Recent Files” . In KDE 4.3 you could just add a link to “nepomuksearch:/Recent Files” in the places panel an have a new KDE killer feature.
I know there I can already do that, but is not a default, and having it as a default makes the difference between “What the hell is Nepomuk?” and “So Nepomuk is what allows me to find recent files? I use that function ten times a day!! What else can I do with it?”.
Second problem is that nepomuksearch doesn’t work in KDE 4.3. At least in Debian.
would love to have them as default. However, these queries (virtual folders) only work if Strigi is enabled and that is not the case for everyone.
So maybe if we enhanced the places view to support conditional places this would be possible… hm, I think this is a good idea. Will have to talk to Dolphin’s Peter about that.
What is fuse-kio?
Wow, great work!
Really interesting!
I rally hope that we will see these features inside dolphin or inside a “find file” dialog: you know, I’m not that kind of people that as first thing fire up Kword and *then* opens the file dialog… I find myself all the time in a dolphin window looking for a file and double clicking on it, or dragging it on a program to open it.
And after all, maybe we shouldn’t take for granted that people knows what program they need to open their documents…
Spectacular! Wonderful!
Finally an approach that might work for an organizational freak (and at the same time very messy person) like me.
Only 2 comments:
1. What about different filesystems… Some file I want to save on an external HD, some in sda1, some in sda7, … This needs to be possible (even more: this needs to be easy).
2. What about corruption of the metadata store? Since current filesystem hierarchy is so simple, fairly dumb tools can more or less recreate this structure, even after a fair amount of corruption. But in this scenario, I see lots of opportunities for major loss of (meta) data.
Pingback: What We Did Last Summer (And the Rest of 2009) – A Look Back Onto the Nepomuk Development Year With an Obscenely Long Title « Trueg's Blog