[PATCH] Re: [RFC long] Opening files from different applications (gideon) - generic MIME configuration problem?
Roger Larsson
roger.larsson at norran.net
Fri Jul 25 02:41:07 BST 2003
On Thursday 24 July 2003 12.11, Waldo Bastian wrote:
> On Thursday 24 July 2003 02:35, Roger Larsson wrote:
> > Hi all,
> >
> > Have you ever been hit by a MIME type related bug?
> > I have, they are among the most common bugs that I run into when using
> > KDE. And worse - they may lead to really strange problems...
> > Especially when applications (konqueror, gideon) makes silent overrides!
> > This is mostly to trigger some thinking in large - I will file additional
> > bug reports / wishes for the specific issues later.
>
> I think a lot of the text:plain related issues can be solved with the new
> isAlso property of mimetypes.
>
> E.g. applications such as kword, kate and khtml shouldn't check for
> mimetype == text/plain but should check for mimetype.isAlso(text/plain)
> instead. That way they will suddenly understand that they can open
> application/x-python just fine. (Assuming application/x-python has an
> is-also-text/plain property)
But that only solves the problem when you already is executing the application
code.
But the application/viewer won't show up as choice in Open With, you have to
select Other... and browse to the application - the user has to know that the
application can open a specific filetype...
Try this:
# echo "Test" > test.latex
or
# echo "Test" > test.url
Now try to open it in different ways - thumbnail view is the only part that
gets it right.
None of kwrite, kate, kword offer its help.
For me khexedit does (I have it associated with MIME type "all/allfiles")
Something is missing from the .desktop files not in the application source.
To take a specific example - gideon
What would be needed in the .desktop system to be able to remove the
hardcoded mimeinfo?
Hmm... I might need to repeat why hardcoded bindings is bad even if
they were using isAlso(text/plain) even if it is much better than the
current code. Suppose I had developed a new python specific editor plug-in.
How would I configure it - application/x-python naturally...
But that will not work because gideon sees that application/x-python
isAlso(text/plain) and opens with the default editor for text/plain...
If I know this then I can configure my really python specific editor for all
text/plain... even if it is not even decent at edition text/x-csrc files...
Today this happens (when bug is corrected and isAlso is used)
if "application/x-python".isAlso("text/plain") {
open with plug-in associated with "text/plain" unless
gideon is configured with a application specific
"EmbeddedKTextEditor" then try to use that.
I added a patch for gideon that uses the new isAlso property
(compiles, not tested, it is late...)
Note (this feature not a bug): if you try to open a application/x-python and
have a EmbeddedKTextEditor defined, then it will only be used if either:
* There are no editor defined for application/x-python (then check the parent)
* The EmbeddedKTextEditor is defined for application/x-python
Note: most mime descriptors are lacking the isAlso property...
/RogerL
PS
Shouldn't KMimeType::parentMimeType() return a KMimeType::Ptr?
Atleast rename the current to parentMimeName()...
DS
--
Roger Larsson
SkellefteƄ
Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: partcontroller.cpp.patch
Type: text/x-diff
Size: 6689 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030725/afb93da5/attachment.patch>
More information about the kde-core-devel
mailing list