Re: [dev] Some 2wm questions

[Thomas Dahms]

2011/11/1 Thomas Dahms :
> 2011/11/1 Bert Münnich :
>> On 01.11.11, Connor Lane Smith wrote:
>>> I notice this patch doesn't have an attach (M-a) to accompany detach
>>> (M-d). Is this a bug or a feature?
>>
>> It's a feature. I've used attach only very rarely. Instead, I switch to
>> the other tag temporarily, use detach (toggletag) on the clients I want
>> to detach and switch back.
>
> Your patch is quite a bit different than 2wm. 2wm has only one view.

Sorry, I missed toggleview(). Nevertheless, I found attach to be
essential when trying 2wm.

> Your patch looks more like dwm limited to two tags.
>
> --
> Thomas Dahms
>



-- 
Thomas Dahms

Re: [dev] Some 2wm questions

[Thomas Dahms]

2011/11/1 Bert Münnich :
> On 01.11.11, Connor Lane Smith wrote:
>> I notice this patch doesn't have an attach (M-a) to accompany detach
>> (M-d). Is this a bug or a feature?
>
> It's a feature. I've used attach only very rarely. Instead, I switch to
> the other tag temporarily, use detach (toggletag) on the clients I want
> to detach and switch back.

Your patch is quite a bit different than 2wm. 2wm has only one view.
Your patch looks more like dwm limited to two tags.

-- 
Thomas Dahms

Re: [dev] [dwm] 2000 SLOC

[Troels Henriksen]

Anselm R Garbe  writes:

> On 31 October 2011 12:42, Troels Henriksen  wrote:
>> Anselm R Garbe  writes:
>>
>>> * surf (seems dead, please shout if you disagree or if anyone wants to
>>> take this on, it doesn't make sense if it is not maintained, as
>>> webkitgtk carries away)
>>
>> I wouldn't mind taking maintainership of Surf, if necessary.  I'm
>> already maintaining an off-tree fork with some changes (although not all
>> of those changes are "suckless", I think I have figured out some good
>> ways to make Surf more useful).
>
> Excellent, please send me your SSH key via privmail.

What, no solemn vow to uphold the sacred Suckless principles?  At least
I hope I still get to learn about a secret handshake or something.

-- 
\  Troels
/\ Henriksen

Re: [dev] [dwm] 2000 SLOC

[Anselm R Garbe]

On 31 October 2011 12:42, Troels Henriksen  wrote:
> Anselm R Garbe  writes:
>
>> * surf (seems dead, please shout if you disagree or if anyone wants to
>> take this on, it doesn't make sense if it is not maintained, as
>> webkitgtk carries away)
>
> I wouldn't mind taking maintainership of Surf, if necessary.  I'm
> already maintaining an off-tree fork with some changes (although not all
> of those changes are "suckless", I think I have figured out some good
> ways to make Surf more useful).

Excellent, please send me your SSH key via privmail.

Cheers,
Anselm

Re: [dev] [dwm] 2000 SLOC

[Joerg Zinke]

Hi,

Am 31.10.2011 um 20:44 schrieb Anselm R Garbe :

> On Mon, Oct 31, 2011 at 08:39:00PM +0100, Joerg Zinke wrote:
>> 
>> 
> * surf (seems dead, please shout if you disagree or if anyone wants to
> take this on, it doesn't make sense if it is not maintained, as
> webkitgtk carries away)
>> 
>> Shout!
>> 
 I wouldn't mind taking maintainership of Surf, if necessary.  I'm
 already maintaining an off-tree fork with some changes (although not all
 of those changes are "suckless", I think I have figured out some good
 ways to make Surf more useful).
>>> 
>>> I second Troels self-nomination.  I use surf all the time.
>> 
>> ACK, same here. No better alternatives.
> 
> Ok surf will stay,

Nice to hear.

> but we need some maintainer who likes to volunteer if Gottox
> really hasn't got the time anymore.

I do not know the rules, but what about Troels Henriksen offer?

Regards,
Joerg

Re: [dev] Some 2wm questions

[Bert Münnich]

On 01.11.11, Connor Lane Smith wrote:
> On 1 November 2011 08:25, Bert Münnich  wrote:
> > I've tried 2wm some time ago, liked the concept but got fed up with its
> > old code base. So I wrote a small dwm -> 2wm (d2wm) conversion patch.
> 
> Thanks for this.
> 
> > The patch simply changes toggle{tag,view}, so that they move the current
> > client to the other tag / change the view to the other tag.
> 
> I notice this patch doesn't have an attach (M-a) to accompany detach
> (M-d). Is this a bug or a feature?

It's a feature. I've used attach only very rarely. Instead, I switch to 
the other tag temporarily, use detach (toggletag) on the clients I want 
to detach and switch back.

Bert

Re: [dev] [dwm] 2000 SLOC

[ilf]

On 11-01 10:11, Connor Lane Smith wrote:

A problem, though, is that it removes hyperlinks.


I consider this a problem as well.

