Re: [dev] Macbook retina and dwm
FRIGN wrote:
Refer to this:
https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI
Not mentioned there, but working with any screen that communicates it's
physical size correctly:
xrandr --fbmm $(xrandr | /bin/sed -n '/ connected / {s/.* \([0-9]\+\)mm
x \([0-9]\+\)mm/\1x\2/p;q}')
Re: [dev] surf rewrite for WebKit2GTK
On Sun, Oct 26, 2014 at 12:34 AM, Andrew Hills ahi...@ednos.net wrote: On 10/25/14 13:41, F Hssn wrote: Following suckless's minimal philosophy, I'd be interested to find out ... snip ... latest webkit. Do you really want to write your own Javascript engine? Well, I hadn't thought of that but now that you mentioned, I downloaded v8 and spidermonkey sources, 0.5 vs 1.2 million (both mostly C++). Then in v8 I noticed it has directories for architectures like arm arm64 mips mips64 ia32. I removed those directories and left only x87 and x64 and ended up with 333k, with 223k lines of C++ source files. To answer your question, I guess it comes down to how much time I have (as always) which is, not much. But I would definitely like some suckless cleanup in this direction, just like in other directions.
Re: [dev] surf rewrite for WebKit2GTK
F Hssn writes: On Sun, Oct 26, 2014 at 12:34 AM, Andrew Hills ahi...@ednos.net wrote: On 10/25/14 13:41, F Hssn wrote: Following suckless's minimal philosophy, I'd be interested to find out ... snip ... latest webkit. Do you really want to write your own Javascript engine? Well, I hadn't thought of that but now that you mentioned, I downloaded v8 and spidermonkey sources, 0.5 vs 1.2 million (both mostly C++). Then in v8 I noticed it has directories for architectures like arm arm64 mips mips64 ia32. I removed those directories and left only x87 and x64 and ended up with 333k, with 223k lines of C++ source files. To answer your question, I guess it comes down to how much time I have (as always) which is, not much. But I would definitely like some suckless cleanup in this direction, just like in other directions. Duktape isn't perfect but it's at least within the realm of sanity: http://duktape.org/ -- Anthony J. Bentley
Re: [dev] surf rewrite for WebKit2GTK
On Sun, Oct 26, 2014 at 01:15:04PM -0500, F Hssn wrote: On Sun, Oct 26, 2014 at 12:34 AM, Andrew Hills ahi...@ednos.net wrote: On 10/25/14 13:41, F Hssn wrote: Following suckless's minimal philosophy, I'd be interested to find out ... snip ... latest webkit. Do you really want to write your own Javascript engine? Well, I hadn't thought of that but now that you mentioned, I downloaded v8 and spidermonkey sources, 0.5 vs 1.2 million (both mostly C++). Then in v8 I noticed it has directories for architectures like arm arm64 mips mips64 ia32. I removed those directories and left only x87 and x64 and ended up with 333k, with 223k lines of C++ source files. To answer your question, I guess it comes down to how much time I have (as always) which is, not much. But I would definitely like some suckless cleanup in this direction, just like in other directions. There is also the c++-C port in order to help remove the c++ compiler/ABI/runtime non-sense from suckless systems. But the real issue with javascript seems to be the dynamic bindings with a www renderer which is huge and insanely complex. This is the feedback I got from one of the netsurf coder. Netsurf is a www renderer, C coded (may have one or two ugly perl5 code generators in their SDK). With javascript support (very partial), it uses the spidermonkey before the mentally ill people at mozilla decided to move it to c++. -- Sylvain
[dev] [dvtm] Truecolor support
Hi, I see that st nicely support truecolor sequences, as it can be easily tested with this command: printf \x1b[38;2;255;100;0mTRUECOLOR\x1b[0m\n that has to be given outside any terminal multiplexer. The point is that currently no terminal multiplexer (tmux, dvtm, screen) supports this kind of color sequences. I'd be interested to see this feature added to dvtm, but I'm not sure if it is possible as it may be a limitation of libncurses. Did anybody try to implement this before? Paride
Re: [dev] Macbook retina and dwm
I'm in the same boat. My DPI is automagically set correctly and using a larger font size works as it should with dwm's status bar and my terminal. The problem I'm currently facing is finding a browser that supports HIDPI correctly. I've been playing with chrome, firefox, and surf but have yet to find a satisfactory setup. Anyone have any recommendations? -emg
Re: [dev] Macbook retina and dwm
On October 26, 2014 9:57:49 PM EET, Evan Gates evan.ga...@gmail.com wrote: I'm in the same boat. My DPI is automagically set correctly Without a xorg.conf? Cool. and using a larger font size works as it should with dwm's status bar and my terminal. What font size are you using The problem I'm currently facing is finding a browser that supports HIDPI correctly. Pictures for ants? or other problems too?
Re: [dev] Macbook retina and dwm
On Sun, Oct 26, 2014 at 1:02 PM, Dimitris Zervas dzer...@dzervas.gr wrote: On October 26, 2014 9:57:49 PM EET, Evan Gates evan.ga...@gmail.com wrote: I'm in the same boat. My DPI is automagically set correctly Without a xorg.conf? Cool. Correct. and using a larger font size works as it should with dwm's status bar and my terminal. What font size are you using I'm currently switching between Terminus size 24 and 28 trying to figure out which I prefer. The problem I'm currently facing is finding a browser that supports HIDPI correctly. Pictures for ants? or other problems too? Most things are tiny, however some text is too large (e.g. titles in tabs). I recompiled chrome in an attempt to figure out the experimental hidpi mode but I haven't had any luck. Zooming in on a page helps, but then all elements are big and the page doesn't seem reflow as it should. Same is true for using surf's zoomto96dpi setting. As such I'm spending most of my time between 150% and 200% zoom with dwm in monocle mode. -emg
Re: [dev] [PATCH] [st] Fix issues with wcwidth() returning -1 for unsupported unicode chars
On Sun, Oct 26, 2014 at 3:15 AM, dequis d...@dxzone.com.ar wrote: My patch: Just wcwidth(...) - abs(wcwidth(...)) In other words: if wcwidth returns -1, interpret that as a column width of 1. It's a bit dirty and lazy, but it works wonderfully for most characters. I'm not sure what the correct solution would be, but it's definitely not something as simple as this - would mean fixing the libc to support unicode up to 7.0, or implementing our own version of it. Opinions? I think your fall-back workaround makes alot of sense until glibc mans up and implements it (the correct solution). I have tested it locally with glibc and musl libc, interestingly musl knows the correct character width. Kind regards, Hiltjo
Re: [dev] [PATCH] [st] Fix issues with wcwidth() returning -1 for unsupported unicode chars
On 26 October 2014 19:36, Dmitrij D. Czarkoff czark...@gmail.com wrote: Apparently no workaround is needed - just use sane libc or avoid using new codepoints until glibc fixes that. Or, if you won't feel dirty after that, send a patch to glibc instead. 'Just using musl' doesn't seem feasible given a glibc-based system - it's easier for smaller programs, but in the case of st i'd have to rebuild xlib, xcb, xft, freetype, fontconfig, etc (and their dependencies) against musl. Not to mention that musl doesn't implement unicode 7.0 either, only up to 6.2. Avoiding using new codepoints is not really an option either, they just appear in messages written by other people and result in unreadable/invisible lines. They offset columns by -1, so with enough characters, they can make a whole line appear as empty. My workaround until now was to open a different terminal emulator just to read the 'missing' lines. I'd say that knowingly allowing that kind of rendering glitch is a bad idea.
[dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same
The background/foreground of selected text is currently set by setting
ATTR_REVERSE, which flips its normal bg/fg. When the text being
selected has the same bg and fg, it won't be readable after selecting
it, either.
This may sound silly - my main use case is IRC channels using color
codes for black-on-black to mark 'spoilers'.
This patch allows that text to be read by selecting it, turning it
into text with white bg and black fg (given default values for
defaultbg/fg), just like most normal unformatted text when selected.
From 380f8ba874976a8392d9c2a6639775b45fce5d91 Mon Sep 17 00:00:00 2001
From: dequis d...@dxzone.com.ar
Date: Sun, 26 Oct 2014 22:39:46 -0300
Subject: [PATCH] Use inverted defaultbg/fg for selection when bg/fg are the
same
The background/foreground of selected text is currently set by setting
ATTR_REVERSE, which flips its normal bg/fg. When the text being selected
has the same bg and fg, it won't be readable after selecting it, either.
This may sound silly - my main use case is IRC channels using color
codes for black-on-black to mark 'spoilers'.
This patch allows that text to be read by selecting it, turning it into
text with white bg and black fg (given default values for defaultbg/fg),
just like most normal unformatted text when selected.
---
st.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/st.c b/st.c
index 12af1ab..e2b7003 100644
--- a/st.c
+++ b/st.c
@@ -3296,9 +3296,14 @@ xdraws(char *s, Glyph base, int x, int y, int charlen, int bytelen) {
}
if(base.mode ATTR_REVERSE) {
- temp = fg;
- fg = bg;
- bg = temp;
+ if (bg == fg) {
+ bg = dc.col[defaultfg];
+ fg = dc.col[defaultbg];
+ } else {
+ temp = fg;
+ fg = bg;
+ bg = temp;
+ }
}
if(base.mode ATTR_FAINT !(base.mode ATTR_BOLD)) {
--
2.1.2
Re: [dev] surf rewrite for WebKit2GTK
duktape is a great find and appears quite complete. But still seems quite large. There's also Tiny-JS [0] (2k-ish LOC), 42Tiny-JS [1] (a forked, enhanced, more complete version), and Espruinio [2] (same original author as Tiny-JS, more complete but focused on Arduino applications). [0] https://code.google.com/p/tiny-js/ [1] https://code.google.com/p/42tiny-js/ [2] https://github.com/espruino/Espruino On Sun, Oct 26, 2014 at 11:23 AM, Anthony J. Bentley anth...@cathet.us wrote: F Hssn writes: On Sun, Oct 26, 2014 at 12:34 AM, Andrew Hills ahi...@ednos.net wrote: On 10/25/14 13:41, F Hssn wrote: Following suckless's minimal philosophy, I'd be interested to find out ... snip ... latest webkit. Do you really want to write your own Javascript engine? Well, I hadn't thought of that but now that you mentioned, I downloaded v8 and spidermonkey sources, 0.5 vs 1.2 million (both mostly C++). Then in v8 I noticed it has directories for architectures like arm arm64 mips mips64 ia32. I removed those directories and left only x87 and x64 and ended up with 333k, with 223k lines of C++ source files. To answer your question, I guess it comes down to how much time I have (as always) which is, not much. But I would definitely like some suckless cleanup in this direction, just like in other directions. Duktape isn't perfect but it's at least within the realm of sanity: http://duktape.org/ -- Anthony J. Bentley
