[RFC long] Opening files from different applications (gideon) - generic MIME configuration problem?

[Roger Larsson]

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.

	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)

This does not conflict with each other since you may only left click in 
konqueror. In gideon you open files with the standard dialogue.

	c) My "text/x-diff" has Kompare as last application alternative is this the
	   default?- it should be first.

	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?

	e) If I configure inode/directory to default to another application than
	konqueror it is ignored by konqueror... 
	(use separate viewer, place quickshow first gives bug:45771)

	f) for *.txt (text/plain) kword was preferred over katepart...

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

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!

* 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? 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, konqueror is pleased if it is possible to read and view - it does not
  need write. Gideon likes ReadWrite...)

Generic problems with this are:
* User configurability is lost, user might like to open files in
  different embedded editors depending on MIME type. But it might also
  indicate that there is to much configureability or missing features.
* Consistency is also lost (python, perl)
* This problem will get worse if more applications needs a application
  specific handling of MIME types.

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

* 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.
	BTW, opening a jpeg file in
	 konqueror uses khtmlimage
	 gideon uses the kviewviewer
	Nice isn't it :-)

* No hardcoded overrides - please...
	* 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?

	* The gideon case is intentional.
		* What would be missing if it only selects embedded or separate
		  depending on window model? (Child frame, IDEAl, ...)

* 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...?
	Maybe there should be an "Open With" option? 

* Quick change viewer/editor
	think khexedit for any file in gideon, I have it specified for "all/allfiles"

	konqueror kind of supports this (in two ways for text/html): 
	1) Location -> Open with Quanta plus [to edit?]
	2) View -> View Mode -> katepart [to view source]

	Suppose all applications could easily change from the current one to
	another one that supports the mime type you are currently looking at?

	Suppose that you in an application built with plug-ins easily could change
	between the plugins that support the current mime type?

Related to
	bug:58912 File Open gives "Could not import file of type text/x-chdr"
	bug:45771 konqueror not honoring user configured inode/directory
and more...

/RogerL

PS
	Yes, I have made really strange changes over the years...

	bug 51202 made me change text/plain to KHTML as a work around
	KHTML likes text/plain, but not text/x-chdr => bug 58912

	In bug 45771 I changed inode/directory to kuickshow and got some
	very interesting results...
DS



-- 
Roger Larsson
Skellefteå
Sweden