If there was an option to keep links, I'd happily enable it. Also I'd 
adjust the new CSS (as in: clear it.


I wonder if it would be possible to 'crowdsource' readability so we 
can contribute bits of pages to hide, like on Wikipedia we don't care 
about '[edit]', etc... Not sure how we'd go about that, though.


I once envisioned a Plugin to directly go to "Print Views" of websites, 
since they tend to have considerably less suck on them. I'm pretty 
trained for my standard websites, but still I do: Open Print View, 
disbale CSS, and now trigger SimplyRead.


I think we could automate all that and crowd-source the rules for it.

--
ilf

Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung


signature.asc
Description: Digital signature

Re: [dev] [dwm] 2000 SLOC

[Nick]

On Tue, Nov 01, 2011 at 06:20:29PM +0100, pancake wrote:
> >> On 31 October 2011 23:28, Nick  wrote:
> >>> http://njw.me.uk/software/simplyread/ is a little js thing I wrote
> >>> which is basically a nicer, simpler version of readability. works
> >>> with surf, uzbl, chrome, firefox.
>
> Can you port it to surf and add it to the surf extensions page?

It works fine in surf already. If you download the source
tarball (imagine for a moment that the link wasn't a 404),
and read INSTALL, you'll see that you can do this:

  cat keybind.js simplyread.js >> $HOME/.surf/script.js

You're right, I should add that to the surf wiki. I'll do so
soon.

Re: [dev] [dwm] 2000 SLOC

[pancake]

Can you port it to surf and add it to the surf extensions page?

On 01/11/2011, at 10:44, Nick  wrote:

> On Tue, Nov 01, 2011 at 09:34:21AM +, Connor Lane Smith wrote:
>> On 31 October 2011 23:28, Nick  wrote:
>>> http://njw.me.uk/software/simplyread/ is a little js thing I wrote
>>> which is basically a nicer, simpler version of readability. works
>>> with surf, uzbl, chrome, firefox.
>> 
>> Thanks! However, your XPI is incompatible with my Firefox (9.0a2) and
>> the source tarball is a 404. :(
> 
> Indeed, I just noticed the source tarball was missing. The joys
> of having little used software is that you can get away with
> such things for a while. I'll fix that tonight.
> 
> As for your futuristic firefox, if you could be so kind,
> could you either:
> - test the current xpi with firefox, using mozilla's addon
>  compatibility extension, to see if it works, or
> - just grab the latest version from git, change
>  em:maxVersion in gecko/install.ttl, and run "make xpi",
>  and test it.
> And let me know that it works (it should, naturally it
> doesn't make use of much of firefox's special sauces).
> 

Re: [dev] herbstluftwm

[Christoph Lohmann]

Greetings.

On 01.11.2011 17:37, Sime Ramov wrote:
> * Anselm R Garbe  [2011-11-01 17:13+0100]:
>> Client-Server rarely makes sense if there is only one client and
>> one server.
> 
> It makes sense, if only for shell scripts, automation and a good way of
> storing and restoring custom layouts. Clients could be anything.

X11 is already client and server. That's like the dbus insanity of
having a separate »bus«, which needs to exported too.


Sincerely,

Christoph Lohmann

Re: [dev] herbstluftwm

[Sime Ramov]

* Anselm R Garbe  [2011-11-01 17:13+0100]:
> Client-Server rarely makes sense if there is only one client and
> one server.

It makes sense, if only for shell scripts, automation and a good way of
storing and restoring custom layouts. Clients could be anything.

Re: [dev] Re: [dwm] A general approach to master-slave layouts

[Anselm R Garbe]

On 1 November 2011 17:04, lolilolicon  wrote:
> On Tue, Nov 1, 2011 at 11:38 PM, Anselm R Garbe  wrote:
>> however this would require some reshuffling of the config.h inclusion
>> and also changes in various places. So I doubt it would be necessary
>> at all. Just stick with nmaster/mfact in Monitor.
>>
>
> Hmm, I think the difficulty is to track the index of the current layout
> in the layouts array.  I'm not sure how.  I'd like to stick with the
> current Monitor struct.

Hmm, ok.

>> This could work for a patch, but I don't think this is a great way of
>> programming for mainline, since manipulating and restoring
>> nmaster/mfact for the time being is quite ugly. ;)
>
> Well, it's a compromise.  Would you feel it's less ugly if I define the
> apply_mslts function like this:
>
>    tatic void apply_mslts(Monitor *m, Bool hsplit,
>        float mfact, int nmaster,
>        void (*mltf)(Client **, Booth *, unsigned int),
>        void (*sltf)(Client **, Booth *, unsigned int)) {
>        /* uses mfact instead of m->mfact, nmaster intead of m->nmaster */
>    }
>
> and define the layouts like:
>
>    void
>    col(Monitor *m) {
>       int nmaster = MIN(m->nmaster, m->ww / term_width);
>       float mfact = (float)term_width * nmaster / m->ww;
>      apply_mslts(m, False, mfact, nmaster, lt_hstack, lt_vstack);
>    }
>    void
>    tile(Monitor *m) {
>      apply_mslts(m, False, m->mfact, m->nmaster, lt_vstack, lt_vstack);
>    }
>
> Basically the same thing, I guess it's still ugly, but does it feel less
> ugly? :D

I think this is less ugly, because you don't manipulate (like before)
m->{nmaster, mfact}.

Cheers,
Anselm

Re: [dev] herbstluftwm

[Anselm R Garbe]

On 1 November 2011 16:57, Sime Ramov  wrote:
> * Anselm R Garbe  [2011-11-01 16:49+0100]:
>>  (i) It features a kind of 'static' window management model in the
>>      tradition of ion/wmi(i)/i3.
>
> And that is exactly why I use it. It has perfect balance between dynamic
> and manual tiling.

Fair enough.

>> (ii) The IPC mechanism reminds me of all the mistakes I made in wmi
>>      (with wmiremote) and later wmii with wmiir/libixp.
>
> Conceptually or? I am not a programmer but I prefer server/client
> software model.

Having an IPC mechnism to control and configure your WM makes the code
unnecessary more complex. Client-Server rarely makes sense if there is
only one client and one server.

Cheers,
Anselm

Re: [dev] Re: [dwm] A general approach to master-slave layouts

[lolilolicon]

On Tue, Nov 1, 2011 at 11:38 PM, Anselm R Garbe  wrote:
> On 1 November 2011 16:27, lolilolicon  wrote:
>> But now I realize another problem with moving mfact/nmaster to Layout.
>> The issue is two monitors should be able to use different mfact/nmaster
>> values for the same layout; also, the setmfact/incnmaster functions
>> will not update the unselected monitor, but will have their effects all
>> of a sudden next time that monitor is arranged.
>> This makes me want to make nmaster/mfact specific to the monitor *and*
>> the layout.  And I also prefer achieving this in the least intrusive
>> way possible.
>
> Exactly this is the main problem. You could work around it with
> changing monitor as follows:
>
>  struct Monitor {
>        char ltsymbol[16];
> -       float mfact;
> -       int nmaster;
> +       float mfact[LENGTH(layouts)];
> +       int nmaster[LENGTH(layouts)];
>        int num;
>        int by;               /* bar geometry */
>        int mx, my, mw, mh;   /* screen size */
>
> however this would require some reshuffling of the config.h inclusion
> and also changes in various places. So I doubt it would be necessary
> at all. Just stick with nmaster/mfact in Monitor.
>

Hmm, I think the difficulty is to track the index of the current layout
in the layouts array.  I'm not sure how.  I'd like to stick with the
current Monitor struct.

>> You are absolutely right.  Now that I think of it, we can temporarily
>> set m->mfact and/or m->nmaster in a layout function before calling
>> apply_mslts, and restore the values afterwards.  For example, define
>> the col layout like this:
>>
>>    /* int term_width is the width of a terminal (e.g. 80 characters) */
>>    void
>>    col(Monitor *m) {
>>        float mfact = m->mfact;
>>        int nmaster = m->nmaster;
>>        /* masters will be term_width wide */
>>        m->nmaster = MIN(nmaster, m->ww / term_width);
>>        m->mfact = (float)term_width * m->nmaster / m->ww;
>>        apply_mslts(m, False, lt_hstack, lt_vstack);
>>        m->mfact = mfact;
>>        m->nmaster = nmaster;
>>    }
>>
>> A bit back-and-forth with the mfact calculation (since we will calculate
>> back to the width in apply_mslts), but it's a fair compromise, I guess.
>
> This could work for a patch, but I don't think this is a great way of
> programming for mainline, since manipulating and restoring
> nmaster/mfact for the time being is quite ugly. ;)

Well, it's a compromise.  Would you feel it's less ugly if I define the
apply_mslts function like this:

tatic void apply_mslts(Monitor *m, Bool hsplit,
float mfact, int nmaster,
void (*mltf)(Client **, Booth *, unsigned int),
void (*sltf)(Client **, Booth *, unsigned int)) {
/* uses mfact instead of m->mfact, nmaster intead of m->nmaster */
}

and define the layouts like:

void
col(Monitor *m) {
      int nmaster = MIN(m->nmaster, m->ww / term_width);
      float mfact = (float)term_width * nmaster / m->ww;
  apply_mslts(m, False, mfact, nmaster, lt_hstack, lt_vstack);
}
void
tile(Monitor *m) {
  apply_mslts(m, False, m->mfact, m->nmaster, lt_vstack, lt_vstack);
}

Basically the same thing, I guess it's still ugly, but does it feel less
ugly? :D

>
> Cheers,
> Anselm
>
>

Re: [dev] herbstluftwm

[Sime Ramov]

* Anselm R Garbe  [2011-11-01 16:49+0100]:
>  (i) It features a kind of 'static' window management model in the
>  tradition of ion/wmi(i)/i3.

And that is exactly why I use it. It has perfect balance between dynamic
and manual tiling.

> (ii) The IPC mechanism reminds me of all the mistakes I made in wmi
>  (with wmiremote) and later wmii with wmiir/libixp.

Conceptually or? I am not a programmer but I prefer server/client
software model.

Re: [dev] herbstluftwm

[Anselm R Garbe]

On 1 November 2011 14:51, Sime Ramov  wrote:
> 
>
> I find it extremely good and it has just replaced ratpoison as my
> WM. Maybe it will be a good match for someone else too (it is
> virtually unknown).

It's SLOC is ok, but two issues for me:

(i) It features a kind of 'static' window management model in the
tradition of ion/wmi(i)/i3.

(ii) The IPC mechanism reminds me of all the mistakes I made in wmi
(with wmiremote) and later wmii with wmiir/libixp.

I can't comment on musca which it claims to be an influence as well though.

But good to see another tiling WM being around, as this at least gives
some hope that the tiled world will have some impact on mainstream
interfaces (actually I believe they already had quite a lot of impact
when looking at mobile OS'es like Android).

Cheers,
Anselm

Re: [dev] [dwm] mapping wm state, and other stories

[Connor Lane Smith]

On 1 November 2011 15:31, Christoph Lohmann <2...@r-36.net> wrote:
> Attached is a quick patch to make dwm DIALOG-agnostic. I don't
> have a certain test window to try it out, so please test before
> applying it.

Thanks, that patch works fine for me.

cls

Re: [dev] Re: [dwm] A general approach to master-slave layouts

[Anselm R Garbe]

On 1 November 2011 16:27, lolilolicon  wrote:
> On Tue, Nov 1, 2011 at 6:20 PM, Anselm R Garbe  wrote:
>> The change of the Layout struct makes it a lot harder to define
>> layouts, as now one also has to understand the variables
>> nmaster/mfact. Also nmaster/mfact are now layout specific variables
>> that might not be used by other layouts. This lacks a bit conceptual
>> clarity imho.
>
> I also agree with what you said here, but let me clarify my intention.
> I really think it more useful to make mfact/nmaster layout-specific,
> otherwise I wounldn't have made the change to the Layout struct.  For
> example, on my 1280x800 screen, mfact == 0.75 combined with nmaster == 2
> in the n?col layout makes a nice layout, but the combination is very
> bad for the tile layout.  As such, sharing mfact/nmaster across layouts
> isn't exactly nice, nor is it "dynamic" enough.
>
> But now I realize another problem with moving mfact/nmaster to Layout.
> The issue is two monitors should be able to use different mfact/nmaster
> values for the same layout; also, the setmfact/incnmaster functions
> will not update the unselected monitor, but will have their effects all
> of a sudden next time that monitor is arranged.
> This makes me want to make nmaster/mfact specific to the monitor *and*
> the layout.  And I also prefer achieving this in the least intrusive
> way possible.

Exactly this is the main problem. You could work around it with
changing monitor as follows:

 struct Monitor {
char ltsymbol[16];
-   float mfact;
-   int nmaster;
+   float mfact[LENGTH(layouts)];
+   int nmaster[LENGTH(layouts)];
int num;
int by;   /* bar geometry */
int mx, my, mw, mh;   /* screen size */

however this would require some reshuffling of the config.h inclusion
and also changes in various places. So I doubt it would be necessary
at all. Just stick with nmaster/mfact in Monitor.

>> What I'd really prefer is keeping the interface intact we had, a
>> layout is just a function -- I have no objections that this function
>> calls other functions or set up some variables to fit its needs. This
>> would keep it equally simple to the user to define Layouts and leave
>> the interface to be a function, rather than a function + variables.
>
> You are absolutely right.  Now that I think of it, we can temporarily
> set m->mfact and/or m->nmaster in a layout function before calling
> apply_mslts, and restore the values afterwards.  For example, define
> the col layout like this:
>
>    /* int term_width is the width of a terminal (e.g. 80 characters) */
>    void
>    col(Monitor *m) {
>        float mfact = m->mfact;
>        int nmaster = m->nmaster;
>        /* masters will be term_width wide */
>        m->nmaster = MIN(nmaster, m->ww / term_width);
>        m->mfact = (float)term_width * m->nmaster / m->ww;
>        apply_mslts(m, False, lt_hstack, lt_vstack);
>        m->mfact = mfact;
>        m->nmaster = nmaster;
>    }
>
> A bit back-and-forth with the mfact calculation (since we will calculate
> back to the width in apply_mslts), but it's a fair compromise, I guess.

This could work for a patch, but I don't think this is a great way of
programming for mainline, since manipulating and restoring
nmaster/mfact for the time being is quite ugly. ;)

Cheers,
Anselm

Re: [dev] [dwm] mapping wm state, and other stories

[Christoph Lohmann]

Greetings.

On 01.11.2011 11:59, Connor Lane Smith wrote:
> It would also be nice if dwm supported _NET_WM_WINDOW_TYPE hints as
> well, so we can make _NET_WM_WINDOW_TYPE_DIALOG windows float. (We
> could steal the updatewindowtype() function from Christoph Lohmann's
> dock patch.)

Attached is a quick patch to make dwm DIALOG-agnostic. I don't
have a certain test window to try it out, so please test before
applying it.


Sincerely,

Christoph Lohmann
# HG changeset patch
# User Christoph Lohmann <2...@r-36.net>
# Date 1320161309 -3600
# Node ID e5464b692b020c4e87dae05bb1a1a760f168c9a5
# Parent  904e923827cb010abb7a31298264548946616d92
Adding WindowType and initial Dialog type support.

diff -r 904e923827cb -r e5464b692b02 dwm.c
--- a/dwm.c	Mon Oct 31 20:09:27 2011 +0100
+++ b/dwm.c	Tue Nov 01 16:28:29 2011 +0100
@@ -58,7 +58,8 @@
 enum { CurNormal, CurResize, CurMove, CurLast };/* cursor */
 enum { ColBorder, ColFG, ColBG, ColLast };  /* color */
 enum { NetSupported, NetWMName, NetWMState,
-   NetWMFullscreen, NetActiveWindow, NetLast }; /* EWMH atoms */
+   NetWMFullscreen, NetActiveWindow, NetWMWindowType,
+   NetWMWindowTypeDialog, NetLast }; /* EWMH atoms */
 enum { WMProtocols, WMDelete, WMState, WMTakeFocus, WMLast }; /* default atoms */
 enum { ClkTagBar, ClkLtSymbol, ClkStatusText, ClkWinTitle,
ClkClientWin, ClkRootWin, ClkLast }; /* clicks */
@@ -237,6 +238,7 @@
 static void updatenumlockmask(void);
 static void updatesizehints(Client *c);
 static void updatestatus(void);
+static void updatewindowtype(Client *c);
 static void updatetitle(Client *c);
 static void updatewmhints(Client *c);
 static void view(const Arg *arg);
@@ -1152,6 +1154,7 @@
 	XConfigureWindow(dpy, w, CWBorderWidth, &wc);
 	XSetWindowBorder(dpy, w, dc.norm[ColBorder]);
 	configure(c); /* propagates border_width, if size doesn't change */
+	updatewindowtype(c);
 	updatesizehints(c);
 	updatewmhints(c);
 	XSelectInput(dpy, w, EnterWindowMask|FocusChangeMask|PropertyChangeMask|StructureNotifyMask);
@@ -1308,6 +1311,8 @@
 			if(c == c->mon->sel)
 drawbar(c->mon);
 		}
+		if(ev->atom == netatom[NetWMWindowType])
+			updatewindowtype(c);
 	}
 }
 
