Re: [RP] [PATCH] Update expose.pl to Work with 1.4.9

[Jeremie Courreges-Anglas]

On Mon, Nov 13 2017, Fahri Cihan Demirci  wrote:
> Since after xrandr support was added, sdump returns current screen name,
> screen number, x-coordinate, y-coordinate, width, height and a boolean
> flag designating the active screen.
> This patch changes sdump parsing method in the expose.pl script to
> accommodate those changes.

This looks right.  But I wonder if we should really print the screen
name in sdump.  Or maybe we should print the screen name last, and print
a dummy name instead of nothing if we don't have xrandr.  The migration
path looks suboptimal now.

Cc'ing Mathieu since he's done most of the xrandr work.

Thoughts?

> ---
>  contrib/expose.pl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/expose.pl b/contrib/expose.pl
> index 0a7127e..4db326b 100644
> --- a/contrib/expose.pl
> +++ b/contrib/expose.pl
> @@ -41,7 +41,7 @@ my $frames_old = ('fdump'); chomp $frames_old;
>  my @r; # Sub-optimal way of grabbing screen x,y,w,h.
>  
>  #fixed to use sdump
> -($_, $r[0], $r[1], $r[2], $r[3]) = split(/ /, ('sdump'));
> +($_, $_, $r[0], $r[1], $r[2], $r[3], $_) = split(/ /, ('sdump'));
>  
>  my $ret = join(", ", _split(\@xids, \, $n, \@r));

-- 
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] [PATCH 1/3 v2] Limit width of formatted text by characters rather than bytes

[Jeremie Courreges-Anglas]

On Tue, Aug 29 2017, Will Storey <w...@summercat.com> wrote:
> On Mon 2017-08-28 20:50:19 +0200, Jeremie Courreges-Anglas wrote:
>> 
>> Hi Will,
>
> Hi!
>
> Thank you for looking at this.
>
>> First, thanks for your submission.  You're dealing with a known problem.
>> 
>> The direction taken so far in ratpoison was: don't deal with wide
>> characters, only handle UTF-8 in a rather dumb but at least simple way.
>> 
>> Rationale:
>> - the wide characters API has a lot of gotchas.  I won't detail them
>>   here but what to do in case of an invalid sequence often remains an
>>   open question.  Here, I can see that you return a partial length
>>   early.  I'm not sure this is desirable.
>
> I see. I'm not super familiar with the wchar.h API. I was not aware
> ratpoison had functionality for this!
>
> Regarding returning on invalid characters: Another option we could do would
> be to replace them with U+FFFD.
>
>> - UTF-8 is easy and looks like the sanest choice for a multibyte locale.
>>   No offense, but other less commonly used locales are just a pain to
>>   handle.  Think state-dependant encodings.
>
> Well, even with UTF-8 it is not so easy to do everything perfectly! I'm not
> sure how wchar.h deals with there being combining characters in weird spots
> for instance. That might be something to look at if we ever revisited using
> it.
>
>> So while technically speaking the wide characters API looks like the
>> obvious choice, I think its cost is a bit high.  Consistency is good.
>> If we start using the wide chars API somewhere, it should be used in all
>> places where it makes sense.  I'm not sure this is an easy task even in
>> ratpoison. :)
>>
>> Handling only UTF-8 as a multibyte locale, the tentative diff below
>> seems to do the job.  *WARNING*: I have barely tested it with your html
>> testcase.
>> 
>> Feedback / test reports welcome.
>
> Cool! Thanks for writing that. I've tried it out and it works well.

Actually the behavior was rather incorrect.  After my patch,
concat_width was copying up to 'width' bytes, not up to 'width' UTF-8
characters.  This gotcha was caught by your test case.  I find the
latter behavior more useful.

Note that the function only cares about how many characters we concat,
not about their actual width on screen.  I believe this behavior is
reasonable, though.

> I'm in agreement about only worrying about support for UTF-8.
>
> After looking at the UTF8 macros, one thought I have is we could improve
> this to be more conservative about what we accept. For example, only
> consuming two, three, or four bytes when the first byte indicates that is
> appropriate, rather than having no limit. I suppose it depends how far we
> want to go in writing UTF-8 decoding.

So far the direction taken was not to bother validating anything.
Garbage in, garbage out.

> Anyway, I think it is a big improvement as is.
>
> It also still might be good to have a few unit tests. Would you be okay
> with tests in the form of my third patch?

