[dev] [dwm] Useless Gaps Are Useful
Hi, In my opinion, the concept of gap between frames should be part of dwm. The existing patches are not solid enough. Having no gaps (the current situation) is just a particular case. Try removing margins from a book: it certainly will destroy readability. Greetings, -- Bastien
Re: [dev] [dmenu] No x, y, w options?
Hey, On 2 December 2011 19:12, Bastien Dejean nihilh...@gmail.com wrote: (Of course I'm referring to the options of the same name already available in dzen2.) It would be more sensible to have a single '-g' flag, for geometry, which would take an X geometry string. I did write a patch a while back which did this, but I don't know where I put it. I also didn't find it at all useful, and some of the code was a bit ugly. What would be the use case for this? On 2 December 2011 20:12, Bjartur Thorlacius svartma...@gmail.com wrote: Why choose window placement and dimensions at exec, instead of letting the window manager handle the issue? Just set _NET_WM_WINDOW_TYPE to _NET_WM_WINDOW_TYPE_DIALOG and spend engineering time ranting about WM_TRANSIENT_FOR, modality and modularity instead. DIALOG wouldn't work, because dmenu would be given silly decorations c. I think if we were to go down this route we'd have to go with DOCK and use _NET_WM_STRUT_PARTIAL. Not sure that's a good idea, though. dmenu's override-redirect flag has always annoyed me, as well as grabbing the whole keyboard rendering it temporarily unusable for anything but typing text into dmenu or escaping out of it. I would think that moving one's mouse unfocusing dmenu would be annoying. But if someone were to write a patch I would try it out. Thanks, cls
Re: [dev] [dmenu] No x, y, w options?
Connor Lane Smith: I also didn't find it at all useful, and some of the code was a bit ugly. What would be the use case for this? Well, it's useful when one wants to (properly) place dmenu at the optical center of the screen and eventually add some incredibly necessary margins. dmenu's default position make it looks like a status bar. Of course, I'm using a patched x, y, w version. (But I failed to add *inner margins*, any help?) Greetings, -- Bastien
Re: [dev] [dmenu] No x, y, w options?
Bjartur Thorlacius: grabbing the whole keyboard rendering it temporarily unusable for anything but typing text into dmenu or escaping out of it. Yes, it's extremely annoying and alas, it's not just dmenu, many programs have the *input black hole* feature. Cheers, -- Bastien
Re: [dev] [dwm] Useless Gaps Are Useful
On 12/3/11, Bastien Dejean nihilh...@gmail.com wrote: In my opinion, the concept of gap between frames should be part of dwm. The existing patches are not solid enough. Having no gaps (the current situation) is just a particular case. I consider gaps between frames as a valid and preferable substitute for borders. I despise borders adjacent to monitor edges, especially in monocle mode, where borders serve no purpose. I do have code somewhere in another town, but the patch is trivial enough.
Re: [dev] [dmenu] No x, y, w options?
On 12/3/11, Bastien Dejean nihilh...@gmail.com wrote: Well, it's useful when one wants to (properly) place dmenu at the optical center of the screen and eventually add some incredibly necessary margins. Which is exactly what _NET_WM_WINDOW_TYPE_DIALOG is for. Note that doing this in the WM is the only way to do decoration (or preferably lack thereof), placement and sizing consistently. Just because dwm lacks support for many window types doesn't mean window types are inherently evil.
Re: [dev] [dwm] Useless Gaps Are Useful
+--- Bjartur Thorlacius ---+ On 12/3/11, Bastien Dejean nihilh...@gmail.com wrote: In my opinion, the concept of gap between frames should be part of dwm. The existing patches are not solid enough. Having no gaps (the current situation) is just a particular case. I consider gaps between frames as a valid and preferable substitute for borders. I despise borders adjacent to monitor edges, especially in monocle mode, where borders serve no purpose. I do have code somewhere in another town, but the patch is trivial enough. i use a 14px border with the same color as my term bgcolor as a substitute for padding ... actually i think that my term should take care of that?
Re: [dev] [dwm] Useless Gaps Are Useful
*internalBorder?? On Dec 3, 2011 8:00 AM, Yoshi Rokuko yo...@rokuko.net wrote: +--- Bjartur Thorlacius ---+ On 12/3/11, Bastien Dejean nihilh...@gmail.com wrote: In my opinion, the concept of gap between frames should be part of dwm. The existing patches are not solid enough. Having no gaps (the current situation) is just a particular case. I consider gaps between frames as a valid and preferable substitute for borders. I despise borders adjacent to monitor edges, especially in monocle mode, where borders serve no purpose. I do have code somewhere in another town, but the patch is trivial enough. i use a 14px border with the same color as my term bgcolor as a substitute for padding ... actually i think that my term should take care of that?
Re: [dev] [dmenu] No x, y, w options?
The mailing list post where a patch for this was posted last time:
http://lists.suckless.org/dev/1108/9190.html
That seems to be doing fine for me, and works fine with 4.4.1, so maybe
just use something to this effect (ish?).
Then again, your mileage may vary, depending on your use. I set mine up to
place itself in my DWM bar just after the ASCII icon for my tiling mode.
Think AwesomeWM's run bar style, except this covers up the window title
rather than shifting it right.
On Sat, Dec 3, 2011 at 9:14 AM, Peter John Hartman
peterjohnhart...@gmail.com wrote:
It would be more sensible to have a single '-g' flag, for geometry,
which would take an X geometry string. I did write a patch a while
back which did this, but I don't know where I put it. I also didn't
find it at all useful, and some of the code was a bit ugly. What would
be the use case for this?
diff -r 6341d6b4c23f config.mk
--- a/config.mk Mon Oct 17 10:22:23 2011 +0100
+++ b/config.mk Wed Oct 19 14:17:18 2011 +0100
@@ -18,7 +18,7 @@
# flags
CPPFLAGS = -D_BSD_SOURCE -DVERSION=\${VERSION}\ ${XINERAMAFLAGS}
-CFLAGS = -ansi -pedantic -Wall -Os ${INCS} ${CPPFLAGS}
+CFLAGS = -ansi -pedantic -Wall -Wextra -Os ${INCS} ${CPPFLAGS}
LDFLAGS = -s ${LIBS}
# compiler and linker
diff -r 6341d6b4c23f dmenu.c
--- a/dmenu.c Mon Oct 17 10:22:23 2011 +0100
+++ b/dmenu.c Wed Oct 19 14:17:18 2011 +0100
@@ -39,15 +39,16 @@
static void usage(void);
static char text[BUFSIZ] = ;
-static int bh, mw, mh;
static int inputw, promptw;
static size_t cursor = 0;
static const char *font = NULL;
+static const char *geom = NULL;
static const char *prompt = NULL;
static const char *normbgcolor = #cc;
static const char *normfgcolor = #00;
static const char *selbgcolor = #0066ff;
static const char *selfgcolor = #ff;
+static unsigned int bh, mw, mh;
static unsigned int lines = 0;
static unsigned long normcol[ColLast];
static unsigned long selcol[ColLast];
@@ -85,6 +86,8 @@
else if(i+1 == argc)
usage();
/* double flags */
+ else if(!strcmp(argv[i], -g))
+ geom = argv[++i];
else if(!strcmp(argv[i], -l))
lines = atoi(argv[++i]);
else if(!strcmp(argv[i], -p))
@@ -511,8 +514,12 @@
bh = dc-font.height + 2;
lines = MAX(lines, 0);
mh = (lines + 1) * bh;
+ if(geom) {
+ XParseGeometry(geom, x, y, mw, mh);
+ lines = (mh / bh)-1;
+ }
#ifdef XINERAMA
- if((info = XineramaQueryScreens(dc-dpy, n))) {
+ else if((info = XineramaQueryScreens(dc-dpy, n))) {
int i, di;
unsigned int du;
Window w, dw;
@@ -531,9 +538,8 @@
mw = info[i].width;
XFree(info);
}
- else
#endif
- {
+ else {
x = 0;
y = topbar ? 0 : DisplayHeight(dc-dpy, screen) - mh;
mw = DisplayWidth(dc-dpy, screen);
On 2 December 2011 20:12, Bjartur Thorlacius svartma...@gmail.com
wrote:
Why choose window placement and dimensions at exec, instead of letting
the window manager handle the issue? Just set _NET_WM_WINDOW_TYPE to
_NET_WM_WINDOW_TYPE_DIALOG and spend engineering time ranting about
WM_TRANSIENT_FOR, modality and modularity instead.
DIALOG wouldn't work, because dmenu would be given silly decorations
c. I think if we were to go down this route we'd have to go with DOCK
and use _NET_WM_STRUT_PARTIAL. Not sure that's a good idea, though.
dmenu's override-redirect flag has always annoyed me, as well as
grabbing the whole keyboard rendering it temporarily unusable for
anything but typing text into dmenu or escaping out of it.
I would think that moving one's mouse unfocusing dmenu would be
annoying. But if someone were to write a patch I would try it out.
Why would you move the mouse and not expect it to refocus things? Esp.
since this is how it works everywhere else?
Thanks,
cls
--
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
--
Invalid Argument (iv597)
Re: [dev] [dmenu] Keyboard focus
On 12/3/11, Peter John Hartman peterjohnhart...@gmail.com wrote: Why would you move the mouse and not expect it to refocus things? Esp. since this is how it works everywhere else? To be fair, sloppy focus is generally surprising and annoying if you ever move your pointer. Reaching out for your mouse only to change focus and not sending any ButtonPress events is not a valid use case. If you are a keyboard-only user, focus windows using keyboard shortcuts (either using shortcuts assigned to applications/windows or by repeated Alt-(Shift)-Escaping/^jk). If you are a mouse user (on suckless?), then saving the click on the text box may be mildly convenient. But for any window not keyboard driven, you are likely to wish to click something anyway. Thus it seems keyboard-only users that may or may not interact with windows that expect ButtonPress events could be more productive under a focus-follows-click policy (where focus is changed upon ButtonPress events, but they still allowed to reach the clicked window) or a mouse-agnostic focus policy where focus change is incited by windows or keyboard only.