@@ -1562,6 +1567,8 @@
 	netatom[NetWMName] = XInternAtom(dpy, "_NET_WM_NAME", False);
 	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[NetWMWindowTypeDialog] = XInternAtom(dpy, "_NET_WM_WINDOW_TYPE_DIALOG", False);
 	/* init cursors */
 	cursor[CurNormal] = XCreateFontCursor(dpy, XC_left_ptr);
 	cursor[CurResize] = XCreateFontCursor(dpy, XC_sizing);
@@ -1967,6 +1974,26 @@
 }
 
 void
+updatewindowtype(Client *c)
+{
+	Atom wtype, real;
+	int format;
+	unsigned long n, extra;
+	unsigned char *p = NULL;
+
+	if(XGetWindowProperty(dpy, c->win, netatom[NetWMWindowType], 0L,
+sizeof(Atom), False, XA_ATOM, &real, &format,
+&n, &extra, (unsigned char **)&p) == Success
+			&& p) {
+		wtype = *(Atom *)p;
+		XFree(p);
+
+		if(wtype == netatom[NetWMWindowTypeDialog])
+			c->isfloating = True;
+	}
+}
+
+void
 updatewmhints(Client *c) {
 	XWMHints *wmh;
 

Re: [dev] Re: [dwm] A general approach to master-slave layouts

[lolilolicon]

On Tue, Nov 1, 2011 at 6:20 PM, Anselm R Garbe  wrote:
> On 1 November 2011 00:07, lolilolicon  wrote:
>> Indeed mfact and nmaster being members of Layout does make more sense, and
>> I made a patch which includes this change.
>>
>> Note that this may seem to add some SLOCs, but it actually reduces the
>> amount of code required to implement the same layouts by avoiding code
>> duplication.  See how tile, bstack and col are each defined using just a
>> one-liner.  By defining two layout algorithms `lt_vstack` and `lt_hstack`,
>> in combination with the hsplit switch, one can define 2 ** 2 * 2 = 8 such
>> layouts, and if you count the (masters|slaves)-only layouts as separate
>> ones, we got 10.  Add a third layout algorithm, and you have
>> 3 ** 2 * 2 + 3 = 21.  Sure, not all layouts are useful for everyone, but
>> hopefully this will produce some interesting layouts suitable for your
>> particular setup.
>
> Thanks for you patch, I looked at it and it is indeed interesting.
> However it needs further testing and review in order to be a candidate
> for mainline at some point.
>

Can't agree more.

> Some remarks:
>
> The change of the Layout struct makes it a lot harder to define
> layouts, as now one also has to understand the variables
> nmaster/mfact. Also nmaster/mfact are now layout specific variables
> that might not be used by other layouts. This lacks a bit conceptual
> clarity imho.
>

I also agree with what you said here, but let me clarify my intention.
I really think it more useful to make mfact/nmaster layout-specific,
otherwise I wounldn't have made the change to the Layout struct.  For
example, on my 1280x800 screen, mfact == 0.75 combined with nmaster == 2
in the n?col layout makes a nice layout, but the combination is very
bad for the tile layout.  As such, sharing mfact/nmaster across layouts
isn't exactly nice, nor is it "dynamic" enough.

But now I realize another problem with moving mfact/nmaster to Layout.
The issue is two monitors should be able to use different mfact/nmaster
values for the same layout; also, the setmfact/incnmaster functions
will not update the unselected monitor, but will have their effects all
of a sudden next time that monitor is arranged.
This makes me want to make nmaster/mfact specific to the monitor *and*
the layout.  And I also prefer achieving this in the least intrusive
way possible.

> What I'd really prefer is keeping the interface intact we had, a
> layout is just a function -- I have no objections that this function
> calls other functions or set up some variables to fit its needs. This
> would keep it equally simple to the user to define Layouts and leave
> the interface to be a function, rather than a function + variables.
>

You are absolutely right.  Now that I think of it, we can temporarily
set m->mfact and/or m->nmaster in a layout function before calling
apply_mslts, and restore the values afterwards.  For example, define
the col layout like this:

/* int term_width is the width of a terminal (e.g. 80 characters) */
void
col(Monitor *m) {
float mfact = m->mfact;
int nmaster = m->nmaster;
/* masters will be term_width wide */
m->nmaster = MIN(nmaster, m->ww / term_width);
m->mfact = (float)term_width * m->nmaster / m->ww;
apply_mslts(m, False, lt_hstack, lt_vstack);
m->mfact = mfact;
m->nmaster = nmaster;
}

A bit back-and-forth with the mfact calculation (since we will calculate
back to the width in apply_mslts), but it's a fair compromise, I guess.

> Also I'm not absolutely happy about the introduction of the Booth
> struct, I would rename that into Rect as we have used a similar name
> in other areas. Having said this, I'm in favor of *not* using
> XRectangle where possible, in order to keep the core code of dwm X
> agnostic (which is one 6.0 goal btw).
>

Bah, Booth is cute!  Just kidding; I knew it would sound strange and
probably have to be renamed.  Here we go, Rect it is.

> Cheers,
> Anselm
>
>

Re: [dev] [st] Patch to fix selection rendering

[Aurélien Aptel]

Thanks, applied.

[dev] herbstluftwm

[Sime Ramov]

I find it extremely good and it has just replaced ratpoison as my
WM. Maybe it will be a good match for someone else too (it is
virtually unknown).

Here's a patch for it to compile on OpenBSD (you'll need `gmake` and
`asciidoc`):


