Re: [dwm] nanox

2009-05-20 Thread Anselm R Garbe
Hi pancake,

2009/5/19 pancake panc...@youterm.com:
 I have been looking a bit for an alternative for X11, and I found nano-X
 quite interesting,
 but it is currently an abandoned project. 8000 LOCs, there's an abstraction
 library to wrap
 libX11 and there's support for some many IO devices (tty, gpm, ..) It runs
 directly writing
 on fb0, but it shouldnt be hard to make it run as Xnest (for testing
 purposes) or draw a
 xorg-driver layer to directly run with native graphics drivers.

 The source looks quite clean and I think we can use it as base for the
 minimal X replacement.

 ARG, what do you think about this? :)

I'm looking at it and must confess it could be some starting point.

 There's little movement in the mailing list nowadays, but the last release
 is from 1999. So I
 can think that the project is dead.

 Here's the last release of nanox (0.4)
  http://www.tucows.com/download.html?software_id=9833t=2

 Actually the project has grown and it was renamed to microwindows which
 has become a much bigger project: ( iwas unable to compile it because of the
 outdated dependency against freetype (v1) )

  ftp://microwindows.censoft.com/pub/microwindows/microwindows-full-0.91.tar.gz
 (10MB)

 this tarball contains nanox (but depends on freetype and such) and now is
 16KLOC

 Official website:
  http://www.microwindows.org/

Thanks and kind regards,
Anselm



Re: [dwm] nanox

2009-05-20 Thread Anselm R Garbe
2009/5/20 Jacob Todd jaketodd...@gmail.com:
 On Tue, May 19, 2009 at 04:08:07PM +0200, pancake wrote:
 

 Seems interesting, but instead of reinventing the wheel, why don't we just 
 clean
 up X.org and submit patches back upstream? Rewriting/implementing X.org seems 
 li
 ke more work than it's worth, but cleaning up Xorg would be better for 
 everyone.

Unfortunately that's not my intention. I have a completely new WS in
mind, design-wise with no X dependency, just an X legacy support layer
instead. The crucial part of X imho is the hardware support, that's
why I want to stick to xorg-drivers*, just because that's the bit
which can't be done properly without driver experts. X.org can't be
fixed because it consists of all the X10 and X11 legacy we don't want
to carry on in a new WS, we want a different WS, not a state-machine
WS like X. And X.org won't be willing to accept patches which change
its internal behavior radically.

Kind regards,
Anselm



Re: [dwm] Re: New mailing list

2009-05-20 Thread Anselm R Garbe
I think that's a sensible proposal, let's do it.

For those who are subscribed already, there won't be a difference. The
new ones will subscribe to hackers. We will keep dwm@ and wmii@
working, but direct it to hack...@.

Kind regards,
Anselm

2009/5/20 markus schnalke mei...@marmaro.de:
 [2009-05-20 08:35] Uriel urie...@gmail.com

 I suggested a while ago to merge wmii@ and dwm@ into hackers@, both
 lists are rather low level, and there is much overlap, and such a
 single list would be more fitting for new minor side projects and for
 'offtopic' discussion.

 +1


 Right now when one has something to say that doesn't quite fit in
 wmii@ or dwm@, or that could fit in both, you have to pick one list at
 random, or to cross post, and both options suck.

   What do you think about creating an offtopic mailing list in suckless for
   discussing such
   kind of topics, instead of using the dwm@ one like nowadays happen.
 
  I think it's been the charme of dwm@ to discuss lot's of other things,

 Yes. Merge, don't split.


 meillo

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.6 (GNU/Linux)

 iD8DBQFKE6ly6aFpZ+X9qBIRArW7AJ4sXPrq+pagoWmS2AKT032PSmqOTQCfXsgx
 b3yhcxM+v9dwI/Mo9IklZHU=
 =OWPz
 -END PGP SIGNATURE-





Re: [dwm] Re: New mailing list

2009-05-20 Thread Anselm R Garbe
Ok, I meant the following:

Let's have hackers@ be some meta list which sends to dwm@ and wmii@,
and those subscribed to hackers will receive dwm@ and w...@. Those who
are only interested in dwm@ or wmii@ specifically could just stay on
dwm@ resp. w...@. That should be technically possible.

Kind regards,
Anselm

2009/5/20 Anselm R Garbe garb...@gmail.com:
 I think that's a sensible proposal, let's do it.

 For those who are subscribed already, there won't be a difference. The
 new ones will subscribe to hackers. We will keep dwm@ and wmii@
 working, but direct it to hack...@.

 Kind regards,
 Anselm

 2009/5/20 markus schnalke mei...@marmaro.de:
 [2009-05-20 08:35] Uriel urie...@gmail.com

 I suggested a while ago to merge wmii@ and dwm@ into hackers@, both
 lists are rather low level, and there is much overlap, and such a
 single list would be more fitting for new minor side projects and for
 'offtopic' discussion.

 +1


 Right now when one has something to say that doesn't quite fit in
 wmii@ or dwm@, or that could fit in both, you have to pick one list at
 random, or to cross post, and both options suck.

   What do you think about creating an offtopic mailing list in suckless 
   for
   discussing such
   kind of topics, instead of using the dwm@ one like nowadays happen.
 
  I think it's been the charme of dwm@ to discuss lot's of other things,

 Yes. Merge, don't split.


 meillo

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.6 (GNU/Linux)

 iD8DBQFKE6ly6aFpZ+X9qBIRArW7AJ4sXPrq+pagoWmS2AKT032PSmqOTQCfXsgx
 b3yhcxM+v9dwI/Mo9IklZHU=
 =OWPz
 -END PGP SIGNATURE-






Re: [dwm] Re: New mailing list

2009-05-20 Thread Anselm R Garbe
Hi,

2009/5/20 Szabolcs Nagy nszabo...@gmail.com:
 On 5/20/09, Anselm R Garbe garb...@gmail.com wrote:
 Let's have hackers@ be some meta list which sends to dwm@ and wmii@,
 and those subscribed to hackers will receive dwm@ and w...@. Those who
 are only interested in dwm@ or wmii@ specifically could just stay on
 dwm@ resp. w...@. That should be technically possible.

 dwm, wmii - hackers
 hackers - dwm, wmii

 so one sends a mail to dwm@ then it goes to hackers@ then someone
 replies there and the reply goes to w...@?

 imho if we merge then don't keep separate dwm and wmii lists

 if there are too many commits then commit messages may be separated
 from discussions

Well, let's have one list then as you propose and see how we get on. I
like to see the commits side by side. Because so far there were nearly
0 discussions regarding commits, but we had plenty on dwm@ about
patches.

Still, the traffic won't go up like hell.

Kind regards,
Anselm



Re: [dwm] Re: New mailing list

2009-05-20 Thread Anselm R Garbe
2009/5/20 Premysl Hruby dfe...@gmail.com:
 On (20/05/09 10:04), Anselm R Garbe wrote:
 To: dwm mail list dwm@suckless.org, wmii mail list w...@suckless.org
 From: Anselm R Garbe garb...@gmail.com
 Subject: Re: [dwm] Re: New mailing list
 Reply-To: dwm mail list dwm@suckless.org
 List-Id: dwm mail list dwm.suckless.org

 Ok, I meant the following:

 Let's have hackers@ be some meta list which sends to dwm@ and wmii@,
 and those subscribed to hackers will receive dwm@ and w...@. Those who
 are only interested in dwm@ or wmii@ specifically could just stay on
 dwm@ resp. w...@. That should be technically possible.

 Kind regards,
 Anselm


 Don't forget that hackers@ receive commit emails, imho leave it as is or
 join all into one ml. Idea for having one ml as sort of syndication ml
 imho sux :), if someone wants to receive/send both ml, he/she can
 subscribe/cc them.

If commit messages become a problem, we can move them to hglog@

Kind regards,
Anselm



Re: [dwm] Re: New mailing list

2009-05-20 Thread Anselm R Garbe
2009/5/20 yy yiyu@gmail.com:
 2009/5/20 Szabolcs Nagy nszabo...@gmail.com:
 On 5/20/09, Anselm R Garbe garb...@gmail.com wrote:
 Let's have hackers@ be some meta list which sends to dwm@ and wmii@,
 and those subscribed to hackers will receive dwm@ and w...@. Those who
 are only interested in dwm@ or wmii@ specifically could just stay on
 dwm@ resp. w...@. That should be technically possible.

 dwm, wmii - hackers
 hackers - dwm, wmii

 so one sends a mail to dwm@ then it goes to hackers@ then someone
 replies there and the reply goes to w...@?


 Maybe I'm being naive, mailing lists are not my strong point. But IMO
 you can send the messages to the people subscribed to hackers with the
 corresponding FROM: field (dwm or wmii). So, if one sends a mail to
 dwm, you recive it as coming from dwm. Since hackers subscribed recive
 mail from both lists, the reply will arrive to dwm and hackers
 subscribers. Only if you specifically send an email to hackers it will
 be received by both lists (and you could, for example, change the TO:
 field when the discussion goes off-topic). Maybe somebody knows if I'm
 right or absolutely wrong.

That's possible, though in reality people will reply to dwm@ or wmii@
and the others won't see it, which is why having one list to keep
track of the discussions is better, where dwm@ and wmii@ are aliases
for the same. In the beginning I'd even go that far to have the commit
logs on that list as well.

Kind regards,
Anselm



Re: [dwm] Re: New mailing list

2009-05-20 Thread Anselm R Garbe
2009/5/20 Uriel urie...@gmail.com:
 The problem is not dwm@ and wmii@, the problem is all the other stuff
 that is unrelated to either, the only two logical and consistent
 options are to either we further split the community into st@ dws@ and
 so on, or we merge everything, and I think that option is a
 no-brainer.

I agree with that, though I think we should introduce a new list.

Here is what we will do:

We'll keep hackers@ as is -- just commit logs.

We will introduce d...@suckless.org which merges dwm@ and wmii@ into
one list, and dwm@ and wmii@ will be aliases for that.

On IRC we already formed

#suckless @ oftc.net

Kind regards,
Anselm



Re: [dwm] Irc channel moved

2009-05-20 Thread Anselm R Garbe
2009/5/20 Dusan ef_...@yahoo.com:
 #suckless is probably the best. #hackers will attract wrong kids and
 does not describe anything.

The agreed channel name is #suckless. Period.

Kind regards,
Anselm



Re: [dwm] musca wm

2009-05-15 Thread Anselm R Garbe
2009/5/15 pancake panc...@youterm.com:
 another tiling manager with interesting features:

 http://aerosuidae.net/musca.html

Looks to me it's aiming the original WMI without tabbing a little bit.
I definately prefer the dwm way after all ;)

Kind regards,
Anselm



Re: [dwm] musca wm

2009-05-15 Thread Anselm R Garbe
2009/5/15 pancake panc...@youterm.com:
 What I find interesting is the support for multi-screen. Actually I'm using
 wmii at work,
 because dwm cannot properly handle multiscreen layouts and this made me use
 the
 mouse too much.

 Wmii has some bugs, but at least is IMHO better for multiscreen layouts. I
 think this is
 the eternal discussion, because it is hard to find the 'best' approach to
 this problem
 for dwm.

 But for single-screen environments dwm still rocks :)

 I really miss the conceptual experimentation that dwm was in the past. But I
 agree that
 we should probably focus on other topics like 'st' or a full OS based on
 minimalist software
 (based on Linux without GNU craps) ...

I'll provide a new multiscreen support this weekend in dwm. It's based
on assigning specific tags to specific screens.

 What do you think about creating an offtopic mailing list in suckless for
 discussing such
 kind of topics, instead of using the dwm@ one like nowadays happen.

I think it's been the charme of dwm@ to discuss lot's of other things,
so I'd rather keep it as it is for now ;)

Kind regards,
Anselm



