[dev] [dwm] Tags vs Monitors

2012-01-12 Thread Thomas Dean 
I've used dwm for about half a year now (3 years of wmii before), and like
it a lot. However, I find that the handling of tags for multiple monitors
keeps disturbing my workflow. Isn't it against the general philosophy of
dwm to assign a definite monitor to each window, and to have separate
tagsets for each monitor?

I usually use tags as a sort of grouping of windows pertaining to certain
tasks. With only one monitor, dwm works wonderfully for me, and I never
have to think about arranging windows. But with two monitors, I constantly
find myself moving windows between the two, and searching for windows that
I lost because I put them on the other monitor, which makes them lose
their previously assigned tags.

I would imagine that the (or my at least) workflow could be much smoother
if there was only one tagset, independently of the number of monitors, and
if there were (a) layout(s) suitable for multi-screen views. The first
useful layout for two monitors that would come to my mind would consist of
two master windows plus one stack on one of the two monitors.

What do you guys think? How do you make efficient use of two monitors? Do
you find the current tag/monitor paradigm useful? I would be very
interested in your opinions.

Best,
TD

Re: [dev] [dwm] Tags vs Monitors

2012-01-12 Thread Petr Šabata 
On Thu, Jan 12, 2012 at 04:16:37PM +0100, Thomas Dean wrote:
 I've used dwm for about half a year now (3 years of wmii before), and like
 it a lot. However, I find that the handling of tags for multiple monitors
 keeps disturbing my workflow. Isn't it against the general philosophy of
 dwm to assign a definite monitor to each window, and to have separate
 tagsets for each monitor?
 
 I usually use tags as a sort of grouping of windows pertaining to certain
 tasks. With only one monitor, dwm works wonderfully for me, and I never
 have to think about arranging windows. But with two monitors, I constantly
 find myself moving windows between the two, and searching for windows that
 I lost because I put them on the other monitor, which makes them lose
 their previously assigned tags.
 
 I would imagine that the (or my at least) workflow could be much smoother
 if there was only one tagset, independently of the number of monitors, and
 if there were (a) layout(s) suitable for multi-screen views. The first
 useful layout for two monitors that would come to my mind would consist of
 two master windows plus one stack on one of the two monitors.
 
 What do you guys think? How do you make efficient use of two monitors? Do
 you find the current tag/monitor paradigm useful? I would be very
 interested in your opinions.
 
 Best,
 TD

I'm just a single monitor user but I think both approaches
have their pros and cons and it depends on the user what
she prefers.  If this behavior was configurable in config.h,
it would be perfect.

-P


pgpuwPMBPT1n4.pgp
Description: PGP signature

Re: [dev] [dwm] Tags vs Monitors

2012-01-12 Thread Justin Pogue 
I actually really prefer it this way because it's a lot more flexible.
 I've tried other WM's and this behavior is the reason I always come
back to DWM.

That said, I like your idea and would love to see it implemented in
the form of a patch.

On Thu, Jan 12, 2012 at 9:16 AM, Thomas Dean 78...@web.de wrote:
 I've used dwm for about half a year now (3 years of wmii before), and like
 it a lot. However, I find that the handling of tags for multiple monitors
 keeps disturbing my workflow. Isn't it against the general philosophy of
 dwm to assign a definite monitor to each window, and to have separate
 tagsets for each monitor?

 I usually use tags as a sort of grouping of windows pertaining to certain
 tasks. With only one monitor, dwm works wonderfully for me, and I never
 have to think about arranging windows. But with two monitors, I constantly
 find myself moving windows between the two, and searching for windows that
 I lost because I put them on the other monitor, which makes them lose
 their previously assigned tags.

 I would imagine that the (or my at least) workflow could be much smoother
 if there was only one tagset, independently of the number of monitors, and
 if there were (a) layout(s) suitable for multi-screen views. The first
 useful layout for two monitors that would come to my mind would consist of
 two master windows plus one stack on one of the two monitors.

 What do you guys think? How do you make efficient use of two monitors? Do
 you find the current tag/monitor paradigm useful? I would be very
 interested in your opinions.

 Best,
 TD