diff --git a/Makefile b/Makefile
index 1412745..bf5c224 100644
--- a/Makefile
+++ b/Makefile
@@ -41,7 +41,7 @@ tar: doc
 
 doc/%.1: doc/%.txt
$(call colorecho,DOC,$@)
-   @a2x -f manpage -a "herbstluftwmversion=herbstluftwm $(VERSION)" -a 
"date=`date +%Y-%m-%d`" $<
+   @a2x.py -f manpage -a "herbstluftwmversion=herbstluftwm $(VERSION)" -a 
"date=`date +%Y-%m-%d`" $<
 
 doc/%.html: doc/%.txt
$(call colorecho,DOC,$@)
diff --git a/config.mk b/config.mk
index 93a3c9a..e7abf05 100644
--- a/config.mk
+++ b/config.mk
@@ -4,7 +4,7 @@ X11INC = /usr/X11R6/include
 X11LIB = /usr/X11R6/lib
 
 INCS = -Isrc/ -I/usr/include -I${X11INC}  `pkg-config --cflags glib-2.0`
-LIBS = -L/usr/lib -lrt -lc -L${X11LIB} -lX11 `pkg-config --libs glib-2.0`
+LIBS = -L/usr/lib -lc -L${X11LIB} -lX11 `pkg-config --libs glib-2.0`
 
 # FLAGS
 LD = gcc

