Re: [dev] Lightweight UTF-8 library
On 14 April 2012 18:33, Connor Lane Smith wrote: > I've written a UTF-8 library based on Plan 9's libutf API, with a > bunch of improvements [1]. > > I've tested it on various correct and incorrect inputs and it seems to > be 100% Unicode compliant (unlike Plan 9), but if anyone finds any > bugs please tell me. > > Might this be useful to have on hg.suckless.org? Feel welcome to add it to the repos. Cheers, Anselm
Re: [dev] fix numlock bug
On 15 April 2012 08:15, Nikolay G. Petrov wrote:
> 14.04.2012 19:20, Bjartur Thorlacius написал:
> Try stepping through updatenumlockmask() and checking the value of
> unsigned int numlockmask.
>
> grep -i numlockmask dwm.c
First of all, which dwm version are you referring to?
Second, this grepping isn't exactly what Bjartur was suggesting. The
only relevant place to look for numlockmask is the function
updatenumlockmask() -- in the inner loop all the modifier keycodes are
OR'ed in. Check if in your setup this leads to the weird side-effect
that others can't reproduce.
However, judging based on your grep, makes me think you are not using
dwm's tip, correct?
>
> /*#define CLEANMASK(mask) (mask & ~(numlockmask|LockMask))*/
> #define CLEANMASK(mask) (mask &
> (ShiftMask|ControlMask|Mod1Mask|Mod2Mask|Mod3Mask|Mod4Mask|Mod5Mask))
>
> static void updatenumlockmask(void);
> static unsigned int numlockmask = 0;
> updatenumlockmask();
> unsigned int modifiers[] = { 0, LockMask, numlockmask,
> numlockmask|LockMask };
> updatenumlockmask();
> unsigned int modifiers[] = { 0, LockMask, numlockmask,
> numlockmask|LockMask };
> updatenumlockmask(void) {
> numlockmask = 0;
Cheers,
Anselm
Re: [dev] [dwm] strange issue with gedit and multiple screens
On 13 April 2012 19:12, Martti Kühne wrote: > after whining earlier on irc, I've got to put things straight here. > I have two monitors and most of the time I don't really care where the mouse > pointer is. using dwm with multiple monitors works great, as there is the > focusmon function, which I have assigned to a key to switch between monitors. > > The issue I was having with gedit was this: every now and then, gedit would > refuse to display a text cursor when I use the mouse to point, click and, at > the same time, get focus from a different screen. The only way of knowing > where > in the text the cursor was, was to blindly type something or press the > focusmon > key twice, which worked as a workaround for the issue. > > In the course of debugging this I also noticed the same can be achieved when > the focusmon key is used to switch to a window on the other screen and follow > with the mouse and come back again, returning focus to the screen where gedit > runs. Again, input is taken, blue border is drawn, but no text cursor is > shown. > > Well, I can imagine that it's easy to blame gedit for that inconsistency, > apparently qt applications do not suffer from this. > > Anyway, looking at dwm's codebase it isn't really clear when focus() is > called, > selmon is set and unfocus is called, and, focus() itself calls unfocus and > sets > selmon just in case. Needless to say, it made debugging a horrible task here. True, the focus handling is one of the most sucking parts of dwm and X ;) > I have tried quite a lot of things which ultimately lead to the desired > behavior, and then tested things hunkwise to find the culprit after all; > turns out it's my regular use of focusmon() which actually triggers the bug in > the first place; the change that solved my issues can be found in [1]. > > tl:dr; improve focus behavior of at least anjuta and gedit [1] Applied for now, looking forward that someone starts whining that the next X client is broken now. Cheers, Anselm
Re: [dev] [dwm] drop the bars (was: systray in upstream dwm?)
On 6 April 2012 07:41, Jan Christoph Ebersbach wrote: > Thank you Anselm for explaining the issue. From my point of view there > is no other way of implementing a proper systray for dwm as long as it > contains the bars and has no interface. > > Why don't we drop the bars and keybindings and let separate programs > handle it. There are also other patches like Xft that show that there is > a need for choice and extension. Building everything into dwm is not a > good idea, agreed. So let's create a proper interface for dwm that other > programs can use. The main issue with those interfacing approaches is, that it creates more overall complexity unfortunately. It might lead to a nice (but rarely usable) dwm core, but half of it would just implement one side of the interface, the other side would be implemented by a bunch of different programs. I've been there a couple of years ago with wmii, and the answer to this disaster was dwm. The status text area was a simple compromise after all, not the most elegant one, but one that seemed fairly simple for that matter and didn't require an interface. A while back I planned to separate the drawing code from the core, to make it easier to use Xft or pango or whatever, but this would also lead to some kind of interface that doesn't quite fit all the different technologies. The real fix for the unicode issues has to be done in Xlib itself imo. Cheers, Anselm
Re: [dev] [dwm] drop the bars (was: systray in upstream dwm?)
On 10 April 2012 22:11, Bjartur Thorlacius wrote: > I'm still in favor of separating tiling from tagging, so you could > e.g. use dwm's grid with 2wm's dual-stack without having to hand-merge > patches because the dwm patch references context not present in the > stereo window manager. > That way someone could just write an alternative fancy-pants Qt tagger > without bothering the rest of us—while providing us with a new option > if I ever figure graphical icons could better represent tags to humans > than textual labels. The ugly part then will be implementing the simple tagger around X properties... and dealing with the race conditions that input focus handling offers to us (occasionally the simple tagger will tag the wrong window). I'm not very keen about such a change of direction. Cheers, Anselm
Re: [dev] [slock] Issue with shadow passwords and NIS
On 7 April 2012 05:45, Ben Secrest wrote: > I'm not sure the best way to differentiate between the shadow vs. NIS > situation. One guess is that when shadow information is present, the > pw_passwd field of the passwd struct will contain 'x', '*', or > whatever the system uses as a placeholder in /etc/passwd. I added this kludge to slock for now, also waiting for someone showing up that is entry is \0 ;) Cheers, Anselm
Re: [dev] fix numlock bug
15.04.2012 13:36, Anselm R Garbe написал:
On 15 April 2012 08:15, Nikolay G. Petrov wrote:
14.04.2012 19:20, Bjartur Thorlacius написал:
Try stepping through updatenumlockmask() and checking the value of
unsigned int numlockmask.
grep -i numlockmask dwm.c
First of all, which dwm version are you referring to?
Second, this grepping isn't exactly what Bjartur was suggesting. The
only relevant place to look for numlockmask is the function
updatenumlockmask() -- in the inner loop all the modifier keycodes are
OR'ed in. Check if in your setup this leads to the weird side-effect
that others can't reproduce.
However, judging based on your grep, makes me think you are not using
dwm's tip, correct?
/*#define CLEANMASK(mask) (mask& ~(numlockmask|LockMask))*/
#define CLEANMASK(mask) (mask&
(ShiftMask|ControlMask|Mod1Mask|Mod2Mask|Mod3Mask|Mod4Mask|Mod5Mask))
static void updatenumlockmask(void);
static unsigned int numlockmask = 0;
updatenumlockmask();
unsigned int modifiers[] = { 0, LockMask, numlockmask,
numlockmask|LockMask };
updatenumlockmask();
unsigned int modifiers[] = { 0, LockMask, numlockmask,
numlockmask|LockMask };
updatenumlockmask(void) {
numlockmask = 0;
Cheers,
Anselm
dwm version: 5.8.2
OS: ubuntu last desktop (11.04)
Installing:
sudo apt-get build-dep dwm
sudo apt-get source dwm
(in this step I edit source, under my prefer settings)
dpkg-buildpackage
dpkg -i ../dwm*.deb
I'm not very good programmer under "c#" and without help think I don't
resolve the problem.
---
...in the inner loop all the modifier keycodes are
OR'ed in. Check if in your setup this leads to the weird side-effect
that others can't reproduce.
However, judging based on your grep, makes me think you are not using
dwm's tip, correct?
sorry, but I cannot translate and understand what do you mean!
Re: [dev] fix numlock bug
On 15 April 2012 13:10, Nikolay G. Petrov wrote: > dwm version: 5.8.2 > OS: ubuntu last desktop (11.04) > Installing: > > sudo apt-get build-dep dwm > sudo apt-get source dwm > > (in this step I edit source, under my prefer settings) > > dpkg-buildpackage > dpkg -i ../dwm*.deb Use dwm-6.0 or hg tip instead. We don't support 5.8.2 anymore. > I'm not very good programmer under "c#" and without help think I don't > resolve the problem. dwm is written C, not in C#. Please check if the problem is still present in dwm tip or dwm 6.0. Cheers, Anselm
Re: [dev] st utf8 printing
Am 14.04.2012 um 17:38 schrieb Connor Lane Smith : > But that aside, the distinction between TUIs and GUIs is completely > artificial. The only difference is that a "TUI" *cannot* display > images, even when it might be useful. I think you are wrong. An example for a TUI with images is w3m compiled with inline images. Regards, Joerg
Re: [dev] st utf8 printing
On Sun, Apr 15, 2012 at 5:02 PM, Joerg Zinke wrote: > I think you are wrong. An example for a TUI with images is w3m compiled with > inline images. I think, by definition, a TUI cannot display images. It becomes a GUI. --Andrew Hills
Re: [dev] st utf8 printing
Greetings. On Sun, 15 Apr 2012 23:33:00 +0200 Joerg Zinke wrote: > > Am 14.04.2012 um 17:38 schrieb Connor Lane Smith : > > > But that aside, the distinction between TUIs and GUIs is completely > > artificial. The only difference is that a "TUI" *cannot* display > > images, even when it might be useful. > > I think you are wrong. An example for a TUI with images is w3m com‐ > piled with inline images. Images in w3m are a huge hack[0]. W3m is spawning an extra process to do the whole X11 work, where it is simply drawing to the X11 window the xterm it is running in. There were proposals[1] to do graphics over ttys, but the web destroyed them in its advent. Regaining strength in such a technology first needs a working terminal for them and then applications using these proto‐ cols. With technical people floating directly into every new Apple gadget such a dream needs to be implemented in Go, using HTML5 and of course the first target is iTunes/AppStore compatibility. Sincerely, Christoph Lohmann [0] http://w3m.cvs.sourceforge.net/viewvc/w3m/w3m/w3mimg/ [1] http://home.comcast.net/~johnkwasnik/RIP/rip.html
Re: [dev] st utf8 printing
On 14/04/2012, Connor Lane Smith wrote: > the distinction between TUIs and GUIs is completely artificial. This. Furthermore, the distinction between text and graphic is totally artificial, and the distinction between natural and artificial is itself totally artificial (^_~) The former distinction is chiefly perpetuated by a moronic but woefully common scheme of programs who fake serial terminalhood to allow old programs written for such to work, and libraries to allow NEW programs to be written for such archaic hardware, which thus operate in the same sham world of limited runes and irksome input methods, while mighty graphics controllers sit idle. *WRATH* I quite hope for ivo. Cheers, strake