[dev] interested in issue tracker dev

2012-01-12 Thread aecepoglu 
I might be interested in trying to help write one such suckless issue tracker 
as requested on the webpage.

I just want to ask;
What set of features are a must for you?

Thanks,
cheers.

Re: [dev] interested in issue tracker dev

2012-01-12 Thread Anselm R Garbe 
On 12 January 2012 18:34,  aecepo...@gmail.com wrote:
 I might be interested in trying to help write one such suckless issue tracker 
 as requested on the webpage.

 I just want to ask;
 What set of features are a must for you?

Oh what a relief someone wants to volunteer on this idea.

One of the most important things of such a tracker is decent mail
integration in my opinion (as most trackers that have evolved in the
OSS space recently suck very much when it comes to mail integration).

One aspect of this tracker could be to start with a proper mail
archiving system and then writing the web stuff on top. This would
allow proper querying. The mail archiving could be based on a
repository storage (hg or git) instead of some poor database based
system.

All the controlling could be done mail based (similarly to mlmmj perhaps).

What do you think?

Cheers,
Anselm

Re: [dev] [dwm] Tags vs Monitors

2012-01-12 Thread Rob 
On Thu, Jan 12, 2012 at 04:16:37PM +0100, Thomas Dean wrote:
 I would imagine that the (or my at least) workflow could be much smoother
 if there was only one tagset, independently of the number of monitors, and
 if there were (a) layout(s) suitable for multi-screen views. The first
 useful layout for two monitors that would come to my mind would consist of
 two master windows plus one stack on one of the two monitors.

 What do you guys think? How do you make efficient use of two monitors? Do
 you find the current tag/monitor paradigm useful? I would be very
 interested in your opinions.

I had this thought, but how would you implement it? What if you selected
the same tagset on each monitor? You can only display a window in a single
place, so it couldn't be on both monitors at the same time, think about
it. It can't be done unless you can somehow clone the window or something
(I'm not very clued up on X11).

Rob

[dev] [surf] minor fix

2012-01-12 Thread Peter John Hartman 
Hi,

I removed the eval function, and I added spatial as a variable as with
plugins et al.  (Frankly, I hate spatial; why is it default?) Question:
Shouldn't we move spatial, plugins, etc.  into config.def.h?

Best,
Peter

-- 
sic dicit magister P
University of Toronto / Fordham University
Collins Hall B06; Office Hours TF10-12
http://individual.utoronto.ca/peterjh
gpg --keyserver pgp.mit.edu --recv-keys E0DBD3D6 
diff -r 2ea243e2ca82 surf.c
--- a/surf.cSun Nov 20 16:06:38 2011 +0100
+++ b/surf.cThu Jan 12 13:21:37 2012 -0500
@@ -62,7 +62,7 @@
 static gboolean showxid = FALSE;
 static char winid[64];
 static char *progname;
-static gboolean loadimage = 1, plugin = 1, script = 1;
+static gboolean loadimage = 1, plugin = 1, script = 1, spatial = 1;
 
 static char *buildpath(const char *path);
 static void cleanup(void);
@@ -103,7 +103,6 @@
 static void sigchld(int unused);
 static void source(Client *c, const Arg *arg);
 static void spawn(Client *c, const Arg *arg);
-static void eval(Client *c, const Arg *arg);
 static void stop(Client *c, const Arg *arg);
 static void titlechange(WebKitWebView *v, WebKitWebFrame* frame, const char* 
title, Client *c);
 static void update(Client *c);
@@ -529,7 +528,7 @@
g_object_set(G_OBJECT(settings), auto-load-images, loadimage, NULL);
g_object_set(G_OBJECT(settings), enable-plugins, plugin, NULL);
g_object_set(G_OBJECT(settings), enable-scripts, script, NULL);
-   g_object_set(G_OBJECT(settings), enable-spatial-navigation, true, 
NULL);
+   g_object_set(G_OBJECT(settings), enable-spatial-navigation, spatial, 
NULL);
 
g_free(uri);
 
@@ -773,12 +772,6 @@
 }
 
 void