Re: [dwm] dwm status bar..

2009-04-30 Thread Anselm R Garbe
2009/4/30 Wu, Yue vano...@gmail.com:
 On Wed, Apr 29, 2009 at 10:08:09PM -0700, Scytrin dai Kinthra wrote:
 use `xsetroot -name status` as dwm's status bar contents are now
 derived from the name attribute of the root window.
 It's a good thing, as you no longer need to play the pipe game.

 It's a pain that I have to install an extra software to achieve this simple
 thing. :(

There is wmname as well which can be used.

Kind regards,
--Anselm



Re: [dwm] dwm's future

2009-04-28 Thread Anselm R Garbe
Ok, thanks again for continuing the discussion.

My conclusion is as follows:

1) dwm will be slightly redesigned, code-wise. I consider having a
less suckish font and drawing abstraction in order to be implemented
in different ways (which will also be used by st and dmenu).
Officially there will only be X font support as is. But due to this
abstraction it'll be possible to implement cairo/pango backends if
that seems more suitable for non western glyphs without the need to
change any vanilla dwm code.

2) Similiarly I will separate the bar bits into a separate file to
make it easy to get rid of the bar if someone prefers going with
dzen+xdotool.

3) Regarding the broken apps I need to investigate further. If it's
really related to reparenting, it's definately a bug in these apps or
in the toolkit (JDK?) they rely on. If that's the case I WON'T
introduce kludges to handle them, instead we should file bug reports
that these apps get fixed.

Particularly if these apps are of commercial nature, it should be the
vendor's interest to fix their apps that you as a customer can use
them in your preferred environment. You or your organization pays
someone license fees I guess so that's just a totally valid request
that the vendor fixes these apps.

4) Regarding multihead I will start a separate thread soon what a
viable solution might be.

Kind regards,
Anselm



Re: [dwm] dwm's future

2009-04-28 Thread Anselm R Garbe
2009/4/28 pmarin pacog...@gmail.com:
 Try to make the new dependencies optionals.

 About the broken non-free apps, is not dwm's problem and one solution
 can be to use a qemu instance with another WM and connect to the host
 Xwindows server.

That won't be a really good solution, the better solution is Xnest.

And don't worry about the dependencies, there won't be any more than
what we currently got.

Kind regards,
Anselm



Re: [dwm] dwm's future

2009-04-27 Thread Anselm R Garbe
Thanks for all the valueable input so far in this thread.

I think here are the action points:

1) I plan to separate the bar stuff code-wise into two portions -- the
tag bar with tags and layout info, and the title/status bar, but
things will stay as they are from a user perspective, it's just some
code cleanup which allows replacing the tagbar and/or title/status bar
with something else (or avoiding to compile it in)

There might be possible pango/cairo implementations of this stuff, I
plan to have a font API interface, something like libsfont which is
used by dwm and dmenu to start with, and which depends on either Xlib
or some more fancy sucking stuff optionally.

2) I need to investigate into the reparent stuff first, I really
dislike going the reparent route, because each parent window consumes
much more X resource memory (basically twice the buffer sizes as we
have already if you use a reparenting WM -- this makes everything
slower). I really think bug the authors of the broken apps to fix
their apps that they do not assume a reparenting WM.

So the action here is: let's make a list of all apps which are known
to be broken and behaving strange with dwm first, that I can
investigate.

- Mathematica (Version?)
- ... please provide input

3) I agree multihead has got some preference, I like the approach to
assign certain tags to specific screens.

Kind regards,
Anselm



Re: [dwm] dwm's future

2009-04-27 Thread Anselm R Garbe
2009/4/27 Preben Randhol rand...@pvv.org:
 On Sun, 26 Apr 2009 11:11:03 +0100
 Anselm R Garbe garb...@gmail.com wrote:

 So there are only three ways:

 - stick with what we got (don't care if some langs look ugly)
 - use pango and/or cairo or something like that
 - invest some effort into a new font rendering lib (seems to be a hard
 job, esp. if one asks for proper font support which can't be done by
 us)

 What about xft? Wasn't there a patch for 4.7 (can't find it anymore).
 I don't know much about the font systems.

One option, though quite half hearted in my opinion.

Kind regards,
--Anselm



Re: [dwm] dwm's future

2009-04-26 Thread Anselm R Garbe
Hi,

2009/4/26 Szabolcs Nagy nszabo...@gmail.com:
 On 4/26/09, Christian Garbs mi...@cgarbs.de wrote:
 On Sat, Apr 25, 2009 at 11:06:08PM +0100, Szabolcs Nagy wrote:
 On 4/25/09, Christian Garbs mi...@cgarbs.de wrote:
  work, even without pango or cairo.  I have German umlauts as well as
  Japanese characters (eg. web page titles from Firefox).

 try greek or cyrillic
 i had trouble with those when fonts were loaded with XCreateFontSet

 Looks ok to me:
 https://www.cgarbs.de/tmp/dwm-ru.png

 no, that is ugly bold font, same problem with greek

 Wrong font here?
 https://www.cgarbs.de/tmp/dwm-ar.png

 most likely your font does not cover arabic fonts (iso8859-6) in the given 
 size

 Korean does look broken, though:
 https://www.cgarbs.de/tmp/dwm-ko.png

 yes, i get the same result using fixed-14

With the font spec:

-*-*-medium-*-*-*-14-*-*-*-*-*-*-*

I'm able to get proper results including Japanese, Chinese, Korean,
Greek, Russian, Hebrew, and Thai with that. Though not all of them are
monospaced (Gree and Russian for instance).

Arabic doesn't work for me if I'm not increasing the size to 17 or
above which is huge... and that's hard to be monospaced anyways.

I had a look into pango, well and I agree having such a dependency is
not very nice, pango is quite complex for what we need, cairo is bad
either for what we require. These achieve pseudo-monospace'ing through
scaling, which ends up in more or less equally bad results as using
plain X fonts, though perhaps looking a little bit smoother because
one doesn't need to declare large fonts.

So there are only three ways:

- stick with what we got (don't care if some langs look ugly)
- use pango and/or cairo or something like that
- invest some effort into a new font rendering lib (seems to be a hard
job, esp. if one asks for proper font support which can't be done by
us)

So I think, we stick to what we got after all. The bar stays at it is.

I agree there are more interesting problems.

Kind regards,
--Anselm



Re: [dwm] dwm's future

2009-04-26 Thread Anselm R Garbe
2009/4/26 Szabolcs Nagy nszabo...@gmail.com:
 On 4/25/09, Anselm R Garbe garb...@gmail.com wrote:
 1. One idea is getting rid of the dwm bar altogether and to print the
 dwm state to stdout when it changes, however after thinking carefully
 about it I conclude that having the bar build-in is definately a
 stayer. It's so much simpler than the hassle with an external bar, not
 worth it. So very unlikely.

 if external bar is a hassle then inter-process communication is broken
 in our systems

 if built-in bar is a hassle then x is broken (unable to display text)

Well, an external bar is a hassle because it would increase the
overall complexity if it's assumed to be implemented properly (or in a
fashion like what we got). One has to specify handling where the bar
appears, which size, and all kinds of interface handling between the
bar and dwm.

 2. Another idea is to switch to another dependency for the rendering
 bit which could possibly be cairo. After all I'm nearly giving up the
 hope that X font handling will ever be fixed and work properly,

 $ du -h /usr/lib/libcairo.a
 608K    /usr/lib/libcairo.a

 pango seems to be slightly smaller, but i don't know what these libs
 do exactly..

They do fairly more than what we need for a single bar. So let's stick
to what we got.

 imo it's not suckless, but it can be a temporary solution until x is fixed

Knowing who drives the X development I gave up any hope that X will
ever be fixed, more the contrary.

I think the only solution is dws, which needs more assistance and
which can be based on legacy crap. Important is that dws provides
decent interfaces and possibly a legacy X interface on top of it. I
think that's the long term plan we should achieve. But it'll take a
long time with the resources we got atm (I hoped GSoC would sponsor us
somehow to get started into that direction).

 3. A third idea for legacy support is, that I tend to add a
 compile-time option or a specific Rule extension that let's you set to
 reparent all clients or certain clients which are broken

 rule extension won't work as these applications tend not to set
 class,instance,name properly

Yea that's a pity and that makes the rules more questionable, perhaps
I should make them simpler or changing the mechanism eg having a
catch next map function instead which applies a certain rule to the
next window which is mapped.

Kind regards,
--Anselm



[dwm] dwm's future

2009-04-25 Thread Anselm R Garbe
Hi there,

I discussed several stuff on IRC recently but wanted to share my thoughts here.

1. One idea is getting rid of the dwm bar altogether and to print the
dwm state to stdout when it changes, however after thinking carefully
about it I conclude that having the bar build-in is definately a
stayer. It's so much simpler than the hassle with an external bar, not
worth it. So very unlikely.

2. Another idea is to switch to another dependency for the rendering
bit which could possibly be cairo. After all I'm nearly giving up the
hope that X font handling will ever be fixed and work properly, so
that relying on a pile of other crap seems to become a solution. cairo
is a dependency for firefox and I guess that every dwm user uses
firefox occasionally. And we might benefit from a little bit smoother
looking dwm (same for dmenu of course and my ongoing st efforts). I
think this idea is quite likely.

3. A third idea for legacy support is, that I tend to add a
compile-time option or a specific Rule extension that let's you set to
reparent all clients or certain clients which are broken such as
Mathematica or various Swing apps, though I'm not absolutely sure how
likely that is. Somehow my inner feelings are against it, because it's
not a dwm problem and those broken apps should be fixed.

Please feel free to comment or add other ideas to this list.

Kind regards,
--Anselm



Re: [dwm] dwm's future

2009-04-25 Thread Anselm R Garbe
2009/4/25 yy yiyu@gmail.com:
 There is a middle way solution. I just thought about it, and will
 probably have its drawbacks, but here it goes: keep a bar with only
 the tags and tile symbol and print the sel client title to stdout.
 This way you can use an external program (dzen) to render the title
 (and status text, of course). I don't think nobody needs unicode
 glyphs in their tag names or tile symbols, you wouldn't need cairo in
 dwm (but could add it to dzen) and would remove a lot of loc getting
 ride of status text and window title.
 About the reparent call, I don't think is a good idea. There are lots
 of dwm similar wms around, and it is very easy changing between them.
 I would keep dwm as pure as possible and would let the others to
 handle the dirty stuff, but of course I'm not the one who needs to use
 those broken apps...

Well I like and hate that idea. Those who do not like relying on some
other apps won't see the title anymore (just ignoring the status
text). On the other hand, purists might not be interested in the title
and status text anyways.

So definately worth considering!

Kind regards,
--Anselm



Re: [dwm] [RFC] dwm-win32

2009-04-21 Thread Anselm R Garbe
Hi Marc,

just digged through my spam filter and spotted that thread here
(including your older mail a month ago):

2009/4/20 Marc Andre Tanner m...@brain-dump.org:
 So a month passed since my last posting and there was absolutely
 no feedback so I assume the reasons are:

  (a) you guys are in the comfortable situation of not having to
     touch windows boxes

  (b) alpha1 was unusable and you didn't even bother to write a comment

 Anyway I have since fixed a few bugs and probably also introduced some
 new ones. But since I most likely wont have time to look into this in
 the near future I post my current codebase just in case someone is
 interested in it.

  http://www.brain-dump.org/projects/dwm-win32/dwm-win32-alpha2.zip
  http://www.brain-dump.org/projects/dwm-win32/dwm-win32-alpha2.tar.gz
  http://www.brain-dump.org/projects/dwm-win32/dwm-win32-alpha2.exe

Thanks, that's very interesting I will look into it.

Lemme get back to you soon.

Kind regards,
--Anselm



Re: [dwm] Replacing slock screen overlay with screenshot / bitmap

