A proposal for the handling of MIME types was published by Red Hat’s JRB.
Proposal for a new MIME system in GNOME
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I probably speak for a large percentage of Gnome users when I say, “And it’s about time too!”
I hope they go for it.
Am i the only one which thinks a mimetype system would be usful bellow the GUI? That is, provide set of command line tools to build the mimetype configuration files in XML or something. That way GUIs such as KDE, Gnome and other apps cause use these command line apps etc to provide basic mimetype support. Also, this way, its more portable and not confined to any one GUI!
So they are picking up a freedesktop.org proposal, what’s that makes it news-worthy?
Does it cover the situation that a program the first
time it is started mixes with the MIME database
in order to catch the files it knows how to handle.
For example, if I a bit map manipulating program,
I may want it to be started when the user clicks
on a GIF file. How does the program install itself,
is there an api for this.
And does the user need to know that the program
installs itself in the MIME database.
If yes, isn’t the normal user confused by seeing the
message:
“I’m installing myself as a MIME handler for YYY, OK?”.
Maybe this confirmation should be configurable.
Also, for a graphics file, you may want to differ between
viewers and editors.
regards,
Clx
Go read the proposal again, and you will se how they handle multiple mime types and multiple programs that handle the same types.
I really appreciate the fact this sort of thing is planned out and defined before it’s implemented.
This seems identical to the way KDE does things already though. Does GNOME not do it that way already, or is this just laying out a precise behaviour?
GNOME always does this. This is the reason they seem slow in adding some functionality, like how long it tool to get teh new file selector. Its actually debated and prototyped or something like that, before its implemented. They have tp make sure it doesn’t break anything, and is futureproof.
They have tp make sure it doesn’t break anything, and is futureproof.
Yep. And that’s why I love using it. It just seems so well-planned (because it is!).
I really hope they bite on this one. MIME has been something in need of an overhaul since 2.0. If this can make it into 2.6 I’d be thrilled.
> GNOME always does this. This is the reason they seem slow in adding some functionality, like how long it tool to get teh new file selector. Its actually debated and prototyped or something like that, before its implemented.
I see that the new file selector was delay one to two years and then rushed the last month before Gtk 2.4 feature freeze.
> They have tp make sure it doesn’t break anything
Wrong, the introduced a complete new API for the file selector so there was nothing to break.
‘In the case where there is no known handler for the file, then the primary application is the “Open With Other Application…” menu item’
Other than what? Why not make it “Open With…”? Confusing stuff.
I guess the freedesktop project is making an unified MIME type standard to the new X Server, so why GNOME team is doing this?
“Wrong, the introduced a complete new API for the file selector so there was nothing to break.”
Yes, they had to, which was why they decided to take their time and do it right.
The fileselector was not rushed. It was always planned for GTK 2.4, and is being developed there, and this has nto much to do with GNOME, besides GNOE using the toolkit. There is no duplication of API’s. Right now, there are at least 2 API’s for Qt apps, and dare I say, I have seen 3. This is the duplication they are trying to avoid. The GNOME developers could hava made their own file selectors, but they chosed to implement one good one at the toolkit level.
Why does the verb always have to be “Open”?
I’d like to see different verbs which reflect the task I intend to do. Like this example a .html file.
Instead of:
Open with Mozilla
Open with Emacs
It should be:
View with Mozilla
Edit with Emacs
This reminds me a lot of what we had with BeOS with the first release of the BFS filesystem back in what, 1998? 1999?
– chrish
Add the correct verb for a task.
Let’s get the meta-data handled well enough before we add meta-meta-data
I guess the freedesktop project is making an unified MIME type standard to the new X Server, so why GNOME team is doing this?
This new mime type system is based on the freedesktop.org standard:
The MIME system is based on the proposed system at http://www.freedesktop.org. The current version, version 0.12, has pretty good traction on the lists, and will definitely be usable by the time GNOME 2.6 is released.
> I see that the new file selector was delay one to two years
> and then rushed the last month before Gtk 2.4 feature
> freeze.
This is half right. The file seleector was initially deveoped as an indenpendent module, (sort of like libegg is used to ‘hatch’ new code ;P). It got delayed towards the end because of a needed OO feature (somehting very specific with interfaces, not sure, but you can look it up in the archives) in gobject that would of allowed it to continue development. The person that should of worked on that part, didnt have time, and thereby delayed the development.
The API’s are now getting finalised. The gui is still in development. You gotta admit though, that they ended up making more then a file selector… (a whole fs abstration, that will allow the selector to use gnome-vfs or window’s special directories seamlessly.)
@m:
“Instead of:
Open with Mozilla
Open with Emacs
It should be:
View with Mozilla
Edit with Emacs”
Ah, but there’s a few problems with that. What if Emacs isn’t installed? What about the fact that you can edit HTML pages with composer in Mozilla? So technically it could be:
“View With Mozilla
Edit With Mozilla
Edit With Emacs”
🙂
I was hoping for:
1. A system that does NOT depend on meta data beeing part of the filename. filename and file type should be two totally different things, simply because they ARE different. If i have a “gif” image named document.pdf, it should be identified as “gif” image, and the icon should also show the fact that the content of the file is a “gif”. ONLY when the content of the file cannot be determined by looking at it (file types without signatures) the file extension should be used to identify it. File extensions is and has always been a bad hack.
2. A system that is independant of the windows/file manager. It would simply be a simple database running in the background, that any application could query. that way, we could have console based interfaces to launch files, i would like to be able to type sometghing like:
$ launch –verb edit /public_html/index.html
or
$ launch –verb view prodigy.mpg
3. A possibility to configure what application (and icon) to associate with a specific verb running under a specific window manager.
Clicking on an image file in kde might start “kuickshow” and doing it in wmaker might spawn “qiv”.
1. A system that does NOT depend on meta data beeing part of the filename. filename and file type should be two totally different things, simply because they ARE different. If i have a “gif” image named document.pdf, it should be identified as “gif” image, and the icon should also show the fact that the content of the file is a “gif”. ONLY when the content of the file cannot be determined by looking at it (file types without signatures) the file extension should be used to identify it. File extensions is and has always been a bad hack.
Do you realize how disgustingly complex an algorithm like that will be? And how expensive the cycles devoted to deciphering the content of the file will be? Extensions are far from being a hack. They are useful and they serve a purpose. When I view files via my terminal, how do you think I recognize whether a file is an image, text or compressed file?
A system that is independant of the windows/file manager. It would simply be a simple database running in the background, that any application could query. that way, we could have console based interfaces to launch files, i would like to be able to type sometghing like:
Again, for resource concerns, it is generally not a good idea to implement database related methods on a desktop. Databases are heavily resource intensive, and generally, developers shy away from using them as much as possible on the desktop. Nobody wants Nautilus querying a database just to view a file.
A possibility to configure what application (and icon) to associate with a specific verb running under a specific window manager. Clicking on an image file in kde might start “kuickshow” and doing it in wmaker might spawn “qiv”.
Isn’t that how it works at present? Or am I missing something?
Once again the Linux community shows how good it is at innovation.
Even a “dead” OS has had this for years, and the Linux crowd is only now catching on? C’mon. That’s just lame.
This is not a troll. I’m serious, how is it possible that this hasn’t been implemented earlier? After all it’s a really usefull system(at least it is on BeOS), and shouldn’t be too hard to implement (IIRC some FS’s on Linux already have support for metadata etc.).
Once again the Linux community shows how good it is at innovation.
Even a “dead” OS has had this for years, and the Linux crowd is only now catching on? C’mon. That’s just lame.
This is not a troll. I’m serious, how is it possible that this hasn’t been implemented earlier? After all it’s a really usefull system(at least it is on BeOS), and shouldn’t be too hard to implement (IIRC some FS’s on Linux already have support for metadata etc.).
What’s with all this glorification of a dead system? So what BeOS *had* something similar. Emphasis on “had”. Where is BeOS today? The fact that a platform had something first doesn’t make it special. BeOS was designed from the ground up to be a desktop system.
That’s not exactly Unix and Unix-like platforms strong points. There are tonnes of things Linux can do that BeOS wouldn’t dream of doing. And please…please, let’s just stop talking about, as you rightly put it, a dead operating system.
So because BeOS had something similar, Linux shouldn’t implement it. How about the millions of things BeOS does that Linux doesn’t give a damn about? Why don’t you mention those?
The thread might be dead, but anyway
I have a problem with this new mime handling in gnome and I am wondering if other people might see it as a problem too.
What do you do if there are a lot of applications associated with one mime type. It’s not that uncommon. But you frequently use only a subset of them. Won’t be difficult to distinguish from that alphabetically sorted list the application you need?
Currently there are no plans include a way to select which applications are showed in the menu and which are not.
One more. There won’t be a way to select a default application for a single file/folder. I mean a different one than for its mime type. I use this feature only for folders and for me it’s only a work around for not having the possibility to define mime types for folder. Is there such a possibility? Anyway, does it affect you?
Finally someone found out one of the worst thing in gnome: MIME HANDLING imho its the most unusable thing.
The new system seems well planned, I hope that they implement it very fast
hmms i dont think it would be that hard to check the filetype without loking att the exstension.
the command file alredy exsist and does just that
GNOME already does check the MIME-type without looking at the extension. That’s also known as MIME-type sniffing. It’s very common.
gnome-vfs can already be used from non-GUI applications. As well as telling you a file’s MIME type, it can also tell you what applications can handle that MIME type.
Dude, even /usr/bin/file can tell the difference between a GIF and a PDF, and I seriously doubt it takes a lot of “wasted” cycles to figure that out.
And, if the default filesystems would get out of the stone age, this sort of file meta-data could be cached.
“Oh no, it’ll waste space on my disk storing all those MIME strings!” Again, you’d be penny-wise and pound foolish. If you want to do it in an “efficient” manner, store the MIME types in a database, and store a 32-bit unique hash or something in the filesystem… 4 bytes/node shouldn’t be a big problem. Of course, when you teach zip to know about the meta-data, you’ll want to store the actual MIME type, not the hash (unless you use a hash that always produces the same output)…
Being an armchair designer for operating system services is fun.
– chrish