-eval(Client *c, const Arg *arg) {
-   WebKitWebFrame *frame = webkit_web_view_get_main_frame(c-view);
-   evalscript(frame, webkit_web_frame_get_global_context(frame), ((char 
**)arg-v)[0], );
-}
-
-void
 stop(Client *c, const Arg *arg) {
webkit_web_view_stop_loading(c-view);
 }

Re: [dev] interested in issue tracker dev

2012-01-12 Thread Bjartur Thorlacius 

What's wrong with GNATS?

Re: [dev] interested in issue tracker dev

2012-01-12 Thread Anselm R Garbe 
On 12 January 2012 19:58, Bjartur Thorlacius svartma...@gmail.com wrote:
 What's wrong with GNATS?

Nearly everything. GNU, 50kSLOC, etc.

Cheers,
Anselm

Re: [dev] dwm: bug in fullscreen mode (SDL?)

2012-01-12 Thread Eckehard Berns 
On Thu, Jan 12, 2012 at 07:39:53AM +0100, Anselm R Garbe wrote:
 I applied your two patches to tip, this needs to be tested for side effects 
 now.

Ok, I ran into trouble pretty fast. Since the floating windows are never
raised in restack() they won't get raised during normal interaction
either.

I attached a somewhat ugly patch to correct the behavior, but there
might be consequences, too. Instead of simply adding XRaiseWindow() I
replaced calls to restack() in focusstack(), movemouse(), and
resizemouse(). I assume restacking isn't needed there and the calls to
restack() simple where a glorified XRaiseWindow() anyway, but I'm not
too familiar with the dwm code, so I might be wrong.

-- 
Eckehard Berns
diff -r 070112b7435f dwm.c
--- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
+++ b/dwm.c Thu Jan 12 22:07:34 2012 +0100
@@ -907,7 +907,8 @@
}
if(c) {
focus(c);
-   restack(selmon);
+   if (selmon-sel-isfloating)
+   XRaiseWindow(dpy, selmon-sel-win);
}
 }
 
@@ -1227,7 +1228,7 @@
 
if(!(c = selmon-sel))
return;
-   restack(selmon);
+   XRaiseWindow(dpy, selmon-sel-win);
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync, 
GrabModeAsync,
@@ -1371,7 +1372,7 @@
 
if(!(c = selmon-sel))
return;
-   restack(selmon);
+   XRaiseWindow(dpy, selmon-sel-win);
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync, 
GrabModeAsync,
@@ -1738,9 +1739,11 @@
if(!selmon-sel)
return;
selmon-sel-isfloating = !selmon-sel-isfloating || 
selmon-sel-isfixed;
-   if(selmon-sel-isfloating)
+   if(selmon-sel-isfloating) {
resize(selmon-sel, selmon-sel-x, selmon-sel-y,
   selmon-sel-w, selmon-sel-h, False);
+   XRaiseWindow(dpy, selmon-sel-win);
+   }
arrange(selmon);
 }

Re: [dev] dwm: bug in fullscreen mode (SDL?)

2012-01-12 Thread Eckehard Berns 
On Thu, Jan 12, 2012 at 10:23:14PM +0100, Eckehard Berns wrote:
 I attached a somewhat ugly patch to correct the behavior, ...

Oops, we need raising in focusstack() not only for floating windows, but
also if we're in a floating layout. Corrected patch is attached.

-- 
Eckehard Berns
diff -r 070112b7435f dwm.c
--- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
+++ b/dwm.c Thu Jan 12 22:27:51 2012 +0100
@@ -907,7 +907,8 @@
}
if(c) {
focus(c);
-   restack(selmon);
+   if (selmon-sel-isfloating || 
!selmon-lt[selmon-sellt]-arrange)
+   XRaiseWindow(dpy, selmon-sel-win);
}
 }
 
@@ -1227,7 +1228,7 @@
 
if(!(c = selmon-sel))
return;
-   restack(selmon);
+   XRaiseWindow(dpy, selmon-sel-win);
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync, 
GrabModeAsync,
@@ -1371,7 +1372,7 @@
 
