https://bugs.kde.org/show_bug.cgi?id=365210
--- Comment #2 from Till Schäfer <till2.schae...@uni-dortmund.de> --- hmm you are right, krarc:/path/to/file.ext.gz works as expected. I see two ways to handle this situation: Solution 1: Even if katepart can transparently view/edit gziped files: handle them as single file archives, because there exist other applications which cannot handle gziped files transparently. Furthermore, the shortcuts to view or edit a gzip file still work directly on the gzip file. It is therefore easy to edit the files directly with katepart (and only katepart / other applications which can handle gzip transparently are cut of). Solution 2: Alternatively, we must differentiate between the associated applications of the second order extension and mime type, e.g. <filename>.txt.gzip (text/plain; charset=us-ascii compressed-encoding=application/x-gzip; charset=binary) would open directly with kate and <filename>.mp3.gzip (audio/mpeg; charset=binary compressed-encoding=application/x-gzip; charset=binary) would trigger the krarc browsing as my associated player does not handle gzip files transparently. I do not know if there is an easy way to know if an application can handle gzip transparently. It might therefore be troublesome to implement this feature (but still: it would be pretty cool :-) ). -- You are receiving this mail because: You are watching all bug changes.
