Fileselector with meta-data

Desktop Concepts

Source (link to git-repo or to original if based on someone elses unmodified work): Add the source-code for this project on opencode.net

0
5.0
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:

14 years ago

-------------
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*

rhorn

14 years ago

I like the idea, but this is one of those things that needs to be an advanced feature that's turned off by default.

Report

C

Superstoned

14 years ago

well, it probably could be integrated in the search KIOslave. and that whould be great, whoulnt it :D

Report

C

Superstoned

14 years ago

like to add the search should include subdir's by default...

Report

starbase218

14 years ago

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.

Report

cies

14 years ago

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

Report

MOD

leinir

14 years ago

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...

Report

C

Superstoned

14 years ago

I can't really picture what you mean... ??? you go to a certain 'map' (eg search://) and you see a search screen?

Report

MMax

14 years ago

That would be werry cool stuff!

Report

TimeRever

14 years ago

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.

Report

chuliomartinez

14 years ago

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.

Report

14 years ago

-------------
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*

12345678910
product-maker Count: 4 Rating: 5.0
File (click to download) Version Description Downloads Date Filesize DL OCS-Install
Pling
*Needs ocs-url or ocs-store to install things
Details
license
version
updated Dec 03 2004
added Jul 13 2004
downloads today
0
page views today 4
System Tags concept ui