Re: [dwm] Virtual keyboards
Hi Peter, 2009/1/31 Peter Hartlich sg...@hartlich.com: I like this patch and will apply it to 5.4 which is going to be released until the weekend. One problem with it is that you don't really know where keyboard input will be going (dwm being focus-follows-mouse by default). I use another patch on top of that (attached) to draw a selfgcolor border around the last focusable window when an unfocusable window is selected, but I'm not sure recycling selfgcolor is kosher... Plus you may want to rename focus() to selectwin() or something. I see. I think the whole unfocussable stuff needs further thinking before going mainstream. I'm going to release 5.4 now. It appears to me that both the onscreen keyboard and the client with the input focus should have a selfg border -- at least that makes most sense in my opinion. Introducing another couple just for that sounds quite over-engineered to me. I should get broadband today that I'll be ack online and can support questions regarding my upcoming st and libtg release. So, when's the st release and does libtg (if that's the name of the not-completely-secret project) use XCB? :) Well, I changed my mind several times during the last weeks. When I get time I end up thinking that several decisions I made are wrong by nature... but I will come up with one way or another soon. I'm not too convinced libtg as it is (X abstraction primitives + text format processing + parts of text window abstractions and input handling) is the right way to go. I feel remembered at the wmii times, when wmii was screwed up due to depending on its 9P scripting interface. I believe I did the same journey with st making it dependent on libtg, and I tend to revert this mistake at the moment. Kind regards, --Anselm
[dwm] dwm-5.4
Hi there, I'm glad to announce the new dwm-5.4 release which can be downloaded from: http://code.suckless.org/dl/dwm/dwm-5.4.tar.gz This release doesn't draw any borders around tiled clients if there is only 1 tiled client in the view. This saves some extra space of screen real estate for the application in use -- and provides a hint in monocle layout if there are more clients managed by dwm or not. Kind regards, --Anselm
Re: [dwm] dwm-5.4
dwm-5.4, (c) 2006-2008 dwm engineers, see LICENSE for details At least in Russia it's 2009th now ._. //wbr, ojab On Sun, Feb 8, 2009 at 12:58 PM, Anselm R Garbe garb...@gmail.com wrote: Hi there, I'm glad to announce the new dwm-5.4 release which can be downloaded from: http://code.suckless.org/dl/dwm/dwm-5.4.tar.gz This release doesn't draw any borders around tiled clients if there is only 1 tiled client in the view. This saves some extra space of screen real estate for the application in use -- and provides a hint in monocle layout if there are more clients managed by dwm or not. Kind regards, --Anselm
[dwm] spawn terminal with current view information
Hi, I read this * Marcin Cieslak sa...@system.pl [2009-02-08 05:42]: The only slight problem that all windows get tagged in the tag 1 after restart, since dwm has no clue what was the previous tag assignement. How this internal dwm 'state' could be passed over to the new instance? on the thread for crash-only software, and it remind me to my wish to, for example, *name* terminal windows dependent on the current dwm view when they are spawned. I mean sth like urxvtcd -name view_name Is there a way to do this? In almost all of my use cases, this would be the solution to what Marcin complains about -- the windows would have their internal state, i.e. labels, which can be used by dwm to tag them correctly according to config.h. Most of my windows are named so that dwm can tag them correctly, but sometimes I need some additional ones, and I would like them to stay where they were created. It might be a matter of preference, whether to see *which tag a window belongs to* as dwm or window state. IMO, dwm is intended to represent user's idea of assigning tags to windows -- based on tasks, or importance, or whatever logic which is held in config.h --, and *what does one use a window for* is a kind of window's internal state. Just my two euro-cents :o) -- cheers stanio_
Re: [dwm] dwm-5.4
This release doesn't draw any borders around tiled clients if there is only 1 tiled client in the view. This saves some extra space of screen real estate for the application in use -- and provides a hint in monocle layout if there are more clients managed by dwm or not. Hi, I think this isn't working as expected, try the next scenario: 1. We have a view with 2 tiled clients 2. We toggle to floating layout one of them. So, we have a tiled client with no border and a floating client with border. 3. We toggle to floating layout the other one. And now, we have two floating clients, one with border and one with no border. Maybe, number of visible clients should be used instead of number of tiled clients when calling showhide(). Kind Regards, Nibble
Re: [dwm] dwm-5.4
Ok, I hope that's fixed in 5.4.1. Kind regards, Anselm 2009/2/8 Nibble nibble...@gmail.com: This release doesn't draw any borders around tiled clients if there is only 1 tiled client in the view. This saves some extra space of screen real estate for the application in use -- and provides a hint in monocle layout if there are more clients managed by dwm or not. Hi, I think this isn't working as expected, try the next scenario: 1. We have a view with 2 tiled clients 2. We toggle to floating layout one of them. So, we have a tiled client with no border and a floating client with border. 3. We toggle to floating layout the other one. And now, we have two floating clients, one with border and one with no border. Maybe, number of visible clients should be used instead of number of tiled clients when calling showhide(). Kind Regards, Nibble
[dwm] dwm-5.4.1
Hi there, a bugfix release: http://code.suckless.org/dl/dwm/dwm-5.4.1.tar.gz Kind regards, --Anselm
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Sun, Feb 08, 2009 at 05:24:52PM +0800, bill lam wrote:
On Mon, 26 Jan 2009, Marc Andre Tanner wrote:
* Scrollback support
By default 500 lines scrollback history is preserved, this can
be changed in config.h or overridden by the -h command line option
at runtime.
Scrolling is done with Mod+PageUp and Mod+PageDown.
I would like to use shift+pageup/down provided by xterm, is there any
option to use that function directly, instead of dvtm's mod+pageup
(rather inconvenient when scrollback continuously)
The xterm functionality should obviously still work but doesn't make
that much sense because it will scroll the whole display area and not
just the currently focused dvtm window.
Or would you just like to use the same key combination as in xterm?
This can be adjusted in config.h, however I doubt that
shift+Page{Up,Down} will work.
Regards,
Marc
--
Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dwm] Virtual keyboards
Hi Anselm,
It appears to me that both the onscreen keyboard and the client with
the input focus should have a selfg border -- at least that makes most
sense in my opinion.
But you need to be able to distinguish between dwm's _selected_ (for
tagging, closing etc.) client and X's _focused_ client. Killing your
terminal window on accident could be awful.
Introducing another couple just for that sounds quite over-engineered
to me.
Agreed.
What I would propose is the attached series of patches for hg import:
The first renames focus() to selclient() and focusstack() to selstack().
The second adds a new focus() function calling XSetInputFocus() and
saving the client in a global foc (analogue to sel) variable; it then
implements isfocusable based on the Gottox port + selfgcolor border
for focused, but unselected windows.
By the way, your last commits have a...@null as the author?
Regards,
Peter
From 21a07081c462ba83851d4bc120fd02be3692fe7a Mon Sep 17 00:00:00 2001
From: Peter Hartlich sg...@hartlich.com
Date: Mon, 9 Feb 2009 01:13:29 +0059
Subject: [PATCH 1/2] rename focus to selclient, focusstack to selstack
---
config.def.h |4 +-
dwm.c| 114 +-
2 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/config.def.h b/config.def.h
index bb60471..03dc235 100644
--- a/config.def.h
+++ b/config.def.h
@@ -56,8 +56,8 @@ static Key keys[] = {
{ MODKEY, XK_p, spawn, {.v =
dmenucmd } },
{ MODKEY|ShiftMask, XK_Return, spawn, {.v =
termcmd } },
{ MODKEY, XK_b, togglebar, {0} },
- { MODKEY, XK_j, focusstack, {.i = +1 } },
- { MODKEY, XK_k, focusstack, {.i = -1 } },
+ { MODKEY, XK_j, selstack, {.i = +1 } },
+ { MODKEY, XK_k, selstack, {.i = -1 } },
{ MODKEY, XK_h, setmfact, {.f = -0.05}
},
{ MODKEY, XK_l, setmfact, {.f = +0.05}
},
{ MODKEY, XK_Return, zoom, {0} },
diff --git a/dwm.c b/dwm.c
index db9e9c0..489fe0e 100644
--- a/dwm.c
+++ b/dwm.c
@@ -149,9 +149,7 @@ static void drawsquare(Bool filled, Bool empty, Bool
invert, unsigned long col[C
static void drawtext(const char *text, unsigned long col[ColLast], Bool
invert);
static void enternotify(XEvent *e);
static void expose(XEvent *e);
-static void focus(Client *c);
static void focusin(XEvent *e);
-static void focusstack(const Arg *arg);
static Client *getclient(Window w);
static unsigned long getcolor(const char *colstr);
static long getstate(Window w);
@@ -175,6 +173,8 @@ static void resizemouse(const Arg *arg);
static void restack(void);
static void run(void);
static void scan(void);
+static void selclient(Client *c);
+static void selstack(const Arg *arg);
static void setclientstate(Client *c, long state);
static void setlayout(const Arg *arg);
static void setmfact(const Arg *arg);
@@ -288,7 +288,7 @@ arrange(void) {
for(nt = 0, c = nexttiled(clients); c; c = nexttiled(c-next), nt++);
showhide(stack, nt);
- focus(NULL);
+ selclient(NULL);
if(lt[sellt]-arrange)
lt[sellt]-arrange();
restack();
@@ -329,7 +329,7 @@ buttonpress(XEvent *e) {
click = ClkWinTitle;
}
else if((c = getclient(ev-window))) {
- focus(c);
+ selclient(c);
click = ClkClientWin;
}
@@ -603,9 +603,9 @@ enternotify(XEvent *e) {
if((ev-mode != NotifyNormal || ev-detail == NotifyInferior)
ev-window != root)
return;
if((c = getclient(ev-window)))
- focus(c);
+ selclient(c);
else
- focus(NULL);
+ selclient(NULL);
}
void
@@ -617,29 +617,6 @@ expose(XEvent *e) {
}
void
-focus(Client *c) {
- if(!c || !ISVISIBLE(c))
- for(c = stack; c !ISVISIBLE(c); c = c-snext);
- if(sel sel != c) {
- grabbuttons(sel, False);
- XSetWindowBorder(dpy, sel-win, dc.norm[ColBorder]);
- }
- if(c) {
- if(c-isurgent)
- clearurgent(c);
- detachstack(c);
- attachstack(c);
- grabbuttons(c, True);
- XSetWindowBorder(dpy, c-win, dc.sel[ColBorder]);
- XSetInputFocus(dpy, c-win, RevertToPointerRoot, CurrentTime);
- }
- else
- XSetInputFocus(dpy, root, RevertToPointerRoot, CurrentTime);
- sel = c;
- drawbar();
-}
-
-void
focusin(XEvent *e) { /* there are some broken focus acquiring clients */
XFocusChangeEvent *ev = e-xfocus;
@@ -647,32 +624,6 @@ focusin(XEvent *e) { /* there are
[dwm] displaydate patch for dwm 5.4
The original displaydate patch no longers work for dwm 5.4. I hacked
it and create a new displaydate patch. Please comment if there is any
issue.
--
regards,
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩104 李白 夜泊牛渚懷古
牛渚西江夜 青天無片雲 登舟望秋月 空憶謝將軍
余亦能高詠 斯人不可聞 明朝挂帆席 楓葉落紛紛
--- dwm2/dwm.c 2009-02-09 11:53:19.0 +0800
+++ dwm/dwm.c 2009-02-09 11:56:07.0 +0800
@@ -28,6 +28,7 @@
#include stdlib.h
#include string.h
#include unistd.h
+#include time.h
#include sys/types.h
#include sys/wait.h
#include X11/cursorfont.h
@@ -1204,6 +1205,16 @@
/* main event loop */
XSync(dpy, False);
while(running !XNextEvent(dpy, ev)) {
+ {
+ time_t t;
+
+ t = time(NULL);
+ strftime(stext, sizeof stext - 1, %a %e %b, %I:%M%p,
localtime(t));
+ /* Depending on the implementation of strftime, stext might
+ * not be null terminated. */
+ stext[sizeof stext - 1] = '\0';
+ drawbar();
+ }
if(handler[ev.type])
(handler[ev.type])(ev); /* call handler */
}
