GtkDialog - How to Perform function conditionally? [SOLVED]

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#16 Post by MochiMoppel »

SFR wrote:Yeah, KEY_SYM/KEY_VAL might be indeed a better choice, just note that if SHIFT is pressed, the output values/characters reflect the difference (unlike KEY_RAW)
I know, but that's rather an advantage. We may not need the extra check for the Shift status:

Code: Select all

<action signal="key-press-event"> [ $KEY_SYM = A ] && xmessage " Shift+A pressed"</action>
<action signal="key-press-event"> [ $KEY_SYM = a ] && xmessage " A pressed"</action>
/usr/share/doc/gtkdialog/examples should be in devx_xxx.sfs, but here's the online version:
Thanks for this hint. I seldom load devx_xxx.sfs and I haven't noticed, but I swear I downloaded it from somewhere else...
Reading the reference online is OK, but having the examples only online is a bit cumbersome. I found a slightly old package which might be worth downloading just for the examples it includes. I'm sure there are others: https://www.archlinux.org/packages/comm ... gtkdialog/

EDIT 1
If we would want SHIFT alone, it would be $(( $KEY_MOD & 1)) = 1, only CTRL - $(( $KEY_MOD & 4 )) = 4 and so on.
(I hope it's clear enough?)
Well, finally it seemed to be clear, but unfortunately it doesn't produce the expected result. $(( $KEY_MOD & 1)) = 1 checks it the Shift bit is set and and judging from the formula it doesn't care about the other modifier bits, but when running your example with this condition the variable is refreshed in cases of Shift+R, Ctrl+Shift+R, Alt+Shift+R etc. , likewise your original example refreshes in case of Crtl+Shift+Alt+R :cry:

Compare this to the rock solid behavior of my usual menubar approach:

Code: Select all

#!/bin/sh
# Shift+R to refresh the date 
export MAIN=' 
 <window> 
  <vbox>
    <hbox>
      <menubar width-request="1" height-request="1">
        <menu>
          <menuitem accel-key="0x52" accel-mods="1"> 
            <action>Refresh:varDATE</action>
          </menuitem>
        </menu>
      </menubar>
    </hbox>
   <text> 
     <variable>varDATE</variable> 
     <input>date</input> 
   </text> 
  </vbox>
 </window>' 

 gtkdialog -cp MAIN
1) In contrast to the key-press-event solution it doesn't matter whether I use accel-key="0x52" (small r) or accel-key="0x72" (capital R). Both work the same. Quite amazing.
2) Of course the variable refreshes only when Shift+R was pressed
3) Needs a bit more boxes, but makes multiple actions and functions easy. With the condition set in <menuitem> and therefore out of the way, all following actions are easy to read and maintain.
4) Usually I set <menu use-underline="true"> and add <label>"_M"</label> to the menu section. Then upon hitting Alt+M the menu pops out of nowhere. At least during development useful for testing the correct assignment of the accel-keys .


There are some downsides...that's why I'm still very much interested in making the key-press-event solution work

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#17 Post by SFR »

MochiMoppel wrote:$(( $KEY_MOD & 1)) = 1 checks it the Shift bit is set and and judging from the formula it doesn't care about the other modifier bits, but when running your example with this condition the variable is refreshed in cases of Shift+R, Ctrl+Shift+R, Alt+Shift+R etc. , likewise your original example refreshes in case of Crtl+Shift+Alt+R
Yep, that's exactly what I mentioned in the attached txt. 8)
me wrote:The above method has a flaw though. If we want to probe e.g. SHIFT+some_key, discarding all other bits will return positive results also if
SHIFT+CTRL+some_key or SHIFT+ALT+some_key or SHIFT+CTRL+ALT+some_key (and so on) are pressed.

So, I think that best solution is to discard only NUMLOCK's, CAPSLOCK's (and those two unknown bits') states, in which case the AND mask will be always constant: 10001101 (141), and only the value we comparing it with will vary.
However, knowing now (more or less) what those two "unknown" bits are, I think it's enough to discard only NumLock, CapsLock and Mod3 (which appears to be Scroll_Lock, not enabled by default in Puppy though).
So, $(( $KEY_MOD & 205 )) = 1 will do the job properly.
MochiMoppel wrote:4) Usually I set <menu use-underline="true"> and add <label>"_M"</label> to the menu section. Then upon hitting Alt+M the menu pops out of nowhere. At least during development useful for testing the correct assignment of the accel-keys .
F10 has the same effect in my case.
Actually, I'd like to disable it, but nothing from what I have found does work. :roll:

Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#18 Post by MochiMoppel »

