Re: [dev] [Announce] Desktop Entry Launcher
Hi Eric, Thanks for sharing! I recently thought about creating a similar tool that would enhance dex (https://github.com/jceb/dex) which I use to autostart programs during dwm launch. del works graet for me! The one thing I noticed is that I couldn't get del to work at first because it was messing the .del file in $HOME. del: open: /home/jceb/.del: No such file or directory del: dmenu died with exit status 1 It took a while until I figured out that "del -r" would create the missing file. Jan Christoph On Mon 06-02-2017 23:10 -0800, Eric Pruitt wrote: > I use dmenu to run programs, but I did not like that dmenu_run > included every single program included those without GUIs. I > maintained a list of programs manually, then I wrote a script to > generate the list based on whether or not a binary linked to GUI > libraries. Recently, I wrote a C program that uses nftw(3) to find > [desktop entry files][1], parses them and adds them to a list saved at > ~/.del by default. The source is here: > https://github.com/ericpruitt/edge/blob/master/utilities/del.c . I > believe it is POSIX compliant, and I was able to compile it on Linux, > OpenBSD and FreeBSD. > > [1]: > https://specifications.freedesktop.org/desktop-entry-spec/latest/ > > Here's the usage information: > > DEL searches for Freedesktop Desktop Entries, generates a list of > graphical commands and uses dmenu as a front-end so the user can > select a command to execute. > > Exit statuses: > 1Fatal error encountered. > 2Non-fatal error encountered. > > 128The dmenu subprocess was killed by a signal. > > Options: > -h Show this text and exit. > -f PATH Use specified file as the command list. When this is >unspecified, it defaults to ~/.del > -r Search for desktop entries to refresh the command list. >Trailing command line parameters are interpreted as folders to be >searched. Folders on different devices must be explicitly >enumerated because the search will not automatically cross >filesystem boundaries; in terms >of find(1), the search is equivalent to the following: find >$ARGUMENTS -xdev -name '*.desktop' When no paths are given, >"/" is searched by default. A newline-separated list of >programs can be fed to del via stdin to include programs >that do not have desktop entries in the generated launcher >list. The programs must exist in $PATH or they will be >silently ignored. > > When "-r" is not specified, dmenu is launched with the command list > feed into standard input. Trailing command line arguments can be used > to pass flags to dmenu or use a different menu altogether: > > Set the background color of selected text to red: $ del -- -sb > "#ff" > > Use rofi in dmenu mode instead of dmenu: $ del rofi -dmenu > > Please let me know what you think. > > Thanks, Eric > -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev] [PATCH] systray-alpha patch
setclientstate(i, WithdrawnState); > + } > + else > + return; > + sendevent(i-> win, xatom[Xembed], StructureNotifyMask, CurrentTime, > code, 0, > + systray-> win, XEMBED_EMBEDDED_VERSION); > +} > + > +void > +updatesystray(void) > +{ > + XSetWindowAttributes wa; > + XWindowChanges wc; > + Client *i; > + Monitor *m = systraytomon(NULL); > + unsigned int x = m-> mx + m->mw; > + unsigned int w = 1; > + > + if (!showsystray) > + return; > + if (!systray) { > + /* init systray */ > + if (!(systray = (Systray *)calloc(1, sizeof(Systray > + die("fatal: could not malloc() %u bytesn", > sizeof(Systray)); > + wa.event_mask= ButtonPressMask | ExposureMask; > + wa.override_redirect = True; > + wa.background_pixel = scheme[SchemeNorm][ColBg].pixel; > + wa.border_pixel = 0; > + wa.colormap = drw-> cmap; > + systray-> win = XCreateWindow(dpy, root, x, m->by, w, bh, 0, > drw->depth, > + InputOutput, drw-> visual, > + > CWOverrideRedirect|CWBackPixel|CWBorderPixel|CWColormap|CWEventMask, &wa); > + XSelectInput(dpy, systray-> win, SubstructureNotifyMask); > + XChangeProperty(dpy, systray-> win, > netatom[NetSystemTrayOrientation], XA_CARDINAL, 32, > + PropModeReplace, (unsigned char > *)&netatom[NetSystemTrayOrientationHorz], 1); > + XChangeProperty(dpy, systray-> win, > netatom[NetSystemTrayVisual], XA_VISUALID, 32, > + PropModeReplace, (unsigned char *)&drw-> > visual->visualid, 1); > + XMapRaised(dpy, systray-> win); > + XSetSelectionOwner(dpy, netatom[NetSystemTray], systray-> win, > CurrentTime); > + if (XGetSelectionOwner(dpy, netatom[NetSystemTray]) == > systray-> win) { > + sendevent(root, xatom[Manager], StructureNotifyMask, > CurrentTime, netatom[NetSystemTray], systray-> win, 0, 0); > + XSync(dpy, False); > + } > + else { > + fprintf(stderr, "dwm: unable to obtain system tray.n"); > + free(systray); > + systray = NULL; > + return; > + } > + } > + for (w = 0, i = systray-> icons; i; i = i->next) { > + /* make sure the background color stays the same */ > + wa.background_pixel = scheme[SchemeNorm][ColBg].pixel; > + XChangeWindowAttributes(dpy, i-> win, CWBackPixel, &wa); > + XMapRaised(dpy, i-> win); > + w += systrayspacing; > + i-> x = w; > + XMoveResizeWindow(dpy, i-> win, i->x, 0, i->w, i->h); > + w += i-> w; > + if (i-> mon != m) > + i-> mon = m; > + } > + w = w ? w + systrayspacing : 1; > + x -= w; > + XMoveResizeWindow(dpy, systray-> win, x, m->by, w, bh); > + wc.x = x; wc.y = m-> by; wc.width = w; wc.height = bh; > + wc.stack_mode = Above; wc.sibling = m-> barwin; > + XConfigureWindow(dpy, systray-> win, > CWX|CWY|CWWidth|CWHeight|CWSibling|CWStackMode, &wc); > + XMapWindow(dpy, systray-> win); > + XMapSubwindows(dpy, systray-> win); > + /* redraw background */ > + XSetForeground(dpy, drw-> gc, scheme[SchemeNorm][ColBg].pixel); > + XFillRectangle(dpy, systray-> win, drw->gc, 0, 0, w, bh); > + XSync(dpy, False); > } > > void > @@ -2064,6 +2393,16 @@ wintoclient(Window w) > return NULL; > } > > +Client * > +wintosystrayicon(Window w) { > + Client *i = NULL; > + > + if (!showsystray || !w) > + return i; > + for (i = systray-> icons; i && i->win != w; i = i->next) ; > + return i; > +} > + > Monitor * > wintomon(Window w) > { > @@ -2117,6 +2456,22 @@ xerrorstart(Display *dpy, XErrorEvent *ee) > return -1; > } > > +Monitor * > +systraytomon(Monitor *m) { > + Monitor *t; > + int i, n; > + if(!systraypinning) { > + if(!m) > + return selmon; > + return m == selmon ? m : NULL; > + } > + for(n = 1, t = mons; t && t-> next; n++, t = t->next) ; > + for(i = 1, t = mons; t && t-> next && i < systraypinning; i++, t = > t->next) ; > + if(systraypinningfailfirst && n < systraypinning) > + return mons; > + return t; > +} > + > void > zoom(const Arg *arg) > { -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev] new pre-patched version of dwm available
On Sun 24-07-2016 20:42 -0700, Eric Pruitt wrote: > On Sat, Jul 23, 2016 at 05:21:42PM +0200, FRIGN wrote: > > It's a difficult matter because patches interfere. I know of no way > > to make multiple patches inclusive to each other, in many cases it > > is not possible. > > Something I do with my patches to make them easier manually edit the > resulting diffs to reduce lines of context for certain chunks. As a > result, rebasing some of changes on newer versions of dwm becomes a > little less painful. I will also sometimes write code in a less > efficient manner if it means I can produce a patch that won't conflict > with any of my other patches while still applying cleanly to dwm. Have you tried to increase patch's fuzz factor with the --fuzz option in order to achieve the same result? > Up until about a month ago, I kept a copy of the dwm repo that I > periodically merged with the suckless master tree, but I now keep a > repository of patches alone that get applied to dwm using a Makefile > (https://github.com/ericpruitt/mydwm). I never used the rebase model described in the customization section. Since you know both ways, why did you switch to patch files? > More recently, I decided to combine all of my suckless configurations > and GUI-related programs into a single repo that is yet unpublished > but works similarly to the aforementioned link. Here's what the > Makefile for that currently looks like: > https://gist.github.com/ericpruitt/32f3f8b6c3df903d03f5e95ed8ba3428 > I'm using GNU make and taking advantage of the numerous features it > provides. I know that monstrosity is far from suckless, but it works > well, and I've learned a lot about GNU make. Nice work. I keep dwm and other suckless tools as submodules in my personal configuration repositories with simple build and install scripts. A central location to update all tools is something I'm missing in my setup. Jan Christoph -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev] [dmenu] [PATCH] Added option to prompt for passwords
If dmenu could easily be used as a replacement for pinentry my desktop would suck a little less. I'm not aware of many other use cases for entering passwords. Is that possible with your patch? Jan Christoph On Mon 25-07-2016 13:21 -0700, Eric Pruitt wrote: > On Mon, Jul 25, 2016 at 11:14:28PM -1100, mikan wrote: > > I was working on a similar thing but decided that password entry > > doesn't make sense in dmenu context (since it's a menu!) and made a > > separate tool instead and glue pinentry code to it. > > I don't agree with this sentiment -- dmenu happily supports arbitrary > text entry when the thing you want to enter isn't in the list of > presented items. I already use dmenu, so I would much rather maintain > my ~40 line patch than introduce a new tool to my workflow that may > eventually diverge from dmenu in ways I consider undesirable or be > abandoned by its sole maintainer. > > Eric > -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev][patch] Proper window type for dwm and dmenu
Hi Ben, Actually the patch I provided would remove the shadow from dmenu because it would be flagged as "dock". However, I also realized that it might be something useful for dmenu. For dwm I think it's totally useless and it should definitely be flagged as dock. Cheers. Jan Christoph On Sun 24-07-2016 20:41 -0700, Ben Woolley wrote: > Don't be discouraged by the other replies. I have been caught off > guard by a dmenu of my own use being a bit too subtle for me to > notice, and a shadow would have made it more clear that a new object > needs attention. Not sure why anyone would complain about a UI > advancement that is both trivial and backed by years of research. > > > On Jul 24, 2016, at 12:56 PM, Jan Christoph Ebersbach > > wrote: > > > > Hi, > > > > Here are the patches to set _NET_WM_WINDOW_TYPE_DOCK for dwm's bar > > and dmenu. Would someone with commit rights apply them to master? > > > > Thank you. > > > > Jan Christoph > > > > > On Wed 20-07-2016 07:05 +0200, Jan Christoph Ebersbach wrote: > > > > > > Great, thanks for the feeback. I'll provide a patch this week. > > > > > > Jan Christoph > > > > > > > On Tue 19-07-2016 20:47 +0200, v4hn wrote: > > > > > > > > Where's the patch? > > > > > > > > On Tue, Jul 19, 2016 at 07:43:26PM +0200, Jan Christoph > > > > Ebersbach wrote: > > > >> Hi, > > > >> > > > >> I just stumbled upon the compositor compton and came across > > > >> this wiki page that describes that shadows don't work properly > > > >> in combination with dwm and dmenu: > > > >> https://wiki.archlinux.org/index.php/Compton#dwm_.26_dmenu The > > > >> reason for this is that _NET_WM_WINDOW_TYPE and > > > >> _NET_WM_WINDOW_TYPE_DESKTOP aren't set for the bar/menu that is > > > >> drawn. > > > >> > > > >> The closest I could get in my research was > > > >> http://comments.gmane.org/gmane.comp.misc.suckless/7688. dwm > > > >> implements _NET_WM_WINDOW_TYPE for client windows. > > > >> > > > >> Is there a specific reason for not implementing > > > >> _NET_WM_WINDOW_TYPE for dwm and dmenu other than that nobody > > > >> did it so far? I think it's worth the issue because a > > > >> compositor greatly improves window tearing and it would make > > > >> the tools more compatible to the expected behavior. > > > >> > > > >> Btw, here is another issue related to compositors that might be > > > >> worth considering again: > > > >> http://lists.suckless.org/dev/1505/26735.html > > > >> > > > >> Jan Christoph > > > > -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand > > of righteousness that comes from keeping a list of rules when I > > could get the robust kind that comes from trusting Christ - God’s > > righteousness. Phil 3:9 <0001-Mark-barwin-type-as-dock_dwm.patch> > > <0001-Mark-window-type-as-dock_dmenu.patch> > -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev][patch] Proper window type for dwm and dmenu
Hi, Here are the patches to set _NET_WM_WINDOW_TYPE_DOCK for dwm's bar and dmenu. Would someone with commit rights apply them to master? Thank you. Jan Christoph On Wed 20-07-2016 07:05 +0200, Jan Christoph Ebersbach wrote: > Great, thanks for the feeback. I'll provide a patch this week. > > Jan Christoph > > On Tue 19-07-2016 20:47 +0200, v4hn wrote: > > > Where's the patch? > > > > On Tue, Jul 19, 2016 at 07:43:26PM +0200, Jan Christoph Ebersbach > > wrote: > > > Hi, > > > > > > I just stumbled upon the compositor compton and came across this > > > wiki page that describes that shadows don't work properly in > > > combination with dwm and dmenu: > > > https://wiki.archlinux.org/index.php/Compton#dwm_.26_dmenu The > > > reason for this is that _NET_WM_WINDOW_TYPE and > > > _NET_WM_WINDOW_TYPE_DESKTOP aren't set for the bar/menu that is > > > drawn. > > > > > > The closest I could get in my research was > > > http://comments.gmane.org/gmane.comp.misc.suckless/7688. dwm > > > implements _NET_WM_WINDOW_TYPE for client windows. > > > > > > Is there a specific reason for not implementing > > > _NET_WM_WINDOW_TYPE for dwm and dmenu other than that nobody did > > > it so far? I think it's worth the issue because a compositor > > > greatly improves window tearing and it would make the tools more > > > compatible to the expected behavior. > > > > > > Btw, here is another issue related to compositors that might be > > > worth considering again: > > > http://lists.suckless.org/dev/1505/26735.html > > > > > > Jan Christoph > > > -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 From b848f86e84f53c751899ecc9eb6aba960219bcce Mon Sep 17 00:00:00 2001 From: Jan Christoph Ebersbach Date: Sun, 24 Jul 2016 21:22:52 +0200 Subject: [PATCH] Mark barwin type as dock --- dwm.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/dwm.c b/dwm.c index b2bc9bd..4fd3e5c 100644 --- a/dwm.c +++ b/dwm.c @@ -62,7 +62,7 @@ enum { CurNormal, CurResize, CurMove, CurLast }; /* cursor */ enum { SchemeNorm, SchemeSel, SchemeLast }; /* color schemes */ enum { NetSupported, NetWMName, NetWMState, - NetWMFullscreen, NetActiveWindow, NetWMWindowType, + NetWMFullscreen, NetActiveWindow, NetWMWindowType, NetWMWindowTypeDock, NetWMWindowTypeDialog, NetClientList, NetLast }; /* EWMH atoms */ enum { WMProtocols, WMDelete, WMState, WMTakeFocus, WMLast }; /* default atoms */ enum { ClkTagBar, ClkLtSymbol, ClkStatusText, ClkWinTitle, @@ -1576,6 +1576,7 @@ setup(void) netatom[NetWMState] = XInternAtom(dpy, "_NET_WM_STATE", False); netatom[NetWMFullscreen] = XInternAtom(dpy, "_NET_WM_STATE_FULLSCREEN", False); netatom[NetWMWindowType] = XInternAtom(dpy, "_NET_WM_WINDOW_TYPE", False); + netatom[NetWMWindowTypeDock] = XInternAtom(dpy, "_NET_WM_WINDOW_TYPE_DOCK", False); netatom[NetWMWindowTypeDialog] = XInternAtom(dpy, "_NET_WM_WINDOW_TYPE_DIALOG", False); netatom[NetClientList] = XInternAtom(dpy, "_NET_CLIENT_LIST", False); /* init cursors */ @@ -1806,6 +1807,8 @@ updatebars(void) m->barwin = XCreateWindow(dpy, root, m->wx, m->by, m->ww, bh, 0, DefaultDepth(dpy, screen), CopyFromParent, DefaultVisual(dpy, screen), CWOverrideRedirect|CWBackPixmap|CWEventMask, &wa); + XChangeProperty(dpy, m->barwin, netatom[NetWMWindowType], XA_ATOM, 32, +PropModeReplace, (unsigned char *) &netatom[NetWMWindowTypeDock], 1); XDefineCursor(dpy, m->barwin, cursor[CurNormal]->cursor); XMapRaised(dpy, m->barwin); } -- 2.9.0 From 8bd603d31c5d05d01baedc9dcf44fe21adc644dc Mon Sep 17 00:00:00 2001 From: Jan Christoph Ebersbach Date: Sun, 24 Jul 2016 21:37:23 +0200 Subject: [PATCH] Mark window type as dock --- dmenu.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/dmenu.c b/dmenu.c index e926eca..d59ed98 100644 --- a/dmenu.c +++ b/dmenu.c @@ -44,7 +44,7 @@ static struct item *matches, *matchend; static struct item *prev, *curr, *next, *sel; static int mon = -1, screen; -static Atom clip, utf8; +static Atom clip, utf8, type, dock; static Display *dpy; static Window root, win; static XIC xic; @@ -533,6 +533,8 @@ setup(void) clip = XInternAtom(dpy, "CLIPBOARD", False); utf8 = XInternAtom(dpy, "UTF8_STRING", False); + type = XInternAtom(dpy, "_NET_WM_WINDOW_TYPE", False); + dock = XInternAtom(dpy, "_NET_WM_
Re: [dev] new pre-patched version of dwm available
Hi, I also keep a patched version of dwm at github.com/jceb/dwm-patches that stacks all the patches in order to smoothly apply them. This is also how I develop my patch using quilt. Unfortunately, it's extremely hard to port interwoven patches back to mainline. I have some tooling at github.com/jceb/dwm-clean-patches that reduces the pain to the bare minimum but even this is a lot of pain and time. Personally, I'd recommend newbies that want to use a patched version to find someone who's maintaining a "fork". Maybe these "forks" could be listed in the patches section of the wiki. What do you think? Jan Christoph PS: I'll update my share of patches in the next 1-2 weeks to the current HEAD. On Sat 23-07-2016 17:21 +0200, FRIGN wrote: > On Fri, 22 Jul 2016 13:54:36 -0800 Britton Kerin > wrote: > > Hey Britton, > > > dwm needs patches to be good but the patches area is a mess and I > > couln't get along with devs about fixing it, so I thought a > > pre-rolled version of dwm might be useful instead: > > you really raise a valid point, fortunately, as you may know, there > are proceedings to clean up the wiki and the progress is already > pretty good. It's a difficult matter because patches interfere. I > know of no way to make multiple patches inclusive to each other, in > many cases it is not possible. There are some things thought that I'd > like to see in mainline, e.g. removing borders of the window when > there's only one window in the current tag. > > Cheers > > FRIGN > -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev] Proper window type for dwm and dmenu
Great, thanks for the feeback. I'll provide a patch this week. Jan Christoph On Tue 19-07-2016 20:47 +0200, v4hn wrote: > Where's the patch? > > On Tue, Jul 19, 2016 at 07:43:26PM +0200, Jan Christoph Ebersbach > wrote: > > Hi, > > > > I just stumbled upon the compositor compton and came across this > > wiki page that describes that shadows don't work properly in > > combination with dwm and dmenu: > > https://wiki.archlinux.org/index.php/Compton#dwm_.26_dmenu The > > reason for this is that _NET_WM_WINDOW_TYPE and > > _NET_WM_WINDOW_TYPE_DESKTOP aren't set for the bar/menu that is > > drawn. > > > > The closest I could get in my research was > > http://comments.gmane.org/gmane.comp.misc.suckless/7688. dwm > > implements _NET_WM_WINDOW_TYPE for client windows. > > > > Is there a specific reason for not implementing _NET_WM_WINDOW_TYPE > > for dwm and dmenu other than that nobody did it so far? I think > > it's worth the issue because a compositor greatly improves window > > tearing and it would make the tools more compatible to the expected > > behavior. > > > > Btw, here is another issue related to compositors that might be > > worth considering again: > > http://lists.suckless.org/dev/1505/26735.html > > > > Jan Christoph -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
[dev] Proper window type for dwm and dmenu
Hi, I just stumbled upon the compositor compton and came across this wiki page that describes that shadows don't work properly in combination with dwm and dmenu: https://wiki.archlinux.org/index.php/Compton#dwm_.26_dmenu The reason for this is that _NET_WM_WINDOW_TYPE and _NET_WM_WINDOW_TYPE_DESKTOP aren't set for the bar/menu that is drawn. The closest I could get in my research was http://comments.gmane.org/gmane.comp.misc.suckless/7688. dwm implements _NET_WM_WINDOW_TYPE for client windows. Is there a specific reason for not implementing _NET_WM_WINDOW_TYPE for dwm and dmenu other than that nobody did it so far? I think it's worth the issue because a compositor greatly improves window tearing and it would make the tools more compatible to the expected behavior. Btw, here is another issue related to compositors that might be worth considering again: http://lists.suckless.org/dev/1505/26735.html Jan Christoph -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev] [slock] PAM support
On Mon 16-05-2016 15:52 -0700, Eric Pruitt wrote: > On Mon, May 16, 2016 at 10:38:00PM +0200, Jan Christoph Ebersbach > wrote: > > On Mon 16-05-2016 11:54 -0700, Eric Pruitt wrote: > > > Since PAM configurations typically enforce a delay before you can > > > reauthenticate after an incorrect password is entered, it would be > > > nice if there was another color to indicate that slock is waiting > > > for the PAM functions to return. > > > > As far as my test go, only if the password was entered incorrectly, > > PAM waits for a moment. > > Yes, that's the scenario I described in my earlier message. > > > In this case it would be nice to have a different color that > > indicates that the password has been handed to PAM. However, when > > the password is correct, PAM immediately returns. In this case, the > > screen would quickly change colors. Not sure if this desirable. > > It's mildly annoying, but I don't consider it a deal breaker and think > the behavior is fine. The added complexity to work around it wouldn't > be worth it in my opinion. It can be made a little less jarring by > selecting a color that's in between the "password being typed" and > "password is incorrect" colors. > > > Attached you find the patch that adds this feature. What do you > > think? > > I think this patch works well. Great, I changed the color to purple. Jan Christoph -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev] [slock] PAM support
On Mon 16-05-2016 11:54 -0700, Eric Pruitt wrote: > I have a suggestion -- I think you should add another color option to > the configuration. Since PAM configurations typically enforce a delay > before you can reauthenticate after an incorrect password is entered, > it would be nice if there was another color to indicate that slock is > waiting for the PAM functions to return. As far as my test go, only if the password was entered incorrectly, PAM waits for a moment. In this case it would be nice to have a different color that indicates that the password has been handed to PAM. However, when the password is correct, PAM immediately returns. In this case, the screen would quickly change colors. Not sure if this desirable. Attached you find the patch that adds this feature. What do you think? Jan Christoph -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 Author: Jan Christoph Ebersbach URL: http://tools.suckless.org/slock/patches/pam_auth Replaces shadow support with PAM authentication support. Change variable `pam_service` in `config.def.h` to the corresponding PAM service. The default configuration is for ArchLinux's `login` service. Index: slock-patches/slock/config.def.h === --- slock-patches.orig/slock/config.def.h +++ slock-patches/slock/config.def.h @@ -2,7 +2,11 @@ static const char *colorname[NUMCOLS] = "black", /* after initialization */ "#005577", /* during input */ "#CC", /* wrong password */ + "#FCCB1D", /* waiting for PAM */ }; /* treat a cleared input like a wrong password */ static const int failonclear = 1; + +/* PAM service that's used for authentication */ +static const char* pam_service = "login"; Index: slock-patches/slock/config.mk === --- slock-patches.orig/slock/config.mk +++ slock-patches/slock/config.mk @@ -12,7 +12,7 @@ X11LIB = /usr/X11R6/lib # includes and libs INCS = -I. -I/usr/include -I${X11INC} -LIBS = -L/usr/lib -lc -lcrypt -L${X11LIB} -lX11 -lXext -lXrandr +LIBS = -L/usr/lib -lc -lcrypt -L${X11LIB} -lX11 -lXext -lXrandr -lpam # flags CPPFLAGS = -DVERSION=\"${VERSION}\" -DHAVE_SHADOW_H Index: slock-patches/slock/slock.c === --- slock-patches.orig/slock/slock.c +++ slock-patches/slock/slock.c @@ -17,6 +17,8 @@ #include #include #include +#include +#include #if HAVE_BSD_AUTH #include @@ -27,6 +29,7 @@ enum { INIT, INPUT, FAILED, + PAM, NUMCOLS }; @@ -39,6 +42,9 @@ typedef struct { unsigned long colors[NUMCOLS]; } Lock; +static int pam_conv(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *appdata_ptr); +struct pam_conv pamc = {pam_conv, NULL}; +char passwd[256]; static Lock **locks; static int nscreens; static Bool running = True; @@ -112,6 +118,31 @@ getpw(void) } #endif +static int +pam_conv(int num_msg, const struct pam_message **msg, + struct pam_response **resp, void *appdata_ptr) +{ + int retval = PAM_CONV_ERR; + for(int i=0; imsg_style == PAM_PROMPT_ECHO_OFF && +strncmp(msg[i]->msg, "Password: ", 10) == 0) { + struct pam_response *resp_msg = malloc(sizeof(struct pam_response)); + if (!resp_msg) +die("malloc failed"); + char *password = malloc(strlen(passwd) + 1); + if (!password) +die("malloc failed"); + memset(password, 0, strlen(passwd) + 1); + strcpy(password, passwd); + resp_msg->resp_retcode = 0; + resp_msg->resp = password; + resp[i] = resp_msg; + retval = PAM_SUCCESS; + } + } + return retval; +} + static void #ifdef HAVE_BSD_AUTH readpw(Display *dpy) @@ -119,12 +150,15 @@ readpw(Display *dpy) readpw(Display *dpy, const char *pws) #endif { - char buf[32], passwd[256]; - int num, screen; + char buf[32]; + struct passwd* pw; + int num, screen, retval; unsigned int len, color; KeySym ksym; XEvent ev; static int oldc = INIT; + pam_handle_t *pamh; + len = 0; running = True; @@ -155,7 +189,30 @@ readpw(Display *dpy, const char *pws) #ifdef HAVE_BSD_AUTH running = !auth_userokay(getlogin(), NULL, "auth-xlock", passwd); #else -running = !!strcmp(crypt(passwd, pws), pws); + +color = PAM; +fprintf(stderr, "go\n"); +for (screen = 0; screen < nscreens; screen++) { + XSetWindowBackground(dpy, locks[screen]->win, locks[screen]->colors[color]); + XClearWindow(dpy, locks[screen]->win); + XRaiseWindow(dpy, locks[screen]->win); + XSync(dpy, False); +} + +pw = getpwuid(getuid()); +retval = pam_start(pam_service, pw->pw_name, &pamc,
Re: [dev] [slock] PAM support
On Mon 16-05-2016 11:47 -0700, Eric Pruitt wrote: > On Mon, May 16, 2016 at 08:07:54PM +0200, Jan Christoph Ebersbach > wrote: > > I guess this issue can still happen. I didn't remove most of the > > getpw* code in order to keep the patch small. I'm using sssd and so > > the getpw calls still work. The only issue is that the password > > hash can't be retrieved. This problem I solved with this patch by > > passing everything through PAM. > > On the system I'm using that relies on PAM, my account doesn't have an > entry in the local /etc/passwd file. Disabling getpw and related bits > makes the patch work for me. I fixed the issue and moved the getpw code to an ifdef. Jan Christoph -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev] [slock] PAM support
Hi Eric, On Mon 16-05-2016 10:05 -0700, Eric Pruitt wrote: > On Mon, May 16, 2016 at 06:32:54PM +0200, Jan Christoph Ebersbach > wrote: > > Yes, it's there in git but it takes a while till the web pages have > > be regenerated, I guess. > > I could be wrong, but I'm fairly certain the website is manually > regenerated. Otherwise, it would be pretty easy to do malicious > things. > > I downloaded and applied the patch directly from the sites repo, but I > get "cannot retrieve shadow entry" when running it. I don't have time > to debug the issue right now, so I'll follow-up later. I guess this issue can still happen. I didn't remove most of the getpw* code in order to keep the patch small. I'm using sssd and so the getpw calls still work. The only issue is that the password hash can't be retrieved. This problem I solved with this patch by passing everything through PAM. Jan Christoph -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev] [slock] PAM support
Yes, it's there in git but it takes a while till the web pages have be regenerated, I guess. On Mon 16-05-2016 09:06 -0700, Eric Pruitt wrote: > On Mon, May 16, 2016 at 05:21:01PM +0200, Jan Christoph Ebersbach > wrote: > > I've added support for PAM authentication to slock. When you try > > it, I'd very happy about feedback because I haven't really done any > > serious work with PAM yet: > > > > http://tools.suckless.org/slock/patches/pam_auth > > When I try to access the URL, I get "The requested document at > 'http://tools.suckless.org/slock/patches/pam_auth' doesn't exist," and > the patch also does not appear in the sidebar. Are you sure your patch > has been committed to the HTTP serving tree? > > Eric > -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev] [slock] PAM support
What auth system are you using if it's neither PAM nor shadow/passwd? On Mon 16-05-2016 17:38 +0200, hiro wrote: > bad idea, just like the existing bullshit for auth in slock. > signature.asc Description: PGP signature
[dev] [slock] PAM support
Hi, I've added support for PAM authentication to slock. When you try it, I'd very happy about feedback because I haven't really done any serious work with PAM yet: http://tools.suckless.org/slock/patches/pam_auth Cheers, Jan Christoph -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev] structural regular expression support for vis
Not yet, I have it on my agenda for May. On Sat 12-03-2016 18:44 +0100, Marc André Tanner wrote: > On Fri, Mar 11, 2016 at 08:08:38PM +0100, Marc André Tanner wrote: > > > - There will likely be bugs, memory leaks, crashes, infinite loops > > etc. YOU are supposed to fix them and submit patches ;) > > A particularly embarrassing one, preventing the use of multiple > regular expressions in the same command has been fixed. > > I will keep rebasing the branch onto master. > > Did anyone try it out, comments? > -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor
Hi Marc, I like vis very much. It's blazing fast and comes with good defaults. The following things I noticed: - Setting defaults requires patching some c file instead of config.def.h - Background/Foreground colors are only applied when syntax highlighting is possible for the currently loaded file - I miss that I can't align multiple cursors in insert mode, i.e. to align all "=" over multiple lines. The editor kakoune supports this nicely - I also miss C-a and C-x for dealing with numbers .. but that's just a minor inconvenience right now - It took me ages to start vis with the proper VIS_PATH and VIS_THEME settings. My installation directory for vis is ~/.local which is not part of the default locations. Furthermore, the manpage still refers to ~/.vis as the location where to put my personal configuration but it is actually ~/.config/vis. I had to create a little shell script that sets VIS_PATH and VIS_THEME before starting vis. In my opinion these obstacles make it very hard to start playing around with it. Since I'm using a light terminal background, I recreated the papercolor theme. Please feel free to integrate it: https://github.com/jceb/dotfiles/blob/master/config/vis/lexers/themes/papercolor.lua Keep up the good work! Jan Christoph On Fri 15-01-2016 16:56 +0100, Marc André Tanner wrote: > On Thu, Dec 31, 2015 at 07:59:37PM +0100, Connor Lane Smith wrote: > > > I think this is pushing it for a 2015 release. But I'll be sure to > > give it a go asap, 2016. :) > > Did you (or anyone else) try it? First impressions? Which features did > you miss the most? > -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 signature.asc Description: PGP signature
[dev] Space to advance to the next slide
Hi, Thank you very much for sent, it's awesome! Since Space is very common in other presentation tools to advance to the next slide it would be a great default for sent as well. The attached patch adds the Space key as another way to advance to the next slide. Regards, Jan Christoph -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 From ca10921d45d1605647a882e101a52d612033640b Mon Sep 17 00:00:00 2001 From: Jan Christoph Ebersbach Date: Tue, 17 Nov 2015 06:33:46 +0100 Subject: [PATCH] Register Space to advance to the next slide --- config.def.h | 1 + 1 file changed, 1 insertion(+) diff --git a/config.def.h b/config.def.h index 39772fb..6ecc267 100644 --- a/config.def.h +++ b/config.def.h @@ -29,6 +29,7 @@ static Shortcut shortcuts[] = { { XK_Right, advance,{.i = +1} }, { XK_Left,advance,{.i = -1} }, { XK_Return, advance,{.i = +1} }, + { XK_space, advance,{.i = +1} }, { XK_BackSpace, advance,{.i = -1} }, { XK_l, advance,{.i = +1} }, { XK_h, advance,{.i = -1} }, -- 2.6.2 signature.asc Description: PGP signature
Re: [dev] [st] expose cursor shape in config.def.h
Hi Christoph, Thank you for the hint. Attached is the patch in git format. Cheers, Jan Christoph On 09/07/2015 08:55 PM, Christoph Lohmann wrote: > Greetings. > > On Mon, 07 Sep 2015 20:55:46 +0200 Jan Christoph Ebersbach > wrote: >> Hi, >> >> I just realized that st implements the cursor shapes Block, IBeam and >> Underline. It would be nice if the default cursor shape would be >> configurable, i.e. because IBeam is a nice alternative to Block. >> >> The attached patch exposes cursor shape in config.def.h. > > Thanks for sending in the patch. > > Could you please make it a git‐format‐patch so your name will be in the > commit log? > > > Sincerely, > > Christoph Lohmann > > -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 From e7c8461ffdeb13f0a583d00a9dc31b1bb7b63eaa Mon Sep 17 00:00:00 2001 From: Jan Christoph Ebersbach Date: Tue, 8 Sep 2015 07:28:52 +0200 Subject: [PATCH] Expose cursor shape in config.def.h --- config.def.h | 9 + st.c | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/config.def.h b/config.def.h index 930e468..b42aa74 100644 --- a/config.def.h +++ b/config.def.h @@ -105,6 +105,15 @@ static unsigned int defaultfg = 7; static unsigned int defaultbg = 0; static unsigned int defaultcs = 256; +/* + * Default shape of cursor + * 2: Block + * 4: Underline + * 6: IBeam + */ + +static unsigned int cursorshape = 2; + /* * Default colour and shape of the mouse cursor diff --git a/st.c b/st.c index 256f8f5..7f4409b 100644 --- a/st.c +++ b/st.c @@ -4306,7 +4306,7 @@ main(int argc, char *argv[]) xw.l = xw.t = 0; xw.isfixed = False; - xw.cursor = 0; + xw.cursor = cursorshape; ARGBEGIN { case 'a': -- 2.5.1 signature.asc Description: OpenPGP digital signature
[dev] [st] expose cursor shape in config.def.h
Hi, I just realized that st implements the cursor shapes Block, IBeam and Underline. It would be nice if the default cursor shape would be configurable, i.e. because IBeam is a nice alternative to Block. The attached patch exposes cursor shape in config.def.h. Cheers, Jan Christoph -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 Index: st/config.def.h === --- st/config.def.h.orig +++ st/config.def.h @@ -108,6 +108,15 @@ static unsigned int defaultfg = 0; static unsigned int defaultbg = 15; static unsigned int defaultcs = 256; +/* + * Default shape of cursor + * 2: Block + * 4: Underline + * 6: IBeam + */ + +static unsigned int cursorshape = 2; + /* * Default colour and shape of the mouse cursor Index: st/st.c === --- st/st.c.orig +++ st/st.c @@ -4307,7 +4307,7 @@ main(int argc, char *argv[]) xw.l = xw.t = 0; xw.isfixed = False; - xw.cursor = 0; + xw.cursor = cursorshape; ARGBEGIN { case 'a': signature.asc Description: OpenPGP digital signature
Re: [dev] [st utf8 3/4] Change internal character representation.
Hi, I just realized that UTF-8 characters aren't supported as word delimiters. The attached patch fixes this issue. For a higher usefulness of the utf8strchr function, the index of the UTF-8 character could be returned in addition with a Rune instead of a char*. Since utf8strchr is currently only used by ISDELIM I didn't bother to increase the complexity. Please let me know if I should change something. Cheers, Jan Christoph On Mon 27-04-2015 09:34 +0200, Roberto E. Vargas Caballero wrote: > Applied (with minor changes), thanks. > > -- Jan Christoph Ebersbach I didn’t want some petty, inferior brand of righteousness that comes from keeping a list of rules when I could get the robust kind that comes from trusting Christ - God’s righteousness. Phil 3:9 diff --git a/st.c b/st.c index 0c6b9c3..3460a37 100644 --- a/st.c +++ b/st.c @@ -71,7 +71,7 @@ char *argv0; #define ISCONTROLC0(c) (BETWEEN(c, 0, 0x1f) || (c) == '\177') #define ISCONTROLC1(c) (BETWEEN(c, 0x80, 0x9f)) #define ISCONTROL(c) (ISCONTROLC0(c) || ISCONTROLC1(c)) -#define ISDELIM(u) (BETWEEN(u, 0, 127) && strchr(worddelimiters, u) != NULL) +#define ISDELIM(u) (utf8strchr(worddelimiters, u) != NULL) #define LIMIT(x, a, b)(x) = (x) < (a) ? (a) : (x) > (b) ? (b) : (x) #define ATTRCMP(a, b) ((a).mode != (b).mode || (a).fg != (b).fg || (a).bg != (b).bg) #define IS_SET(flag) ((term.mode & (flag)) != 0) @@ -473,6 +473,7 @@ static size_t utf8decode(char *, Rune *, size_t); static Rune utf8decodebyte(char, size_t *); static size_t utf8encode(Rune, char *); static char utf8encodebyte(Rune, size_t); +static char *utf8strchr(char *s, Rune u); static size_t utf8validate(Rune *, size_t); static ssize_t xwrite(int, const char *, size_t); @@ -640,6 +641,21 @@ utf8encodebyte(Rune u, size_t i) { return utfbyte[i] | (u & ~utfmask[i]); } +char * +utf8strchr(char *s, Rune u) { + Rune r; + size_t i, j, len; + + len = strlen(s); + for(i = 0, j = 0; i < len; i += j) { + if(!(j = utf8decode(&s[i], &r, len - i))) + break; + if(r == u) + return &(s[i]); + } + return NULL; +} + size_t utf8validate(Rune *u, size_t i) { if(!BETWEEN(*u, utfmin[i], utfmax[i]) || BETWEEN(*u, 0xD800, 0xDFFF)) pgpmMsA0HQr9J.pgp Description: PGP signature
[dev] FOSDEM
Hi, Is anyone planning to be at FOSDEM next weekend? It would be nice to meet some of the suckless hackers in person. I'll be there for the whole conference. Jan Christoph pgpqDaZeIBzi9.pgp Description: PGP signature
[dev] cloned screen setup broken
Hi, Thanks to hwi...@gmail.com I discovered an interesting, I'd say broken, behavior when using dwm in a cloned screen setup, i.e. connect a laptop to a beamer. In the archives I only found this lengthy thread (http://lists.suckless.org/dwm/0812/7109.html) regarding the dual head setup but it doesn't focus on the cloned setup. The problem becomes evident when one of the two screen operates on a higher resolution than the other. In the following picture S1 is the beamer, S2 the laptop. +--+---+ |S1|S2 | | | | +--+ | | | +--+ First of all, the bar is drawn on both screens although just one bar needed to be drawn. This causes the visual effect of a truncated information area (where the selected window's title is drawn) on S2. The more annoying problems start when new windows are spawned on both screen. Because both screens have their own list of clients but share the same visible tag, the windows are drawn on top of each other. When the focus is on screen S1 it is also not possible to focus a window from the other screen S2, although it's also visible on S1. I guess it could be difficult to solve the issue within dwm, therefore I suggest the following guidelines for this setup: - use the same resolution on both screens (I guess this is a good idea in general) - never spawn windows on the other screen - and hide the bar on the other screen Jan Christoph pgpfn2MwjpSrn.pgp Description: PGP signature
RE: [dev] [dwm] Patch for hor/vert-maximizing floating windows
Hi Krister, The patch looks interesting. I'll test it some time next week. Jan Christoph -Original message- > From:Krister Svanlund > Sent: Thu 19-Jul-2012 00:43 > To: dev@suckless.org > Subject: [dev] [dwm] Patch for hor/vert-maximizing floating windows > > Based on the dwm-6.0-maximize_vert_horz patch at > http://dwm.suckless.org/patches/moveresize I wrote a new version that > I feel is more intuitive and that remembers previous sizes, etc. Any > thoughts and opinions? > > The patch is attached >
RE: [dev] switch all windows from a monitor to another
Hi Maxime, I created a similar patch some time ago. It makes the tags being shared among all monitors instead of having separate tag sets. Maybe this is something you are also interested in. The downside is that it introduces fundamental changes to dwm that probably break other patches: http://dwm.suckless.org/patches/single_tagset Jan Christoph -Original message- > From:Maxime Daniel > Sent: Tue 17-Jul-2012 16:52 > To: dev@suckless.org > Subject: [dev] switch all windows from a monitor to another > > Hi, > > I wrote a patch which add a feature like tagmon, but with all the windows of > the current monitor. > "switchmon" permit to send all the windows of the current monitor to another > one (and keep the tag set) > > The patch is attached >
RE: [dev] [dwm] drop the bars (was: systray in upstream dwm?)
Hi, -Original message- > From:Bjartur Thorlacius > Sent: Tue 10-Apr-2012 12:09 > To: dev mail list > Subject: Re: [dev] [dwm] drop the bars (was: systray in upstream dwm?) > > On Saturday 07 April 2012 12:13:43 Jan Christoph Ebersbach wrote: > > I wonder how these kind of patches can be done in a better way. It's clear > > that including a systray in dwm is not a good idea but it is also not > > possible to work around the bar included in dwm. I want to see the mode my > > tag is in, the selected tags and the name of the current window. If there > > were a way to present this information to an external program, the bar > > wasn't necessary anymore. Xft and Systray would be implemented by a > > separate program and all the fruitless discussions about the visual stuff, > > would come to an end. > What about going to the other extreme: dwm should draw what it needs to draw > and /nothing/ else. On most displays, dwm doesn't need a sw wide bar. Instead, > it could reserve the rest of the status bar area for small WINDOW_TYPE_DOCKs. Sounds interesting but since there is no way of communicating with dwm we wouldn't gain much. The code for bars and keybindings would also stay. I'm rather for going the whole way. Jan Christoph
RE: [dev] [dwm] drop the bars (was: systray in upstream dwm?)
Hi, My case is not anymore to include the systray patch in dwm, don't get me wrong. I wonder how these kind of patches can be done in a better way. It's clear that including a systray in dwm is not a good idea but it is also not possible to work around the bar included in dwm. I want to see the mode my tag is in, the selected tags and the name of the current window. If there were a way to present this information to an external program, the bar wasn't necessary anymore. Xft and Systray would be implemented by a separate program and all the fruitless discussions about the visual stuff, would come to an end. Did anyone actually try to remove the bars (and keybindings) from dwm and define a simple IPC mechanism? Jan Christoph This message was sent using Zarafa WebApp.-Original message- From: Luis Anaya Sent: Sat 07-Apr-2012 10:57 To: dev@suckless.org Subject: RE: [dev] [dwm] drop the bars (was: systray in upstream dwm?) Hi: I see the case for a need of a systray, but there are tiling window managers that provide this facility. The "awesome" window manager does have systray capability fairly small footprint, something to consider. Dwm is meant to be minimal and it is embedded in its design philosophy and being that many of the systray application do have a command line counterpart in most cases, there's really no rush to include this as a main feature IMHO. But if it can be cleanly patched, it can be included in the patches section.
Re: [dev] [dwm] systray in upstream dwm?
Hi, Sorry for the confusion. I uploaded the patch against the current tip. The wiki page now contains both patches. Jan Christoph On Thu 05-04-2012 12:18 -0500, Micheal Smith wrote: > On Wed, Apr 04, 2012 at 11:29:27PM +0200, Arian Kuschki wrote: > > On 4 April 2012 22:29, Jan Christoph Ebersbach wrote: > > > > > ** > > > Hi, > > > > > > What needs to be done to get the systray patch upstream into dwm? Is there > > > any chance of getting it upstream or is it a total no go? > > > > > > The patch proved to be stable and I continued to refine it over last week. > > > Please let me know in case you discover any issues. > > > > > > Jan Christoph > > > > > > This message was sent using Zarafa WebApp. > > > > > > > The patch does not apply to dwm-6.0 cleanly, could you update it to 6.0 or > > tip? I for one am tired of running a standalone tray just to be able to use > > network-manager and am grateful for this. > > > > Cheers, > > Arian > > Just updated the patch to apply cleanly with 6.0. Hope that helps. > > Thanks, > Micheal > > pgpGvUYCavuJ4.pgp Description: PGP signature
[dev] [dwm] drop the bars (was: systray in upstream dwm?)
Good Friday, Thank you Anselm for explaining the issue. From my point of view there is no other way of implementing a proper systray for dwm as long as it contains the bars and has no interface. Why don't we drop the bars and keybindings and let separate programs handle it. There are also other patches like Xft that show that there is a need for choice and extension. Building everything into dwm is not a good idea, agreed. So let's create a proper interface for dwm that other programs can use. Jan Christoph On Thu 05-04-2012 19:31 +0200, Anselm R Garbe wrote: > On 4 April 2012 22:29, Jan Christoph Ebersbach wrote: > > What needs to be done to get the systray patch upstream into dwm? Is there > > any chance of getting it upstream or is it a total no go? > > It is a total no go. It is even questionable that dwm contains a > status text area. There are tools like dzen for this instead. > > I think it is very fair for those who need this functionality to have > it available as a patch. > > Cheers, > Anselm > pgpwXXhTEWEx2.pgp Description: PGP signature
[dev] [dwm] systray in upstream dwm?
Hi, What needs to be done to get the systray patch upstream into dwm? Is there any chance of getting it upstream or is it a total no go? The patch proved to be stable and I continued to refine it over last week. Please let me know in case you discover any issues. Jan Christoph This message was sent using Zarafa WebApp.
[dev] [dwm] systray implementation
Hi, I created a systray implementation for dwm. It can be dowloaded from http://dwm.suckless.org/patches/systray. Please let me know about any issues. Cheers, Jan Christoph
RE: [dev] [dwm] Tags vs Monitors continued
Here is an updated version of the patch that doesn't cause dwm to crash when adding or removing monitors. There is also a know issue when multiple tags are assigned to a single window. The patch doesn't prevent you from displaying both tags on two monitors at the same time - better don't do it. https://bitbucket.org/jceb81/dwm-patches/raw/53cc07efad29/single_clientlist.patch Cheers, Jan Christoph -Original message----- From: Jan Christoph Ebersbach Sent: Mon 27-02-2012 21:12 Subject:[dev] [dwm] Tags vs Monitors continued To: dev@suckless.org; CC: 78...@web.de; > Hi Thomas, > Hi everybody, > > I experienced the very same difficulties with dwm's multi-monitor > support that Thomas described earlier this year. In the attached patch I > solved the problem by detaching the list of clients from the monitor. > There is just one list of clients and all tags are shared between the > monitors. > > The biggest advantage in my eyes is the ability to swap tags between > monitors while every monitor still keeps its one tag(s). > > It's crucial that a tag/window can't be displayed on two monitors at the > same this. The patch implements this functionality at the cost of > MODKEY-0 - it doesn't work anymore in a multi-monitor setup. > > Feedback is very welcome. The patch is very fresh and I expect that a > number of corner cases won't work. Due to the large number of changes > it's very likely that the patch also breaks other patches. > > https://bitbucket.org/jceb81/dwm-patches/raw/95eca0c72fc7/single_clientlist.patc > h > > Cheers, > > Jan Christoph > >
[dev] [dwm] Tags vs Monitors continued
Hi Thomas, Hi everybody, I experienced the very same difficulties with dwm's multi-monitor support that Thomas described earlier this year. In the attached patch I solved the problem by detaching the list of clients from the monitor. There is just one list of clients and all tags are shared between the monitors. The biggest advantage in my eyes is the ability to swap tags between monitors while every monitor still keeps its one tag(s). It's crucial that a tag/window can't be displayed on two monitors at the same this. The patch implements this functionality at the cost of MODKEY-0 - it doesn't work anymore in a multi-monitor setup. Feedback is very welcome. The patch is very fresh and I expect that a number of corner cases won't work. Due to the large number of changes it's very likely that the patch also breaks other patches. https://bitbucket.org/jceb81/dwm-patches/raw/95eca0c72fc7/single_clientlist.patch Cheers, Jan Christoph