Re: [dwm] uriel sez the default config is retarded
On 2/11/07, lobzang <[EMAIL PROTECTED]> wrote:
Hi,
I'm interested in the togglemax funcionnality , however I was unable to
use it ... did you patch dwm ?
On Fri, 2007-02-09 at 15:06 +0100, Szabolcs Nagy wrote:
> { MODKEY, XK_m, togglemax, { 0 } }, \
well, iirc old dwm had togglemax(Arg *) function, but this
functionality is now removed (static void togglemax(Client*) is only
used when zooming float windows)
i don't know why but there is some reasoning behind it for sure
anyway if you want togglemax, then you can create a simple function in view.c:
void
dotogglemax(Arg* a){
togglemax(sel);
}
also add a declaration in dwm.h:
void dotogglemax(Arg* a);
and then you can use it in your config.h
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
On Tue, Feb 20, 2007 at 02:53:45PM +0200, Alexandru E. Ungur wrote: > >>> sender: "Anselm R. Garbe" date: "Tue, Feb 20, 2007 at 11:35:17AM +0100" > >>> << > On Mon, Feb 19, 2007 at 09:22:41PM -0500, John S. Yates, Jr. wrote: > > > On Mon, Feb 19, 2007 at 11:56:18AM I wrote: > > > > Scanning the bundles showing up on [hackers] it is clear that > > > > those of us who have any significant investment in dwm patches > > > > are in for rough sledding trying to track this refactoring. > > > To which Anselm replied with a detailed list of his changes > > > explaining that none should be a significant impediment to > > > propagating patches. > > > > Well I have to describe the last step: > > > > I split screen.c into layout.c and tag.c again. layout.c > > contains all arrangement-related stuff (*also new algorithms > > like dogrid should go into this file for patches*). > I have a question: if instead of patching the layout.c file for new > layouts, each of us who created a layout patch would create a > separate file, such as: > > layout_grid.c > layout_bstack.c Do what you like, but don't forget that those files must be included in Makefile somehow and the function signatures must be local in layout.c as well... so I consider this as don't do it that way ;) > wouldn't that be easier for people wanting to try several layout > patches? This way at least the layout patching part would be a simple > file copy, free of any merging conflicts. See above, it's not so simple. And I don't want to hack the Makefile with such quirks we had once in wmii-2. Regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] Patch to handle null X Class the way you want.
On Tue, Feb 20, 2007 at 09:18:10AM -0500, John A. Grahor wrote:
> I have a number of in-house written X Clients that don't set the X res
> class and X res name properties making XGetClassHint return non-zero. I
> found that this short circuited the regular expression processing thus
> forcing all such clients to the default action vis. floating and/or
> tagging. I see this as a bug but you may not.
>
> It so happens that I want these clients to float and my default action
> is to tile.
>
> I am submitting the following patch which allows this. If XGetClassHint
> returns non zero it sets the test string to "::name" and normal regular
> expression processing proceeds. Now you can create a regular expression
> like "::.*" and send these clients where you want.
>
> By the way, I've only just tried dwm and I love it even more than wmii.
>
> Cheers,
> John
>
>
> diff -up dwm-3.3/tag.c dwm-my/tag.c
> --- dwm-3.3/tag.c 2007-02-01 02:22:55.0 -0500
> +++ dwm-my/tag.c 2007-02-08 18:10:24.0 -0500
> @@ -77,12 +77,15 @@ settags(Client *c, Client *trans) {
> regmatch_t tmp;
> Bool matched = trans != NULL;
> XClassHint ch;
> + ch.res_class = NULL;
> + ch.res_name = NULL;
>
> if(matched) {
> for(i = 0; i < ntags; i++)
> c->tags[i] = trans->tags[i];
> }
> - else if(XGetClassHint(dpy, c->win, &ch)) {
> + else {
> + XGetClassHint(dpy, c->win, &ch);
> snprintf(prop, sizeof prop, "%s:%s:%s",
> ch.res_class ? ch.res_class : "",
> ch.res_name ? ch.res_name : "", c->name);
FYI something similiar is in mainstream dwm since dwm-3.4.
--
Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
[dwm] Patch to handle null X Class the way you want.
I have a number of in-house written X Clients that don't set the X res
class and X res name properties making XGetClassHint return non-zero. I
found that this short circuited the regular expression processing thus
forcing all such clients to the default action vis. floating and/or
tagging. I see this as a bug but you may not.
It so happens that I want these clients to float and my default action
is to tile.
I am submitting the following patch which allows this. If XGetClassHint
returns non zero it sets the test string to "::name" and normal regular
expression processing proceeds. Now you can create a regular expression
like "::.*" and send these clients where you want.
By the way, I've only just tried dwm and I love it even more than wmii.
Cheers,
John
diff -up dwm-3.3/tag.c dwm-my/tag.c
--- dwm-3.3/tag.c 2007-02-01 02:22:55.0 -0500
+++ dwm-my/tag.c2007-02-08 18:10:24.0 -0500
@@ -77,12 +77,15 @@ settags(Client *c, Client *trans) {
regmatch_t tmp;
Bool matched = trans != NULL;
XClassHint ch;
+ ch.res_class = NULL;
+ ch.res_name = NULL;
if(matched) {
for(i = 0; i < ntags; i++)
c->tags[i] = trans->tags[i];
}
- else if(XGetClassHint(dpy, c->win, &ch)) {
+ else {
+ XGetClassHint(dpy, c->win, &ch);
snprintf(prop, sizeof prop, "%s:%s:%s",
ch.res_class ? ch.res_class : "",
ch.res_name ? ch.res_name : "", c->name);
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
>>> sender: "Anselm R. Garbe" date: "Tue, Feb 20, 2007 at 11:35:17AM +0100" >>> << On Mon, Feb 19, 2007 at 09:22:41PM -0500, John S. Yates, Jr. wrote: > > On Mon, Feb 19, 2007 at 11:56:18AM I wrote: > > > Scanning the bundles showing up on [hackers] it is clear that > > > those of us who have any significant investment in dwm patches > > > are in for rough sledding trying to track this refactoring. > > To which Anselm replied with a detailed list of his changes > > explaining that none should be a significant impediment to > > propagating patches. > > Well I have to describe the last step: > > I split screen.c into layout.c and tag.c again. layout.c > contains all arrangement-related stuff (*also new algorithms > like dogrid should go into this file for patches*). I have a question: if instead of patching the layout.c file for new layouts, each of us who created a layout patch would create a separate file, such as: layout_grid.c layout_bstack.c etc. wouldn't that be easier for people wanting to try several layout patches? This way at least the layout patching part would be a simple file copy, free of any merging conflicts. Cheers, Alex
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
On Tue, Feb 20, 2007 at 01:25:19PM +0100, Anselm R. Garbe wrote: > On Tue, Feb 20, 2007 at 11:08:28AM +, David Tweed wrote: > > |The motivation is reducing the code, grouping the functions into > > |more intuitive sets and reducing the amount of exported > > |functions (only because several functions have been called from > > |a different object in one place - that was really annoying). > > |So all in all this also reduces the call graph and makes the > > |executable slightly smaller than before. Beside the fact of the > > |new Layout struct being ready for more layout-specific > > |additions. > > > > Could I just see if it's possible for mainline to just not mark > > drawtext as not static? (I'm looking to see if there's a simpler > > way of re-instituting per-window titles than Ross Mohn's patch > > - which is very impressive but looks to me like a huge > > pain to maintain - which inherently involves both writing > > strings and traversing the client list so having both sets of > > functions static means more patching. I'd image Ross's titles patch > > would also be slightly shorter without having to un-static this.) > > Hmm, actually I doubt marking drawtext as non-static will help. > Simply because such a patch should come packed with a > drawtitle(Client *c) function which should be located in main.c > to easily access drawtext instead. This is because the > drawtitle function needs to map the drawed client title anyways > to the client title window (you will also need resizetitle() > anyways). Well ok, I made drawtext extern (with putting the square drawing algorithm into a different function) - I also will move the draw stuff from main.c to draw.c again - I think it was a bad idea to merge it into main.c - except setfont and getcolor. -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
|Hmm, actually I doubt marking drawtext as non-static will help. |Simply because such a patch should come packed with a |drawtitle(Client *c) function which should be located in main.c |to easily access drawtext instead. This is because the |drawtitle function needs to map the drawed client title anyways |to the client title window (you will also need resizetitle() |anyways). Note: I'm doing this for my own purposes because I really need a list of all visible clients' titles to work effectively; I'm not imagining it for mainstream. I'm experimenting with a different approach of collecting all the titles into one window in the corner, which is why I need to use both nexttiled() and drawtext() in same function. This seems to need only 2 call-sites. This approach is less useful than real on-window titles, but I'm just checking how useful before stripping Ross's solution from his patchset. But I hadn't noticed you've made nexttiled exported, which means my function can probably live in main.c. cheers, dave tweed ___ Inbox full of unwanted email? Get leading protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
On Tue, Feb 20, 2007 at 11:08:28AM +, David Tweed wrote: > |The motivation is reducing the code, grouping the functions into > |more intuitive sets and reducing the amount of exported > |functions (only because several functions have been called from > |a different object in one place - that was really annoying). > |So all in all this also reduces the call graph and makes the > |executable slightly smaller than before. Beside the fact of the > |new Layout struct being ready for more layout-specific > |additions. > > Could I just see if it's possible for mainline to just not mark > drawtext as not static? (I'm looking to see if there's a simpler > way of re-instituting per-window titles than Ross Mohn's patch > - which is very impressive but looks to me like a huge > pain to maintain - which inherently involves both writing > strings and traversing the client list so having both sets of > functions static means more patching. I'd image Ross's titles patch > would also be slightly shorter without having to un-static this.) Hmm, actually I doubt marking drawtext as non-static will help. Simply because such a patch should come packed with a drawtitle(Client *c) function which should be located in main.c to easily access drawtext instead. This is because the drawtitle function needs to map the drawed client title anyways to the client title window (you will also need resizetitle() anyways). > Does the slight change in executable size from making them > static actually remotely > matter? I work with images/databases and the resident code Actually it does not matter much. But I prefer keeping functions static which don't really need to be exported. Regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
if any day dwm gets into the no-more-releases state would be nice to provide the patches inside the same tarball/repo and include them in config.h or config.mk. For me DWM is perfect except for the lack of the append-window patch. But this will be really easy to re-implement thanks to the new redesign of dwm. --pancake > On Mon, Feb 19, 2007 at 09:22:41PM -0500, John S. Yates, Jr. wrote: >> On Mon, Feb 19, 2007 at 11:56:18AM I wrote: >> > Scanning the bundles showing up on [hackers] it is clear that >> > those of us who have any significant investment in dwm patches >> > are in for rough sledding trying to track this refactoring. >> To which Anselm replied with a detailed list of his changes >> explaining that none should be a significant impediment to >> propagating patches. > > Well I have to describe the last step: > > I split screen.c into layout.c and tag.c again. layout.c > contains all arrangement-related stuff (*also new algorithms > like dogrid should go into this file for patches*). tag.c > contains the tag-related stuff like rules, and the view- and > tag-specific functions. This seems more natural to me than > putting everything into a single file. > >> In that same posting I further wrote: >> >> > Will there be appreciable new functionality or is this just >> > gilding the lily? At what point will st get any real >> > attention? >> >> So what is the motivation for this refactoring? Personally > > The motivation is reducing the code, grouping the functions into > more intuitive sets and reducing the amount of exported > functions (only because several functions have been called from > a different object in one place - that was really annoying). > So all in all this also reduces the call graph and makes the > executable slightly smaller than before. Beside the fact of the > new Layout struct being ready for more layout-specific > additions. > > All in all I think that after this refactoring dwm is in a state > that we don't need more releases. I have no request for > additional functionality - it basically fits perfectly my needs. > So see the motivation as final polishing/review. > >> I have much more interest in st reaching a minimal level of >> utility than in a refactoring of dwm that really presents us >> nothing new. > > Hehe, I'm with you, but lack of time at the moment. I delayed st > for several reasons. But its development will go on soon. > >> But an st that we can all help evolve will make much more of a >> difference to the suckless community than an endlessly polished >> dwm. > > Hehe yes. But note that dwm was not written from scratch and > suffered to some extend to design decisions made in wmii, this > has been fixed now. > > The aspect ratio algorithm is going to be slightly changed, > after this I think it will be time for 3.6. > > Regards, > -- > Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361 > >
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
|The motivation is reducing the code, grouping the functions into |more intuitive sets and reducing the amount of exported |functions (only because several functions have been called from |a different object in one place - that was really annoying). |So all in all this also reduces the call graph and makes the |executable slightly smaller than before. Beside the fact of the |new Layout struct being ready for more layout-specific |additions. Could I just see if it's possible for mainline to just not mark drawtext as not static? (I'm looking to see if there's a simpler way of re-instituting per-window titles than Ross Mohn's patch - which is very impressive but looks to me like a huge pain to maintain - which inherently involves both writing strings and traversing the client list so having both sets of functions static means more patching. I'd image Ross's titles patch would also be slightly shorter without having to un-static this.) Does the slight change in executable size from making them static actually remotely matter? I work with images/databases and the resident code size is almost always a vanishing fraction of the data-structure memory usage. For example, on my x86-64 machine sizeof(Client) is 408 bytes, of which 256 is the title array. Given that the majority of applications don't change title remotely frequently I've wondered about the tradeoff in making that a malloced array. Of course client list traversals in dwm is going to be nowhere near as cache hot as application code - and the cache ought to map only those fields actually used at during the traversals in layout algorithm - but if you want to optimise something I'd suggest data structure size is more practically relevant than executable size. cheers, dave tweed ___ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
update: Re: [dwm] recent changes to dwm (since dwm-3.5)
On Mon, Feb 19, 2007 at 09:22:41PM -0500, John S. Yates, Jr. wrote: > On Mon, Feb 19, 2007 at 11:56:18AM I wrote: > > Scanning the bundles showing up on [hackers] it is clear that > > those of us who have any significant investment in dwm patches > > are in for rough sledding trying to track this refactoring. > To which Anselm replied with a detailed list of his changes > explaining that none should be a significant impediment to > propagating patches. Well I have to describe the last step: I split screen.c into layout.c and tag.c again. layout.c contains all arrangement-related stuff (*also new algorithms like dogrid should go into this file for patches*). tag.c contains the tag-related stuff like rules, and the view- and tag-specific functions. This seems more natural to me than putting everything into a single file. > In that same posting I further wrote: > > > Will there be appreciable new functionality or is this just > > gilding the lily? At what point will st get any real > > attention? > > So what is the motivation for this refactoring? Personally The motivation is reducing the code, grouping the functions into more intuitive sets and reducing the amount of exported functions (only because several functions have been called from a different object in one place - that was really annoying). So all in all this also reduces the call graph and makes the executable slightly smaller than before. Beside the fact of the new Layout struct being ready for more layout-specific additions. All in all I think that after this refactoring dwm is in a state that we don't need more releases. I have no request for additional functionality - it basically fits perfectly my needs. So see the motivation as final polishing/review. > I have much more interest in st reaching a minimal level of > utility than in a refactoring of dwm that really presents us > nothing new. Hehe, I'm with you, but lack of time at the moment. I delayed st for several reasons. But its development will go on soon. > But an st that we can all help evolve will make much more of a > difference to the suckless community than an endlessly polished > dwm. Hehe yes. But note that dwm was not written from scratch and suffered to some extend to design decisions made in wmii, this has been fixed now. The aspect ratio algorithm is going to be slightly changed, after this I think it will be time for 3.6. Regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] dzen-0.3
On 2/20/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: On Tue, Feb 20, 2007 at 12:27:27AM +, Julian Romero wrote: > Regarding the icon, what I want is a quick indicator to know if the text > that popped-up is worth reading right now or it can wait. This can be > combined with the ability to stack dzens: if a message is ultra-important it > will show the corresponding icon and will dismisses only when clicked. Oh, never consider adding icons - you end with scalability issues, handling of different formats, linking to crappy libraries etc. - use a decent color scheme for urgent messages instead. How easy is to mix 2 fonts in the message? Is there any font that render as symbols? This can do the trick while not sucking too much...the messages will be a first (last) symbol character plus the message all with a contrast color combination. -- Julián
Re: [dwm] dzen-0.3
On Mon, Feb 19, 2007 at 11:25:18PM +0100, Robert Manea wrote:
> P.P.S: I'll test this version and if it is a stayer i'll add a geometry
>option and maybe a progress bar
I won't add geometry if I were you, I think its pretty
convenient to let those thing appear at the bottom or top and
nowhere else cluttering the client area with notifications (like
nasty popup dialogues). I also think you shouldn't implement a
progress bar - people who are smart know how to use dzen like a
statusbar if they need it (- if dzen supports reading from stdin
like dwm, you can do following to have a status bar:
{
echo [=== ]
do what you like
echo [=== ]
do what you like
echo [= ]
do what you like
echo [==]
} | dzen
Regards,
--
Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] dzen-0.3
On Tue, Feb 20, 2007 at 12:27:27AM +, Julian Romero wrote: > Regarding the icon, what I want is a quick indicator to know if the text > that popped-up is worth reading right now or it can wait. This can be > combined with the ability to stack dzens: if a message is ultra-important it > will show the corresponding icon and will dismisses only when clicked. Oh, never consider adding icons - you end with scalability issues, handling of different formats, linking to crappy libraries etc. - use a decent color scheme for urgent messages instead. Regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] dzen-0.3
Fixed with dzen-0.7 , thanks :) On Mon, 2007-02-19 at 15:38 +0100, lobzang wrote: > Hi, > Thanks for the tool, really good. > > Just a little problem I experience , dzen is taking much cpu > (around 80%) > > Here is result of top command : > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ > COMMAND > > 22605 lobzang 25 0 2708 956 792 R 81.2 0.1 0:20.95 > dzen > > > Lobzang. > > > > On Mon, 2007-02-19 at 15:22 +0100, Robert Manea wrote: > > > * Alexandre Boily ([EMAIL PROTECTED]) wrote: > > Hi, > > > > > Dzen works very well for me, except for the fact that it exits with a > > > segmentation fault... > > > > I cannot reproduce the segfault here, maybe you can send me a core dump? > > > > > By the way, you had a great idea by coding dzen. I look forward for > > > further > > > developments! > > > > Thanks :). > > > > I did some code cleanup to have it look less messy and 'dzen' will now > > remove trailing CRs, as Antoni Grzymala suggested. I think this is sane > > as we don't handle CRs at all. > > > > Get it here: > > http://gotmor.googlepages.com/dzen-0.5.tar.gz > > > > Bye, Rob > > > >