[dev] Re: herbstluftwm

[Sime Ramov]

Also, forgot that default autostart file needs some adjustments in order
to work in other shells (it is a bash script). I just removed brackets
in function names and commented tag stuff to work with ksh.

[dev] Re: 6.0 roadmap layout decision

[Anselm R Garbe]

I also made my mind up regarding the two other topics that are on the
roadmap for 6.0:

First, there was the idea to simplify the Monitor handling in dwm, due
to the fact that many users use (still?) single-head setups. I thought
a while about possible simplifications but concluded it is not really
worth the buzz.

Second, there was the idea to change dwm's core to be X agnostic in
order to have a nice backend system for example wayland. But I also
conclude this is not really a good idea as this would make dwm's code
base more complex for no real benefit. If one day wayland or something
else will become the leading graphical environment on Linux/Unix then
we can change the necessary code portions to target those and we have
the older releases for X.

These two decision bring dwm 6.0 a lot closer now.

However what I do indeed plan for dwm 6.0 is sharing the functionality
of dmenu that can be shared among both, mainly draw.c. This would
enable us to write certain functions once. There is also potential for
st in this (and probably a future editor project as well that could
use draw.c).

Cheers,
Anselm

Re: [dev] [dwm] 2000 SLOC

[hiro]

I don't like simplyread at all, but drunk as I was I've been playing
around with this http://labs.opera.com/news/2011/10/19/

here's the user stylesheet I'm currently using with it. Great if you
have a large display and don't want to scroll down after every clicked
link.

I also activate the Black on white Contrast stylesheet which comes with opera.

@navigation { nav-up: -o-link-rel(index) }
html{
height: 100%;
overflow: -o-paged-x;
padding: 5%;
box-sizing: border-box;
columns: 25em;
text-align:justify;
}

Re: [dev] [dwm] mapping wm state, and other stories

[Connor Lane Smith]

On 1 November 2011 11:27, Anselm R Garbe  wrote:
> Well applying monocle will lead to other problems. Some fullscreen
> windows will destroy themselves when they loose the input focus (for
> example flash)

They sound like broken clients to me, but fair enough, I think we
should do this, then:

On 1 November 2011 11:11, Anselm R Garbe  wrote:
> Also I would say that accidentally focussing windows that are behind
> the fullscreen window is a user interaction bug. If that's really an
> issue others also have (I rarely had this issue) we could consider
> preventing key bindings or mouse actions that toggle the focus through
> checking selmon->sel->isfullscreen or somtheing similar.

> I don't think so. A window belongs to the monitor where its center is.
> If the center is very close to a boundary

This code breaks when the centre is on neither monitor. I'll look into
making dwm do this by calculating the area of intersection (a small
macro from dmenu).

I still think you should be able to cycle through any floating window
which occupies the selmon, but that would require a radical change in
our Xinerama support.  I might write a supplement patch anyway.

Thanks,
cls

[dev] 6.0 roadmap layout decision

[Anselm R Garbe]

Hi there,

I have made my mind up regarding the recent layout discussion what
should go mainline and what not.

Mainline dwm 6.0 will only feature floating, monocle and tile (as
before). It will also incorporate nmaster inc/decrementing.

bstack and other tuning like 3 columns (2 master cols in bstack, or 2
slave cols in tile) need to be patched in further in the future. I
don't really see a broad use case for them.

Cheers,
Anselm

Re: [dev] [dwm] 2000 SLOC

[hiro]

> I wonder if it would be possible to 'crowdsource' readability so we
> can contribute bits of pages to hide, like on Wikipedia we don't care
> about '[edit]', etc... Not sure how we'd go about that, though.

I'd rather pull out all the contents and indexes out of the most
worthy web sites we navigate to every day and synchronise it with my
file system. This would include the use of something like htmlfmt and
something which can navigate with the help of the indexes.

Re: [dev] Re: [dwm] A general approach to master-slave layouts

[Anselm R Garbe]

