On 170420-05:57+0200, Floyd Anderson wrote: > On Do, 13 Apr 21:55:29 +0200 > Miroslav Rovis <miro.ro...@croatiafidelis.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
signature.asc
Description: Digital signature