Re: [dev] mapping keyboard buttons to move the mouse?
Hiho, I was wondering if it was possible to map keyboard buttons to move the mouse cursor/ send mouse button events. For example, I was thinning of having alt gr and the arrow buttons move the mouse cursor, and alt gr + z, x and c send left, middle, right mouse button events. have you tried this one yet: http://www.tuxfiles.org/linuxhelp/movecursor.html altho this doesn't offer random keybindings (i wouldn't be surprised if you can tune it using xmodmap somehow, though) Regards, Mate
Re: [dev] [9base] @strip and ${MAKE} handling
2009/8/27 KIMURA Masaru hiyuh.r...@gmail.com: Hi, http://dev.gentoo.gr.jp/~hiyuh/cgi-bin/hgweb.cgi/file/tip/sys-apps/9base-hg/9base-hg-3_p42.ebuild As src_prepare() does so, I think 9base make infra is not bit package friendly. Could you mind to fix? And I also found wrong MANPREFIX handling in some uninstall rules which are not used in my ebuild though. Ok, will look at that tonight. Please change the hg URL to: http://hg.suckless.org/9base Kind regards, Anselm
Re: [dev] mapping keyboard buttons to move the mouse?
Hiho, I was wondering if it was possible to map keyboard buttons to move the mouse cursor/ send mouse button events. For example, I was thinning of having alt gr and the arrow buttons move the mouse cursor, and alt gr + z, x and c send left, middle, right mouse button events. have you tried this one yet: http://www.tuxfiles.org/linuxhelp/movecursor.html altho this doesn't offer random keybindings (i wouldn't be surprised if you can tune it using xmodmap somehow, though) Regards, Mate Thanks, I did already know about this though, and unfortunately it doesn't help (assuming key mapping cannot be changed). The tuchpad on this laptop is extremely twitchy, which I have bean working around for about a year with DWM, Vimperator, Vim, Xbindkeys etc (I prefer keyboard driven apps anyway). However there are a few things, mostly Flash video players, which cannot be contorted without the mouse. As laptops don't have number pads, the keyboard mouse features built into X are unusable.
Re: [dev] mapping keyboard buttons to move the mouse?
I don't know if this exists already but we could divide the screen into sections. Some ideas: 1) The screen is a section that you can split. You either go to the left/right or up/down on the actual section to split it. The cursor is then warped at the center of the created section, and so on. 2) Cursor speed is proportional to the section size. If it's integrated with the wm, section can be window. I'll try to implement something. On Thu, Aug 27, 2009 at 2:56 PM, hessi...@hessiess.com wrote: Sure, I have attached a tar of what I currently have, it just moves the cursor right 1 pixel at a time, It is so fast that it locks the cursor to the right side of the screen, so it is limited to 4000 iterations. How do you create a event receiver with xlib to catch mod5(alt gr) + some key regardless of the focused window? Post the code --Original Message-- From: hessi...@hessiess.com To: dev mail list ReplyTo: dev mail list Subject: Re: [dev] mapping keyboard buttons to move the mouse? Sent: Aug 26, 2009 21:52 On Thu, Aug 27, 2009 at 1:46 AM, hessi...@hessiess.com wrote: Thanks for the application suggestions. how can I get the current cursor location from the CLI? See attached file. Thanks for that, though I cannot get the cursor to move smoothly, using cli commands, it moves very slowly and jerkily. I guess its becouse a lot of processes are being spawned/killed in a short time period. Il try to reimplement it with C. Sent from my BlackBerry
Re: [dev] [9base] @strip and ${MAKE} handling
Please recheck hg tip if you are happy with it. If there are no complaints the tip will be 9base-4 tonight. Kind regards, Anselm 2009/8/27 Anselm R Garbe garb...@gmail.com: 2009/8/27 KIMURA Masaru hiyuh.r...@gmail.com: Hi, http://dev.gentoo.gr.jp/~hiyuh/cgi-bin/hgweb.cgi/file/tip/sys-apps/9base-hg/9base-hg-3_p42.ebuild As src_prepare() does so, I think 9base make infra is not bit package friendly. Could you mind to fix? And I also found wrong MANPREFIX handling in some uninstall rules which are not used in my ebuild though. Ok, will look at that tonight. Please change the hg URL to: http://hg.suckless.org/9base Kind regards, Anselm
[dev] Focus after closing a window
I'm seeing what I think is non-intuitive behavior of the focus after closing a window in tiled mode. Here's the situation: I use rox as my file-system browser. Let's assume rox is by itself in tag 6 and dwm is in tile mode. Now suppose I open a .pdf file and then another by clicking them in rox, having specified xpdf (in rox) as the program to deal with .pdf extensions. Now I've got two xpdfs windows in addition to the rox window, all with tag 6. The second xpdf is in the master area and has the focus. The first xpdf and rox are in the stacking area. Now I do mod1-shift-c, which closes the second xpdf, the one in the master area. This causes the first xpdf to move to the master area, with rox now the only window in the stacking area. But the rox window gets the focus at this point. If I fail to notice that and do another mod1-shift-c with the intention of closing the first xpdf, I will close the rox window by mistake. It seems to me that, before the first close, the focus was in the master area and after the close, it should remain there. Having it move at all is a surprise and having it move away from the master area, which contains the window you just popped off the stack, is a double surprise. I am running 5.6.1 without xinerama (which still does not work correctly on my system; I'll detail in another message) on OpenBSD 4.5. Comments? /Don Allen
Re: [dev] Focus after closing a window
Hi Donald, 2009/8/27 Donald Allen donaldcal...@gmail.com: I'm seeing what I think is non-intuitive behavior of the focus after closing a window in tiled mode. Here's the situation: I use rox as my file-system browser. Let's assume rox is by itself in tag 6 and dwm is in tile mode. Now suppose I open a .pdf file and then another by clicking them in rox, having specified xpdf (in rox) as the program to deal with .pdf extensions. Now I've got two xpdfs windows in addition to the rox window, all with tag 6. The second xpdf is in the master area and has the focus. The first xpdf and rox are in the stacking area. Now I do mod1-shift-c, which closes the second xpdf, the one in the master area. This causes the first xpdf to move to the master area, with rox now the only window in the stacking area. But the rox window gets the focus at this point. If I fail to notice that and do another mod1-shift-c with the intention of closing the first xpdf, I will close the rox window by mistake. dwm remebers the focus history in a focus stack, since rox was focused before your second pdf window appeared, it will revert to the window that had the focus before the second xpdf appeared, which is rox in your case. It seems to me that, before the first close, the focus was in the master area and after the close, it should remain there. Having it move at all is a surprise and having it move away from the master area, which contains the window you just popped off the stack, is a double surprise. Well it might be less a surprise with the above constraint in mind. I am running 5.6.1 without xinerama (which still does not work correctly on my system; I'll detail in another message) on OpenBSD 4.5. Let us know the issues, and also check if the issues also happen with other WMs that support xinerama. Kind regards, Anselm
Re: [dev] freebsd port of wmii
Michal dixit (2009-08-25, 22:30): Hello, Does anybody has a working port of latest snapshot and is willing to share it? Michal -- UNIX is user-friendly, it just chooses its friends. -Andreas Bogk Hmm. dwm works nice on FreeBSD for me, i think that wmii will work too. Regards. pgpfpoloqTe0r.pgp Description: PGP signature
[dev] dwm is awesome!
I just recently learned of dwm and the rest of suckless, and I wanted to send out an email to express my appreciation. The suckless philosophy really resonates with my own appreciation for powerful, minimalist, simple software. Its great to find a community of others who not only feel the same way, but have organized a development effort around it! I'm loving dwm. Andy
Re: [dev] dwm is awesome!
Thanks! I've never participated in an open source community before but I am thinking suckless could be a good place to start. Andy 2009/8/27 Slawomir Gonet gon...@gmail.com: Welcome on suckless!
Re: [dev] Focus after closing a window
On Thu, Aug 27, 2009 at 9:27 AM, Anselm R Garbe garb...@gmail.com wrote: Hi Donald, 2009/8/27 Donald Allen donaldcal...@gmail.com: I'm seeing what I think is non-intuitive behavior of the focus after closing a window in tiled mode. Here's the situation: I use rox as my file-system browser. Let's assume rox is by itself in tag 6 and dwm is in tile mode. Now suppose I open a .pdf file and then another by clicking them in rox, having specified xpdf (in rox) as the program to deal with .pdf extensions. Now I've got two xpdfs windows in addition to the rox window, all with tag 6. The second xpdf is in the master area and has the focus. The first xpdf and rox are in the stacking area. Now I do mod1-shift-c, which closes the second xpdf, the one in the master area. This causes the first xpdf to move to the master area, with rox now the only window in the stacking area. But the rox window gets the focus at this point. If I fail to notice that and do another mod1-shift-c with the intention of closing the first xpdf, I will close the rox window by mistake. dwm remebers the focus history in a focus stack, since rox was focused before your second pdf window appeared, it will revert to the window that had the focus before the second xpdf appeared, which is rox in your case. It seems to me that, before the first close, the focus was in the master area and after the close, it should remain there. Having it move at all is a surprise and having it move away from the master area, which contains the window you just popped off the stack, is a double surprise. Well it might be less a surprise with the above constraint in mind. Perhaps less of a surprise now that I know what you are doing, but still unintuitive, in my opinion. I would expect the relative position in the window stack to remain constant as windows get closed regardless of the focus path I traversed to get there. So, if the focus is in the window in the master area and I close that window, I would expect the window that gets popped from the stack into the master area to receive the focus. There's something else going on here that strikes me as odd: When I begin, I have a rox window alone in tag 6. Rox is displaying a directory that contains multiple .pdf files. I click the first one I want to display and an xpdf window appears in the master area. It gets the focus, but the cursor does not move. It may be in the focused window, it may not be, depending on where the file icon was in the rox window. Then, I move the cursor to the rox window, which is now in the stack area. I click another pdf file and a new xpdf window appears in the master area and has the focus, but the cursor is still in the rox window, so the focus is in one place and the cursor is in another. I am running 5.6.1 without xinerama (which still does not work correctly on my system; I'll detail in another message) on OpenBSD 4.5. Let us know the issues, I will. and also check if the issues also happen with other WMs that support xinerama. I doubt that I will have time to do that kind of experimenting, but if I can, I will. /Don Kind regards, Anselm
Re: [dev] Focus after closing a window
On Thu, Aug 27, 2009 at 11:14 AM, Donald Allen donaldcal...@gmail.comwrote: On Thu, Aug 27, 2009 at 9:27 AM, Anselm R Garbe garb...@gmail.com wrote: Hi Donald, 2009/8/27 Donald Allen donaldcal...@gmail.com: I'm seeing what I think is non-intuitive behavior of the focus after closing a window in tiled mode. Here's the situation: I use rox as my file-system browser. Let's assume rox is by itself in tag 6 and dwm is in tile mode. Now suppose I open a .pdf file and then another by clicking them in rox, having specified xpdf (in rox) as the program to deal with .pdf extensions. Now I've got two xpdfs windows in addition to the rox window, all with tag 6. The second xpdf is in the master area and has the focus. The first xpdf and rox are in the stacking area. Now I do mod1-shift-c, which closes the second xpdf, the one in the master area. This causes the first xpdf to move to the master area, with rox now the only window in the stacking area. But the rox window gets the focus at this point. If I fail to notice that and do another mod1-shift-c with the intention of closing the first xpdf, I will close the rox window by mistake. dwm remebers the focus history in a focus stack, since rox was focused before your second pdf window appeared, it will revert to the window that had the focus before the second xpdf appeared, which is rox in your case. It seems to me that, before the first close, the focus was in the master area and after the close, it should remain there. Having it move at all is a surprise and having it move away from the master area, which contains the window you just popped off the stack, is a double surprise. Well it might be less a surprise with the above constraint in mind. Perhaps less of a surprise now that I know what you are doing, but still unintuitive, in my opinion. I would expect the relative position in the window stack Oops -- in the above I should have said relative position in the window stack *of the focus*. /Don
Re: [dev] freebsd port of wmii
Kris, it would be so much easier if you'd put a 3.7 tag somewhere, upload the tarball and let the port maintainers do their thing. Can we please have a 3.7 release?
Re: [dev] freebsd port of wmii
On Thu, Aug 27, 2009 at 07:43:30PM +0300, Vitaly Magerya wrote: Kris, it would be so much easier if you'd put a 3.7 tag somewhere, upload the tarball and let the port maintainers do their thing. Can we please have a 3.7 release? Alright, the 3.9a1 tarball is available at http://wmii.suckless.org/. I'll release 3.9 as soon as I have sufficient feedback. -- Kris Maglione Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defence against complexity. --David Gelernter
[dev] 9base-4
Hi there, I just released 9base-4, which can be downloaded from: http://dl.suckless.org/tools/9base-4.tar.gz It includes some new commands such as troff, mk, du, hoc, and some minor code cleanup. Kind regards, Anselm
Re: [dev] mapping keyboard buttons to move the mouse?
On Aug 27, 2009, at 5:56 AM, hessi...@hessiess.com wrote:
Sure, I have attached a tar of what I currently have, it just moves
the
cursor right 1 pixel at a time, It is so fast that it locks the
cursor to
the right side of the screen, so it is limited to 4000 iterations.
How do you create a event receiver with xlib to catch mod5(alt gr) +
some
key regardless of the focused window?
Check the source code to dwm for this. In fact, if you're already
using dwm, it might be easiest to simply bolt on this functionality (/
me puts on flame suit).
diff -r 63e19dad219c config.def.h
--- a/config.def.h Tue Aug 18 15:59:38 2009 +0100
+++ b/config.def.h Thu Aug 27 11:30:57 2009 -0700
@@ -48,6 +48,13 @@
static const char *dmenucmd[] = { dmenu_run, -fn, font, -nb,
normbgcolor, -nf, normfgcolor, -sb, selbgcolor, -sf, selfgcolor,
NULL };
static const char *termcmd[] = { uxterm, NULL };
+static void
+movecursor(const Arg *arg)
+{
+const int delta = 5;
+XWarpPointer(dpy, None, None, 0, 0, 0, 0, (arg-i % 2) * delta,
(arg-i / 2) * delta);
+}
+
static Key keys[] = {
/* modifier keyfunction
argument */
{ MODKEY, XK_p, spawn,
{.v = dmenucmd } },
@@ -57,6 +64,10 @@
{ MODKEY, XK_k, focusstack,
{.i = -1 } },
{ MODKEY, XK_h, setmfact,
{.f = -0.05} },
{ MODKEY, XK_l, setmfact,
{.f = +0.05} },
+ { MODKEY, XK_Left, movecursor, {.i
= -1} },
+ { MODKEY, XK_Right, movecursor, {.i
= +1} },
+ { MODKEY, XK_Up, movecursor, {.i
= -2} },
+ { MODKEY, XK_Down, movecursor, {.i
= +2} },
{ MODKEY, XK_Return, zoom,
{0} },
{ MODKEY, XK_Tab,view,
{0} },
{ MODKEY|ShiftMask, XK_c, killclient,
{0} },
Re: [dev] mapping keyboard buttons to move the mouse?
http://www.semicomplete.com/projects/keynav/ On Aug 27, 2009, at 5:39 AM, Aurélien Aptel wrote: I don't know if this exists already but we could divide the screen into sections. Some ideas: 1) The screen is a section that you can split. You either go to the left/right or up/down on the actual section to split it. The cursor is then warped at the center of the created section, and so on. 2) Cursor speed is proportional to the section size. If it's integrated with the wm, section can be window. I'll try to implement something. On Thu, Aug 27, 2009 at 2:56 PM, hessi...@hessiess.com wrote: Sure, I have attached a tar of what I currently have, it just moves the cursor right 1 pixel at a time, It is so fast that it locks the cursor to the right side of the screen, so it is limited to 4000 iterations. How do you create a event receiver with xlib to catch mod5(alt gr) + some key regardless of the focused window? Post the code --Original Message-- From: hessi...@hessiess.com To: dev mail list ReplyTo: dev mail list Subject: Re: [dev] mapping keyboard buttons to move the mouse? Sent: Aug 26, 2009 21:52 On Thu, Aug 27, 2009 at 1:46 AM, hessi...@hessiess.com wrote: Thanks for the application suggestions. how can I get the current cursor location from the CLI? See attached file. Thanks for that, though I cannot get the cursor to move smoothly, using cli commands, it moves very slowly and jerkily. I guess its becouse a lot of processes are being spawned/killed in a short time period. Il try to reimplement it with C. Sent from my BlackBerry
Re: [dev] mapping keyboard buttons to move the mouse?
On Thu, Aug 27, 2009 at 8:40 PM, Donald Chaidonald.c...@gmail.com wrote: http://www.semicomplete.com/projects/keynav/ That's exactly what I was thinking :)
Re: [dev] mapping keyboard buttons to move the mouse?
http://www.semicomplete.com/projects/keynav/ On Aug 27, 2009, at 5:39 AM, Aurélien Aptel wrote: I don't know if this exists already but we could divide the screen into sections. Some ideas: 1) The screen is a section that you can split. You either go to the left/right or up/down on the actual section to split it. The cursor is then warped at the center of the created section, and so on. 2) Cursor speed is proportional to the section size. If it's integrated with the wm, section can be window. I'll try to implement something. That would be nice if it were integrated into DWM and treated tiles as subdivisions.
Re: [dev] 9base-4
Awesome, this should be enough to run werc. Thanks! uriel On Thu, Aug 27, 2009 at 8:07 PM, Anselm R Garbegarb...@gmail.com wrote: Hi there, I just released 9base-4, which can be downloaded from: http://dl.suckless.org/tools/9base-4.tar.gz It includes some new commands such as troff, mk, du, hoc, and some minor code cleanup. Kind regards, Anselm
Re: [dev] dwm is awesome!
On Thu, Aug 27, 2009 at 5:27 PM, Anders Anderssonpipat...@gmail.com wrote: Heh, I just started using dwm myself, and I love it! I wanted to try a tiling window manager, and did some basic research and dwm seemed to suit me best. I wish I did this switch years ago. I might want to try wmii too, mainly because I want the possibility of a grid layout (2x2 for example) rather than master+stack. I thought I really wanted the grid feature, and was using the very nice gapless grid patch for a while, until one day I decided to try doing without it and found I didn't miss it at all. In any case, you don't need to write that code yourself - it's in suckless wiki.
Re: [dev] freebsd port of wmii
Kris Maglione wrote: I have a makefile for the hg build somewhere. I stopped distributing it because wmii-hg was in the ports tree. I'll see if I can find it later today. If not, I'll write an updated one. As far as I'm concerned the only wmii version currently available in ports tree is historical 3.6. That's the main reason why I would really welcome new release version, I'm sure that somebody would update the port very quickly. At the moment I'm running latest snapshot and it works like a charm but it's installed with my ugly try-until-it-works Makefile and it lacks man pages. Michal -- Complexity is a symptom of confusion, not a cause. -Jeff Hawkins
Re: [dev] wmii - clock issues
On Thu, Aug 27, 2009 at 07:15:35PM -0500, Nathan Neff wrote: THE PROBLEM: for some reason, wmII's clock isn't being updated. load average monitor seems fine, it changes.. but the clock just sits there and shows the time from when I launched wmii. I think it's a problem with having two defmonitor stanzas, or else it's a problem with the implementation of the datetime.now() method on Ubuntu 9.04 You can @defmonitor as many monitors as you like, or at least I can. I have noticed, though, that using import lines from monitors tends to cause me trouble. You might try moving the import line out of the time function. -- Kris Maglione I have always found that plans are useless, but planning is indispensable. --Dwight Eisenhower
Re: [dev] [last] lastfm interface
On Tue, Aug 25, 2009 at 01:58:30PM +0200, Yoshi Rokuko wrote: | Can't get stream: Connection refused | 29863: signal: sys: segmentation violation | % no one else has this problem? I actually switched from Last.FM to Pandora a few months ago, so I suppose things may have changed since the last time I used it. I'll look into it later. -- Kris Maglione It is best to read the weather forecast before praying for rain. --Mark Twain