On 1 November 2011 02:10, lolilolicon  wrote:
> On Tue, Nov 1, 2011 at 7:36 AM, Rob  wrote:
>>
>> I don't have much time today, or possibly tomorrow, but I'm interested
>> in this patch, it sounds almost like it recurses on each sub-section of
>> the total area, applying a different layout function each time, except
>> it's limited to two calls, one for the master area and one for the
>> slave.
>
> It's only one patch, which I sent in my last mail, so not much really :)
>
> The core is the `apply_mslts' funtion.  It walks all clients like any
> tiling layout would do, e.g., the `tile' function defined in the patch
> simply calls `apply_mslts(m, False, lt_vstack, lt_vstack)`, and it should
> do the layout exactly the same way the original `tile' would do, no extra
> wasted work.  The code should be clear, but maybe note that the mltf/sltf
> functions modify `c'.
>
>> Either way, I'm hoping to try out your patch(es) at some point
>> this week, and hoping to mess around with the key bindings, I assume you
>> can change the master layout while keeping the slave one the same with a
>> binding, right?
>
> Not really.  DWM knows only about a single layout per monitor, even if we
> set the masters to temporarily use a different layout algorithm, but not
> update the currently selected layout name, DWM will rearrange the masters
> back to the selected layout whenever arrangemon() is called, which happens
> probably before you realize it ;).  That said, you can always define two
> layouts which differ only in the master layout, (e.g. `tile' and `col').
> Or if we feel progressive, let's make DWM aware of the master layout as
> well as the slave layout, although I don't see practical need so far.

This progressive approach will lead to two layout actions in a single
view just for a subset of layouts. Overall this will make the usage
much more complicated which is why I would not implement it in
mainline dwm. See my other mail, I suggest making the layout approach
more direct through (re)setting nmaster/mfact in the layout function
as precondition. I'm not totally opposed to have manipulators of
nmaster/mfact optionally though.

> Similarly, I also considered to enable toggling master/slave splitting
> direction, effectively "rotating" the layout, or even allow "flipping",
> but then thought it not useful in practice...

Nah, don't go there. At the end of the day the user applies a
particular layout he feels comfortable with. If the user ends up
fiddling with the layout algorithms all the time then we did something
seriously wrong.

We should never forget that it is the window managers job to manage
the windows, not the users job. Even having a mfact manipulator as of
today does violate this paradigm already a bit.

Cheers,
Anselm

Re: [dev] [dwm] mapping wm state, and other stories

[Anselm R Garbe]

On 1 November 2011 12:18, Connor Lane Smith  wrote:
> On 1 November 2011 11:11, Anselm R Garbe  wrote:
>> I disagree, setting a particular layout implicitly because some random
>> window says it is in fullscreen state is not a great idea imho.
>
> By making one client fullscreen we're already effectively doing this.
> We're just making the other windows invisible, too. That seems to me
> to be even worse.

Well applying monocle will lead to other problems. Some fullscreen
windows will destroy themselves when they loose the input focus (for
example flash). Also bare in mind that you'd treat perfectly fine
positioned clients in a tile layout now as monocles for no really good
reason.

The nature of fullscreen windows is that they are transient and that
there should only be one at  a time. Otherwise you have monocle
already. But implicit layout switching is definitely a no go, as
monocle might not exist at all (at least dwm is designed that layouts
could be easily removed).

>> I don't understand this. Cycling through any kind of windows is
>> monitor specific already, if not we have a bug.
>
> What I mean is, if a window is between monitors, you should be able to
> cycle through it on either monitor, its canonical monitor being the
> one with the largest area of intersection. At the moment the window is
> arbitrarily bound to one of the monitors (you cannot tell which
> without focusing it), and can only be cycled through on that monitor.
> This is a symptom of the stack-per-monitor approach, which imo is a
> design flaw.

I don't think so. A window belongs to the monitor where its center is.
If the center is very close to a boundary, well I don't get what the
purpose is with this approach, why would I want some parts of a client
on different screens?

Cheers,
Anselm

Re: [dev] [dwm] mapping wm state, and other stories

[Connor Lane Smith]

On 1 November 2011 11:11, Anselm R Garbe  wrote:
> I disagree, setting a particular layout implicitly because some random
> window says it is in fullscreen state is not a great idea imho.

By making one client fullscreen we're already effectively doing this.
We're just making the other windows invisible, too. That seems to me
to be even worse.

> I don't understand this. Cycling through any kind of windows is
> monitor specific already, if not we have a bug.

What I mean is, if a window is between monitors, you should be able to
cycle through it on either monitor, its canonical monitor being the
one with the largest area of intersection. At the moment the window is
arbitrarily bound to one of the monitors (you cannot tell which
without focusing it), and can only be cycled through on that monitor.
This is a symptom of the stack-per-monitor approach, which imo is a
design flaw.

Thanks,
cls

Re: [dev] [dwm] mapping wm state, and other stories

[Anselm R Garbe]

On 1 November 2011 11:59, Connor Lane Smith  wrote:
> I noticed dwm has a bug handling _NET_WM_STATE_FULLSCREEN when a
> window is mapped. The EWMH spec says, "The Window Manager SHOULD honor
> _NET_WM_STATE whenever a withdrawn window requests to be mapped. A
> Client wishing to change the state of a window MUST send a
> _NET_WM_STATE client message to the root window." dwm honours
> _NET_WM_STATE_FULLSCREEN client messages in clientmessage(), but
> ignores the property in manage(). We ought to refactor fullscreen
> toggling into a new function and check for the property when the
> window is mapped.

Agreed.

> It would also be nice if dwm supported _NET_WM_WINDOW_TYPE hints as
> well, so we can make _NET_WM_WINDOW_TYPE_DIALOG windows float. (We
> could steal the updatewindowtype() function from Christoph Lohmann's
> dock patch.)

Agreed.

> I sometimes wonder whether it would be simpler to just make
> _NET_WM_STATE_FULLSCREEN switch dwm into monocle mode. Forcing one
> window to be at the front very often leads me to accidentally focus
> and interact with window hidden behind it. Which is why I think
> floating windows ought to be able to be behind tiled windows, too.

I disagree, setting a particular layout implicitly because some random
window says it is in fullscreen state is not a great idea imho.

Also I would say that accidentally focussing windows that are behind
the fullscreen window is a user interaction bug. If that's really an
issue others also have (I rarely had this issue) we could consider
preventing key bindings or mouse actions that toggle the focus through
checking selmon->sel->isfullscreen or somtheing similar.

> I also think we could make floating windows smarter by letting you
> cycle through any floating windows visible on the same monitor, using
> selmon to root us to a single monitor rather than straying off because
> the window "belongs" to another monitor. This would require a single
> client stack instead of one per monitor, like I've talked about
> before. We could also make a floating window's canonical monitor
> dependent on area of intersection, like in dmenu tip. Just throwing
> that out there.

I don't understand this. Cycling through any kind of windows is
monitor specific already, if not we have a bug.

Cheers,
Anselm

[dev] [dwm] mapping wm state, and other stories

[Connor Lane Smith]

Hey all,

I noticed dwm has a bug handling _NET_WM_STATE_FULLSCREEN when a
window is mapped. The EWMH spec says, "The Window Manager SHOULD honor
_NET_WM_STATE whenever a withdrawn window requests to be mapped. A
Client wishing to change the state of a window MUST send a
_NET_WM_STATE client message to the root window." dwm honours
_NET_WM_STATE_FULLSCREEN client messages in clientmessage(), but
ignores the property in manage(). We ought to refactor fullscreen
toggling into a new function and check for the property when the
window is mapped.

It would also be nice if dwm supported _NET_WM_WINDOW_TYPE hints as
well, so we can make _NET_WM_WINDOW_TYPE_DIALOG windows float. (We
could steal the updatewindowtype() function from Christoph Lohmann's
dock patch.)

I sometimes wonder whether it would be simpler to just make
_NET_WM_STATE_FULLSCREEN switch dwm into monocle mode. Forcing one
window to be at the front very often leads me to accidentally focus
and interact with window hidden behind it. Which is why I think
floating windows ought to be able to be behind tiled windows, too.

I also think we could make floating windows smarter by letting you
cycle through any floating windows visible on the same monitor, using
selmon to root us to a single monitor rather than straying off because
the window "belongs" to another monitor. This would require a single
client stack instead of one per monitor, like I've talked about
before. We could also make a floating window's canonical monitor
dependent on area of intersection, like in dmenu tip. Just throwing
that out there.

Well, this email sort of became a loose assortment of ideas, but what
do you folks think? I'll try to produce a few patches once I have some
spare time (unless someone else wants to ;) ).

Thanks,
cls

Re: [dev] [dwm] 2000 SLOC

[Anselm R Garbe]

On 1 November 2011 09:34, anonymous  wrote:
> On Mon, Oct 31, 2011 at 10:21:19PM +0100, Connor Lane Smith wrote:
>> ... because it clashes with the developers' CSS. That's the problem. I
>> think there ought to be pure style-free semantic HTML, and then users
>> can style every site to fit their personal needs, without it resulting
>> in ugly.
>
> http://suckless.org/ is not style-free at all.  Navigation is done using
> lists and there are divs with ids "container", "midHeader", "main-copy"
> and classes "left" and "right".  If you disable CSS, all these lists
> can nearly fill entire screen and these divs are usless if you want to
> create your own style.
>
> IMO navigation lines on top should be done without lists like on
> http://cat-v.org/.  Or, much better, navigation can be completely
> removed and replaced with simple links like on http://www.mutt.org/.
>
> Nice guidelines are already present on http://port70.net/webless/

Funny you mention this, actually this was a plan for quite some time
to tidy suckless.org up and to make its web interface clearer. And
nearly all your points will be used in the new design (though werc of
course will remain, but it's default style isn't great either ;))

