[dev] [dmenu] XLFD fonts are not supported
If I try printf 'X\n' | dmenu -fn '-misc-fixed-*-*-*-*-*-*-*-*-*-*-*-*' with Dmenu 5.0, it runs with a fallback font that is clearly not the XLFD Fixed font. No warning, nothing at all on standard error to hint at the fact that it is not using it. I believe that either the manual page should document that XLFD is not supported anymore or that the stderr should be used to warn users that the font was not recognized and a fallback was used instead.
Re: [dev] [surf] content filter interest check
> Hi there John, Hello Benjamin, > > Is anyone interested in using surf with WebKit content filtering? > > > > If so, I'd like to see your must-have features and can't-have excesses. But > > a mere yea or nay would also be informative, if perhaps more suitable for > > direct contact. > > > > Your idea sounds great, and my opinion it, would be a great addition to surf! > I have tried many times to make surf my de-facto web browser but realized > over time that it lacked three things to achieve this: > => Good content filtering As I said, it already has through wyebadblock > => Good password management (autofill is a must) Good password management is your brain. I see autofill almost as much secure as having no password or the same one everywhere. Maybe somebody will write an external patch for it though. > With those three combined, surf would be (again, in my opinion) the best of > the best. What's the third one?
Re: [dev] [dmenu] XLFD fonts are not supported
On Sun, May 16, 2021 at 10:39:27PM +0200, qsm...@tutanota.com wrote: > If I try > > printf 'X\n' | dmenu -fn '-misc-fixed-*-*-*-*-*-*-*-*-*-*-*-*' > > with Dmenu 5.0, it runs with a fallback font that is clearly not the XLFD > Fixed font. No warning, nothing at all on standard error to hint at the fact > that it is not using it. > > I believe that either the manual page should document that XLFD is not > supported anymore or that the stderr should be used to warn users that the > font was not recognized and a fallback was used instead. > dmenu uses Xft fonts since atleast dmenu 4.5, which was released in 2015. Maybe it is a good idea to document in the man page though (Xft / freetype / fontconfig), not sure. -- Kind regards, Hiltjo
Re: [dev] [surf] content filter interest check
Hi there John, > > Is anyone interested in using surf with WebKit content filtering? > > If so, I'd like to see your must-have features and can't-have excesses. But a > mere yea or nay would also be informative, if perhaps more suitable for > direct contact. > Your idea sounds great, and my opinion it, would be a great addition to surf! I have tried many times to make surf my de-facto web browser but realized over time that it lacked three things to achieve this: => Good content filtering => Good password management (autofill is a must) With those three combined, surf would be (again, in my opinion) the best of the best. When it comes to feature sets, I might be considered to be extreme but I just love Adnauseam (adnauseam.io) which is an agressive take on content filtering. From what I can tell though, this community cares about privacy and any way tracking and/or fingerprinting can be avoided is a welcome change. Anyway, have a great one! -Benjamin Chausse signature.asc Description: PGP signature
Re: [dev] [surf] content filter interest check
On 5/16/21 2:45 PM, Quentin Rameau wrote: => Good password management (autofill is a must) Good password management is your brain. I see autofill almost as much secure as having no password or the same one everywhere. Good password management is pass[0] plus passmenu[1]! [0]: https://www.passwordstore.org/ [1]: https://git.zx2c4.com/password-store/tree/contrib/dmenu -- Sebastian LaVine | https://smlavine.com OpenPGP_0x819C7D054C7C1465.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [dev] [surf] content filter interest check
Hello Jonathan, > Launch delays might be a problem as WebKit seems to want to compile the > filtering binary from a json rules file upon each and every launch. But I > believe that is an optimization issue which I can address later. (Short term, > I'll do what I can and you can opt out. Perhaps, medium-term, mimic > emacs-server. Long term, maybe help develop an API that abstracts the > renderer from the interface -- I suspect one imperative of "suck less" is > "pipe more".) Have you looked at wyebadblock? > Your feedback is truly welcome, even if entirely negative. Questions are > encouraged; accessibility concerns will be given particular attention. Well, it's nice to read about your interest in surf. I don't know about your skill level and motivation endurance, maybe start by doing something not too complex to get aquainted with webkitgtk and its DOM API, something that you won't take a year to do and can use quickly. One thing that comes in mind is a webextention for having keyboard “hints” on webpage (so that you can access links through a combination of alnums instead of having to clickety-click everything). In any case, good luck!
