[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 
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
# 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...


	Shouldn't KMimeType::parentMimeType() return a KMimeType::Ptr?
	Atleast rename the current to parentMimeName()...

Roger Larsson
-------------- 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