[RFC long] Opening files from different applications (gideon) - generic MIME configuration problem?
roger.larsson at norran.net
Wed Aug 13 16:19:55 BST 2003
On Wednesday 13 August 2003 11.48, David Faure wrote:
> On Thursday 24 July 2003 02:35, Roger Larsson wrote:
> > e) If I configure inode/directory to default to another application than
> > konqueror it is ignored by konqueror...
> Would you really want konqueror to open another app every time you
> click on a directory? This sounds really cumbersome...
Yes it sounds cumbersome...
> Associating another app to inode/directory should work, but only when
> opening that dir from another app (minicli, krun, kdesktop, etc.)
But this inconsistency is even worse what was even worse was when I had
specified quickshow to be the preferred one. And everyting seemed to work
but not clicking on a device icon on the desktop - it, but nothing else,
opened in quickview... (bug:46894)
If konqueror were consistent I would never have run into this problem -
I would have fixed the preferrence in a heart beat :-)
> > Changing the global setting might result in really strange problems, many
> > of the problems I see is related to me having changed default handling of
> > a mimetype, then something seemingly unrelated breaks...
> Which global setting? "kcmshell filetypes"?
> This is very very vague, what you're saying here.
I have made a number of bug reports that have boiled down to me having
a unusual mime type setting...
> > Gideon contains code that overrides the user settings to be able to open
> > everything embedded, see kdevelop/src/partcontroller.cpp:249
> > * Forces all text/* to be treated as text/plain, but does some further
> > special handling for text/html. Will I be able to use "quantapart"
> > (whenever it becomes available) for editing html files in kdeveloper?
> > BUT There is no guarantee that the user specified application for
> > text/plain likes to open text/x-chdr (like in Bug 58912, kword/khtml
> > does not like it)
> > * Forces some other specific MIME types (application/x-perl, /x-desktop,
> > ...) to be treated as text/plain.
> > BUT it does not force others (application/x-python, /x-ruby...)
> > This leads to inconsistency!
> Sounds all bad indeed (but those are gideon problems, not generic mime
I think they are generic mime problems.
They want to open a set of files in an embedded text editor.
But the user might have specified almost anything - so they override it (hard)
> > * Allows the user to specify a preferred "EmbeddedKTextEditor". I don't
> > like this option, why would I like to have another embedded text editor
> > in gideon than in konqueror?
> Because one is for viewing and the other is for editing?
Yes, that is one reason.
I guess the other reason is to be consistent within kdeveloper.
> This is why I'd suggest querying for a ReadWritePart - but then we need to
> extend the component configuration (maybe not in "kcmshell filetypes", it
> would get a bit too crowded, IIRC we have a component chooser module, but
> that's different too)...
> > I can think of only one case - in konqueror it is read
> > only and it could be a really simple and quick viewer. But then the
> > override should be in konqueror instead, shouldn't it? Or should it be
> > possible to specify differentiate between editor/viewer when konfiguring
> > MIME types?
> Yes - see the genericServiceType argument in KTrader.
> Currently it's usually Application or KParts/ReadOnlyPart. In your case it
> would be KParts/ReadWritePart, and the profile could have entries for
> this case (this should work already). What's missing is the user
> configuration for this.
Yes, Is the icon suggested below enough?
> > Suggestion:
> > * Group selectable defaults (application and embedded)
> > then Kwrite/kate could be the default for all text/* including future
> > ones and only specific applications like kompare would need to be
> > specified at a specific MIME type.
> > selection order: text/x-diff, text/*, all/allfiles, all/all
> I think mimetype inheritance solves this better.
text/x-c++hdr -> text/x-source [new!] -> text/plain -> all/allfiles -> all/all
The user needs to be able to navigate in this hierarchy!
And I guess we should clean things up...
kate.desktop MimeType association
Could be simplified as
[I guess x-makefile inherits x-source]
kwrite.desktop could be simplified to
[Assuming application/x-shellscript and text/x-diff to inherit from
BTW, Can the system handle kwrite having higher preference for text/plain than
kate but lower than kate for text/x-source. And at the same time having lower
preferrence for text/x-diff than kompare...
> > * Possible to specify embedded viewer (read only), editor (read / write).
> > Like for image/jpeg
> > khtmlimage is a KParts/ReadOnlyPart
> > kviewviewer is a KParts/ReadWritePart
> > The only thing missing is an indication/icon? of what kind of part it
> > is.
Will this be enough - an icon?
> > * File Open dialogue
> > Why isn't it possible to open a .kpr (kpresenter) file with kwords
> > Open...?
> It is possible here - because there's a kpresenter->kword filter. I don't
> see the relation with the discussion at hand though.
Mine fails with "Could not open" even if the file is available...
> > Maybe there should be an "Open With" option?
> KWord isn't supposed to launch another app, I think there's a confusion
But "Open with..." has its uses too - when working with a file you often want
to edit another file in that directory (but sometimes it is of another type
and not visible in the Open dialogue)
> > * Quick change viewer/editor
> > think khexedit for any file in gideon, I have it specified for
> > "all/allfiles"
> > Suppose all applications could easily change from the current one to
> > another one that supports the mime type you are currently looking at?
> Again, not all apps are application launchers, I'm not sure this is really
> necessary. If I launched KWord to edit text, I don't need an "open in kate"
> menu item there, I already chose to do my editing in KWord.
Maybe a "Reopen in ->"
When Opening in a viewer I sometimes like to edit the file. Or do something
else with it. Or maybe hexedit it...
> > Suppose that you in an application built with plug-ins easily could
> > change between the plugins that support the current mime type?
> Makes sense (feel free to grab code from Konqueror :).
Filing a wish! (bug:62604)
More information about the kde-core-devel