Yep.  I have applied your 3/3 patch, which introduces a testcase, and
made further tweaks.  Namely:
- rename concat_width to something more appropriate
- move it so sbuf.c
- shuffled some code to make it easier to link against it
- move the testcase to its own .c file
- simplify src/Makefile.am accordingly

Feedback welcome.

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] BUG QT Application

[Jeremie Courreges-Anglas]

On Wed, Aug 30 2017, m...@gutierri.me wrote:
> There is a bug in certain applications (or perhaps in a single one) that when 
> it changes from Workspace (via rpws) it disappears but the process remains 
> active.
>  
> Application: Bitcon Wallet (QT application)

Thanks for the report, but you don't give much details.  The ratpoison
version, the X server version, the operating system, the "Bitcoin
Wallet" version and the version of Qt could all matter here.

I heard rumors about Qt applications misbehaving somehow, but I'm not
sure rpws was at fault.  Do you hit issues even when you don't use rpws?

-- 
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] [PATCH] add texinfo documentation for variable onlyborder

[Jeremie Courreges-Anglas]

Pushed, 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] [PATCH 2/3] Move several functions out of main.c into globals.c

[Jeremie Courreges-Anglas]

On Sun, Aug 27 2017, Will Storey  wrote:
> These functions are used in many parts of ratpoison. In order to compile
> a separate program using the ratpoison files, we need them available
> outside of main.c.
>
> I want to create such a program for a set of unit tests.

Pushed (with a few tweaks).  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] [PATCH 1/3 v2] Limit width of formatted text by characters rather than bytes

[Jeremie Courreges-Anglas]

Hi Will,

On Sun, Aug 27 2017, Will Storey  wrote:
> When formatting text for display in the window list, it is possible to
> specify a limit to truncate at. This is useful for example with %t when
> you have a long title in the window.
>
> The prior implementation truncated counting by bytes. This was
> problematic if the limit happened to be in the middle of a multibyte
> character. When that happened, the window list text cut off starting at
> the invalid character.
>
> We now count by characters rather than bytes. This ensures we always
> include a full multibyte character.
>
> It is possible to see the problem with this test case:
>
> set winfmt %n%s%10t
> set winliststyle row
> set winname title
>
> Then create a window such that we truncate in the middle of a multibyte
> character. This is possible with the following HTML document:
>
> 
> 
> testing  1 2 3
>
> Assuming you are using UTF-8 encoding, if your browser's title has only
> this text, then truncating at 10 will truncate on the second of the
> three bytes in the trademark symbol.

First, thanks for your submission.  You're dealing with a known problem.

The direction taken so far in ratpoison was: don't deal with wide
characters, only handle UTF-8 in a rather dumb but at least simple way.

Rationale:
- the wide characters API has a lot of gotchas.  I won't detail them
  here but what to do in case of an invalid sequence often remains an
  open question.  Here, I can see that you return a partial length
  early.  I'm not sure this is desirable.
- UTF-8 is easy and looks like the sanest choice for a multibyte locale.
  No offense, but other less commonly used locales are just a pain to
  handle.  Think state-dependant encodings.

So while technically speaking the wide characters API looks like the
obvious choice, I think its cost is a bit high.  Consistency is good.
If we start using the wide chars API somewhere, it should be used in all
places where it makes sense.  I'm not sure this is an easy task even in
ratpoison. :)

Handling only UTF-8 as a multibyte locale, the tentative diff below
seems to do the job.  *WARNING*: I have barely tested it with your html
testcase.

Feedback / test reports welcome.


diff --git a/src/format.c b/src/format.c
index caf8781..fa8b068 100644
--- a/src/format.c
+++ b/src/format.c
@@ -82,11 +82,18 @@ concat_width (struct sbuf *buf, char *s, int width)
 {
   if (width >= 0)
 {
-  char *s1 = xsprintf ("%%.%ds", width);
-  char *s2 = xsprintf (s1, s);
-  sbuf_concat (buf, s2);
-  free (s1);
-  free (s2);
+  int len = 0;
+
+  while (s[len] != '\0' && len < width)
+{
+  if (RP_IS_UTF8_START (s[len]))
+do
+  len++;
+while (RP_IS_UTF8_CONT (s[len]));
+  else
+len++;
+}
+  sbuf_printf_concat (buf, "%.*s", len, s);
 }
   else
 sbuf_concat (buf, s);


-- 
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] [PATCH] add onlyborder variable

[Jeremie Courreges-Anglas]