2009-04-18 Thread Anselm R Garbe
2009/4/18 Jan Blazek appoli...@gmail.com
 Scytrin dai Kinthra wrote:
 I use a combination of xss and xkeygrab to lock my screen but allow
 the UI to update in the background so I can see incoming emails and
 chats.

 This is something I always wanted but didn't have enough time/will to dig 
 into it. Would you mind sharing your solution?

What about not creating the black window at all?

Kind regards,
--Anselm



[dwm] dwm-5.5 / dmenu-4.0

2009-04-18 Thread Anselm R Garbe
Hi there,

I'm glad to announce some new releases:

  http://code.suckless.org/dl/dwm/dwm-5.5.tar.gz
  http://code.suckless.org/dl/tools/dmenu-4.0.tar.gz

The new dwm release contains various bugfixes and code cleanups
appeared during the last months and it has also been simplified:
- the noborder feature of single tiled clients in the view has been
removed for simplicity reasons
- the usegrab option in config.h has been removed

The new dmenu release also contains various bugfixes appeared during
the last months.

Let me know any issues.

Kind regards,
--Anselm



Re: [dwm] Raise window when requested?

2009-04-15 Thread Anselm R Garbe
Hi,

2009/4/14 Haomin Wen wen1...@gmail.com:
 I often write some latex files in vim, and use xdvi to see the result. My
 screen is small, so I work in monocle layout.

 The man page of xdvi said that the existing xdvi will raise its window when
 another xdvi is evoked with -sourceposition option, but it seems that dwm
 can not handle this.

 Can somebody fix this?

I will have a look into it. It'll be required that these windows are
set to floating, otherwise dwm will always override to behind
floating windows if these windows are managed/tiled by default. Afaik
configurenotify does not handle raise requests right now.

Note, this fix won't be in officially before dwm-5.6, because hg tip
is what I'm going to release as dwm-5.5.

Kind regards,
--Anselm



Re: [dwm] [dmenu] OPTFLAGS in config.mk + patch

2009-04-09 Thread Anselm R Garbe
Hi,

Honestly, I think introducing OPTFLAGS is kind of arbitrary, even if
it's done in existing software (well existing software uses autohell
quite a lot). In my opinion CFLAGS is the right variable to include
compiler flags, and -Ox is one of them.

Kind regards,
Anselm

2009/4/8 Jan Blazek appoli...@gmail.com:
 I would like to make package of dmenu for Fedora and in the review process
 someone (Till Maas) suggested it would be better to have ability to pass gcc
 optimization flags to make on the command line. [1]

 Best regards,
 Jan Blazek

 PS: Patch attached.

 [1] https://bugzilla.redhat.com/show_bug.cgi?id=485638#c3

 --- dmenu-3.9/config.mk.optflags        2008-09-09 15:45:00.0 -0400
 +++ dmenu-3.9/config.mk 2009-04-02 15:26:41.0 -0400
 @@ -20,7 +20,8 @@ LIBS = -L/usr/lib -lc -L${X11LIB} -lX11

  # flags
  CPPFLAGS = -DVERSION=\${VERSION}\ ${XINERAMAFLAGS}
 -CFLAGS = -std=c99 -pedantic -Wall -Os ${INCS} ${CPPFLAGS}
 +OPTFLAGS = -Os
 +CFLAGS = -std=c99 -pedantic -Wall ${OPTFLAGS} ${INCS} ${CPPFLAGS}
  LDFLAGS = -s ${LIBS}

  # Solaris



Re: [dwm] Push patch

2009-04-01 Thread Anselm R Garbe
http://dwm.suckless.org/patches/push-5.3.c

Sorry, the page is not formatted correctly.

2009/4/1 Nikke niklas.ih...@gmail.com:
 I can't seem to find the download link for the push patch?
 There is no link at the push patch site, can someone give me a working
 url please? :)

 /Nikke



Re: [dwm] Fake key in xterm

2009-03-31 Thread Anselm R Garbe
2009/3/31 Tinou tinou...@gmail.com:
 In vim, to jump to a tag (tjump) ctrl-] is used. I'm french and using a
 french azerty keyboard. On windows or osx, ctrl-] can be acheived by
 pressing ctrl-$ but not in xorg, since ^$ doesn't seem to exist.

 ctrl-$ is simpler because to produce a ']' I need to use one more
 modifier: altgr.

 So, to reproduce the windows/osx behaviour, I though I could grab the
 key ctrl-$ in dwm and then send to the selected window the key
 combination ctrl-altgr-].

 The attach code does this and it works perfectly in gvim or
 rxvt-unicode.

 But not in xterm (nor uxterm).

 My question is: how can I make this work in xterm ?

The reason is that you are using XSendEvent and that xterm has got a
protection against synthetic key events by default (otherwise a
malicious app could send rm -rf /\n to a xterm window).

To allow synthetic key events, set something like:

XTerm*allowSendEvents: True

Kind regards,
Anselm



[dwm] GSoC 2009, suckless.org has been rejected

2009-03-19 Thread Anselm R Garbe
Hi there,

I'm sorry to announce that we didn't make it this time.

I want to thank all people involved in the preparations for their efforts.

Hopefully, I will have a private chat tomorrow with Leslie to hear
about the reasons and what we can do better the next time.

The GSoC page is moved to

http://suckless.org/common/project_ideas

I will add an auto-redirection later today (currently it's an href)...

Kind regards,
--Anselm



Re: [dwm] autoconf

2009-03-19 Thread Anselm R Garbe
2009/3/19 bill lam cbill@gmail.com:
 -             die(dwm-VERSION, © 2006-2009 dwm engineers, see LICENSE for 
 details\n);

 Not related to autoconfm but I notice the copyright sign is in utf-8.
 If dwm is compiled in other locale, will it display properly when
 run on that locale?

No, but we expect all users are using UTF-8 nowadays -- and if not,
they won't care either about that detail I suppose (like those OpenBSD
users ;)).

Kind regards,
--Anselm



Re: [dwm] splash screen

2009-03-17 Thread Anselm R. Garbe
On Tue, Mar 17, 2009 at 12:05:15AM +0800, bill lam wrote:
 On Mon, 16 Mar 2009, mi...@milesgroman.com wrote:
  Can you reply with your rule for gnumeric?  I occasionally use
  gnumeric, though I do not recall a splash, it does tile as expected.
 
 static Rule rules[] = {
   /* class  instancetitle   tags mask isfloating */
   { UXTerm,NULL,   NULL,   0,False },
   { XTerm,NULL,   NULL,   0,False },
   { Iceweasel,  NULL,   NULL,   1  8,   True },
   { Firefox,  NULL,   NULL,   1  8,   True },
 };
 
 No special treatment for gnumeric. It tiles correctly if starts with
 no worksheet or with a small worksheet because gnumeric will only
 shows a splash screen when it needs a longer time to load, about 5 to
 10 seconds. I do not know the exact timing but that should be the 
 intended behavior of gnumeric

I suppose it sets a TRANSIENT_FOR hint on the main window to the
splash because of some brokeness in gnumeric.

Kind regards,
Anselm



Re: [dwm] what is mwm hint?

2009-03-16 Thread Anselm R Garbe
2009/3/16 bill lam cbill@gmail.com:
 When I try turn on full screen in feh (an image viewer). It said

 feh WARNING: Window Manager does not support MWM hints.
 To get a borderless window I have to bypass your wm.

 What is mwm hint? Is that important?

 dwm-5.5

Hmm, if so that's a bug, because dwm used to support MWM since the
beginning. Will check.

MWM stands for Motif WM hints.

Kind regards,
--Anselm



Re: [dwm] Gaps

2009-03-13 Thread Anselm R Garbe
2009/3/13 anonymous anonym...@id.ru:
 Is it possible to add, for example, left side gap?

Yes, have a look at tile() and change it in order to use w- instead of
0 as offset.

Kind regards,
--Anselm



Re: [dwm] Wiki date format

2009-03-13 Thread Anselm R Garbe
I think the whole issue is resolved now, because the news index is
using /MM/DD now.

Kind regards,
Anselm

2009/3/13 Uriel urie...@gmail.com:
 The '-' is a tr(1) call away, but I don't see the point, and using '/'
 emphasizes the fs structure and that the urls are 'hackable' (as the
 latest buzzword goes).

 uriel

 On Wed, Mar 11, 2009 at 6:34 PM,  sta...@cs.tu-berlin.de wrote:
 * markus schnalke mei...@marmaro.de [2009-03-11 16:42]:
 [2009-03-11 16:10] yy yiyu@gmail.com
  OTOH, a
  /mm/dd structure is convenient to organize months and years in a
  tree structure, i.e. directories

 If /mm/dd depicts a path, I agree. Anyway, in this case it's the
 only way, as slash separates files in a path.

 One can use the standard for representation, i.e. show 2042-03-11 _and_
 store files in 2042/03/11 ( ... as was the intention when time was invented
 :o) ).
 What's the problem?

 Well, this will effectively result in URLs like
 http://foo.bar.bg/posts/2042/03/11/date-format-is-confusing.html which may
 be a bit confusing for some people, but the context (hierarchical
 structure) should prompt what date it is supposed to be. (if one is aware
 of what the intention was when time was invented)
 :o)

 --
  cheers
  stanio_



Re: [dwm] suckless.org stylesheet glitch

2009-03-13 Thread Anselm R Garbe
2009/3/13 Uriel urie...@gmail.com:
 I run http://cat-v.org on xen, and even really long pages like
 http://ninetimes.cat-v.org take a couple of seconds to load.

 Something was wrong with suckless.org, sometimes a small page could
 take ten seconds, it is better now but still on the slow side of
 things.

I guess you use ipv6?

Kind regards,
--Anselm



Re: [dwm] suckless.org stylesheet glitch

2009-03-11 Thread Anselm R Garbe
2009/3/11 pmarin pacog...@gmail.com:
 Why have you change to werc?

The main reason is I'm not very keen on maintaining a web framework
and Uriel spend his last year on this and I think his werc is very
good.

Kind regards,
--Anselm



Re: [dwm] suckless.org stylesheet glitch

2009-03-11 Thread Anselm R Garbe
2009/3/11 twfb twf...@googlemail.com:
 On 00:59 Wed 11 Mar     , Uriel wrote:
 Also, www.suckless.org is *SLOW* to the point of being unusable

 Slight exaggeration perhaps... but it is a little bit slow and was
 indeed slow even before the switch to werc. Nothing dramatic but
 noticable slow for such a low graphic website.

Don't expect too much from a xen instance. But it's more friendly to
the environment than having a full blown dedicated server idling most
of the time ;)

Kind regards,
--Anselm



Re: [dwm] wiki location changed

2009-03-10 Thread Anselm R Garbe
2009/3/9 Uriel urie...@gmail.com:
 Good work Anselm!

 And anyone interested in werc, see: http://werc.cat-v.org

 uriel

 P.S.: Can you make http://suckless.org work properly and
 http://www.suckless.org redirect to it? (Or the other way around if
 you really prefer it that way, although I prefer no www.)

You are right.

I'll do so when I got some time today.

Kind regards,
--Anselm



Re: [dwm] C unit testing

2009-03-10 Thread Anselm R Garbe
2009/3/10 Richard Pöttler richard.poett...@gmail.com:
 I just wanted to ask you guys if you could recommend me a tool to
 unit test my C code. So far I only found CUnit, Check and CuTest but
 haven't dug into any of them. Do you have any suggestions?

#include assert.h

;)

Kind regards,
--Anselm



[dwm] GSoC2009

2009-03-10 Thread Anselm R Garbe
For those of you who haven't noticed, we are applying as a mentoring
organization during GSoC2009 this year.

http://www.suckless.org/GSoC2009

We set up a new mailing list for GSoC specific questions which is
world-writable here:

