"Vincent van Ravesteijn - TNW" writes:
> So, now I can start complaining about Windows :)
Yes please :)
JMarc
>>> I hoped there would be a solution that would avoid changing LyXFunc
>>> at all and just ignore() early when the key event are unknown.
>>
>> Ah, probably because you want to isolate all Qt-related code within
>> frontends/qt4/. Here's yet another approach, at the keyPressEvent()
>> level:
"Ben M." writes:
>> I hoped there would be a solution that would avoid changing LyXFunc at all
>> and just ignore() early when the key event are unknown.
>
> Ah, probably because you want to isolate all Qt-related code within
> frontends/qt4/. Here's yet another approach, at the keyPressEvent()
>
On 05/07/2009 16:06, Jean-Marc Lasgouttes wrote:
Le 2 juil. 09 à 04:00, Ben M. a écrit :
I hoped there would be a solution that would avoid changing LyXFunc
at all
and just ignore() early when the key event are unknown.
Ah, probably because you want to isolate all Qt-related code within
front
On Sun, Jul 05, 2009 at 04:34:45PM +0200, Jean-Marc Lasgouttes wrote:
> Le 5 juil. 09 � 16:06, Jean-Marc Lasgouttes a �crit :
> > Unfortunately this does not tell me that it is working. I am currently
> > compiling on OS X, but the problem is to know what to test.
>
> Everything I tested on OS X
Le 5 juil. 09 à 16:06, Jean-Marc Lasgouttes a écrit :
Unfortunately this does not tell me that it is working. I am currently
compiling on OS X, but the problem is to know what to test.
Everything I tested on OS X seems correct.
Abdel, could you have a look please?
The plan could be to apply
Le 2 juil. 09 à 04:00, Ben M. a écrit :
I hoped there would be a solution that would avoid changing LyXFunc
at all
and just ignore() early when the key event are unknown.
Ah, probably because you want to isolate all Qt-related code within
frontends/qt4/. Here's yet another approach, at the k
> I hoped there would be a solution that would avoid changing LyXFunc at all
> and just ignore() early when the key event are unknown.
Ah, probably because you want to isolate all Qt-related code within
frontends/qt4/. Here's yet another approach, at the keyPressEvent()
level:
http://www.lyx.or
Le 1 juil. 09 à 22:02, Ben M. a écrit :
Thank you. I don't yet know proper C++ syntax, so I will do these
silly things while I learn.
No problem, I am here just for that. You are a very efficient student :)
What I would like is to drop the "Unknown function part" and only
test
on isKnown.
On Wed, Jul 1, 2009 at 6:40 AM, Jean-Marc Lasgouttes wrote:
> First incident remark: use
> known = !qkey_to_string(key_).empty();
> instead.
Thank you. I don't yet know proper C++ syntax, so I will do these
silly things while I learn.
> What I would like is to drop the "Unknown function par
"Ben M." writes:
> On Tue, Jun 30, 2009 at 5:12 AM, Jean-Marc Lasgouttes
> wrote:
>> What I would like (but I have not understood yet where to do that) is to
>> use reject() only when we have an unknown keysym. We should not reject
>> events because M-C-j is not bound currently, but because a giv
> Sure, how's this?
> http://www.lyx.org/trac/attachment/ticket/6043/multimediakeys3.diff
I verified that this patch also works on trunk.
Multimedia keys do work in Document - Settings, and Tools -
Preferences, but don't work in File - Open. I wonder if I missed a
QKeyEvent somewhere. However,
On Tue, Jun 30, 2009 at 5:12 AM, Jean-Marc Lasgouttes wrote:
> What I would like (but I have not understood yet where to do that) is to
> use reject() only when we have an unknown keysym. We should not reject
> events because M-C-j is not bound currently, but because a given
> multimedia key is not
Jean-Marc Lasgouttes writes:
> What I would like (but I have not understood yet where to do that) is to
> use reject() only when we have an unknown keysym. We should not reject
ignore()
> events because M-C-j is not bound currently, but because a given
> multimedia key is not handled by
"Ben M." writes:
> According to
> http://doc.trolltech.com/3.3/qkeyevent.html#details
> "Key events for multi media keys are ignored by default. You should
> call QKeyEvent::accept() if your widget handles those events."
Very good detective work (although you should point to the 4.2
documentati
According to
http://doc.trolltech.com/3.3/qkeyevent.html#details
"Key events for multi media keys are ignored by default. You should
call QKeyEvent::accept() if your widget handles those events."
Currently, LyX calls accept() for everything, so multimedia keys are
undesirably blocked:
http://w
16 matches
Mail list logo