On Tue, Aug 22 2017, Vasil Zlatanov  wrote:
> When onlyborder is set to 0 (default 1), borders are not displayed if
> there is only a single frame on a given screen.
>
> This is useful if you use (thick) coloured borders to show which is the
> currently focused window when using splits, but also don't want to have
> borders taking up space unnecessarily when running a fullscreen window.

Looks useful, pushed, thanks.  Could you please prepare a blurb for the
texinfo documentation?

-- 
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] [PATCH] Fix: sync wins correctly after tmpwm for multiple screens

[Jeremie Courreges-Anglas]

On Sun, Aug 06 2017, Antoine Busque  wrote:
> The current implementation of `sync_wins`, which gets called after
> control is returned to ratpoison following a call to `tmpwm`, gets
> executed once per screen.
>
> This is not only unnecesary, but also causes ratpoison to break after
> returning from `tmpwm`. This is due to two things: first, we can scan
> for the windows in only one pass, because the call to `XQueryTree`
> returns all windows below the root window, which is shared across the
> screens. Second, the current implementation only checks whether a
> window is a special ratpoison window (i.e. the key window, bar window,
> etc.) for the current screen. This results in some windows being
> mapped although they shouldn't be, which is what causes the break
> preventing ratpoison from receiving commands correctly,
>
> This patch fixes these issues by only running `sync_wins` once instead
> of on all screens, and by using the existing `is_rp_window` utility
> function to prevent a special ratpoison window from being mapped,
> regardless of the screen it belongs to.
>
> Signed-off-by: Antoine Busque 
> ---
>  src/actions.c | 16 ++--
>  1 file changed, 6 insertions(+), 10 deletions(-)

Pushed, thanks.

