Re: [dwm] musca wm

2009-05-15 Thread Brendan MacDonell

On Fri, 15 May 2009, Mate Nagy wrote:


Minimalism is a good thing to consider while developing software, but
obsessing about it is no better than with anything else. I'm as annoyed
with huge monstrous software like OpenOffice or Gnome or even Firefox as
anyone, but wanting to take away the features of the CLI userland that
make it comfortable is mad.
I was just about to write the exact same thing. However, coreutils could 
likely use some love to cut down on functionality duplicated across 
binaries, not to mention some extraneous options which few people ever 
use. In my opinion, it's about finding the balance between simplicity (so 
that people can hold the entire model of a command/utility in their head) 
and features (to allow users to achieve something without spending all of 
their time trying to fill in the gaps with awk.)



I say dwm (for example) is good because it's good, not because it's
suckless. The sucklessness is certainly part of its goodness, but not
all. If it was uncomfortable, would anyone use it? and it's still only
marginably usable with a multi-monitor configuration - proper handling of
this would require adding of this bloat everyone hates so much.
Exactly. dwm was largely well-adopted initially because there were no 
alternatives for dynamically managing windows. Since then, awesome and 
xmonad have largely poached the people looking for features and 
extensibility, while dwm has remained the ideal minimal core to play with 
and experiment on. People advocating for the recreation of cut-down 
versions of things just to be suckless fail to see that these will suck 
just as much, only there will be fewer useful _and_ extraneous features.


Take it from me: I hate Wirth's Law, and I try to implement minimal, 
well-specified utilities myself, but I try to do this in a way which 
_improves_ on existing models instead of wasting my time duplicating 
existing efforts.


Brendan MacDonell



Re: [dwm] Suckess Code Management

2009-03-14 Thread Brendan MacDonell
On Fri, Mar 13, 2009 at 4:46 AM, Amit Uttamchandani atu13...@csun.edu wrote:
 I just looked at vile...very cool app. Haven't figured out all the
 commands yet but I'm quite happy that it supports verilog syntax
 highlighting. Can you do vertical splits or file browsing within vile?
Vile unfortunately has no present vertical split capability, though
there is a file management interface via the hypertext capability
(which you has no default binding, so you have to bind in your vilerc)
and directory.pm via the perl interface if you use it. There are
apparently also some gdb and shell bindings via perl, but YMMV. I'm
afraid I don't know much more than that about it, because I've never
felt the need to make use of them.

 * TODO/Bug tracking/Notes: I keep track of my Todo list and other info
 with a 1.3KLOC (C++) utility I wrote to handle tagged notes from the
 command line. Maybe I'll get around to writing up a readme and
 releasing it soon.
 I'd very interested in this.
I'll see what I can do about finishing up the unit / integration tests
and releasing it. The only thing that makes me hesitate to do so is
the fact that someone will likely build a feature-comparable (albeit
slower for large databases and without the query DSL) version using sh
and grep. :-)

Brendan MacDonell



Re: [dwm] Suckess Code Management

2009-03-12 Thread Brendan MacDonell
I'll only bother to mention here what utilities/applications I use
that might be considered unusual, as repeating the same set of
browsers / chat clients / DCVS tools ad infinitum would likely become
tedious. Without further preamble, I think the following might be
worth mentioning:

* WM: a forked dwm-5.3.1 (I altered it slightly to allow process
management and on-the-fly reloading.)
* Shell: rc or bash, depending on whether I'm working heavily with
scripting or interactive use.
* File Manager: I've come to prefer the shell.
* Text Editor: vile. I prefer the statically compiled lexers for
syntax highlighting as it means that I never have to contend with the
limited context and broken highlighting caused by starting vim at a
line in the middle of a large function. The binary is still smaller
than vim, @ 1.4MB with all of the filters compiled in, and there's few
configuration files to load.
* TODO/Bug tracking/Notes: I keep track of my Todo list and other info
with a 1.3KLOC (C++) utility I wrote to handle tagged notes from the
command line. Maybe I'll get around to writing up a readme and
releasing it soon.
* Compilers: GCC/G++/Gambit-C (scheme).

Brendan MacDonell



Re: [dwm] Crash-only software

2009-01-14 Thread Brendan MacDonell
 What do you think about the concept of crash-only software?

