Re: [dev] [dwm] execwm(), ie, self?
On 2024-09-10 10:32 AM, Jakub Bystron wrote: On Tuesday, September 10th, 2024 at 00:51, Steffen Nurpmeso wrote: But, hey, one thing. I go totally insane with how the terminal window is shown in the "fullscreen" layouts. It is so that the st instance has 55 lines and 191 columns here, then, but this does not suffice to be really fullscreen, there is a bit of background visible on the right and the bottom. With cwm, the maximize simply scaled the window no matter what (ie borders aka padding nside then but due to the colour it "would not hurt"). If it would be placed so what the border would be evenly spaced on the left and right (and the top and bottom). But so it is terrible. Is it somehow doable to get around these "holes"? (With bar shown they seem to be evenly "width" at least.) Well i now did "xsetroot -bg black", .. but isn't that a hack. Thank you! --steffen Blessings that someone mentioned that! :-) I thought it was a lack of configuration on my end or that I had patched st too much. Is there a quick and easy fix to address these gaps? Kind regards, -- jb Turn off resize hints [1]. Q: I've got a 1 or 2 pixel gap between the right side of my terminal and the right side of the screen, and I want to turn it off. A: This is due to the column-based nature of terminals. Terminals don't just insert space somewhere, but tell the WM they can't be resized in a certain way. The terminal can't use the "wasted space" anyway, so this is purely aesthetics. You can change `static const int resizehints = 1;` to `0` in config.h to turn resizehints off. This wastes the same amount of space inside the terminal window that would otherwise be wasted outside. [1]: https://dwm.suckless.org/faq/ --- Kind regards, Andy Gozas _ ( ) ascii ribbon campaign X against html e-mail / \ against proprietary attachments
Re: [dev] Commandline Email Advice Request
On 2022-11-24 07:42 PM, Michael Partridge wrote: Happy Thanksgiving! I'm having trouble using `git --send-email` to send a patch in. I am trying to use this email address (mcp...@nau.edu) with the following settings in my global config: ``` [sendemail] smtpencryption = tls smtpserver = smtp.gmail.com smtpuser = mcp...@nau.edu smtpserverport = 587 ``` Source: https://git.wiki.kernel.org/index.php/GitTips#Mail Although it is an NAU account, it routes to a gmail inbox. I've also tried the SSL settings from this page: https://support.google.com/mail/answer/7126229?authuser=1&visit_id=638049147999726000-3838985679&hl=en&rd=1#zippy=%2Cstep-change-smtp-other-settings-in-your-email-client What email service do you guys use and how did you set it up for the commandline? MCP I remember having problems when sending a patch using `git --send-email` which was due to `perl-authen-sasl` (that's what it's called in pacman on archlinux, not sure what it would be called on your system) package not being installed. Git send-email relies on that package being there, but for some reason might not have it as a dependency. Try checking if you have it. Also, is there any error message, when `git --send-email` exits, that you could provide? --- Kind regards, Andy Gozas.
Re: [dev][surf] surf has become super-slow!
On 2022-10-12 05:00 PM, Robert Winkler wrote: Hi, I just re-compiled surf on a recent manjaro arch linux; However, text input has become too slow for productive use. Is the problem known? Any idea on how to solve it? Hi, you should check your webkit2gtk version if it was installed using the package manager (for archlinux: pacman -Qi webkit2gtk). On webkit2gtk versions above 2.36.6 there is a bug which causes all kinds of problems in surf (http://lists.suckless.org/dev/2210/34979.html). If you are on the affected versions, you should try and either remove the webkit library as described in the thread above, or downgrade to a previous version of webkit2gtk, which you can find here (for archlinux): https://archive.archlinux.org/packages/w/webkit2gtk/ and see if your problem would go away. --- Andy Gozas.
Re: [dev] [surf] Application renders unresponsive after first keystrokes
On 2022-10-09 04:40 PM, Petr Vaněk wrote: Hi, On Sun, Oct 09, 2022 at 06:12:56PM +0200, Chris Weber wrote: Surf is my browser for 6 month (/wo any issue ) and last week the above issue arose. When I navigate to any website (js heavy or html only) and begin to interact with the website via keyboard, the website content renders unresponsive from 5-20s. After rendering responsive again, it will steadily happen again and again. I assume it's an updated dependency which I installed unintentionally, because I left the surf sources untouched. Do you have any tips for troubleshooting the above issue? My first attempt was to debug with gdb, but I'm unshure where to put the breakpoints. I think it should be easier to profile it first and spot the component which freezes the rendering. Or install different versions of webkit? I experience the same issue with webkit-gtk 2.36.8 and 2.38.0. I switched back to 2.36.7, which works fine. I didn't find any related bug report in upstream (one week ago). It would be probably nice to git-bisect between 2.36.7 and 2.36.8 to find the commit causing this issue. Best, Petr If I had to guess, this is probably related to this problem in Webkit https://github.com/WebKit/WebKit/pull/4868 Since the last Webkit update (commit 28a89facb8720 in Webkit), file descriptors from the main process are no longer passed to child processes, which results in surfs web-extension reading out data out of a different file descriptor, that Webkit is using for its own communication, which results in the whole program glitching out. From what I understand, the change will be reverted in the next release of Webkit. Until then, you would have to either downgrade Webkit to 2.36.7 or remove the web extension file located in /usr/local/lib/surf/ directory. I still think however, that this behavior of surf should be changed, since it was made clear to me that there is no guarantee that FDs will always be passed going forward. One way of communication that I found and was also suggested to me by Webkit contributors is using function webkit_web_context_send_message_to_all_extensions which is part of Webkit API, so it would not break as easily. --- Andy Gozas.
