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
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
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
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
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
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
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? :)
>
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo