[RFC long] Opening files from different applications (gideon) - generic MIME configuration problem?
David Faure
dfaure at klaralvdalens-datakonsult.se
Wed Aug 13 10:48:18 BST 2003
On Thursday 24 July 2003 02:35, Roger Larsson wrote:
> a) When browsing files local and you click on a .h file (text/x-chdr) you
> might have specified it to open in an new application window like kate.
>
> b) But when working in gideon, you rather like text/x-chdr to open up
> embedded in gideon - but you might like to specify the application (katepart)
The "application" and "component" configurations are separate already,
no problem there. See the two tabs in "kcmshell filetypes".
> c) My "text/x-diff" has Kompare as last application alternative is this the
> default?- it should be first.
Then Kompare should provide an InitialPreference value (higher than the other
apps associated with text/x-diff).
> d) When working in gideon I might like to open/work with
> * any file in khexedit...
> * text/html in KHTML, katepart, or (future) quantapart
> (and the preference might change instantaneously)
>
> Add some more options to gideon then... or is this more generic?
Maybe you want to query for a KParts::ReadWritePart in gideon,
if it's more about editing than about viewing. But then you won't get
KHTML for html... What's the underlying concept then?
> 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...
Associating another app to inode/directory should work, but only when
opening that dir from another app (minicli, krun, kdesktop, etc.)
> f) for *.txt (text/plain) kword was preferred over katepart...
Probably a wrong profile entry (cf Waldo's fix). The initial preference is lower
so this shouldn't happen on a clean install.
> 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.
> 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 problems).
> * 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?
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.
> 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.
> * 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.
Yes.
> BTW, opening a jpeg file in
> konqueror uses khtmlimage
> gideon uses the kviewviewer
> Nice isn't it :-)
Then gideon doesn't use KTrader.....
> * No hardcoded overrides - please...
Yes.
> * The konqueror inode/directory case is probably an oversight, fixing it
> will make user configuration errors visible.
>
> OR should there be a possibility for applications to override?
> is inode/directory and text/html always overridden in konqueror?
> Should the user be able for the user to see this somewere?
IMHO inode/directory is a special case, I think when you're already in
konqueror it should always open in konqueror (just like, when you're in kview,
opening an image opens it in kview, not in your preferred image viewer!)
> * MIME types for plug-in based applications.
> gideon resembles konqueror in several ways since they both integrates kparts
> => gideon should be able to Open any file supported by its kparts.
> How to express this? Maybe it shouln't... it kind of works already...
?
> * 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.
> Maybe there should be an "Open With" option?
KWord isn't supposed to launch another app, I think there's a confusion here.
> * 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.
> 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 :).
--
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions
More information about the kde-core-devel
mailing list