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

[Roger Larsson]

On Wednesday 13 August 2003 11.48, David Faure wrote:
> On Thursday 24 July 2003 02:35, Roger Larsson wrote:
>
> > 	e) If I configure inode/directory to default to another application than
> > 	konqueror it is ignored by konqueror...
>
> Would you really want konqueror to open another app every time you
> click on a directory? This sounds really cumbersome...

Yes it sounds cumbersome... 

> Associating another app to inode/directory should work, but only when
> opening that dir from another app (minicli, krun, kdesktop, etc.)
>

But this inconsistency is even worse what was even worse was when I had
specified quickshow to be the preferred one. And everyting seemed to work
but not clicking on a device icon on the desktop - it, but nothing else,
opened in quickview... (bug:46894)

If konqueror were consistent I would never have run into this problem -
I would have fixed the preferrence in a heart beat :-)

> > 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...
>
> Which global setting? "kcmshell filetypes"?
yes

> This is very very vague, what you're saying here.

I have made a number of bug reports that have boiled down to me having
a unusual mime type setting...

>
> > 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!
>
> Sounds all bad indeed (but those are gideon problems, not generic mime
> problems).

I think they are generic mime problems.
They want to open a set of files in an embedded text editor.
But the user might have specified almost anything - so they override it (hard)

>
> > * 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?
>
> Because one is for viewing and the other is for editing?

Yes, that is one reason.
I guess the other reason is to be consistent within kdeveloper.

> This is why I'd suggest querying for a ReadWritePart - but then we need to
> extend the component configuration (maybe not in "kcmshell filetypes", it
> would get a bit too crowded, IIRC we have a component chooser module, but
> that's different too)...
>
> >   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 - see the genericServiceType argument in KTrader.
> Currently it's usually Application or KParts/ReadOnlyPart. In your case it
> would be KParts/ReadWritePart, and the profile could have entries for
> this case (this should work already). What's missing is the user
> configuration for this.

Yes, Is the icon suggested below enough?

>
> > 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
>
> I think mimetype inheritance solves this better.

text/x-c++hdr -> text/x-source [new!] -> text/plain -> all/allfiles -> all/all
The user needs to be able to navigate in this hierarchy!
And I guess we should clean things up...

kate.desktop MimeType association
	MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;
	text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;
	text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
Could be simplified as
	MimeType=text/english;text/plain;text/x-source
	[I guess x-makefile inherits x-source]

kwrite.desktop could be simplified to
MimeType=text/english;text/plain;text/x-source;text/x-tex;
	[Assuming application/x-shellscript and text/x-diff to inherit from
	 text/x-source]


BTW, Can the system handle kwrite having higher preference for text/plain than 
kate but lower than kate for text/x-source. And at the same time having lower
preferrence for text/x-diff than kompare...

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

Will this be enough - an icon?

>
> > * File Open dialogue
> > 	Why isn't it possible to open a .kpr (kpresenter) file with kwords
> > Open...?
>
> It is possible here - because there's a kpresenter->kword filter. I don't
> see the relation with the discussion at hand though.

Mine fails with "Could not open" even if the file is available...

>
> > 	Maybe there should be an "Open With" option?
>
> KWord isn't supposed to launch another app, I think there's a confusion
> here.
>

But "Open with..." has its uses too - when working with a file you often want
to edit another file in that directory (but sometimes it is of another type 
and not visible in the Open dialogue)

> > * Quick change viewer/editor
> > 	think khexedit for any file in gideon, I have it specified for
> > "all/allfiles"
> >
> > 	Suppose all applications could easily change from the current one to
> > 	another one that supports the mime type you are currently looking at?
>
> Again, not all apps are application launchers, I'm not sure this is really
> necessary. If I launched KWord to edit text, I don't need an "open in kate"
> menu item there, I already chose to do my editing in KWord.

Maybe a "Reopen in ->"
When Opening in a viewer I sometimes like to edit the file. Or do something 
else with it. Or maybe hexedit it...


>
> > 	Suppose that you in an application built with plug-ins easily could
> > change between the plugins that support the current mime type?
>
> Makes sense (feel free to grab code from Konqueror :).

Filing a wish! (bug:62604)

-- 
Roger Larsson
Skellefteå
Sweden