SFR wrote:F10 has the same effect in my case.
Actually, I'd like to disable it, but nothing from what I have found does work. :roll:
Seems to be a gtk default thing. If you use JWM you can override it with a dummy shortcut. <Key key="F10">exec:</Key> works for me.

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#19 Post by SFR »

Thanks, I did not think of that. Alas it disables this shortcut completely and (clarifying the problem) the real PITA is that F10 overrides application's specific shortcuts, e.g. in RoxTerm or LxTerminal there's no way to quit htop or MidnightCommander using F10, because it opens terminal's "File" menu instead.

Well, I found this on several forums (to be put in ~/.gtkrc-2.0):

Code: Select all

binding "NoKeyboardNavigation" {
    unbind "<shift>F10"
}

class "*" binding "NoKeyboardNavigation"
and it apparently works for most of folks, but not for me (with or without <shift>).

Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#20 Post by zigbert »

I have linked to this thread from the 'Gtkdialog Tips' thread.

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#21 Post by MochiMoppel »

SFR wrote: it apparently works for most of folks, but not for me (with or without <shift>).
Doesn't work for me either, but this does:
Step1: Create file /root/.gtkrc.mine (I didn't have one and the theme changer overwrote my settings in /root/.gtkrc-2.0 and referenced this file. I didn't bother to check how to put it permanently into .gtkrc-2.0)
Step2: Input the line
gtk-menu-bar-accel=F20
I know that the default is F10, but I don't know the syntax. I tried to set it to F12 and other real function keys, but it doesn't work, so I thought I might as well use a dummy key. The important point is: No menus popping up anymore and the Press and Release Events script now accepts F10. It didn't respond before.

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#22 Post by SFR »

Ha, great, works for me as well, at last - thanks a lot! :D
Just tried and we can also, e.g.:

Code: Select all

gtk-menu-bar-accel="<ctrl><shift>F10"
to not lose that functionality completely.
Quotation marks seem to be crucial - F12 works too, if it's wrapped by "".

Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#23 Post by MochiMoppel »

Seems we have a win-win-win situation here: I've got all my questions answered, I learned about the F10 feature, you solved your F10 problem...who could ask for more? :D

Let me wrap up the result, using your example script:

Code: Select all

#!/bin/sh
# ============= Various shortcuts to refresh the date =================================
#
# A            (Depends on keyboard layout, also responds to Shift+A,Ctrl+A, Alt+A etc.)
# B            (CapsLock must be off, responds to Shift+B when CapsLock on, also responds to Ctrl+B , Alt+B etc.)
# C
# Ctrl+Shift+D
# 0 ~ 9        (= any numeric key)

export MAIN=' 
<window> 
  <text> 
    <variable>varDATE</variable> 
    <input>date</input> 
  </text> 
  <action signal="key-press-event" condition="command_is_true([ $KEY_RAW = 0x26 ] && echo true )">Refresh:varDATE</action> 
  <action signal="key-press-event" condition="command_is_true([ $KEY_SYM = b ] && echo true )">Refresh:varDATE</action> 
  <action signal="key-press-event" condition="command_is_true([[ $((KEY_MOD & 205)) = 0 && $KEY_SYM = [cC] ]] && echo true )">Refresh:varDATE</action> 
  <action signal="key-press-event" condition="command_is_true([[ $((KEY_MOD & 205)) = 5 && $KEY_SYM = [dD] ]] && echo true )">Refresh:varDATE</action> 
  <action signal="key-press-event" condition="command_is_true([[ $((KEY_MOD & 205)) = 0 && $KEY_SYM =~ (KP_)*[0-9] ]] && echo true )">Refresh:varDATE</action> 
</window>' 
gtkdialog -cp MAIN
Some notes:
Shortcut A: Apart from using KEY_RAW this is your reply to my original question. Works with limitations, but answered my question.
Shortcut B: Same as above, but using KEY_SYM. Different limitations, but easy to read and maintain. I love single key shortcuts, and this is the way to go for my private scripts.
Shortcut C: Also single key, but bullet-proof. This would be the way to go for published scripts. By using double brackets I can avoid the inherent case restrictions of KEY_SYM values. [cC] checks for both values, thus removes the only disadvantage of KEY_SYM.
Shortcut Ctrl+Shift+D: Basically your answer to my additional question about modifiers. I had little expectations, but now I am glad I asked. Without your bit masking magic I would never use a single key-press-event the way I did in the previous example.
Shortcut 0-9: Just pushing the envelope a bit further. The double brackets allow regex expressions, so why not use them? [cC] was already a simple example. Interestingly this time gtkdialog insists on a real "=~" regex operator, otherwise produces an error.

I think, that's it. Thanks a lot for your help and feedback!Image

Post Reply