KDE 4.6 ---- Dolphin Crashes on a mouse over

[Duncan]

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.