> diff --git a/src/actions.c b/src/actions.c
> index a044f7a..21237ee 100644
> --- a/src/actions.c
> +++ b/src/actions.c
> @@ -4949,12 +4949,15 @@ cmd_warp (int interactive UNUSED, struct cmdarg 
> **args)
>  }
>  
>  static void
> -sync_wins (rp_screen *s)
> +sync_wins (void)
>  {
> +  rp_screen *s;
>rp_window *win, *wintmp;
>XWindowAttributes attr;
>unsigned int i, nwins;
>Window dw1, dw2, *wins;
> +
> +  list_first (s, _screens, node);
>XQueryTree(dpy, s->root, , , , );
>  
>/* Remove any windows in our cached lists that aren't in the query
> @@ -5009,11 +5012,7 @@ sync_wins (rp_screen *s)
>for (i=0; i  {
>XGetWindowAttributes(dpy, wins[i], );
> -  if (wins[i] == s->bar_window
> -  || wins[i] == s->key_window
> -  || wins[i] == s->input_window
> -  || wins[i] == s->frame_window
> -  || wins[i] == s->help_window
> +  if (is_rp_window (wins[i])
>|| attr.override_redirect == True) continue;
>  
>/* Find the window in our mapped window list. */
> @@ -5195,10 +5194,7 @@ cmd_tmpwm (int interactive UNUSED, struct cmdarg 
> **args)
>  
>/* Sort through all the windows in each group and pick out the ones
>   that are unmapped or destroyed. */
> -  list_for_each_entry (cur_screen, _screens, node)
> -{
> -  sync_wins (cur_screen);
> -}
> +  sync_wins ();
>  
>/* At this point, new windows have the top level keys grabbed but
>   existing windows don't. So grab them on all windows just to be
<#secure method=pgpmime mode=sign>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

___
Ratpoison-devel mailing list
Ratpoison-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/ratpoison-devel

Re: [RP] libhistory-support.

[Jeremie Courreges-Anglas]

On Wed, Aug 09 2017, Spiros Bousbouras <spi...@gmail.com> wrote:
> On Monday 2017-08-07 Jeremie Courreges-Anglas wrote :
>> As I already said on this list, mouse-focus support is likely to be
>> accepted if someone actually takes the time to discuss and implement it,
>> from scratch or using the work done by folks like Jeff Abrahamson.
>
> What about the patch submitted by Julien Pagès in February this year ?
> The feedback was that some improvements were needed and the last post
> on the matter was by him replying to you where he said
>
> 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!
>
> I don't know if he lost interest or he is still waiting for your reply.

Well, let's Cc: him and we'll find out!

xrandr has been merged in, ratpoison-1.4.9 is out, so the road is clear.

-- 
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] libhistory-support.

[Jeremie Courreges-Anglas]

On Sun, Jul 30 2017, Martin Hertz  wrote:
> After thinking about it, then as ratpoison has implemented internal history
> support itself, then maybe enabling libhistory support and adding to
> resource-usage, wouldn't be the best solution, and I only also wanted a
> single option from said lib, which was the search-in-history completion
> function(e.g. 'ch' becomes 'chromium', or 'sou' becomes
> 'source .ratpoisonrc' etc, which in libhistory is enabled with a preceding
> exclamation-mark), which possibly could be implemented anyway additionally
> later on, in the internal history support if deemed appropriate.

Being able to search in the ratpoison history using C-r, etc looks like
a nice feature, maybe it could be implemented in a simple fashion.

> Btw, i'm sorry I cannot contribute myself (yet), as a noob in C
> programming, but im doing what I can to learn it currently :)

As someone that uses C almost every day, I can only support that
effort. :)

> Unrelated, sorry, but I previously read about adding mouse-focus to frames,
> though not by default... I have no say in this obviously, but I would hope
> it would then be as an external compile option and external file, like
> sloppy.c, and not going into main-code. Personally I find this highly
> strange, that there's a demand for such and think it's highly
> misplaced,

I personnally don't care at all about mouse-focus suport.  And fact that
you care about a feature doesn't mean that I - or anyone - *has* to
implement it.  This is free software, you're not a client.

> but of course as said, none of my business, and I respect the maintainers
> decision on this obviously.

As I already said on this list, mouse-focus support is likely to be
accepted if someone actually takes the time to discuss and implement it,
from scratch or using the work done by folks like Jeff Abrahamson.

> A final unrelated note, is that I would love if xft got disabled by default
> - it more than doubles memory usage and imho doesn't seem to fit into a
> small fast keyboard-centric wm, but that's just my humble opinion. though
> i've seen plenty state the same around the web - of course the only ones
> deserving a vote on this, is the actual maintainer and coding-contributors,
> I of course understand and respect.

I'm unlikely to disable Xft support by default given that non-Xft looks
ugly even to me, and most people have tons of ram and high-resolution
screens.  If you build ratpoison yourself you can disable it, or ask
your distro to disable it by default.

> Thanks for keeping ratpoison alive everyone, it's very much appreciated!

Sure. :)

-- 
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] [PATCH] Fix: call using_history after initializing history entries

[Jeremie Courreges-Anglas]

On Wed, Aug 02 2017, Antoine Busque  wrote:
> In its current state, history expansion requiring any sort of string
> lookup is not working, always returing "event not found". This is due
> to `history_offset` being set improperly by an early call to
> `using_history`.
>
> A call to `using_history` needs to follow, not precede, the loop
> performing initialization of history entries found in
> `history_expand_line`. This allows for `history_offset` to reflect the
> now non-zero length of the history, restoring the expected behaviour
> of history expansion.

Thanks for figuring this out, Antoine.

I don't think I've ever used (or tried to use) history expansion
support in ratpoison.  I think there are two possible ways to move
forward:
- history expansion has been broken for so long that this code should
  just be removed.
- only recent versions of libhistory break with the current ratpoison
  code.  So people that are used to this history expansion support might
  like your fix.

I have recently disabled libhistory support by default, and asked
whether people would miss it if it was removed for good from ratpoison.
Only two persons answered positively.  Also, looking at the code in your
diff below, history expansion will only be enabled for lines that
contain '!', which is a subset of what libhistory supports.

I am going to merge your fix, so that people can play with history
expansion, and hopefully improve it.  I won't test it myself, as my
day-to-day system doesn't provide libhistory.  Input welcome.

> Tested-by: Martin Hertz 
> Signed-off-by: Antoine Busque 
> ---
>  src/history.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/history.c b/src/history.c
> index d1e9938..1466e89 100644
> --- a/src/history.c
> +++ b/src/history.c
> @@ -314,10 +314,10 @@ history_expand_line (int history_id UNUSED, char 
> *string, char **output)
>  
>if (strchr (string, '!')) {
>  clear_history ();
> -using_history ();
>  list_for_each_entry(item, [history_id].head, node) {
>add_history (item->line);
>  }
> +using_history ();
>  return history_expand (string, output);
>}
>  #endif

-- 
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] [PATCH] Show frame indicator on focus* invocations

[Jeremie Courreges-Anglas]

Hi,

Antoine Busque  writes:

> The current behaviour of `focus{up,down,left,right}` is to show the
> indicator if and only if the screen onto which the focus has just been
> moved (or stayed) has more than 1 frame on it.
>
> This however is rather unintuitive, especially in multi-screen setups,
> where the focus can move from one screen to a completely different
> one, without any indication of the current frame, provided that the
> newly focused screen has a single window.

This sounds very confusing indeed.

> Instead, show the current frame indicator regardless of number of
> frames whenever invoking `focus*`.

I like the idea, however... why the show_frame_indicator(0) ->
show_frame_indicator(1) changes below?

Right now, if the focus{up,down,left,right} commands can't find an
appropriate frame, they'll stay silent if you are on a single-frame
screen.  I think it's nicer that way.

The rest of the patch looks correct, but I think there is room to
simplify the handling of the frame indicator.  Could you please test
the diff below and report back?


diff --git a/src/split.c b/src/split.c
index a9d69cd..c7e62cf 100644
--- a/src/split.c
+++ b/src/split.c
@@ -847,6 +847,9 @@ set_active_frame (rp_frame *frame, int force_indicator)
   if ((old != s->current_frame && num_frames(s) > 1)
   || s != old_s)
 {
+  if (s != old_s)
+force_indicator = 1;
+
   show_frame_indicator(force_indicator);
 
   /* run the frame switch hook. We call it in here because this is


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

___
Ratpoison-devel mailing list
Ratpoison-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/ratpoison-devel

Re: [RP] ratpoison-1.4.9 has been released

[Jeremie Courreges-Anglas]

Eric S Fraga <e.fr...@ucl.ac.uk> writes:

> On Tuesday,  4 Apr 2017 at 07:30, Jeremie Courreges-Anglas wrote:
>> Hi folks,
>>
>> Here's a new release with a lot of changes accumulated over the past
>> three years.  Please see the NEWS entry for a description of changes and
>> new features.
>
> I have finally had a chance to try this out.
>
> Unfortunately, on my 3 screen system, v1.4.9 does not work properly
> whereas 1.4.8 (on Debian testing) does.  In particular, 1.4.9 finds only
> one screen although 1.4.8 finds all three although the latter treats
> them as completely separate servers (i.e. cannot move windows from one
> screen to another).  The X server (with nouveaur driver) doesn't support
> xrandr on this system so maybe this is the problem.

That's likely.  The code that used to support xinerama was removed and
replaced by the xrandr code.  At that time I had no objection regarding
this, as xrandr seemed supported by most drivers.

> Any suggestions for getting 1.4.9 working on a non-xinerama non-xrandr
> multiple screen configuration would be welcome.

First I think we could try to understand why xrandr isn't working on
your nouveau setup:

  https://nouveau.freedesktop.org/wiki/Randr12/

Does ratpoison print any message on stderr?
(Such as "Xrandr version 1.2 is not supported".)

-- 
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

[RP] ratpoison-1.4.9 has been released

[Jeremie Courreges-Anglas]

Hi folks,

Here's a new release with a lot of changes accumulated over the past
three years.  Please see the NEWS entry for a description of changes and
new features.

Thanks to all who provided bug reports, tests, suggestions and patches!

Download links:
  http://download.savannah.nongnu.org/releases/ratpoison/ratpoison-1.4.9.tar.gz
  
http://download.savannah.nongnu.org/releases/ratpoison/ratpoison-1.4.9.tar.gz.sig
  http://download.savannah.nongnu.org/releases/ratpoison/ratpoison-1.4.9.tar.xz
  
http://download.savannah.nongnu.org/releases/ratpoison/ratpoison-1.4.9.tar.xz.sig

Savannah project:
http://savannah.nongnu.org/projects/ratpoison

Git repo:
git://git.savannah.nongnu.org/ratpoison.git

Wiki:
http://ratpoison.wxcvbn.org/cgi-bin/wiki.pl

-- 
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] ratpoison-1.4.9-rc2

[Jeremie Courreges-Anglas]

Mathieu Othacehe  writes:

> Hi Joren,
>
>> what differences are there for a user? Will ratpoison somehow automatically
>> detect when another screen is plugged in or do we still have to use the
>> 'restart' command?
>
> Yes, thanks to xrandr support, when a new screen is plugged and activated
> (via xrandr(1) or any other tool based on xrandr), it is automatically
> detected by ratpoison.
>
> You no longer have to use :restart command. You should be able to see
> the new screen with :sdump command. This is also true for screen
> rotation and resizing, no :restart is needed anymore.

Feels like this should be documented.

Suggestions (and patches) welcome!

[...]

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

___
Ratpoison-devel mailing list
Ratpoison-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/ratpoison-devel

[RP] ratpoison-1.4.9-rc2

[Jeremie Courreges-Anglas]

Hi,

The xrandr branch has been merged, ratpoison now uses Xrandr to keep
track of screens at runtime.  I guess it means a bit of testing is
needed before the 1.4.9 release.

Why "rc2"?  Because I published rc1 tarballs yesterday but found more
stuff to tweak in the meantime.

Please report back, successful reports are welcome, especially for
multiple screens setup.  Even reports about Xinerama setups would be
interesting (no idea how those behave right now).

So here are the tarballs:

  http://autogeree.net/~jca/ratpoison/alpha/ratpoison-1.4.9-rc2.tar.gz
  http://autogeree.net/~jca/ratpoison/alpha/ratpoison-1.4.9-rc2.tar.xz

PGP signatures:

  http://autogeree.net/~jca/ratpoison/alpha/ratpoison-1.4.9-rc2.tar.gz.sig
  http://autogeree.net/~jca/ratpoison/alpha/ratpoison-1.4.9-rc2.tar.xz.sig

-- 
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

[Jeremie Courreges-Anglas]

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] [PATCH 2/2] Fix frozen state when a new screen appears after all screens have been removed

[Jeremie Courreges-Anglas]

Merged, thanks.

Please see below,

Mathieu OTHACEHE  writes:

> Handle correctly the fact that the deleted screen could be the last one.
> If a screen is plugged, and no other screens are present, give focus to
> it's key window.
> ---
>  src/screen.c | 45 ++---
>  1 file changed, 26 insertions(+), 19 deletions(-)
>
> diff --git a/src/screen.c b/src/screen.c
> index d8f580f..cfcf2f8 100644
> --- a/src/screen.c
> +++ b/src/screen.c
> @@ -635,11 +635,6 @@ screen_add (int rr_output)
>  
>screen->number = numset_request (rp_glob_screen.numset);
>  
> -  if (!rp_current_screen)
> -rp_current_screen = screen;
> -
> -  change_windows_screen (NULL, screen);
> -
>  #ifdef HAVE_XRANDR
>if (rp_have_xrandr)
>  xrandr_fill_screen (rr_output, screen);
> @@ -647,30 +642,42 @@ screen_add (int rr_output)
>init_screen (screen);
>init_frame_list (screen);
>  
> +  if (screen_count () == 1)
> +{
> +  rp_current_screen = screen;
> +  change_windows_screen (NULL, rp_current_screen);
> +  set_window_focus (rp_current_screen->key_window);
> +}
> +
>return screen;
>  }
>  
>  void
>  screen_del (rp_screen *s)
>  {
> -  /*
> -   * The deleted screen cannot be the current screen anymore,
> -   * focus the next one.
> -   */
> -  if (s == rp_current_screen) {
> -screen_remove_current ();
> -  } else {
> -rp_frame *cur_frame;
> -rp_window *cur_win;
> +  if (screen_count () == 1)

Here "s == rp_current_screen" is also true.

> +{
> +  hide_screen_windows (s);
> +  rp_current_screen = NULL;
> +}
> +  else if (s == rp_current_screen)
> +{
> +  /*
> +   * The deleted screen cannot be the current screen anymore,
> +   * focus the next one.
> +   */
> +  screen_remove_current ();
> +}

Wouldn't this be better expressed as:
  if (s == rp_current_screen)
{
  if (screen_count () == 1)
 ...
  else
 ...
}
  else
...

> +  else
> +{
> +  hide_screen_windows (s);
> +}
>  
> -cur_frame = screen_get_frame (s, s->current_frame);
> -cur_win = find_window_number (cur_frame->win_number);
> -hide_window (cur_win);
> -  }
> +  /* Affect window's screen backpointer to the new current screen */
> +  change_windows_screen (s, rp_current_screen);
>  
>numset_release (rp_glob_screen.numset, s->number);
>  
> -  change_windows_screen (s, rp_current_screen);
>screen_free (s);
>  
>list_del (>node);

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

___
Ratpoison-devel mailing list
Ratpoison-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/ratpoison-devel

Re: [RP] [PATCH] Make focus* commands screen aware.

[Jeremie Courreges-Anglas]

Pedro Silva  writes:

> Joseph Mingrone  writes:
>
>> This is a nice idea.  It makes ratpoison behave similar to StumpWM
>> with respect to multiple screens, which I find more intuitive.
>>
>> I've attached an updated patch, which applies against the xrandr
>> branch.

Thanks Joseph for both sending a follow-up *and* refreshing the patch!

> Thanks Joseph, I've been meaning to try out the xrandr stuff, but
> couldn't find the time to do what you just did. Just applied it cleanly
> against the xrandr branch, everything's looking good. Thanks again!
>
> Now, to get it into master...

I noticed your mail early, but then work on xrandr kinda conflicted.

Given the positive feedback this has good chances to land in the next
release.  Thanks!

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

___
Ratpoison-devel mailing list
Ratpoison-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/ratpoison-devel

[RP] ratpoison-1.4.9-xrandr4 snapshots

[Jeremie Courreges-Anglas]

Hi,

updated snapshots after the recently merged patches from Mathieu
Othacehe:

  http://wxcvbn.org/~jca/distfiles/ratpoison-1.4.9-xrandr4.tar.gz
  http://wxcvbn.org/~jca/distfiles/ratpoison-1.4.9-xrandr4.tar.gz.sig
  http://wxcvbn.org/~jca/distfiles/ratpoison-1.4.9-xrandr4.tar.xz
  http://wxcvbn.org/~jca/distfiles/ratpoison-1.4.9-xrandr4.tar.xz.sig

Test reports welcome, as usual. :)

