Re: [RP] adding some basic mouse support to switch frame
Jeremie Courreges-Anglas writes: > Some points: > - I have heard concerns from users that mouse support didn't match the > spirit of ratpoison. I do not think we need to make arbitrary > restrictions based on this reasoning. All I would demand is that the > default behavior isn't changed. > - mouse support would allow me to remove sloppy.c from the ratpoison > distribution, which is a good thing per se. > - people have proposed implementations before. May I suggest you take > a look at what Jeff Abrahamson implemented in > https://github.com/JeffAbrahamson/ratpoison/commits/master ? > The configuration bits looked right at the time. > > https://github.com/JeffAbrahamson/ratpoison/commit/8d8d325b929252e9d8d4a22b1314b241b06abc8a Well, I did not intended to change the default behaviour (I mentioned it in a previous mail) - and looking at what the commits here looks like, it is basically the same idea I had. Minor difference is that the option name I propose is mousefocuspolicy, and can take two values for now, "none" (default, and no mouse support), and "click" to support selecting frames on mouse click. (which I believe is the other difference from the links, I chose to let the mouse select frames, not windows). I can change the option name or other things. Anyway, if adding basic mouse support is not desired, I won't complain, and I will be happy with the current state of ratpoison! :) Note that I asked on the mailing list before coding something though, and had only a (one) positive feedback, so I thought it was ok. > I'm not sure what exactly you mean by "callback", but I suggest you try > to avoid over-complicated solutions. :) That was not my intention :) I wrote the last patch with exactly this intention in mind. Hum, I am not sure what to do now :) I you are still interested in the feature and that it needs to be rebased/reworked, please send me a line! Cheers, -- ~Julien ___ Ratpoison-devel mailing list Ratpoison-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/ratpoison-devel
Re: [RP] adding some basic mouse support to switch frame
On Thursday 2017-02-02 Jeremie Courreges-Anglas wrote : > Yes, the xrandr changes are a bit intrusive and should be merged back in > the master git branch soon(tm). The idea is to produce a new release > within the next month. I do not know yet if mouse support would be > a good addition for the next release, we already have lots of changes. As long as the changes are backwards compatible I don't think there's anything wrong with many of them. On the contrary it improves the image of the project if it can be seen that it gets lots of extra features (as long as they work correctly of course). It also encourages people to submit patches. > Some points: > - I have heard concerns from users that mouse support didn't match the > spirit of ratpoison. I do not think we need to make arbitrary > restrictions based on this reasoning. All I would demand is that the > default behavior isn't changed. My feelings exactly. > - mouse support would allow me to remove sloppy.c from the ratpoison > distribution, which is a good thing per se. What if some people depend on it ? Perhaps it would be better if it became "deprecated". This would mean that in the next release the man page will warn people of this fact and inform them that the functionality has now become part of ratpoison itself. And then in some late release , sloppy.c can be ratpoisoned ! -- Spiros Bousbouras ___ Ratpoison-devel mailing list Ratpoison-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/ratpoison-devel
Re: [RP] adding some basic mouse support to switch frame
Julien Pagès writes: > Mathieu OTHACEHE writes: > >> You should maybe consider rebasing your work on top on xrandr branch. It >> would make your code cleaner as you would iterate on a screen list instead of >> a static array of screens. Yes, the xrandr changes are a bit intrusive and should be merged back in the master git branch soon(tm). The idea is to produce a new release within the next month. I do not know yet if mouse support would be a good addition for the next release, we already have lots of changes. Some points: - I have heard concerns from users that mouse support didn't match the spirit of ratpoison. I do not think we need to make arbitrary restrictions based on this reasoning. All I would demand is that the default behavior isn't changed. - mouse support would allow me to remove sloppy.c from the ratpoison distribution, which is a good thing per se. - people have proposed implementations before. May I suggest you take a look at what Jeff Abrahamson implemented in https://github.com/JeffAbrahamson/ratpoison/commits/master ? The configuration bits looked right at the time. https://github.com/JeffAbrahamson/ratpoison/commit/8d8d325b929252e9d8d4a22b1314b241b06abc8a >> This way when a user plugs a new screen, the frames on this screen >> could be directly selected without having to restart ratpoison, how nice >> :) > > Hi Mathieu, > > Sure, I can do that :) > > I believe what it would really needs is some sort of callback when new > screens are plugged, to call grab button on the root window of the new > screen in case the mousefocus policy is equal to click (in order to be > notified from clicks on this screen). > > Is it possible? Or should I just iterate over the list like I do now? I'm not sure what exactly you mean by "callback", but I suggest you try to avoid over-complicated solutions. :) Thanks, -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE signature.asc Description: PGP signature ___ Ratpoison-devel mailing list Ratpoison-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/ratpoison-devel
Re: [RP] adding some basic mouse support to switch frame
Mathieu OTHACEHE writes: > You should maybe consider rebasing your work on top on xrandr branch. It > would make your code cleaner as you would iterate on a screen list instead of > a static array of screens. > > This way when a user plugs a new screen, the frames on this screen > could be directly selected without having to restart ratpoison, how nice > :) Hi Mathieu, Sure, I can do that :) I believe what it would really needs is some sort of callback when new screens are plugged, to call grab button on the root window of the new screen in case the mousefocus policy is equal to click (in order to be notified from clicks on this screen). Is it possible? Or should I just iterate over the list like I do now? Thanks, -- ~Julien ___ Ratpoison-devel mailing list Ratpoison-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/ratpoison-devel
Re: [RP] adding some basic mouse support to switch frame
Hi Julien, > So I wrote a patch for the click feature. It seems to work pretty well, > I tried it on a laptop connected to an external screen and it seems OK > to me. Note that the frames are selected (not the windows) which I > believe is better. Nice work ! You should maybe consider rebasing your work on top on xrandr branch. It would make your code cleaner as you would iterate on a screen list instead of a static array of screens. This way when a user plugs a new screen, the frames on this screen could be directly selected without having to restart ratpoison, how nice :) Thanks, Mathieu ___ Ratpoison-devel mailing list Ratpoison-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/ratpoison-devel
Re: [RP] adding some basic mouse support to switch frame
Spiros Bousbouras writes:
> On Wednesday 2017-01-25 Julien Pagès wrote :
>> I would like to add some basic support to be able to switch frame using
>> the mouse. It should be configurable, I do not intend to change the
>> default behavior. I was thinking about a new variable, let's say
>> 'mousefocuspolicy', which could take some values:
>>
>> - "none": this is the current behavior
>> - "click": allow to select the frame under the mouse when the user click
>> - "move": (maybe this can be done later, I am not sure of that yet) this
>> would select the frame automatically under the mouse, when the user
>> move it
>>
>> It could then be used easily in the configuration file:
>>
>> set mousefocuspolicy click
>
> BLASPHEMY ! HERESY ! ;-)
>
> No , actually this is a good idea ; I would find useful both the "click" and
> "move" functionalities so I say go for it.
Excellent, you got me on the first line :D
So I wrote a patch for the click feature. It seems to work pretty well,
I tried it on a laptop connected to an external screen and it seems OK
to me. Note that the frames are selected (not the windows) which I
believe is better.
I am not sure for the "mouse" policy, but I don't plan to do it right
now - it seems to be a bit more complicated than what I expected :).
Once you are happy with the attached patch (note it is also available on
my github account,
https://github.com/parkouss/ratpoison/commit/15c2a0ab6cfe944d65c3d0831cc7c01219ea1839),
I would be happy to write another patch for the documentation/changelog
(I am not sure what I should change yet, and I am not a native English
speaker, but I would be glad to do my best!).
Cheers,
>From 15c2a0ab6cfe944d65c3d0831cc7c01219ea1839 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Julien=20Pag=C3=A8s?=
Date: Sun, 29 Jan 2017 14:23:47 +0100
Subject: [PATCH] add basic support for the mouse
Basic support for the mouse is provided to be able to activate a frame
when clicking on it.
To activate the behavior, the mousefocuspolicy variable must be set:
set mousefocuspolicy click
Currently mousefocuspolicy only accept two values: none (no mouse
support at all) and click (activate a frame on click).
---
src/actions.c | 62 +++
src/data.h| 3 +++
src/events.c | 20 ++-
src/globals.h | 4
src/main.c| 2 ++
src/screen.c | 2 +-
src/split.c | 21
src/split.h | 1 +
8 files changed, 113 insertions(+), 2 deletions(-)
diff --git a/src/actions.c b/src/actions.c
index ef856cf..7a511ba 100644
--- a/src/actions.c
+++ b/src/actions.c
@@ -162,6 +162,7 @@ static cmdret * set_inputwidth (struct cmdarg **args);
static cmdret * set_waitcursor (struct cmdarg **args);
static cmdret * set_winfmt (struct cmdarg **args);
static cmdret * set_winname (struct cmdarg **args);
+static cmdret * set_mousefocuspolicy (struct cmdarg **args);
static cmdret * set_framefmt (struct cmdarg **args);
static cmdret * set_fgcolor (struct cmdarg **args);
static cmdret * set_bgcolor (struct cmdarg **args);
@@ -373,6 +374,7 @@ init_set_vars (void)
add_set_var ("wingravity", set_wingravity, 1, "", arg_GRAVITY);
add_set_var ("winliststyle", set_winliststyle, 1, "", arg_STRING);
add_set_var ("winname", set_winname, 1, "", arg_STRING);
+ add_set_var ("mousefocuspolicy", set_mousefocuspolicy, 1, "", arg_STRING);
}
/* i_nrequired is the number required when called
@@ -1258,6 +1260,30 @@ ungrab_rat (void)
XUngrabPointer (dpy, CurrentTime);
}
+static void
+grab_button (void)
+{
+ int j;
+ for (j=0; jroot,
+ True, ButtonPressMask,
+ GrabModeSync, GrabModeAsync, None, None);
+}
+}
+
+static void
+ungrab_button (void)
+{
+ int j;
+ for (j=0; jroot);
+}
+}
+
/* Unmanage window */
cmdret *
cmd_unmanage (int interactive, struct cmdarg **args)
@@ -4304,6 +4330,42 @@ set_winname (struct cmdarg **args)
}
static cmdret *
+set_mousefocuspolicy(struct cmdarg **args)
+{
+ char *policy;
+
+ if (args[0] == NULL)
+switch (defaults.mouse_focus_policy)
+ {
+ case MOUSE_FOCUS_POLICY_NONE:
+return cmdret_new (RET_SUCCESS, "none");
+ case MOUSE_FOCUS_POLICY_CLICK:
+return cmdret_new (RET_SUCCESS, "click");
+ default:
+PRINT_DEBUG (("Unknown mouse_focus_policy\n"));
+return cmdret_new (RET_FAILURE, "unknown");
+ }
+
+ policy = ARG_STRING(0);
+
+ if (!strncmp (policy, "none", sizeof ("none")))
+{
+ defaults.mouse_focus_policy = MOUSE_FOCUS_POLICY_NONE;
+ ungrab_button();
+}
+ else if (!strncmp (policy, "click", sizeof ("click")))
+{
+ defaults.mouse_focus_policy = MOUSE_FOCUS_POLICY_CLICK;
+ grab_button();
+}
+ else
+return cmdret_new (RET_FAILURE,
+ "set mousefocuspolicy: invalid argument `%s'", policy);
+
+ return cmdret_new (RET_SUCCESS, NULL);
+}
+
+static cmdret *
set_framefmt (struct cmdarg **args)
{
Re: [RP] adding some basic mouse support to switch frame
On Wednesday 2017-01-25 Julien Pagès wrote : > I would like to add some basic support to be able to switch frame using > the mouse. It should be configurable, I do not intend to change the > default behavior. I was thinking about a new variable, let's say > 'mousefocuspolicy', which could take some values: > > - "none": this is the current behavior > - "click": allow to select the frame under the mouse when the user click > - "move": (maybe this can be done later, I am not sure of that yet) this > would select the frame automatically under the mouse, when the user > move it > > It could then be used easily in the configuration file: > > set mousefocuspolicy click BLASPHEMY ! HERESY ! ;-) No , actually this is a good idea ; I would find useful both the "click" and "move" functionalities so I say go for it. -- Spiros Bousbouras ___ Ratpoison-devel mailing list Ratpoison-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/ratpoison-devel
[RP] adding some basic mouse support to switch frame
Hello, I am a new user of ratpoison, and so far I love it! So first thing, thanks a lot for this great software! I would like to add some basic support to be able to switch frame using the mouse. It should be configurable, I do not intend to change the default behavior. I was thinking about a new variable, let's say 'mousefocuspolicy', which could take some values: - "none": this is the current behavior - "click": allow to select the frame under the mouse when the user click - "move": (maybe this can be done later, I am not sure of that yet) this would select the frame automatically under the mouse, when the user move it It could then be used easily in the configuration file: set mousefocuspolicy click Note that I am aware of the sloppy.c file, but I find it too intrusive, and it does not exactly fix my need I believe. I started to look at the code, and those changes will require the ratpoison windows to listen to some new x events (using ButtonMotionMask, and I think EnterWindowMask or maybe PointerMotionMask for the "move" value). Anyway, before going further, I would like to hear what you think of it. Does it sounds interesting? I would be happy to implement it (without the "move" value for now) if that sounds good to you. Cheers, -- ~Julien ___ Ratpoison-devel mailing list Ratpoison-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/ratpoison-devel
