sgtpepper

Well, the idea was mainly to make 'Recent Files' more "intelligent" by adding functionality.

Admittedly, it wouldn't be as simple as it is now anymore. But in its present state it is so damn simple I find it hardly usable...

keep record of not only 10 or 20 accessed files (a search function for only a few items of course wouldn't make sense), but maybe a hundred, or hundreds of them -- but *NOT* show them all at once, rather those which met certain criteria

let collect KDE enough information about those files (i.e., how often a file has been accessed) to sort and categorize them in a customizable way

Store the exact position where a file has been left, in order to resume there later

Interface design is always a matter of taste and it's hard, maybe impossible, to find a consense which fits all needs. A good way would be, imho, to have sensible defaults, but still offer "advanced users" the possibility to tweak it according their specific needs...

If you don't like the search bar, you would easily be able turn it off via context menu.

You would not need to have it on the K Menu.
Even now you can turn it off and add it as a Special Button to the panel instead.

And if there were a KIO slave to managed and access Recent Files, you would have a stand-alone application, and this application would be Konqueror

greets - Aug 09 2004

Oh, and thanks for the positive feedback! - Aug 06 2004

So, I don't know much about Reiser4, except for its extensibility throuh plugins and ability to store meta-data on file-system-layer, but what I'd like to know is:

How does one bundle files together with their metadata, for instance to transfer them to a filesystem not capable of handling meta-data or to send them over a network?

Thanks in advance... - Aug 06 2004

I think there's no reason to stress one's nerves by using this feature.

In contrast to Gnome's design approach "Simplify everything into oblivion" , in KDE appears everything as complex or as simply as I want it to be. So you would perhaps be able to

Turn URB Storing off completely
Turn it on or off only for specific fily types/specific attributes
Manually clear the URB for a file
Let the application handle it appropriatly (i.e., a media player would store an URB for that file, if the player quits in a state of being "playing" or "paused"; but if it exists in a state of "stopped", it would not store it ... something like that)

Actually, my guess would have beem that KDE's .desktop files are much lighter than e.g. Gnome's gconf, since on the one hand, the former uses simple = pairs, the latter uses XML, which might be bigger (having to every tag) and slower to parse (don't flame me, I am not a coder!))

But of course there are much better ways to store meta data! In fact, I just came up with this .desktop thing 'cause I tried to think of a simple quick'n'dirty hack to the existing system -- in order to put something here :-)
GNOME Storage would be great, if, well, if it weren't GNOME Storage. No trolling here, but I think it would be really nice to have such a metadata management backend as Desktop-Environment-/Widget-Toolkit-independent and even as cross-platform as possible!
Apple (or Google) could have sponsered it and contributed to it, and finally implemented this instead of their Spotlight... then, being network-transparent as it is, KDE, GNOME and Mac OS X machines on a network could share and search the same meta data...!
This network does not even have to be a LAN. Think of the Internet! I think of a seperation of Private and Public Meta-Data, whereas the latter could be stored as a hash of checksum and metadata on a global database server, helping others to identify their files and collecting information about them.. well, errh.. apologize... some wet geek dream of mine... ;-)
Where was I? Oh, yeah... a better Meta-data backend would be ... better.

(Don't know much about Reiser4, though...)

Thanks for listening... :-) - Aug 06 2004

Well, I especially like the idea with the KIO slave! That way 'Recent' entries could be consistenly accessible within every KDE application, also providing Konqueror's abilities to manipulate themn a convenient way (searching - as you said, also renaming, editing meta data, chosing an application to start it with, etc. ).

And as a global 'Recent Documents' list, or "URB-List", would automatically get sync'd, these changes would be instantly visible to all other KDE applications.

(It's really a shame that I'm such a lousy coder! :-)
I'd really like to see such features asap...) - Aug 06 2004

Well, the -i switch is used to edit files with sed "in-place", that is: without having to make the changes to a temporary file and then overwriting the original with it... pretty convenient, I thought.
Since I am using GNU sed version 4.0.9 from Debian SID, I guess this feature is simply not yet supported in earlier versions. :-/

However, the more I look at it, the more it bugs me how bad the script is designed. At the current state it relies on 8 external utilities, in many cases for doing very small things that Bash is probably able to do on its own.
I just started with Bash scripting, or more or less programming in general, so there is still much to learn.

Also, I think it is a very poor idea to actually rename the Desktop files, because it leads to many problems (i.e., Icon positioning). I just found out that the script could simply manipulate or append an entry "Name=Volume Name" to the Desktop file for the same effect...
So I am looking forward to do a major re-write asap (at the weekend).

bye - Jun 08 2004

...erm... well, no. :-D
Though I'm glad that you like it and that it works for you, it is still nothing more than a simple Shell script and should thus be considered a quick'n'dirty workaround, until the developers integrate this feature in a more "sophisticated" way.

However, I'll try to improve it further ( i.e., to support icons embedded in .exe and .dll using the 'icoutils' ), but mainly in order to learn Bash scripting, and hopefully Perl, while at the same time creating something useful.

Thanks for your comment!! :-) - Jun 08 2004