-- 
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] [PATCH v2 0/6] Improve xrandr support

[Jeremie Courreges-Anglas]

Jeremie Courreges-Anglas <j...@wxcvbn.org> writes:

> Mathieu OTHACEHE <m.othac...@gmail.com> writes:
>
>> This patch set does 4 things :
>>
>> * Affect a number from a global numset to each screen.
>> * Use the previous number in multi-monitor commands (sselect, sfdump, 
>> sfrestore and fdump).
>> * Sort screens using height dimension.
>> * Fix a gcc warning when compiling without xrandr support.
>>
>> To be applied to xrandr branch.
>
> Patchset applied!  Note that I've modified the approach you've taken for
> sfrestore, as it didn't work well with multiple frames per screen.
>
> Note that savannah is undergoing maintenance, I don't know when the git
> repo will become available again.  In the meantime I might publish
> snapshots tomorrow, and perhaps use a temporary public git repo.

Savannah seems to be back on track, the latest changes have been pushed
to the xrandr branch.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

___
Ratpoison-devel mailing list
Ratpoison-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/ratpoison-devel

[RP] New ratpoison-1.4.9-xrandr2 snapshots

[Jeremie Courreges-Anglas]

Here are fresh tarballs of the xrandr branch, they contain recent
improvements & bugfixes that are not yet committed in the main git repo,
which is currently unavailable.  Please test and report back, especially
if you have a setup that involves multiple screens!

  http://wxcvbn.org/~jca/distfiles/ratpoison-1.4.9-xrandr2.tar.gz
  http://wxcvbn.org/~jca/distfiles/ratpoison-1.4.9-xrandr2.tar.gz.sig
  http://wxcvbn.org/~jca/distfiles/ratpoison-1.4.9-xrandr2.tar.xz
  http://wxcvbn.org/~jca/distfiles/ratpoison-1.4.9-xrandr2.tar.xz.sig

