[arch-general] Automatic File Associations Alloting
Hi, Whenever I install a new text editor, it will "hijack" the files without notifying me. My .tex files were associated with Kile and when I recently installed emacs, it hijacked the file associations. This happens quiet often. Going by the Archway, I guess this is unwarranted. The system is doing something automatically without asking me first and I wish it didn't happen. I understand that when I installed Kile, it also automatically took up .tex for its use. But then I guess, .tex was not allocated to anything (excpet may be the default text editor for that env). What I wish is, by default all applications should be allocated to a text editor for that DE. (For example, Kwrite for KDE, Gedit for Gnome and so on.) But as the programs get installed, the programs should check whether there is a file association. If it is just to the text editor, then they can take over. However, if it is to some other program, then they should not do anything instead leave a message during installation that these file types were not changed because they are otherwise associated and then the user can change some if he wants. I know I can edit my custom preferences in ~/.local/share/mime folder or /usr/share/application/defaults.list. But still I was wondering about the default behaviour. ---------------------------------------------------------------------------------------------------------------------------------------------- Cheers and Regards Jayesh Vinay Badwaik Electronics and Communication Engineering VNIT, INDIA -
On 19 November 2011 13:23, Jayesh Badwaik <jayesh.badwaik90@gmail.com> wrote:
Hi,
Whenever I install a new text editor, it will "hijack" the files without notifying me. My .tex files were associated with Kile and when I recently installed emacs, it hijacked the file associations.
This happens quiet often. Going by the Archway, I guess this is unwarranted. The system is doing something automatically without asking me first and I wish it didn't happen.
I have to admit that this is something that gets my back up as well. Why the hell would wine think that I would want to use the hideous Notepad editor when just about any Linux editor is better I just don't know. It also associates images with 'Internet Explorer' yuk. I only install wine so I can use mp3DirectCut. Seems to me that there are no etiquette rules to be followed and no matter what you install it just feels it is free to screw with current associations. Does anyone know if there are any rules and they are just plain ignored or is it an association free-for-all. Clive -- Infinity: A concept for those who cannot comprehend the big picture. () Arch Linux - For movers and shakers. ()
text files opening automatically with wine is really a VERY annoying thing...
Excerpts from Bernardo Barros's message of 2011-11-20 00:06:05 +0100:
text files opening automatically with wine is really a VERY annoying thing...
This is pretty clearly a DE issue. Are you all using the same DE or is this common behavior in all popular DEs? I rarely have any of those issues since I usually call my programs by name and ROX uses manual file association. Only firefox is sometimes hard to convince, but it uses gconf or some other DE stuff underneath. It's somewhat nice to see that DE users also have problems with that kind of stuff. Maybe this stuff can be changed using regedit or however that great program to change gconf settings is called. I'm sorry, somehow this ended up as another DE flame instead of being helpful. Oh well... So how is this stuff controlled these days? Those funky desktop files? gconf? dconf? Something else entirely?
On (11/21/11 22:36), Philipp Überbacher wrote: -~> Excerpts from Bernardo Barros's message of 2011-11-20 00:06:05 +0100: -~> > text files opening automatically with wine is really a VERY annoying thing... -~> -~> This is pretty clearly a DE issue. Are you all using the same DE or is -~> this common behavior in all popular DEs? I rarely have any of those -~> issues since I usually call my programs by name and ROX uses manual -~> file association. Only firefox is sometimes hard to convince, but it -~> uses gconf or some other DE stuff underneath. It's somewhat nice to see -~> that DE users also have problems with that kind of stuff. Maybe this -~> stuff can be changed using regedit or however that great program to -~> change gconf settings is called. I'm sorry, somehow this ended up as -~> another DE flame instead of being helpful. Oh well... -~> -~> So how is this stuff controlled these days? Those funky desktop files? -~> gconf? dconf? Something else entirely? gconf, I think in gnome. In xfce (thunar) there is something like $HOME/.local/share/applications/mimeapps.list. They are all evil, however: http://www.youtube.com/watch?v=ovfYBa1EHm4 (ShmooCon 2011: USB Autorun attacks against Linux). -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
In KDE I don't have this problem. It happens with xmonad and openbox. pcmanfm can configure that too, but automatic picks the last installed package that handle this type of file, and wine is always the last thing I install in the system..
On 21-11-2011 22:08, Bernardo Barros wrote:
In KDE I don't have this problem.
It happens with xmonad and openbox.
pcmanfm can configure that too, but automatic picks the last installed package that handle this type of file, and wine is always the last thing I install in the system..
To work around the wine annoyance I usually do (after running wine once after the update): find ~/.local/share/mime -name '*wine*' -exec rm {} \; rm ~/.local/share/applications/wine*.desktop update-mime-database ~/.local/share/mime And everything gets back in order to the way I had it configured before. The original idea isn't mine, I've seen someone suggest this on the forums or here, can't remember where or who suggested it though. -- Mauro Santos
On 11/21/2011 05:49 PM, Mauro Santos wrote:
On 21-11-2011 22:08, Bernardo Barros wrote:
In KDE I don't have this problem.
It happens with xmonad and openbox.
pcmanfm can configure that too, but automatic picks the last installed package that handle this type of file, and wine is always the last thing I install in the system..
To work around the wine annoyance I usually do (after running wine once after the update):
find ~/.local/share/mime -name '*wine*' -exec rm {} \; rm ~/.local/share/applications/wine*.desktop update-mime-database ~/.local/share/mime
And everything gets back in order to the way I had it configured before. The original idea isn't mine, I've seen someone suggest this on the forums or here, can't remember where or who suggested it though.
For wine you can have export WINEDLLOVERRIDES=winemenubuilder.exe=d in your profile to avoid the associations.
On Mon, Nov 21, 2011 at 22:09, Matthew Monaco <dgbaley27@0x01b.net> wrote:
On 11/21/2011 05:49 PM, Mauro Santos wrote:
On 21-11-2011 22:08, Bernardo Barros wrote:
In KDE I don't have this problem.
It happens with xmonad and openbox.
pcmanfm can configure that too, but automatic picks the last installed package that handle this type of file, and wine is always the last thing I install in the system..
To work around the wine annoyance I usually do (after running wine once after the update):
find ~/.local/share/mime -name '*wine*' -exec rm {} \; rm ~/.local/share/applications/**wine*.desktop update-mime-database ~/.local/share/mime
And everything gets back in order to the way I had it configured before. The original idea isn't mine, I've seen someone suggest this on the forums or here, can't remember where or who suggested it though.
For wine you can have export WINEDLLOVERRIDES=**winemenubuilder.exe=d in your profile to avoid the associations.
To all: There is a simple little app in the aur by xyne called mimeo. For those who use openbox this works really great. Y'all should check it out. On top of that, at least with Thunar, you can set up custom actions and if you right click on file it will ask you which program you would like to use to open it with -- down to including an option to search for the program you would like to use. I gave up on U and Deb for a reason. I also refuse to use gnome, used to use it all the time, and KDE because they want to do it all for me -- just like another un-named os from Redmond. In my old age I need some conveniences but I don't need my os to tell me what I need to work on a file, at least I don't think I'm that senile yet. Rather than "mother dog mother dog" about it and point out how well other os's handle it. Figure out the syntactic sugar they use on top of the base tools and apply it your self. The tools all exist somewhere in Arch. That's the whole point of Arch and Kiss, or as the agile developers say "you ain't gonna need it" and "don't repeat yourself". The tools are there and if an old dog can figure it out. Myra -- Life's fun when your sick and psychotic! And highly opinionated.
One can use defaults.list file in /usr/share/applications to associate. But it is one hell of a job. Especially when C header is different from c source. The problem is mainly that for the application to overwrite 100s of file association wrongly take no time. For me to restore them back is a hell of a time. That being said, I tried to keep a list of my custom file associations but then I install some other app, which then does it again. But this time, it also adds new associatiosn which I actually need, and then I have to run a script to filter out what I want and what I don't. Should it be that difficult? Also, the defaults are I guess quiet wrong.
Also, looking at this file, in both Debian and Ubuntu, I found out that is not what I'd want on my system, since I don't have some of the applications associated with some files in these distros. What worked great for me, was to take the files from both distros, compare them and come up with my own defaults.list [2].
Right on. A bigger problem with the defaults is as such. For all images file, the default is GIMP if it is installed. I mean really?? Everyone wants to edit the images? And again, it would have been no problem. But gimp just takes so long to load as compared to some other app such as gwenview etc Then for folder/directory, konqueror is the app. Again really??? Why the hell was dolphin invented for? For pdf files guess who? GIMP again!! What the hell!!! Who uses gimp to read a PDF anyway? Give me evince. Or okular or even XPDF but Gimp?? Why Arch Why?? Emacs for all text files is what I have found on other distros too.. Its somewhat sad (myself being a vim user ;) ) but i guess that is emacs fault and is packaging problem. What I was thinking was that there should be something out of this mess. I install a new text editor to try out and I am left with a default mess??? This situation is quiet unavoidable on other distributions as they install a lot of things automatically. However, in Arch, we install minimalistic things and hence, I guess, we can find a solution within the philosophy. And I believe, it is as follows. 1. Get the defaults right for the DE. I guess they are and other apps invade their space. but still this should be the first checklist. It is highly subjective. So, doesn't really matter but seriously, konqueror for folder/directory is too much. 2. Here we assume that a Archer (the one who uses Arch) installs only what he wants. So, the package can only add to the file association table. It cannot change already existing entries in it. I guess its a simple script. Its just that instead of me using it everytime, the package does it for me. 3. Sometimes though, you might want the new application to actually take over all the things. In which case, we can have some sort of program which manages file associations and kind of runs either during the package installation or can be run manually after it. Just like ld is run. I am thinking of writing a small program to do so. I'll let you know how I am progressing. Right now I only have a design in my mind and I have some exams coming up in three-four days. So after I am done with them, I would put my plans into action. I can post my plans and if they are any good, we can try developing something. I haven't got time right now so I cannot even make the docs. ---------------------------------------------------------------------------------------------------------------------------------------------- Cheers and Regards Jayesh Vinay Badwaik Electronics and Communication Engineering VNIT, INDIA
On Tue, Nov 22, 2011 at 6:15 PM, Jayesh Badwaik <jayesh.badwaik90@gmail.com> wrote: <snip>
I am thinking of writing a small program to do so. I'll let you know how I am progressing. Right now I only have a design in my mind and I have some exams coming up in three-four days. So after I am done with them, I would put my plans into action. I can post my plans and if they are any good, we can try developing something. I haven't got time right now so I cannot even make the docs.
xdg-open? Xyne wrote mimeo to help manage mime-types, been using that with xdg-utils-mimeo from the AUR for a while now...
ohk... I will see that... i was thinking something very simple I was thinking more along the lines of a utility to create a mimeinfo.list from a description file. (XML or something like that) That description file can be provided by the package and then whenever it gets updated. There are certain parameters in the description file which will allow for easy parsing and processing. The program will read the the mimeinfo.xml file on system and one with the package. Then, will check for conflicts and ask the user to resolve them using some sort of interface (plain text or ncurses). That way, there is a clean interface on what to do. It will be compatible with the current DE and does not present any special requirements. However, I will see the program. I never heard of it before to tell the truth. I'll see it and then get back to you. Bye! ---------------------------------------------------------------------------------------------------------------------------------------------- Cheers and Regards Jayesh Vinay Badwaik Electronics and Communication Engineering VNIT, INDIA - On Wed, Nov 23, 2011 at 7:38 AM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Tue, Nov 22, 2011 at 6:15 PM, Jayesh Badwaik <jayesh.badwaik90@gmail.com> wrote: <snip>
I am thinking of writing a small program to do so. I'll let you know how I am progressing. Right now I only have a design in my mind and I have some exams coming up in three-four days. So after I am done with them, I would put my plans into action. I can post my plans and if they are any good, we can try developing something. I haven't got time right now so I cannot even make the docs.
xdg-open? Xyne wrote mimeo to help manage mime-types, been using that with xdg-utils-mimeo from the AUR for a while now...
On Wed, Nov 23, 2011 at 6:12 AM, Jayesh Badwaik <jayesh.badwaik90@gmail.com>wrote:
xdg-open? Xyne wrote mimeo to help manage mime-types, been using that with xdg-utils-mimeo from the AUR for a while now...
Comment by: xduugu on Sun, 13 Mar 2011 23:12:21 +0000 Since mimeo also supports file uris now, there is no need to change
xdg-utils-mimeo is orphaned in the aur, and some comments suggest that is is not needed anymore: this package anymore. Is this true? I'm just starting to learn mimeo and associations in general, seems pretty complicated for me.
Hi, All the programs, mimeo, xdg-open are oriented towards using mime info to open application. My problem is different. What I want is a way to tell "my" desktop environment or whatever to use which applications. The main issue is as follows. Every program that gets installed can do anything to the mimeinfo.list file. Sometimes, it will also change the xdg-open values. There are multiple systems with multiple standards. We cannot do much about that. However, what we can do is, we can make it easy to create an interface to program that. My suggestions is as follows. All file associations would be stored in a XML based file. There will be other details in it. But the main details is as follows 1. mime-type 2. associated applications wuth priority starting from 1. Why exactly one, will be clear later. Now whenever a new package is installed. It will contain an XML file containing description of the mimetype in the same manner. When the package is installed, the file will be transferred to a folder. The main file which contains the descriptions of the mime type will be somewhere else. This folder will contain the mime files which have not yet been incorportated into the main file. Now, a program would run which will take this folder and the original file as the default arguments and then update the file types. If there is a conflict, especially if the priority of the application for the mime type is already taken, then there can be a ncurses based resolution window, letting window resolve the conflict (modeled on the file association selectors in Windows applications). The priority in the package files can be -1 if the file wants to go to the last priority if possible. (like the nice factor of the processes) But no one can occupy the priority zero. Suppose a user opens an app using open with command and then checks the box, then automatically an entry is created in the folder with priority zero and then it is updated. This way, automatic software will never trump the user set defaults under any circumstances and the conflict management would prevent the irritation at the file open time. I am sure people are more careful during install than they are during file opening. Now the final XML file is created. This file can be then modified into whatever is demanded by any DE etc etc. What do you think? ---------------------------------------------------------------------------------------------------------------------------------------------- Cheers and Regards Jayesh Vinay Badwaik Electronics and Communication Engineering VNIT, INDIA - On Wed, Nov 23, 2011 at 3:45 PM, SanskritFritz <sanskritfritz@gmail.com> wrote:
Since mimeo also supports file uris now, there is no need to change this package anymore.
EDIT: Int the above post, check the box means checks the always opens box? ---------------------------------------------------------------------------------------------------------------------------------------------- Cheers and Regards Jayesh Vinay Badwaik Electronics and Communication Engineering VNIT, INDIA - On Wed, Nov 23, 2011 at 10:08 PM, Jayesh Badwaik <jayesh.badwaik90@gmail.com> wrote:
Hi,
All the programs, mimeo, xdg-open are oriented towards using mime info to open application. My problem is different. What I want is a way to tell "my" desktop environment or whatever to use which applications.
The main issue is as follows. Every program that gets installed can do anything to the mimeinfo.list file. Sometimes, it will also change the xdg-open values. There are multiple systems with multiple standards. We cannot do much about that. However, what we can do is, we can make it easy to create an interface to program that.
My suggestions is as follows. All file associations would be stored in a XML based file. There will be other details in it. But the main details is as follows 1. mime-type 2. associated applications wuth priority starting from 1. Why exactly one, will be clear later.
Now whenever a new package is installed. It will contain an XML file containing description of the mimetype in the same manner. When the package is installed, the file will be transferred to a folder. The main file which contains the descriptions of the mime type will be somewhere else. This folder will contain the mime files which have not yet been incorportated into the main file.
Now, a program would run which will take this folder and the original file as the default arguments and then update the file types. If there is a conflict, especially if the priority of the application for the mime type is already taken, then there can be a ncurses based resolution window, letting window resolve the conflict (modeled on the file association selectors in Windows applications). The priority in the package files can be -1 if the file wants to go to the last priority if possible. (like the nice factor of the processes)
But no one can occupy the priority zero. Suppose a user opens an app using open with command and then checks the box, then automatically an entry is created in the folder with priority zero and then it is updated. This way, automatic software will never trump the user set defaults under any circumstances and the conflict management would prevent the irritation at the file open time. I am sure people are more careful during install than they are during file opening.
Now the final XML file is created. This file can be then modified into whatever is demanded by any DE etc etc. What do you think?
---------------------------------------------------------------------------------------------------------------------------------------------- Cheers and Regards Jayesh Vinay Badwaik Electronics and Communication Engineering VNIT, INDIA -
On Wed, Nov 23, 2011 at 3:45 PM, SanskritFritz <sanskritfritz@gmail.com> wrote:
Since mimeo also supports file uris now, there is no need to change this package anymore.
Jayesh Badwaik wrote:
Now whenever a new package is installed. It will contain an XML file containing description of the mimetype in the same manner. When the package is installed, the file will be transferred to a folder. The main file which contains the descriptions of the mime type will be somewhere else. This folder will contain the mime files which have not yet been incorportated into the main file.
Now, a program would run which will take this folder and the original file as the default arguments and then update the file types. If there is a conflict, especially if the priority of the application for the mime type is already taken, then there can be a ncurses based resolution window, letting window resolve the conflict (modeled on the file association selectors in Windows applications). The priority in the package files can be -1 if the file wants to go to the last priority if possible. (like the nice factor of the processes)
But no one can occupy the priority zero. Suppose a user opens an app using open with command and then checks the box, then automatically an entry is created in the folder with priority zero and then it is updated. This way, automatic software will never trump the user set defaults under any circumstances and the conflict management would prevent the irritation at the file open time. I am sure people are more careful during install than they are during file opening.
Now the final XML file is created. This file can be then modified into whatever is demanded by any DE etc etc. What do you think?
XML is such a nasty beast to handle, especially for such a simple application. I'm using a custom lessopen command as a companion to less(1). My lessopen keeps a simple textfile with one mimetype/extension/open-helper per line. Each file is checked against this "database" with "file -Lsbz --mime-type" or "file -Lsb --mime-type". If a specific mimetype/extension/open-helper tuple cannot be found, the user is queried for it. In your case you want a unified database, because new programs may suggest some entry. This requires merging and conflict resolution. I wouldn't go this way, I'd just use two different databases, where the user supplied one is checked first and a distribution one second (or last, in case the searching stops here). Database entries look like this (mimetype "_:_" extension ":::" helper): application/vnd.ms-cab-compressed_:_CAB:::7z l # an entry with a catchall (wildcard) application/x-executable_:_*:::readelf -d "${FILE}"; strings -a < If a filename contains several dots, the last few are taken to be the extension unless a catchall entry exists. Using extensions for additional differentiation lets one use different programs in special cases. The variable "$FILE" can be used in case the helper wants a real file, the "<" redirection operator lets the shell handle the readonly case. If lessopen isn't used by less, it can equally well be used for interactive, even GUI programs. I wrote the script because I was not at all satisfied with the official version, which is very complicated, doesn't let me configure my own programs and doesn't use a separate database, everything is needlessly hardcoded. My version is simpler and more versatile. clemens
Yeah. I too have my personal stuff for that. I have a script actually which uses a file and from that creates the default.list file which is then used by anyone who cares to use it (Firefox, KDE etc). But I am now tired of the custom stuff. I just wanted to explore. And XML seemed quiet universal in the sense. And I have heard a lot but I still don't get it. Why is XML a beast? I have read everything from every source where people have even given point wise listings. But I am not able to appreciate anything. XML is just a way of writing data, right? Instead of parsing text you parse tags and their values. The only difference and advantage is that the stuff is more human readable. ---------------------------------------------------------------------------------------------------------------------------------------------- Cheers and Regards Jayesh Vinay Badwaik Electronics and Communication Engineering VNIT, INDIA - On Sat, Nov 26, 2011 at 2:48 AM, clemens fischer <ino-news@spotteswoode.dnsalias.org> wrote:
Jayesh Badwaik wrote:
Now whenever a new package is installed. It will contain an XML file containing description of the mimetype in the same manner. When the package is installed, the file will be transferred to a folder. The main file which contains the descriptions of the mime type will be somewhere else. This folder will contain the mime files which have not yet been incorportated into the main file.
Now, a program would run which will take this folder and the original file as the default arguments and then update the file types. If there is a conflict, especially if the priority of the application for the mime type is already taken, then there can be a ncurses based resolution window, letting window resolve the conflict (modeled on the file association selectors in Windows applications). The priority in the package files can be -1 if the file wants to go to the last priority if possible. (like the nice factor of the processes)
But no one can occupy the priority zero. Suppose a user opens an app using open with command and then checks the box, then automatically an entry is created in the folder with priority zero and then it is updated. This way, automatic software will never trump the user set defaults under any circumstances and the conflict management would prevent the irritation at the file open time. I am sure people are more careful during install than they are during file opening.
Now the final XML file is created. This file can be then modified into whatever is demanded by any DE etc etc. What do you think?
XML is such a nasty beast to handle, especially for such a simple application. I'm using a custom lessopen command as a companion to less(1). My lessopen keeps a simple textfile with one mimetype/extension/open-helper per line. Each file is checked against this "database" with "file -Lsbz --mime-type" or "file -Lsb --mime-type". If a specific mimetype/extension/open-helper tuple cannot be found, the user is queried for it.
In your case you want a unified database, because new programs may suggest some entry. This requires merging and conflict resolution. I wouldn't go this way, I'd just use two different databases, where the user supplied one is checked first and a distribution one second (or last, in case the searching stops here).
Database entries look like this (mimetype "_:_" extension ":::" helper):
application/vnd.ms-cab-compressed_:_CAB:::7z l # an entry with a catchall (wildcard) application/x-executable_:_*:::readelf -d "${FILE}"; strings -a <
If a filename contains several dots, the last few are taken to be the extension unless a catchall entry exists. Using extensions for additional differentiation lets one use different programs in special cases. The variable "$FILE" can be used in case the helper wants a real file, the "<" redirection operator lets the shell handle the readonly case.
If lessopen isn't used by less, it can equally well be used for interactive, even GUI programs.
I wrote the script because I was not at all satisfied with the official version, which is very complicated, doesn't let me configure my own programs and doesn't use a separate database, everything is needlessly hardcoded. My version is simpler and more versatile.
clemens
Jayesh Badwaik wrote:
Yeah. I too have my personal stuff for that. I have a script actually which uses a file and from that creates the default.list file which is then used by anyone who cares to use it (Firefox, KDE etc). But I am now tired of the custom stuff. I just wanted to explore. And XML seemed quiet universal in the sense.
And I have heard a lot but I still don't get it. Why is XML a beast? I have read everything from every source where people have even given point wise listings. But I am not able to appreciate anything. XML is just a way of writing data, right? Instead of parsing text you parse tags and their values. The only difference and advantage is that the stuff is more human readable.
I was talking from the viewpoint of the task you were trying to solve. You want a way to handle mimetype associations for file objects. There's not much info needed. XML is not the best format to parse without bloaty libs. If you want a script, a simpler (oneline) format might be more practical. It is also easier to have a simple format when you later need to write adapters in case you still want XML. Whatever. You still might consider using two or more databases if you want a hierarchy: user-choices -> program-choices -> system-choices. No need to merge into one database if the later choices are fallbacks. clemens
ohk..... I get your point now. ---------------------------------------------------------------------------------------------------------------------------------------------- Cheers and Regards Jayesh Vinay Badwaik Electronics and Communication Engineering VNIT, INDIA - On Sun, Nov 27, 2011 at 2:38 AM, clemens fischer <ino-news@spotteswoode.dnsalias.org> wrote:
Jayesh Badwaik wrote:
Yeah. I too have my personal stuff for that. I have a script actually which uses a file and from that creates the default.list file which is then used by anyone who cares to use it (Firefox, KDE etc). But I am now tired of the custom stuff. I just wanted to explore. And XML seemed quiet universal in the sense.
And I have heard a lot but I still don't get it. Why is XML a beast? I have read everything from every source where people have even given point wise listings. But I am not able to appreciate anything. XML is just a way of writing data, right? Instead of parsing text you parse tags and their values. The only difference and advantage is that the stuff is more human readable.
I was talking from the viewpoint of the task you were trying to solve. You want a way to handle mimetype associations for file objects. There's not much info needed. XML is not the best format to parse without bloaty libs. If you want a script, a simpler (oneline) format might be more practical. It is also easier to have a simple format when you later need to write adapters in case you still want XML.
Whatever. You still might consider using two or more databases if you want a hierarchy: user-choices -> program-choices -> system-choices. No need to merge into one database if the later choices are fallbacks.
clemens
On 2011-11-21 23:36, Philipp Überbacher wrote:
So how is this stuff controlled these days? Those funky desktop files? gconf? dconf? Something else entirely?
The default programs are kept in ~/.local/share/applications/mimeapps.list, according to fd.o "MIME Actions spec". <http://www.freedesktop.org/wiki/Specifications/mime-actions-spec> All popular DEs - GNOME, Xfce, KDE - use this, and should respect explicitly set defaults. On 2011-11-22 00:06, Leonid Isaev wrote:
gconf, I think in gnome. In xfce (thunar) there is something like $HOME/.local/share/applications/mimeapps.list. They are all evil, however: http://www.youtube.com/watch?v=ovfYBa1EHm4 (ShmooCon 2011: USB Autorun attacks against Linux).
Waitwaitwaitwait. How the *hell* does the existence of XDG autorun spec automatically make all other XDG specs "evil"? Especially file-program associations, which are completely unrelated? -- Mantas M.
On (11/22/11 01:50), Mantas Mikulėnas wrote: -~> On 2011-11-21 23:36, Philipp Überbacher wrote: -~> > So how is this stuff controlled these days? Those funky desktop files? -~> > gconf? dconf? Something else entirely? -~> -~> The default programs are kept in -~> ~/.local/share/applications/mimeapps.list, according to fd.o "MIME -~> Actions spec". -~> -~> <http://www.freedesktop.org/wiki/Specifications/mime-actions-spec> -~> -~> All popular DEs - GNOME, Xfce, KDE - use this, and should respect -~> explicitly set defaults. -~> -~> On 2011-11-22 00:06, Leonid Isaev wrote: -~> > gconf, I think in gnome. In xfce (thunar) there is something like -~> > $HOME/.local/share/applications/mimeapps.list. They are all evil, however: -~> > http://www.youtube.com/watch?v=ovfYBa1EHm4 (ShmooCon 2011: USB Autorun -~> attacks -~> > against Linux). -~> -~> Waitwaitwaitwait. How the *hell* does the existence of XDG autorun spec -~> automatically make all other XDG specs "evil"? Especially file-program -~> associations, which are completely unrelated? -~> -~> -~> -- -~> Mantas M. Al right, evil might be too strong :) But still auto-associations means automatic thumbnailing in any decent file manager, like nautilus -- hence the above link. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Excerpts from Mantas Mikulėnas's message of 2011-11-22 00:50:25 +0100:
On 2011-11-21 23:36, Philipp Überbacher wrote:
So how is this stuff controlled these days? Those funky desktop files? gconf? dconf? Something else entirely?
The default programs are kept in ~/.local/share/applications/mimeapps.list, according to fd.o "MIME Actions spec".
<http://www.freedesktop.org/wiki/Specifications/mime-actions-spec>
All popular DEs - GNOME, Xfce, KDE - use this, and should respect explicitly set defaults.
Thanks, this page is rather informative and links to the original mailinglist discussion, hope I'll find time to read it and understand the reasoning for some of the decisions. For example, I find it odd that they wanted to have a way for an application to become the new default after installation ("Application X wants to be the default application for text/html after installation"). In my book there's no reason why this decision should be up to the application instead of the user (or possibly DE). Well, maybe I'll figure out their reasoning. Thanks again for the link. Regards, Philipp
În data de Lu, 21-11-2011 la 22:36 +0100, Philipp Überbacher a scris:
So how is this stuff controlled these days? Those funky desktop files? gconf? dconf? Something else entirely?
Usually other distros deal with this quite well, using a defaults.list file. For example Debian [1] and Ubuntu [2], though each other having the file in a different packages and different places, keep this thing almost sane. I'm not sure how is done for other DEs in these distros, but at least for GNOME this file has most of known/common file asociations. There is the gnome-defaults-list [1] package in AUR, but for personal reasons I believe is not done in the best way, thou it gave me a good ideea, and this is how I got to what I'm writing here. This package pulls an archive from Ubuntu, unpacks it, copies the defaults.list file into /etc/gnome then symlinks it to /usr/share/applications/defaults.list, which I find odd, it could've place the file there in the 1st place. Also, looking at this file, in both Debian and Ubuntu, I found out that is not what I'd want on my system, since I don't have some of the applications associated with some files in these distros. What worked great for me, was to take the files from both distros, compare them and come up with my own defaults.list [2]. Now, the great part in this, is that if you have some unusual file association, it's quite easy to add to the file, afterall, the "funky desktop files" are all in the same place, /usr/share/applications and can give you some ideeas. ;) [1] https://aur.archlinux.org/packages.php?K=gnome-defaults-list&SeB=x [2] http://ompldr.org/vYmU0ZQ/defaults.list -- <>< Sorin-Mihai Vârgolici Proud member of Ceata (http://ceata.org/)
În data de Ma, 22-11-2011 la 01:59 +0200, Sorin-Mihai Vârgolici a scris: Sorry, forgot to fix the links numbers and add 2 more. [1] http://packages.debian.org/search?searchon=contents&keywords=defaults.list&mode=path&suite=stable&arch=any [2] http://packages.ubuntu.com/search?searchon=contents&keywords=defaults.list&mode=exactfilename&suite=oneiric&arch=any
[3] https://aur.archlinux.org/packages.php?K=gnome-defaults-list&SeB=x [4] http://ompldr.org/vYmU0ZQ/defaults.list
-- <>< Sorin-Mihai Vârgolici Proud member of Ceata (http://ceata.org/)
On Mon 21 Nov 2011 22:36 +0100, Philipp Überbacher wrote:
Excerpts from Bernardo Barros's message of 2011-11-20 00:06:05 +0100:
text files opening automatically with wine is really a VERY annoying thing...
This is pretty clearly a DE issue. Are you all using the same DE or is this common behavior in all popular DEs? I rarely have any of those issues since I usually call my programs by name and ROX uses manual file association. Only firefox is sometimes hard to convince, but it uses gconf or some other DE stuff underneath. It's somewhat nice to see that DE users also have problems with that kind of stuff. Maybe this stuff can be changed using regedit or however that great program to change gconf settings is called. I'm sorry, somehow this ended up as another DE flame instead of being helpful. Oh well...
So how is this stuff controlled these days? Those funky desktop files? gconf? dconf? Something else entirely?
I'm thinking that this (the culprit) should be removed from all install scriptlets: update-desktop-database -q It's caused me headaches too. And I don't use any DE.
participants (14)
-
Bernardo Barros
-
clemens fischer
-
Clive Cooper
-
Jayesh Badwaik
-
Leonid Isaev
-
Loui Chang
-
Mantas Mikulėnas
-
Matthew Monaco
-
Mauro Santos
-
Myra Nelson
-
Oon-Ee Ng
-
Philipp Überbacher
-
SanskritFritz
-
Sorin-Mihai Vârgolici