Description: I think meta-data will be used more and more (well, we also see mac and m$ think this - and other OSses have/had it already). with ReiserFS4, Linux will have state-of-the art meta-data capabillities - especially speed-wise.
when is it usefull? when you have a lot documents. so everyone needs it ;-)
Now, you organize docs in maps, and you use a (deep) tree. But what if you trew all your files in ~/documents, because you knew you'll still be able to find them easilly, while you dont even use propper naming? whoulnt that be usefull? thats where meta-data (should) comes in.
to take full advantage, there will have to be some reiserFS4/other meta-data-tools (storage!) KIO-slave, I guess.
And the file-selector needs a change!
This is just meant to make ppl start thinking about it - its not very good ;-)
but I think there should be something like this in KDE 4...
So please start thinkin'...
ps I'm no coder (yep another one just talkin' and doin' nothing, I'm sorry)Last changelog:
------------- Now KDE 3.4 gets close, and we have the search-KIO slave, I think we should ask if the searchproblem is solved, now, or not... the search KIO slave could give maps with certain content, as Leinir said. but whoulnt it be nice if the search could be a bit more customized, like you see in this screenshot? is that possible with a search KIOslave, or not? If so, that whould solve the whole problem for sure... and very clean.
Also, the search-KIO slave should be exposed to the users! most people dont know it, and if it gets more features, it should be more prominently available. some automatic narowing of the search whould be nice, too. its very cool now, that if you enter a name in the name dialogue, kde points to the file already. but this could be improved, if the dialogue could only show matching files. ---------------
- there should be more options, and I guess they should adapt to the choosen filetype. - I know a video is a bad example - a document whould be easier (you whoulnt really need to make a description). - I'm sure the options can be aranged, worded and in general made much better ;-) this is just an (bad) *idea*
Nice, but the same (and more) can be achieved once there is a KIO-slave for searching. This was discussed a little while ago on kde-usability. It would allow you to search from Konqueror or any file open/save dialog. The search results would show up as an ordinary filesystem.
GOOD IDEA!
"""
gg: search the net
&
search: sheet q1 expenses
"""
it could be searching 'intelligently'; i.e. using the locate-db, searching the man/info pages, starting with a search in the home folder, return executables (apps) and choose for one approach or an other when it is 'likely' to work like this.
GOOD
It could be a search kio that could be very capable, if it had a pluggable backend system... So that it would output the results in folders, one for each backend... This just hit me. Done this way, the frontend using the search kio could present the data in a good way to the user...
Someone before has talked about this, not the file selector but the concept itself, i think it's a very nice thing to Linux/KDE have, and to don't fall back to other OSs too (like it's very common...), but just as the same discussion the problem is the same, and i think it's a problem that will only be solved using brute force since... well the problem is that not all apps use KDE fileselector or KIO, there is a bunch of good apps writen in GTK that are making this kind of stuff hard to project cause if you write a document in OpenOffice.org or in GEdit it won't use KIO, nor KDE fileselector, so before metadata can be used we need a standard in terms of toolkits and other stuff.
I only hope thats the solution that will be used cause i don't wanna see this toolkit mess for a bunch of years again.
Maybe the a daemon could be running an watching changes to ~/docs and updating metadata on-the-fly? I know its ms indexing service way, but works, and the user can use any editor. For every filetype a "meta-dumper" app would be registered (much the same way as "open with" works) and off you go. Sure apps that care could call it directly, thus producing meta-data right after save, those which don't would be handled by the daemon.
KIOslave, or not? If so, that whould solve the whole problem for sure... and very clean.
Ratings & Comments
10 Comments
I like the idea, but this is one of those things that needs to be an advanced feature that's turned off by default.
well, it probably could be integrated in the search KIOslave. and that whould be great, whoulnt it :D
like to add the search should include subdir's by default...
Nice, but the same (and more) can be achieved once there is a KIO-slave for searching. This was discussed a little while ago on kde-usability. It would allow you to search from Konqueror or any file open/save dialog. The search results would show up as an ordinary filesystem.
That would be werry cool stuff!
I can't really picture what you mean... ??? you go to a certain 'map' (eg search://) and you see a search screen?
GOOD IDEA! """ gg: search the net & search: sheet q1 expenses """ it could be searching 'intelligently'; i.e. using the locate-db, searching the man/info pages, starting with a search in the home folder, return executables (apps) and choose for one approach or an other when it is 'likely' to work like this. GOOD
It could be a search kio that could be very capable, if it had a pluggable backend system... So that it would output the results in folders, one for each backend... This just hit me. Done this way, the frontend using the search kio could present the data in a good way to the user...
Someone before has talked about this, not the file selector but the concept itself, i think it's a very nice thing to Linux/KDE have, and to don't fall back to other OSs too (like it's very common...), but just as the same discussion the problem is the same, and i think it's a problem that will only be solved using brute force since... well the problem is that not all apps use KDE fileselector or KIO, there is a bunch of good apps writen in GTK that are making this kind of stuff hard to project cause if you write a document in OpenOffice.org or in GEdit it won't use KIO, nor KDE fileselector, so before metadata can be used we need a standard in terms of toolkits and other stuff. I only hope thats the solution that will be used cause i don't wanna see this toolkit mess for a bunch of years again.
Maybe the a daemon could be running an watching changes to ~/docs and updating metadata on-the-fly? I know its ms indexing service way, but works, and the user can use any editor. For every filetype a "meta-dumper" app would be registered (much the same way as "open with" works) and off you go. Sure apps that care could call it directly, thus producing meta-data right after save, those which don't would be handled by the daemon.