Re: [dwm] dwm's future
2009/4/29 Martin Oppegaard mar...@deathaven.com: On Wed, Apr 29, 2009 at 02:08:20PM +0200, Matthias-Christian Ott wrote: On Wed, Apr 29, 2009 at 01:05:40PM +0200, Martin Oppegaard wrote: On Wed, Apr 29, 2009 at 12:58:23PM +0200, Preben Randhol wrote: On Wed, 29 Apr 2009 10:45:35 +0200 Martin Oppegaard mar...@deathaven.com wrote: On Wed, Apr 29, 2009 at 10:35:12AM +0200, Preben Randhol wrote: On Wed, 29 Apr 2009 10:25:55 +0200 Martin Oppegaard mar...@deathaven.com wrote: I like free software. But not GPL? It's just another lock in which is getting too big. Sure, if you want to make proprietary software... If you want to be free from wacko organisations. Are you sure, you know what you are talking about? At least all people I know from Free Software Foundation Europe are quite friendly and really care about Free Software and fight actively against proprietary software. They are by no means wackos. Of course they are! I'm just being sceptical. But as mentioned this discussion could go on and on without a result. -- Preben Randhol Regards, Matthias-Christian All opensource license are crap, don't use any of them, keep you're source secure by not publishing it. I mean, these guys who use open source have apparently a very small penis. my 2 cents. -- http://gnuffy.chaotika.org - Real Community Distro
Re: [dwm] dwm's future
Hi there ! 2009/4/27, Anselm R Garbe garb...@gmail.com: Thanks for all the valueable input so far in this thread. I think here are the action points: 1) I plan to separate the bar stuff code-wise into two portions -- the tag bar with tags and layout info, and the title/status bar, but things will stay as they are from a user perspective, it's just some code cleanup which allows replacing the tagbar and/or title/status bar with something else (or avoiding to compile it in) Nice idea. I ever thought dwm's status bar is to deep in the code. There might be possible pango/cairo implementations of this stuff, I plan to have a font API interface, something like libsfont which is used by dwm and dmenu to start with, and which depends on either Xlib or some more fancy sucking stuff optionally. I would prefer plain xlib, but otherwise, as you said, it really sucks for fonthandling. So, yea, it's ok for me :) 2) I need to investigate into the reparent stuff first, I really dislike going the reparent route, because each parent window consumes much more X resource memory (basically twice the buffer sizes as we have already if you use a reparenting WM -- this makes everything slower). I really think bug the authors of the broken apps to fix their apps that they do not assume a reparenting WM. So the action here is: let's make a list of all apps which are known to be broken and behaving strange with dwm first, that I can investigate. - Mathematica (Version?) - ... please provide input What about an compile time switch which turns reparenting on and off globally? I don't see any sense to differ between broken and not broken apps clientwise. This would add to much complexity. And I believe someone who uses Mathematica should not care about some KB of stuctures. Otherwise on an embedded device where one need every free kb, nobody would use these kinds of apps. 3) I agree multihead has got some preference, I like the approach to assign certain tags to specific screens. You already tried this between 4.7 and 4.8. That was the time I detached my branch, because there was just no sane way to implement it. I prefere the approach of dwm-gtx, because it's very simple and does not fuck up the tagging concept. Kind regards, Anselm -- http://gnuffy.chaotika.org - Real Community Distro
Re: [dwm] dwm's future
Hi There! 3. A third idea for legacy support is, that I tend to add a compile-time option or a specific Rule extension that let's you set to reparent all clients or certain clients which are broken such as Mathematica or various Swing apps, though I'm not absolutely sure how likely that is. Somehow my inner feelings are against it, because it's not a dwm problem and those broken apps should be fixed. I believe that a compile time switch in rules is unneccessary. If we want to support these b0rken apps, why not reparent any client? regard Gottox
Re: [dwm] Tag events
What are tag events? Never heard of it. 2009/4/17, Bartosz Nitkiewicz bartosz.nitkiew...@dziq.pl: I'm wondering how to set up tag events. I had this feature before, but suddenly disappeared. -- http://gnuffy.chaotika.org - Real Community Distro
Re: [dwm] Gaps
I would recommended setting sw and sx in setup() and ww and wx in updategeom() to the disired values. 2009/3/13, Anselm R Garbe garb...@gmail.com: 2009/3/13 anonymous anonym...@id.ru: Is it possible to add, for example, left side gap? Yes, have a look at tile() and change it in order to use w- instead of 0 as offset. Kind regards, --Anselm -- http://gnuffy.chaotika.org - Real Community Distro
Re: [dwm] Suckess Code Management
1. Window Manager = dwm-gtx 2. Shell = zsh 3. Texteditor = vim 4. Calender = cal / vim 5. VCS = mercurial 8. Chat = irssi/bitlbee 9. Music = mpd / ncmpc 10. Terminal = rxvt-unicode 11. Debugger = gdb/valgrind 2009/3/12, Jorge Vargas jorge.var...@gmail.com: On Thu, Mar 12, 2009 at 3:51 AM, Alan Busby thebu...@thebusby.com wrote: How do suckless members code? How do they manage multiple files? Bug reports, etc? I'm very curious to hear how others respond so I might as well pitch in too; same here, maybe a wiki page :) here is mine, please note I'm primarily a python programmer oriented to web development. (I know you guys hate the web :p) 1. Window Manager = dwm(virtualized ubuntu)/macox 2. File Manager = bash/finder 3. Text Editor = vim 4. Calendar/Todo = ical/gmail/trac/google cal/ * 5. File search = grep 6. VCS = hg, svn when forced 7. Email = gmail 8. Chat = xchat/colloquy * 9. Music = None * 10. Terminal = Tilda (testing) 11. Terminal manager = screen ** 12. Debugger = unittest (nose) / firefox / firebug 13. Build = doesn't applies really but for distribution (setup.py/paver/make) 14. environment manager = virtualenv + pip * need to work on making it suckless ** need to learn how to use them -- http://www.gnuffy.chaotika.org - Real Community Distro
[dwm] [PATCH] remove sizehints argument in resize()
Hi!
I wrote a patch which removes the last argument from resize(). This is
handled now directly in applysizehints(). What do you think about it?
regards
Gottox
--
http://www.gnuffy.chaotika.org - Real Community Distro
diff -r b4e7c220422d dwm.c
--- a/dwm.c Sat Feb 21 19:20:11 2009 +
+++ b/dwm.c Mon Mar 02 20:55:27 2009 +0100
@@ -129,6 +129,7 @@
/* function declarations */
static void applyrules(Client *c);
+static void applysizehints(Client *c, int *w, int *h);
static void arrange(void);
static void attach(Client *c);
static void attachstack(Client *c);
@@ -169,7 +170,7 @@
static Client *nexttiled(Client *c);
static void propertynotify(XEvent *e);
static void quit(const Arg *arg);
-static void resize(Client *c, int x, int y, int w, int h, Bool sizehints);
+static void resize(Client *c, int x, int y, int w, int h);
static void resizemouse(const Arg *arg);
static void restack(void);
static void run(void);
@@ -271,6 +272,58 @@
}
void
+applysizehints(Client *c, int *w, int *h) {
+ Bool baseismin;
+
+ if(!resizehints !c-isfloating)
+ return;
+
+ /* see last two sentences in ICCCM 4.1.2.3 */
+ baseismin = c-basew == c-minw c-baseh == c-minh;
+
+ /* set minimum possible */
+ *w = MAX(1, *w);
+ *h = MAX(1, *h);
+
+ if(!baseismin) { /* temporarily remove base dimensions */
+ *w -= c-basew;
+ *h -= c-baseh;
+ }
+
+ /* adjust for aspect limits */
+ if(c-mina 0 c-maxa 0) {
+ if(c-maxa (float)*w / *h)
+ *w = *h * c-maxa;
+ else if(c-mina (float)*h / *w)
+ *h = *w * c-mina;
+ }
+
+ if(baseismin) { /* increment calculation requires this */
+ *w -= c-basew;
+ *h -= c-baseh;
+ }
+
+ /* adjust for increment value */
+ if(c-incw)
+ *w -= *w % c-incw;
+ if(c-inch)
+ *h -= *h % c-inch;
+
+ /* restore base dimensions */
+ *w += c-basew;
+ *h += c-baseh;
+
+ *w = MAX(*w, c-minw);
+ *h = MAX(*h, c-minh);
+
+ if(c-maxw)
+ *w = MIN(*w, c-maxw);
+
+ if(c-maxh)
+ *h = MIN(*h, c-maxh);
+}
+
+void
arrange(void) {
unsigned int nt;
Client *c;
@@ -931,7 +984,7 @@
Client *c;
for(c = nexttiled(clients); c; c = nexttiled(c-next)) {
- resize(c, wx, wy, ww - 2 * c-bw, wh - 2 * c-bw, resizehints);
+ resize(c, wx, wy, ww - 2 * c-bw, wh - 2 * c-bw);
}
}
@@ -979,7 +1032,7 @@
togglefloating(NULL);
}
if(!lt[sellt]-arrange || c-isfloating)
- resize(c, nx, ny, c-w, c-h, False);
+ resize(c, nx, ny, c-w, c-h);
break;
}
}
@@ -1035,54 +1088,10 @@
}
void
-resize(Client *c, int x, int y, int w, int h, Bool sizehints) {
+resize(Client *c, int x, int y, int w, int h) {
XWindowChanges wc;
- if(sizehints) {
- /* see last two sentences in ICCCM 4.1.2.3 */
- Bool baseismin = c-basew == c-minw c-baseh == c-minh;
-
- /* set minimum possible */
- w = MAX(1, w);
- h = MAX(1, h);
-
- if(!baseismin) { /* temporarily remove base dimensions */
- w -= c-basew;
- h -= c-baseh;
- }
-
- /* adjust for aspect limits */
- if(c-mina 0 c-maxa 0) {
- if(c-maxa (float)w / h)
- w = h * c-maxa;
- else if(c-mina (float)h / w)
- h = w * c-mina;
- }
-
- if(baseismin) { /* increment calculation requires this */
- w -= c-basew;
- h -= c-baseh;
- }
-
- /* adjust for increment value */
- if(c-incw)
- w -= w % c-incw;
- if(c-inch)
- h -= h % c-inch;
-
- /* restore base dimensions */
- w += c-basew;
- h += c-baseh;
-
- w = MAX(w, c-minw);
- h = MAX(h, c-minh);
-
- if(c-maxw)
- w = MIN(w, c-maxw);
-
- if(c-maxh)
- h = MIN(h, c-maxh);
- }
+ applysizehints(c, w, h);
if(w = 0 || h = 0)
return;
if(x sx + sw)
@@ -1147,7 +1156,7 @@
togglefloating(NULL);
}
if(!lt[sellt]-arrange || c-isfloating)
- resize(c, c-x, c-y, nw, nh, True);
+ resize(c, c-x, c-y, nw, nh);
[dwm] [PATCH] spltting resizehints from resize()
Hi!
I wrote a small patch which splits the resizehints from resize and
puts it into its own function. This makes resizehints more reusable
for efficienter tiling algorythms.
regards
Gottox
--
http://www.gnuffy.chaotika.org - Real Community Distro
diff -r b4e7c220422d dwm.c
--- a/dwm.c Sat Feb 21 19:20:11 2009 +
+++ b/dwm.c Sat Feb 28 09:02:52 2009 +0100
@@ -129,6 +129,7 @@
/* function declarations */
static void applyrules(Client *c);
+static void applysizehints(Client *c, int *w, int *h);
static void arrange(void);
static void attach(Client *c);
static void attachstack(Client *c);
@@ -271,6 +272,55 @@
}
void
+applysizehints(Client *c, int *w, int *h) {
+ Bool baseismin;
+
+ /* see last two sentences in ICCCM 4.1.2.3 */
+ baseismin = c-basew == c-minw c-baseh == c-minh;
+
+ /* set minimum possible */
+ *w = MAX(1, *w);
+ *h = MAX(1, *h);
+
+ if(!baseismin) { /* temporarily remove base dimensions */
+ *w -= c-basew;
+ *h -= c-baseh;
+ }
+
+ /* adjust for aspect limits */
+ if(c-mina 0 c-maxa 0) {
+ if(c-maxa (float)*w / *h)
+ *w = *h * c-maxa;
+ else if(c-mina (float)*h / *w)
+ *h = *w * c-mina;
+ }
+
+ if(baseismin) { /* increment calculation requires this */
+ *w -= c-basew;
+ *h -= c-baseh;
+ }
+
+ /* adjust for increment value */
+ if(c-incw)
+ *w -= *w % c-incw;
+ if(c-inch)
+ *h -= *h % c-inch;
+
+ /* restore base dimensions */
+ *w += c-basew;
+ *h += c-baseh;
+
+ *w = MAX(*w, c-minw);
+ *h = MAX(*h, c-minh);
+
+ if(c-maxw)
+ *w = MIN(*w, c-maxw);
+
+ if(c-maxh)
+ *h = MIN(*h, c-maxh);
+}
+
+void
arrange(void) {
unsigned int nt;
Client *c;
@@ -1038,51 +1088,8 @@
resize(Client *c, int x, int y, int w, int h, Bool sizehints) {
XWindowChanges wc;
- if(sizehints) {
- /* see last two sentences in ICCCM 4.1.2.3 */
- Bool baseismin = c-basew == c-minw c-baseh == c-minh;
-
- /* set minimum possible */
- w = MAX(1, w);
- h = MAX(1, h);
-
- if(!baseismin) { /* temporarily remove base dimensions */
- w -= c-basew;
- h -= c-baseh;
- }
-
- /* adjust for aspect limits */
- if(c-mina 0 c-maxa 0) {
- if(c-maxa (float)w / h)
- w = h * c-maxa;
- else if(c-mina (float)h / w)
- h = w * c-mina;
- }
-
- if(baseismin) { /* increment calculation requires this */
- w -= c-basew;
- h -= c-baseh;
- }
-
- /* adjust for increment value */
- if(c-incw)
- w -= w % c-incw;
- if(c-inch)
- h -= h % c-inch;
-
- /* restore base dimensions */
- w += c-basew;
- h += c-baseh;
-
- w = MAX(w, c-minw);
- h = MAX(h, c-minh);
-
- if(c-maxw)
- w = MIN(w, c-maxw);
-
- if(c-maxh)
- h = MIN(h, c-maxh);
- }
+ if(sizehints)
+ applysizehints(c, w, h);
if(w = 0 || h = 0)
return;
if(x sx + sw)
[dwm] dwm and virt-manager
Hi! I got a very strange effect using virt-manager with dwm. The main-window doesn't get managed by dwm. I tried to debug dwm with gdb. It looks like the mainwindow gets create multiple times, sometimes it's managed sometimes not. Unfortunally while debugging it's managed most of the times, so it looks like a race condition. Does someone else using virt-manager with similiar effects? regards Gottox -- http://www.gnuffy.chaotika.org - Real Community Distro
