John Woodhouse posted on Thu, 14 Jun 2012 05:10:09 -0700 as excerpted: > Turning it off is a thought however even from the bug it looks like > Dolphin sees it as a picture file so there may be a better way. Is > associations the only place file types are kept? Or is there another > hidden away. If the association with raw files being picture files can > be disabled it will enable me to use Dolphin without problem. There is > not a lot of point in click launching them. It's more a case of using > "open with". I assume if I go through a program selection process for > the 2 or 3 apps that I might use to open raw files they will appear in > the open with tab? > > Another approach might be to create another association group. I would > hope that this is possible? Then I should get the open with options I > will need. I hope but again need to know if this info is only kept in > the associations system. Please don't reply on top of the quote; it seriously screws up context. Reply inline (as I am here), snipping the context you're not replying to and edit/summarizing [square braces are traditionally used to indicate edit/summary rewording] if necessary to keep the quoted text under a page or so between inline replies. (Obviously "a page or so" is only a guideline, since displayed page sizes will differ, but if someone's paging down more than twice and they've not deliberately made their window size tiny or are trying to read it on a phone or something with a way tiny display, it's too much.) That makes it MUCH easier for other people to reply properly to you, too. Associations: KDE (and I think gnome, but I don't run it) uses mimetype associations, tho it uses extensions as a hint on the mimetype. If you open the associations applet in kde settings, you'll see the setup. Groups are via top-level mimetype (image/ here, or text/ etc) and only contain the default emedded-viewer vs. external-viewer option for that top-level mimetype. Individual sub-types (image/raw in this case, I believe, text/plain and image/jpeg being other examples) are where the real association goes on. Among other things, you can override the group's embedded vs. external viewer option, set various extensions that belong to that mimetype, manually change or add/delete the various apps associated with that type and change their preference order, etc. What you apparently need to do is override the image-group's default embedded-viewer options, setting it to external-viewer, for image/raw. Setting up a different top-level or even subtype mimetype is possible but can be complicated since there's the freedesktop.org standards to worry about and if you deviate from them, various bits will complain (generally only to STDOUT for kde apps, which isn't a big deal since that's usually routed to /dev/null or ~/.xsession-errors for X apps, but anyway...). However, I don't believe you'll need to worry about that as the above override to external-viewer will hopefully fix it. Similarly, click-to-open simply opens with the top ranked association, while open-with gives you a choice of all associated programs. Thus, in ordered to disable click-to-open, you'd have to delete the association for all associated programs, thus eliminating the open-with list as well. You'd then get the generic open-with app-browser dialog each time. Again, that's possible, but I don't believe it would fix the problem, which is I think the embedded-viewer. AFAIK the info is indeed only kept in the associations system (tho in a running kde session that's cached to ksycoca, which should rebuild automatically if you change the associations using kde settings, but you can always trigger a rebuild manually by running kbuildsycoca4 from krunner or whatever), but that associations system is rather more complex than most people realize. But hopefully simply resetting the embedded viewer to external viewer, for the image/raw mime-subtype, will be all you need to do. =:^) Meanwhile, FWIW, I believe it's kdcraw that would be the problem package, here. That's the interface between kde and the usual dcraw. > Upgrade - NO - Lots of people will run opensuse 11.4 for a long time > yet. Probably until 12.3 has been out for some months. I need my machine > and have little time to play. I bug report when I can too but the > residuals I'm left with can't be bug reported sensibly There are only 2. > Well known - machine goes awol for a just about an unbearable time along > with much disc tinkling. Kmail - Over maybe a month or probably more of > no reboots or kde restarts it may stop receiving mail. Relationship to > Kwallet changes ie doesn't ask for a password when kmail starts up and > sometimes asks for it before it's started. The later seems more > prevalent lately. I'm thinking of bugging that to Novell but haven't > found any clues as to why it happens yet. 30 or often more active > browser tabs may be something to do with it. The kmail bug is extremely likely to simply rot at this point (at least with kde, SuSE might do something, but I'd guess not), because all of kdepim is going akonadified, now, and that's probably the last non-akonadified version. I believe we've covered this before, but if you're in the least interested in switching to something other than kmail, I'd STRONGLY suggest that now is the time. The conversion/upgrade to the akonadified format is problematic for some, and there remain enough bugs with the new system that a lot of people are switching to other things. Thus, if you're the least bit interested in doing so, or the least bit worried about stable mail, I'd STRONLY suggest switching now, before your next upgrade, while you have a bit of time to plan and execute the switch. It may be that you can wait and the switch will go off without problems for you and you'll be perfectly happy with akonadified kmail and/or kontact. However, if you seriously depend on mail and can't afford lost mail or unexpected mail downtime, as I said, I'd STRONGLY suggest that you at minimum have a backup mail client tested and working (including access to your mail archives and addresses if you rely on them), before that upgrade, and it's only a tiny jump from that, to a full swtich. Enough people have had problems with it, that if you depend on it at all, at least having the backup ready is definitely wise. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.