Re: [gentoo-user] Re: How to set size to windows in Openbox in local config [SOLVED]

[Miroslav Rovis]

On 170420-05:57+0200, Floyd Anderson wrote:
> On Do, 13 Apr 21:55:29 +0200
> Miroslav Rovis <miro.rovis@××××××××××××××.hr> wrote:
...
> >
> >But I forgot floyd has got a "patch to keep the window position while
> >resizing the font" and offered it:
> >
> >https://marc.info/?l=gentoo-user&m=149205691530349&w=2
...
>
> Hi Miroslav,
>
> back from some computer-free holidays,
I hope you had good and restful time!

> I haven’t forgotten that I owe
> you a patch. Study my attached approach and if you like, apply the patch
> at your own risk (it should be clean applicable to the currently latest
> upstream commit [1]).
which I just git clone'd, for that purpose. 

> If you have any questions or ideas, get back to me.
Don't worry, I will! With my usual excuse for my slowness and relative
inaptitude...

> But keep in mind,
> I’m neither a developer nor a GUI programmer guru.
>
> It has some limits and/or doesn’t resolve certain issues:
>   - the patch assumes ‘NorthWest’ as the reference point for the window
>     gravity.
NW is just fine, I would expect that, it's the usual default.

>   - if terminal background is colourised via escape sequences (as Andrew
>     mentioned in [2]),
Yeah, I had marked important that email previously already, but only now
found some time to study the links (and only *some* time)...

And some of these notes of yours below I'll only more fully understand
when I, hopefully, try and apply the patch (more about my plan on that
further below):
>     you may notice that a borderless window colourise
>     only full cells (of rows/columns), not the gap between a terminal
>     cell end and the window edge. Framed windows seems not to be
>     affected by this behaviour.
>   - window edges flutters/flickers while resizing fonts (independently
>     from step-size and also when using escape sequences for resizing)
>   - toggling a window between normal -> fullscreen/maximised state ->
>     and back, you may notice that the window size has changed. I don’t
>     know the reason for this issue (which occurs independently from the
>     urxvt-font-size extension and my patch).
>   - different window manager (WM) probably produces different
>     behaviours. Think about a WM that try to imitate a tiling window
>     manager by automatic resizing/positioning within a snapping area
>     near the desktop edges.
>   - patch is tested to my moderate needs but not fully with all kinds of
>     fonts, WMs, multi monitor environment, etc.
>   - ...
>
> The patch is too unimportant to solve some/all of the above issues
> and/or bloating up the urxvt extension script. And additionally,
> rxvt-unicode won’t and doesn’t expose all Xlib functions (such as
> XGetWindowAttributes) in urxvtperl, the embedded perl interpreter. So it
$ man urxvtperl # but how cryptic!, how long study that will be... I don't
                  have all those hours right now...
                  I hope I'll find a solution with less time to invest,
                  else...
> will be tricky sometimes, to solve a specific behaviour.
>
> My used and tested urxvt-font-size related Xresource settings:
> 	URxvt.font-size.keepwin:	true
> 	URxvt.font-size.step:		4
> 	URxvt.keysym.C-0xffad:		font-size:decrease
> 	URxvt.keysym.C-0xffab:		font-size:increase
> 	URxvt.keysym.C-0xffb0:		font-size:reset
>
> Since I use the default keysyms for font-size:{decrease,increase,reset}
> in Vim, I changed those defaults to C-KP_Substract (C-0xffad), C-KP_Add
> (C-0xffab), C-KP_0 (C-0xffb0) like in Firefox and others.
I don't get what these are. Not at this time. And this is my second
reading of your email...

NOTE (at proofreading): Is that 'C-KP_Substract' should read
'C-KP_Subtract'?, the "-" on the keypad? So 'C-KP_Subtract' means
Ctrl-<minus>?, and C-KP_0 means Ctrl-0?

I also compared what I have currently installed:

