'Type Manager' The File Manager of Tomorrow? 321
IceFox writes "In the past few years many of us have been introduced to a new type of application, the Type Manager. Most of us are familiar with iTunes, but there are many other Type Managers out there that are gaining market share and a rabid fan base of users such as digiKam and amaroK. Type Managers seem to have that magic combinations of features that makes users love them. I have been taken a closer look at the Type Manager, what makes them so usefull, what they really provide for the user and came to some surprising results. After creating a list of all the traits of a Type Manager I was able to define exactly what a file manager should be and discovered that there are in fact many partial Type Managers out there now that implemented only half of what makes up a full Type Manager."
type manager ? WTF ? (Score:2, Interesting)
who the fuck gave this guy a license to make up new technical definitions on the fly ?
iTunes (Score:1, Interesting)
before iTunes I used Musicmatch on Windows which I liked a lot because of its library management, though it started getting bloated towards the end (bloat doesn't mean adding lots of features, it means adding features at the cost of ease of use).
Re:Move Along (Score:2, Interesting)
seriously, not trolling, but this really isn't that big a deal to do. most jukeboxes do this for you automatically anyway. Maybe not on linux - i don't know - but jeez even wmp does this. Are we really getting that lazy. Next your gonna tell me you code in JAVA and forgot C.
Assumes Type-based work (Score:5, Interesting)
My friend had basically created a Type Manager-like approach. I thought it was crazy because the engineering projects that we did used multiple files of multiple types. On his system the files of any given project were scattered across all these type-based of folders.
My point is that Type Managers can be very useful if a given activity only uses one application or type of file (e.g., rip/mix/burn/listen with music). But when the activity spans multiple types it drives the user back to using a general file manager. In such situations, existing Type Managers fragment the user's access to files and become a hinderance if the project's files are scattered across an email client, a photo manager, a sound file manager, etc.
And I thought a type manager was... (Score:3, Interesting)
Adobe Type Manager 3.0 Easter Egg:
Open Help/About, double right-click on it and will see the designer's photograph. FUN!!!
KimDaBa (Score:2, Interesting)
From the website :
Check out KimDaBa Demonstration Videos [kde.org] for details
Re:Well your Type Manager... (Score:2, Interesting)
$ TM=`grep this_article -ioe 'Type Manager'|wc -l`; WC=`cahis_article|wc -w `; echo print\ \(\($TM/$WC\)\*100\) |perl
4.76190476190476
It wasn't that often. only 4.76% of his total words were Type Manager. Of course that is 7/12 of his lines.....
*yeesh*
Re:wrong (Score:2, Interesting)
OS/2 used to be great at this sort of thing! (Score:3, Interesting)
One extreme example of exactly what this article is talking about was RexxMail [degeus.com]. From what I understand, instead of having a mail program with a dedicated custom interface, the developers of RexxMail simply extended the standard folder to list files of type email so that you can see the To: From: Subject and so-on in the view. When double clicking the file, it would open it in an appropriate editor and provide different options. This way you could use all the power of the Operating System's file system and folders to manage your email without having to learn some completely different interface that insisted that your email go in some specific place. Very cool.
Type Managers? Just one possibility (Score:3, Interesting)
- Location has been used for decades (flat filesystems are not that common today)
- Content type is used to associate actions but BeOS live queries shows the way to spread its use. Nautilus specific views is another form
- Properties is the ability to query based on some properties included in the data (Exif, MP3 tags,
...) Already available but only for certain data. There is not yet a general way to deal with properties.
- Tags have prove themselves usefull for links (del.icio.us) but could be used for any file
- Computed values are special values that are maintained from the data (thumbnails,
...). They are similar to properties but are computed instead
- Full indexing (Google desktop, Beagle,
...). Also include the transformation of data to text (Google images)
- Recommandations is the way to ask other people their opinion about a specific chunk of data
There is no single way. All of them seem interesting and I try to implement them in JDistro [jdistro.com]. However, support from the filestystems (inotify and al.) or from the databases (triggers) are required to make them viable. In summary: I don't think Type Managers are the future, Data Managers are.Re:wrong (Score:3, Interesting)
It would look something like this:
file.mp3
file.mp3/Artist
file.mp3/Year
So that all the usual tools would work as you would expect.
Re:wrong (Score:3, Interesting)
Now you have the basic building blocks for building a real user interface. Anything on your file system replacement can now be queried by the system for all meta-data, and data, and incorporates all of the methods required for doing this.
At the very lowest level, you still have files as a collection of bytes. The important difference is that nothing that the user interacts with should be aware of this lack-of-abstraction.