Re: [dev] [Announce] Desktop Entry Launcher

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

> +
> +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, );
> + XSelectInput(dpy, systray-> win, SubstructureNotifyMask);
> + XChangeProperty(dpy, systray-> win, 
> netatom[NetSystemTrayOrientation], XA_CARDINAL, 32,
> + PropModeReplace, (unsigned char 
> *)[NetSystemTrayOrientationHorz], 1);
> + XChangeProperty(dpy, systray-> win, 
> netatom[NetSystemTrayVisual], XA_VISUALID, 32,
> + PropModeReplace, (unsigned char *)> 
> 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, );
> + 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, );
> + 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

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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 <j...@e-jc.de>
> > 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

[Jan Christoph Ebersbach]

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 <j...@e-jc.de>
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, );
+		XChangeProperty(dpy, m->barwin, netatom[NetWMWindowType], XA_ATOM, 32,
+PropModeReplace, (unsigned char *) [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 <j...@e-jc.de>
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_WINDOW_TY

Re: [dev] new pre-patched version of dwm available

[Jan Christoph Ebersbach]

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
> <britton.ke...@gmail.com> 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

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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 <j...@e-jc.de>
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; i<num_msg; i++) {
+		if (msg[i]->msg_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_star

Re: [dev] [slock] PAM support

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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 <j...@e-jc.de>
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

[Jan Christoph Ebersbach]

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 <j...@e-jc.de> 
> 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 <j...@e-jc.de>
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

[Jan Christoph Ebersbach]

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.

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

Hi Krister,

The patch looks interesting. I'll test it some time next week.

Jan Christoph 
 
-Original message-
 From:Krister Svanlund krister.svanl...@gmail.com
 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

[Jan Christoph Ebersbach]

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 l...@maxux.net
 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?)

[Jan Christoph Ebersbach]

Hi,
 
-Original message-
 From:Bjartur Thorlacius svartma...@gmail.com
 Sent: Tue 10-Apr-2012 12:09
 To: dev mail list dev@suckless.org
 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] systray in upstream dwm?

[Jan Christoph Ebersbach]

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 j...@e-jc.de 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?)

[Jan Christoph Ebersbach]

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 j...@e-jc.de 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?

[Jan Christoph Ebersbach]

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

[Jan Christoph Ebersbach]

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

[dev] [dwm] Tags vs Monitors continued

[Jan Christoph Ebersbach]

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

RE: [dev] [dwm] Tags vs Monitors continued

[Jan Christoph Ebersbach]

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 j...@e-jc.de
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