GNOME Bugzilla – Bug 510842
support more archive formats for theme packages
Last modified: 2008-04-11 17:06:23 UTC
Please describe the problem: While using the Gnome desktop users expect certain things, like all "working formats" to work across the whole "OS" without inconsistency. That said, file-roller currently (on my box) can handle the following types: .tar.gz, .tar.bz2, .tar, .zip, .ar, .ear, .jar, .war, .7z, .rar but only *some* work in gnome-appearance-properties utility... Steps to reproduce: 1. Extract a known-working theme 2. create an archive of any of the following types: .tar, .zip, .ar, .ear, .jar, .war, .7z, .rar 3. drag & drop into the "Theme" tab's window and watch the failure flail about like a helpless child being trampled. 4. Wonder why the thing isn't made to work with all the formats file-roller is. 5. Do it manually, completely circumventing the point of the utility (gnome-appearance-properties), further crippling the desktop environment. Actual results: You waste precious time trying to install a theme for your desktop instead of getting work done. Re-compressing themes is so much more fun. Expected results: "Just works" comes to mind. Does this happen every time? Don't hard-coded things ALWAYS happen every time regardless of what plug-ins you install for any other API? Other information: It would be quite lovely if Gnome's utilities and various apps that deal with archives read off the same thing as it's _archival application_. That's to say, there should be a layer in Gnome which doesn't care what's accessing it, only that something is asking for something it supports (.tar.gz, .tar.bz2, .tar, .zip, .ar, .ear, .jar, .war, .7z, .rar, <future formats in the form of plug-ins>, etc.). file-roller, nautilus, gnome-appearance-properties and gdmsetup *each* take different types of archives... what a mess. I don't like my apps forcing me to use one certain archive type. So much for open standards.
file-roller doesn't expose its archive "plugins" for other to use, so there's nothing we can do about that. I'm sure they'd welcome your help in factoring them out, though. > So much for open standards. I think you are confusing "open standards" with something completely different here.
>> So much for open standards. > I think you are confusing "open standards" with something completely different here. Correct. My bad. What I meant to say was, so much for a user's choice. Good catch.
(In reply to comment #0) > 2. create an archive of any of the following types: .tar, .zip, .ar, .ear, > .jar, .war, .7z, .rar > 3. drag & drop into the "Theme" tab's window and watch the failure flail about > like a helpless child being trampled. Err, excuse me? A "theme" is a bunch of well-defined files, packed into a well-defined container. That's how the file format has been specified. A .jar actually is a .zip file. Same for the OpenOffice and OpenDocument file formats. You can not throw a re-encoded version, say in .rar format, at either of these and expect it to work. IMHO, this is NOTABUG (The problem described is not actually a bug, but a design choice of some sort.) but I'll leave the decision to keep it as a valid feature request to the maintainers. Well, and those who specify the theme container format...
oops, sorry
I agree with Karsten, this is a design choice. I also fail to see how the use case for this bug is actually useful.