-- 
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] [PATCH v2 0/6] Improve xrandr support

[Jeremie Courreges-Anglas]

Mathieu OTHACEHE  writes:

> This patch set does 4 things :
>
> * Affect a number from a global numset to each screen.
> * Use the previous number in multi-monitor commands (sselect, sfdump, 
> sfrestore and fdump).
> * Sort screens using height dimension.
> * Fix a gcc warning when compiling without xrandr support.
>
> To be applied to xrandr branch.

Patchset applied!  Note that I've modified the approach you've taken for
sfrestore, as it didn't work well with multiple frames per screen.

Note that savannah is undergoing maintenance, I don't know when the git
repo will become available again.  In the meantime I might publish
snapshots tomorrow, and perhaps use a temporary public git repo.

Cheers,
-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

___
Ratpoison-devel mailing list
Ratpoison-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/ratpoison-devel

Re: [RP] [PATCH 3/6] Disable sfdump if there is no xrandr support.

[Jeremie Courreges-Anglas]

Mathieu OTHACEHE  writes:

>> No idea whether how stable would be the mapping between Xrandr ids and
>> ratpoison ids, though, as we don't control the former.  There's not much
>> choice though, but 1. you already have implemented a screen_sort
>> function, and 2. this sounds better than forcing the user to deal with
>> numbers like 42 and 66, especially for 'sselect'. :)
>
> I could use numset (fron number.c), to affect an id to each screen.
> The id would be affected at ratpoison start, once screen are detected
> and sorted.

