Re: [dev] Re: coreutils / moreutils - DC a directory counter
On mán 29.júl 2013 04:39, Paul Hoffman wrote: Their 100+ Perl and bash scripts are slow because they're opening files in a humongous directory. They can't subdivide the directory because they're afraid that they will break the scripts when modifying them. I posted a comprehensive comment on the blog post that has yet to be approved by the censor. In short, ext2/3 directories are linked lists. You can traverse said list in constant space and process each entry when you encounter it. O(n) time is unavoidable. Bash globs and ls listings are automatically sorted. Dash and ls -f or find . -type f don't. Switching to dash might result in all sorts of compatibility issues, but s/ls/ls -f/g is easy to test, and just might work. And then s/ \* / \$(ls -f) /g (assuming old regex, \n in $IFS). Dividing the directory into folders requires structural changes and just contains the scalability issue instead of just not sorting. Sorting does not only take up to O(n^2) time, but requires searching for every single entry in the linked list. That's equal to traversing half the list n times, instead of all of the list just once. http://ext2.sourceforge.net/2005-ols/paper-html/node3.html P.S. This just might be my favorite regex: s/ \* / \$\(ls -f\) /g.
Re: [dev] Re: coreutils / moreutils - DC a directory counter
On mán 29.júl 2013 11:38, Thorsten Glaser wrote: Are they, still? I thought they had the equivalent of UFS_DIRHASH nowadays… Ext4 does, optionally.
Re: [dev] [sbase] [patch v3] Add df(1)
On 07/23/2013 02:18 PM, Steve Dee wrote: BSD doesn't have mntent or /proc, but does have getmntinfo. I think we Well, FreeBSD has some sort of a /proc, even if intentionally incompatible with Linux.
[Resend?] Re: [dev] coreutils / moreutils - DC a directory counter
On 07/17/2013 06:13 PM, Calvin Morrison wrote: I rely heavily on unioned directories (go plan9!) so mine tend to get large when working with many large datasets. Does anyone use large directories often? Unices avoid large directories to scalability problems like the one you're trying to solve. Many programs and scripts are infrequently tested on large directories, in part because they're rare. Even the GNU coreutils test suite does not test against huge directories unless explicitly allowed to use tens of thousands of inodes. Which is at least once for every release candidate on every supported system. [OT] IIRC, an Ext4 explicitly does not care about ridiculously huge directories because common functions and syscalls will get mildly surprisingly slow when forced to go through large lists or trees of files. But I haven't tested anything myself. If you can make such an interface that performance problems can be implemented under hood, that would be terrific. But a dedicated utility for such a specific function that it's hardly going to be used in scripts has no place in moreutils. It would be nice to keep around somewhere, though. Package it with other file tree related functions/commands.
Re: [dev] [sbase] [patch] Adding tar v2
On 07/17/2013 01:52 PM, Markus Wichmann wrote: I do partially. That is, I usually list the archive before unpacking, but I don't visually scan each and every entry, because, for one, I use st, so no scrollback buffer (I refuse to run a terminal multiplexer in an environment, were it is never going to see more than one terminal), You can paginate without multiplexing your terminal. Also, using a fixed-width character grid makes sense only for running TUI programs that directly manipulate said grid. If you're just interacting with a shell, you should be using a simple I/O text window, with or without autocompletion.
Re: [dev] textwin
Well, there's gobject.io_add_watch, if you're ok with something that
sucks somewhat. Feel free to rewrite this in Tcl/Tk. Please, join #suckless.
import gtk,pygtk
import subprocess
import gobject
class CommandTextView(gtk.TextView):
def __init__(self,command):
super(CommandTextView,self).__init__()
self.command = command
def run(self):
proc = subprocess.Popen(self.command,shell=True,stdout=subprocess.PIPE)
gobject.io_add_watch(proc.stdout, gobject.IO_IN IO_OUT, self.io)
def io(self, fd, condition):
if condition == gobject.IO_IN:
char = fd.read(1)
buf = self.get_buffer()
buf.insert_at_cursor(char)
return True
elif condition == gobject.IO_OUT:
fd.write(â¦
else:
return False
def write(self, fd, condition):
def test():
win=gtk.Window()
win.set_size_request(300,300)
win.connect('delete-event',lambda w,e : gtk.main_quit())
ctv=CommandTextView(ls -l)
win.add(ctv)
win.show_all()
ctv.run()
gtk.main()
if __name__=='__main__': test()
Re: [dev] coreutils / moreutils - DC a directory counter
On 07/17/2013 06:13 PM, Calvin Morrison wrote: I rely heavily on unioned directories (go plan9!) so mine tend to get large when working with many large datasets. Does anyone use large directories often? Unices avoid large directories to scalability problems like the one you're trying to solve. Many programs and scripts are infrequently tested on large directories, in part because they're rare. Even the GNU coreutils test suite does not test against huge directories unless explicitly allowed to use tens of thousands of inodes. Which is at least once for every release candidate on every supported system. [OT] IIRC, an Ext4 explicitly does not care about ridiculously huge directories because common functions and syscalls will get mildly surprisingly slow anyway. But I haven't tested anything myself. If you can make such an interface that performance problems can be implemented under hood, that would be terrific. But a dedicated utility for such a specific function that it's hardly going to be used in scripts has no place in moreutils. It would be nice to keep around somewhere, though. Package it with other file tree related utilities.
Re: [dev] Re: coreutils / moreutils - DC a directory counter
On 07/17/2013 09:02 PM, Calvin Morrison wrote: So it seems a good deal of that time is ls Wait, sbase ls doesn't seem to implement -f. Are you sorting the directory entries?
[dev] Parentheses
Galos, David: The types array stood out to me as a bit of a code smell. After pondering over it for a couple of minutes, I realized that you could just do this: type = argv[1][0] == 'b' ? S_IFBLK : S_IFCHR; type = ((argv[1][0] == 'b') ? S_IFBLK : S_IFCHR)
Re: [dev] [sbase] sponge v2
On 07/02/2013 07:54 PM, Calvin Morrison wrote: If on any system other than linux, I would consider loading into ram, but because of memory overcommit, malloc never fails, the whole system crawls to a halt, and the oom killer takes 20 minutes to put everything back together. No thanks. Okay so you are discussing a problem with your version of unix and malloc, not with the tool sponge. This being sbase, the discussion should boil down to whether it's simpler to malloc or write and read. Writing data to a tempfile marks it for paging. If there's a simpler way to do that, or if that is in fact unwanted, tempfiles should be eschewed. You're just storing data into memory. Just tell the OS what you're doing, hand over the data and be done with it. The problem with mallocing large amounts of data is that malloc'd data is byte addressable, implying that for O_LARGEFILEs you need practically 64bit addresses, which on current machines can lead to (minor) performance penalties. This can be worked around simply by telling the OS that you don't need to be able to address all of the data at once: buffered write()s. So, if you ever need to pipe a multi-gibibyte file through a shell command on a 32bit machine, you want sponge to use tempfiles. Otherwise, you shouldn't care.
Re: [dev] Re: Why HTTP is so bad?
On 05/24/2013 08:47 PM, random...@fastmail.us wrote: You need_something_ monolithic to manage a linear (or, rather, branching only when you choose to, via open new window or new tab) browsing history, even if content viewers aren't part of it. When you click a link within the appropriate viewer, it needs to be_replaced_ with the viewer for the content at the link you clicked on. Are you describing (an evolution of) Rio? Web browsers sure have showed that window management is severely broken. Tiling solves the problem for low numbers of windows per view, but should become equivalent to iconification for as the number of windows grows out of hand. Freedom to be lax about tagging is absurdly convenient, if possibly unhealthy. Automatic tagging would probably be way too complicated, unless implemented by the Netsurf developers.* * http://www.netsurf-browser.org/documentation/guide#HistoryLocal
Re: [dev] Re: Why HTTP is so bad?
On 05/24/2013 02:11 PM, Christian Neukirchen wrote: Types can't be declared properly in Unix. In Unix, filetype are defined on a per file basis. Delimeters in IPC text streams are defined using $IFS. Rc is hailed exclusively because it makes less use if $IFS. Well, that and the Plan 9 label.
Re: [dev] Re: Why HTTP is so bad?
On 05/24/2013 02:35 PM, Strake wrote: It has saner syntax, too. In special, fewer quotation marks :)
Re: [dev] [dwm] Running dwm in KDE
On 05/21/2013 05:22 PM, Fernando C.V. wrote: Also instead of slim you can just add [[ $TTY == /dev/tty1 ]] exec xinit to your bashrc and get rid of the display manager completely. Wouldn't that be .profile?
Re: [dev] print utility
Do note that gres(1) lives on as replace(1). Replace is maintained by the MySQL team.
Re: [dev] print utility
On 03/31/2013 01:52 PM, Charlie Kester wrote: I'd read the file one character at a time, counting newlines, until I reached the desired line. [..] Doing it this way avoids the need for a buffer altogether, along with any guessing about possible line lengths. Reading is expensive. Loop through an optimally sized buffer and incrementally count newlines.
Re: [dev] print utility
On 03/31/2013 06:03 PM, Charlie Kester wrote: Why add this extra complexity when stdio is already buffering the input stream? I did not mean to imply double-buffering. In fact, I figured I should've linked to documentation on input streams seconds after I sent the mail.
Re: [dev] [PATCH] Changed the way title is set to support UTF-8.
On 02/22/2013 05:32 PM, Lukas Fleischer wrote: You can use `git send-email --annotate HEAD^` and add a prefix to the subject. Or just change the format.subjectprefix configuration value to something like st] [PATCH. Which is one reason why cluttering Subject sucks more than using Keywords.
Re: [dev] [dmenu][bug]cjk ime is unusable in dmenu
On 02/09/2013 03:57 AM, Daniel Zhang wrote: Do you know how to fixed it? I did some try but could not find where should be fixed. The offending function is grabkeyboard: XGrabKeyboard(dc-dpy, DefaultRootWindow(dc-dpy), True, GrabModeAsync, GrabModeAsync, CurrentTime). Try deleting calls to grabkeyboard, leaving readstdin() alone. But then you need to take care of input focus elsewhere, such as with a window manager.
[dev] Internet messages
lordkrandel wrote: If you do not care about their user base, and also do not care about integration with mail clients, just share a folder over 9p, FTP, HTTP or whatever. Thatt way combining multiple folders into superfolders becomes trivial. Unfortunately, browsing huge hierarchical folders sucks. Fortunately, files can be linked in multiple folders allowing simple expressions to filter messages: dev, !dev/st, !dev/OT whatwg, !javascript cnn, !cnn/US, cnn/US/military Arguably, one could just use full text search. But then one needs to throw keywords into the message itself, where they don't really belong. #vapourware #messaging #tldrHashTagsSuck
Re: [dev] Starch has a web site
On Thu, Dec 6, 2012 at 3:59 PM, Truls Becken truls.bec...@gmail.com wrote: The installation guideline suggests using the Arch installer. That's fine, but I'd just like to mention that I always found it fascinating how you can install Arch by booting any Linux system you have at hand (an existing installation or some live cd), download a static build of pacman, mount the partition you want to install on, and simply run; ./pacman -S base -r /mnt For the record it should be noted that Debian can be installed similarly using the debootstrap sh or C program. Unfortunately, debootstrap is distributed as a deb, which is a gzipped tarball inside an ar. Whic is OK, unless you can't get hold of the ancient ar extractor. In short, static binaries are wonderful.
Re: [dev] I'm back
On Sun, Nov 18, 2012 at 11:10 AM, Felix Janda felix.ja...@posteo.de wrote: On 11/18/12 at 07:00am, Jens Staal wrote: Each application gets its own directory under /opt and then installed files get symlinks in / (the file system hierarchy is stali-inspired with everything in root and usr just pointing back to root). [snip] djb had a similar idea with his slashpackage system. It doesn't seem to have caught on much, tough. GNU Stow also.
Re: [dev] Re: I'm back
On Sun, Nov 18, 2012 at 2:32 PM, hiro 23h...@gmail.com wrote: tinycore also links all files of mounted squashfs mounts into the /usr/local. That kind of hack is more simple than stuff like unionfs. With replacements being written into /usr? I prefer the indirection being behind a standard and consistent API, instead of requiring applications to crawl $PATH every time. But as we seem to be stuck with $PATH for a while, this might be an OK hack.
Re: [dev] Troff for typsetting e-mails
Christoph Lohmann wrote: as the subject says, I’m thinking of typesetting my e‐mail in troff. I have never done that; I use plain UTF-8. But are you talking about writing email in troff and converting it to HTML? Or what makes email special, aside from the convention to use plain text instead of typeset?
Re: [dev] Hide border in monocle mode
On Tue, Oct 23, 2012 at 09:53:58AM +0300, Daniel Bainton wrote: On 23 October 2012 00:31, Bjartur Thorlacius svartma...@gmail.com wrote: Attached is a unified patch against tip for hiding the border of clients when in monocle mode. A border is still drawn when in tiled mode, even if there's only one client visible. That's unuseful but as a passive reminder of the current mode. This behaviour is a compromise stemming from the border drawing handler being less accessible. The patch is makes the same change to both resizeclient() and configure(). This is especially awkward considering that resizeclient() calls configure(). Why didn't you just use the noborder patch in the wiki? It's called lazyness. My patch is not even complete. Frankly, my message was equally a remark about the seeming redundancy in configure() and resizeclient(). And please read your patches before sending them, this includes your personal config.mk changes. My bad.
[dev] Hide border in monocle mode
Attached is a unified patch against tip for hiding the border of clients when
in monocle mode. A border is still drawn when in tiled mode, even if there's
only one client visible. That's unuseful but as a passive reminder of the
current mode. This behaviour is a compromise stemming from the border drawing
handler being less accessible.
The patch is makes the same change to both resizeclient() and configure(). This
is especially awkward considering that resizeclient() calls configure().
diff -r c794a9f5ae5e -r fcdacab99af2 config.def.h
--- a/config.def.h Sun Jul 08 09:45:53 2012 +0200
+++ b/config.def.h Mon Oct 22 21:17:23 2012 +
@@ -33,9 +33,9 @@
static const Layout layouts[] = {
/* symbol arrange function */
- { []=, tile },/* first entry is default */
- { , NULL },/* no layout function means floating behavior */
- { [M], monocle },
+ { True, []=, tile },/* first entry is default */
+ { True, , NULL },/* no layout function means floating behavior */
+ { False, [M], monocle },
};
/* key definitions */
diff -r c794a9f5ae5e -r fcdacab99af2 config.mk
--- a/config.mk Sun Jul 08 09:45:53 2012 +0200
+++ b/config.mk Mon Oct 22 21:17:23 2012 +
@@ -21,7 +21,7 @@
# flags
CPPFLAGS = -D_BSD_SOURCE -D_POSIX_C_SOURCE=2 -DVERSION=\${VERSION}\ ${XINERAMAFLAGS}
#CFLAGS = -g -std=c99 -pedantic -Wall -O0 ${INCS} ${CPPFLAGS}
-CFLAGS = -std=c99 -pedantic -Wall -Os ${INCS} ${CPPFLAGS}
+CFLAGS = ${CPPFLAGS}
LDFLAGS = -s ${LIBS}
# Solaris
@@ -29,4 +29,4 @@
#LDFLAGS = ${LIBS}
# compiler and linker
-CC = cc
+CC = tcc
diff -r c794a9f5ae5e -r fcdacab99af2 dwm.c
--- a/dwm.c Sun Jul 08 09:45:53 2012 +0200
+++ b/dwm.c Mon Oct 22 21:17:23 2012 +
@@ -121,6 +121,7 @@
} Key;
typedef struct {
+ Bool showborder;
const char *symbol;
void (*arrange)(Monitor *);
} Layout;
@@ -479,7 +480,7 @@
void
cleanup(void) {
Arg a = {.ui = ~0};
- Layout foo = { , NULL };
+ Layout foo = { True, , NULL };
Monitor *m;
view(a);
@@ -564,7 +565,10 @@
ce.y = c-y;
ce.width = c-w;
ce.height = c-h;
- ce.border_width = c-bw;
+ if(c-mon-lt[c-mon-sellt]-showborder)
+ ce.border_width = c-bw;
+ else
+ ce.border_width = 0;
ce.above = None;
ce.override_redirect = False;
XSendEvent(dpy, c-win, False, StructureNotifyMask, (XEvent *)ce);
@@ -1367,7 +1371,10 @@
c-oldy = c-y; c-y = wc.y = y;
c-oldw = c-w; c-w = wc.width = w;
c-oldh = c-h; c-h = wc.height = h;
- wc.border_width = c-bw;
+ if(c-mon-lt[c-mon-sellt]-showborder)
+ wc.border_width = c-bw;
+ else
+ wc.border_width = 0;
XConfigureWindow(dpy, c-win, CWX|CWY|CWWidth|CWHeight|CWBorderWidth, wc);
configure(c);
XSync(dpy, False);
Re: [dev] [st] toggle font
On Tue, Oct 16, 2012 at 06:25:40PM +0200, Roberto E. Vargas Caballero wrote: Surely, it would be better to use a separate control input stream, stdctl (or nstdctl), for configuration. Are you talking about keep, for example, file descriptor 3 for control operations? Yes.
Re: [dev] [st] toggle font
Edgaras wrote: On Wed, Oct 10, 2012 at 09:28:33PM +0100, Nick wrote: Quoth Roberto E. Vargas Caballero: I also need this feature, but maybe could be done in other way. I talked about this with other persons of the list, and we liked let st be configured using the stdin of st, so you can do it something like: configurator | st And, for example, you could use dmenu and select the font you want to use. Eugh. That isn't the way anything else is configured. It's a pretty weird interface. config.h, argv switches and potentially keybindings are reasonable ways to configure programs. stdin is just silly. I wouldn't say that. I would say it depends very strongly on the application. For example for quite some time I have an idea of general key-binder, something like xbindkeys, except that it would not read any config files, but it would read configuration from stdin. This would allow simple key rebinding while application is already running without introducing inconsistent configuration loadings, i.e. from file and then some other way for rebinding on the fly. What I want to say that stdin for configuration/commands/options for (maybe just certain)gui applications can be a nice option (obviously for cli applications that is not the case, because there stdin is main input for data). Surely, it would be better to use a separate control input stream, stdctl (or nstdctl), for configuration.
Re: [dev] Hall of shame of the web
hiro wrote: that hall of shame is called google. we should all get back to using gopher or telnet. Yes. Because Gopher and Telnet are superior to HTTP and SSH. /s
Re: [dev] Hall of shame of the web
mrpantou...@upyum.com wrote: What do you mean by « all the plug-ing » ? Only Flash or would you like to include Silverlight, VLC… ? All the plugins the page requests, presumably.
Re: [dev] any update on stali?
On Mon, Aug 27, 2012 at 8:55 PM, Strake strake...@gmail.com wrote: * diversify architecturally, e.g. i686, Loongson Why Loongson?
Re: [dev] sfeed: a simple RSS and Atom parser and reader
Hiltjo Posthuma wrote: I would like to announce a simple RSS and Atom parser and reader I've been working on. [snip] - easy to sync your feeds TO THE CLOUD ;P I don't think rsync depends on an Atom parser. Or are your referring to some Atom PubSub magic?
Re: [dev] Starting surf automatically after webserver has started
On Tue, Jul 17, 2012 at 2:20 AM, Amit Uttamchandani amit.uttamchand...@my.csun.edu wrote: Hello, I would like to have surf start up when the webserver on the system has started up. Right now, surf starts up but the webserver starts up after surf. Thus, when surf loads there is a 404 not found error. A manual refresh has to be performed. I played around with init.d in debian but not sure what the proper way is. Adding a delay seems to be a hack. Is there a way to signal surf to start? Yes. You have to declare to your init that surf depends on httpd. Consult the documentation for your init or consider installing a simpler init to start services in the correct order. FYI, I have no idea where the current best practices for writing service description files in init.d on Debian systems, but I do think you are supposed to put httpd in one or two of the LSB headers in /etc/init.d/surf; one to declare that surf is to start after httpd, and optionally one to declare if surf is to stop before httpd.
Re: [dev] Starting surf automatically after webserver has started
The init systems of the mainstream distros are terribly broken in the name of 'easy' modification. I would love having the core boot script compiled into a single executable from a simple shell script of s, s, ;s and |s. Rc might be a good choice for the glue as a language easily learnt in minutes by anyone that knows sh. It could call programs written in languages that can perform syscalls without spawning a new process, such as tcpserver. The compiled would probably be linked to 'run' in a directory of its own, for use by supervise.
Re: [dev] Re: Digest of dev@suckless.org issue 186 (12070-12119)
On Tue, Jul 17, 2012 at 9:13 PM, Kurt H Maier khm-suckl...@intma.in wrote: On Tue, Jul 17, 2012 at 07:52:06PM +0100, Deric Bytes wrote: Unsubscribe No. Like
Re: [dev] fceux in fullscreen
On Tue, Jul 3, 2012 at 9:32 PM, Manolo Martínez man...@austrohungaro.com wrote: On 07/03/12 at 06:36pm, Bjartur Thorlacius wrote: Can you verify that the rectangle is in fact not a new top-level window but an in-window artifact of SDL by logging window mapping requests in your X11 server. Is the attached patch what you meant? (Sorry, my C is very basic). I meant to suggest patching Xorg, but this zorks just as well. If it is, when I open new windows they do leave a XID at my /tmp/errores.txt file but, interestingly, fceux does not. Not even the tiny floating window, let alone the fullscreen version. I don't know what fceux is, nor do I know how SDL works. I do have a hunch that the black rectangle is a hack fceux' SDL uses to obscure other windows (so they won't repaint themselfes), or some pseudo-input-only (with output) to get around some limitation in X11 instead of using proper input-onl windows. It's entirely possible that I have misinterpreted your instructions, though. Let me know if that's the case. This got me the information I wanted, even if by slightly differently from what I had in mind. I don't understand why exactly fceux creates this window, though.
Re: [dev] [dmenu] multiple menu patch
Have you considered multisel? http://tools.suckless.org/dmenu/patches/multisel http://tools.suckless.org/dmenu/patches/multiselect_and_newline
Re: [dev] fceux in fullscreen
On Tue, Jul 3, 2012 at 4:51 PM, Manolo Martínez man...@austrohungaro.com wrote: Also, this square is slightly bigger than the unmaximized fceux, so I don't really know where is that coming from. How can I get it out of the way? Please send us the output of running xprop and clicking on the black square, and then for running xprop again and clicking on fceux itself. If the outputs are vastly different (in special, if _NET_WM_TITLE or WM_TITLE differ), you can try running xkill and clicking on the black square. If they're identical (aside from *TIME), this must be a bug in fceux.
Re: [dev] fceux in fullscreen
On Tue, Jul 3, 2012 at 5:56 PM, Manolo Martínez man...@austrohungaro.com wrote: None of that works: dwm keys are, as I say, unresponsive in fceux fullscreen. When trying sleep + xprop, xprop complains that it can't grab the mouse. Can you verify that the rectangle is in fact not a new top-level window but an in-window artifact of SDL by logging window mapping requests in your X11 server. Something like the following Pseudo-C snippet, or preferably a gdb trace, should do the job. | case MapRequest: [..] | fprintf(stderr, XID:\t%i, Req-Window); | break; The XID, if it's a top-level window, can than be input as an argument to xprop or xwininfo. Sorry if I'm just being thick! You're most likely not, this seems quite bizarre.
Re: [dev] Systems Software Research is Irrelevant
On Tue, Jul 3, 2012 at 5:39 PM, Kai Hendry hen...@iki.fi wrote: On the topic of odd finds, anyone heard of http://code.google.com/p/es-operating-system/ ? Yeah, but didn't think anyone would go out and write a new CSS HTML rendering engine for it to run JavaScript interactive hypermedia applications on it. I think I'll stay on the Francophonic side of the German border for a while now, in case the Suckless van hasn't run permanently out of gas yet. The included browser evidently has Acid2 support That was intentional, so it doesn't guarantee conformance though.
Re: [dev] Systems Software Research is Irrelevant
On Tue, Jul 3, 2012 at 7:27 PM, Kurt H Maier khm-suckl...@intma.in wrote: As we realize ECMAScript/Web based applications are becoming very important and useful, ES operating system has been designed to make the Web Apps APIs as the primary operating system interfaces, JavaScript is becoming fairly standard for some things. In fact my current mail client (which I use when on someone's else Windows box), Gmail, is more usable than mutt - if you've got more than a couple hundred million bytes of main memory to spare. Err, make that more than triple hundred million bytes. Wasteful? Yes. Still got almost half of my main memory free, though. Computer manufacturers gotta make money somehow. ;)
Re: [dev] suckless document generator for C code
On 5/11/12, Amit Uttamchandani amit.uttamchand...@my.csun.edu wrote: The problem right now is the APIs are kept in a MS Word Office 2010 .docx file, which doesn't work right with LibreOffice. I smiled - `til I realized you weren't joking.
Re: [dev] Multimedia keys doesn't send proper keycodes
On Fri, 20 Apr 2012 21:38:01 -, Carlos Torres vlaadbr...@gmail.com wrote: the wonders of execve At least it doesn't try to interpret anything in the filename but control characters. -- -,Bjartur
Re: [dev] [ii] exposed password on process monitoring
On Fri, 20 Apr 2012 00:37:40 -, Nico Golde n...@ngolde.de wrote: * Ivan Kanakarakis ivan.ka...@gmail.com [2012-04-20 01:54]: I think a nice thing to do that would also resolve the naming choice would be to have -k or some other argument mean that ii should read the -k flag as an env var. so $ ii -k IRCPASS would getenv(IRCPASS), and $ ii -k OFTCPASS would getenv(OFTCPASS) etc I agree this is actually also a very nice solution! I will think about that a little before I commit. Environment variables are of course also visible using ps (probably ps e or ps -e, depending on your system, but I'm not on a unice to test atm). I don't think, however, that they're leaked on any modern Unix starting with Solaris 9. Given this lists fetish for esoteric systems, we should tread carefully and test before making choices. I recommend using regular files whose permissions are better understood. But then again, files are usually world-readable by default whereas environment variables nowadays are not, so environment variables make at least equal sense. [Note to self: Party, not write, after eleven o'clock.] -- -,Bjartur
Re: [dev] Multimedia keys doesn't send proper keycodes
On Tue, 17 Apr 2012 19:41:33 -, Arian Kuschki arian.kusc...@googlemail.com wrote: or use xbindkeys to bind those keys, e.g. Or speckeysd. -- -,Bjartur
Re: [dev] st utf8 printing
On 4/13/12, Connor Lane Smith c...@lubutu.com wrote: vim *is* a GUI. It's not a line editor, is it? libcurses is a GUI toolkit too, it just happens to abstract over the hack that is ANSI escapes. The curses version is a TUI; it uses characters rather than arbitrary icons or drawing graphics.
Re: [dev] fix numlock bug
On 4/13/12, Nikolay G. Petrov r...@dir.bg wrote: When my numlock is active, I can't switching under different workspace or start the terminal,or by press on mouse button, nothings works! When I switch off numlock, all is ok. Where in source code I can fix that? Try stepping through updatenumlockmask() and checking the value of unsigned int numlockmask.
Re: [dev] [dwm] drop the bars (was: systray in upstream dwm?)
On Saturday 07 April 2012 12:13:43 Jan Christoph Ebersbach wrote: I wonder how these kind of patches can be done in a better way. It's clear that including a systray in dwm is not a good idea but it is also not possible to work around the bar included in dwm. I want to see the mode my tag is in, the selected tags and the name of the current window. If there were a way to present this information to an external program, the bar wasn't necessary anymore. Xft and Systray would be implemented by a separate program and all the fruitless discussions about the visual stuff, would come to an end. What about going to the other extreme: dwm should draw what it needs to draw and /nothing/ else. On most displays, dwm doesn't need a sw wide bar. Instead, it could reserve the rest of the status bar area for small WINDOW_TYPE_DOCKs.
Re: [dev] [dwm] drop the bars (was: systray in upstream dwm?)
On 4/10/12, Jan Christoph Ebersbach j...@e-jc.de wrote: Sounds interesting but since there is no way of communicating with dwm we wouldn't gain much. The code for bars and keybindings would also stay. I'm rather for going the whole way. Yeah, dwm would still have to draw tag names/icons itself. But do we need fancy drawing libraries to represent tags, or do we want them to draw misc. other stuff such as a systray, a battery charge indicator, window titles or tail -f? This compromising seems unnecessary and smells like design by committee. The correct solution is not using a library that's heavier than strictly necessary but not quite satisfactory for all use cases. And neither is doing the same, but through 9P. Yes, we love Plan 9, but 9P is native to neither Lunices nor BSDs. 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.
Re: [dev] [slock] Issue with shadow passwords and NIS
On 4/7/12, Ben Secrest blsec...@gmail.com 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. Slock should use a high-level authentication interface that will perform whatever authentication the site administrator requires. How much does this list hate or love PAM?
Re: [dev] dmenu idea and diff, Ability to set menu width
I wasn't suggesting resizing it depending on the match, but resizing it to the given font metrics for the longest item read from stdin instead (only once at the start of dmenu). Most simply, dmenu would be as wide as the screen.
Re: [dev] [dwm] Why am I having a gap between the master window and the others?
Þann fim 16.feb 2012 20:08, skrifaði pmarin: Now a new question arose. Which applications need to have resizehints set to True? MPlayer, for example.
Re: [dev] Adventures with static linking
On Feb 14, 2012, at 7:26 PM, Paul Onyschuk wrote: # find / -name *.so* | xargs rm But, think of the hyphens! Not that this should cause any trouble with existing rm implementations, but you'll never know what syntactic extensions GNU might come up with for userspace in-rm chroot filesystem hierarchies.
Re: [dev] Adventures with static linking
Thanks for a great reading. :) On Feb 14, 2012, at 7:26 PM, Paul Onyschuk wrote: I compiled almost whole Xorg (statically linked) from pkgsrc. Only missing part is xkeyboard-config, which depends on intltool. Intltool requires XML Parser module for Perl. I used static build of Perl, so dynamic module can't be loaded. I'll look into this later (compiling in XML Parser into Perl binary). Do you intend to compile all modules you might use into a single perl binary? Or just enough to compile stuff, and then stick to shell scripts and Lisp?
Re: [dev] Environment variables
On Sun, 12 Feb 2012 12:09:44 -, Christoph Lohmann 2...@r-36.net wrote: Some of you might be more experienced in the old Unix ways and might know how in the good old days all the environment variables were standardized. What I am up to: There are these new stylish ways of running applications based on their file extensions or mime types, which is annoying and leads to many symlinks. Instead some environment variables do exist. But maybe history has evolved some other substandards than I know? Bind mount or symlink. Do not construct pathnames from environment variables. mount -o bind /usr/bin/vim /bin/editor In fact, the /etc/alternatives mess of Debian would be acceptable, if it were not for the symlinks from /usr/bin to /etc/alternatives. They're forced to do that, however, because of the way $PATH works. In this regard, Plan 9 sucks less than Unix. -- -,Bjartur
Re: [dev] Suckless OS (was About escape sequences and stuff)
On Sat, 11 Feb 2012 20:32:16 -, Jonathan Slark jonathan.sl...@gmail.com wrote: Has the suckless community considered starting an operating system from scratch? Linux/BSD etc suck by default as they are evolutions of software from the 1970s and have all the legacy baggage that comes with that. Even Plan 9 dates back to the 1980s. The only new OS's that seem to be in development are based on existing software: Haiku, ReactOS etc. ...and GNU Hurd, Singularity, etc. All the real fun seems to happen in L4, but Plan9 is alive and kicking softly. -- -,Bjartur
Re: [dev] Hosting services for projects under public domain, ISC, MIT/X or BSD licenses
Thank you! Do you only accept software projects?
Re: [dev] [st] VT100 Emulation
Þann sun 5.feb 2012 09:02, skrifaði Christoph Lohmann: Why are we still emulating a 32 years old terminal? Because it works. s/works/breaks if you so much as use a variable width font
Re: [dev] [st] Handling of WM_DELETE_WINDOW atom
Þann fös 3.feb 2012 19:47, skrifaði Kurt H Maier: The ICCCM part is about clients with multiple top-level windows, which st isn't, and ewmh sucks. Yes, dwm should not strive for full ewmh conformance. Just because a part of the standard is idiotic doesn't mean we should ignore the whole of it. We should be as compatible and conforming as is sensible without sacrificing the core features of dwm. What's wrong with what ewmh says about deleting windows?
Re: [dev] [st] VT100 Emulation
Þann lau 4.feb 2012 23:05, skrifaði Kurt H Maier: There are already terminals that care about such bullshit; why write another?
Re: [dev] [dwm] Optional status bar
On Sat, 28 Jan 2012 15:28:24 -, Kurt H Maier khm-suckl...@intma.in wrote: This phrasing suggests an implicit approval of the way e.g. ewmh-compliant software handles docks. dwm handles docks perfectly fine -- it renders them like any other x window. if the dock doesn't like it, that is the dock's problem, not dwm's. Dwm creates a dock (status bar) of its own and manages unlike any other x window. Dwm is configured to use a menu that, rather than being managed like any other x window, requests exemption from window management. By your logic, if dmenu is not best rendered like any other x window than dmenu is broken, and so is the status bar. not supporting ewmh is not a fault, it's a design decision. A design decision moot by the very menu that dwm is configured for by default and maintained along with. Remove override-redirect from dmenu, and I'll believe this is a question of design. -- -,Bjartur
Re: [dev] [dwm] Optional status bar
On Sat, 28 Jan 2012 16:35:49 -, Kurt H Maier khm-suckl...@intma.in wrote: On Sat, Jan 28, 2012 at 04:01:09PM -, Bjartur Thorlacius wrote: Dwm creates a dock (status bar) of its own and manages unlike any other x window. Dwm is configured to use a menu that, rather than being managed like any other x window, requests exemption from window management. By your logic, if dmenu is not best rendered like any other x window than dmenu is broken, and so is the status bar. Your logic is inconsistent. The status bar and dwm are not 'managed unlike any other x window' because they are not managed at all. This is, in my opinion, a superior alternative to overengineering a ridiculous set of specifications to accomplish the simple things that dmenu and the status bar provide. ewmh is flawed because it presumes a specific interface paradigm. it provides nothing that dmenu or the status bar need that cannot be provided with override-redirect. Fair enough. Keyboard grabbing and override-redirect make dmenu multisel e.g. unusable for intermittent input. But as dmenu is intended to be short-lived, that use case is simply out of scope anyway. I have the right to fork dmenu and maintain the dock patch for dwm, so I'll stop complaining. -- -,Bjartur
Re: [dev] [dwm] Optional status bar
Þann lau 28.jan 2012 19:13, skrifaði Tom Vincent: Thanks for the discussion. It seems we can conclude targeting ewmh/icccm is out of the question. How about a new suckless protocol between dwm and its status bar? Much like dmenu handles launching, there's still scope in separating the status bar. Perhaps a compile-time option to disable it completely if nothing else? _NET_WM_TYPE_DOCK support and XEmbed tag switcher would do half the job. A XID would still have to be sent. Any more complicated protocol would have to go over DBus, which is not an option.
Re: [dev] [dwm] Optional status bar
Þann lau 28.jan 2012 19:13, skrifaði Tom Vincent: It seems we can conclude targeting ewmh/icccm is out of the question. For tag switching at least.
Re: [dev] [dwm] Optional status bar
Þann lau 28.jan 2012 22:40, skrifaði Suraj N. Kurapati: DBus is overkill. A named pipe or UNIX domain socket would suffice. I think even doing it the Xorg way would be an overkill. I'm in favor of splitting tagging into a separate program drawing to a subwindow of a panel. Some people use tagging, the dwm way, but others grouping into workspaces. A decision one way or another should not limit the choice of layouts. Layouts should be portable, at least as copyable source code files between dwm derivatives.
Re: [dev] [dwm] running rdesktop in full-screen
Þann fim 26.jan 2012 18:12, skrifaði Dennis Yurichev: I'm running rdesktop from terminal window with -f option meaning full-screen. But when I try to escape from it by pressing RCtrl-RAlt-Enter, rdesktop tries to change its window's geometry but can't, and stays in full-screen mode. Is there something I miss? Dwm keeps a fullscreen flag of every managed window. That flag is automatically set for windows of requested dimensions equal to those of the screen. I do not remember how or if that flag can be unset (without restarting dwm), but it might be bound to Mod1+Shift+t or Mod1+Shift+f. I have rarely managed to unfloat windows (a separate flag, but related) in dwm, so expect bugs. I suspect many dwm engineers just use monacle mode and hide the bar (Mod1+m Mod1+b). I haven't pulled in a while, so this message may or may not apply to tip.
Re: [dev] network usage graphs
On Thu, 26 Jan 2012 22:36:28 -, hiro 23h...@googlemail.com wrote: Thanks, this is the only valid answer, but now I have to install an other OS: -bash: ed: command not found How can debian/ubuntu folks be so ignorant?! aptitude install rc coreutils moreutils What use is bloatware such as ed when you have sed and sponge? -- -,Bjartur
Re: [dev] suckless vs. security? - Was: [slock] kill slock with Ctrl+Alt+Multiply
On Mon, 23 Jan 2012 11:04:55 -, Nick suckless-...@njw.me.uk wrote: On Mon, Jan 23, 2012 at 11:57:42AM +0100, hiro wrote: Security is not a feature. I thought you were restricting yourself to Sundays. Yes, on Sundays ;) -- -,Bjartur
Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply
On Sun, 22 Jan 2012 20:08:03 -, hiro 23h...@googlemail.com wrote: People used to take their steering wheels with them so that nobody drives their car away. So I think your approach should work. Perhaps you could take away the whole keyboard. It's very easy on my thinkpad. Only 7 screws away from perfect security. From now on I shall keep a steering wheel and a keyboard in my backpack. -- -,Bjartur
Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply
Does this actually go out and send a SIGTERM to the PID of the owner of the window, or merely destroy the window?
Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply
Þann fös 20.jan 2012 23:42, skrifaði Rob: On Fri, Jan 20, 2012 at 07:01:22PM +, Bjartur Thorlacius wrote: Surely it just destroys the window, you can't get a PID for any X window, since it could be a networked one As I expected. The PID is usually stored in a window property, as is the hostname, of every or most windows. But this is a flat out bug in slock. Slock should survive window destruction, right?
Re: [dev] One Border is Not Enough
This could be implemented as a gap between windows in tile(). Just offset
windows a few pixels more than {wh,ww} + 2*borderpx. Dwm.c is probably
more readable than the previous sentence.
--
-,Bjartur
Re: [dev] One Border is Not Enough
On Sun, 15 Jan 2012 12:02:01 -, Troels Henriksen at...@sigkill.dk
wrote:
Bjartur Thorlacius svartma...@gmail.com writes:
This could be implemented as a gap between windows in tile(). Just
offset windows a few pixels more than {wh,ww} + 2*borderpx. Dwm.c is
probably more readable than the previous sentence.
You'd also need to construct a border pixmap rather than the current
single-colour border. I'm not entirely certain how those are tiled,
though.
You could just use the root window. It's suboptimal, but works. Just set
the background color of root and let a glimpse shine trough between
windows. That way you don't need to put the double-border at edges of the
screen. IMO borders or gaps should only be between windows.
tl;dr Just draw the second border on the root window.
--
-,Bjartur
Re: [dev] One Border is Not Enough
On Sun, 15 Jan 2012 13:08:55 -, Connor Lane Smith c...@lubutu.com wrote: Your work is so mission critical that mistaking window focus being very unlikely is not enough? Well then, the only way to avoid such a mistake is to maximise every window (i.e., monocle mode); or more generally always placing the focused window at the same place. Master seems like a nice place. -- -,Bjartur
Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support
Þann sun 15.jan 2012 18:09, skrifaði Andreas Amann: The problem is that Ivan uses wmname to set _NET_WM_NAME to LG3D. Actually chromium does not care about _NET_WM_NAME. But wmname has a dirty side effect, it sets the _NET_SUPPORTING_WM_CHECK property of the root window to the window id of the root window. That is clearly against EWMH rules and it would be better if wmname would leave _NET_SUPPORTING_WM_CHECK alone. I guess Chromium for some reason is smart enough to figure out that _NET_SUPPORTING_WM_CHECK is not set correctly, and therefore seems to decide that it cannot trust the wm. The correct solution is therefore not to use wmname. Should we not patch wmname?
Re: [dev] [dwm] Tags vs Monitors
Þann fös 13.jan 2012 10:32, skrifaði Thomas Dean: This problem would come up if there was only one tagset and each monitor would be an independent view whose visible tags could be set independently. I rather meant that there should be only one tagset, and all monitors together would form a combined view, i.e. both monitors would always have the same set of tags visible. Each window should still be assigned a definite monitor. I'm sorry if my previous description was unclear, and hope that this one clarifies it. That sounds great. At that point I would in fact expect dynamic monitor assignment.
Re: [dev] interested in issue tracker dev
What's wrong with GNATS?
Re: [dev] wmii falling out of favor
Þann fim 5.jan 2012 23:12, skrifaði Connor Lane Smith: That's not inherent to GUIs, it just so happens that existing GUIs are extremely poorly made. It's not interaction which needs to be logged so much as the modification of persistent data -- files and such -- which could easily be logged by graphical apps. The more I think about it the more I believe terminals only continue to be used because of how awfully bad the alternatives are. That's not enough. I want the output of all commands (messages, documents, calculations, notes and error reports) to be stored on increasingly mainstream terabyte disks along with enough metadata to uniquely identify it. Modification is superseding a file with a derivation. Derivatives that do not supersede any other file need also be stored, whether they be drafts for future supersedes or files on their own.
[dev] Logging Commands
On Thu, 05 Jan 2012 14:19:00 -, David Tweed david.tw...@gmail.com wrote: I'm not aware of any way of either storing or, more importantly, searching a user's interaction with the GUI apps on a computer system. Some GUI programs such as Netsurf log user actions for later inspection.[1] GNOME Zeitgeist is also interesting in this respect, although their pride of running in under 10mb RAM is a fair complaint on this list. Unless they've actually invented centibit random-access memory, in which case I would grudgingly consider it acceptable. For those of you that stick to lynx no matter what, Netsurf represents visited pages as thumbnails in a tree, as opposed to lines of text. 1: http://www.netsurf-browser.org/documentation/guide#History
Re: [dev] [surf] make error
On Wed, 04 Jan 2012 20:28:20 -, Hannes Blut blut.han...@googlemail.com wrote: In file included from /usr/include/webkit-1.0/JavaScriptCore/JavaScriptCore.h:30:0, from surf.c:20: /usr/include/webkit-1.0/JavaScriptCore/JSStringRefCF.h:30:43: fatal error: CoreFoundation/CoreFoundation.h: No such file or directory compilation terminated. Where is CoreFoundation located? -- -,Bjartur
Re: [dev] monsterwm - 700 SLOC dwm fork
I love suckless' facility for coralling all the nitwits into one self-contained forum. It just sucks when some of the retardation leaks out into the real world. T,FTFY The real world is still safe. You're not.
Re: [dev] dwm in Deus Ex 3 concept art
On Sun, 25 Dec 2011 08:23:36 -, Suraj N. Kurapati sun...@gmail.com wrote: I recently finished playing Deus Ex 3 and while reading about its development, I found this DWM reference in a concept art poster: http://www.stuffwelike.com/stuffwelike/wp-content/uploads/2008/11/deusex3_169801.jpg For all we know it could refer to Desktop Window Manager (the window compositor of Windows 6). -- -,Bjartur
Re: [dev] wmii falling out of favor
On 12/24/11, Connor Lane Smith c...@lubutu.com wrote: I'm not sure a screenshot is necessary. It would just be a fullscreen window. :p If you hide the status bar it's honestly *just* the window. And a border, telling you whether it is focused or not (assuming a non-zero borderpx).
Re: [dev] network usage graphs
On 12/25/11, Anthony J. Bentley anthonyjbent...@gmail.com wrote: On 12/24/11, Szabolcs Nagy n...@port70.net wrote: * hiro 23h...@googlemail.com [2011-12-24 02:00:47 +0100]: sed -i 1d original.dat That’s a GNUism. What about $(rp sed 1d original.dat) ;) To address the original (-er) question, I think moreutils sponge(1) is the answer, filename duplication notwithstanding. % sed 1d original.dat | sponge original.dat
Re: [dev] wmii falling out of favor
On Fri, 23 Dec 2011 10:34:35 -, hiro 23h...@googlemail.com wrote: I kill dwm when I've placed all my windows correctly so I can save more RAM. I actually did that the other day, so I could GIMP my Christmas cards.
Re: [dev] [wmii] widgets with graphics?
On Thu, 22 Dec 2011 13:44:54 -, dtk d...@gmx.de wrote: is there a way to have widgets in the status bar display images instead of utf8 symbols? s/(image|symbol)/glyph/g Modify your font. There are patches either on the website or on the Archlinux Forums that modify dwm to use more powerful font rendering code. If you really like wmii, you might even port it. -- -,Bjartur
Re: [dev] sbase ls patch
Tiny cleanup patch. Now more memory is allocated than necessary. Is that a good thing or a typo?
Re: [dev] simplyread
Even if HTML5 were the only standard around, people would still misuse it untill you guys enable me to one-click-slay (TM) them. Of course, all seducers of the masses, potential tyrants or fanatics, have used this argument to make their case; the communists did the same when they declared themselves the most enlightened segment of the population, and, by virtue of this alleged enlightenment, arrogated to themselves the right to rule arbitrarily. - Václav Havel I know you were kidding, but I couldn't resist.
Re: [dev] simplyread
On 12/19/11, hiro 23h...@googlemail.com wrote: It's a good quote that I think I had yet to see. But I knew the communists also used such unique methods. It was taken out of the context of an article found on Al Jazeera arguing that people should be dictated by benevolent intellectuals ethically ignorant of contemporary and local problems that don't brainwash people through news media. Oh, the idealist ignorance of the nature of humans. Shortly after my last post yesterday I heard there's a book now (about 300 pages I think) about how mankind overall got less violent. It should be clear to anyone that only the recent technological breakthrough of HTML5 and it's extensions (one-klick-slay being the most recent) made possible the currently widespread goodness. I forwarded your email to Amazon. The patent has been granted. On a more serious note, lets all thank the USA DoD for their worldwide suppression of violence¡
Re: [dev] simplyread
On 12/18/11, hiro 23h...@googlemail.com wrote: I would approve if the existence of HTML5 meant anyone using the older HTML4 features got killed. Most of the novelties of HTML5 are complementary to the elements of HTML 2 and 4. HTML3 Plus was documentation of a bunch of bells and whistles implemented by commercial web browsers of which every copy should be burned, twice. Sadly, the scripting interface defined by HTML5 is defined pretty much the same way as the elements of HTML3 Plus were, but executable code in documents is bound to suck anyway. Next I would demand communism. After you've shot all writers of HTML 4, lawyers, politicians, programmers and designers? And expect people to listen to and support your political theories?
Re: [dev] what's your opinion on Go
On Tue, 13 Dec 2011 10:34:50 -, Hadrian Węgrzynowski hadr...@hawski.com wrote: C is the king and Go is the prince. Go needs to be more stable/mature, then it will be the king. Then what is D? I guess the answer will be the same as for Haskell. + D is the best of C and Python modulo compatibility and popularity. Unlike lisp, most any programmer can read it. -- -,Bjartur
Re: [dev] simplyread
I don't know if this is something you should add into stock simplyread, but my suckless stylesheet columnates text to make it readable on wide screens without too much paging. I reckon Webkit is able to columnate text. I used a column-count dependent on viewport width, but Opera doesn't rematch media queries on resize so it never quite worked correctly. But I still felt it enhanced readability. -,Bjartur
Re: [dev] Shameless patch request
On Wed, 07 Dec 2011 18:03:44 -, ilf i...@zeromail.org wrote: On 12-07 11:04, Justin Pogue wrote: At work, I typically have a terminal doing something like while true; do ls -l /var/cores sleep 10 clear; done, and it bugs me that I'm taking up so much screen space with things like that when all I need to be able to see is whether or not there are any files being created there. All I need is 2 or 3 lines of output. Script it and put the output to dwm status bar via xsetroot. Upon dnotify or inotify, then. -- -,Bjartur
Re: [dev] [dwm] Useless Gaps Are Useful
On 12/3/11, Bastien Dejean nihilh...@gmail.com wrote: In my opinion, the concept of gap between frames should be part of dwm. The existing patches are not solid enough. Having no gaps (the current situation) is just a particular case. I consider gaps between frames as a valid and preferable substitute for borders. I despise borders adjacent to monitor edges, especially in monocle mode, where borders serve no purpose. I do have code somewhere in another town, but the patch is trivial enough.
Re: [dev] [dmenu] No x, y, w options?
On 12/3/11, Bastien Dejean nihilh...@gmail.com wrote: Well, it's useful when one wants to (properly) place dmenu at the optical center of the screen and eventually add some incredibly necessary margins. Which is exactly what _NET_WM_WINDOW_TYPE_DIALOG is for. Note that doing this in the WM is the only way to do decoration (or preferably lack thereof), placement and sizing consistently. Just because dwm lacks support for many window types doesn't mean window types are inherently evil.
Re: [dev] [dmenu] Keyboard focus
On 12/3/11, Peter John Hartman peterjohnhart...@gmail.com wrote: Why would you move the mouse and not expect it to refocus things? Esp. since this is how it works everywhere else? To be fair, sloppy focus is generally surprising and annoying if you ever move your pointer. Reaching out for your mouse only to change focus and not sending any ButtonPress events is not a valid use case. If you are a keyboard-only user, focus windows using keyboard shortcuts (either using shortcuts assigned to applications/windows or by repeated Alt-(Shift)-Escaping/^jk). If you are a mouse user (on suckless?), then saving the click on the text box may be mildly convenient. But for any window not keyboard driven, you are likely to wish to click something anyway. Thus it seems keyboard-only users that may or may not interact with windows that expect ButtonPress events could be more productive under a focus-follows-click policy (where focus is changed upon ButtonPress events, but they still allowed to reach the clicked window) or a mouse-agnostic focus policy where focus change is incited by windows or keyboard only.
Re: [dev] [dmenu] No x, y, w options?
Why choose window placement and dimensions at exec, instead of letting the window manager handle the issue? Just set _NET_WM_WINDOW_TYPE to _NET_WM_WINDOW_TYPE_DIALOG and spend engineering time ranting about WM_TRANSIENT_FOR, modality and modularity instead. dmenu's override-redirect flag has always annoyed me, as well as grabbing the whole keyboard rendering it temporarily unusable for anything but typing text into dmenu or escaping out of it.
Re: [dev] Re: dmenu's lsx binary naming conflicts with lrzsz!
On Mon, 28 Nov 2011 14:43:55 -, Christian Neukirchen chneukirc...@gmail.com wrote: Connor Lane Smith c...@lubutu.com writes: On 28 November 2011 13:35, Christian Neukirchen chneukirc...@gmail.com wrote: Any reason we don't replace lsx with this? find -L . -maxdepth 1 -type f -perm -111 POSIX compatibility. All supported except for -maxdepth, but you can use: find -L . -type d \! -name . -prune -o -type f -perm -111 -print Reading this more closely yet sans documentation, should a '!' -name .. not be inserted into this monster of argument list, or better yet, the \! -name . be removed and find allowed to simply rely on -type f? Or does -type depend on stat?? -- -,Bjartur
Re: [dev] [dwm] Fullscreen programs in tile mode
IIRC dwm automatically floats windows the size of the screen (and F11 makes most windows resize to cover the whole screen) as well as windows with a fullscreen hint set. You can modify dwm.c to have fullscreen windows tiled by default.
Re: [dev] [dmenu] Keyboard Bindings
On Sun, 20 Nov 2011 19:28:14 -, Yoshi Rokuko yo...@rokuko.net wrote: i use dmenu only on url and program names, i used it for file names too, but my files do not have whitespaces, and i agree that typing 'hg ta' is much faster then 'hg.*ta', but i think one should not touch REGEXP(7) in a single program that is part of a toolkit ... you know what i mean. i am not talking about legacy support or change in general, i would love it if dmenu would support REGEXP(7) patterns. To me, regexp does not seem like a good expression language for matching IRIs and pathnames. First and foremost, pathnames are easily tokenized, rendering the power of regular expressions unnecessary. Secondly, pathnames often contain dots - and IRIs even more so. Reserving the dot is not an option IMHO. Would you ever use character sets or classes in dmenu? I most certainly won't. -- -,Bjartur