g...@suckless.org

We do not know yet if we will be accepted.

Kind regards,
--Anselm



[dwm] GSoC 2009 mentors please shout

2009-03-06 Thread Anselm R Garbe
Hi there,

please send me a private mail if you'd be willing to mentor a GSoC
project this year for suckless.org.
We need at least 10 mentors I'd say.

Kind regards,
--Anselm



Re: [dwm] .xinitrc error?

2009-03-05 Thread Anselm R Garbe
2009/3/5 Christoph Siegenthaler c...@gmx.ch:
 I haven't changed my dwm config.h since 4.9 and was using it happily for
 months. I finally decided to try out 5.4.1 and I'm almost done.
 The only problem is that I can't get the status bar to display what's piped
 into dwm. It was working before and displayed a lot of fancy stuff.
 I stripped it down to the bare minimum now but it still displays dwm-5.4.1
 instead of what I want it to:

 $ cat .xinitrc
 #!/bin/sh
 ###
 # DWM #
 ###
 timeout=0.2
 while true
   do
       echo Test
       sleep $timeout
   done | dwm | eval `cat ~/.fehbg`

 What do I miss here? I'm sure it's something obvious (far somebody else but
 me)...

See the README file ;)

Kind regards,
--Anselm



Re: [dwm] This question is probably beneath you all--but I will ask anyway

2009-02-28 Thread Anselm R Garbe
Doesn't Alt+Left mouse button drags for move, and Alt+Right mouse
button drags for resize work? I haven't seen any X window which won't
resize using this.

Kind regards,
Anselm

2009/2/28 I. Khider cont...@ikhider.com:
 Greeting fellow DWM users

 I noticed with certain applications like Gimp, k3b, etc. it is very
 difficult to maximize a work screen--I have yet to figure it out. Also for
 Gimp, I have tried to move my tools applications around the workspace and
 apart from toggling between them, I canot move them around.

 I tried the man page and to google the problem and IRC on some channels but
 nobody knows, hence my appeal to you. Perhaps someone knows of a document I
 could consult to get on my way?

 Thank you in advance for your patience.

 -I-



-- 
--Anselm



Re: [dwm] Google Summer of Code 2009

2009-02-20 Thread Anselm R Garbe
2009/2/20 Matthias-Christian Ott o...@mirix.org:
 this year there will be Google' Summer of Code and Anselm has agreed
 that the suckless project will pariticipate. Usually it will be
 announced in the next weeks.

 Since they require every participating project to provide a website
 that lists the ideas for the student projects, I suggest to setup a wiki
 page. Maybe we can discuss them here prior posting them.

The requirements:

http://code.google.com/opensource/gsoc/2009/faqs.html#0_1_org_apply_4694175091022641

Kind regards,
--Anselm



[dwm] Issues with border

2009-02-19 Thread Anselm R Garbe
Hi,

I dislike the recent addition of the 0 border if only 1 tiled client
is in the view, reasons:

- gained screen real eastate is very minimal
- configure events are increased by n at any view() and toggleview(),
if n is the number of clients in the view
- corner cases for togglefloating()
- I dislike adjustborder() altogether

So my proposal is: reverting to old behavior (nonoborder), and for
those who like it, use a config.h function like:

void toggleborder(const Arg *arg) {
   borderpx = 1 - borderpx;
   arrange();
}

And then define a key binding for it.

Opinions?

Kind regards,
--Anselm



Re: [dwm] [OT] Personal Website and CSS

2009-02-19 Thread Anselm R Garbe
2009/2/19 Matthias-Christian Ott o...@mirix.org:
 On Thu, Feb 19, 2009 at 12:07:16AM +0100, hiro wrote:
  I think the only way is dropping HTML and CSS altogether and going
  with something new. I'd be very interested in contributing. I think
  the replacement should not only focus on presentation but equally on
  forming a base for less suckish applications which are highly network
  transparent.
 
  Kind regards,
  --Anselm

 Not sure if OP really wanted to do this, but such alternatives have
 always existed. Look at gopher for example.

 I would export 9p filetrees and mount them in acme. You can use text
 files and plumbing if you want hyperlinks.
 I very much enjoy reading 9fans that way.

 But I admit this not being beauty typesetting.

  browsers like Mozilla Firefox have terrible default typographic style
  and using text-mode browsers like links often seems to be only solution
  when reading longer texts.

 I don't really get this: Where can we find real typographic style in links?

 There's actually none, but it's better to display the text in a fixed-font
 uniform size than in misproportioned text with unsuitable spacing.

 Perhaps we need a combination of Troff's beauty and web browser's dynamics.

 What do you mean by dynamic? AJAX? I suppose you mean hyperlinks.

Well, here is what I realized during the st development and which
emerged into some text (g)ui library which can be seen as graphical
curses at some point and which I'm going to consider forming the base
of replacing HTML+CSS and vt100 and curses and all that stuff (and
which I'm afraid to publish in its current flaky and unfinished state
still but I need to do so anyways sooner or later).

Apart from presenting information (which can be done in a
terminal-like sense, and a browser is a terminal to some extend) which
used to be HTML in the past, it is very obvious that there is the
demand for so called web applications which run as hybrids remotely
and locally and which are simply loaded (instead of physically
installed) on every access time again and again... They can access
local and remote resources in a kind of transparent way and provide
services -- even if it's just about reading a bolg article.

There are 3 layers in such an approach:

- resource access
- resource
- scripting

The resource access should be done using a stateful protocol rather than HTTP.

The resource itself isthe content (could be something that replaces
HTML+CSS+JS and provide extensions such as map() for mapping contents
rendered by server- or client-side code and extensions for scripting).

The scripting layer is also an extension with access to the server and
client environment (not necessarily bound to the resource only). One
can compare it to JS -- though I doubt the DOM-based approach of how
web pages are scriptable nowadays is right.

In the case of a terminal, the resource is a tty session, the resource
access is the connection to it and the scripting are the commands send
back and forth (which are not restricted to the resource itself, which
could be a shell process, but which could be control sequences as well
(server- and client environment access).

So if you consider the modern Web as consisting of terminal servers
providing content then we get closer to the idea. I think designing
the HTML+CSS replacement must go hand in hand with the underlying
protocol.

Kind regards,
--Anselm



Re: [dwm] [OT] Personal Website and CSS

2009-02-18 Thread Anselm R Garbe
2009/2/18 Matthias-Christian Ott o...@mirix.org:
 since several years I have been planed to launch a personal website. I
 used to do quite aesthetical web design before I have subscribed to
 minimalism. What annoyed me then and now was CSS and its implementations
 in modern browsers.

 When I tried to design a minimalist website (just some typographic
 enhancements to make texts more read- and printable), I realised that
 there seems to be no agreed standard for a default CSS stylesheet merely a
 recommendation from the CSS standard [1] (which is incomplete) and a lot
 of people seem to be concerned about resetting the browser CSS defaults -
 even the W3C does so in their stylesheets [2]. Most people seems to have
 installed nearly all popular browsers, test with those and incorporate
 workarounds if necessary.

 All in all this seems very absurd to me and I would like to know how
 you approached this problem.

 At the moment I'm just aware of The Anti-web Manifesto [3] that someone
 linked to on this mailing list. Although I mainly subscribe to it,
 browsers like Mozilla Firefox have terrible default typographic style
 and using text-mode browsers like links often seems to be only solution
 when reading longer texts.

 Any ideas?

I think the only way is dropping HTML and CSS altogether and going
with something new. I'd be very interested in contributing. I think
the replacement should not only focus on presentation but equally on
forming a base for less suckish applications which are highly network
transparent.

Kind regards,
--Anselm



Re: [dwm] solaris regression tests

2009-02-14 Thread Anselm R Garbe
Hi,

2009/2/13 Stefan Kuttler dele...@gmx.net:
 After some digging within Solaris PATH Settings, I managed to compile 
 dwm-5.4.1 without problems: (So did others hopefully, but I want to
 collect nearly all plattforms)

 ,echo $PATH
 /usr/bin:/usr/openwin/bin:/usr/ucb:/usr/dist/exe:/usr/sfw:/usr/sfw/bin

 ,CC=/usr/sfw/bin/gcc

 ,gmake
 dwm build options:
 CFLAGS   = -std=c99 -pedantic -Wall -Os -I. -I/usr/include 
 -I/usr/X11R6/include -DVERSION=5.4.1
 LDFLAGS  = -s -L/usr/lib -lc -L/usr/X11R6/lib -lX11
 CC   = /usr/sfw/bin/gcc
 CC dwm.c
 CC -o dwm
 ,uname -a
 SunOS srm-hello-08 5.10 Generic_127111-07 sun4v sparc SUNW,Sun-Fire-T200
 ,file dwm
 dwm:ELF 32-bit MSB executable SPARC Version 1, dynamically 
 linked, stripped


 I got the idea of nightly regression tests for dwm (think Tinderbox).
 This could then be extended to match several patches against several
 Versions.


Last time I checked to compile it on SunOS it worked well with the sun
cc, not sure why you want to use gcc instead. Also, note that there
are some FLAGS in config.mk for SunOS.

Kind regards,
--Anselm



Re: [dwm] Virtual keyboards

2009-02-09 Thread Anselm R Garbe
Hi Peter,

2009/2/9 Peter Hartlich sg...@hartlich.com:
 It appears to me that both the onscreen keyboard and the client with
 the input focus should have a selfg border -- at least that makes most
 sense in my opinion.

 But you need to be able to distinguish between dwm's _selected_ (for
 tagging, closing etc.) client and X's _focused_ client. Killing your
 terminal window on accident could be awful.

What's wrong with focussing the next in the stack?

 Introducing another couple just for that sounds quite over-engineered
 to me.

 Agreed.

 What I would propose is the attached series of patches for hg import:
 The first renames focus() to selclient() and focusstack() to selstack().
 The second adds a new focus() function calling XSetInputFocus() and
 saving the client in a global foc (analogue to sel) variable; it then
 implements isfocusable based on the Gottox port + selfgcolor border
 for focused, but unselected windows.

Agreed, I'll apply your patches.

 By the way, your last commits have a...@null as the author?

I will address this. I'm using a fresh host.

Kind regards,
--Anselm



Re: [dwm] Virtual keyboards

2009-02-08 Thread Anselm R Garbe
Hi Peter,

2009/1/31 Peter Hartlich sg...@hartlich.com:
 I like this patch and will apply it to 5.4 which is going to be
 released until the weekend.

 One problem with it is that you don't really know where keyboard input
 will be going (dwm being focus-follows-mouse by default). I use another
 patch on top of that (attached) to draw a selfgcolor border around the
 last focusable window when an unfocusable window is selected, but I'm
 not sure recycling selfgcolor is kosher...

 Plus you may want to rename focus() to selectwin() or something.

I see. I think the whole unfocussable stuff needs further thinking
before going mainstream. I'm going to release 5.4 now.

It appears to me that both the onscreen keyboard and the client with
the input focus should have a selfg border -- at least that makes most
sense in my opinion. Introducing another couple just for that sounds
quite over-engineered to me.

 I should get broadband today that I'll be ack online and can support
 questions regarding my upcoming st and libtg release.

 So, when's the st release and does libtg (if that's the name of the
 not-completely-secret project) use XCB? :)

Well, I changed my mind several times during the last weeks. When I
get time I end up thinking that several decisions I made are wrong by
nature... but I will come up with one way or another soon. I'm not too
convinced libtg as it is (X abstraction primitives + text format
processing + parts of text window abstractions and input handling) is
the right way to go. I feel remembered at the wmii times, when wmii
was screwed up due to depending on its 9P scripting interface. I
believe I did the same journey with st making it dependent on libtg,
and I tend to revert this mistake at the moment.

Kind regards,
--Anselm



[dwm] dwm-5.4