This makes me think that screens are currently sorted with only a
"left < right" criteria, maybe total ordering with an additional
"top < bottom" could be interesting.

(Which makes me think that screen_sort() happens early, thus we
should probably check that we do respect Xrandr's rotations even when
they happen early / before ratpoison even exists...)

>
> Then, if a screen is removed, its numset is released. On screen plugging, a
> new numset is affected.

My lack of knowledge about multiple-screens setups strikes again: do you
mean to say that just unplugging a screen makes Xrandr notify ratpoison
that the screen went away?  I thought that some kind of manual (or
preconfigured) intervention with xrandr(1) or any other GUI tool was
needed.  If not, I'd say that

> On the positive side, if the user doesn't add or remove screens, its
> screen will keep using the same ids.
>
> On the negative side, if the user unplug a screen and plug a different
> screen, it will have the same id as the previously unplugged screen.

Well, if screen A in unplugged from "slot 1" and screen B is then
plugged in "slot 1", then I think this is the desired behavior.  BTW, do
the Xrandr IDs change when you do that?

> What's your opinion about it ?

Sounds good at first, I think providing a stable ordering for static
setups is enough to make current users happy.  I'm wondering how much
people are relying on sselect.

> Thanks,

Thank *you* in advance for bearing with me.  I'm really a "one laptop
screen will do" kind of guy.  This Xrandr thingie almost makes me want
to buy extra screens just so that I can stop looking stupid. :)

