Description: I'd like to share some humble ideas of mine regarding KDE's 'Recent Files', 'Bookmark' and general file association management here. (Apperently it is slowly developing towards an interface for a meta-data based file system layer...?!)
Originally it was about a new 'Recent Files' menu, which is much more powerful and useful than the current one. This is shown in Screenshot #1
But more important is the idea this new designed menu depends upon: a new concept of storing bookmarks, according to which Bookmarks and Recent Files are no longer mere pointers to a file name, but rather to a position within the file!
This is what I pompously call "Universal Resource Bookmark", or URB.
Screenshot #2 shows on the top two more examples of meta-data-enriched filetype-popups.
Moreover, the other two snippets demonstrate in which way it could be customized in order to fulfill the (re)quest of uncluttering the menu
Screenshot #3 shows the modest beginnings of KIO Slave Interface mockup for accessing 'Recent Documents'
Some more details are described in the Proposal file, among many screenshots of the various interface features (still quite work-in-progress (except, I don't work on it very much ;-), and still not very clear.
Anyway...
Have Fun! Sgt.PepperLast changelog:
* changed the description
* reworked the 2nd screenshot to integrate new design ideas
I like the idea of sorting recent files by type or whatever. I am not to sure about the other. Having said that the improvment you made to the recent files should of been built into KDE in the first place.
Great work. Keep going
A search combobox in a popupmenu ..
Tooltips popping up above popupmenus ..
Menus that will hardly fit in a 800x600 screen ..
Well, you can implement that if you like, but doubt that i will ever use that, and I am against having that in the default kde menu (for everyone)
In my opinion, the recent files should not appear in a menu (the kde menu has already way too many items), but in a standalone application (used for browsing, searching, showing the recent files that are now invalid, etc).
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
I like it but the search bar and the sort by have to be marked differently. I wonder whether it is good to put that on the menu bar as an entry rather than on a context menu.
I wonder whether a search option will be really used. What I would like to see is a recent files
recent:// in konqueror that can be linked from the menu and provides all these nice options. don't overload the menu.
Recent files Categories like Video, Audio and so on are atz the wrong place.
I love this idea, I can't wait for it to be the next kde.
I would love to see the album cover and some info from the mp3 tags on the tooltips. That would be awesome.
I like the rounded boxes in the "recent:/" screenshot. However, the recent entry in the start menu is simply too crowded and confusing IMO. Less is more. You should try cleaning it up a bit.
Well, you can implement a database in kde. thats what macintosh did. easier whould be to add the database to the filesystem. thats what microsoft is going to do. the best (performance and flexibility-wise) whould be to add the data to the filesystem, which is an database itself: ReiserFS4.
I think this is a wonderfull idea. more meta-data in documents (like a undo/redo history, last position in file, etc) is nice I think, and this whould be an usefull way to use it.
Hmmmm hope reiserFS4 is finished soon... it can handle these kind'a things at virtually no performance cost (as opposed to the macintosh and microsoft solutions to this, resp seperated database and database layer on filesystem).
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...
well, afaik, reiserfs could simply do that using seperate files. file attributes are kind'a saved as files, too. or to state it different, you might say there are no files in reiserFS, just entries. the nice performance trick is that it doesnt matter how many files you put in a map, for performance. so you can just make new entries as much as you want, performance does not decline. every piece of meta-data is an entry. like the files. and reiserfs treats them all the same. when you copy them, I guess its easy to simply compact the meta-data-entries in a file, and extract it when putting back on a reiserFS system. the files could be deleted, indeed, but if the windoze user doesnt, the meta-data will be saved and restored.
It's good, but I also have a couple of ideas:
1. implementing recent as a kicker applet or button, which pressed opens a simple window that shows icons (with metadata tooltips) and a search bar or a filter.
2. implementing recent as a KIO slave recent:/ and use the konqueror's search and filter capabilities.
Making the Kmenu able to embed kio's (it's difficult to write, I mean being able to browse a kioslave, for example smb:/, within the menu) it's possible to create a recent entry like yours, what do you think?
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...)
I like the sorting idea. I think it would realy make the "recent files" usable. At the moment I don't use it at all.
The search idea is not bad either. How about searching for the file I have opened 2 days ago in program XYZ?
URB sounds sweet, but could also be realy enerving. Imagine watching the first half of a movie and then wanting to watch it again with some friends.. where will it start?
And I don't think it's a good idea to clutter the .desktop files too much, cause it would make the whole thing slow.
But still, I realy hope to see some or most of these things in kde4 perhaps.. perhaps with a switch to just switch it off?
Greets
Tom
Actually, I think a pointer to a position in a file is interesting, and at least to me, innovative in regards to this. A simple "Restart" or "Resume" location of media files would fix your concern, I think.
Definately a much better "Recent Docs" proposal. I also don't use mine much at all, simply because it's not very helpful with the amount of docs and files I access in a typical work day.
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... :-)
Ratings & Comments
18 Comments
The design proposal is good, where can one download the application
I like the idea of sorting recent files by type or whatever. I am not to sure about the other. Having said that the improvment you made to the recent files should of been built into KDE in the first place. Great work. Keep going
A search combobox in a popupmenu .. Tooltips popping up above popupmenus .. Menus that will hardly fit in a 800x600 screen .. Well, you can implement that if you like, but doubt that i will ever use that, and I am against having that in the default kde menu (for everyone) In my opinion, the recent files should not appear in a menu (the kde menu has already way too many items), but in a standalone application (used for browsing, searching, showing the recent files that are now invalid, etc).
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 greetsI like it but the search bar and the sort by have to be marked differently. I wonder whether it is good to put that on the menu bar as an entry rather than on a context menu. I wonder whether a search option will be really used. What I would like to see is a recent files recent:// in konqueror that can be linked from the menu and provides all these nice options. don't overload the menu. Recent files Categories like Video, Audio and so on are atz the wrong place.
I love this idea, I can't wait for it to be the next kde. I would love to see the album cover and some info from the mp3 tags on the tooltips. That would be awesome.
I like the rounded boxes in the "recent:/" screenshot. However, the recent entry in the start menu is simply too crowded and confusing IMO. Less is more. You should try cleaning it up a bit.
But I don't think KDE can do all that by itself, I think it needs the help of both the filesystem and kernel. I'm I wrong?
Well, you can implement a database in kde. thats what macintosh did. easier whould be to add the database to the filesystem. thats what microsoft is going to do. the best (performance and flexibility-wise) whould be to add the data to the filesystem, which is an database itself: ReiserFS4.
I think this is a wonderfull idea. more meta-data in documents (like a undo/redo history, last position in file, etc) is nice I think, and this whould be an usefull way to use it. Hmmmm hope reiserFS4 is finished soon... it can handle these kind'a things at virtually no performance cost (as opposed to the macintosh and microsoft solutions to this, resp seperated database and database layer on filesystem).
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...
Oh, and thanks for the positive feedback!
well, afaik, reiserfs could simply do that using seperate files. file attributes are kind'a saved as files, too. or to state it different, you might say there are no files in reiserFS, just entries. the nice performance trick is that it doesnt matter how many files you put in a map, for performance. so you can just make new entries as much as you want, performance does not decline. every piece of meta-data is an entry. like the files. and reiserfs treats them all the same. when you copy them, I guess its easy to simply compact the meta-data-entries in a file, and extract it when putting back on a reiserFS system. the files could be deleted, indeed, but if the windoze user doesnt, the meta-data will be saved and restored.
It's good, but I also have a couple of ideas: 1. implementing recent as a kicker applet or button, which pressed opens a simple window that shows icons (with metadata tooltips) and a search bar or a filter. 2. implementing recent as a KIO slave recent:/ and use the konqueror's search and filter capabilities. Making the Kmenu able to embed kio's (it's difficult to write, I mean being able to browse a kioslave, for example smb:/, within the menu) it's possible to create a recent entry like yours, what do you think?
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...)
I like the sorting idea. I think it would realy make the "recent files" usable. At the moment I don't use it at all. The search idea is not bad either. How about searching for the file I have opened 2 days ago in program XYZ? URB sounds sweet, but could also be realy enerving. Imagine watching the first half of a movie and then wanting to watch it again with some friends.. where will it start? And I don't think it's a good idea to clutter the .desktop files too much, cause it would make the whole thing slow. But still, I realy hope to see some or most of these things in kde4 perhaps.. perhaps with a switch to just switch it off? Greets Tom
Actually, I think a pointer to a position in a file is interesting, and at least to me, innovative in regards to this. A simple "Restart" or "Resume" location of media files would fix your concern, I think. Definately a much better "Recent Docs" proposal. I also don't use mine much at all, simply because it's not very helpful with the amount of docs and files I access in a typical work day.
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... :-)