On Mon, May 05, 2008 at 09:06:54PM +0200, Antoni Grzymala wrote:
I've found running separate dwm instances on subdisplays entirely
sufficient for my multihead needs. I don't even have time and will to
try and comprehend all the new DEFGEOM stuff (and neither I see a
Hence I vote -1
On Thu, Jul 10, 2008 at 06:35:03PM +0300, John Mpanos wrote:
After some digging around i figured what to do to draw text in the
status area, so i wrote a simple clock using threads. I can't
understand though why the clock doesn't get updated sometimes even
though i call drawbar()
This keeps its userbase small and elitist. No novices asking stupid
i wholeheartedly support these words.
Please discuss about removing, or altering that.
The reason is, that I met people who thought, that the dwm-/suckless-
community is arrogant. They
We are publishing a software for the masses: we make it available and
have a website for it, a mailing list, a wiki, and a mercurial
There is nothing elitist about that.
The fact that we have to modify the source to customise the product is
IMHO, you're staggeringly wrong,
I would like to propose adding xft support and gnome systray support to dwm.
And also sound effects.
Neat idea. Also, someone could write a config editor that patched the
binary (like what Dehacked did to the old DOS DOOM).
Just because I'm curious: Am I the only one using readline (shell, etc.)
with Emacs key bindings and am therefore always remapping/deleting some
default dwm key bindings?
Or is everyone using readline in vi mode?
we're using Mod4 as modkey.
On Thu, Jul 31, 2008 at 01:37:22PM +0200, pancake wrote:
I wrote a random list of tips for coding (mostly in C)
If you have some ideas/missing tips i'm open for discussion :)
I mostly agree with everything, except with your bizarre anger against
A while ago there was some talk about making the wiki available in
I made a quick mockup: gopher://schot.a-eskwadraat.nl/1/suckless
The idea is pretty simple: No conversion to html and embed the index.md page
the gophermenu (yes, 'i' itemtype abuse).
On Fri, Sep 05, 2008 at 10:28:28AM +0100, Anselm R Garbe wrote:
What do people think about such an EEE PC as low budget option to run
dwm on? Any experiences already if the screen is big enough for daily
work? I had an opportunity yesterday to try one, and I must admit I'm
let's say that I have a number of floating windows running complicated
OpenGL applications. When I move them around (by mod+mouse1 drag),
moving the window each step takes some time. This time is larger than
the frequency at which dwm gets mousemotions, thus the movement lags
Actually, I quite like the old styled XOR-outline method. I may not be
as pretty, but it's definitely useful for various applications that take
ages to resize their windows.
I also like the XOR outline. I even think it's prettier ;)
My display looked like a farmland some time ago. I just had key
bindings in dwm to open xterms with a given background color in a
given screen window.
It looked like this:
This is the most horrifying thing I have ever seen.
I really need the redraw to manage gimp windows, sometimes I just have
to see what they are doing to know the size I want, I have the same
problem with image viewers, openoffice, etc, but if the server grab
solution is simpler I won't matter maintaining a patch for that, maybe
1. Generate small C programs and call them via system() inside the
well, if speed is a non-issue...
how about dlopen/dlsym? that's pretty simple and rather usual. Callable
C functions should export a standard API (like the builtins in your
option which allows to set use server grabs during mouse based
now i'm using a computer where this is again an issue, except much more
so, and not only with GL windows (big shared framebuffer mode with intel
945gm). I tried hacking server grabs into dwm 5.2 myself
On Wed, Dec 10, 2008 at 06:05:23PM +0100, Johannes Wegener wrote:
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
On Wed, Dec 10, 2008 at 05:37:14PM +, Anselm R Garbe wrote:
2008/12/10 Johannes Wegener [EMAIL PROTECTED]:
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
could just drag
On Wed, Dec 10, 2008 at 06:36:12PM +, Anselm R Garbe wrote:
The lesson I learnt from this: I will never buy a laptop with integrated
intel graphics again.
Which laptop model is to blame? ;)
Lenovo 3000 V100. Especially painful is that otherwise I love this one
- great keyboard, good
On Thu, Dec 11, 2008 at 09:39:19AM +0100, yy wrote:
on this list and, if somebody finds a great _general_ solution (which
seems difficult, but I would be love to be wrong), I'm sure Anselm
would be glad to include it in the official release.
Just my 2cts,
I don't see anything difficult
On Thu, Dec 11, 2008 at 09:52:45AM +, Anselm R Garbe wrote:
- 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
On Fri, Dec 12, 2008 at 07:15:55PM +, Anselm R Garbe wrote:
here is the plan:
slock-1.1 will be released soon containing Ali's patch with some minor
dwm-5.4 will also be released soon containing the transition patch
with the proposed x property based status
The website lists clarity as a feature. Clarity!
As for only having to learn C code to edit the config, I know C
reasonably well, but I get bad vibes from config.h, I think I'd rather
try to learn Lua.
do consider the alternatives - xmonad is a smashing tiling wm (using it
now for its
On Tue, Feb 24, 2009 at 02:05:21PM -0500, Jeremy Jay wrote:
If you want to avoid the compile I'm sure it'd be
just as easy to use a hex-editor on the strings.
we should write something like Dehacked for dwm :D
Window Manager = xmonad (for working twinview support)
Shell = zsh and bash (zsh is good but oh so slow...)
File Manager = shell/mc
Text Editor = vim
Calendar / Todo = nothing/cal/text files in svn
File search = locate/find/grep/ctags!!
SCM = svn
E-Mail = mutt
Music = mocp
Chat = irssi bitlbee
Just tried, does not help.
in fact, this problem appears with xmonad as well, so it's probably
generic to all tiling wms; tiling wms are Doing It Wrong - probably
according to the text of the standards, but many apps don't respect
If Java doesn't work because it's a buggy POS,
I'm sure there is a severe risk of this piece being understood as
flamebait (this is not my intention).
However, I strongly believe that the major problem of dwm currently is
not font handling (8bit ascii bitmap fonts are perfectly fine thank
you); not the status bar (it's great);
...that's from dwm 5.4.1, using xrandr --output DVI-0 --right-of
DVI-1. Problem solved.
well obviously i had something more sophisticated in mind :)
like, horribile dictu, displaying different tags or different layouts
on different monitors. or supporting more monitors than 2...
I cannot understand GNU software. ls or cat source in GNU is scary,
glibc is even worse. The old UNIX utilities or Plan9 ones have a
simplicity which GNU lacks. I don't have anything against the GPL
license, but I prefer less restrictive licenses. And, of course, I
don't like rms.
Using a prefork or similar technique done by apache f.ex can really
accelerate such tasks, so a minimal vi editor with nice features can be
really achieved by delegating all such features to external apps or
a minimal application with a dozen external modules,
Mail list logo