Cheers,
Anselm

Re: [dev] [dwm] ncol layout

[Anselm R Garbe]

On 31 October 2011 19:12, Jeremy Jackins  wrote:
>> So in other words, if we can say tha majority use cases are:
>>
>> nmaster: 1-2
>> ncol (slave cols): 1-2
>
> Hm, so are we no longer considering bstack? I agree that mod-shift-t
> would be a nice way to do nmaster=2, but this means that with more
> than two windows I'm stuck a stack on the side and I've lost
> horizontal screen space on my small netbook screen.

No it doesn't mean bstack is not considered. I just try to collect the
opinions and to make some reasoning out of this discussion, see also
my previous email in this thread.

Cheers,
Anselm

Re: [dev] [dwm] ncol layout

[Anselm R Garbe]

On 31 October 2011 20:31, Connor Lane Smith  wrote:
> On 31 October 2011 20:28, Connor Lane Smith  wrote:
>> Also, having special
>> 'set' bindings instead of the simple I-to-Increase, D-to-Decrease, is
>> far harder to remember.
>
> An afterthought: if it's the number of bound keys which is worrying
> you, why not make, e.g., Mod-n increase nmaster, and Mod-Shift-n
> decrease nmaster?

It is not the number of bound keys that is worrying me. It is the
directness of the interaction with the WM that worries me. SInce
manipulating nmaster or mfact is indeed layout specific, I conclude
this should belong to setting a particular layout function.

We identified the main argument for this approach already: user do
tend to stick to very few layout variations -- like nmaster being only
1 or 2, or having a 2 column master area.

Also not having dynamic manipulators for nmaster/mfact (by default),
would increase the clarity of the user interface a bit, as
manipulating the layout requires setting a layout function. And the
user will end up with probably up to 5 favorit layout functions and
this fits very well into the way we apply layouts that do not depent
on nmaster or mfact variables as well.

Cheers,
Anselm

Re: [dev] [dwm] 2000 SLOC

[Nick]

On Tue, Nov 01, 2011 at 10:11:46AM +, Connor Lane Smith wrote:
> On 1 November 2011 09:44, Nick  wrote:
> > - test the current xpi with firefox, using mozilla's addon
> >  compatibility extension, to see if it works, or
> 
> Done. It seems to work fine.

Cool, thanks, I'll release an updated xpi tomorrow.

> A problem, though, is that it removes hyperlinks.

That's by design, actually. I'd rather read just the thing I
want to read, without thinking "maybe i should go here", and go
follow stuff afterwards. Unlike readability, it's designed
to be toggled, so turn it on, read, turn it off, navigate,
is a nice workflow.

> It's not quite smart enough to render a lot of bad sites
> that readable, but it is an improvement.

Yes. I didn't want to fall down the rabbithole of trying to
make it work with too bad code. This is good enough for most
sites in the real world, and to do better would mean a lot
more code and less maintainability.


> I wonder if it would be possible to 'crowdsource' readability so we
> can contribute bits of pages to hide, like on Wikipedia we don't care
> about '[edit]', etc... Not sure how we'd go about that, though.

I can't imagine such a thing would be worth it, or that
things to hide would be entirely shared between people.
There was a firefox extension that allowed you to select
elements and delete them. One could imagine creating some
croudsourcing element around that. But it doesn't seem to me
like it would actually work well.

Re: [dev] Re: [dwm] A general approach to master-slave layouts

[Anselm R Garbe]

On 1 November 2011 00:07, lolilolicon  wrote:
> Indeed mfact and nmaster being members of Layout does make more sense, and
> I made a patch which includes this change.
>
> Note that this may seem to add some SLOCs, but it actually reduces the
> amount of code required to implement the same layouts by avoiding code
> duplication.  See how tile, bstack and col are each defined using just a
> one-liner.  By defining two layout algorithms `lt_vstack` and `lt_hstack`,
> in combination with the hsplit switch, one can define 2 ** 2 * 2 = 8 such
> layouts, and if you count the (masters|slaves)-only layouts as separate
> ones, we got 10.  Add a third layout algorithm, and you have
> 3 ** 2 * 2 + 3 = 21.  Sure, not all layouts are useful for everyone, but
> hopefully this will produce some interesting layouts suitable for your
> particular setup.

Thanks for you patch, I looked at it and it is indeed interesting.
However it needs further testing and review in order to be a candidate
for mainline at some point.

Some remarks:

The change of the Layout struct makes it a lot harder to define
layouts, as now one also has to understand the variables
nmaster/mfact. Also nmaster/mfact are now layout specific variables
that might not be used by other layouts. This lacks a bit conceptual
clarity imho.

What I'd really prefer is keeping the interface intact we had, a
layout is just a function -- I have no objections that this function
calls other functions or set up some variables to fit its needs. This
would keep it equally simple to the user to define Layouts and leave
the interface to be a function, rather than a function + variables.

Also I'm not absolutely happy about the introduction of the Booth
struct, I would rename that into Rect as we have used a similar name
in other areas. Having said this, I'm in favor of *not* using
XRectangle where possible, in order to keep the core code of dwm X
agnostic (which is one 6.0 goal btw).

Cheers,
Anselm

Re: [dev] [dwm] 2000 SLOC

[Connor Lane Smith]

On 1 November 2011 09:44, Nick  wrote:
> As for your futuristic firefox, if you could be so kind,
> could you either:
> - test the current xpi with firefox, using mozilla's addon
>  compatibility extension, to see if it works, or

Done. It seems to work fine. A problem, though, is that it removes
hyperlinks. It's not quite smart enough to render a lot of bad sites
that readable, but it is an improvement.

I wonder if it would be possible to 'crowdsource' readability so we
can contribute bits of pages to hide, like on Wikipedia we don't care
about '[edit]', etc... Not sure how we'd go about that, though.

cls

Re: [dev] [dwm] 2000 SLOC

[Nick]