if(!(c = selmon-sel))
return;
-   restack(selmon);
+   XRaiseWindow(dpy, selmon-sel-win);
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync, 
GrabModeAsync,
@@ -1738,9 +1739,11 @@
if(!selmon-sel)
return;
selmon-sel-isfloating = !selmon-sel-isfloating || 
selmon-sel-isfixed;
-   if(selmon-sel-isfloating)
+   if(selmon-sel-isfloating) {
resize(selmon-sel, selmon-sel-x, selmon-sel-y,
   selmon-sel-w, selmon-sel-h, False);
+   XRaiseWindow(dpy, selmon-sel-win);
+   }
arrange(selmon);
 }

Re: [dev] interested in issue tracker dev

2012-01-12 Thread markus schnalke 
[2012-01-12 19:06] Anselm R Garbe garb...@gmail.com
 On 12 January 2012 18:34,  aecepo...@gmail.com wrote:
 
  I might be interested in trying to help write one such suckless
  issue tracker as requested on the webpage.
 
  I just want to ask;
  What set of features are a must for you?
 
 Oh what a relief someone wants to volunteer on this idea.
 
 One of the most important things of such a tracker is decent mail
 integration in my opinion (as most trackers that have evolved in the
 OSS space recently suck very much when it comes to mail integration).

What about debbugs? Haven't set it up yet, but used it within Debian
and like its user (mail) interface.

Apart from that, you might want to consider building the issue tracker
on top of MH.


meillo

Re: [dev] [dwm] Tags vs Monitors

2012-01-12 Thread TJ Robotham 
On Thu, Jan 12, 2012 at 04:16:37PM +0100, Thomas Dean wrote:
 But with two monitors, I constantly find myself moving windows between the
 two, and searching for windows that I lost because I put them on the other
 monitor, which makes them lose their previously assigned tags.

You might find it helpful to go into sendmon and delete that one line that
resets the window's tags to whatever's currently visible on the other monitor.
That was pretty much the first thing I did when multihead support was added,
since I rarely want to both move a window between monitors and retag it.

Re: [dev] dwm: bug in fullscreen mode (SDL?)

2012-01-12 Thread Eckehard Berns 
Sorry for spamming the list, but I didn't catch monocle mode with the
last patch. Here is a corrected patch...

-- 
Eckehard Berns
diff -r 070112b7435f dwm.c
--- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
+++ b/dwm.c Thu Jan 12 23:56:15 2012 +0100
@@ -907,6 +907,8 @@
}
if(c) {
focus(c);
+   if (selmon-sel-isfloating || 
!selmon-lt[selmon-sellt]-arrange)
+   XRaiseWindow(dpy, selmon-sel-win);
restack(selmon);
}
 }
@@ -1227,7 +1229,7 @@
 
if(!(c = selmon-sel))
return;
-   restack(selmon);
+   XRaiseWindow(dpy, selmon-sel-win);
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync, 
GrabModeAsync,
@@ -1371,7 +1373,7 @@
 
if(!(c = selmon-sel))
return;
-   restack(selmon);
+   XRaiseWindow(dpy, selmon-sel-win);
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync, 
GrabModeAsync,
@@ -1738,9 +1740,11 @@
if(!selmon-sel)
return;
selmon-sel-isfloating = !selmon-sel-isfloating || 
selmon-sel-isfixed;
-   if(selmon-sel-isfloating)
+   if(selmon-sel-isfloating) {
resize(selmon-sel, selmon-sel-x, selmon-sel-y,
   selmon-sel-w, selmon-sel-h, False);
+   XRaiseWindow(dpy, selmon-sel-win);
+   }
arrange(selmon);
 }

Re: [dev] dwm: bug in fullscreen mode (SDL?)

2012-01-12 Thread Eremite 
Eckehard Berns ecki-suckl...@ecki.to wrote:

 Sorry for spamming the list, but I didn't catch monocle mode with the
 last patch. Here is a corrected patch...

 -- 
 Eckehard Berns

work in combination with barwin-leak.patch

no-raise-float-in-restack.patch work too. dwm-6.0 + SDL-1.2.14 clean