While I'm certain that it's great for large, complex,
high-availability applications which infrequently write persistent
state to disk, I don't think it's of much use for small software
components. Such programs are unlikely to be able to architecturally
differentiate between micro-reboots and macro-reboots, not to mention
that the average consumer-grade application already supports
auto-saving and can start up cleaning in a short period of time - even
moreso for suckless programs.

  What about removing the running flag from dwm and replacing quit()
  with kill(pid)?

My interpretation of the original paper's statement that 'stop=crash'
was that a crash and a stop instruction are considered equivalent, ie.
that there is no path dedicated to storing resources on shutdown which
would be unavailable in the case of a crash, and not that an
application should have no method to cleanly exit and require the use
of kill. The collection of articles seems to imply that 'crash-only'
refers to the usage of rebootable components and frequent saving of
persistent state to cope with errors instead of using more complex
error recovery mechanisms. In fact, since dwm doesn't have any
persistent state and consists of a single logical module, Neale's
script _would_ arguably make it crash only software.

Brendan MacDonell



Re: [dwm] Re: dwm-5.4 stdin; cycle tags

2008-12-13 Thread Brendan MacDonell
On Sat, Dec 13, 2008 at 2:26 PM, henry atting
nspm...@literaturlatenight.de wrote:
 Patching works without problems but I get this warnings:

dwm.c:1640: warning: 'viewnext' defined but not used
dwm.c:1657: warning: 'viewprevious' defined but not used

 And, what should I say, it *is* not used ;)

 henry
That's because you haven't bound those functions to any keys in your
config.h. ;)



Re: [dwm] dwm-5.3

2008-12-06 Thread Brendan MacDonell
On Sat, Dec 6, 2008 at 2:20 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
 I just tried the close(0) patch but it does not change anything. And I
 found something very weird. I told you that in the previous version of
 dwm (5.2) with the .xinitrc containing the while | dwm all worked
 fine and I am sure of that. I quitted dwm-5.2 many times with a lot of
 openned windows and all worked fine. But now, when I reinstall dwm-5.2 I
 get the same problem than in dwm-5.3 and dwm-5.3.1, double-fork,
 simple-fork and re-double-fork. I don't understand why.

Is there any chance you may have recently updated your version of
xorg-server? I know the change just got pushed out recently on
Archlinux, and it seems to have changed some corner cases that people
previously took for granted.


In response to your idea for executing status scripts, that's roughly
how my patched version of dwm does it, though mine takes the status
script name (or possibly even the content) as an argument, and stores
the entirety of argv so that dwm can re-exec itself to restart/change
the script. In any case, the function you're looking for to replace a
fid with another is 'dup2(replacement, to_replace)'.

On Sat, Dec 6, 2008 at 2:20 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
 I just tried the close(0) patch but it does not change anything. And I
 found something very weird. I told you that in the previous version of
 dwm (5.2) with the .xinitrc containing the while | dwm all worked
 fine and I am sure of that. I quitted dwm-5.2 many times with a lot of
 openned windows and all worked fine. But now, when I reinstall dwm-5.2 I
 get the same problem than in dwm-5.3 and dwm-5.3.1, double-fork,
 simple-fork and re-double-fork. I don't understand why.

 Why don't we change the way dwm gets its status text ? For example
 we could use the SIGALRM signal to call a spawn2 :

 spawn2()
 {
check for a certain shell script .dwmstatus;
if it is not present then return;
create some pipe p[];
(double or simple)-fork;
in the child process
{
close(0);
close(1);
close(2);
set stdout to p[1]; /* I don't know how exactly */
execv(.dwmstatus);
}
/* Here is dwm */
read status from p[0];
display status;
 }

 This will take only a few LOC, because all the reading p[0] part
 will be in fact the reading-stdin code from the run() function which
 will not be needed anymore. This has the advantages that one can change
 the status when dwm is running and there are no more quitting
 problem. This is just an idea, forgive me not to propose some real
 code. Well tell me what you think of this idea.

 --
 Kind regards,
 Guillaume Quintin.





Re: [dwm] dwm-5.3

2008-12-06 Thread Brendan MacDonell
That's how my version currently works. Unfortunately, mine likely
wouldn't be much good to you because there is a massive amount of
overhead that I added to fine-tune process controls - and I can't
merge into my github repository to demonstrate until the daily
mercurial mirror updates. Of course, your idea is actually as simple
as using popen, the non-standard function fileno, and dup2 to replace
stdin if you wanted to minimize the amount of code you touch, ie.
(somewhere in main()):

