Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
Hi, I was experimenting with our 2 different approaches to implement this in kate4 yesterday. Somehow, after implementing KateApp::eventFilter() I kept seeing events being delivered to that function after commenting out the corresponding installEventFilter() call. That's with a KApplication::eventFilter() function in place, but non-virtual so it should be called instead of KateApp::eventFilter when that function is not installed. Have you checked whether `installEventFilter(this)` is redundant? Cheers, René ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
Hi, > Hi, > > I was experimenting with our 2 different approaches to implement this in kate4 > yesterday. Somehow, after implementing KateApp::eventFilter() I kept seeing > events being delivered to that function after commenting out the corresponding > installEventFilter() call. That's with a KApplication::eventFilter() function > in place, but non-virtual so it should be called instead of > KateApp::eventFilter when that function is not installed. > > Have you checked whether `installEventFilter(this)` is redundant? I think the difference is that in Kate4 KateApp inherits from *Application, in Kate5 it is just a simple QObject. Therefore I do there not installEventFilter(this) but installEventFilter(qApp) and qApp != this. For 4 I guess it is easiest to implement ::event like e.g described here: http://www.qtforum.org/article/23098/how-to-make-my-app-open-a-doc-by-dd-or-doubleclick-on-a-mac.html Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
On Tuesday January 05 2016 15:01:08 Christoph Cullmann wrote: >Therefore I do there not installEventFilter(this) but installEventFilter(qApp) >and qApp != this. Right. I must have seen that but not really realised what it implied. >For 4 I guess it is easiest to implement ::event like e.g described here: > >http://www.qtforum.org/article/23098/how-to-make-my-app-open-a-doc-by-dd-or-doubleclick-on-a-mac.html Ah, thanks. I certainly did not notice ::event(), interesting. Cheers, René ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
Hi,
> Hi,
>
>
> I have gotten a bit further. As I thought it is critical to have a correct
> Info.plist (or else the event is never sent), and it isn't trivial to edit
> that
> file "in place" and have the system recognise its new content (easiest way is
> to copy the entire app bundle in the Finder).
>
> You also need to set a flag (LSMultipleInstancesProhibited) in the Info.plist
> to
> avoid launching multiple copies; for some reason the mechanism that is in
> place
> to prevent that doesn't work when you drop a document on Kate's app icon in
> the
> Finder (or the Dock). So:
>
> NSPrincipalClass
> NSApplication
> NSSupportsAutomaticGraphicsSwitching
>
> LSMultipleInstancesProhibited
>
> CFBundleDocumentTypes
>
>
> CFBundleTypeExtensions
>
>*
>
> CFBundleTypeName
> NSStringPboardType
> CFBundleTypeRole
> Editor
>
>
>
> (The NSSupportsAutomaticGraphicsSwitching comes from QtCreator; I haven't
> check
> what it does exactly but it shouldn't harm).
Thanks for the hint with the plist file!
>
> With this, I see the events arrive in kate's main.cpp when I add the
> following:
>
> #include
> class FileOpenHandler : public QObject
> {
>Q_OBJECT
> public:
>FileOpenHandler(QObject *parent=Q_NULLPTR)
>: QObject(parent)
>{}
>bool eventFilter(QObject *obj, QEvent *event)
>{
>if (event->type() == QEvent::FileOpen) {
>QFileOpenEvent *foe = static_cast(event);
>qDebug() << Q_FUNC_INFO << "FileOpen event" << foe;
>// call KateApp::openUrl(foe->url() ...) from here
>return true;
>} else {
>return QObject::eventFilter(obj, event);
>}
>}
> };
>
> and then just before starting the main loop:
>
> #ifdef Q_OS_OSX
>FileOpenHandler *fileOpenHandler = new FileOpenHandler(qApp);
>qApp->installEventFilter(fileOpenHandler);
> #endif
I have added this now just to KateApp.
https://quickgit.kde.org/?p=kate.git=commit=cd6ec201725cf627a336015d472c39f5ff73b2a7
>
> Question is: what about the encoding parameter?
Can be just set to empty QString like done in my commit above.
>
> Also, for a local/MacPorts KDE4 implementation of this : if I add a signal to
> the KApplication class, do I need to rebuild all dependents to avoid
> ABI-related crashing, or only those that are modified to connect to the new
> signal?
> (IOW, can you add a signal to a class without breaking backwards
> compatibility?)
Signal adding should be binary compatible, but I doubt that is a good idea.
Why not just add the matching code to the applications you want to have support?
They will anyway need adjustments.
Greetings
Christoph
--
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
Science Park 1 Tel: +49-681-38360-22
66123 Saarbrücken Fax: +49-681-38360-20
GERMANYWWW: http://www.AbsInt.com
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
Hi, > On Saturday January 02 2016 19:56:28 Christoph Cullmann wrote: > > Hi, > > >> I have added this now just to KateApp. >> >> https://quickgit.kde.org/?p=kate.git=commit=cd6ec201725cf627a336015d472c39f5ff73b2a7 > > Hmm, thanks for the hint with the Info.plist? You mean you already knew about > the rest? :) Yeah, as said, I just never had time to implement it (and was too dumb to get MacOS to trigger the event). Besides: No need for ifdefs, QFileOpenEvent is there on all platforms, just without function. > >> Can be just set to empty QString like done in my commit above. > > That's what I hoped, but now I can just grab your patch. ;) Added the same to KWrite, both should be fine now, at least for the cases where we have some url. > >> Why not just add the matching code to the applications you want to have >> support? >> They will anyway need adjustments. > > Yes, but it'd be a bit easier if you can just connect to a signal, especially > if > you already have a slot that takes a QUrl to open. KDE4 has its own > QApplication derivative that can act as the "delegate" for the event; I find > that a more elegant solution if it can be implemented without breaking binary > compatibility. But you are aware that KDE 4.x is in pure maintainance mode and for KF5 based stuff the simplest solution will be the event filter (or adding ::event overwrite if the application already has inherited from qapp) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
On Saturday January 02 2016 20:24:25 Christoph Cullmann wrote: > Besides: No need for ifdefs, QFileOpenEvent is there on all platforms, just > without function. True, but there's no point in installing an event filter for it on platforms where the event never occurs. > But you are aware that KDE 4.x is in pure maintainance mode and for KF5 based > stuff I know, but it's not going anywhere anytime soon on client desktops and in MacPorts; not as long as Qt4 builds I reckon. Heck, I'll probably be sticking to KDevelop4 on my older hardware if what the KDevelop guys say about their new clang-based parser is true (and I believe it; even on my i7 earlier versions of that parser were *much* slower than the legacy C++ parser). R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
On Saturday January 02 2016 19:56:28 Christoph Cullmann wrote: Hi, > I have added this now just to KateApp. > > https://quickgit.kde.org/?p=kate.git=commit=cd6ec201725cf627a336015d472c39f5ff73b2a7 Hmm, thanks for the hint with the Info.plist? You mean you already knew about the rest? :) > Can be just set to empty QString like done in my commit above. That's what I hoped, but now I can just grab your patch. > Why not just add the matching code to the applications you want to have > support? > They will anyway need adjustments. Yes, but it'd be a bit easier if you can just connect to a signal, especially if you already have a slot that takes a QUrl to open. KDE4 has its own QApplication derivative that can act as the "delegate" for the event; I find that a more elegant solution if it can be implemented without breaking binary compatibility. Cheers, René ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
Hi,
I have gotten a bit further. As I thought it is critical to have a correct
Info.plist (or else the event is never sent), and it isn't trivial to edit that
file "in place" and have the system recognise its new content (easiest way is
to copy the entire app bundle in the Finder).
You also need to set a flag (LSMultipleInstancesProhibited) in the Info.plist
to avoid launching multiple copies; for some reason the mechanism that is in
place to prevent that doesn't work when you drop a document on Kate's app icon
in the Finder (or the Dock). So:
NSPrincipalClass
NSApplication
NSSupportsAutomaticGraphicsSwitching
LSMultipleInstancesProhibited
CFBundleDocumentTypes
CFBundleTypeExtensions
*
CFBundleTypeName
NSStringPboardType
CFBundleTypeRole
Editor
(The NSSupportsAutomaticGraphicsSwitching comes from QtCreator; I haven't check
what it does exactly but it shouldn't harm).
With this, I see the events arrive in kate's main.cpp when I add the following:
#include
class FileOpenHandler : public QObject
{
Q_OBJECT
public:
FileOpenHandler(QObject *parent=Q_NULLPTR)
: QObject(parent)
{}
bool eventFilter(QObject *obj, QEvent *event)
{
if (event->type() == QEvent::FileOpen) {
QFileOpenEvent *foe = static_cast(event);
qDebug() << Q_FUNC_INFO << "FileOpen event" << foe;
// call KateApp::openUrl(foe->url() ...) from here
return true;
} else {
return QObject::eventFilter(obj, event);
}
}
};
and then just before starting the main loop:
#ifdef Q_OS_OSX
FileOpenHandler *fileOpenHandler = new FileOpenHandler(qApp);
qApp->installEventFilter(fileOpenHandler);
#endif
Question is: what about the encoding parameter?
Also, for a local/MacPorts KDE4 implementation of this : if I add a signal to
the KApplication class, do I need to rebuild all dependents to avoid
ABI-related crashing, or only those that are modified to connect to the new
signal?
(IOW, can you add a signal to a class without breaking backwards compatibility?)
R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
Hi, > On Saturday January 02 2016 20:24:25 Christoph Cullmann wrote: > >> Besides: No need for ifdefs, QFileOpenEvent is there on all platforms, just >> without function. > > True, but there's no point in installing an event filter for it on platforms > where the event never occurs. That small overhead doesn't hurt and we don't have yet an other code path that is only compiled on mac os. > > >> But you are aware that KDE 4.x is in pure maintainance mode and for KF5 based >> stuff > > I know, but it's not going anywhere anytime soon on client desktops and in > MacPorts; not as long as Qt4 builds I reckon. > Heck, I'll probably be sticking to KDevelop4 on my older hardware if what the > KDevelop guys say about their new clang-based parser is true (and I believe > it; > even on my i7 earlier versions of that parser were *much* slower than the > legacy C++ parser). I personally wouldn't want to stick with stuff that is not actively developed and fixed anymore, but you are right, it won't go away that fast. But keep in mind e.g. for Kate/KWrite, no KDE 4.x based non-critical (aka dataloss) bugs will be fixed anymore, we even have not enough manpower to keep all master bugs in check :/ Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
On Saturday January 02 2016 20:24:25 Christoph Cullmann wrote: Hi, Something else: is the KateApp supposed to be subclassable? In that case you may want to put the FileOpen event back into the queue rather than eating it (i.e. return false instead of true from the event filter), so that the descendant class can receive it too. If events work that way of course, I've never tried. > That small overhead doesn't hurt and we don't have yet an other code path > that is only compiled on mac os. Agreed, not in a text editor, no. > I personally wouldn't want to stick with stuff that is not actively > developed and fixed anymore Heh, if it ain't broke, don't look for ways to fix it ... at least not beyond what's reasonable ;) The big advantage of using stuff like this (and that works well enough to get the job done) is that you actually get around to getting jobs done rather than spending a significant amount of time applying updates (or worse, building them). I've already decided that I'm not going to upgrade my ports in sync with the monthly release cycle but instead wait until there's a sufficiently long list of fixes, new features etc. to warrant the overhead. Don't worry about me submitting patches for any of this in KDE4. I may decide to publish some of the ones for KDELibs via RRs but that's about it. R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
On Friday January 01 2016 20:24:59 Christoph Cullmann wrote: >I think the Qt support is already ok enough, the application just needs to >handle it. >That should just be a few lines of code, not sure if any more wrapping will >make this less work. You're probably right. Would be nice though if there were some kind of unified interface that presents standard file open requests to the application, regardless of whether they came in over DBus, LaunchServices or whatever mechanism might exist on other platforms. >I think the one with the QString is atm the thing Kate can easily support. OK. The one returning a QUrl is probably the same, for local files at least. >Then that is all fine, as long as Qt handles all right with the QFileOpenEvent >each app >that wants to have support just needs 5 lines of handling this event. > >Guess I should add the handling to Kate/KWrite ;=) Keep me posted if you get around to it, or if not :) You'd also have to figure out what additional information to add to the Info.plist, about the filetypes the applications can handle. If Kate handles RTF too you can just copy that from TextEdit, I guess. Cheers, R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
On Friday January 01 2016 20:24:59 Christoph Cullmann wrote: Hi, > Guess I should add the handling to Kate/KWrite ;=) I just made a quick attempt, not very successful. From what I understand, you either have to subclass QApplication in order to provide a dedicated ::event() method, or maybe you can use an event filter. That's what I tried. The filter gets loads of application events, but not the QEvent::FileOpen event we're interested in. 'night, René ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
Hi, > On Friday January 01 2016 17:47:17 Christoph Cullmann wrote: > > Hi, > > Apparently you already looked into this? > >> I can tell you that this needs to be done at the application level, not at >> kpart >> level. > > Can you explain why? Does that mean it won't be possible to encapsulate the > functionality in a framework? I think the Qt support is already ok enough, the application just needs to handle it. That should just be a few lines of code, not sure if any more wrapping will make this less work. > >> E.g. in Kate, you would need to handle QFileOpenEvent just like a dbus >> request >> to open >> a new file (atm I guess only the variant that has some url is feasible, the >> other variant >> won't work with the current interfaces to the editor part we have). > > The QString QFE::file() variant, or the one that returns an opened QFile? I'm > not sure that one would even be relevant (or even in what circumstances it has > to be used). I think the one with the QString is atm the thing Kate can easily support. > >> >> Same for e.g. KWrite, just open a new windows with the file, like file open. > > If memory serves me well, the old MacOS used to handle file open requests like > that: it would more or less send the same even to the application that would > be > sent when using the File/Open menu, and somehow shortcut the file selection > dialog. > At least, that's what the guy I shared my office with claimed, but he was > usually right about this kind of thing :) Then that is all fine, as long as Qt handles all right with the QFileOpenEvent each app that wants to have support just needs 5 lines of handling this event. Guess I should add the handling to Kate/KWrite ;=) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
Hi, > Hi, > > Best wishes for 2016! > > As hinted in the subject, I've dusted off a resolution from last year: > finding a > way to support opening files "the Mac way". > Some of you probably know that OS X doesn't hand off the documents to be > opened > in the standard argc,argv way when an application is started through the > Finder > (LaunchServices in general). Rather, a specific event is sent that contains a > reference to the file; this mechanism is the same whether the application is > already started or not. > > Qt has had an interface to the underlying mechanism since at least v4.6, but > KDE > never used it. I see that KF5 applications already set the NSPrincipalClass to > NSApplication; that is a requirement, but not a sufficient one for the > mechanism to work. > > When the system receives the request to open a file, Qt will send an instance > of > a QFileOpenEvent to the QApplication instance, which will need to take action > on it. This event contains the filename, but also a function that is capable > of > opening files that cannot simply be opened by name. > > I think it should be possible to connect (the filename from) this event to a > central mechanism that signals applications that a file should be opened. But > I > am not so sure if such a mechanism exists. I would assume that KDE > applications > have been designed for the kind of desktop shell that is used on Linux and MS > Windows, in which the GUI for opening a document with a given application > spawns a new instance of that application which receives the filename through > the argc,argv interface. > It should be relatively easy to write a handler for QFileOpenEvents that just > spawns a new copy of the running process, something like > > fork() > execvp(argv[0], qFileOpenEvent->file()) > > and let the child process decide whether it should continue to exist as a > separate application or hand off the argument(s) to the running > KUniqueApplication instance. Drawbacks: in the first case the separate child > process will open somewhere behind the parent process; in the latter case we'd > be taking a detour (but there may not be a standard way in which > KUniqueApplications hand off documents to be opened to the running instance?). > > So what are the options here to hook into the QFileOpenEvent feature in such a > way that applications need to as little modification as possible to deploy the > new functionality? It's likely though that they'd require a dedicated > Info.plist file. > > If multiple solutions exist, I'd prefer those which are easiest to backport to > KDE4 (for local patching). > > Anyway, I'd be interested in beginning to work on a proof of concept > implementation using Kate (hopefully in the kpart so that all applications > building on the Kate editor can benefit). Or should I rather aim for > KTextEditor or even KXmlGui? Anyone care to think along with me on this one? I can tell you that this needs to be done at the application level, not at kpart level. E.g. in Kate, you would need to handle QFileOpenEvent just like a dbus request to open a new file (atm I guess only the variant that has some url is feasible, the other variant won't work with the current interfaces to the editor part we have). Same for e.g. KWrite, just open a new windows with the file, like file open. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)
On Friday January 01 2016 17:47:17 Christoph Cullmann wrote: Hi, Apparently you already looked into this? > I can tell you that this needs to be done at the application level, not at > kpart level. Can you explain why? Does that mean it won't be possible to encapsulate the functionality in a framework? > E.g. in Kate, you would need to handle QFileOpenEvent just like a dbus > request to open > a new file (atm I guess only the variant that has some url is feasible, the > other variant > won't work with the current interfaces to the editor part we have). The QString QFE::file() variant, or the one that returns an opened QFile? I'm not sure that one would even be relevant (or even in what circumstances it has to be used). > > Same for e.g. KWrite, just open a new windows with the file, like file open. If memory serves me well, the old MacOS used to handle file open requests like that: it would more or less send the same even to the application that would be sent when using the File/Open menu, and somehow shortcut the file selection dialog. At least, that's what the guy I shared my office with claimed, but he was usually right about this kind of thing :) R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