2009-02-08 Thread Anselm R Garbe
Hi there,

I'm glad to announce the new dwm-5.4 release which can be downloaded from:

  http://code.suckless.org/dl/dwm/dwm-5.4.tar.gz

This release doesn't draw any borders around tiled clients if there is
only 1 tiled client in the view. This saves some extra space of screen
real estate for the application in use -- and provides a hint in
monocle layout if there are more clients managed by dwm or not.

Kind regards,
--Anselm



Re: [dwm] dwm-5.4

2009-02-08 Thread Anselm R Garbe
Ok, I hope that's fixed in 5.4.1.

Kind regards,
Anselm

2009/2/8 Nibble nibble...@gmail.com:
 This release doesn't draw any borders around tiled clients if there is
 only 1 tiled client in the view. This saves some extra space of screen
 real estate for the application in use -- and provides a hint in
 monocle layout if there are more clients managed by dwm or not.

 Hi,

 I think this isn't working as expected, try the next scenario:
  1. We have a view with 2 tiled clients
  2. We toggle to floating layout one of them. So, we have a tiled
 client with no border and a floating client with border.
  3. We toggle to floating layout the other one. And now, we have two
 floating clients, one with border and one with no border.

 Maybe, number of visible clients should be used instead of number
 of tiled clients when calling showhide().

 Kind Regards,
 Nibble



[dwm] dwm-5.4.1

2009-02-08 Thread Anselm R Garbe
Hi there,

a bugfix release:

  http://code.suckless.org/dl/dwm/dwm-5.4.1.tar.gz

Kind regards,
--Anselm



Re: [dwm] Virtual keyboards

2009-01-26 Thread Anselm R Garbe
Hi,

I like this patch and will apply it to 5.4 which is going to be
released until the weekend. I should get broadband today that I'll be
back online and can support questions regarding my upcoming st and
libtg release.

Kind regards,
Anselm

2009/1/22 Peter Hartlich sg...@hartlich.com:
 Hi,

 http://s01.de/~gottox/hg/dwm/rev/d3c3a8018349

 A port of that + http://s01.de/~gottox/hg/dwm/rev/0c589f7247e6
 is attached. Thanks Gottox!

 Regards,
 Peter



Re: [dwm] Layers

2009-01-26 Thread Anselm R Garbe
2009/1/22 Matthias-Christian Ott o...@mirix.org:
 Dwm has by default a floating and a tiled layer that can have a different
 layout. Tiling or maximisation works fine for most clients (by the way,
 is there are reason why windows are called clients in dwm jargon?), some
 dialogs, popups or short-living windows require to be floating. Therefore
 dwm keeps these windows on an upper layer.

It's called client because it's a client of the window manager -- the
terminology has been in use for ages in different WMs and been adopted
by dwm for this legacy reason in order to increase the understanding
by the reader (who might compare the code base with different WMs).

 While this makes sense for most applications, there are some (Gimp is
 as famous example for this) that are build around this WIMP concept and
 thus have to be floating in order to usable. But sometimes it makes sense
 to quickly hide them to access information hidden by them (for example
 I use the dictionary programme Ding when writing E-Mails in English).

 A common approach would be to dedicate a tag to them and switch
 via ALT+TAB back and forth. In my opinion this a bit cumbersome and
 non-intuitive. I rather expect to rotate the two layers like I can do
 with windows in monocle layout.

Well, apart from the floating mode, I bind gimp to the dedicated tag
7 where I only assign broken apps with. Since all gimp windows are
floating by the same rule, toggleview()'ing 16 will do the trick
without switching the layout.

Kind regards,
--Anselm



Re: [dwm] No Border Behaviour

2009-01-08 Thread Anselm R Garbe
Hi,

2008/12/22 Matthias-Christian Ott o...@mirix.org:
 Yesterday I updated my dwm tree to tip and noticed that the borders were
 removed (1376). This applies only to clients in tiled layout, is there
 a reason why this behaviour is not present in monocle?

It is present in monocle as well, if there is only 1 client. This
makes the new behavior also an indicator for the monocle layout if
there are more clients.

 If no border indicates that there's just one client in the tag it makes
 some sense, but I rather like borderless if there's only one client
 visible. This seems more intuitive to me, because borders indicate a
 separation which is only necessary when there is more than one client
 visible.

Yes, that's how it is supposed to be.

Kind regards,
--Anselm



Re: [dwm] dio-0.1.3

2009-01-05 Thread Anselm R Garbe
2009/1/4 Yoshi Rokuko yoshi.rok...@yokuts.org:
 On Fri, Jan 02, 2009 at 06:53:10PM +0100, yy wrote:
 I have been experimenting with user interfaces concepts lately.
 My first aim was a simple mp3 player. The code has been adapted later
 to do other tasks, and now it is some sort of generic list manager,
 where items can be played. It was initially based on dmenu-3.9 (that's
 the reason it is announced here), though it has evolved to be much
 more complicated (too much, actually).

 I like the idea. A while ago I was thinking about a xlib gui file-opener,
 your `launcher' dio script reminds me on that ...

 It would be cool to have more nice xlib apps to create some sort of dwm
 desktop, I have to try your stuff ;-)

My still secret project is about the foundation for that -- a
collection of libraries which should enable writing such apps, mainly
window/event abstractions and a decent font API -- this is code which
emerged from my st code base which is subject to be published soon as
well. I was a little bit shocked, that yiyus went into a similiar
direction already ;)

But I'm in the middle of yet another move currently, so I will
postpone any announcements, otherwise I won't be able to be of any
support...

Kind regards,
--Anselm



Re: [dwm] [dmenu] help me test possibly faster dmenu_path

2008-12-17 Thread Anselm R Garbe
Neale,

2008/12/17 Neale Pickett ne...@woozle.org:
 I theorize that find outperforms for/test.  Below are two shell scripts:
 if you run the first one it will let you know the results of two runs.
 The second one is a modified dmenu_run that uses find.  I'd appreciate
 it if people would run the first one and mail the results to me.  I'll
 let the list know what the results are.

Similiar tests have been done a while ago, however we decided for the
shell-only version for various reasons. First of all you are referring
to GNU find as far as I can tell, however the BSD find is slightly
different (same applies to Solaris), then there was an issue with
softlink following and something else which resulted in displaying
executables which were not intended to show up, the refresh testing
and maybe another issue I don't remember right now (it's all in the
mail archive somewhere). Of course find is faster, however I don't
intend to change the shell only solution since we got cached
results...

Kind regards,
--Anselm



Re: [dwm] Border hater, border lover

2008-12-17 Thread Anselm R Garbe
2008/12/15 Anselm R Garbe garb...@gmail.com:
 2008/12/14 voltaic volt...@gmail.com:
 It seems this idea was forgotten again, so I thought I would bring it
 up once more. As DWM 5.4 is being finalized and there is discussion on
 what to include in future versions, I'd love to see the
 no-border-if-single-window behavior become mainstream.

 Agreed, will push a patch accordingly during the day.

It's in. Please recheck if there are any issues. Otherwise I'm going
to release 5.4 tomorrow.

Kind regards,
--Anselm



Re: [dwm] xsetroot/status scripting using rc shell?

2008-12-16 Thread Anselm R Garbe
Try

text=`{date}^ ^`{uptime}
xsetroot -name $text

Kind regards,
Anselm

2008/12/16 Michael Brown ebeb...@gmail.com:
 These work:
 xsetroot -name test
 xsetroot -name `{echo test}

 These don't:
 xsetroot -name `{date}
 xsetroot -name `{echo test test}
 xsetroot -name `{echo 'test test'}
 xsetroot -name (`{echo test test})

 Seems the problem has something to do with xsetroot's whitespace handling...

 Mike

 On Mon, Dec 15, 2008 at 3:15 AM, Anselm R Garbe garb...@gmail.com wrote:
 2008/12/14 Michael Brown ebeb...@gmail.com:
 Maybe a silly question, but is any p9p user out there able to set the
 statusbar text with xsetroot using rc(1)?

 Did you check if

  xsetroot -name foobar

 works at all? If not something might be wrong with the DISPLAY variable.

 The following don't seem to work:
 xsetroot -name `{SCRIPT}
 xsetroot -name `{SCRIPT}
 xsetroot -name (`{SCRIPT})

 The first one is correct. Try something like

  xsetroot -name `{date}^ ^`{uptime}

 for example.

 Kind regards,
 --Anselm



Re: [dwm] xsetroot/status scripting using rc shell?

2008-12-15 Thread Anselm R Garbe
2008/12/14 Michael Brown ebeb...@gmail.com:
 Maybe a silly question, but is any p9p user out there able to set the
 statusbar text with xsetroot using rc(1)?

Did you check if

  xsetroot -name foobar

works at all? If not something might be wrong with the DISPLAY variable.

 The following don't seem to work:
 xsetroot -name `{SCRIPT}
 xsetroot -name `{SCRIPT}
 xsetroot -name (`{SCRIPT})

The first one is correct. Try something like

  xsetroot -name `{date}^ ^`{uptime}

for example.

Kind regards,
--Anselm



[dwm] 25c3

2008-12-14 Thread Anselm R Garbe
Hi there,

I'll be around from Dec 27 late night to Dec 28 late night at 25c3 in
Berlin this year only.
Let me know if you are around as well through editing the scklss wiki
entry of the 25c3 wiki at:

http://events.ccc.de/congress/2008/wiki/Scklss

I'd also like to see some guys willing to escape from the BCC in order
to get some drinks in some nice bar...

I plan a lightning talk on the 28/12 in the morning about st and the
secret project... so if you arrive late we could meet there as well. I
haven't reserved any space in the hack center unfortunately. But
usually there is enough space to hang around anyways.

Kind regards,
--Anselm



Re: [dwm] Border hater, border lover

2008-12-14 Thread Anselm R Garbe
2008/12/14 voltaic volt...@gmail.com:
 It seems this idea was forgotten again, so I thought I would bring it
 up once more. As DWM 5.4 is being finalized and there is discussion on
 what to include in future versions, I'd love to see the
 no-border-if-single-window behavior become mainstream.

Agreed, will push a patch accordingly during the day.

Kind regards,
--Anselm



Re: [dwm] dwm-5.3

2008-12-13 Thread Anselm R Garbe
2008/12/13 Frederic Chardon chardon.frede...@gmail.com:
 2008/12/13 James Turner ja...@bsdgroup.org:
 After taking some time and looking at the different signal headers on
 OpenBSD only #include sys/signal.h is required, no need to #include
 signal.h which contains additional functions.

 Same for FreeBSD (and probably all other *BSD). Would it be possible
 to include this one line mainstream?
 Fred

Yes, will do that.

Kind regards,
--Anselm



Re: [dwm] dwm on tablet pc

2008-12-13 Thread Anselm R Garbe
2008/12/12  jo...@freenet.de:
 Try dwm-gtx. Onscreenkeyboards should work with it. :)
 Thanks for the hint. I tried your version of dwm, and cellwriter works.
 What is the essential part for this to work?

 Getting cw to work is the first step. I also tried the mouse
 actions for the bar, which are already implemented in dwm, but
 especially those with MODKEY do not work in conjunction with cw. There
 would still be much work to do regarding a clickable bar and of course
 a clickable version of dmenu for application launching.

 @yy: Emulating a 5 buttons mouse would only be possible by implementing
 onscreen buttons, I think, causing a similar amount of work.

 I am not a c programmer - writing a small patch is possible, but not
 more - I am more a script kiddie ;-) Atm I am using openbox and
 fbpanel, but I am missing dynamic tiling. Of course there are   tile
 and whaw, but they are not sufficient for me. I will try to get it
 working with devilspie executing a perl script and issuing wmctrl.