# eix urxvt-font-size
[I] x11-misc/urxvt-font-size
     Available versions:  1.1 **9999
     Installed versions:  1.1(13:07:28 22/02/15)
     Homepage:            https://github.com/majutsushi/urxvt-font-size/
     Description:         Perl extension for rxvt-unicode to change the font size on the fly

#

# qlist urxvt-font-size
/usr/lib64/urxvt/perl/font-size
/usr/share/doc/urxvt-font-size-1.1/README.markdown.bz2
#

[I compared what I have currently installed] with the 9999 version, which
is the version that, IIUC, I plan to hopefully try and patch with your
patch...

>
> References:
> [1] <https://github.com/majutsushi/urxvt-font-size/commit/0cc2624489fb60fcebf85d5c4dd62f425196c5b0>
That's the the two colons that Jan Larres, the current maintainer left
out, and you reminded him they were missing. Nice of you! (IIUC)

> [2] <https://archives.gentoo.org/gentoo-user/message/a4d58e993934aa4a273998eda030d115>
The link that Savchenko gave in that email is puzzling me:
http://rcr.io/words/dynamic-xterm-colors.html
I want to try and figure out that bash script there... It's very
educational.

I need more time to study this. But I do have a question:

I read, somewhere, spender (the author of grsecurity) wrote it, but I
don't recall the entire context, and so I can only vaguely paraphrase
what I remember he wrote, that... Aaargh, can't remember well at all...
I think it wasn't about perl only, or perl wasn't even mentioned
explicity, but it was spender saying how running scripts by using stuff
like:

#!/usr/bin/env [perl|python|...]
(
in the new script it's 
#!/usr/bin/env perl
)


instead of the more simple, traditional shebang line:

#!/usr/bin/<interpreter> # perl or python or bash

(
in the old script it's 
#!/usr/bin/perl
)

that the former (...env <interpreter>) is not as safe as the latter
(...bin/<interpreter>).

Why was it necessary to introduce that change? I'm referring to Jan's
change, of course.

It can't be it does not bring a tiny bit more into the attack surface,
can it?

I need to try and understand some more of the above, but not
immediately. A couple of hours of work on this today still got me
too inconclusive in my understanding... And I do have other stuff on my
hands that require my efforts and time...

And my plan is... Probably bump the ebuild into my custom overlay, as I
don't install online from git (until it becomes possible to verifiably
install packages while online, I mean: for non-experts like me; it is
possible to verifiably install packages with the old webrsync, also
while online...; OTOH app-crypt/gkeys that Savchenko recommended to me
in an email a month or two ago to try and test, those do bring in
more verifiability when installing from git, but I haven't found time to
study gkeys yet...)

[And my plan is... Probably bump the ebuild into my custom overlay,]
modify it to get the git source served from my local Apache cgit repo
[1] (and urxvt-font-size package is not even PGP-signed, neither tags
nor commits, which is always an important feature missing with the code,
for me...)

[modify it to get the git source from my local Apache cgit repo], put
your patch in /etc/portage/patches/x11-misc/urxvt-font-size/ check that
my /etc/portage/bashrc is ready to apply user patches (I recently
updated it as per the wiki page, gave the link in another email a couple
of days ago, to this list, yeah, it was in the non-replied-to message to
Ian Zimmermann in a 2 emails --so far-- thread split from this one...
which was about window positions as well!... [2]), and...

...And emerge it:

# emerge urxvt-font-size

Courious to read what your opinion is on usage of /env vs plain /bin
scripts security-wise, as I put it further above! And why that change...

Regards!
---
[1]  I have actually learned when installing gnunet from
     youbroketheinternet-overlay just two days ago that I probably can
     use local overlay even without seving it with cgit and Apache,
     simply from local filesystem!

[2]  openbox window positions
     https://lists.gt.net/gentoo/user/325342
     (and my reply to it contains digressions, but also simple
     questions...)

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr