bugGNU TeXmacs - Bugs: bug #31334, Incompatibility Qt keyboard...

 
 

You are not allowed to post comments on this tracker with your current authentification level.

bug #31334: Incompatibility Qt keyboard shortcut system and TeXmacs shortcut system

Submitted by:  Joris van der Hoeven <vdhoeven>
Submitted on:  Thu Oct 14 20:05:57 2010  
 
Category: Qt portPriority: 9 - Immediate
Item Group: ErrorStatus: Ready For Test
Privacy: PublicAssigned to: Massimiliano Gubinelli <mgubi>
Originator Name: Open/Closed: Open
Release: Release: None
Fixed Release: NoneFixed Release: 
Keywords: 

(Jump to the original submission Jump to the original submission)

Tue Sep 4 16:01:36 2012, comment #7:

Is this still valid? I'm not sure the current implementation is what's stated below. Should we close this? And what is "a keyboard shortcut which does not work"?

Miguel de Benito <mdbenito>
Project Member
Sat Oct 16 13:15:28 2010, comment #6:

Cool; this works for me.

Of course, the solution is still fragile:
if the user provides a keyboard shortcut which does not work,
or if we compute an incorrect shortcut ourselves,
then the menu item won't work either.

If there is indeed a way to distinguish between
click->command and shortcut->keypress,
then that would be perfect: click-command should
be as before and shortcut->keypress as in the new solution.

Joris van der Hoeven <vdhoeven>
Project Administrator
Fri Oct 15 21:17:55 2010, comment #5:

Fixed in r3387. Now menu items that do specify a keybinding will send a keyboard event directly to the TeXmacs widget (bypassing the Qt widget layer, in particular they are not converted in QKeyEvent). Maybe it would be nice if we conditionally activate the shortcut or the command depending on the mode of activation of the menu item (click->command, shortcut->keypress).

Massimiliano Gubinelli <mgubi>
Project AdministratorIn charge of this item.
Fri Oct 15 16:14:19 2010, comment #4:

As an aside: the Alt-[ shortcut poses a problem on French keyboard: the square bracket is obtained as Alt-Shift-( so it is not possible to type Alt-[.

Massimiliano Gubinelli <mgubi>
Project AdministratorIn charge of this item.
Fri Oct 15 15:31:24 2010, comment #3:

Yes, this last workaround is more or less what I proposed.
Of course, it would be better if we could distinguish whether
the event was triggered by a menu or the keyboard.
Does Qt provide some way to do this? Maybe you can ask
on some mailing list.

One shortcut which examplifies the problem is A-[ tab
(with auto-closing brackets). The A-[ shortcut produces [].
Next, pressing tab undoes the insertion of [] and inserts [[
instead (in order to create a right-open french interval).
Yet other intervals can be produced by repeatedly pressing tab.

btw: Is it possible to define a keybinding for the current window,
which overrides the binding from the menu, but yet leaves
the binding in the menu being displayed?

Joris van der Hoeven <vdhoeven>
Project Administrator
Fri Oct 15 13:47:29 2010, comment #2:

A possible workaround: upon activation menu items which are associated to a shortcut will not execute their command but generate a keyboard event. This keyboard event will be subsequently handled by texmacs and generate an action.
This will work under the assumption that menu items generate exaclty the same action (when clicked for example) as the associated to shortcut.
Drawback is the clicking on the menu item associated to shortcut X will be indistinguishable to typing X (so for example click+var will be interpreted as X var).

What do you think?

Massimiliano Gubinelli <mgubi>
Project AdministratorIn charge of this item.
Fri Oct 15 13:28:14 2010, comment #1:

Your proposed workaround will not work properly since the same action is taken when a menu item is selecter or when the corresponding shortcut is activated. Discriminating between the two origins would lead to cumbersome code (maybe should be considerer as a last option to fix this problem).
I do not understand this issue: if TeXmacs claims that keybinding X is associated to a given command then this command should be performed whenever the binding is pressend independently of subsequent keys.

Could you point out a problem with a specific shortcut?

Massimiliano Gubinelli <mgubi>
Project AdministratorIn charge of this item.
Thu Oct 14 20:05:57 2010, original submission:

Currently, when defining a keyboard shortcut for a menu command,
Qt automatically enables this keyboard shortcut for the widget.
The corresponding keyboard events are no longer sent to TeXmacs,
and the commands are directly executed by Qt.

This is incompatible with the TeXmacs shortcut system.
For instance, assume that "X" is some shortcut,
occurring in the menus, but "X var" is also a shortcut.
Then the shortcut "X var" will never be executed,
because the key-press "X" is never sent to TeXmacs:
when pressing "X", the shortcut command is directly
executed by Qt.

A possible workaround might be to bind the Qt keyboard shortcut
to a command which simply generates the corresponding keyboard
events for TeXmacs. In the above example, the command associated
to the shortcut "X" would just send a keypress "X" event
to TeXmacs.

Joris van der Hoeven <vdhoeven>
Project Administrator

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mdbenito (Posted a comment)
  • -unavailable- added by mgubi (Posted a comment)
  • -unavailable- added by vdhoeven (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue Sep 4 16:01:36 2012mdbenitoSummaryIncompatability Qt keyboard shortcut system and TeXmacs shortcut system=>Incompatibility Qt keyboard shortcut system and TeXmacs shortcut system
    Fri Oct 15 21:17:55 2010mgubiStatusConfirmed=>Ready For Test
    Thu Oct 14 20:06:25 2010vdhoevenPriority8 - Very high=>9 - Immediate
    Thu Oct 14 20:06:10 2010vdhoevenPriority5 - Normal=>8 - Very high

    Back to the top


    Powered by Savane 3.1-cleanup