On Tue, Nov 01, 2011 at 09:34:21AM +, Connor Lane Smith wrote:
> On 31 October 2011 23:28, Nick  wrote:
> > http://njw.me.uk/software/simplyread/ is a little js thing I wrote
> > which is basically a nicer, simpler version of readability. works
> > with surf, uzbl, chrome, firefox.
> 
> Thanks! However, your XPI is incompatible with my Firefox (9.0a2) and
> the source tarball is a 404. :(

Indeed, I just noticed the source tarball was missing. The joys
of having little used software is that you can get away with
such things for a while. I'll fix that tonight.

As for your futuristic firefox, if you could be so kind,
could you either:
- test the current xpi with firefox, using mozilla's addon
  compatibility extension, to see if it works, or
- just grab the latest version from git, change
  em:maxVersion in gecko/install.ttl, and run "make xpi",
  and test it.
And let me know that it works (it should, naturally it
doesn't make use of much of firefox's special sauces).

Re: [dev] [dwm] 2000 SLOC

[Connor Lane Smith]

On 31 October 2011 23:28, Nick  wrote:
> http://njw.me.uk/software/simplyread/ is a little js thing I wrote
> which is basically a nicer, simpler version of readability. works
> with surf, uzbl, chrome, firefox.

Thanks! However, your XPI is incompatible with my Firefox (9.0a2) and
the source tarball is a 404. :(

cls

Re: [dev] Some 2wm questions

[Connor Lane Smith]

On 1 November 2011 08:25, Bert Münnich  wrote:
> I've tried 2wm some time ago, liked the concept but got fed up with its
> old code base. So I wrote a small dwm -> 2wm (d2wm) conversion patch.

Thanks for this.

> The patch simply changes toggle{tag,view}, so that they move the current
> client to the other tag / change the view to the other tag.

I notice this patch doesn't have an attach (M-a) to accompany detach
(M-d). Is this a bug or a feature?

cls

Re: [dev] [dwm] 2000 SLOC

[anonymous]

On Mon, Oct 31, 2011 at 10:21:19PM +0100, Connor Lane Smith wrote:
> ... because it clashes with the developers' CSS. That's the problem. I
> think there ought to be pure style-free semantic HTML, and then users
> can style every site to fit their personal needs, without it resulting
> in ugly.

http://suckless.org/ is not style-free at all.  Navigation is done using
lists and there are divs with ids "container", "midHeader", "main-copy"
and classes "left" and "right".  If you disable CSS, all these lists
can nearly fill entire screen and these divs are usless if you want to
create your own style.

IMO navigation lines on top should be done without lists like on
http://cat-v.org/.  Or, much better, navigation can be completely
removed and replaced with simple links like on http://www.mutt.org/.

Nice guidelines are already present on http://port70.net/webless/

Re: [dev] Some 2wm questions

[Bert Münnich]

On 01.11.11, Connor Lane Smith wrote:
> 2wm is very old and completely unsupported, so I doubt there are
> patches like this. It would be awesome if there were a dwm 'stereo
> patch', though.

I've tried 2wm some time ago, liked the concept but got fed up with its
old code base. So I wrote a small dwm -> 2wm (d2wm) conversion patch.

The patch simply changes toggle{tag,view}, so that they move the current
client to the other tag / change the view to the other tag.

Some additional lines in the patch overwrite the tagnames with the
number of clients attached to the tag.

The patch also changes some mouse and keybindings in config.def.h, most
importantly Mod-{Shift-}Space for toggle{view,tag}, so that one can
directly try it out.


Bert
diff -rup dwm-5.9-orig/config.def.h dwm-5.9/config.def.h
--- dwm-5.9-orig/config.def.h   2011-11-01 08:50:33.0 +0100
+++ dwm-5.9/config.def.h2011-11-01 08:58:00.0 +0100
@@ -14,7 +14,7 @@ static const Bool showbar   = Tr
 static const Bool topbar= True; /* False means bottom bar */
 
 /* tagging */
-static const char *tags[] = { "1", "2", "3", "4", "5", "6", "7", "8", "9" };
+static const char *tags[] = { "1", "2" };
 
 static const Rule rules[] = {
/* class  instancetitle   tags mask isfloating   
monitor */
@@ -35,11 +35,6 @@ static const Layout layouts[] = {
 
 /* key definitions */
 #define MODKEY Mod1Mask
-#define TAGKEYS(KEY,TAG) \
-   { MODKEY,   KEY,  view,   {.ui = 1 << 
TAG} }, \
-   { MODKEY|ControlMask,   KEY,  toggleview, {.ui = 1 << 
TAG} }, \
-   { MODKEY|ShiftMask, KEY,  tag,{.ui = 1 << 
TAG} }, \
-   { MODKEY|ControlMask|ShiftMask, KEY,  toggletag,  {.ui = 1 << 
TAG} },
 
 /* helper for spawning shell commands in the pre dwm-5.0 fashion */
 #define SHCMD(cmd) { .v = (const char*[]){ "/bin/sh", "-c", cmd, NULL } }
@@ -62,24 +57,14 @@ static Key keys[] = {
{ MODKEY|ShiftMask, XK_c,  killclient, {0} },
{ MODKEY,   XK_t,  setlayout,  {.v = 
&layouts[0]} },
{ MODKEY,   XK_f,  setlayout,  {.v = 
&layouts[1]} },
+   { MODKEY|ShiftMask, XK_f,  togglefloating, {0} },
{ MODKEY,   XK_m,  setlayout,  {.v = 
&layouts[2]} },
-   { MODKEY,   XK_space,  setlayout,  {0} },
-   { MODKEY|ShiftMask, XK_space,  togglefloating, {0} },
-   { MODKEY,   XK_0,  view,   {.ui = ~0 } 
},
-   { MODKEY|ShiftMask, XK_0,  tag,{.ui = ~0 } 
},
+   { MODKEY,   XK_space,  toggleview, {0} },
+   { MODKEY|ShiftMask, XK_space,  toggletag,  {0} },
{ MODKEY,   XK_comma,  focusmon,   {.i = -1 } },
{ MODKEY,   XK_period, focusmon,   {.i = +1 } },
{ MODKEY|ShiftMask, XK_comma,  tagmon, {.i = -1 } },
{ MODKEY|ShiftMask, XK_period, tagmon, {.i = +1 } },
-   TAGKEYS(XK_1,  0)
-   TAGKEYS(XK_2,  1)
-   TAGKEYS(XK_3,  2)
-   TAGKEYS(XK_4,  3)
-   TAGKEYS(XK_5,  4)
-   TAGKEYS(XK_6,  5)
-   TAGKEYS(XK_7,  6)
-   TAGKEYS(XK_8,  7)
-   TAGKEYS(XK_9,  8)
{ MODKEY|ShiftMask, XK_q,  quit,   {0} },
 };
 
@@ -94,9 +79,7 @@ static Button buttons[] = {
{ ClkClientWin, MODKEY, Button1,movemouse,  
{0} },
{ ClkClientWin, MODKEY, Button2,togglefloating, 
{0} },
{ ClkClientWin, MODKEY, Button3,resizemouse,
{0} },
-   { ClkTagBar,0,  Button1,view,   
{0} },
-   { ClkTagBar,0,  Button3,toggleview, 
{0} },
-   { ClkTagBar,MODKEY, Button1,tag,
{0} },
-   { ClkTagBar,MODKEY, Button3,toggletag,  
{0} },
+   { ClkTagBar,0,  Button1,toggleview, 
{0} },
+   { ClkTagBar,0,  Button3,toggletag,  
{0} },
 };
 
diff -rup dwm-5.9-orig/dwm.c dwm-5.9/dwm.c
--- dwm-5.9-orig/dwm.c  2011-11-01 08:50:33.0 +0100
+++ dwm-5.9/dwm.c   2011-11-01 08:54:09.0 +0100
@@ -247,7 +247,7 @@ static void zoom(const Arg *arg);
 
 /* variables */
 

Re: [dev] [dwm] 2000 SLOC

[ilf]

On 10-31 23:28, Nick wrote:
http://njw.me.uk/software/simplyread/ is a little js thing I wrote 
which is basically a nicer, simpler version of readability. works 
with surf, uzbl, chrome, firefox. 


Awesome! I've had this idea for years, but never found anyone following 
through with it.


--
ilf

Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung


signature.asc
Description: Digital signature