[dwm] Inclusion of DWM Wiki Pages in DWM tarball
I upgraded from version 4.9 to 5.1 the other day and found quite a bit of changes in the way rules are defined. Initially I couldn't figure it out so I searched the mailing list archives and found a few posts regarding how the new rules config works. The wiki also contains quite a bit of useful information that helped me out a lot. Why not include the DWM wiki pages in a doc/ directory in the source tarball? It wouldn't bump up the size significantly and it would greatly help a lot of users. I guess one could ask why not just go to the online browse the wiki? In my case, I find that I am not online most of the time and having the documentation at hand in the tarball is a great reference for when I want to configure DWM. Any thoughts? Is this a possibility? Thanks, Amit
Re: [dwm] Inclusion of DWM Wiki Pages in DWM tarball
On 9/7/08, Amit Uttamchandani [EMAIL PROTECTED] wrote: Why not include the DWM wiki pages in a doc/ directory in the source tarball? It wouldn't bump up the size significantly and it would greatly help a lot of users. I guess one could ask why not just go to the online browse the wiki? In my case, I find that I am not online most of the time and having the documentation at hand in the tarball is a great reference for when I want to configure DWM. the wiki is a mercurial repository, ie. you can clone the whole wiki with revision history and browse it offline the wiki may change more frequently than the dwm releases the wiki is huge compared to dwm ( 1MB when compressed without history) the wiki is a completely separate thing, we could include all the suckless tools in dwm tarball by that logic
Re: [dwm] Inclusion of DWM Wiki Pages in DWM tarball
On Sun, 7 Sep 2008 08:27:40 +0200 Szabolcs Nagy [EMAIL PROTECTED] wrote: On 9/7/08, Amit Uttamchandani [EMAIL PROTECTED] wrote: Why not include the DWM wiki pages in a doc/ directory in the source tarball? It wouldn't bump up the size significantly and it would greatly help a lot of users. I guess one could ask why not just go to the online browse the wiki? In my case, I find that I am not online most of the time and having the documentation at hand in the tarball is a great reference for when I want to configure DWM. the wiki is a mercurial repository, ie. you can clone the whole wiki with revision history and browse it offline That's a good idea. the wiki may change more frequently than the dwm releases How about whenever the tarball is released, a snapshot of the DWM wiki. the wiki is huge compared to dwm ( 1MB when compressed without history) the wiki is a completely separate thing, we could include all the suckless tools in dwm tarball by that logic I wasn't talking about the whole wiki. Just the sections pertaining to DWM. For example, under suckless.org/dwm/ only the tuorial and the customisation section can be included (don't need the manpages, screenshots, etc): 1. /tutorial.html 2. /customisation - ./customfuncs.html - ./font.html - ./noapps.html - ./noinpu.html - ./patch_queue.html - ./tagmask.html - ./windows_key.html I'm sure the above once compressed will be less than a few kilobytes. Thanks, Amit
Re: [dwm] malloc'ed client in manage()
2008/9/6 Brendan MacDonell [EMAIL PROTECTED]: 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... I agree in this case. Kind regards, --Anselm
Re: [dwm] Asustek EEE PC 1000 Atom 1GB 40G SSD Linux Black
On Sat, Sep 06, 2008 at 11:48:05PM -0500, Kurt H Maier wrote: Alt+F2 brings up a run dialog in xfce. Yes, but I think this is disabled in the Acer's Linpus Linux. However, you can use search for files (I guess that is using Thunar) to open an xterm as mentioned. As for the manpages: I'd install a different distro anyway. That would necessitate some extra configuration to account for the flash storage (e.g. disabling logging), but I think it is worth the effort. regards Martin
Re: [dwm] malloc'ed client in manage()
On 9/6/08, Filippo Erik Negroni [EMAIL PROTECTED] wrote: A preferable, safer and more portable way of achieving such initialisation is to use the compiler's static initialisation. is it because of null pointer might not be represented as zeros? the point is good, but i doubt X would run on such platform ;)
Re: [dwm] malloc'ed client in manage()
On Sun, 7 Sep 2008 11:25:53 +0200 Szabolcs Nagy [EMAIL PROTECTED] wrote: On 9/6/08, Filippo Erik Negroni [EMAIL PROTECTED] wrote: A preferable, safer and more portable way of achieving such initialisation is to use the compiler's static initialisation. is it because of null pointer might not be represented as zeros? I don't think so. KR, 2nd Ed. page 102: Pointers and integers are not interchangeable. Zero is the sole exception: the constant zero may be assigned to a pointer, and a pointer may be compared with the constant zero. The symbolic constant NULL is often used in place of zero, as a mnemonic to indicate that this is a special value for a pointer I think it's quite explicit: the NULL macro expands to 0. -- Nicolas Martyanoff http://codemore.org [EMAIL PROTECTED] signature.asc Description: PGP signature
Re: [dwm] malloc'ed client in manage()
Nicolas Martyanoff wrote:
On Sun, 7 Sep 2008 11:25:53 +0200
Szabolcs Nagy [EMAIL PROTECTED] wrote:
On 9/6/08, Filippo Erik Negroni [EMAIL PROTECTED] wrote:
A preferable, safer and more portable way of achieving such
initialisation is to use the compiler's static initialisation.
is it because of null pointer might not be represented as zeros?
I don't think so.
KR, 2nd Ed. page 102:
Pointers and integers are not interchangeable. Zero is the sole
exception: the constant zero may be assigned to a pointer, and a
pointer may be compared with the constant zero. The symbolic constant
NULL is often used in place of zero, as a mnemonic to indicate that
this is a special value for a pointer
I think it's quite explicit: the NULL macro expands to 0.
Does anyone know whether there are architectures where NULL is not equal
to 0?
See ISO/IEC 9899:TC2 Section 7.17.3:
The macros are NULL which expands to an implementation-defined null
pointer constant and; ...
See ISO/IEC 9899:TC2 Section 6.3.2.3.3:
An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.
Seems like a contradiction in the C99 standard (I have to admit that my
version is a Committee Draft).
See ISO/IEC 14882:1998 and ISO/IEC 14882:2003 Section 4.10:
A null pointer constant is an integer constant expression (5.19)
rvalue of integer type that evaluates to zero.
See ISO/IEC 14882:1998 and ISO/IEC 14882:2003 Section 18 Footnote 180:
Possible definitions include 0 and 0L, but not (void *)0.
And this sounds like a conflict between C and C++.
But anyhow it seems that you can't do this reliably, because s isn't
used by memset as a pointer.
memset(s, 0, sizeof(s));
where s is a struct.
According to ISO/IEC 9899:TC2 Section 6.7.8.1 and Section 6.7.8.10 this
would be correct:
s = {0}; or s = 0;
Anyhow it's not working with gcc.
Regards,
Matthias-Christian
Re: [dwm] malloc'ed client in manage()
On 9/7/08, Nicolas Martyanoff [EMAIL PROTECTED] wrote: I think it's quite explicit: the NULL macro expands to 0. NULL macro does not necessaryly expands to 0, but this is basic knowledge look it up in the standard. what am i concerned about is the internal null pointer representation (which has nothing to do wether NULL is defined 0 or not) it is explicitely stated in c99 that there might be architectures where memset(p, 0, sizeof(p)) is not equivalent to p=0;
Re: [dwm] malloc'ed client in manage()
On 9/7/08, Matthias-Christian Ott [EMAIL PROTECTED] wrote:
Nicolas Martyanoff wrote:
Does anyone know whether there are architectures where NULL is not equal
to 0?
this question occasionally appears on comp.lang.c and there exists
such beast, but i cannot find the reference now
probably it's some old or otherwise esoteric architecture
See ISO/IEC 9899:TC2 Section 7.17.3:
The macros are NULL which expands to an implementation-defined null
pointer constant and; ...
See ISO/IEC 9899:TC2 Section 6.3.2.3.3:
An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.
Seems like a contradiction in the C99 standard (I have to admit that my
version is a Committee Draft).
there is no contradiction
'0' can simply mean 2 completely different things: null pointer in
pointer context, or integer 0 otherwise
so a _constant_ integer expression with value 0 automagically becomes
a null pointer which may or may not be represented internally by all
bits zero
(but eg an integer 0 must be represented by all bits zero)
See ISO/IEC 14882:1998 and ISO/IEC 14882:2003 Section 4.10:
A null pointer constant is an integer constant expression (5.19)
rvalue of integer type that evaluates to zero.
See ISO/IEC 14882:1998 and ISO/IEC 14882:2003 Section 18 Footnote 180:
Possible definitions include 0 and 0L, but not (void *)0.
And this sounds like a conflict between C and C++.
yes, c++ was developped with this design decision from the start
But anyhow it seems that you can't do this reliably, because s isn't
used by memset as a pointer.
memset(s, 0, sizeof(s));
where s is a struct.
yes, that's the point: according to standard calloc is not ok, but
default struct initialization is
(but we can overlook this since X won't run such weird architecture)
According to ISO/IEC 9899:TC2 Section 6.7.8.1 and Section 6.7.8.10 this
would be correct:
s = {0}; or s = 0;
Anyhow it's not working with gcc.
in c99 you initialize a struct to zero with:
struct_t s = {};
Re: [dwm] malloc'ed client in manage()
On Sun, 7 Sep 2008 13:53:11 +0200
Szabolcs Nagy [EMAIL PROTECTED] wrote:
On 9/7/08, Nicolas Martyanoff [EMAIL PROTECTED] wrote:
I think it's quite explicit: the NULL macro expands to 0.
NULL macro does not necessaryly expands to 0, but this is basic
knowledge look it up in the standard.
what am i concerned about is the internal null pointer representation
(which has nothing to do wether NULL is defined 0 or not)
NULL is a macro that expands to the
implementation-defined null pointer constant. [7.17.3]
If NULL expands to 0, then basic logic tells me that the null pointer
constant is 0; if I'm making a logic error, what is it ?
it is explicitely stated in c99 that there might be architectures
where memset(p, 0, sizeof(p)) is not equivalent to p=0;
The standard contains ambiguities, everybody knows that; if KR 2 tells
NULL expands to 0, and the C standard tells that NULL expands to the
null pointer constant, then I think we can assume that setting a pointer
to 0 is ok.
Therefore:
struct foo {
int i;
void *ptr;
}
struct foo bar;
memset(bar, 0, sizeof(struct foo));
Will get bar.i == 0, and foo.ptr == NULL.
Now, another idea is to find an existing architecture where the null
pointer representation is NOT 0. To be honest, if such an architecture
exists, then a lot of softwares won't work on it. (and KR 2 will be
wrong...)
--
Nicolas Martyanoff
http://codemore.org
[EMAIL PROTECTED]
signature.asc
Description: PGP signature
Re: [dwm] malloc'ed client in manage()
On 9/7/08, Nicolas Martyanoff [EMAIL PROTECTED] wrote: If NULL expands to 0, then basic logic tells me that the null pointer constant is 0; if I'm making a logic error, what is it ? you expect that the symbol '0' means the same for integers and pointers, but it's not (as i wrote earlier: integer 0 is 'all-bits-zero', thus memset works, but pointer 0 is not required to be 'all-bits-zero', it just *happens to be* 'all-bits-zero' on every sane platform) The standard contains ambiguities, everybody knows that; if KR 2 tells no the standard is very precise about this. struct foo bar; memset(bar, 0, sizeof(struct foo)); Will get bar.i == 0, and foo.ptr == NULL. not guaranteed by the standard
Re: [dwm] malloc'ed client in manage()
On 9/7/08, Matthias-Christian Ott [EMAIL PROTECTED] wrote: Does anyone know whether there are architectures where NULL is not equal to 0? see question 1.14: http://www.lysator.liu.se/c/c-faq/c-1.html#1-14 (last modified in 1994)
Re: [dwm] malloc'ed client in manage()
Szabolcs Nagy wrote:
On 9/7/08, Matthias-Christian Ott [EMAIL PROTECTED] wrote:
Nicolas Martyanoff wrote:
Does anyone know whether there are architectures where NULL is not equal
to 0?
this question occasionally appears on comp.lang.c and there exists
such beast, but i cannot find the reference now
probably it's some old or otherwise esoteric architecture
See ISO/IEC 9899:TC2 Section 7.17.3:
The macros are NULL which expands to an implementation-defined null
pointer constant and; ...
See ISO/IEC 9899:TC2 Section 6.3.2.3.3:
An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.
Seems like a contradiction in the C99 standard (I have to admit that my
version is a Committee Draft).
there is no contradiction
OK, if think about the phrase implementation-defined null pointer
constant twice, it becomes clear that this means that NULL can be
defined in one of the following ways:
#define NULL(void *)0
or
#define NULL0
I overread null pointer constant and thought that they first mention
that NULL is implementation-defined and then state that NULL is 0 oder
(void *)0.
'0' can simply mean 2 completely different things: null pointer in
pointer context, or integer 0 otherwise
so a _constant_ integer expression with value 0 automagically becomes
a null pointer which may or may not be represented internally by all
bits zero
(but eg an integer 0 must be represented by all bits zero)
See ISO/IEC 14882:1998 and ISO/IEC 14882:2003 Section 4.10:
A null pointer constant is an integer constant expression (5.19)
rvalue of integer type that evaluates to zero.
See ISO/IEC 14882:1998 and ISO/IEC 14882:2003 Section 18 Footnote 180:
Possible definitions include 0 and 0L, but not (void *)0.
And this sounds like a conflict between C and C++.
yes, c++ was developped with this design decision from the start
But anyhow it seems that you can't do this reliably, because s isn't
used by memset as a pointer.
memset(s, 0, sizeof(s));
where s is a struct.
yes, that's the point: according to standard calloc is not ok, but
default struct initialization is
(but we can overlook this since X won't run such weird architecture)
I mean this whole NULL pointer thing scarses me. First they thought: OK,
NULL was always synonimous with 0, so let's say if someone assigns 0 to
a pointer lets make it a hardware NULL (which isn't 0 on some
architectures). But what follows is that all code that generalises the
pointer = 0 principle to variable = 0, cast to pointer to be the
same becomes invalid. That's so stupid.
In my code I'll assume that memset(s, 0, sizeof(s)); works for all
pointers.
According to ISO/IEC 9899:TC2 Section 6.7.8.1 and Section 6.7.8.10 this
would be correct:
s = {0}; or s = 0;
Anyhow it's not working with gcc.
in c99 you initialize a struct to zero with:
struct_t s = {};
But anyways I'm not sure whether static char *p is equal to char *p =
NULL.
Regards
Matthias-Christian
Re: [dwm] An overlapped tiled layout
Hello, I've applied a modified version of your patch to my copy of dwm. I don't quite understand the need to set stack_mode to 'Above' and then 'Below' when reached the selected client (in restack(void)). Actually, this alone messes with monocle layout (open a floating window and you'll see the n - 1 window is no longer the one beneath the new floating window. Once removed, I didn't see a change in tileo... Thanks anyway for your patch, I like it :-) -- Tinou On Sun, Jun 8, 2008 at 1:23 PM, Monsieur Pinocchio [EMAIL PROTECTED] wrote: On Sun, Jun 8, 2008 at 7:14 AM, Monsieur Pinocchio [EMAIL PROTECTED] wrote: On Sun, Jun 8, 2008 at 6:59 AM, Monsieur Pinocchio [EMAIL PROTECTED] wrote: On Sun, Jun 8, 2008 at 6:43 AM, Matthias-Christian Ott [EMAIL PROTECTED] wrote: Monsieur Pinocchio [EMAIL PROTECTED] wrote: Hi, I thought I would experiment with a new layout concept. I call it the overlapped tiled layout :) or in short tileo. I required some changes to restack() to make it work... though I hope this only makes restack() cleaner. The basic concept it to overlap the windows in the stack so that 1) they can have a size larger than (th / n) 2) the windows before and after it in the stack are overlapped and stacked (as per X11 stacking) below the focused window in the stack area. The main benefit is to be able to increase the size of the focused window in the stack without moving them on another tag. The height of the windows in the stack is a constant value of th*0.8. The windows in the stack are overlapped like a deck of cards. The focused window is raised. I generally like using it in conjunction with the regular tilev() layout with shortcuts to switch quickly to either layout. It really helps if you have a large number of windows in the stack area. Here is the patch... I think the patch simplifies the restack() function so that should be useful to upstream in itself. Any comments are most welcome: Do you have any screenshots? Regards Matthias-Christian Hope this explains it better. -- Pinocchio Oops... its seems that I cannot post anything larger than 40K. Let's wait for the moderator to approve the post. -- Pinocchio I have cancelled the post and uploaded the screenshot here. Let me know your thoughts... http://picasaweb.google.com/cchinopio/Dwm -- Pinocchio
Re: [dwm] patch: fix screen flicker with monocle
On Sep 6, 2008, at 1:25 AM, Anselm R Garbe wrote: 2008/9/3 Donald Chai [EMAIL PROTECTED]: I'm sure there might be other problems I created...I don't understand the X11 event model at all. Yes you did. It is important to showhide() before focus and restack handling. I also slightly changed your initial showhide() version. See hg tip for reference. You're right. For example, if my pointer is located over window A, and I use the keyboard to switch between windows B and C, window A briefly gets focus. Yes, this was because you performed showhide() after restack(). At the end of restack all enternotify's are flushed. Actually, this is a totally unrelated problem. The problem is that XGrabKeyboard generates focus events (XGrabKeyboard is called by the X server after establishing the passive grab with XGrabKey). So, all keyboard shortcuts cause the window under the mouse to briefly get focus. I've used Metacity (the GNOME WM) with focus- follows-mouse, and it doesn't have this behavior when I Alt-Tab.