-- 
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] [PATCH 3/6] Disable sfdump if there is no xrandr support.

[Jeremie Courreges-Anglas]

Mathieu OTHACEHE  writes:

> Without xrandr support, sfdump command has no interest.

I think this is headed in the wrong direction.  There is no reason to
disable this command when we can easily deal with the single available
screen.

Same thing for your sselect and srestore diffs.  Moreover, those
introduce additional uses of xrandr-specific function in generic code.
I'd rather have a generic abstraction for available screens.

I have to think more about this.

-- 
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] [RFC v3] Add xrandr support

[Jeremie Courreges-Anglas]

Mathieu OTHACEHE  writes:

> Drop deprecated xinerama support and replace it with xrandr.
>
> Signed-off-by: Mathieu OTHACEHE 
> ---
>
> Hi,
>
> Here is v3, to address Jeremie review and rebase patch on top of recent 
> changes.

Thank you Mathieu.

I've prepared some snapshots:

  http://wxcvbn.org/~jca/distfiles/ratpoison-1.4.9-beta.tar.gz
  http://wxcvbn.org/~jca/distfiles/ratpoison-1.4.9-beta.tar.xz

PGP signatures:

  http://wxcvbn.org/~jca/distfiles/ratpoison-1.4.9-beta.tar.gz.sig
  http://wxcvbn.org/~jca/distfiles/ratpoison-1.4.9-beta.tar.xz.sig

It would be nice to get test reports from people with multiple screens
setups.  The more reports I get the earlier we can publish a new
release. ;)

-- 
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] [RFC v2] Add xrandr support

[Jeremie Courreges-Anglas]

Mathieu OTHACEHE  writes:

>> Erm, you may have to do it again, since I've now pushed some old stuff
>> to the repo. :-|
>
> No problem :)
>>
>> OTOH, diffs are fine for testing but for what should hit the repo
>> I would prefer commits generated with git format-patch.  Could you
>> please use this format?
>
> Well, I did use git format-patch & git send-email for my patches.

Bleh. *grabs another coffee*

> By the way, could you have a look to this old patch
>
> http://lists.nongnu.org/archive/html/ratpoison-devel/2016-08/msg1.html

Pushed.

> Thanks,

Well, thank you for your patience. ;)

-- 
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] [RFC v2] Add xrandr support

[Jeremie Courreges-Anglas]

Mathieu OTHACEHE  writes:

> Drop deprecated xinerama support and replace it with xrandr.
>
> Signed-off-by: Mathieu OTHACEHE 
> ---
>
> Hi.
>
> I forget to rebase my patch on top of master, so here is v2.

Erm, you may have to do it again, since I've now pushed some old stuff
to the repo. :-|

OTOH, diffs are fine for testing but for what should hit the repo
I would prefer commits generated with git format-patch.  Could you
please use this format?

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

___
Ratpoison-devel mailing list
Ratpoison-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/ratpoison-devel