I just installed dwm on Arch and am loving it. However, I found that I have no use for the status bar except when I'm switching tags, so I thought a useful feature would be to only display it while MODKEY is pressed.
I know that MODKEY+b toggles the bar, but I'd like to be able to peek at it while MODKEY's being held down. I'd also prefer that this doesn't consume the event, so I'll still be able to chain additional keys onto the sequence.
The only thing I found online about this was a post from Lokichaos (https://warosu.org/g/thread/24122078):
I split the difference with "peek" behavior. When I hold down Mod4 (my main dwm modkey) it shows the bar (but does not reserve space for it). The bar also auto-shows when there is an urgent client waiting (so I can see the highlighted tag). [...]
Is there any way I could implement this with my config.h file, or would I need to get into the nitty-gritty dwm.c? Any ideas as to how this could be done in an organized fashion so that I could bind other actions to key presses and releases?
Thanks for your help!
--EDIT--
This patch allows you to listen to release events, (they even show you how to toggle the bar with pressing/releasing MODKEY+b), but I'm only able to listen to presses and releases on non-mod keys. Again, my goal is to have the bar display when I press MODKEY, and disappear again when I release it.
Here are the three things I've tried in config.h:
type modifier key function argument
{ KeyRelease,MODKEY, 0, togglebar, {0} },
{ KeyRelease,MODKEY, NULL, togglebar, {0} },
{ KeyRelease,MODKEY, XK_Super_L, togglebar, {0} },
...to no avail.
You may try holdbar patch to serve your purpose. I am using this and it is working seamlessly without any errors.
Note that after using this, togglebar will not work any more and bar will be always hidden. Also you cannot map HOLDKEY to simply MODKEY as it takes keysym bindings. You can get them by running xev and pressing the required key. It's keysym value in hexadecimal will be displayed. I use the Super (Windows) key and it's keysym value is 0xffeb. I have applied the same patch. If you want to see, you can view it on Github.
Related
I'm linking an arcade button connected to a USB encoder with a Max patch. The button is behaving strangely. Here's what happens:
I have the button mapped to the a key. When Max is open, this functionality breaks. Even outside of Max. Even once I close Max, I need to remap the key. I'm not using MAME or anything like that; just JoytoKey for the mapping.
This issue is negated partially through use of the HIobject. Max recognizes the button and I can use it, however it's not functioning as an on/off. Rather a bang is sent on button press and release. How do I make the button work normally (send a single bang on press, and none on release)?
Here's my patch, if it helps. I don't know how useful it is without my video files:
<pre><code>
----------begin_max5_patcher----------
2245.3oc6cszbjpaEdsmpl+CTr1gB8hGYY1jJYaRVMUptvzx1ZtzPGdX6I2J
+2i3YyCoF0.M8hqbMi6FjP5b9zQe5bPvw+92+1Sluj7EMyz3Oa7Cimd524m4
opyUdlmZOwSlmB9JLJHqphlEmnwElO2TzGAowAmnBJIt3DKNhlWcUf1ydNHk
W8bZ5AZbvKQzAExxomp6j+JMllxBMLL9W+i+hgweO4WY4rveyvneymTj219n
tl3X00m7xO+S.+tJWWy7eclVqqlr3bymMLq9uw+9hvkG9NK9sCozv75Zhv9V
DhM+G.B.P1Pf+yF.Hwxl+gKn7CHzx9RajE7A83gf77T1KE4zKeKqATaQ0RrK
pfl7Z646JnOJEkD+lX.dP0NwGhJqhsnBydOIMWgFge9SM3ib7uSSGbosPKro
r+22+V82Z+Rym7OdVYKsSzrrf2ncih4zuxaJPlcFTr4APj4AQt4wBrIbsKsE
P9WrHVrdGS+jKfSU62YyL4ZnRCEnzH45bDKKegyG78rP9k+f7g1HnC.xw.d8
taHwOY4VexhOl7ow4nfeUJ5GYYm6p34TZFMNOHmkDeHhESCSJhyGPTLnJWzO
Hvxydj5g8qFacvk+lX2e19MMNzuKkZUBskOD8RP7ayODAvdkPuCeTojjBh1.
SxH1GTqJ3WDw+zRkft.WGqJCEWaWejKDa6H15AWg0.Rer9TxQZeNNy7zf3LV
KZBWwBOqY.C3cEdj4GrVChbOWqYxXpv0a.yudy0andq4vEQPIfw+DtmKyHij
IiFYPlyhF54Nkv.BpWL.O08.UVs5lr+bwqkuPUU3t.v9lKBY5C.j0B.XfqkM
4AA.dqG.bVK.f7.ON.vctoXBc4XWmh4tZ.VQU3t.vNyBv.eKzCkCya0.rhpv
1GKh+pCDg3uz.Qv1tUNYSpiCcK73Vpd5sd8zcwAbwcRxdmzSEni.R.8EAPpL
+frhPUw6lEhB7L1RFFueHGZwHG.sa1by6koqmkCtLJAOO9uID281BDrTbDx8
sPEQ+drz2rgix65p.sFHaMVoKDVuoE9vvUGruhpvcwyB7r1sDQC96nmEXvpi
NRQU3t.vnYAX.4ACvq91UopJbW.X3rTDdXKviDfQ9qlhPQU3t.vfYAXBxxy+
QBvqN3CUUgECvuFkTdaxl8lq5VuqTv16S8UwtqdmQ6tGquljdJnpCb1Brlb8
6UZEdOy8KUlRt4luoAwGSNY.rUE3qcpwwYYFs2j+XH702aSkvvox616Z67tH
fcEvNsit1hVtqsbyOv8z0Von5B8KXGQU3huoFPf28MfAon5BcFXOQ0EeKT.d
tOHa0E5Avdhp3EipDGkD8Eipkazc6NbO+xPB16ZTIWe0ONDhCAX6iJcJoZqg
Qd27dYitosF8JVqbE6.2whT1WsOGNGYgkMVP5uVf2VXazT0j.br7KOGDh4.B
1Ai4CHt98U5njDtpbNIMefVbLHOXxdnFFwN28vRMXSTexL3krjnhbJWfeuB.
9aw4oIG9mexdKH8TFz5TxGW1.TteUrHZ2VjpPc+MVbMvxKiQKOS+ZTpEC2NV
tzlDmyGgNjwGjnc66aegtZX4bQd6Fqyw1da6ZcwGZER9XVgK101FgvXyg06H
qYObAOOtIJoAJRoCZFDFU0LvQMSoVPqUyeXXOpKRC9LOYxjxdZwgltR3kmy3
7SgAQMk5XOp7ORhZz.qQkTjQOlkew7arbMnrmK+2TPnTwNmv8KK6PFMrwDpx
0U6wcWvwfy4BGLRaFFEHiGKR6lHNQBOmb4Yj3GS6vRjYnTMr7vjHdH.cVHlA
ou8h4zlPXW+ZYfEWlcMo7vfv24cN6+1d4Vf5Iw17kprA.GAh5oLgMUPQdBmO
gEJsT97fTwHKeHNKMT5PbQL6+THQAOKC13C1zzyBundVCcJyyBgttmZoqzFx
ZfgDaBafdHxnRGBGRrpuvDIbVIM9MVbmUyGuZ1rL3fmaitkCmiNkUQQVdHkO
Hec5TEpqlNUSmpoS0zoZ5zRJRvMPmBzzoZ5TMcplNUSmNlNMHH8LRApTo0SS
ipoQ0znZZTMMJTQZTcv8ZZTMMplFUSiJjFEnHMpNndMMplFUSipoQmPi1tq7
pPkd05poS0zoZ5TMc5eToSG9PNYftgmHJC8cKUSnpIT0DpZBUo6gO5F1CeMc
plNUSmpoS+CCcZaASSSX0snYYNBbbdPs5cOHpoG58BZjkTjF11sco.tdJn4Q
ZVNKt2Dlt2YOiq9xfndORTpC2t9yUk9qJ2EtU8nuYeygqqgcYHP1w9lrXDYZ
ZsBPpRQmHjS86.Y+i7qR4GnxyMIEWhr1FEChUBJcuplAbbDj0GpyRN.Gjjx1
F42cKjeemouien5zroP4uprsQ982.4GB8l91zsOxORIweLizH4WnINe5a06s
FBTm2P6ejWc1mzywBONYUVVzkNJI8HMsxQwMRWmkC.3uYjNpgsiLf5zX6sPB
.ag0Iez8AM6BoD6FhrcCYpsRnmjwLu8SDjY13tah.1VhH3reh.PhHP1OQ.JQ
D72MQvEKQDv6mHPtmrXpIBNRDAv9IBtRDA39IBxnlPagHnTfIvsKvDjRdWAm
y6PjfL.QclzQnmiUksIx+XJRIxu+LdGRDjqEZyDPdRJaajek7eXrWFikeGfb
4WjuEan7CuECVY1ObeVmlUFvMQGIJxI7VEcDYS7eyG7nhtff1.4GAgV6mDS1
BIlfq+q2wtHwaQDzHOxNhwaQLyUYY88RhcUJNDxL7f9tBRpzM7f90I4kgGUy
wHb961ww3pjEO45qQggNBxH40ZSyH0nip0s9GsMZiiRZyLyF3FNxzFT88tXz
Q0ZSyrnMTaTZt8XNKUt6LsxO4h1rMRrRtHRPyv36I3OgDMRLr+Lk1iZv+5UJ
Di+M2Z9fym+fll0HO0Jh4ofelTG.+y0GyhqOtNwEZlR+f0dI0ItPyfzv2Y4z
v1cvy7Kml79T0eYYRiKXsAeTBkkccUdXpbeEyNGTCZU4qou+MdE9+qypUK.
-----------end_max5_patcher-----------
</code></pre>
It's hard to give an exact answer without knowing what your USB device outputs, however in your patch whatever exits the [hi] object goes into the [live.text] button, which is set to Button mode, always converting it to a bang.
In the patch below I set the [live.text] button to Toggle mode. I also took the liberty of cleaning some other things up.
The next thing though is that you will need to find out what part of the output of the hi object is the information you are looking for. You can do that with a [print] object. Then you can select that number with an [unpack] and select the 1's and use that to trigger [random] (see the patch below).
----------begin_max5_patcher----------
1559.3oc6Z0ziiZCF9bxuBDmmF4O3ypdpWpZu11SqVE4P7Lw6BXpwjYFsZ+u
WaCjPBDvIgY6glLRCAaiseedd+zjusbg6F9azRWme14SNKV7skKVXZR2vhl6
W3lQdKIkTZFlaBOKilKceptOI8Moo8ew4YV9VG4NpSdU1FpvgkatKkUJUegH
cJekIS1QKc1PkuRo4N.Gh5QfsyUgfVplZhjwyWmxxoI7pbyriZFgZlY4oToY
q.aZjs0rA3a9xOAAtGGIuR1NTP6JPTa.V9KqEzDYsTiBvq.O4.AlKXXj9BBr
B37Y8y78kK0+6IKQmb5qp8QOvoPvNBYSIDwWuLfTadef5CDCgX.BFeThPFAB
MuBTUdAI4qJBT8msxUzvxEto05ljuWPqEJWCjcxEmOeYL.FFrJV+IDDFiCQd
f.EFfhWgMshiQ.LJ.hdxIL7tPjKa.jriyKo055M1.6nBps3S3Mq6hA8kRTTv
GglbIM8nA6IRDpuD4MrDgtDiugj+hlqGknQ.+AH5HCoh89HT1kNrAcQ0U4CZ
V3HCenT57a2EVx8ngQJ3.Ka21GzlYbvynUfqAJX7GCbAsDt7CuQ3B9CFt.Gz
qtC3pR41npciumHxIYz9cvjzr5w+azbpfk33372+4u537G72KkLkSWGacn.O
DIofHTKljJVSyIaRocefqya7jlmP.nu4oxAkVcqg16xzkj8zsqIRofsoRRO9
sxFjrAJ0HVZEk+bayssepvUk0rcA5MJ7vN8jgkxyeYPv+jQkoHuN3zI8UtiK
jSOEsvGptKi9R6kqT4IiVVRdg1yXqqpyTtig9ia1ziyG21P48v+7jNB75GIB
+g3kYGyVy.7UFERmv5zp4CktwPReWuaymz+Elb0qp7s4u5TjRdWuk2xJKlNS
Z73dlQvUQfy3TuXi0afwGnW703lFAFG6s1QskYFX7VG3aT3fH7co2kx1SWY.
7AbY2qyKFoa.0j3n9pId0Aj8uFzEFYi+cofjWxZQXz7vG2XVZCYfLfj+QETP
MZndmqthrHzv4j7MFdXzoYFCQLRF6.6Kw9RJxJ6HC0EFEo9uuen1qFDbLAN7
E0cGpx.z+ANFPgAyPQBOqzQTZTSY2GVmwiIkQePu7ddlKxHlAGXaXL+wr1Ay
mcsARsAN8vmKbymVqxo0VdlCDXIP6aRsLHnGPOklH16GasDHsmtS2o2.poi+
2F32hhs5ESGqgMym.e+.eHHFqMLLG9ENBzA+R47htxs9dAsP4f6rhHFOVU30
q7hmfA1JHuJ4lkv8RjhBmVqryDr2ZKdYKKQOQDw6GYK0iUTIWqU9pDzoNzkl
ZBCF.A8gpv851PHOEV6E34oc6zMmosDI47nXIorhCGBa2vXKbIaJ4opHepMx
Nin964RAe8e8J6EhHqDsJiu+PbEkaEVJ8PfmoG5WUoPVWFAeOipaoy.ZnuJP
jNKe+Pbm9NSqvHD7bohlVWpXJ5g.xcjktLV2hKpCjySaTWOhUlNDMyV+dR3o
Jmn7ssbMQ7xlSmzpb1+T0z8oOqxXkJJNzSaGMgeasDmfJXF7UeKUUX9nTwzC
0JpHvSqc4G8fJFkJf1SEvakJhBLTQ7CpXPpfPDE3oogKMLqn.jef18K3AEbQ
J.YGEbyNj7hMT.7AEbQJ.ZGEbyNhv.sin.zCJXPJnM8GKngwFpcwDPFqA7Cp
XzjVcv1m0pyMGcvGqq5Iv6AYLZtRX6yU5lohvProNo+eQEMMdxY4YlBW8Auc
1O5FSgl51Osn+RdkHoc607xLb5TLIsTxxOTY7mN7CHoyX3hsTgol1AOmAaW3
H0jBmXgMmHsykNQi4TDiFVDg20B6YwBi8lAI7.NM5RMGqDxh0Qe1L28BoOP2
I0OPyA1YgDglKAZRnaNT28sQWXNDIrUJ39yjI7jNKN0MUFaaAW4TswuHLdnW
bVP+WeTj+pPuabb0+9WfPvJu3A55d0Tis.EvygIQnMpp52E68uT1nr1WlpC6
QJJ1SEkMC1rFtYjuvMttidxbKKu9VyAv5Jn6YsiutEhHYGSRSZOnV22BpO.e
WcbbQdEqINfR5VpOYURYoNclxBRsfXNX8kee4+Jwi4ZG
-----------end_max5_patcher-----------
I call gtk_window_is_active(wnd) and always receive 0, even when I know for sure that wnd is active and receiving keyboard input. What is the cause and where is the remedy for this?
In fact, I run gtk_window_list_toplevels() and iterate over the list - and gtk_window_is_active() returns 0 for each of them!
When you create a GtkWindow it is still in the 'unrealized' state. You have to call show() on it and let the main loop run, then the window gets realized. So if you call gtk_window_is_active after creating the windows, but before the main loop has chances to run, you will get false.
Thanks to Emmanuele Bassi, Gnome Foundation staff, I figured it out: the problem is that my focus-in-event handler returned 1 (TRUE), and thus prevented the default GTK behaviour. It turned out (something not obvious) that keeping track of the active window is part of that default behavior that i unknowingly overrode.
So, I changed focus-in-event handler of my windows to return FALSE (0), and ever since gtk_window_is_active() works like a clock.
I came to realize an unhelpful (to my task) detail: gtk_window_is_active() only works AFTER all focus-in-event handlers have completed working. Well, I have a mouse click handler that activates some other window, and then needs to check if a certain window is active (these things belong to different objects and different modules, yet are executed within one click hadler invocation). In my case gtk_window_is_active() is useless: it returs FALSE for the active window until after my click handler has finished and the focus-in-handlers (mine and the default) have finished, too.
In my Text Editor application, I save the users font format selection as a preference.
Signals and slots are first set up in the constructor, and then the preferences are read as in the code below:
Constructor:
boldAction->setCheckable(true);
italicAction->setCheckable(true);
underlineAction->setCheckable(true);
fontSizeSelector->setCheckable(false);
connect(boldAction,SIGNAL(changed()),this,SLOT(bold()));
connect(italicAction,SIGNAL(triggered()),this,SLOT(italic()));
connect(underlineAction,SIGNAL(triggered()),this,SLOT(underline()));
ReadUserPreferences():
void TextEditor::readUserPreferences()
{
QSettings userPreferences(QSettings::NativeFormat,QSettings::UserScope,ORGANIZATION_TITLE,APPLICATION_TITLE);
this->boldAction->setChecked( userPreferences.value("appearance/bold").toBool() );
this->italicAction->setChecked( userPreferences.value("appearance/italic").toBool() );
this->underlineAction->setChecked( userPreferences.value("appearance/underline").toBool());
//other code.
}
Now, in the readPreferences function, when boldAction->setChecked(true);, shouldn't the text become bold because the signal and slot mechanism has already been defined? If so, then why isn't it working on my application? The bold function itself works perfectly fine.
Is there a better way of doing this than what I'm doing? Thanks for your help
There appear to be two things wrong here.
Firstly, you are connecting to the wrong signals. The changed signal does not pass a value indicating the action's checked state, and triggered is not emitted at all when setChecked is called. You need to connect to the toggled signal.
Secondly, the signal will only be emitted if the checked state has changed. So if the action is already checked and the user preference evaluates to true, nothing will happen. You probably need to take steps to ensure the appropriate default state is set before connecting the signals.
I am programming an FPS (First Person Shooter) game using "Gtkmm" as a window manager and I would like to do the "mouse-look". Therefore, I have to "grab" the mouse pointer to redirect all the mouse motion events to my application window.
There seems to be three overloaded functions to do that job and I have chosen the simplest one for the beginning:
Gdk::GrabStatus Gdk::Window::pointer_grab(bool owner_events, Gdk::EventMask event_mask, guint32 timestamp)
I have tried to put this function to my application but I have had "bad results" so far - it doesn't do what I want it to, it behaves "differently" on "Windows" than on "Linux", etc...
So I will write down what I have done so far, but first, what is my target: "I want to have my application in a window and want to be able to do the mouse-look with a mouse even when I leave the window with the mouse pointer".
So let's get to the function parameters:
-->bool owner_events: when I set it to "true", I got events only when I was inside the window, but (worse) when I set it to "false", I didn't get any events - so I set it to true (the better option :-) )
-->Gdk::EventMask event_mask: there should be those events which I want to catch. For now, I am interested only in mouse motion events, so I put there only "Gdk::POINTER_MOTION_MASK"
-->guint32 timestamp: this I also don't understand but when I put there pure "0", the grab status was OK, thus "GRAB_SUCCESS" (when I tried to set it to 1, 2 or whatever other number, it returned "GRAB_INVALID_TIME" as a grab status) - so I set it to "0"
And now when I run it on Linux, it although grabs the pointer and when I click somewhere outside the window, it doesn't react (thus my window stays always at the top, which is what "I want"), but the problem is that, that the application doesn't catch any events or catches it only when I am inside the window (when I set owner_events to true).
And on Windows it is yet worse: when I click somewhere outside the window, it switches me to the area where I clicked - so this is the same as "without grabbing".
Could someone tell me, what I am doing wrong, or give me a little example on using grabbing in Gtkmm?
For the event_mask, you should include Gdk::ENTER_NOTIFY_MASK and Gdk::BUTTON_RELEASE_MASK so you can ungrab the point when it either reenters the window or when the button is released.
For timestamp, either pass the GdkEvent...::time member, or Gdk::CURRENT_TIME.
I am developing applcation with UISearchBar & TableView. On UISearchBar's text enter event I am reading char. & for entered text I am geeting results from database. But problem is that it is kind of blocking call. so I have wait till result gets back but again I pressess next char. I have to query from database. For each chars enter, I have query with entire text enterd from database. I want to implement AutoCompeltion like google search bar. As In google search bar, to get list for entred chars user has to wait.
Iwant that to be implemented in my applcation. I am using iPhoneSDK 3.0.
Same thing is running while I am pressing BackSpace. but the problem is that on iPhone Simulatior it application crashes if I press BackSpace continuously.
Can anybody give me hint ???
You could always implement your text lookup on a separate thread -- it might not offer suggestions as often, but it at least wouldn't block.
If you do this, make sure to "remember" the text the lookup is based on -- then, if the text in the UISearchBar no longer matches it, throw out the results you had -- the will no longer apply.
Example:
The user has typed "bri". Tour lookup determines that possible suggestions are "bridle", "bridge", "bride" and "brigand". If by the time your lookup returns the user has added a 'd', you don't want to suggest "brigand" any more. You don't necessarily have to throw out the whole list, but you want to at least remove the items that no longer work.