[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [RFC, PATCH] Introduction of intermediate "text/x-source"
From:       Roger Larsson <roger.larsson () norran ! net>
Date:       2004-04-26 8:48:21
Message-ID: 200404261048.21288.roger.larsson () norran ! net
[Download RAW message or body]

On Thursday 22 April 2004 12.16, Waldo Bastian wrote:
> On Thu April 22 2004 00:47, Roger Larsson wrote:
> > Solution:
> > 	text/x-chdr -> text/x-source -> text/plain
> > 			^kate
> >
> > 	text/x-diff -> text/x-source
> > 	^kompare	^kate
>
> Why is the introduction of text/x-source needed? Why can't text/plain be
> used for this?

It could but take a look at the mimetype-editors.patch - why is so many
x-source types listed (but not all... emacs does not list x-fortran, 
x-javascript, ...) - we did not have the IsAlso before.

But the IsAlso brings new problems if all editors are associated at that 
level, you loose knowledge about that some of the formats has specific
syntax rules and editors that understands those would be preferred - a editor
that understands one syntax can probably handle only that (kompare) or most 
(kate, emacs). kate and emacs could be used for everything if you don't mind
startup speed, resource usage. I think the following should be a good default:

	text/plain 		- unknown syntax, 
					kedit (plain, simple, fast)
					or: kwrite (quite fast, but more complex)
	text/x-source	- text with formal syntax, source code editors
					kwrite (syntax highlightning, completions, block comment)
					Developers can change this to: kate
					but I am not sure that all want to - kate is best at
					handling projects, and kwrite uses kates text editor anyway.
	text/x-chdr...	- If I like to use a specific editor for c headers 
				  (why should I? No KDE defaults, unless there are a specific
				   application available like for x-diff)
	text/x-diff		- kompare, ...
	text/html		- shouldn't it be IsAlso text/x-source or text/plain?
				 (If I do not have quanta installed I might want to edit it in kwrite,
				but initial preference might become a problem here...)

The point is that x-chdr is the level that is really not necessary, you can 
see that on the incomplete listings, but ther might be cases where the user
want to be very specific - then they are needed.

Even if this might not be THE WAY something needs to be done...
(create yourself a new user and browse among the file associations...)

The same situation exists for audio and images, are you really interested in
needing to maintaint associations / preference on the lowest mime level?
Wouldn't a x-image and x-audio be enough (and then add to specific only if
your generic does not handle that format)?

/RogerL


-- 
Roger Larsson
Skellefteċ
Sweden
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]