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

I've just loaded a lot of software to handle canon raw photo files. If I browse a directory with any raw files in it Dolphin crashes as soon as I move the mouse over one.

There is an association for these files to gThumb and by the name and the problem I wonder if the crash is due to Dolphin trying to display a thumbnail. dcraw / ufraw seem to have a facility for desktops to display thumbnails but it doesn't seem to work.

Any ideas? Even if there is a method of just allowing the files to be click loaded. Gimp etc has no problem loading them at all. Gwenview ignores them when using it to browse pictures. The files can be downloaded from the camera too in printer mode.



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

By Alex Schuster at 06/14/2012 - 05:39

John Woodhouse writes:

Maybe it's this bug? <a href="" title=""></a>

Upgrade, 4.6 is ancient. As a workaround, turning off the info panel
might help.


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

By John Woodhouse at 06/14/2012 - 08:10

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.

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.

On this Dolphin crash - very recent comment on one of ##raw sites regarding thumbnails - works on gnome but not on kde so far. May be no point in upgrading anyway and I wonder what will happen when I add asro picture formats. :-) The UK weather may improve some day but hasn't for the last 10 years at least other than when it's sub zero.


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

By Duncan at 06/14/2012 - 12:42

John Woodhouse posted on Thu, 14 Jun 2012 05:10:09 -0700 as excerpted:

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 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.

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.

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

By John Woodhouse at 06/28/2012 - 08:01

A bit of a note on dolphin going totally awol as soon as the cursor is moved over a canon raw photo file.

Dolphin just disappears basically and a crash report pops up.

I recently added some older canon raw files that are dot crw rather than .cr2. CR2 is the one that causes the crashes. dot crw just does nothing and open with can be used and it makes no attempt at showing a thumbnail. Cannon and others will no doubt continue to change their file naming every now and again each time a new camera comes out basically so that they can tell the difference.

Can't help laughing. It reminds me of my 1st excursion into commercial software production where I rapidly learned that there is a need to filter out what subsequent software will accept and do nothing if not in the list as painful and boring as that may be. In my case it was not fully scanning keyboard input intended for entry into a data base. The data base accepted what it was given as it should as in this case that wasn't it's responsibility. Things are a little different when the entries were read later - the odd characters might be disc errors and couldn't display so it threw an error. The solution was to scan every entry for acceptable characters and wipe the field if there are any problems. That discourages users from messing about which some will do.

Duncan might like to note that once I wrote that input routine it cropped up in every bit of code I wrote. It makes a lot of sense to only write one function and always use it- re akanodi etc. :-) That also encouraged me to move out of commercial software development as I prefer a more varied life. This attitude also helps me accept change. Things often get in such a mess eventually that things have to be re done from scratch and improvements and changes get harder and harder to add as the code evolves. The only answer at some point is to throw the lot away and start again. :-) My management used to hate that as they always do but the problem can be minimized via due attention to structure.