Thanks toad, thats all I was looking for - some people like to have less I guess. The gtk picker has the equivalent of "Look in", you go up by clicking the name of the directory above the one you are in (but of course can click at any level in the path, not just the parent), and has a "~" link. But in addition has bookmarks to take you places you commonly used areas, and recently used areas. And even do a search.

Feel free to drop this thread yourself, but I am genuinely trying to understand why anyone would want to use the non-platform picker. I'll see if anyone else has any input.

Kryten for example said "I'd prefer the sidebar places to be synchronised" and found it awkward. I find the gtk picker grating because it behaves differently to the main file picker and is themed differently. But I wouldn't choose something so basic in place of it just because of these things.

paulkoan wrote:Kryten for example said "I'd prefer the sidebar places to be synchronised" and found it awkward. I find the gtk picker grating because it behaves differently to the main file picker and is themed differently. But I wouldn't choose something so basic in place of it just because of these things.

I guess I need to explain that one a bit better. Let's start with the synchronized part...what I mean by that is that if I add a "bookmark" to the gtk-fileselctor it should be reflected in the KDE equivalent. And yes, I know that is probably not feasable in the short run if at all but one can dream, right? For me as an individual, I can live with having two, three, or four different fileselectors (partially because I've grown used to it, and partially because I know the reasons why...i.e. kde/qt/gnome/gtk). Even if I would prefer not to.

The things is though, I have to support users who are NOT used to that, or know the reasons why (and they shouldn't have to either). The standard gtk+ fileselector and the kde4.x one look superficially very similar. They both, for instance, have a places-part on the left-hand side. They do, however, are sufficiently different to make it a hassle when you have to deal with people that do not know the background.

I've stopped counting the number of times people have asked me why a shortcut added to Dolphin shows up in Kate but not Gimp for example, or why a network shortcut doesn't work in gtk apps (since gtk apps don't know what a kio-slave is).

Maybe my pedagogy needs to be improved (and probably so), but I've found it easier and more productive to "work around" the differences. I.e. making sure kio-slaves are not used but instead using mount to make sure the directory is "locally" available, AND making sure that gtk+apps uses, as far as feasible, a file-selector that does not look like the KDE one. As strange as it may sound, it does help because the users do not seem to expect the same behavior if the look is different.

Maybe just my users though...

TheBlackCat: to make pdf open using a specific application when you double click it in the FF download manager, edit /usr/share/applications/mimeinfo.cache , search for: application/pdf= . Put the name of *application*.desktop of the desired application right after = .

So to use okular, it should look like this:
application/pdf=kde4-okularApplication_pdf.desktop

Notice the extra kde4- , this is necessary because okularApplication_pdf.desktop is in the subfolder kde4 in /usr/share/applications.

Replace okularApplication_pdf.desktop with whatever name of the .desktop file of the app you want. If it's in the same folder as mimeinfo.cache, i.e. /usr/share/applications then use the name of the .desktop folder, if it's in a subfolder then prefix it with kde4- , or kde- , whatever. See if this works.

mimeinfo.cache is a dynamic file and will be changed automatically when you install/uninstall a programme (this explains what happened when you uninstalled gimp). Of course you can keep a local copy of this file maintaining your own associations across reinstalls), you need to put this copy in ~/.local/share/applications , also a copy of /usr/share/applications/defaults.

https://bugzilla.mozilla.org/show_bug.cgi?id=266600

It is better now, thanks.

The gtk file picker and does not deserve the name. Here is what mine looks like::thumbs_up::thumbs_up:

how-to-integrate-f ... l#pid45566

@ Meda: There is also a "defaults.list" file, which I also changed. Changing one of those, or both, seems to have fixed it, but I am not sure which. Thanks!

mimeinfo.cache takes precedence, so changing mimeinfo.cache is what worked, I think. If you delete mimeinfo.cache or there's not application/pdf= entry in it then what's in defaults.list is what matters.

There should be some mechanism to make mimeinfo.cache has the same settings as mimeapps.list, mimeapps.list is what KDE4 looks at. But I guess it's one of those cases where the kde devs think it's mozilla's job to do this, and the mozilla apps think it's the kde devs who should fix this, still this is only a guess.

Does anybody use a colour-theme different than the default?
I am using the coral theme but applying kde colours to gtk-apps does not work properly. It is similar but more red. Any ideas why or where to look?
david

EDIT: Now that is weird. Just applied it again and it works for now inkscape but not firefox.

I'm really wondering, nobody mentioned mozplugger so far.

with kmplayer:


with okular:


with writer:

Hi soliver,

I don't understand, what has mozplugger to do with kde integration?

BTW, could you use a different uploader such as www.omploader.org - they don't insist on java scripting, ads and other unpleasantness

Integrating KDE Apps (kmplayer/okular/kword) into Firefox has nothing to do with integrating Firefox into KDE? :-S

Hm, when you put it like that

However, mozplugger makes my firefox crash consistently when trying to listen to the BBC

Is there a simple way to change out the firefox icons with ones of my own choosing?

I think Firefox uses themes for this purpose. I believe there are some Oxygen ones around somewhere.