Benjamin Meyer on Type Managers
Wednesday, 16 November 2005 | Jriddell
KDE developer Benjamin Meyer explains the concept of a Type Manager as a new form of specialist file manager application. "In the past few years many of us have been introduced to a new type of application, the Type Manager. There are many Type Managers out there such as digiKam and amaroK that are gaining market share and a rabid fan base of users . Type Managers seem to have that magic combinations of features that makes users love them. I have been taking a closer look at the Type Manager, what makes them so useful, what they really provide for the user and came to some surprising results." He concludes that Type Managers are part of the future of the desktop.
Comments:
No links? - Bram Schoenmakers - 2005-11-16
Did you forget to include some links or is this a quicky on it's own?
Re: No links? - Jonathan Riddell - 2005-11-16
Added
What does that mean? - furanku - 2005-11-16
amaroK and digiKam integrated in the Desktop? Aren't they today? What has become of the old Unix philosophy "Do just one thing but do that right"? And what if I prefer Jukbox to amaroK or even F-Spot to digikam? Does integration not need establishing good interfaces first? From what I read in this abstract (is there a link to Benjamins article?) I can't tell what he means nor if it's a good idea, leading to a user friendly Desktop or a Microsoft like unflexible feature monster which tries to do everything and does nothing right.
Ouch! - furanku - 2005-11-16
Thanks for adding the link, now that I've read the article and also the reactions on slashdot, I think that would have been a good opportunity for the new KDE marketing group to intervened. To me that all sounds like trying to establish a new buzz word by mixing obvious things with personal preferences. Take a look at the GUI of an existing good "type manager" and the mockup in the article and you get a feeling of what this article misses. That's the essential and the hard part: Writing something that is user friendly, has some cool new features, ... and that's where this article isn't helpfull at all.
Re: What does that mean? - Carl - 2005-11-17
>What has become of the old Unix philosophy "Do just one thing but do that >right"? That isn't dead. Things like amarok and digikam actually use smaller applications to achieve all their various tasks. Those smaller applications adhear to the unix philosophy, they do one thing and do it right. Really most KDE apps are frontends to a bunch of smaller apps. This follows the philosophy just fine, it just brings all those apps that do one thing together in one place. There's nothing wrong with that.
Re: What does that mean? - CAPSLOCK2000 - 2005-11-17
A frontend is also a small application that does one thing right: the user interface Create a very good UI and leave the lowlevel stuff for the CLI programms that do their own part right.
Re: What does that mean? - Carl - 2005-11-18
So CAPSLOCK200, are you saying that applications like amarok and digikam that do several tasks around one type of media shouldn't exist? Is it better to have several applications and have the user use all of them to achieve what they want rather than one? I'm not attacking you, I really am curious on your view.
Re: What does that mean? - kundor - 2005-11-18
As far as I can tell, that is the exact opposite of what he is saying. The point was supporting the paradigm of "one-task-well" programs by having multiple such sub-programs brought together in a UI such as amaroK, which is another "one-task-well" program, that task being user interface. I am quite curious how you could have gotten such an opposed interpretation from his post.
Re: What does that mean? - CAPSLOCK2000 - 2005-11-23
You have to realize that many gui programs are just that, a gui. The "real" work is done by other programms, that are driven from the gui. For example amarok is using an sql server for it's storage. It didn't create it's own storage module, but used an off-the-shelve component. This way the application writer can focus on what he is good in, namely writing gui's. Somebody who is good in writing databases did the storage component of the program. I don't use Amarok or Digikam, so I don't know if they follow this system. Maybe they are "fat" applications, that do everything themselves. There is nothing inherently bad in that, but it is conflicting with the time honoured Unix adagium: "Do one thing and do it good". Experience learns that every program has bugs, and the larger the program, the more bugs. By keeping the individual programs small it's easier to find and prevent bugs. Another benefit of using small components is that you can replace a module that is broken or not to your liking. Take for example text editors. Everyone in ICT has a favorite text editor (Vim!), and nobody seems to be able to agree on 1 editor to use for everything. But that's not a problem, you can edit any file with any editor. And if you set the EDITOR environment variable other programs will use your favorite editor when an editor is needed. This would not be possible in a fully integrated system.
Re: What does that mean? - CAPSLOCK2000 - 2005-11-23
Replying to myself after reading the thread again, it's obvious you do understand the Unix philosphy. Never mind my previous post. As I'm posting anyways I'd like to point out that I recently came to the conclusion that Konqueror and Type Managers should not opose each other as a primary interface. They should integrate. Konqueror should provide as much of a general Type Manager as possible, eg a search & filter system, and load plugins specific to the file/object to be handled. Throw in Kat or some other desktop search system to locate the objects (not just files) and we have a very nice and extensible Type Manager framework.
type manager? wtf. - KDE User - 2005-11-16
does this article mean anything at all?
The future? - Brandybuck - 2005-11-16
If Type Managers are the wave of the future, please give me the past. While I like Amarok as a player, and the ability to organize my songs into multiple playlists, I find the concept of Type Manager confusing. Can't you just give me a simple a freaking file manager? For people who dump every song they've ever touched into a single folder, the type manager is the only way to find something. But for people like me who organize their folders, the type manager is an impediment. Why do I feel like a dangerous radical bucking convention everytime I create a subdirectory? Maybe I should just dump every file I own onto "My Documents, just like my manager at work who can never find anything. I guess I'm just too old fashioned. I guess it's time for someone to push me out on the ice in a sled so I can freeze to death and no longer bother the young kids in the igloo. Until someone gets around to doing that, though, I hope they put a "Old Fart File Manager" button in their new fangled desktop.
Re: The future? - Brandybuck - 2005-11-16
Gawd I can be such a drama queen at times!
Re: The future? - stumbles - 2005-11-17
Well, you might be acting the drama queen but IMO you have some valid points.
Re: The future? - Brandybuck - 2005-11-17
I'm just hoping that the sled wasn't one of those valid points...
Re: The future? - stumbles - 2005-11-17
Hee, no. Not quite enough snow for the sled. Like you these new "pair of dimes" are in my view a lot like the new toy my daughter wants. It looks pretty, nifty, etc and once she gets it. Plays with it for a little while and off it goes in the toy box along with all the other stuff she doesn't play with. Now I'm not trying to start a flame fest here. But there have been many technologies proclaimed to be the greatest thing since sliced bread. Just leave me the option of using the stone age methods.
Re: The future? - Brandybuck - 2005-11-18
"But there have been many technologies proclaimed to be the greatest thing since sliced bread. Just leave me the option of using the stone age methods." I'm just trying to get back to the days when everything didn't have to be a distributed component!
Re: The future? - Joe Kowalski - 2005-11-17
Well, as the number of files that you personally mangage goes through the roof, you probably will eventually want something to make the process more efficient. You probably already use a type manager as I seriously doubt that you have manually setup and manage the files that comprise all the software on your system. You use a package manager that automates that process and presents you with a simple interface for adding, removing and updating pieces of software without having you manage each and every file that comprise the software on your system.
Re: The future? - Kåre Särs - 2005-11-17
Yes the number of music files, videoclips and movies increase rapidly but it is only a limited number of types that increase rapidly. For these types of files a metadata type organization is OK, but when you want to group many different types of files this metadata stuff is not effective any more. A directory structure gives the lazy (I think most of us are) a simple and quick method to group files of various types. Example: I have a project that contains text files, make files, shell scripts, source files, header files, and various other exotic files. With the metadata model I would have to add a tag to every file. Now if I want to copy some of these files and add them to another project I would have to make a copy and re-tag the files. It could be possible to use the tags as we use directories today, but I think this method would be a LOTT more confusing for the inexperienced user. What could be good is an indexer (like locate) that would be integrated in the filesystem and that would be updated as the filesystem changes. Indexing files containing specific data would be a waist of time/speed and diskspace. You don't always know in advance what data you are going to search for. So what we need is a smart search mechanism not a new file browser.
How to get rid off dubs - gerd - 2005-11-16
My question is how to get rid off dublicate programs in KDE? I mean two image viewers, I mean x music players, 3 editors (or 2.5). What iTunes explained to us is that what matters is not the functions but the combination. Type manager is a good phrase. But this means that the functions have already to be there and you can recombine them. Firefox is another example. Or Kontact. Multimedia and Usability.
Re: How to get rid off dubs - Kevin Krammer - 2005-11-16
"My question is how to get rid off dublicate programs in KDE?" Just don't install both? Too trivial? Automatic removal of duplicates could anger some users
Re: How to get rid off dubs - Adrian Baugh - 2005-11-16
There could be a program cleanup wizard, though. You run it (manually, so as not to annoy people) and it goes through your system checking for programs with very similar functionality. (Do you really want juk and amarok?) Then it provides a list of "duplicates" and you can choose either to get rid of a dupe or to keep both. There would have to be a series of plugins for different package management schemes (rpm, deb and ebuild); these would then work out what package(s) the duplicates were in, and uninstall them. There would be a problem, I suppose, for distributions that have huge bloated packages like "kdemultimedia" instead of separating things out nicely as they should, but that would just become a matter of educating the distributions to do things differently.
Re: How to get rid off dubs - Carl - 2005-11-17
Even better would be to not necessarily uninstall the duplicate applications but remove all references to them. For instance, who cares if I have Kwrite installed if none of my mimetypes know about it and it isn't in my KMenu? The program could search filetype associations and detect which filetypes have multiple applications associated with it. After the user selects which apps they don't want, the apps are de-associated with the various filetypes and removed from the KMenu. Besides so many distributions have apps installed that the user never even knows about. I know I have found many through the various years.
Type Managers and KDE - Benjamin Meyer - 2005-11-16
I wrote up a blog entry talking about what *I* think Type Managers really means for KDE here: <a href="http://www.kdedevelopers.org/node/1624">http://www.kdedevelopers.org/node/1624</a> Pretty much we have some work to do. -Benjamin Meyer
Re: Type Managers and KDE - vkhaitan - 2005-11-17
After so much of bottlethrows, I hope you would be seriously considering reviewing your own blog article or in the future, would try to avoid dot posting of a simple blog :-P
Re: Type Managers and KDE - Benjamin Meyer - 2005-11-17
Hmmmm.... one can only wonder what vkhaitan really meant by that post. I do review my articles, in fact I had a number of people review it.
Re: Type Managers and KDE - vkhaitan - 2005-11-17
hmm, you are right. A number of people here reviewed your article and thrown bottle over it :P . I agree, it has been reviewed by many people :) (just kidding man) On a serious note, I think, You should be more clear about your vision in the article. I could not find enough exciting information into it. May be because, partly , I could not understand it. I can only understand one fact, people should never bother about where their file goes.
OT: KDE3.5rc1 packages for debian sid available - ac - 2005-11-16
http://lists.debian.org/debian-kde/2005/11/msg00060.html
Don't forget KimDaBa - Dan - 2005-11-16
KimDaBa has been an absolutely brilliant 'Type Manager' for images and in that funcitonality pre-dates digiKam by a few years. It deserves a mention, I think.
better name - helpful - 2005-11-16
How about calling them Kype Kanagers? That name sounds *much* better and less confusing.
Re: better name - cm - 2005-11-16
KYawn.
Re: better name - Tink - 2005-11-17
It's really confusing, in the other world, the world outside KDE, a type manager is used to manage Type. As in Fonts. I'll be a lot of people will think of that first, at least I did. I thought KDE had finally gotten a Type ie Font manager. Confusing.....
Re: better name - Mark - 2005-11-17
Me to. At fisrt I thought it was some cool font manager for KDE 4 that lets me manage fonts.
Re: better name - jameth - 2005-11-17
Same here. However wrong we may have been, a Type Manager of the original and more naturally-named fashion is a Type Manager of this new-fangled and rather-confusingly-named fashion that we really could use.
Extend Konq? - Zot - 2005-11-16
Is there anyway that Konq can be extended to be a type manager? maybe thru kioslaves? Then each individual app such as juk could use an embeded konq window for the types that juk says it wants to manage and then konq would also know more about the files when in general file manager mode. We could also create profiles for a specific set of types. One of the types mentioned in the article is email. Could kontact/kmail use an embeded konq for email? What about bookmark management? What is used for the file dialogs when saving and opening files in programs like koffice? This could get the benefit and become a type manager for koffice file types. Are my ideas useful or am I just not understanding the concept?
Re: Extend Konq? - Adrian Baugh - 2005-11-16
There are circumstances in which you need a filemanager or something similar: a businessman would want to associate files belonging to a particular project, rather than all OpenDocument files, for example. However, I do believe there is a lot to be said for the idea of "type management" (if not for the name) and I think that now, while KDE4 is still up in the air, is the time to get it right. In my opinion KDE is going down the right track with kparts allowing for embedding of media viewers in konqueror and kio-slaves allowing for konq to cope with much more than local filesystems. However, to be brutal about it most of the kparts are a bit lacking; they are mostly little more than embedded viewers. All the context of the rest of the directory (think project files) disappears when, for example, I look at a particular PDF using the kpdf kpart. Also, while many kparts do a great job as viewers, very few include much worthwhile editing functionality. Sidebars: do we need the amarok sidebar as readily available when dealing with a project full of image files as when dealing with a project full of mp3s? Sidebars should put themselves forward on a more intelligent basis, when they can offer functionality relevant to the content being worked with. In KDE4 I believe we need to rethink the philosophy behind kparts so that, for each file the user may click on, konqueror offers functionality relevant to that file via a kpart viewer/manipulator and a sidebar or menus with the relevant editing and metadata handling functionality, but still (by default, anyway) has a strip making available other files in the same directory: the user has grouped them together for a contextual reason, so why should konqueror take that grouping away just because one particular file is foregrounded?
Re: Extend Konq? - superstoned - 2005-11-17
I agree. on one hand, i think typemanagers are a great concept. now this article has made clear what they are, and what they are good for, developers of type-managers can re-think what they are doing, and do it better. for example, amarok should evolve in a much more complete music manager. better integration of burning, ripping, downloading etcetera. on the other hand, imho konqi should be able to do these things too (with help from the type managers). so the KIO slaves system might need some refinement.
Re: Extend Konq? - David - 2005-11-17
Yes, that's the way to go in my opinion. We need Konq. to handle those "type manager" programs in an easy ui.. if it's KIO slaves, KParts I don't know. We need multimedia to be easy and consistent in KDE. Does anybody know that the plans are for multimedia in KDE4?
Re: Extend Konq? - gerd - 2005-11-17
All components of a TV/video typemanager application are there.
Type Manager = confusing! - fast_rizwaan - 2005-11-17
Really it means fonts for many a people. a "Data Type Manager" or "Data Type Content Manager" or "Content Type Manager" or something more appropriate and unambiguous would be nice. good article though!
Re: Type Manager = confusing! - nn - 2005-11-17
reminds me of ye old Amiga Datatypes ;-)
koffice as well.... - Mathieu Jobin - 2005-11-18
maybe software like kword could move from a "standard word processor" to a "document type manager"
Re: koffice as well.... - jameth - 2005-11-19
> maybe software like kword could move from a "standard word processor" to a "document type manager" A document manager is a good idea, but I don't think it should be in KWord. Rather, I think it should be in Kontact. Most documents have importance in relation to people and tasks, and Kontact is already designed to track those things. Thus, if it were extended to organizing documents that relate to contacts, I could look for PHI-220 and get all the papers I've done for that class so far, and I could look for NaNoWriMo and get all the chapters I've finished so far this month. Depending on the design paradigm, it might even be able to work emails and IM logs and the like into those lists, which I think would be really cool. Further, if properly integrated with the proposed search system for KDE 4 it could be an excellent example of how to leverage that search system properly. One of the main problems of search systems is having difficulty structuring queries. Since Kontact would make it extremely easy for a user, even a user who isn't very computer savvy, to look for documents relating to a specific person or a specific task. For example, I could look up documents relating to Steph and I'd get all the stories we've been working on so far in one category, our emails in another category, our IM logs in yet another category, and a couple dozen pictures in yet another category. Because Kontact creates a pre-understood context by which the searches are conducted, a user can easily find things relating to the tasks and people they are currently dealing with. I think the idea of a document manager in Kontact has the potential to be a killer app; not in the sense of, "Man, I gotta get that app," but in the sense of, "After having used this for a while, I feel bereft without it."
Re: koffice as well.... - wannabe using ..... - 2005-11-19
agreed.