I think for tablet pcs, there must be a less suckish onscreen keyboard
with some extensions which allow integration with dwm, wether as patch
of dwm.c (which would be the easiest since it doesnt require any
additional communication between dwm and a some kind of a input event
client) or as external app using some x property to communicate with
dwm.

In a first attempt this should be a patch however.

Kind regards,
--Anselm



Re: [dwm] dwm-5.4 stdin; cycle tags

2008-12-13 Thread Anselm R Garbe
2008/12/13 henry atting nspm...@literaturlatenight.de:
 - A `make clean install' does install dwm but it cannot read from stdin
  which prevents me from displaying time and date on the toolbar.

config.h:15: warning: 'readin' defined but not used

See the README file for an example, the status text is set using
xsetroot(1) now.

 - I found a patch for cycling through tags in this group but it is for
  dwm-5.2 and apparently does not work for 5.4. How can I set up cycling
  through tags for 5.4?

The tagging approach didn't change between 5.2 and 5.4, so I assume
it's just a matter of making the 5.2 patch applying to the 5.4
codebase.

Kind regards,
--Anselm



Re: [dwm] Re: dwm-5.4 stdin; cycle tags

2008-12-13 Thread Anselm R Garbe
2008/12/13 henry atting nspm...@literaturlatenight.de:
 2008/12/13 henry atting nspm...@literaturlatenight.de:
 The tagging approach didn't change between 5.2 and 5.4, so I assume
 it's just a matter of making the 5.2 patch applying to the 5.4
 codebase.

 Mmh, I am not very familiar with patching, I did it this way:

 ,
 | do! patch -p1  dwm-5.2-arrownav.diff
 | missing header for unified diff at line 3 of patch
 | can't find file to patch at input line 3
 | Perhaps you used the wrong -p or --strip option?
 | The text leading up to this was:
 | --
 | |--- config.def.h   Tue Sep  9 15:46:17 2008
 | |+++ config.def.h   Tue Nov 18 19:26:53 2008
 | --
 | File to patch: config.def.h
 | patching file config.def.h
 | Hunk #1 succeeded at 62 (offset 1 line).
 | missing header for unified diff at line 14 of patch
 | can't find file to patch at input line 14
 | Perhaps you used the wrong -p or --strip option?
 | The text leading up to this was:
 | --
 | |--- dwm.c  Tue Sep  9 15:46:17 2008
 | |+++ dwm.c  Tue Nov 18 19:31:55 2008
 | --
 | File to patch: dwm.c
 | patching file dwm.c
 | Hunk #1 succeeded at 197 (offset -1 lines).
 | Hunk #2 FAILED at 1668.
 | 1 out of 2 hunks FAILED -- saving rejects to file dwm.c.rej
 `

Well as I said, you will need to patch it manually, since the lines
have changed and the heuristic approach supported by patch(1) isn't
succeeding either.

Kind regards,
--Anselm



[dwm] plan for dwm

2008-12-12 Thread Anselm R Garbe
Hi,

here is the plan:

slock-1.1 will be released soon containing Ali's patch with some minor
modifications.

dwm-5.4 will also be released soon containing the transition patch
with the proposed x property based status reporting, and Neale's spawn
patch again, and possibly some other minor patches ;)

After that 5.5 could contain a more advanced approach for multihead
support (though I think I need to investigate further and experiment
more into this direction, before agreeing on the final approach). It
should also contain a cleaned up usage of the HEIGHT/WIDTH macros
besides the reduction of the ugly 2 * c-bw occurrences throughout
the code (I plan to move these border deductions to resize).

Then there will be something else soon as well...

Kind regards,
--Anselm



Re: [dwm] dwm and dualhead

2008-12-11 Thread Anselm R Garbe
Hi,

I tried different multihead approaches in between 4.9 and 5.1 with
dwm. I remember the following:

- have a dwm environment on each Xinerama screen (like multiple dwm's
in classic multihead setups) as suggested by Mate
  - the problem was, it didn't felt right because it added another
navigation layer on top of dwm, to basically navigate through screens
and to move clients between screens, the conclusion was, if you really
want this, run multiple instances of dwm with a classic multihead
setup

- make layout algorithms use more screens (keep the bar at a specific
main screen)
  - the problem was, that it doesn't scale well, most layout
algorithms aren't designed for multihead setups, esp. if the screens
have different geometries

- split the tags into n distinct tagsets (1 for each screen) and use
the existing tagging concept for focussing/moving clients between
different screens using tagging, display the status bar on the screen
with the focussed client (or some arbitrary fallback if there are no
clients)
  - I think that was my favorit approach, so the main drawback was
that it made dwm significantly more complex and that there needs to be
some kind of setup option which tells which tag belongs to which
screen, so the intermediate approach was having a tag struct with a
screen index - but hell taht sucked

- use the screen with the pointer as default screen where the bar is
presented and the layout algorithms happen, use all other screens for
floating clients
  - this is the current approach

Also, the main question remains, how many multihead users are there?
The main argument for the last approach was, if there are only 10% of
multihead users, why should all single head/laptop users suffer from
the unnecessary complexity? dwm's current Xinerama support isn't worse
than the Xinerama support in any major desktop environment, but it is
not very smart compared to other tiling WMs.

Kind regards,
--Anselm



Re: [dwm] dwm and dualhead

2008-12-10 Thread Anselm R Garbe
2008/12/10 Johannes Wegener [EMAIL PROTECTED]:
 Hi,
 is there anybody who has experience with dwm and dualhead setups? I
 tried to use dwm with a xrandr dualhead but it seemed quite useless becouse I
 could just drag floating windows into the second screen. Xinerama seems
 no more supported by xorg 7.4 and the intel driver.

 So my question are do you plan to put xrandr support into dwm? or has
 anybody a hack/workaround for that problem?

Seems that XRandR support in dwm is becoming a requirement soon, unfortunately.

I wonder which X morons are to blame for dropping Xinerama completely...

I think the whole X.org crowd is totally misled by dodgy desktop
environment communities...

Hopefully I will find some sponsor to fund a from-scratch X server and
X lib reimplementation which does multihead without any quirks and
hacks like XRandR... and which provides a decent font interface to
begin with.

Kind regards,
Anselm



Re: [dwm] dwm and dualhead

2008-12-10 Thread Anselm R Garbe
2008/12/10 Mate Nagy [EMAIL PROTECTED]:
  The lesson I learnt from this: I will never buy a laptop with integrated
 intel graphics again.

Which laptop model is to blame? ;)

Kind regards,
--Anselm



Re: [dwm] xprop patch

2008-12-09 Thread Anselm R Garbe
2008/12/9 Benoit T [EMAIL PROTECTED]:
 On Tue, Dec 09, 2008 at 10:41:35AM -0700, Neale Pickett wrote:
 I very much like this patch.  I realized right away that I would never
 again need to restart dwm when I work on my status script.  When it
 dies, I can just start it up again without restarting DWM.  Someone
 could even have multiple programs running to update the status text.  It
 removes the need for the readin variable: you either set the property
 or you don't.

 The patch removes 39 SLOC:

 gotta admit Neale has 2 points :)

 i like the idea of not having to restart dwm when hacking on the status
 script

 conversely, when hacking on dwm itself, i like being able to restart dwm
 without restarting my x session, yet i want the session to exit when dwm
 exits, ie. dwm  xterm in .xsession is not what i want.

 here is a respawn patch. it is most useful in conjunction with a
 local install in the makefile, copying the newly built dwm binary over
 the currently running one, inside my $HOME rather than in /usr/local

 the patch costs 5 loc in the source + 1 loc in config.h
 the patch is not completely portable due to use of ``environ''. i hope
 that even the BSDs have that nowadays, but probably not through defining
 _GNU_SOURCE, which is glibc specific.

If you consider that Neale's patch makes it upstream, what do you think about:

while true
do
dwm
done

in .xinitrc to restart dwm?

Kind regards,
--Anselm



Re: [dwm] xprop patch

2008-12-09 Thread Anselm R Garbe
2008/12/9 Neale Pickett [EMAIL PROTECTED]:
 I very much like this patch.  I realized right away that I would never
 again need to restart dwm when I work on my status script.  When it
 dies, I can just start it up again without restarting DWM.  Someone
 could even have multiple programs running to update the status text.  It
 removes the need for the readin variable: you either set the property
 or you don't.

I dislike X properties, however I like your patch a lot and consider
it making mainstream, since it simplifies dwm a lot and fixes a lot of
issues. dwm depends on X anyways, so for the status text mechanism to
happen, it's the simpler method.

 This would be 40 if the property were hard coded to XA_WM_NAME.  I left
 in a comment to use a property named DWM_STATUS instead of XA_WM_NAME,
 so people could play with it easily, but I think XA_WM_NAME is
 ultimately the right way to do it.

XA_WM_NAME is the way to go.

Kind regards,
--Anselm



Re: [dwm] applyrules()

