> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> OK, I have updated my kludgy patch. Lars, would that be
Lars> acceptable to | you? The code only affects OSX.
Lars> Looks ok to me. But see comment.
I applied it, but I
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> This seems to be a std::find in disguise. Also do we really
Lars> allow cit-> table to be not initialized? I would think that
Lars> cit->table.get() == 0 to be an error.
cit->table is not 0 when the key is just a prefix for lon
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| OK, I have updated my kludgy patch. Lars, would that be acceptable to
| you? The code only affects OSX.
Looks ok to me.
But see comment.
| Index: src/kbmap.C
| ===
| RCS file: /usr/
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>>> However, since we are supposedly in freeze time, I came up with
>>> the attached kludgy but simple patch. It adds a method to
>>> kb_keymap that returns the first 1-
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> So, now you can access a list of all bindings associated with a
Angus> FuncRequest:
Yes.
Angus> and you would like to generate a QString for each kb_sequence
Angus> in this list. To do so, you need access to 'sequence' and the
Ang
Several days ago, JMarc wrote:
> Actually, the right thing to do would be to have
> kb_keymap::findbinding return a list of kb_sequence and expose only
> that to the frontends. This is more reasonable than this business of
> converting back and forth between strings and keys.
Some time later he wr
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> The patch is nice in that it returns a container of
Angus> kb_sequences when you ask for a container of kb_sequences,
Angus> rather than some stringified version of the same.
Yes, I decided thus to apply it.
Nevertheless, my orig
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> This piece of code cannot modify anything. That, after all, is
Angus> the whole point. It simply provides a mechanism to iterate over
Angus> immutable LyXKeySyms.
Agreed.
Angus> What do you want? An accessor to the 'first' variabl
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]>
>> writes:
>
> Angus> The patch is nice in that it returns a container of
> Angus> kb_sequences when youask for a container of kb_sequences,
> Angus> rather than some stringified version of the same.
>
> Yes. But
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> The patch is nice in that it returns a container of
Angus> kb_sequences when youask for a container of kb_sequences,
Angus> rather than some stringified version of the same.
Yes. But I thought we were not in 'make nice code' mode a
Angus Leeming wrote:
> The patch is nice in that it returns a container of kb_sequences when
> youask for a container of kb_sequences, rather than some stringified
> version of the same.
>
> If you're interested in reading the contents of kb_sequence, then why not
> add to kb_sequence:
Actually,
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]>
>> writes:
However, since we are supposedly in freeze time, I came up with
the attached kludgy but simple patch. It adds a method to
kb_keymap that returns the first 1-key binding to a FuncRequest.
>
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>>> However, since we are supposedly in freeze time, I came up with
>>> the attached kludgy but simple patch. It adds a method to
>>> kb_keymap that returns the first 1-
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
>> Bennett, could you try it and tell me whether it fixes the problems
>> in LyX/Mac? Note that this will not display the emacs-like two-key
>> bindings, but this is a limitation of Qt/Mac, as far as I can see.
Bennett> It works! That is
Jean-Marc Lasgouttes wrote:
> Angus> It would be nicer if getLabel returned a QString in the first
> Angus> place, wheich would also enable you to move the #ifdef block
> Angus> back into getLabel.
>
> Yes, that can be done but... [see below]
>
> Angus> Otherwise, have you not forgotten to do som
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>> However, since we are supposedly in freeze time, I came up with the
>> attached kludgy but simple patch. It adds a method to kb_keymap
>> that returns the first 1-key binding to a FuncRequest. This is much
>> easier than writing the com
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote: One other point. This:
>> label += '\t' + QAccel::keyToString(key);
Angus> is deprecated in the Qt docs which state that you should use:
>> label += '\t' + static_cast(key);
Angus> Ditto with any use of
Jean-Marc Lasgouttes wrote:
One other point. This:
> label += '\t' + QAccel::keyToString(key);
is deprecated in the Qt docs which state that you should use:
> label += '\t' + static_cast(key);
Ditto with any use of QAccel::stringToKey which should be replaced by
QString qstr("foo");
Bennett, could you try it and tell me whether it fixes the problems in
LyX/Mac? Note that this will not display the emacs-like two-key
bindings, but this is a limitation of Qt/Mac, as far as I can see.
It works! That is, all combinations of modifier keys and normal keys
(including function keys) s
Jean-Marc Lasgouttes wrote:
> Angus> Rather than try and do this yourself, why not generate a
> Angus> QKeySequence from the binding and then invoke:
>
> Actually, the right thing to do would be to have
> kb_keymap::findbinding return a list of kb_sequence and expose only
> that to the frontends.
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Rather than try and do this yourself, why not generate a
Angus> QKeySequence from the binding and then invoke:
Actually, the right thing to do would be to have
kb_keymap::findbinding return a list of kb_sequence and expose only
tha
Angus Leeming wrote:
> to generate the QString. Something like this, perhaps:
Actually, reading the Qt docs, this is the way to do it:
#include
#include
#include
#include
#include
QString const toqstr(char const * str)
{
QTextCodec * codec = QTextCodec::codecForLocale();
ret
Jean-Marc Lasgouttes wrote:
> I think that everything would be working smoothly if we did not try
> to use QKeySequence instead of the text representation of bindings,
> but a smoother way would be to keep the unicode representation
> intact in the frontend.
>
> Ideas, anyone?
Jean-Marc,
am I co
I had high hopes that the fact that I used native Qt menu shortcuts in
menus would make LyX/Mac magically display the shortcuts, but it turns
out that I have been overoptimistic.
Currently the shortcuts do not appear, and it seems to be due to the
following explanation from qkeysequence.cpp:
/*!
24 matches
Mail list logo
