On Thursday 15 September 2011 13:52:49 Wolf-Michael Bolle wrote:
> On Thursday 15 September 2011 10:55:41 ext David Faure wrote:
> > > > On the other hand I'm not sure that querying the association
> > > > with
> > > > applications and the open/view/edit distinction belongs there,
> > > > it
> > > > doesn't
> > > > seem very cross- platform -- but that's a separate discussion.
> > >
> > > Similar to KDE, I wanted to express the difference between open/view
> > > and edit, and also leave room for potential other uses.
> >
> > KDE doesn't do that, actually :-)
>
> I was referring to the second parameter of KMimeTypeTrader::query() which is
> genericServiceType. It is either 'KParts/ReadOnlyPart' or 'Application'.
> The KEditFileType utility exposes that as 'Embedding' and 'General' tabs. I
> creatively translated that into open/view and edit.
That's very different.
A part is a *component* used by e.g. konqueror and other programs.
But when the user selects "view" in an hypothetical file manager that allows
to choose between "view" and "edit", he expects an application to be started.
A part alone isn't an executable, it can't be started.
But the association between mimetypes and parts is IMHO not something that Qt
should take care of - these "parts" are very specific to one platform, there
is no cross-platform component technology ("QLibrary and a factory for a
QWidget" would only be a very rough approximation).
> > The desktop entry standard says: in the .desktop file of the
> > application,
> > list the mimetypes it supports. This doesn't leave room for open/edit
> > distinctions.
> >
> > We use "service menus" (a different kind of .desktop file, filemanager-
> > specific) to complement that and offer additional context-menu actions.
>
> Thanks for that input. I see that now in my
> /usr/share/kde4/services/katepart.desktop.
That's a part, not a service menu :-)
I see the confusion (coming from the "services" directory).
A .desktop file can define:
* an application (Type=Application) (freedesktop.org standard)
* a plugin (Type=Service) (KDE-specific)
The ServiceTypes entry defines the kind of plugin:
- KParts/ReadOnlyPart for parts (viewer components).
- KFileItemAction/Plugin for contextual menu actions
- anything else goes here, application-specific plugins, framework
plugins.
> > But I think determining mimetypes is a big enough job in itself, and the
> > relation to applications shouldn't be rushed in with it. We might even
> > have to get more freedesktop.org standards about this first, the
> > current solution for determining the default application preference
> > order is different between KDE and gnome, as well as the extra stuff
> > like open/edit and service menus.
>
> I see where you are going. We'll need to provide libQtCore.so for either
> Gnome, KDE or whatever else, then.
Well, I thought you were planning on doing this with plugins instead...
> To make the discussion about an API easier I could separate the applications
> out into a seperate class QMimeTypeHandling. What do you think?
Separating out the application stuff is most definitely needed.
"Handling" isn't a great name though.
The real question is whether this should be in Qt. Up to now I don't see a way
to implement "querying 1000 .desktop files for a given mimetype" without some
kind of cache, and an on-disk cache (ksycoca) is much preferrable to an in-
memory cache (which would mean that each and every application has to parse
all these files). So either Qt gets an equivalent of KSycoca or
KSharedDataCache, or this isn't something that Qt should implement.
The kservice framework that will soon be available as part of the "kde
frameworks" modularization effort could be used instead. All this on top of
QMimeType of course.
The most common case of "open this url in the associated application" being
already covered in QDesktopServices (by calling platform-specific
executables), I wonder if there is a use case in Qt for "give me all the
applications associated with this mimetype"?
--
David Faure, [email protected], http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