2008-12-09 Thread Anselm R Garbe
2008/12/6 yy [EMAIL PROTECTED]:
 Great 5.3.1 release!

 What about this little change in applyrules?
 @@ -259,7 +259,7 @@
 (!r-class || (ch.res_class 
 strstr(ch.res_class, r-class)))
 (!r-instance || (ch.res_name 
 strstr(ch.res_name, r-instance {
c-isfloating = r-isfloating;
 -   c-tags |= r-tags  TAGMASK;
 +   c-tags |= r-tags  TAGMASK ? r-tags
  TAGMASK : tagset[seltags];
}
}
if(ch.res_class)

 This way you can define rules like:
{ MPlayer,NULL,   NULL,   0,True },
{ MPlayer,NULL,   NULL,   1  6,   True },
 and have mplayer tagged to the currently selected tags and to the 6th
 tag, for example. This trick is very convenient to group windows by
 categories, I do it with image viewers, music players... and I think
 it makes clearer the rules definition. With the current
 implementation, if r-tags is 0 the result of applying that rule is
 undefined depending on the previous rules. The only problem I can see
 is that somebody could be doing:
{ NULL,   NULL,   NULL, 0,True },
 to treat new windows like float by default, by I doubt there's anybody
 here doing such a thing...
 - yiyus || JGL .

I see the use and won't worry to much about this corner case. I
consider making this mainstream as well.

Kind regards,
--Anselm



Re: [dwm] DWM 5.3.1 and Xinerama

2008-12-07 Thread Anselm R Garbe
2008/12/7 Amit Uttamchandani [EMAIL PROTECTED]:
 Sorry to bother with this question

 I have been using DWM for a year or so now but never needed to connect
 my laptop to a projector till today. I realized I had no idea how to do
 this with DWM.

 After some research I found that DWM uses Xinerama and not xrandr. I got
 as far as compiling DWM with Xinerema support and then getting lost.

Isn't Xinerama a legacy API which is glued with XrandR in recent X.Org
builds? At least that was my impression.

 What's the next step? I plan to put a how to in the DWM page once I get
 this up an running.

If dwm has been build with Xinerama support it will use the screen
which contains the pointer as default screen when it starts. The
default screen will be used to display the bar and to apply all
layout algorithms. All other screens can only be used for floating
clients. That's how it is supposed to behave in vanilla dwm.

HTH,
--Anselm



Re: [dwm] dwm-5.3

2008-12-07 Thread Anselm R Garbe
2008/12/7 Neale Pickett [EMAIL PROTECTED]:
 Guillaume Quintin [EMAIL PROTECTED] writes:

 But now, when I reinstall dwm-5.2 I get the same problem than in
 dwm-5.3 and dwm-5.3.1, double-fork, simple-fork and
 re-double-fork. I don't understand why.

 This makes me happy, not only because my spawn function wasn't the
 problem, but also because I can feel again like I know how Unix works :)

 I now think it is the open file descriptor causing the problem.  The
 SIGCHLD or double-fork would both cause this behavior; the problem is
 that the shell running .xinitrc is waiting for an EOF on the pipe it
 created for STD(IN|OUT|ERR), and is never getting it because you still
 have some X clients with it open.

Afair running exec dwmstatus in .xinitrc should delegate this issue to
dwmstatus, because the problem of running some loop | dwm in .xinitrc
existed since the very first dwm version and there is no real solution
to this problem unless the feed process is replaced by something more
appropriate which uses a fifo redirection.

 I advise against closing STDOUT or STDERR in the spawn function: that's
 how error messages make it in to .xsession-errors.

So far it was only about closing stdin.

I don't like the alternatives very much, I dislike popen() some status
feed process, or creating a fifo, or reading from some status text
file, or using X properties (like larsremote). Reading from stdin in
dwm is the simpliest and most elegant solution imho.

Kind regards,
--Anselm



Re: [dwm] Using dwm as a nested manager?

2008-12-06 Thread Anselm R Garbe
2008/12/6 Jorge Vargas [EMAIL PROTECTED]:
 Hi, I have been thinking about this for some time, and I like dwm a
 lot but I don't like it to manage all my windows, so I was wondering
 if it's possible to nest it inside another manager and tell it to
 handle only some windows? Please note I used this a long time ago in
 the 2.x releases so I'm not familiar with the codebase anymore.

You could use Xnest(1) in order to run dwm in a nested sense. However
what do you miss in dwm that you don't like to manage all windows?

Kind regards,
--Anselm



Re: [dwm] patch for colored status text

2008-12-06 Thread Anselm R Garbe
What about adding this patch to the wiki?

Kind regards,
Anselm

2008/12/4 Jeremy Jay [EMAIL PROTECTED]:
 Another simple patch for anyone interested.  Changes the way colors are
 defined slighty, allowing you to create more color combinations.  Then,
 to color the status text from stdin you can simply use the color combo # as
 follows:

 echo -e \x03 warning low battery  -- will be printed with the third color 
 combo
 echo -e \x04 danger will robinson -- will be printed with the fourth color 
 combo
 echo -e  normal text \x03 warning \x04 error \x01 normal again

 For example, my colors in config.h are:
#define NUMCOLORS 4
static const char colors[NUMCOLORS][ColLast][8] = {
  // border   foreground background
  { #33, #dd, #33 },  // normal
  { #88, #ff, #88 },  // selected
  { #ff, #00, #00 },  // urgent/warning  (black on 
 yellow)
  { #ff, #ff, #ff },  // error (white on red)
  // add more here
};

 Which, coupled with my own status script results in things like the attached 
 image.

 Hope someone else finds this handy, I let my battery die one too many
 times because I never noticed how low it was...

 Jeremy



Re: [dwm] Re: urgent windows border

2008-12-06 Thread Anselm R Garbe
2008/12/4 yy [EMAIL PROTECTED]:
 2008/12/4 Anselm R Garbe [EMAIL PROTECTED]:
 I have mixed feelings about this patch. Does someone has strong
 arguments that this would be a good idea for upstream dwm?


 I also have mixed feelings... I wrote it because I didn't see urgent
 windows when they were visible (I know this sentence looks stupid, I
 know, but you get it), and since the implementation resulted simpler I
 decided to post it here.
 There is another middle-way solution which you could be interested in:
 move the clearurgent() call to focus(), like in my patch, but forget
 about the urgent border color (which is what makes the patch uglier).
 This way, you could save some loc while getting the functionality of
 notifying urgent clients in viewed tags. If you have no time or
 whatever I can modify my patch and send it to the list tomorrow.
 OTOH, I will probably maintain the patch for the border color, at
 least for the moment. But I won't post it here or anything if nobody
 else is interested.

Yes, I did something similiar for the 5.3.1 bugfix release I'm
currently uploading.

Kind regards,
--Anselm



Re: [dwm] dwm-5.3

2008-12-06 Thread Anselm R Garbe
I reverted the old spawn in the 5.3.1 release I'm currently uploading,
until this issue gets sorted. But this proofs again never change a
running system, especially I believe we experienced exactly the same 4
years ago when we switched back and forth to double-forks and signal
handlers. Unix is a mess... ;)

Kind regards,
Anselm

2008/12/5 Guillaume Quintin [EMAIL PROTECTED]:
 On Fri, 5 Dec 2008 15:52:26 +0100
 yy [EMAIL PROTECTED] wrote:

 2008/12/5 Guillaume Quintin [EMAIL PROTECTED]:
  On Fri, 5 Dec 2008 08:33:44 +
 
  Here is my .xinitrc :
 
  while true
  do
 echo `date`
 sleep 1
  done | dwm
 

 A bit off-topic, but, why the echo? A simple date should do it.


 Yes a simple date makes it.

 --
 Kind regards,
 Guillaume Quintin.



[dwm] dwm-5.3.1

2008-12-06 Thread Anselm R Garbe
Hi,

the bugfix release can be found at

  http://code.suckless.org/dl/dwm/dwm-5.3.1.tar.gz

It includes a reverted spawn function. Sorry for any inconvenience.

Kind regards,
Anselm

2008/12/4 Anselm R Garbe [EMAIL PROTECTED]:
 Hi,

 there was some silence during the last weeks, simply because I am/was
 rather busy but also because I'm working on a secret surprise project
 (yes it's st related). But I won't tell anything about it yet -- I
 hope to disclose the details at 25C3 in Berlin in a couple of weeks ;)

 Anyway, it's time for a new dwm release, you can fetch it from

  http://code.suckless.org/dl/dwm/dwm-5.3.tar.gz

 This release contains the spawn() version of Neale and several
 bugfixes regarding the NOBORDER handling in 5.2, and a new config.h
 option which allows to set use server grabs during mouse based
 resizals/movements.

 Let me know any issues.

 Kind regards,
 --Anselm



Re: [dwm] Re: urgent windows border

2008-12-06 Thread Anselm R Garbe
2008/12/6 yy [EMAIL PROTECTED]:
 2008/12/6 yy [EMAIL PROTECTED]:
 There is little error here. It is not working as expected in 5.3.1.
 This patch fixes it.

 Be care if you apply this, I forgot to remove my PREFIX (which is
 /usr) in config.mk

Thanks, applied.

I'll wait for other issues first before making a new micro release.

Kind regards,
--Anselm



Re: [dwm] dwm-5.3

2008-12-06 Thread Anselm R Garbe
2008/12/6 Jeremy Jay [EMAIL PROTECTED]:
 This was my hunch too, glad someone got it before me though.  This
 patch fixes the problem with 5.3.  Probably the same with the double-
 fork version too.

Glad you investigated further ;)

I will test this and wait some days, looks like there will be some 5.3.2 soon ;)

Kind regards,
--Anselm



Re: [dwm] dwm-5.3

2008-12-05 Thread Anselm R Garbe
2008/12/5 Neale Pickett [EMAIL PROTECTED]:
 Neale Pickett [EMAIL PROTECTED] writes:

 Would you mind sharing how you launch dwm?

 It might also be helpful to share your status script.  If you launch
 your status script like this:

   status | dwm

 and status forks, the parent may not be exiting.

 If the status program never exits, X won't terminate when you kill dwm.
 To test if yours operates this way, try the following experiment:

  xterm1$ status | cat
  xterm2$ kill (pid of cat)

 My status program at least keeps on running even though it can no longer
 write to stdout.  I think it's because the parent shell, the one outside
 the loop, never gets the SIGPIPE and keeps on running.  I'll play with
 it and report back.

 This problem isn't related to the recent fork patch, tough; you can
 reproduce this behavior without ever calling spawn.

 The reason this doesn't stop X is because your .xsession (or .xinitrc)
 is waiting for all subprocesses to exit.  As long as status keeps
 running, .xsession won't exit, and the X server startup script won't
 kill the X server.

 Here's something you can put in .xsession to run status as a background
 process and cause your .xsession to exit when dwm exits:

  XSTATUS=$HOME/.status.$(hostname).$DISPLAY
  mkfifo -m 600 $XSTATUS
  status  $XSTATUS 
  STATUS_PID=$!
  dwm  $XSTATUS
  kill $STATUS_PID
  rm $XSTATUS

I also think this is rather related to the status feed.

Kind regards,
--Anselm



Re: [dwm] dwm-5.3

2008-12-05 Thread Anselm R Garbe
2008/12/5 James Turner [EMAIL PROTECTED]:
 Great! Thank you for dwm-5.3. I think that it's needed to #include
 signal.h, infact without it I couldn't compile on NetBSD.

 #include signal.h is also required on OpenBSD.

Oh yes, I missed that. I will re-issue dwm-5.3.1 with this fix tonight.

Kind regards,
--Anselm



Re: [dwm] slock dialog behavior

2008-12-04 Thread Anselm R Garbe
Thanks for reporting this, I currently try to reproduce and fix this.

Kind regards,
Anselm

2008/11/29 list subscriber [EMAIL PROTECTED]:
 Hello,
 It seems as though some variation of a previous dialog bug
 (http://lists.suckless.org/dwm/0711/4361.html) still exists. I was able to
 reproduce the behavior with dwm and twm. In the first case I am able to
 regain control to the window manager, but in the second case X must be
 restarted.

 cat t.sh
 #!/bin/bash

 firefox 
 PID=$!
 sleep 3
 kill -9 $PID

 # 1. slock drops back to wm and all windows are visible until an input event
 # (key press/mouse event) in which case it blanks again and it behaves as
 # normal
 slock 
 firefox 

 # 2. just flashes to wm on an input event but doesn't allow entering
 password
 # Warning! I was unable to unlock the display and had to restart X
 :EOF
 while :; do
 [[ `xlsclients | grep firefox` ]]   slock
 done
 EOF

 Thanks



Re: [dwm] patch to not reparent children to init

2008-12-04 Thread Anselm R Garbe
Applied in hg tip, thanks Neale!

2008/11/4 Neale Pickett [EMAIL PROTECTED]:
 Reparenting everything to init with the double-fork is a nightmare on a
 many-user machine, especially when I'm logged in more than once.  pstree
 becomes useless.  This sets up a SIGCHLD handler and only forks once.
 Adds 2 SLOC, but surely there's some reason the double-fork is there that
 I'm just missing...

 void
 sigchld(int signal)
 {
  while (0  waitpid(-1, NULL, WNOHANG));
 }

 void
 spawn(const Arg *arg)
 {
  signal(SIGCHLD, sigchld);
  if (fork() == 0) {
if (dpy) close(ConnectionNumber(dpy));
setsid();
execvp(((char **)arg-v)[0], (char **)arg-v);
fprintf(stderr, dwm: execvp %s, ((char **)arg-v)[0]);
perror( failed);
exit(0);
  }
 }



Re: [dwm] Re: urgent windows border

2008-12-04 Thread Anselm R Garbe
2008/11/29 yy [EMAIL PROTECTED]:
 It had a bug. We don't want to set as urgent the sel client. Sorry for
 the noise.

I have mixed feelings about this patch. Does someone has strong
arguments that this would be a good idea for upstream dwm?

Kind regards,
--Anselm



[dwm] dwm-5.3

2008-12-04 Thread Anselm R Garbe
Hi,

there was some silence during the last weeks, simply because I am/was
rather busy but also because I'm working on a secret surprise project
(yes it's st related). But I won't tell anything about it yet -- I
hope to disclose the details at 25C3 in Berlin in a couple of weeks ;)

Anyway, it's time for a new dwm release, you can fetch it from

  http://code.suckless.org/dl/dwm/dwm-5.3.tar.gz

This release contains the spawn() version of Neale and several
bugfixes regarding the NOBORDER handling in 5.2, and a new config.h
option which allows to set use server grabs during mouse based
resizals/movements.

Let me know any issues.

Kind regards,
--Anselm



Re: [dwm] make setlayout toggle

2008-11-20 Thread Anselm R Garbe
2008/11/20 Claudio M. Alessi [EMAIL PROTECTED]:
 On Wed, Nov 05, 2008 at 09:39:58AM +, Anselm R Garbe wrote:
 Ok, are there any concerns making this upstream again? (Yes I know, we
 had this already in earlier versions, by that time it was called
 togglelayout())... There were reasons for not toggling, basically it
 was confusing to toggle the layout after a long period of time,
 because one forgets about what the previous layout was.
 You shouldn't care about the previous layout, it's not a memory game.
 Users change layouts once they need it, then use another layout in
 order to fit their new needs and so forth. Changing the layout is not
 an hard task, i think. I already have some feature i never use but i
 wouldn't make a dwm-lite release. Please add only real useful code :-)

Am I right that you are against re-adding the toggle?

Kind regards,
Anselm



Re: [dwm] OT : suckless foreign function interface

2008-11-18 Thread Anselm R Garbe
Hi Fernan,

2008/11/15 Fernan Bolando [EMAIL PROTECTED]:
 1. Generate small C programs and call them via system() inside the
 scheme interpreter.

 2. Add custom code into the scheme interpreter and link in the lib
 3. Develop some sort of foreign function interface

What about a 9P interface? Here is a scheme implementation:

http://www.ohloh.net/projects/chicken-9p

 If you guys have an example of implementing some sort of suckless
 approach to foreign function that would be cool.

The advantage is, 9P can be used in an universal way, network
transparently and without any platform/language boundaries. The only
tricky part is defining a sane synthetic fs for abstracting the RPCs
you are looking for. However, there are non-Plan9ish examples in the
procfs (might not be the best reference though).

Kind regards,
--Anselm



Re: [dwm] patch to not reparent children to init

2008-11-06 Thread Anselm R Garbe
Hi Neale,

2008/11/6 Neale Pickett [EMAIL PROTECTED]:
 Donald Chai [EMAIL PROTECTED] writes:
 On Tue, Nov 4, 2008 at 9:09 AM, Neale Pickett [EMAIL PROTECTED] wrote:
 Reparenting everything to init with the double-fork is a nightmare on a
 many-user machine, especially when I'm logged in more than once.  pstree
 becomes useless.  This sets up a SIGCHLD handler and only forks once.
 Adds 2 SLOC, but surely there's some reason the double-fork is there that
 I'm just missing...

 If you quit dwm, what happens to any programs that you've launched?

 Nothing, the setsid() call makes children process group leaders so they
 don't receive any of the signals the parent gets.

Well, I remember there was a problem with the SIGCHLD signal handler,
I need to recheck with Stevens tomorrow. It might be that this was on
some ancient UNIX though. But the double-fork is definately the most
portable solution.

Kind regards,
--Anselm



Re: [dwm] patch to not reparent children to init

2008-11-05 Thread Anselm R Garbe
Well, catching all zombies is a tricky task. AFAIK the SIGCHILD
handler on its own is no reliable solution on all systems. There were
several iterations regarding spawn() during the time, most of them
happened at wmii times and the old double-fork() was the most reliable
and simple solution, which was the reason I chose it and keep it.

Kind regards,
Anselm

2008/11/4 Neale Pickett [EMAIL PROTECTED]:
 Reparenting everything to init with the double-fork is a nightmare on a
 many-user machine, especially when I'm logged in more than once.  pstree
 becomes useless.  This sets up a SIGCHLD handler and only forks once.
 Adds 2 SLOC, but surely there's some reason the double-fork is there that
 I'm just missing...

 void
 sigchld(int signal)
 {
  while (0  waitpid(-1, NULL, WNOHANG));
 }

 void
 spawn(const Arg *arg)
 {
  signal(SIGCHLD, sigchld);
  if (fork() == 0) {
if (dpy) close(ConnectionNumber(dpy));
setsid();
execvp(((char **)arg-v)[0], (char **)arg-v);
fprintf(stderr, dwm: execvp %s, ((char **)arg-v)[0]);
perror( failed);
exit(0);
  }
 }



Re: [dwm] make setlayout toggle

2008-11-05 Thread Anselm R Garbe
2008/11/4 Neale Pickett [EMAIL PROTECTED]:
 yy [EMAIL PROTECTED] writes:

 After a quick look, I think the last check in the first if should be
 arg-v != lt[sellt^1]

 Yes, that's what it should have said.  I wonder how it was working for
 me before, when I sent the code to the list.  [cue twilight zone music]

 Here's what it should have said:

 void
 setlayout(const Arg *arg)
 {
  sellt ^= 1;
  if(arg  arg-v  (arg-v != lt[sellt^1]))
lt[sellt] = (Layout *)arg-v;
  if(sel)
arrange();
  else
drawbar();
 }

Ok, are there any concerns making this upstream again? (Yes I know, we
had this already in earlier versions, by that time it was called
togglelayout())... There were reasons for not toggling, basically it
was confusing to toggle the layout after a long period of time,
because one forgets about what the previous layout was.

Kind regards,
--Anselm



Re: [dwm] sswarp page may need an update

2008-11-03 Thread Anselm R Garbe
2008/11/2 Thayer Williams [EMAIL PROTECTED]:
 To the powers that be,

 I just noticed tonight that the swarp page shows some contradictory
 information. Namely, it lists the bin as sswarp and the package
 itself as SSWARP, yet the actual files swarp with a single 's'.

Fixed. However all web pages can be fixed by anyone since we are using
a world-writable hg repository for the wiki contents, see
http://www.suckless.org/wiki.html for details.

Kind regards,
--Anselm



Re: [dwm] Can dwm ignore tray utilities out of the box?

2008-10-25 Thread Anselm R Garbe
You should define some junk tag and tag such clients accordingly in
some rule, then you could avoid binding any keybinding to this junk
tag that you would never see them, except from clicking the tag.

HTH,
Anselm

2008/10/25 Thayer Williams [EMAIL PROTECTED]:
 Alright, so here goes my silly newb post #1...

 Is it possible to run a tray utility, such as trayer or stalonetray,
 and have dwm ignore it completely?  I've tried various tray settings
 and I also found what I thought was a relevant snippet from a recent
 (v5.2) config.h. It mentioned an extended set of Rules, which I
 adopted for trayer:

/* classinstancetitle   tags mask
 isfloating  isignored   isontop*/
{ trayer, NULL,   NULL,   0,True,
True,   True  },

 But this doesn't have the expected effect so I maybe wrong about its 
 intention.

 My main goal is to make it so that trays are not selectable as a
 client--I'd also like the keep the tray on top of the statusbar at all
 times.



Re: [dwm] Getting a List of Installed Applications in System

2008-10-24 Thread Anselm R Garbe
Mod1-p will show all executables in the path.

2008/10/24 Amit Uttamchandani [EMAIL PROTECTED]:
 Hey guys,

 I recently introduced my friend to DWM. He was using KDE before that.
 He was very happy and surprised about the speed of DWM. Now, the
 question he had was is there some sort of application menu that lists
 all the installed apps? Like the kicker for KDE or its similar
 GNOME/Fluxbox counterpart?

 I did not have an answer for him...I did a search on aptitude but the
 only thing I found was the debian 'menu' package but I am not sure how
 to use that.

 Any ideas?

--Anselm



Re: [dwm] Terminals retain size of stack

2008-10-15 Thread Anselm R Garbe
2008/10/15 Tinou [EMAIL PROTECTED]:
 Could this have something to do with gvim not getting proper size at
 launch ? (wrong number of lines: about 2 or 3 less than expected,
 until resize)
 I'm out of guesses on this issue: tried with and without resizehints
 (made a small function to toggle that btw), different versions of
 gvim, with and without any config, newer versions of gtk, xorg, nvidia
 driver... but I'm currently using a 2.6.22 kernel (the 2.6.25 made
 hiccups in mpd playback, don't know why)

AFAIR there are some known issues with configure request handling in gvim.

Kind regards,
Anselm



Re: [dwm] Re: Patch: pertag for dwm-5.2

2008-10-15 Thread Anselm R Garbe
2008/10/15 v4hn [EMAIL PROTECTED]:
 Ev'ning,

 On Sun, Sep 14, 2008 at 05:34:08PM +0200, Fredrik Ternerot wrote:
 Updated to also support toggle layout per tag.

 /Fredrik


 On 9/13/08, Fredrik Ternerot [EMAIL PROTECTED] wrote:
  Updated pertag patch for dwm-5.2.
 

 Could someone please upload/link this patch on the website?
 Actually the provided link is dead.
 /* http://www.suckless.org/dwm/patches/dwm-5.2-pertag.diff */


Just add this patch to the wiki repository. It's world-writable. See
http://www.suckless.org/wiki.html for details. Make sure the file has
the .diff extension.

Kind regards,
Anselm



Re: [dwm] Floating children

2008-09-29 Thread Anselm R Garbe
2008/9/28 Carlos Pita [EMAIL PROTECTED]:
 as I'm no expert I would like to ask you about the possibility of
 opening clients that are children of a floating one as floating
 themselves, disregarding the current layout.

If these clients set the TRANSIENT_FOR hint to reflect they are
relatives to some kind of main window, this will work out of the box.
Otherwise not. You can ask the developers of these apps to set the
TRANSIENT_FOR flag on these windows.

 For example fluid, the gui designer for fltk, which follows the gimp
 and gaim ugly paradigm of presenting a number of floating windows. I
 can add a rule for floating its main window, based on its class. But
 the child windows has no class or instance properties that can be
 ruled as floating, and the titles are unmatcheable without regexp
 support, so I need to manually move them to the floating state (and
 there is no fixed set of windows, new ones are always popping up
 during the work session). Even worst, if the current layout is, say,
 monocle, they are automatically maximized, so I need to resize them
 every time too. Of course, I could change the layout to floating each
 time I enter fluid's tag, but then I also need to remember to revert
 to monocle -my default mode- upon tag exit. As you can see, there is
 a lot of manual, fallible, work involved.

Sounds like the app you are using is broken in many regards, bug the
developers of this app. The changes they need to do are really simple,
just setting some proper hints on the windows will do the trick.

 I'm a bit reluctant to patch dwm pertag just for this. I think it's
 more sensible to make floating client's children recursively floating.

The problem is, that the children windows you are referring to are no
child windows in the sense of X, they are only child windows from a
semantical point of view of the application itself.

 What do you think? Can you help me implement this, if it's possible at
 all? (I'm not even sure whether X has a notion of parent-child
 relationship between clients or not)

Usually this relationship is reflected by using the TRANSIENT_FOR hint instead.

Kind regards,
--Anselm



Re: [dwm] Re: font problem

2008-09-21 Thread Anselm R Garbe
Try using xfontsel to see if there is a problem with the terminus package.

Also let us know what your actual LC_* vars look like, e.g.

; env | grep LC

Kind regards,
Anselm

2008/9/21 Max Fischer [EMAIL PROTECTED]:
 On Sun, Sep 21, 2008 at 02:06:06AM +0200, Marcin Cieslak wrote:
 Max Fischer wrote:
 hi, i've lately some problems with using the terminus font. dwm responses
 missing font: ISO8859-1. terminus font is working in terminals etc.
 and many other fonts are working with dwm, too. I don't get what's
 wrong, my locale seems ok to me
 http://pastie.org/276377

 That does not explain anything.

 What is your font specification in the config.h?

 Mine is (for example):

 static const char font[] =
 -*-terminus-medium-r-normal-*-12-*-*-*-*-*-iso10646-*;

 (this is wrapped, it's one line).

 Make sure that there are no unwanted spaces in the specification.

 --m




 I've tried several specifications, at least 
 -*-terminus-medium-r-normal-*-12-*-*-*-*-*-*-*.
 Your spec. did it neither.





-- 
--Anselm



  1   2   3   4   5   6   7   8   9   >