FILE *dwmhelper;
...
if(argc == 2) {
 dwmhelper  = popen(argv[1], r);
 if(f) dup2(fileno(dwmhelper), STDIN_FILENO);
}
run();
pclose(dwmhelper);

Actually, I'm unsure that dwm didn't actually work this way by default
at one point. I seem to recall finding it somewhere in the source in
some long-lost revision once when I went repository-diving.

On Sat, Dec 6, 2008 at 10:44 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
 Then use another solution. I posted a patch some hours ago, which
 requires the time.h and execute a script every second but you choose to
 execute it every hour if you like you just have to modify :

 int what_you_want;
 t = time(0) + what_you_want;

 Moreover I thought of another solution more simple for which you won't
 to modify any status script or store any data between calls. It is
 late, I am tired so I won't write a patch but I think we proceed as
 follow :

 You don't need any time.h functions. Before the main loop in the run()
 function you call popen(yourscript,r);
 and within the main loop, you keep select(); and fgets(); when
 necessary and display it. On breaking the main loop you pclose();
 Tomorrow I will try this unless someone write it during the night.

 --
 Kind regards,
 Guillaume Quintin.






Re: [dwm] SLiM login themes for dwm users

2008-10-29 Thread Brendan MacDonell
Is that section copied and pasted from your configuration file? If so,
it's probably the typo where you have 'exex' instead of 'exec' that's
doing it, instead of any real issue with your configuration.

 I have changed the following in /etc/slim.conf:

 #login_cmd   exec /bin/bash -login /etc/X11/Xsession %session
 login_cmd   exex /bin/bash -login ~/.xinitrc %session

 #sessionsstartxfce4,openbox,ion3,icewm,wmaker,blackbox
 sessionsdwm

 Am I doing something wrong here?



Re: [dwm] regression in 5.0.1

2008-09-06 Thread Brendan MacDonell
On Sat, Sep 6, 2008 at 10:35 AM, bill lam [EMAIL PROTECTED] wrote:
 I added that but have no idea where the error log resided.
 Nevertheless, I simplified that line to

 if(!XGetWMNormalHints(dpy, c-win, size, msize))return;

 and the issue is also fxied. My theory is that if XGetWMNormalHints
 fails then information returned in size is rubbish, and set that flag to
 PSize can help to prevent incorrectly change anything.

That is pretty much correct. According to the Xlib programming manual:
 If the property is of type WM_SIZE_HINTS, is of format 32, and is long enough 
 to contain
 either an old (pre-ICCCM) or new size hints structure, XGetWMNormalHints() 
 sets the
 various fields of the XSizeHints structure, sets the supplied_return argument 
 to the list of
 fields that were supplied by the user (whether or not they contained defined 
 values), and
 returns a nonzero status. Otherwise, it returns a zero status.

Ie., if a zero status is returned, then the variable size remains
uninitialized, and will contain whatever garbage was in that stack
segment when the function was called.



Re: [dwm] malloc'ed client in manage()

2008-09-06 Thread Brendan MacDonell
I'm not sure I understand the point of this patch. calloc is defined
in both C89 and C99, and is both fairly generic and very widely used,
so I fail to see anything safer or more portable about this approach.
Not to mention that fact that most people prefer not to use structure
assignments...

Brendan MacDonell



Re: [dwm] new setgeom in hg tip

2008-03-15 Thread Brendan MacDonell
On Sat, Mar 15, 2008 at 5:30 PM, Johannes Hofmann
[EMAIL PROTECTED] wrote:
  Huh? That's a config parser in dwm!
Luckily I'd say, since otherwise we'd seem to be stuck hardcoding
values for screen sizes as 24-line functions for each set of geoms.
This config parser isn't really much different from the regexes that
were used in config.h for matching windows, nor is it difficult to
understand, so I have no objections.

Brendan



Re: [dwm] ntags initialization

2007-10-06 Thread Brendan MacDonell
On Fri, Oct 05, 2007 at 23:33:44 CEST, Anselm R. Garbe wrote:
 You miss that seltags and Client-tags are both globally defined
 in the same context as the tags definition. Afaik you can't
 evaluate the sizeof operator and you can't perform a division
 operation in a non-functional scope, so I don't see how you
 would like to replace the allocation of seltags and Client-tags
 using emallocz.

