Hello!
How can I unsubscribe from this maillist?
Thank you.
2008/8/7 <dwm+help_AT_suckless.org>:
> Dear Kai,
>
> On 2008-08-01, Kai Großjohann wrote:
>> Cool! I am a friend of Vimperator, so perhaps one of those could
>> cooperate with it to provide the vi/vim experience when editing
>> textareas, too?
>
> You can use C-i to open your favourite editor inside of a textarea.
>
> Sincerely,
> --
> Antony Jepson / <antonyat_AT_gmail.com> / GPG Key: 0xFA10ED80
> ++ Sic transit gloria mundi. (So passes the glory of ++
> ++ the world.) ++
> ++ -- Thomas a Kempis ++
>
> I didn't want to set border size to 0 because I do like them when I
> have more then one client on the screen at the same time, but I don't
> want them when I just have one.
>
> So I suggest something like this:
>
> in monocle:
> resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
>
> (as per Alexander Polakov's suggestion that I found in this list's archives.)
>
> in tile:
> if(n==1)
> resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
> else
> resize(c, wx, wy, mw - 2 * c->bw, wh - 2 * c->bw, resizehints);
>
> in bstack:
> (I love bstack (maybe because I hate widescreen) and I hardly ever use the regular tile mode.)
>
> if(n==1)
> resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
> else
> resize(c, wx, wy, ww - 2 * c->bw, mh - 2 * c->bw, resizehints);
>
> Ugh, I'd rather fold those if/elses back into one with ternaries, but
> then we'd need three conditionals instead of one. (Which the compiler
> would probably catch, anyway...)
>
> So, in closing:
> I love dwm (just switched to the main branch from good old
> dwm-4.6-rfigura once I realized that bstack was available as a patch) and
> this is my first post to this list.
>
> I hope that this functionality can go into main; it doesn't increase
> the mental load on the user (like toggleborders or a config option
> would) since it happens automatically, but if you don't like it, I'll
> understand.
>
> Sunnan
>
>
>
>
> On Sat, Aug 2, 2008 at 9:41 AM, Sunnan <sunnan_AT_handgranat.org> wrote:
>>
>> I didn't want to set border size to 0 because I do like them when I
>> have more then one client on the screen at the same time, but I don't
>> want them when I just have one.
>>
>> So I suggest something like this:
>>
>> in monocle:
>> resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
>>
>> (as per Alexander Polakov's suggestion that I found in this list's archives.)
>>
>> in tile:
>> if(n==1)
>> resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
>> else
>> resize(c, wx, wy, mw - 2 * c->bw, wh - 2 * c->bw, resizehints);
>>
>> in bstack:
>> (I love bstack (maybe because I hate widescreen) and I hardly ever use the regular tile mode.)
>>
>> if(n==1)
>> resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
>> else
>> resize(c, wx, wy, ww - 2 * c->bw, mh - 2 * c->bw, resizehints);
>>
>> Ugh, I'd rather fold those if/elses back into one with ternaries, but
>> then we'd need three conditionals instead of one. (Which the compiler
>> would probably catch, anyway...)
>>
>> So, in closing:
>> I love dwm (just switched to the main branch from good old
>> dwm-4.6-rfigura once I realized that bstack was available as a patch) and
>> this is my first post to this list.
>>
>> I hope that this functionality can go into main; it doesn't increase
>> the mental load on the user (like toggleborders or a config option
>> would) since it happens automatically, but if you don't like it, I'll
>> understand.
>>
>> Sunnan
>>
>>
>>
>
>
>
> --
> Ian Daniher
> --
> OLPC Support Volunteer
> OLPCinci Repair Center Coordinator
> --
> it.daniher_AT_gmail.com
> Skype : it.daniher
> irc.freenode.com: Ian_Daniher
> --
> c: 513.290.4942
>
> Hello,
>
> Correct me if I'm wrong, but is the purpose of the monocle layout simply
> to make dwm more manageable for people with multiple screens?
>
> Sincerely,
> --
> Antony Jepson / <antonyat_AT_gmail.com> / GPG Key: 0xFA10ED80
> ++ Veni, vidi, vici. (I came, I saw, I conquered.) ++
> ++ -- Gaius Iulius Caesar ++
>
> Antony Jepson dixit (2008-08-02, 14:53):
>
>> Correct me if I'm wrong, but is the purpose of the monocle layout simply
>> to make dwm more manageable for people with multiple screens?
>
> I'd rather say it's very useful on small screens. I have it as default
> layout on my 8,9" HP Mini-note and seldom use other layouts.
>
> BTW, a friend and I came up with the idea, that it would be useful to
> have some visual hint of how many windows you are actually viewing in
> monocle. Say, there are five windows with currently viewed tag and
> you're viewing the third window in the stack; then there could be an
> indicator like: [3/5] or [..*..]. What do you guys think about that?
>
> Best,
>
> --
> [a]
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkiUr6YACgkQL69KEesxVYNF+gCeJ21zE+yz1t3JVHJjWSbzzR/a
> r2gAoIIpbx6XoxErtBvpihSgEmZkFUM0
> =D4JP
> -----END PGP SIGNATURE-----
>
> Hi All,
> I use Monocle it often on my 12" portable.
>
> BTW, a friend and I came up with the idea, that it would be useful to
> have some visual hint of how many windows you are actually viewing in
> monocle. Say, there are five windows with currently viewed tag and
> you're viewing the third window in the stack; then there could be an
> indicator like: [3/5] or [..*..]. What do you guys think about that?
>
> I definitely think that an indicator of how many windows are on the tab would be helpful.
>
> Also, implementing the alt-tab to switch between the windows on that tab would seem to make sense.
>
> Not being a C coder, I can't offer assistance in the creation of a patch or in the addition of code, but I'd greatly appreciate the aforementioned functionality.
>
> Thanks!
> --
> Ian Daniher
> --
> OLPC Support Volunteer
> OLPCinci Repair Center Coordinator
> --
> it.daniher_AT_gmail.com
> Skype : it.daniher
> irc.freenode.com: Ian_Daniher
>
>
> Well, could'nt you just add:
> { MODKEY, XK_e, focusstack, {.i = -1 } },
> To your config.h and remove:
> { MODKEY, XK_Tab, view, {0} },
>
> To achive this behavior? Regarding alt-tab to change client.
>
> Regards
> Rickard
>
> On [Sat 02.08.2008 16:31], Ian Daniher wrote:
>> Hi All,
>> I use Monocle it often on my 12" portable.
>>
>> BTW, a friend and I came up with the idea, that it would be useful to
>> have some visual hint of how many windows you are actually viewing in
>> monocle. Say, there are five windows with currently viewed tag and
>> you're viewing the third window in the stack; then there could be an
>> indicator like: [3/5] or [..*..]. What do you guys think about that?
>>
>> I definitely think that an indicator of how many windows are on the tab
>> would be helpful.
>>
>> Also, implementing the alt-tab to switch between the windows on that tab
>> would seem to make sense.
>>
>> Not being a C coder, I can't offer assistance in the creation of a patch
>> or in the addition of code, but I'd greatly appreciate the aforementioned
>> functionality.
>>
>> Thanks!
>> --
>> Ian Daniher
>> --
>> OLPC Support Volunteer
>> OLPCinci Repair Center Coordinator
>> --
>> it.daniher_AT_gmail.com
>> Skype : it.daniher
>> irc.freenode.com: Ian_Daniher
> Ev'ning,
>
> On Sat, Aug 02, 2008 at 04:31:50PM -0400, Ian Daniher wrote:
>> BTW, a friend and I came up with the idea, that it would be useful to
>> have some visual hint of how many windows you are actually viewing in
>> monocle. Say, there are five windows with currently viewed tag and
>> you're viewing the third window in the stack; then there could be an
>> indicator like: [3/5] or [..*..]. What do you guys think about that?
>
> hm, just took a quick glance into the code and suppose,
> using the current design, it would result in [1/5] whichever of the 5
> windows is focused, because focusing another window internally results in
> moving the window to the top of a stack. There is no fixed order of
> all windows currently tagged.
>
> *time keeps running on...*
>
> oook, wasn't a big problem in the end, even if it took some time..
> a patch for your request can be found at
>
> http://v4hn.de/patches/dwm-5.1_monocle_count.diff
>
> have fun using it :)
>
>> I definitely think that an indicator of how many windows are on the tab
>> would be helpful.
>>
>> Also, implementing the alt-tab to switch between the windows on that tab
>> would seem to make sense.
>
> What's the problem? Change this line in config.h
>
> { MODKEY, XK_j, focusstack, {.i = +1 } },
>
> to
>
> { MODKEY, XK_Tab, focusstack, {.i = +1 } },
>
> and if your MODKEY is Alt, you got your alt-tab-switch..
>
>
> v4hn
>
>
> PS: It's absolutly great to hack your code everyone,
> such pearls of design are seldom...
>
> Dear v4nn,
>
> On 2008-08-03, v4hn wrote:
>> a patch for your request can be found at
>>
>> http://v4hn.de/patches/dwm-5.1_monocle_count.diff
>
> This patch is useful. Mind if I add it to the wiki?
>
> --
> Antony Jepson / <antonyat_AT_gmail.com> / GPG Key: 0xFA10ED80
> ++ Sic transit gloria mundi. (So passes the glory of ++
> ++ the world.) ++
> ++ -- Thomas a Kempis ++
>
> "Ian Daniher" <it.daniher_AT_gmail.com> wrote:
>
>> Hi All,
>> I use Monocle it often on my 12" portable.
>>
>> BTW, a friend and I came up with the idea, that it would be useful to
>> have some visual hint of how many windows you are actually viewing in
>> monocle. Say, there are five windows with currently viewed tag and
>> you're viewing the third window in the stack; then there could be an
>> indicator like: [3/5] or [..*..]. What do you guys think about that?
>
> +/- 0
> I don't think it helps you a lot.
>
>> I definitely think that an indicator of how many windows are on the tab
>> would be helpful.
>>
>> Also, implementing the alt-tab to switch between the windows on that tab
>> would seem to make sense.
>
> +1
> I would really like to see this in dwm soon.
>
>> Not being a C coder, I can't offer assistance in the creation of a patch or
>> in the addition of code, but I'd greatly appreciate the aforementioned
>> functionality.
>>
>> Thanks!
>> --
>> Ian Daniher
>
> Regards
> Matthias-Christian
> On Sat, Aug 02, 2008 at 10:03:10PM -0400, Antony Jepson wrote:
>> Dear v4nn,
>>
>> On 2008-08-03, v4hn wrote:
>> > a patch for your request can be found at
>> >
>> > http://v4hn.de/patches/dwm-5.1_monocle_count.diff
>>
>> This patch is useful. Mind if I add it to the wiki?
>
> No problem with that, so do it if you like to.
> (but please spell my nick correctly ;) )
>
>
> v4hn
>
> 2008/8/2 Ian Daniher <it.daniher_AT_gmail.com>:
>> BTW, a friend and I came up with the idea, that it would be useful to
>> have some visual hint of how many windows you are actually viewing in
>> monocle. Say, there are five windows with currently viewed tag and
>> you're viewing the third window in the stack; then there could be an
>> indicator like: [3/5] or [..*..]. What do you guys think about that?
>
> This idea is rather old and it was implemented once in some official
> version of dwm. However, because it is only interesting for 1
> particular layout, namely monocle, it has been removed again. AFAIR
> the solution to the problem was a change to the Layout struct, instead
> of defining a simple symbol string for the layout, I used some
> function pointer which returned the layout symbol string.
>
> When using this indicator for some time, I concluded that it wasn't
> obvious enough to be useful, especially because the information "nth
> client of X clients" doesn't give you much -- you rarely remember the
> client order anyways.
>
> Because of the fact that dwm is a dynamic window manager, my
> recommended solution is to switch to some appropriate layout before
> you focus the particular client you are looking for, and then
> switching to monocle again.
>
> So, the way I use monocle is usually only on a client basis or on very
> few clients -- there is the powerful tagging concept for grouping the
> clients you work on.
>
> With this in mind, this idea won't go mainstream again ;)
>
>> Also, implementing the alt-tab to switch between the windows on that tab
>> would seem to make sense.
>
> The philosophy behind dwm and all other less suckish projects I'm
> involved in follows the idea that there should be only 1 distinct
> operation to perform a certain function. If any feature of some
> software can only and always be performed in using 1 distinct
> operation (which never changes), then it is easier to remember and to
> use. Hence one indicator of bad software design is if there are plenty
> ways performing the same operation (e.g. having an icon to click on, a
> shortcut, a menu entry, a context menu entry, another shortcut, etc).
> This indication applies to vim unfortunately -- there is :wq and ZZ
> and what not for instance -- it basically performs the same
> operations, polluting your command space unnecessarily and making you
> think a lot which is the fastest way to perform a certain operation in
> a certain situation, that sucks).
>
> The only exception regarding the 1 distinct operation paradigm is to
> allow only 1 distinct different way in performing it, if there is a
> different input device, like the mouse.
>
> Having two key bindings for the same thing also makes the usage less
> consistent, because Mod1-Tab (in default setup) has a totally
> different meaning. So IMHO Mod1-j/Mod1-k are the navigation shortcuts
> in all layouts (at least in default setup).
>
> And if you are unhappy with this, feel free to change it in config.h.
>
> Kind regards,
> --Anselm
> You remember me that I considered this for mainstream dwm a while ago,
> but forgot about it. Since all tiled windows are restacked under the
> bar window, I don't see any flaws in this solution. The usual way of
> doing it, would be to set the c->bw to 0 in such a case, but some
> clients perform poorly with this, so I really like this particular
> solution.
>
> Any objections in making this mainstream?
>
> Kind regards,
> Anselm
>
> 2008/8/2 Sunnan <sunnan_AT_handgranat.org>:
>> I didn't want to set border size to 0 because I do like them when I
>> have more then one client on the screen at the same time, but I don't
>> want them when I just have one.
>>
>> So I suggest something like this:
>>
>> in monocle:
>> resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
>>
>> (as per Alexander Polakov's suggestion that I found in this list's archives.)
>>
>> in tile:
>> if(n==1)
>> resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
>> else
>> resize(c, wx, wy, mw - 2 * c->bw, wh - 2 * c->bw, resizehints);
>>
>> in bstack:
>> (I love bstack (maybe because I hate widescreen) and I hardly ever use the regular tile mode.)
>>
>> if(n==1)
>> resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
>> else
>> resize(c, wx, wy, ww - 2 * c->bw, mh - 2 * c->bw, resizehints);
>>
>> Ugh, I'd rather fold those if/elses back into one with ternaries, but
>> then we'd need three conditionals instead of one. (Which the compiler
>> would probably catch, anyway...)
>>
>> So, in closing:
>> I love dwm (just switched to the main branch from good old
>> dwm-4.6-rfigura once I realized that bstack was available as a patch) and
>> this is my first post to this list.
>>
>> I hope that this functionality can go into main; it doesn't increase
>> the mental load on the user (like toggleborders or a config option
>> would) since it happens automatically, but if you don't like it, I'll
>> understand.
>>
>> Sunnan
>
> Well, I've experienced some buggy behavior and I have no idea what the
> problem might be and if it's because of this hack or not. The
> behaviour is that sometimes I'll have two clients visible (one per tag
> and both tags visible) and then both try to be master, one taking up
> mh (I'm using bstack) and one taking up wh-mh but both starting at the
> top of the screen.
>
> Anyway, I found a nicer-looking (???) way to code my original
> suggestion; instead of:
> if(n==1)
> resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
> else
> resize(c, wx, wy, ww - 2 * c->bw, mh - 2 * c->bw, resizehints);
>
> if(--n == 0)
> return;
>
> The two checks can be folded into one, like this:
>
> if (--n == 0) {
> resize(c, wx-c->bw, wy-c->bw, ww, wh, resizehints);
> return;
> }
> resize(c, wx, wy, ww - 2 * c->bw, mh - 2 * c->bw, resizehints);
>
> the guard clause allowing us to eliminate the else.
> The weird behavior is the same with both versions, though... wonder
> what I've done wrong.
>
> Btw, there's a huge amount of "- 2 * c->bw" in dwm; maybe this could
> be extracted to a function or macro?
>
> I've got a lisp background so I never want two sexps looking the same;
> and when I try to write C (with mediocre results) I tend to think of
> the syntax tree nodes as sexps, too.
>
> I'd love it if this automatic border toggling becomes mainstream,
> though! Thanks for your attention.
>
> Sunnan
>
> At Sun, 3 Aug 2008 10:56:20 +0100,
> Anselm R Garbe wrote:
>>
>> You remember me that I considered this for mainstream dwm a while ago,
>> but forgot about it. Since all tiled windows are restacked under the
>> bar window, I don't see any flaws in this solution. The usual way of
>> doing it, would be to set the c->bw to 0 in such a case, but some
>> clients perform poorly with this, so I really like this particular
>> solution.
>>
>> Any objections in making this mainstream?
>>
>> Kind regards,
>> Anselm
>>
>> 2008/8/2 Sunnan <sunnan_AT_handgranat.org>:
>> > I didn't want to set border size to 0 because I do like them when I
>> > have more then one client on the screen at the same time, but I don't
>> > want them when I just have one.
>> >
>> > So I suggest something like this:
>> >
>> > in monocle:
>> > resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
>> >
>> > (as per Alexander Polakov's suggestion that I found in this list's archives.)
>> >
>> > in tile:
>> > if(n==1)
>> > resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
>> > else
>> > resize(c, wx, wy, mw - 2 * c->bw, wh - 2 * c->bw, resizehints);
>> >
>> > in bstack:
>> > (I love bstack (maybe because I hate widescreen) and I hardly ever use the regular tile mode.)
>> >
>> > if(n==1)
>> > resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
>> > else
>> > resize(c, wx, wy, ww - 2 * c->bw, mh - 2 * c->bw, resizehints);
>> >
>> > Ugh, I'd rather fold those if/elses back into one with ternaries, but
>> > then we'd need three conditionals instead of one. (Which the compiler
>> > would probably catch, anyway...)
>> >
>> > So, in closing:
>> > I love dwm (just switched to the main branch from good old
>> > dwm-4.6-rfigura once I realized that bstack was available as a patch) and
>> > this is my first post to this list.
>> >
>> > I hope that this functionality can go into main; it doesn't increase
>> > the mental load on the user (like toggleborders or a config option
>> > would) since it happens automatically, but if you don't like it, I'll
>> > understand.
>> >
>> > Sunnan
>>
> 2008/8/3 Sunnan <sunnan_AT_handgranat.org>:
>> Well, I've experienced some buggy behavior and I have no idea what the
>> problem might be and if it's because of this hack or not. The
>> behaviour is that sometimes I'll have two clients visible (one per tag
>> and both tags visible) and then both try to be master, one taking up
>> mh (I'm using bstack) and one taking up wh-mh but both starting at the
>> top of the screen.
>
> That might be a issue in bstack, but I never noticed such behavior in
> default dwm.
>
>> Anyway, I found a nicer-looking (???) way to code my original
>> suggestion; instead of:
>> if(n==1)
>> resize(c, wx-c->bw, wy-c->bw, ww, wh, False);
>> else
>> resize(c, wx, wy, ww - 2 * c->bw, mh - 2 * c->bw, resizehints);
>>
>> if(--n == 0)
>> return;
>>
>> The two checks can be folded into one, like this:
>>
>> if (--n == 0) {
>> resize(c, wx-c->bw, wy-c->bw, ww, wh, resizehints);
>> return;
>> }
>> resize(c, wx, wy, ww - 2 * c->bw, mh - 2 * c->bw, resizehints);
>>
>> the guard clause allowing us to eliminate the else.
>
> Hmm, there is no need for --n.
>
> if(n == 1) {
> resize(c, wx-c->bw, wy-c->bw, ww, wh, resizehints);
> return;
> }
> ...
>
>> Btw, there's a huge amount of "- 2 * c->bw" in dwm; maybe this could
>> be extracted to a function or macro?
>
> Yeah, might look cleaner.
>
>
> Kind regards,
> --Anselm
> At Sun, 3 Aug 2008 13:26:27 +0100,
> Anselm R Garbe wrote:
>> Hmm, there is no need for --n.
>>
>> if(n == 1) {
>> resize(c, wx-c->bw, wy-c->bw, ww, wh, resizehints);
>> return;
>> }
>> ...
>
> It uses n when it stacks the tile and depends on n being the number of
> non-master clients, i.e. decremented.
>
> Sunnan
> Matthias-Christian Ott <ott_AT_enolink.de> wrote:
>
>> "Anselm R Garbe" <garbeam_AT_gmail.com> wrote:
>>
>> > 2008/8/2 Ian Daniher <it.daniher_AT_gmail.com>:
>> > > BTW, a friend and I came up with the idea, that it would be useful to
>> > > have some visual hint of how many windows you are actually viewing in
>> > > monocle. Say, there are five windows with currently viewed tag and
>> > > you're viewing the third window in the stack; then there could be an
>> > > indicator like: [3/5] or [..*..]. What do you guys think about that?
>> >
>> > This idea is rather old and it was implemented once in some official
>> > version of dwm. However, because it is only interesting for 1
>> > particular layout, namely monocle, it has been removed again. AFAIR
>> > the solution to the problem was a change to the Layout struct, instead
>> > of defining a simple symbol string for the layout, I used some
>> > function pointer which returned the layout symbol string.
>> >
>> > When using this indicator for some time, I concluded that it wasn't
>> > obvious enough to be useful, especially because the information "nth
>> > client of X clients" doesn't give you much -- you rarely remember the
>> > client order anyways.
>> >
>> > Because of the fact that dwm is a dynamic window manager, my
>> > recommended solution is to switch to some appropriate layout before
>> > you focus the particular client you are looking for, and then
>> > switching to monocle again.
>> >
>> > So, the way I use monocle is usually only on a client basis or on very
>> > few clients -- there is the powerful tagging concept for grouping the
>> > clients you work on.
>> >
>> > With this in mind, this idea won't go mainstream again ;)
>> >
>> > > Also, implementing the alt-tab to switch between the windows on that tab
>> > > would seem to make sense.
>> >
>> > The philosophy behind dwm and all other less suckish projects I'm
>> > involved in follows the idea that there should be only 1 distinct
>> > operation to perform a certain function. If any feature of some
>> > software can only and always be performed in using 1 distinct
>> > operation (which never changes), then it is easier to remember and to
>> > use. Hence one indicator of bad software design is if there are plenty
>> > ways performing the same operation (e.g. having an icon to click on, a
>> > shortcut, a menu entry, a context menu entry, another shortcut, etc).
>> > This indication applies to vim unfortunately -- there is :wq and ZZ
>> > and what not for instance -- it basically performs the same
>> > operations, polluting your command space unnecessarily and making you
>> > think a lot which is the fastest way to perform a certain operation in
>> > a certain situation, that sucks).
>> >
>> > The only exception regarding the 1 distinct operation paradigm is to
>> > allow only 1 distinct different way in performing it, if there is a
>> > different input device, like the mouse.
>> >
>> > Having two key bindings for the same thing also makes the usage less
>> > consistent, because Mod1-Tab (in default setup) has a totally
>> > different meaning. So IMHO Mod1-j/Mod1-k are the navigation shortcuts
>> > in all layouts (at least in default setup).
>> >
>> > And if you are unhappy with this, feel free to change it in config.h.
>> >
>> > Kind regards,
>> > --Anselm
>> :q!
>
> Sorry just thought that I was in vi ;). Just wanted to add that I didn't
> know about Mod1-j and Mod1-k in monocle. Thanks for the explaination -
> now it makes sense to me.
>
> Regards
> Matthias-Christian
> Regards
> Matthias-Christian
> I'd like second that - I didn't ask for that as a change of defaults, but I was unaware that the feature was already instituted. Thanks!
>
> On Sun, Aug 3, 2008 at 9:35 AM, Matthias-Christian Ott <ott_AT_enolink.de> wrote:
>>
>> Matthias-Christian Ott <ott_AT_enolink.de> wrote:
>>
>> > "Anselm R Garbe" <garbeam_AT_gmail.com> wrote:
>> >
>> > > 2008/8/2 Ian Daniher <it.daniher_AT_gmail.com>:
>> > > > BTW, a friend and I came up with the idea, that it would be useful to
>> > > > have some visual hint of how many windows you are actually viewing in
>> > > > monocle. Say, there are five windows with currently viewed tag and
>> > > > you're viewing the third window in the stack; then there could be an
>> > > > indicator like: [3/5] or [..*..]. What do you guys think about that?
>> > >
>> > > This idea is rather old and it was implemented once in some official
>> > > version of dwm. However, because it is only interesting for 1
>> > > particular layout, namely monocle, it has been removed again. AFAIR
>> > > the solution to the problem was a change to the Layout struct, instead
>> > > of defining a simple symbol string for the layout, I used some
>> > > function pointer which returned the layout symbol string.
>> > >
>> > > When using this indicator for some time, I concluded that it wasn't
>> > > obvious enough to be useful, especially because the information "nth
>> > > client of X clients" doesn't give you much -- you rarely remember the
>> > > client order anyways.
>> > >
>> > > Because of the fact that dwm is a dynamic window manager, my
>> > > recommended solution is to switch to some appropriate layout before
>> > > you focus the particular client you are looking for, and then
>> > > switching to monocle again.
>> > >
>> > > So, the way I use monocle is usually only on a client basis or on very
>> > > few clients -- there is the powerful tagging concept for grouping the
>> > > clients you work on.
>> > >
>> > > With this in mind, this idea won't go mainstream again ;)
>> > >
>> > > > Also, implementing the alt-tab to switch between the windows on that tab
>> > > > would seem to make sense.
>> > >
>> > > The philosophy behind dwm and all other less suckish projects I'm
>> > > involved in follows the idea that there should be only 1 distinct
>> > > operation to perform a certain function. If any feature of some
>> > > software can only and always be performed in using 1 distinct
>> > > operation (which never changes), then it is easier to remember and to
>> > > use. Hence one indicator of bad software design is if there are plenty
>> > > ways performing the same operation (e.g. having an icon to click on, a
>> > > shortcut, a menu entry, a context menu entry, another shortcut, etc).
>> > > This indication applies to vim unfortunately -- there is :wq and ZZ
>> > > and what not for instance -- it basically performs the same
>> > > operations, polluting your command space unnecessarily and making you
>> > > think a lot which is the fastest way to perform a certain operation in
>> > > a certain situation, that sucks).
>> > >
>> > > The only exception regarding the 1 distinct operation paradigm is to
>> > > allow only 1 distinct different way in performing it, if there is a
>> > > different input device, like the mouse.
>> > >
>> > > Having two key bindings for the same thing also makes the usage less
>> > > consistent, because Mod1-Tab (in default setup) has a totally
>> > > different meaning. So IMHO Mod1-j/Mod1-k are the navigation shortcuts
>> > > in all layouts (at least in default setup).
>> > >
>> > > And if you are unhappy with this, feel free to change it in config.h.
>> > >
>> > > Kind regards,
>> > > --Anselm
>> > :q!
>>
>> Sorry just thought that I was in vi ;). Just wanted to add that I didn't
>> know about Mod1-j and Mod1-k in monocle. Thanks for the explaination -
>> now it makes sense to me.
>>
>> Regards
>> Matthias-Christian
>> Regards
>> Matthias-Christian
>>
>
>
>
> --
> Ian Daniher
>
>
> Sunnan,
>
> Do you only see the strange bstack behavior with your patch applied?
> After reading your post I went back and looked at the patch, I noticed a
> minor diff between bstack and tile ( - instead of a + in one line ). I
> just pushed a new diff you can either get it here [0]. If you saw this
> issue without your patch let me know if this fixes it. It should be
> pretty much in line with the current tile now. Thanks.
>
> [0] http://bsdgroup.org/files/dwm-5.1-bstack.diff
>
> --
> James Turner
> BSD Group Consulting
> http://www.bsdgroup.org
> At Sun, 3 Aug 2008 09:54:56 -0400,
> James Turner wrote:
>> Do you only see the strange bstack behavior with your patch applied?
>> After reading your post I went back and looked at the patch, I noticed a
>> minor diff between bstack and tile ( - instead of a + in one line ). I
>
> That could be it; I've applied the change and will let you know if the
> problems re-appear. I won't see the change until I restart X.
>
> Sunnan
> v4hn,
>
> On 2008-08-03, v4hn wrote:
>> No problem with that, so do it if you like to.
>> (but please spell my nick correctly ;) )
>>
>>
>> v4hn
>
> I apologise. I've pushed the changes into the wiki.
>
> Sincerely,
> --
> Antony Jepson / <antonyat_AT_gmail.com> / GPG Key: 0xFA10ED80
> ++ If you don't know where you are going, any road will ++
> ++ get you there. ++
> ++ -- Lewis Carroll ++
>
> Others have stated that they used it on small screens. I find that even with bigger screens some programs tend to be full-screen anyway. One prime example is the web browser. Also, if you use one of those graphical mail reading thingies, then they have lots and lots of little windows and toolbars, so you'll want those to be full-screen, too. And then there are IDEs and PDF viewers.
>
> I often gather multiple of such windows into one tag, which is in monocle layout.
>
> Kai
>
> Antony Jepson wrote:
>>
>> Hello,
>>
>> Correct me if I'm wrong, but is the purpose of the monocle layout simply
>> to make dwm more manageable for people with multiple screens?
>>
>> Sincerely,
>>
>
> Antony Jepson wrote:
>
> On 2008-08-01, Kai Großjohann wrote:
>
>
> Cool! I am a friend of Vimperator, so perhaps one of those could
> cooperate with it to provide the vi/vim experience when editing
> textareas, too?
>
>
> You can use C-i to open your favourite editor inside of a textarea.
>
>
> OMG ;-)
>
> I don't know whether I should rejoice or cry. Should I cry because of all the lost time? Or rejoice because I know it?
>
> Maybe I'll choose rejoicing because I am an optimist at heart and also it feels better.
>
> Thank you very kindly, sir.
>
> Kai
>
>
> Dear Kai,
>
> On 2008-08-03, Kai Großjohann wrote:
>> OMG ;-)
>>
>> I don't know whether I should rejoice or cry. Should I cry because of
>> all the lost time? Or rejoice because I know it?
>>
>> Maybe I'll choose rejoicing because I am an optimist at heart and also
>> it feels better.
>>
>> Thank you very kindly, sir.
>>
>> Kai
>
> You should rejoice because of the time you'll save in the future =P.
>
> No problem; glad to spread the love (and knowledge).
>
> Sincerely,
> --
> Antony Jepson / <antonyat_AT_gmail.com> / GPG Key: 0xFA10ED80
> ++ Corgito, ergo sum. (I think, therefore I am.) ++
> ++ -- Rene Descartes ++
>
> Dear Kai,
>
> On 2008-08-03, Kai Großjohann wrote:
>> Others have stated that they used it on small screens. I find that even
>> with bigger screens some programs tend to be full-screen anyway. One
>> prime example is the web browser. Also, if you use one of those
>> graphical mail reading thingies, then they have lots and lots of little
>> windows and toolbars, so you'll want those to be full-screen, too. And
>> then there are IDEs and PDF viewers.
>>
>> I often gather multiple of such windows into one tag, which is in
>> monocle layout.
>
> It is definitely useful on large screens. At a 1680x1050 resolution, a
> full screen Web browser is a God-send.
>
> Most of the time, all I'll have open is Firefox and rxvt-unicode
> (screen, mutt, irssi, finch, etc.); monocle makes it a breeze to switch
> between apps.
>
> Thanks to whoever contributed the monocle patch.
>
> Sincerely,
> --
> Antony Jepson / <antonyat_AT_gmail.com> / GPG Key: 0xFA10ED80
> ++ Sapere aude! (Dare to be wise!) ++
> ++ -- Quintus Horatius Flaccus ++
>
> On 8/4/08, Antony Jepson <antonyat_AT_gmail.com> wrote:
>> It is definitely useful on large screens. At a 1680x1050 resolution, a
>> full screen Web browser is a God-send.
>
> wide screen browser? i don't see the point.. may be with scaled up
> fonts, otherwise reading lot of text in one line would be hard on the
> eyes
> ..or did you mean 1050x1680?
> hi! i'm using dwm right now, and it's here to stay in my config, but
> i'm a convert from fluxbox, and on it, i used to run gkrellm, it was
> beautifull to have it showed in every desktop, so right now i think if
> it's posible to have gkrellm in dwm, in the exact same behavior, so it
> shows in every tag, and the opened apps, dont get over it, like the
> slit in fluxbox...
>
> here's my config.h, i've added gkrellm to the floating apps list, but
> don't know how to edit it so gkrellm show in every tag
>
> /* See LICENSE file for copyright and license details. */
>
> /* appearance */
> /* static const char font[] =
> "-*-terminus-medium-r-normal-*-18-*-*-*-*-*-*-*"; */
> static const char font[] =
> "-*-fixed-medium-r-*-*-18-*-*-*-*-*-iso8859-*";
> static const char normbordercolor[] = "#111111";
> static const char normbgcolor[] = "#000000";
> static const char normfgcolor[] = "#ffffff";
> static const char selbordercolor[] = "#777777";
> static const char selbgcolor[] = "#222222";
> static const char selfgcolor[] = "#ffffff";
> static unsigned int borderpx = 1; /* border pixel of windows */
> static unsigned int snap = 32; /* snap pixel */
> static Bool showbar = True; /* False means no bar */
> static Bool topbar = False; /* False means bottom bar */
>
> /* tagging */
> static const char tags[][MAXTAGLEN] = { "1", "2", "3", "4", "5", "6",
> "7", "8", "9" };
>
> static Rule rules[] = {
> /* class instance title tags mask isfloating */
> { "Gimp", NULL, NULL, 0, True },
> { "Firefox", NULL, NULL, 1 << 8, True },
> { "MPlayer", NULL, "MPlayer", 0, True },
> { "feh", NULL, "feh", 0, True },
> { "glxgears", "glxgears", "glxgears", 0, True },
> { "vlc", NULL, "vlc", 0, True },
> { "xine", NULL, "xine", 0, True },
> { "gkrellm", NULL, "gkrellm", 0, True },
> { "galculator", NULL, NULL, 0, True },
> { "xcalc", NULL, NULL, 0, True },
> { "winff", NULL, "winff", 0, True },
> { "snes9x", NULL, "snes9x", 0, True },
>
> };
>
> /* layout(s) */
> static float mfact = 0.55;
> static Bool resizehints = True; /* False means respect size hints in
> tiled resizals */
>
> static Layout layouts[] = {
> /* symbol arrange function */
> { "[]=", tile }, /* first entry is default */
> { "><>", NULL }, /* no layout function means floating behavior */
> { "[M]", monocle },
> };
>
> /* 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 } }
>
> /* commands */
> static const char *dmenucmd[] = { "dmenu_run", "-fn", font, "-nb",
> normbgcolor, "-nf", normfgcolor, "-sb", selbgcolor, "-sf", selfgcolor,
> NULL };
> static const char *termcmda[] = { "urxvt", NULL };
> static const char *termcmdb[] = { "urxvt", "-sh", "50", NULL };
> static const char *amixcmdua[] = { "amixer", "-q", "set", "PCM", "20+", NULL };
> static const char *amixcmdda[] = { "amixer", "-q", "set", "PCM", "20-", NULL };
> static const char *amixcmdub[] = { "amixer", "-q", "set", "Front",
> "10+", NULL };
> static const char *amixcmddb[] = { "amixer", "-q", "set", "Front",
> "10-", NULL };
>
> static Key keys[] = {
> /* modifier key function argument */
> { MODKEY, XK_p, spawn, {.v =
> dmenucmd } },
> { MODKEY, XK_Return, spawn, {.v
> = termcmda } },
> { MODKEY|ShiftMask, XK_Return, spawn, {.v
> = termcmdb } },
> { MODKEY, XK_z, spawn, {.v
> = amixcmdda } },
> { MODKEY, XK_x, spawn, {.v
> = amixcmdua } },
> { MODKEY|ShiftMask, XK_z, spawn, {.v
> = amixcmddb } },
> { MODKEY|ShiftMask, XK_x, spawn, {.v
> = amixcmdub } },
> { MODKEY, XK_b, togglebar, {0} },
> { MODKEY, XK_j, focusstack, {.i = +1 } },
> { MODKEY, XK_k, focusstack, {.i = -1 } },
> { MODKEY, XK_h, setmfact, {.f = -0.05} },
> { MODKEY, XK_l, setmfact, {.f = +0.05} },
> { MODKEY|ControlMask, XK_Return, zoom, {0} },
> { MODKEY, XK_Tab, view, {0} },
> { MODKEY, XK_q, killclient, {0} },
> { MODKEY, XK_t, setlayout, {.v =
> &layouts[0]} },
> { MODKEY, XK_f, setlayout, {.v =
> &layouts[1]} },
> { 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 } },
> 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} },
> };
>
> /* button definitions */
> /* click can be a tag number (starting at 0),
> * ClkLtSymbol, ClkStatusText, ClkWinTitle, ClkClientWin, or ClkRootWin */
> static Button buttons[] = {
> /* click event mask button function
> argument */
> { ClkLtSymbol, 0, Button1, setlayout,
> {0} },
> { ClkLtSymbol, 0, Button3, setlayout,
> {.v = &layouts[2]} },
> { ClkWinTitle, 0, Button2, zoom,
> {0} },
> { ClkStatusText, 0, Button2, spawn,
> {.v = termcmda } },
> { 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} },
> };
>
> THANKS!!
> { "gkrellm", NULL, "gkrellm", (1 << 9) - 1, True },
> or you could just replace (1 << 9) - 1 with 511.
>
> On [Mon 04.08.2008 04:19], Leandro Chescotta wrote:
>> hi! i'm using dwm right now, and it's here to stay in my config, but
>> i'm a convert from fluxbox, and on it, i used to run gkrellm, it was
>> beautifull to have it showed in every desktop, so right now i think if
>> it's posible to have gkrellm in dwm, in the exact same behavior, so it
>> shows in every tag, and the opened apps, dont get over it, like the
>> slit in fluxbox...
>>
>> here's my config.h, i've added gkrellm to the floating apps list, but
>> don't know how to edit it so gkrellm show in every tag
>>
>> /* See LICENSE file for copyright and license details. */
>>
>> /* appearance */
>> /* static const char font[] =
>> "-*-terminus-medium-r-normal-*-18-*-*-*-*-*-*-*"; */
>> static const char font[] =
>> "-*-fixed-medium-r-*-*-18-*-*-*-*-*-iso8859-*";
>> static const char normbordercolor[] = "#111111";
>> static const char normbgcolor[] = "#000000";
>> static const char normfgcolor[] = "#ffffff";
>> static const char selbordercolor[] = "#777777";
>> static const char selbgcolor[] = "#222222";
>> static const char selfgcolor[] = "#ffffff";
>> static unsigned int borderpx = 1; /* border pixel of windows */
>> static unsigned int snap = 32; /* snap pixel */
>> static Bool showbar = True; /* False means no bar */
>> static Bool topbar = False; /* False means bottom bar */
>>
>> /* tagging */
>> static const char tags[][MAXTAGLEN] = { "1", "2", "3", "4", "5", "6",
>> "7", "8", "9" };
>>
>> static Rule rules[] = {
>> /* class instance title tags mask isfloating */
>> { "Gimp", NULL, NULL, 0, True },
>> { "Firefox", NULL, NULL, 1 << 8, True },
>> { "MPlayer", NULL, "MPlayer", 0, True },
>> { "feh", NULL, "feh", 0, True },
>> { "glxgears", "glxgears", "glxgears", 0, True },
>> { "vlc", NULL, "vlc", 0, True },
>> { "xine", NULL, "xine", 0, True },
>> { "gkrellm", NULL, "gkrellm", 0, True },
>> { "galculator", NULL, NULL, 0, True },
>> { "xcalc", NULL, NULL, 0, True },
>> { "winff", NULL, "winff", 0, True },
>> { "snes9x", NULL, "snes9x", 0, True },
>>
>> };
>>
>> /* layout(s) */
>> static float mfact = 0.55;
>> static Bool resizehints = True; /* False means respect size hints in
>> tiled resizals */
>>
>> static Layout layouts[] = {
>> /* symbol arrange function */
>> { "[]=", tile }, /* first entry is default */
>> { "><>", NULL }, /* no layout function means floating behavior */
>> { "[M]", monocle },
>> };
>>
>> /* 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 } }
>>
>> /* commands */
>> static const char *dmenucmd[] = { "dmenu_run", "-fn", font, "-nb",
>> normbgcolor, "-nf", normfgcolor, "-sb", selbgcolor, "-sf", selfgcolor,
>> NULL };
>> static const char *termcmda[] = { "urxvt", NULL };
>> static const char *termcmdb[] = { "urxvt", "-sh", "50", NULL };
>> static const char *amixcmdua[] = { "amixer", "-q", "set", "PCM", "20+", NULL };
>> static const char *amixcmdda[] = { "amixer", "-q", "set", "PCM", "20-", NULL };
>> static const char *amixcmdub[] = { "amixer", "-q", "set", "Front",
>> "10+", NULL };
>> static const char *amixcmddb[] = { "amixer", "-q", "set", "Front",
>> "10-", NULL };
>>
>> static Key keys[] = {
>> /* modifier key function argument */
>> { MODKEY, XK_p, spawn, {.v =
>> dmenucmd } },
>> { MODKEY, XK_Return, spawn, {.v
>> = termcmda } },
>> { MODKEY|ShiftMask, XK_Return, spawn, {.v
>> = termcmdb } },
>> { MODKEY, XK_z, spawn, {.v
>> = amixcmdda } },
>> { MODKEY, XK_x, spawn, {.v
>> = amixcmdua } },
>> { MODKEY|ShiftMask, XK_z, spawn, {.v
>> = amixcmddb } },
>> { MODKEY|ShiftMask, XK_x, spawn, {.v
>> = amixcmdub } },
>> { MODKEY, XK_b, togglebar, {0} },
>> { MODKEY, XK_j, focusstack, {.i = +1 } },
>> { MODKEY, XK_k, focusstack, {.i = -1 } },
>> { MODKEY, XK_h, setmfact, {.f = -0.05} },
>> { MODKEY, XK_l, setmfact, {.f = +0.05} },
>> { MODKEY|ControlMask, XK_Return, zoom, {0} },
>> { MODKEY, XK_Tab, view, {0} },
>> { MODKEY, XK_q, killclient, {0} },
>> { MODKEY, XK_t, setlayout, {.v =
>> &layouts[0]} },
>> { MODKEY, XK_f, setlayout, {.v =
>> &layouts[1]} },
>> { 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 } },
>> 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} },
>> };
>>
>> /* button definitions */
>> /* click can be a tag number (starting at 0),
>> * ClkLtSymbol, ClkStatusText, ClkWinTitle, ClkClientWin, or ClkRootWin */
>> static Button buttons[] = {
>> /* click event mask button function
>> argument */
>> { ClkLtSymbol, 0, Button1, setlayout,
>> {0} },
>> { ClkLtSymbol, 0, Button3, setlayout,
>> {.v = &layouts[2]} },
>> { ClkWinTitle, 0, Button2, zoom,
>> {0} },
>> { ClkStatusText, 0, Button2, spawn,
>> {.v = termcmda } },
>> { 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} },
>> };
>>
>> THANKS!!
>>
> You need to define a rule to make it floating and tag it with all tags.
>
> { "gkrellm", NULL, "gkrellm", ~0, True },
>
> Also you might patch dwm.c to leave some space on the right for the
> window, e.g. in updategeom:
>
> wh-=200;
>
> Kind regards,
> Anselm
>
> 2008/8/4 Leandro Chescotta <leandro.chescotta_AT_gmail.com>:
>> hi! i'm using dwm right now, and it's here to stay in my config, but
>> i'm a convert from fluxbox, and on it, i used to run gkrellm, it was
>> beautifull to have it showed in every desktop, so right now i think if
>> it's posible to have gkrellm in dwm, in the exact same behavior, so it
>> shows in every tag, and the opened apps, dont get over it, like the
>> slit in fluxbox...
>>
>> here's my config.h, i've added gkrellm to the floating apps list, but
>> don't know how to edit it so gkrellm show in every tag
>>
>> /* See LICENSE file for copyright and license details. */
>>
>> /* appearance */
>> /* static const char font[] =
>> "-*-terminus-medium-r-normal-*-18-*-*-*-*-*-*-*"; */
>> static const char font[] =
>> "-*-fixed-medium-r-*-*-18-*-*-*-*-*-iso8859-*";
>> static const char normbordercolor[] = "#111111";
>> static const char normbgcolor[] = "#000000";
>> static const char normfgcolor[] = "#ffffff";
>> static const char selbordercolor[] = "#777777";
>> static const char selbgcolor[] = "#222222";
>> static const char selfgcolor[] = "#ffffff";
>> static unsigned int borderpx = 1; /* border pixel of windows */
>> static unsigned int snap = 32; /* snap pixel */
>> static Bool showbar = True; /* False means no bar */
>> static Bool topbar = False; /* False means bottom bar */
>>
>> /* tagging */
>> static const char tags[][MAXTAGLEN] = { "1", "2", "3", "4", "5", "6",
>> "7", "8", "9" };
>>
>> static Rule rules[] = {
>> /* class instance title tags mask isfloating */
>> { "Gimp", NULL, NULL, 0, True },
>> { "Firefox", NULL, NULL, 1 << 8, True },
>> { "MPlayer", NULL, "MPlayer", 0, True },
>> { "feh", NULL, "feh", 0, True },
>> { "glxgears", "glxgears", "glxgears", 0, True },
>> { "vlc", NULL, "vlc", 0, True },
>> { "xine", NULL, "xine", 0, True },
>> { "gkrellm", NULL, "gkrellm", 0, True },
>> { "galculator", NULL, NULL, 0, True },
>> { "xcalc", NULL, NULL, 0, True },
>> { "winff", NULL, "winff", 0, True },
>> { "snes9x", NULL, "snes9x", 0, True },
>>
>> };
>>
>> /* layout(s) */
>> static float mfact = 0.55;
>> static Bool resizehints = True; /* False means respect size hints in
>> tiled resizals */
>>
>> static Layout layouts[] = {
>> /* symbol arrange function */
>> { "[]=", tile }, /* first entry is default */
>> { "><>", NULL }, /* no layout function means floating behavior */
>> { "[M]", monocle },
>> };
>>
>> /* 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 } }
>>
>> /* commands */
>> static const char *dmenucmd[] = { "dmenu_run", "-fn", font, "-nb",
>> normbgcolor, "-nf", normfgcolor, "-sb", selbgcolor, "-sf", selfgcolor,
>> NULL };
>> static const char *termcmda[] = { "urxvt", NULL };
>> static const char *termcmdb[] = { "urxvt", "-sh", "50", NULL };
>> static const char *amixcmdua[] = { "amixer", "-q", "set", "PCM", "20+", NULL };
>> static const char *amixcmdda[] = { "amixer", "-q", "set", "PCM", "20-", NULL };
>> static const char *amixcmdub[] = { "amixer", "-q", "set", "Front",
>> "10+", NULL };
>> static const char *amixcmddb[] = { "amixer", "-q", "set", "Front",
>> "10-", NULL };
>>
>> static Key keys[] = {
>> /* modifier key function argument */
>> { MODKEY, XK_p, spawn, {.v =
>> dmenucmd } },
>> { MODKEY, XK_Return, spawn, {.v
>> = termcmda } },
>> { MODKEY|ShiftMask, XK_Return, spawn, {.v
>> = termcmdb } },
>> { MODKEY, XK_z, spawn, {.v
>> = amixcmdda } },
>> { MODKEY, XK_x, spawn, {.v
>> = amixcmdua } },
>> { MODKEY|ShiftMask, XK_z, spawn, {.v
>> = amixcmddb } },
>> { MODKEY|ShiftMask, XK_x, spawn, {.v
>> = amixcmdub } },
>> { MODKEY, XK_b, togglebar, {0} },
>> { MODKEY, XK_j, focusstack, {.i = +1 } },
>> { MODKEY, XK_k, focusstack, {.i = -1 } },
>> { MODKEY, XK_h, setmfact, {.f = -0.05} },
>> { MODKEY, XK_l, setmfact, {.f = +0.05} },
>> { MODKEY|ControlMask, XK_Return, zoom, {0} },
>> { MODKEY, XK_Tab, view, {0} },
>> { MODKEY, XK_q, killclient, {0} },
>> { MODKEY, XK_t, setlayout, {.v =
>> &layouts[0]} },
>> { MODKEY, XK_f, setlayout, {.v =
>> &layouts[1]} },
>> { 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 } },
>> 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} },
>> };
>>
>> /* button definitions */
>> /* click can be a tag number (starting at 0),
>> * ClkLtSymbol, ClkStatusText, ClkWinTitle, ClkClientWin, or ClkRootWin */
>> static Button buttons[] = {
>> /* click event mask button function
>> argument */
>> { ClkLtSymbol, 0, Button1, setlayout,
>> {0} },
>> { ClkLtSymbol, 0, Button3, setlayout,
>> {.v = &layouts[2]} },
>> { ClkWinTitle, 0, Button2, zoom,
>> {0} },
>> { ClkStatusText, 0, Button2, spawn,
>> {.v = termcmda } },
>> { 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} },
>> };
>>
>> THANKS!!
> On 8/4/08, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
>> Also you might patch dwm.c to leave some space on the right for the
>> window, e.g. in updategeom:
>>
>> wh-=200;
>
> decreasing window area height would leave space at the _bottom_
> ww-=200;
> is probably what you meant ;)
> Hi,
>
> attached are two minor cleanups. The first simplifies grabkeys()
> similar to grabbuttons().
> The second removes isurgent() and isoccupied(). This also means that
> we need to loop over all clients only once in drawbar() now.
>
> Cheers,
> Johannes
>
> On 8/4/08, Johannes Hofmann <Johannes.Hofmann_AT_gmx.de> wrote:
>> attached are two minor cleanups. The first simplifies grabkeys()
>> similar to grabbuttons().
>> The second removes isurgent() and isoccupied(). This also means that
>> we need to loop over all clients only once in drawbar() now.
>
> looks nice
> thanks
> Thanks, applied.
>
> Kind regards,
> Anselm
>
> 2008/8/4 Johannes Hofmann <Johannes.Hofmann_AT_gmx.de>:
>> Hi,
>>
>> attached are two minor cleanups. The first simplifies grabkeys()
>> similar to grabbuttons().
>> The second removes isurgent() and isoccupied(). This also means that
>> we need to loop over all clients only once in drawbar() now.
>>
>> Cheers,
>> Johannes
>>
>
>
>
> --
> --Anselm
> Note, I'll be off until 15/08 -- if you want to annoy me, give me a ring ;)
>
> Kind regards,
> --Anselm
> Szabolcs,
>
> On 2008-08-04, Szabolcs Nagy wrote:
>> wide screen browser? i don't see the point.. may be with scaled up
>> fonts, otherwise reading lot of text in one line would be hard on the
>> eyes
>> ..or did you mean 1050x1680?
>>
>
> No, I said what I meant. Like you said, however, I use large fonts.
>
> Sincerely,
> --
> Antony Jepson / <antonyat_AT_gmail.com> / GPG Key: 0xFA10ED80
> ++ Veni, vidi, vici. (I came, I saw, I conquered.) ++
> ++ -- Gaius Iulius Caesar ++
>
> On Mon, Aug 4, 2008 at 1:09 PM, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
>> Note, I'll be off until 15/08 -- if you want to annoy me, give me a ring ;)
>>
>> Kind regards,
>> --Anselm
>>
>>
>
> Defcon?
> Hi,
>
> there seems to be some inconsistent utf-8 handling id dwm's and dmenu's
> text render code.
>
> Problems illustrated below:
>
> http://theka.tk/fuckup-0.png
> http://theka.tk/fuckup-1.png
>
> And as you can see on:
>
> http://theka.tk/fuckup-1.png
>
> text gets returned by dmenu correctly (which probably isn't much
> relevant, anyway).
>
> Best,
>
> --
> [a]
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkiZWQsACgkQL69KEesxVYPUngCfe/bA8CW+nlBiM9AcRdJAMiNJ
> uHIAoI8Lik96lt4ntD7Ddr5vdxjvIlk8
> =O8M9
> -----END PGP SIGNATURE-----
>
> Antoni Grzymala dixit (2008-08-06, 09:55):
>
>> http://theka.tk/fuckup-1.png
>
> http://theka.tk/fuckup-2.png <= correction.
>
> [a]
>
> --
> [a]
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkiZWhQACgkQL69KEesxVYNoZwCgxO1NXUPGMaoltPtvv2VrIpbM
> QngAoLceHD0zlqK+aSiRji/rLSCVFCPQ
> =JaDZ
> -----END PGP SIGNATURE-----
>
> Make sure the font you're using with dmenu supports UTF-8 and is
> properly configured to use it
>
> # Kurt H Maier
> Kurt H Maier dixit (2008-08-06, 08:58):
>
>> Make sure the font you're using with dmenu supports UTF-8 and is
>> properly configured to use it
>
> Obviously. Other characters wouldn't display correctly if the font
> weren't UTF-aware (and correctly configured).
>
> Have a look at this screenshot (xterm with the cited font, and the font
> used in dmenu):
>
> http://theka.tk/fuckup-3.png
>
> Best,
>
> --
> [a]
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkiZsBMACgkQL69KEesxVYP17ACdH02SrJaKo+awr9ziXqa75uQV
> KLYAnjMvHUTlR5ohVKv1QnIIi0Q/LPFs
> =vkM9
> -----END PGP SIGNATURE-----
>
> What's your locale setup?
>
> # Kurt H Maier
>
>
>
> On Wed, Aug 6, 2008 at 9:07 AM, Antoni Grzymala <antoni_AT_chopin.edu.pl> wrote:
>> Kurt H Maier dixit (2008-08-06, 08:58):
>>
>>> Make sure the font you're using with dmenu supports UTF-8 and is
>>> properly configured to use it
>>
>> Obviously. Other characters wouldn't display correctly if the font
>> weren't UTF-aware (and correctly configured).
>>
>> Have a look at this screenshot (xterm with the cited font, and the font
>> used in dmenu):
>>
>> http://theka.tk/fuckup-3.png
>>
>> Best,
>>
>> --
>> [a]
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.9 (GNU/Linux)
>>
>> iEYEARECAAYFAkiZsBMACgkQL69KEesxVYP17ACdH02SrJaKo+awr9ziXqa75uQV
>> KLYAnjMvHUTlR5ohVKv1QnIIi0Q/LPFs
>> =vkM9
>> -----END PGP SIGNATURE-----
>>
>>
> Kurt H Maier dixit (2008-08-06, 09:26):
>
>> What's your locale setup?
>
> $ locale
> LANG=
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=en_US.UTF-8
>
> $ locale -a
> C
> en_GB.utf8
> en_US.utf8
> pl_PL.utf8
> POSIX
>
> --
> [a]
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkiZuFcACgkQL69KEesxVYPi+wCfUsBbB9ZkD2rZCUZBMzNRpU0h
> hUsAoLrOhT9uWrt2brwwXhv6qNWuMBHP
> =78Y0
> -----END PGP SIGNATURE-----
>
> I had a similar problem by upgrading to dwm-4.9 from dwm-4.7.
> I solved it by restoring the old font from dwm-4.7. To me, it's a
> font stuff anyway. HTH.
>
> Regards,
> Claudio M. Alessi
>
>
> Claudio dixit (2008-08-06, 19:29):
>
>> I had a similar problem by upgrading to dwm-4.9 from dwm-4.7.
>> I solved it by restoring the old font from dwm-4.7. To me, it's a
>> font stuff anyway. HTH.
>
> Happens both with misc-fixed and terminus. And, as has been shown in the
> last screenshot, identically specified font works well for xterm and not
> for dmenu.
>
> --
> [a]
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkiZ5HUACgkQL69KEesxVYNjSACeNUX+x3gfh9gsF3ru+bY8hXnZ
> WmQAoJxOFaDJdeOSWYXyun7JT6rxvbLd
> =OvVg
> -----END PGP SIGNATURE-----
>
> I can confirm this behaviour:
>
> http://lists.suckless.org/dwm/0806/6145.html
>
> I need a better solution than using the ugly fixed font. :)
> I love dmenu, and just for the hell of it wanted a similar program, that
> didn't display anything. So I wrote grab (more like copied the code I
> needed from dmenu). It grabs all key presses until the user hits enter
> or escape, and then prints out whatever was typed. It's not foolproof,
> it's not very well tested, but it works for me. I run it from dwm the
> same way as dmenu. Have fun and do what you will with it.
>
> -Evan
>
> P.S. compile with gcc -lX11
>
> On Wed, Aug 06, 2008 at 09:55:55AM +0200, Antoni Grzymala wrote:
>> Hi,
>>
>> there seems to be some inconsistent utf-8 handling id dwm's and dmenu's
>> text render code.
>
> I'm still using dwm-4.7 and with the following two patches everything
> is alright for me (should be applicable to current dwm, too):
>
> http://www.cgarbs.de/cgi-bin/gitweb.cgi/dwm-mitch.git?a=blob;f=05_patch_dwm_mitch_utf8widechars.diff
> http://www.cgarbs.de/cgi-bin/gitweb.cgi/dwm-mitch.git?a=blob;f=02_patch_dmenu_mitch_utf8widechars.diff
>
> Both
>
> $ xtermset -title 日本語
> $ { echo 猫; echo 犬; echo 何; } | dmenu
>
> are handled and displayed correctly by dwm and dmenu.
>
> I use the font "-misc-fixed-medium-r-normal-*-13-*-*-*-*-*-*-*" in dwm and
> "-misc-fixed-medium-r-*-*-13-*-*-*-*-*-*-*" in dmenu (should really be the
> same, I should add the "normal" to dmenu for consistency).
>
>
> I have _not_ crosschecked this without my patches, so this could be some
> kind of Cargo Cult worship :-) On the other hand, UTF-8 issue like yours
> come up in this mailing list from time to time...
>
> Regards,
> Christian
> --
> ....Christian.Garbs.....................................http://www.cgarbs.de
>
> Suche nie nach Ursachen, schaffe Lösungen.
> (Herr Melzig zum Thema MS-Produkte)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFImgyj50xh8Od/N+4RAu3oAKCz8F7oNNG01F6d3YnI1OsExrih8gCgh2xu
> FUpGEiBhRv1Ne9c76tVwMGo=
> =gpr6
> -----END PGP SIGNATURE-----
>
> Hi, I was wondering if anyone could explain the rationale for introducing the option to set resizehints=False. I find that having a single option isn't quite what I want. I want either resizehints{x,y} or resizehints{in,out}.
>
> E.g. suppose the following tiled layout:
> +------+---+
> | | |
> | +---+
> | | |
> | +---+
> | | |
> +------+---+
> I have the inside border
> +
> |
> +---+
> |
> +---+
> |
> +
> set up to follow resize hints (this packs more text onscreen if my display's number of rows is not a multiple of 3). The outside border
> +------+---+
> | |
> | +
> | |
> | +
> | |
> +------+---+
> does not follow resize hints, because I have them set up to be rendered exactly 1px offscreen (I don't want to see them).
>
> Any reason why the current setup is all-or-nothing?
> Christian Garbs dixit (2008-08-06, 22:42):
>
>> I'm still using dwm-4.7 and with the following two patches everything
>> is alright for me (should be applicable to current dwm, too):
>>
>> http://www.cgarbs.de/cgi-bin/gitweb.cgi/dwm-mitch.git?a=blob;f=05_patch_dwm_mitch_utf8widechars.diff
>> http://www.cgarbs.de/cgi-bin/gitweb.cgi/dwm-mitch.git?a=blob;f=02_patch_dmenu_mitch_utf8widechars.diff
>>
>> Both
>>
>> $ xtermset -title 日本語
>> $ { echo 猫; echo 犬; echo 何; } | dmenu
>>
>> are handled and displayed correctly by dwm and dmenu.
>
> Makes me wonder why these patches didn't go mainline then... Perhaps
> it's hight time, what do you think?
>
> --
> [a]
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkiaF4QACgkQL69KEesxVYMkwgCfQPBMW2NvXwlsvJMjCzQVHu/b
> uHgAniPo9Z9okABcftfWO3g+mW5TpruQ
> =19Z9
> -----END PGP SIGNATURE-----
>
> https://bugs.freedesktop.org/attachment.cgi?id=14467 Doesn't help?
>
> --
> Regards,
>
>
> On Thu, Aug 7, 2008 at 1:28 AM, Antoni Grzymala <antoni_AT_chopin.edu.pl> wrote:
>>
>> Christian Garbs dixit (2008-08-06, 22:42):
>>
>> > I'm still using dwm-4.7 and with the following two patches everything
>> > is alright for me (should be applicable to current dwm, too):
>> >
>> > http://www.cgarbs.de/cgi-bin/gitweb.cgi/dwm-mitch.git?a=blob;f=05_patch_dwm_mitch_utf8widechars.diff
>> > http://www.cgarbs.de/cgi-bin/gitweb.cgi/dwm-mitch.git?a=blob;f=02_patch_dmenu_mitch_utf8widechars.diff
>> >
>> > Both
>> >
>> > $ xtermset -title 日本語
>> > $ { echo 猫; echo 犬; echo 何; } | dmenu
>> >
>> > are handled and displayed correctly by dwm and dmenu.
>>
>> Makes me wonder why these patches didn't go mainline then... Perhaps
>> it's hight time, what do you think?
>>
>> --
>> [a]
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.9 (GNU/Linux)
>>
>> iEYEARECAAYFAkiaF4QACgkQL69KEesxVYMkwgCfQPBMW2NvXwlsvJMjCzQVHu/b
>> uHgAniPo9Z9okABcftfWO3g+mW5TpruQ
>> =19Z9
>> -----END PGP SIGNATURE-----
>>
>
>
>
Received on Thu Aug 07 2008 - 08:35:12 UTC
This archive was generated by hypermail 2.2.0 : Thu Aug 07 2008 - 08:36:03 UTC
