khexedit2 shows up everywhere

[Friedrich W. H. Kossebau]

Am Montag, 7. März 2005 18:21, schrieb David Faure:
> On Sunday 06 March 2005 22:53, Friedrich W. H. Kossebau wrote:
[suggestion to restrict HTML queries to explicit handlers]
> However, do we really want that?
> The fact that KHTML is bad at displaying text/xml is a separate fact from
> the general idea of mimetype inheritance. For instance, when we say
> x-executable-script.desktop:X-KDE-IsAlso=text/plain
> this means that we do accept a plain-text viewer for an executable-script,
> or C++ source, or a log file, etc.
> Or an image/jpeg viewer for an image/pjpeg image.
> Same thing with all aliases of course.

Yes, of course. All the mimetypes make up a big tree, with the handlers being 
able to deal with subtrees in it.

> It seems that we have the notion of "acceptable viewers" and "for experts"
> viewers? Vieweing the XML code behind text/xhtml or SVG is not what most
> people want to do with those files; only the "developers" of those files
> might want to do that. In that respect, khexedit is a "for experts only"
> (for all types of files).
>
> Now, how can we avoid "expert" viewers to come up by default? Well, I
> thought AllowDefault solved that. You're saying the same viewer is "ok" for
> some mimetypes and "expert" for others? In that case we need a per-mimetype
> setting for AllowDefault? Would this help? 

Seems like a good idea, indeed. 

Another idea: Perhaps we can do it in the mimetype descriptions. Aren't our 
expert viewers all those that show the object in another semantic level? So 
if we describe all such mimetype relation as "SourceIs" instead of "IsAlso" 
we could filter the expert viewers this way? The output of

  $KDEDIR/share/mimelnk> grep "X-KDE-IsAlso" * -R

suggests that it might work. 
So for "text/x-pascal" it stays "X-KDE-IsAlso=text/plain"
and "audio/mp4" keeps "X-KDE-IsAlso=video/quicktime"
but for "image/svg+xml" it gets "X-KDE-SourceIs=text/xml".

No idea how complicate this would be to implement in KTrader...

But then this is only for the presentation of the object. Hm. Perhaps somebody 
can elaborate this?

> Not that the .desktop file 
> format makes it really easy to add per-mimetype AllowDefault... But we
> might be able to piggyback this on Waldo's per-mimetype initial preference
> IIRC.

How?

> > The only problem: If KHTML does not find a proper part it searches for
> > other solutions. Here: fires up another konqueror window with a HTML part
> > for the svg file and asks for an application for the trash file. I do not
> > know if this is a suited reaction :(
>
> I'm not sure I see a problem with that reaction.

Those objects are supposed to be embedded in the html view, not to be 
separateley downloaded or shown in a separate window, aren't they? I would 
prefer it if like with broken images (data broken) there would be a special 
symbol in place which tells the user about a missing appropriate viewer.

> > The official docs are out  of date (property "MimeType" is now integrated
> > in "ServiceTypes")!
>
> MimeType and ServiceTypes have always been merged conceptually, since a
> MimeType *is* a ServiceType. The only reason we keep MimeType is f.d.o
> compat...

Ah, so this is the reason why all service.desktops still have a separate 
MimeType. Makes it look cleaner, though.

> > Shall I fix this?
>
> Sure.

Will do.

Thanks for the help
Friedrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050307/287f1e43/attachment.sig>