sizeof is a compile-time constant, and any expression containing only
compile-time constants (literal numbers, sizeof, etc; no variables or
functions) can be evaluated at compile time. To demonstrate, consider
the attached patch against changeset 1025 (written in standard, albeit
little-used, C)  which removes the dynamic allocation of seltags and
Client-tags and replaces it with constant initialization. Due to
added whitespace where some declarations were rearranged, and a
comment, the number of LOC decreased only by 2.
--- dwm.c.old	2007-10-06 10:02:01.680419843 -0300
+++ dwm.c	2007-10-06 11:28:34.323541304 -0300
@@ -57,21 +57,6 @@
 
 /* typedefs */
 typedef struct Client Client;
-struct Client {
-	char name[256];
-	int x, y, w, h;
-	int rx, ry, rw, rh; /* revert geometry */
-	int basew, baseh, incw, inch, maxw, maxh, minw, minh;
-	int minax, maxax, minay, maxay;
-	long flags;
-	unsigned int border, oldborder;
-	Bool isbanned, isfixed, ismax, isfloating, wasfloating;
-	Bool *tags;
-	Client *next;
-	Client *prev;
-	Client *snext;
-	Window win;
-};
 
 typedef struct {
 	int x, y, w, h;
@@ -195,7 +180,7 @@
 double mwfact;
 int screen, sx, sy, sw, sh, wax, way, waw, wah;
 int (*xerrorxlib)(Display *, XErrorEvent *);
-unsigned int bh, bpos, ntags;
+unsigned int bh, bpos;
 unsigned int blw = 0;
 unsigned int ltidx = 0; /* default */
 unsigned int nlayouts = 0;
@@ -218,7 +203,6 @@
 Atom wmatom[WMLast], netatom[NetLast];
 Bool otherwm, readin;
 Bool running = True;
-Bool *seltags;
 Bool selscreen = True;
 Client *clients = NULL;
 Client *sel = NULL;
@@ -232,6 +216,26 @@
 /* configuration, allows nested code to access above variables */
 #include config.h
 
+/* Statically define the number of tags. */
+unsigned int ntags = sizeof tags / sizeof tags[0];
+Bool seltags[sizeof tags / sizeof tags[0]] = {[0] = True};
+
+struct Client {
+	char name[256];
+	int x, y, w, h;
+	int rx, ry, rw, rh; /* revert geometry */
+	int basew, baseh, incw, inch, maxw, maxh, minw, minh;
+	int minax, maxax, minay, maxay;
+	long flags;
+	unsigned int border, oldborder;
+	Bool isbanned, isfixed, ismax, isfloating, wasfloating;
+	Bool tags[sizeof tags / sizeof tags[0]];
+	Client *next;
+	Client *prev;
+	Client *snext;
+	Window win;
+};
+
 /* functions*/
 void
 applyrules(Client *c) {
@@ -393,7 +397,6 @@
 	XFreeCursor(dpy, cursor[CurMove]);
 	XSetInputFocus(dpy, PointerRoot, RevertToPointerRoot, CurrentTime);
 	XSync(dpy, False);
-	free(seltags);
 }
 
 void
@@ -1006,7 +1009,6 @@
 	XWindowChanges wc;
 
 	c = emallocz(sizeof(Client));
-	c-tags = emallocz(ntags * sizeof(Bool));
 	c-win = w;
 	c-x = wa-x;
 	c-y = wa-y;
@@ -1467,9 +1469,6 @@
 
 	/* init tags */
 	compileregs();
-	ntags = sizeof tags / sizeof tags[0];
-	seltags = emallocz(sizeof(Bool) * ntags);
-	seltags[0] = True;
 
 	/* init appearance */
 	dc.norm[ColBorder] = getcolor(NORMBORDERCOLOR);
@@ -1703,7 +1702,6 @@
 		focus(NULL);
 	XUngrabButton(dpy, AnyButton, AnyModifier, c-win);
 	setclientstate(c, WithdrawnState);
-	free(c-tags);
 	free(c);
 	XSync(dpy, False);
 	XSetErrorHandler(xerror);