Re: [dwm] Re: New mailing list

2009-05-20 Thread yy
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.

-- 
- yiyus || JGL .



Re: [dwm] musca wm

2009-05-15 Thread yy
2009/5/15 pancake panc...@youterm.com:
 A friend of me is writing a pkgsystem that builds everything inside a chroot
 and allows to create a full usable distribution, the pkgsystem itself is not
 yet finished, but is pretty fast , written in C and shellscript and I really
 think it is a good project. But actually it is a single-man project. We can
 use this project as a tool to build the base system.

 http://repo.or.cz/w/xbps.git/

 Actually i'm happy with arch linux, but, i really miss a non-gnu linux and
 minimalistic distribution. We should get a look on alternatives for glibc
 (google one? uclibc? ..) but maybe the biggest rock we will face it will be
 the X server...this is probably one of the interesting projects to work on,
 but without keeping the X compatibility. (just as an emulation layer) X11 is
 bloat. (as we have already discussed, we can reuse the drivers of xorg) but
 designing a better and simpler API. But this is probably a long topic to
 talk about, and we're of course not the first ones to claim for an X11
 replacement.

 --pancake


I'd like to agree with you, and I would be glad to help in such an
effort, but it would not give me any real benefit. There is a suckless
alternative to GNU: Plan9. If I still run (arch)linux is because I
often need things like a full featured web browser, pdflatex, the
gimp, or ardour, for example, so I will need all the gnu-x-crap
anyway. The same thing happens with that pkgsystem: it looks good, but
what I really need from a pkgsystem is pre-packaged software, IMO
compatibility with pacman (or any other widely used pm) would be
better. But if you - or anybody else - go for it, every iniciative to
remove GNU from the world has my vote. I have also listened good
things about http://www.tinycorelinux.com, but have not tried the real
thing myself.


-- 
- yiyus || JGL .



Re: [dwm] musca wm

2009-05-15 Thread yy
2009/5/15 Leandro Chescotta lchesco...@banelco.com.ar:
 2009/5/15 yy  yiyu@gmail.com :
 There is a suckless alternative to GNU: Plan9.

 I don't know that, there are apps under Plan9 like GNU? Why make it suckless 
 comparative to GNU?


In the sense that GNU aims to be a similar to UNIX operating system,
but not UNIX, it is almost the same thing than Plan9. But now I was
talking about glibc and the GNU tools, you could read
http://harmful.cat-v.org/cat-v/ to get the idea, or some info pages.

 every initiative to remove GNU from the world has my vote. I have also 
 listened good things about http://www.tinycorelinux.com, but have not tried 
 the real thing myself.

 Why you don't like GNU? I only ask because I don't know, I only want to know 
 what's wrong with it, I only use it, and thinked it was great, I mean, I love 
 open source software, but I really don't know the license thing


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.


-- 
- yiyus || JGL .



Re: [dwm] dwm's future

2009-04-27 Thread yy
2009/4/27 Matthias-Christian Ott o...@mirix.org:
 At least you didn't loose your dignity, carried out your principles and
 proofed that Free Software is as powerful as an expensive proprietary 
 software.


But it is not always possible. I can give you a (quite long) list of
software that doesn't have a free equivalent. Between other things, my
work involves a lot of mechanical testing, and even if developing your
own easy solution would be straightforward you have to use the
nonsense 1gb of ram proprietary (and usually windows) application
because it is the industry standard.
The argument about free software is a non-end disucssion. The matter
is: there are broken applications, do we want to use dwm to manage
their windows? I would prefer keeping it as suckless as possible, as
somebody else suggested. dwm makes a great job managing windows, it is
not its job to fix font handling or work around broken applications.
However, I liked the idea of a suckless font library, but it will
have to suck a lot (i.e. include pango) to work perfectly with every
language on earth.


-- 
- yiyus || JGL .



Re: [dwm] dwm's future

2009-04-26 Thread yy
You could add an option to print the window title to stdout. This way
if somebody wants to pipe it to an external program to show window
titles (like dzen on top of the dwm bar), they can.


-- 
- yiyus || JGL .



Re: [dwm] [idea] mwm - minimal/minimun/monocle window manager

2009-04-26 Thread yy
2009/4/26 Leandro Chescotta leandro.chesco...@gmail.com:
 - no tags, only a list of opened windows, that you can cycle with one
 keybinding or Alt+number
 - no bottom bar, just the window list that you can show/hide
 - no layouts, only a monocle-like one, and a floating layer for
 mplayer/feh/gimp
 - lol, an arch linux AUR package with the config.h ready to customize the
 few font/colors/keybindings/apps


you could just run dwm without the bar, with only one tag, and with
only the monocle layout.


-- 
- yiyus || JGL .



Re: [dwm] Low Power Fanless Computer

2009-04-25 Thread yy
While I really like Asus products (I'm very happy with my eee), maybe
the msi catalog is also worth a look. Both windbox and windnettop look
like interesting fanless desktop replacements in the same line than
the eeebox.
If you want to have your own server the idea of accompanying one of
these devices with plug computers and/or some cheap NAS looks funny,
but given the current price of VPS I don't think home-servers are well
worth any more.

PS[OT]: you would not get rich this way, but I would buy such a thing
for a reasonable price: 1. find the right (cheap) plug computers to
run plan9 cpu servers, the right nas device to run venti, and the
right eee/wind/whichever terminal. 2. preconfigure everything and
package it in a cute box. 3. sell it. 4. profit! 5. goto 1


-- 
- yiyus || JGL .



Re: [dwm] key bindings

2009-04-03 Thread yy
2009/4/4 Steven Blatchford dollarsign...@gmail.com:
 A few months ago I tried yiylus's idea of workspaces to cut down on
 the keystrokes when pulling in other apps (eg modkey+1 modkey+ctrl+2).
 Now, since I rarely use XK_{1,2,3...9} I thought of moving those to the
 function keys thus freeing up XK_{1,2,3...9}.


(I had to check the ml archives, because I didn't remember it, and
then I see I even wrote a wiki page about it... My memory is getting
worse every day)

 How would one bind XK_1 to 'C-a 1'?  I'm hoping this will select a
 screen buffer for the terminal which has the focus.


Wouldn't it be much easier configuring screen?


-- 
- yiyus || JGL .



Re: [dwm] Wiki date format

2009-03-11 Thread yy
2009/3/11 markus schnalke mei...@marmaro.de:

 /mm/dd is not worst but still worse than -mm-dd.

 The latter one is a standard, and it is usable in filenames.

 Think about it.


I'm thinking about it, but really, if slashes are not the standard FS
in dates we are probably living in different worlds. OTOH, a
/mm/dd structure is convenient to organize months and years in a
tree structure, i.e. directories (as God intended when he created
time).


-- 
- yiyus || JGL .



Re: [dwm] [PATCH] remove sizehints argument in resize()

2009-03-02 Thread yy
2009/3/2 Enno Boland (Gottox) got...@gmail.com:

 I wrote a patch which removes the last argument from resize(). This is
 handled now directly in applysizehints(). What do you think about it?


I love this patch. It looks like the right thing.


-- 
- yiyus || JGL .



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

2009-02-28 Thread yy
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-

What do you mean by maximizing a work screen?


-- 


- yiyus || JGL .



Re: [dwm] Google Summer of Code 2009

2009-02-21 Thread yy
Great news :)
I would love to take part on this. I'm PhD student and was thinking
about some Plan9 related project, if the suckless project will also be
a mentoring organization maybe there is some good project involving
both things which could be done (I remember a Plan9 port of dwm -
mentored by Anselm - was a propossed idea in the Plan9 GSoC wiki last
year, for example).
Other vague ideas I have could be something st/libgt related (see my
wheel designs post, I'm really willing to put my hands on this) or
some work to try to fit better plan9port/9vx/inferno with X: I would
like to use plan9/inferno applications in a more transparent way, now
I have the feel of running it inside a box, this is an idea that has
crossed my mind some times: write a rio substitute which multiplexes
/dev/draw to different x windows (clients), modify acme to use
separate windows too, and use dwm/wmii to control everything. It
sounds complicated, but it would just be a matter of moving code from
one place to another, something in these lines should be doable.
Of course, these are just some rough ideas, and I am open to any
suggestion from possible mentors. Though I would apply as a student,
if you need any help to prepare the application as mentoring
organization, just drop me a line, maybe I could help. BTW, I think it
would be interesting to add to the wiki page the candidates to
mentors/students.

I hope we can find some good projects to work on. Regards,

-- 


- yiyus || JGL .



[dwm] [OT] Wheel designs

2009-02-19 Thread yy
I find your current discussion very relevant to what I'm doing with
dio[1] now. It would really be great to share ideas and, eventually,
join efforts.
I will try to explain the different ideas I had with dio development,
it's a long history.

This is what I have now:
The main idea behind dio was a very simple player of items which could
be used for music and video. I took dmenu and extensively modified it
to display items in scrollable windows and manage button events,
depending on the command line options different actions are done when
items are clicked, added, etc. Several bash scripts run dio in
different ways:
The player reads its items from stdin, displays them and launch child
proccess to actually play the file.
A directory browser is done redirecting ls output to dio stdin and
relaunching itself when directories are selected. It is convenient to
add files to the player.
Keyboard input was already supported from dmenu, it allows to search
for items. Giving the option to redirect this input to stdout added
the possibility to turn dio into a very basic terminal emulator. I
never implemented a ptty or anything, it just redirected a shell
stdin/out, but it was pretty usable with simple programs like dc or
sic. Smaller applications like the calendar or terminal history were
straightforward.

In its current state, dio has been a test bed for ui ideas, but its
implementation lacks any kind of design, it just came up like this. In
particular, the idea of turning command line arguments into a new
language sounded like some kind of aberration to me. So, I started to
think in how to rewrite dio from scratch.

The most difficult decission is where you want to put the line of what
it will do and what you will leave to the applications. I thought in
several possibilities:
1. Make dio simpler, so that it just displays input and sends output
(events are sent as output too). In some way, this is in the path of
what Matthias is proposing. All the logic of the player, for example,
would be done by external programs and would tell dio that how to
represent the list. The problem here is that you would have to kept
two different lists of items, and process management can be tricky.
Some kind of language for communication would be needed. All the
simplicity would be gone.
2. Turn dio into a library and have different applications (which make
use of popen()) instead of scripts. It has the advantage you don't
need any new language. It could even be the right approach, in fact
the biggest problem I found with it was that libgt seemed to me like
something similar from the few informantion we have and I was waiting
to se what it exactly was.
3. Develope a small language similar to awk (a subset of) and add to
it special patterns and fields to manage events and make some
formating (bg color, fg color and maybe bold font, no more) and turn
dio into an interpreter. I don't have any strong fundation to suggest
this, new languages should be added only when they are really needed,
but I have been looking at yacc and lex documentation these last days
and, dude, it would be so funny...
4. Rewrite everything in the acme way. The idea to give dio more text
editing capabilities crosses my mind from time to time. acme is almost
perfect as an user interface for me, but it is an user interface for
programmers and when it comes to play music for example and all those
desktop tasks it just isn't the right tool. I have grasped the code
and I have to admit is too much for me, although it is a great  way to
learn I'm not the right person to improve Pike's work, it is out of my
possibilities.

I started to rewrite dio from scatch and what I have now is a small
program that displays its stdin in a scrollable window and prints to
stdout the clicked items on the form Button3 Item 1. Just that, no
more, but everything can be done from there.

As you see, this is a total rambling, but I really think we could have
something here, your ideas also look very interesting to me, and every
comment will be appreciated.

Nacht,


[1] http://code.google.com/p/dynamic-io/

-- 


- yiyus || JGL .



Re: [dwm] dmenu - how to autoconfirm selection in case of exact match?

2009-02-17 Thread yy
2009/2/16 Jeremy Jay dinkuma...@gmail.com:
 OP doesn't want to hit enter every time, dmenu won't return unless you
 do, so a patch is necessary...

 Jeremy

 On Mon 16 Feb 2009 - 07:32PM, yy wrote:
 Another option, if you don't want to patch, is to add those letters to
 dmenu input (with simples echoes in dmenu_path, or even processing an
 aliases file). Personally, I don't use dmenu_path, I just have a list
 with no more than 10 items so I can launch everything with only one or
 two letters.

 hth,

 --

Yes, you're right, my apologies. I misread the question and didn't
even look at the patch. I thought his problem was that dmenu was
selecting an item instead of his input. Sorry for the noise.



-- 


- yiyus || JGL .



Re: [dwm] floating rule when only WM_NAME defined?

2009-02-16 Thread yy
2009/2/16 Adam adam.listm...@gmail.com:
 WM_NAME property should be the title
 is that window have any title? (check the status bar)

 yes, GREG is also the title in the status bar. I thought that:

{ NULL,   NULL,   GREG,  0,True },

 would be the proper way to make it float, but this does not work.



Your problem probably is that the title is set once the rules have
been applied by dwm. IMO you will have to call applyrules() manually
(or you could call it in every arrangement, for example).


-- 


- yiyus || JGL .



Re: [dwm] dmenu - how to autoconfirm selection in case of exact match?

2009-02-16 Thread yy
Another option, if you don't want to patch, is to add those letters to
dmenu input (with simples echoes in dmenu_path, or even processing an
aliases file). Personally, I don't use dmenu_path, I just have a list
with no more than 10 items so I can launch everything with only one or
two letters.

hth,

-- 


- yiyus || JGL .



Re: [dwm] Layers

2009-01-22 Thread yy
I use the floating layout just for this. I have hacked dwm in several
ways in the past: keys to raise clients*, different stack algorithms
(in the lt structure), and what not. At the end, in the case I want to
bring front a tiled client the easiest way is to change to floating
layout**, no complications are necesary and it makes quite sense to
me.

* I think they are named clients because a client can have several
windows (reparenting; eg if you have window decorations). Another good
reason is the confusing it would result to mix that Window with the
Window already present in dwm _code_ (they are called windows in the
man page, for example).

** In order to make this task easier, I have defined my keys and mouse
in a way that a Mod+Space (or B1 on the symbol) set tile or (if tile
is set) floating and Mod+Shift+Space (or B2) set monocle or floating
in the same way. So, with a double Mod+Space - or Mod+Shift+Space, or
double clicks - I can re-tile tiled clients while in floating layout.
(It doesn't sound so great as the feeling is once you get used to it.)

hth,


-- 


- yiyus || JGL .



Re: [dwm] What happened here?

2009-01-20 Thread yy
2009/1/20 andrew alindb...@gmail.com:
 I've spent a lot of time with awesome in the past months, since it
 had, at the time, a sensible tiling system and some of the features I
 wanted that dwm lacked. Unfortunately, with the progression to the
 latest major revision, lua integration has ruined its usability. And
 so I came back to poke around at the dwm project and see if it had
 progressed into something usable for me.

 All I can say is: Yikes.

 Specify commands as a list of argument strings?

This isn't any weird trick. Have a look at exec(3).

 I don't even recognize the key array as C code  ... {.v = dmenucmd} },
 ...   (??)

It is C code. Not less recognizable than any config file parser.

 Tagmasks? Why are we forcing the user to do this in binary?


I would argue about other global booleans moved to a bit mask, but
tags... c'mon! They are a bit mask! Having an array of booleans for
this seems wrong. If the user has any problem with bit operations in C
the wikipedia page about it is quite enlightening. I don't think any
user capable of compiling dwm will have any problem to add or remove
tags, IMO looking at config.def.h the operation is straightforward,
even if you don't understand what you are doing. I think if you search
for it you can find macros in this list to not having to touch bit
masks at all.

 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.

 I understand that a core tenet of the suckless development is
 efficiency.. but it seems to me that at some point between 3.x and 5.3
 this usurped usability in its entirety. The concept of the header
 file is the config file has appeared to outlive it's sensibility.
 Let's face it, a C header was never meant to be a scalable
 configuration file for something as flexible as a tagging, tiling
 window manager.

 Anyway. I don't mean to start a huge fuss, just wanted to make an
 observation as a previous user, and maybe encourage taking a step back
 and looking at the sensibility of how the whole program hangs together
 now, for the user. Because, to me, dwm was primarily about getting the
 window manager out of my way, but looking at the most recent config.h,
 I can tell it won't fit that bill for me anymore.


Really, I don't think making the usual changes to config.h (setting
your rules, tags, keys and buttons) would have taken you longer than
writing this email.
Regarding efficiency, I don't think that was the reason for any of
these changes. I would tell it was simplicity of the code (for
reference, have a look at the example in
http://www.scklss.org/common/index.html). I don't think config.h is
any more complicated now, if you tell any specific problem you found
I'm sure somebody in this list will be glad to help you.

 Sadly going back to the tiling wm dole,


Good luck!

 Andrew





-- 


- yiyus || JGL .



Re: [dwm] Re: What happened here?

2009-01-20 Thread yy
2009/1/20 hiro 23h...@googlemail.com:
[snip]
 Still, dwm somehow seems very much not unix alike for me.


Well, X doesn't look like UNIX neither, however you look at it.



-- 


- yiyus || JGL .



Re: [dwm] how to float all gui programs

2009-01-09 Thread yy
2009/1/9 Szabolcs Nagy nszabo...@gmail.com:
 On 1/9/09, bill lam cbill@gmail.com wrote:
 On Fri, 09 Jan 2009, markus schnalke wrote:
 Make floating the default and add rules for your terminal emulators.

 Thank markus, I patched dwm as per your suggestion and it now works

 use {0,0,0,0,True} as first rule in config.h, editing dwm.c is not
 necessary for this



But with current tip doing this won't let you to tag clients with
rules to a specific tags (because every client will be tagged to the
current tagset, though you can do an OR with them) as discussed in
http://lists.suckless.org/dwm/0812/7057.html , Anselm told in the same
thread he didn't worry too much about that corner case and, in fact,
nobody complained. It looks like things are different now.
If there is interest in both features maybe negative numbers could be
used in the rules definition and applyrules() for current visible or
no tags. Anyway, hardcoding in dwm.c what to do with new clients is
straightforward.

-- 


- yiyus || JGL .



Re: [dwm] dio-0.1.3

2009-01-05 Thread yy
2009/1/5 Anselm R Garbe garb...@gmail.com:
 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


I'm glad to hear that. Since I'm also semi-moving too, dio development
is stalled ATM (I was on holidays in Spain, but will be back in
Belgium the day after tomorrow). So, I will wait to see what Anselm
comes with and maybe we can join efforts or re-use some code.

PS: I suppossed that it was possible that both projects were related,
but probably Anselm code will be better so...


-- 


- yiyus || JGL .



[dwm] dio-0.1.3

2009-01-02 Thread yy
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).
Probably the next step will be a complete rewrite, which could use
libixp and the plan9port plumber, with several simplifications (and,
maybe, completely different).

I have set up a project page on google:
http://code.google.com/p/dynamic-io/ so, no more announcements will be
done on this list.
If you are curious, a screenshot featuring dwm and several dio
applications (terminal, calendar, rpn calculator, irc client, text
viewer, file browser and music player) is available at:
http://y-i-y-u-s.deviantart.com/art/dio-0-1-3-108171356

Don't expect the terminal to replace uxterm, it just wraps rc
stdin/out, but doesn't understand escape sequences. I'm using on a
daily basis the rpn calculator, the irc client, the file browser and
the music player: it fails from time to time, but is usable.

Any comments by private email or the google page will be welcomed.
Kind regards,

-- 


- yiyus || JGL .



Re: [dwm] dio-0.1.3

2009-01-02 Thread yy
2009/1/2 Christoph Lohmann 2...@r-36.net:

 You are recreating acme(1) with less features.


Maybe, acme is probably the user interface which has inspired me more
in the last years. OTOH, using acme (or libframe, I don't know very
much about the internals) would probably be the right way to implement
these artifacts. I would give it a try if it was possible to open acme
windows in different X windows.
Anyway, I do this only for fun (and because I wanted a simple mp3
player), and replacing acme is out of my scope. dio is much more
modest software than acme and, in simple words, much worse. It is only
a toy, to experiment with my (sometimes stupid) ideas.


-- 


- yiyus || JGL .



Re: [dwm] Border hater, border lover

2008-12-17 Thread yy
2008/12/17 Anselm R Garbe garb...@gmail.com:
 It's in. Please recheck if there are any issues. Otherwise I'm going
 to release 5.4 tomorrow.


Two things (of not too much importance, anyway):

1. What about the applyrules modification discussed in
http://lists.suckless.org/dwm/0812/7057.html ?
2. IMO the issingle variable name in adjustborder() should be changed,
e.g. to hasborder.

I will elaborate on #2: I'm using a modified monocle where the border
is removed when the status bar is not visible, so that I have some
kind of fullscreen layout (very useful for firefox video windows from
some sites). When I have seen this new function I thought that it
would perfectly fit in this function (maybe it could even go into
main? I think it will be just one more line), but issingle doesn't
make too much sense then.

Anyway, as I told, nothing important...


-- 


- yiyus || JGL .



Re: [dwm] Border hater, border lover

2008-12-17 Thread yy
2008/12/17 yy yiyu@gmail.com:
 2008/12/17 Anselm R Garbe garb...@gmail.com:
 It's in. Please recheck if there are any issues. Otherwise I'm going
 to release 5.4 tomorrow.


 Two things (of not too much importance, anyway):

 1. What about the applyrules modification discussed in
 http://lists.suckless.org/dwm/0812/7057.html ?
 2. IMO the issingle variable name in adjustborder() should be changed,
 e.g. to hasborder.

 I will elaborate on #2: I'm using a modified monocle where the border
 is removed when the status bar is not visible, so that I have some
 kind of fullscreen layout (very useful for firefox video windows from
 some sites). When I have seen this new function I thought that it
 would perfectly fit in this function (maybe it could even go into
 main? I think it will be just one more line), but issingle doesn't
 make too much sense then.

 Anyway, as I told, nothing important...


 --


 - yiyus || JGL .


I have just realized it wouldn't need a single line of code to remove
the border in fullscreen layout (i.e.: monocle + !showbar). Inside
monocle, doesn't
adjustborder(c, n == 1 || !showbar)
make sense to you?

Maybe you could also have a new define in config.h, so people can choose:
#define MONOCLEBORDER n == 1
#define MONOCLEBORDER n == 1 || !showbar
#define MONOCLEBORDER True
Anyway, having borders in monocle is probably a matter of taste, but
it is so easy adding your own layout that I doubt it is even a
matter...


PS: I will stop rambling now and will wait for tomorrow release. Good night!

-- 


- yiyus || JGL .



Re: [dwm] dwm and dualhead

2008-12-11 Thread yy
The problem with xinerama is that no general implementation is
possible. You can have a tile algorithm for both screens or two
different ones, you can share tags or they can be different, it could
be possible for the user to move windows between screens or not, etc.
And what do you do with the status bar? two different bars, just one
bar in one screen, or an special bar which for example has tags, tile
symbol and window title in one screen and use the other one for status
text? This lack of generality is a good reason to drop xinerama from
dwm at first.
It actually is quite easy to get screens info with very few
modifications to updategeom() and then work on your own implementation
from there. In an ideal world, some good patches would have appeared
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,


-- 


- yiyus || JGL .



Re: [dwm] dwm and dualhead

2008-12-11 Thread yy
2008/12/11 Mate Nagy [EMAIL PROTECTED]:
 Hiho,
 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 about this. In fact, awesome generally
 gets this right. This is what I want from dwm:

  - handle each xrandr screen separately
including all data structures, so different layout, client set,
tagging, etc.

You could have a tile algorithm for two screens, where you have the
zoomed client in one of them and the stack in the other screen
arranged in a grid layout, for example; or something similar to tile
in one screen and two more columns of stack on the other one, the
possibilities are endless. And if you want to completely change your
whole workspace with tagging having to set tags in both screens
would be a pain.

  - draw statusbar everywhere (from the same input text)

I don't understand why you would want the same status text in two
adjacent screens.

  - have a key-bindable function for:
- changing between screens

just warp the pointer to the client.

- move window to another screen

which could simply be done by having different tags in both screens,
something like 1.1 1.2 2.1 2.2 etc.

  - do something semi-intelligent when a screen with clients goes away,
e.g. put clients in previous/next screen oslt.

  Basically, it should behave as multiple separate dwms, except that
 clients can be sent from screen to screen and all dwms have the same
 configuration.


This is an use-case, but I don't see it like a general approach.
Having said this, I don't think it would be difficult to implement, as
far as I can remember dwm did something similar at some point and it
wasn't satisfactory to everybody, but it can definitively be done and,
if everybody (using dual-head, my opinion doesn't count) agrees this
is the perfect behavior, it should be included in main, IMO.


-- 


- yiyus || JGL .



Re: [dwm] dwm and dualhead

2008-12-11 Thread yy
What about moving XineramaScreenInfo *info = NULL; out of
updategeom()? if you make info a global variable it is easy for people
to have custom tile algorithms which make use of it. If you also
define custom functions to view tags, change layouts, etc you will be
able to have plenty of different xinerama configurations without
messing up with dwm.c. People could easily add their custom dual.c
files. You wouldn't be possible to achieve all of the different
configurations which were mentioned in this thread, but I think you
could get most of them.
Just an idea...


-- 


- yiyus || JGL .



Re: [dwm] xprop patch

2008-12-10 Thread yy
2008/12/9 Anselm R Garbe [EMAIL PROTECTED]:
 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.


I have the same opinion. Now that I see the patch it looks so clear
that I also vote for its inclusion in main. I was completely wrong
about this, my apologies to Mr.Pickett ;)



-- 


- yiyus || JGL .



Re: [dwm] dwm-5.3

2008-12-09 Thread yy
2008/12/9 Szabolcs Nagy [EMAIL PROTECTED]:
 On 12/8/08, Neale Pickett [EMAIL PROTECTED] wrote:
 I sort of like the idea of using X properties.  You could use xprop to

 one of the most ununixy interfaces

 man XGetWindowProperty



I agree 100%. The idea of X properties can seem appealing at first,
but it is a pain to use them. I really doubt you can remove loc with
it. Anyway, I feel curiosity for a patch in this direction, it could
be good to have it for reference, to compare. If you don't try, you'll
never know for sure.



-- 


- yiyus || JGL .



Re: [dwm] DWM 5.3.1 and Xinerama

2008-12-07 Thread yy
2008/12/7 Donald Chai [EMAIL PROTECTED]:

 BTW, restarting X is not necessary: the *whole purpose* of Xrandr is to
 avoid doing this.  Just plug in your external display and run xrandr
 --output VGA --auto or whatever your external display is called.  dwm is
 already set up to receive configure events, and will do The Right Thing.



I have a projector at home (best thing for movies since dolby and they
are cheaper every day) and this is basicly what I do. I just mirror
the screen in the laptop and the proyector and close the laptop,
actually that's one of the reasons I control everything in dwm with
the mouse. But you don't have to worry about xinerama or xandr, dwm
will adapt to the new situation because the root window will be
resized if resolution changes. If you want to do something fancier
than duplicating the screen that's another question.


-- 


- yiyus || JGL .



[dwm] applyrules()

2008-12-06 Thread yy
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 .


applyrules.diff
Description: Binary data


Re: [dwm] Re: urgent windows border

2008-12-06 Thread yy
There is little error here. It is not working as expected in 5.3.1.
This patch fixes it.


-- 


- yiyus || JGL .


urgencyfix.diff
Description: Binary data


Re: [dwm] Re: urgent windows border

2008-12-06 Thread yy
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



-- 


- yiyus || JGL .



Re: [dwm] dwm-5.3

2008-12-05 Thread yy
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.

-- 


- yiyus || JGL .



Re: [dwm] Re: urgent windows border

2008-12-04 Thread yy
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.

hth,

-- 


- yiyus || JGL .



Re: [dwm] Re: urgent windows border

2008-12-04 Thread yy
2008/12/4 Tinou [EMAIL PROTECTED]:
 On Thu, Dec 4, 2008 at 9:31 PM, yy [EMAIL PROTECTED] wrote:
 Besides the border color, I think this patch is really useful when using
 the monocle layout. As clearing the urgent flag one could miss that not
 visible urgent window. Though it's only visible viewing another tag...

Not really. Maybe I didn't explain myself very well in my last mail,
but although you remove the border color from the patch I submitted
you will still be able to see it in the status bar. In fact, no code
needs to be added to current dwm to do this, since what it does is
invert the color. Leaving the flag set until the window is focused is
everything you need.
Of course, the inverted color in the tag label doesn't give you so
much information as your taskbar idea (which looks nice), but is
probably more than enough for the common use case.


-- 


- yiyus || JGL .



[dwm] urgent windows border

2008-11-29 Thread yy
The attached patch set a different border color for windows with the
urgency hint flag set. The flag will be removed when the client is
focused (instead of when it is visible). It saves some lines of code
(and can save some more moving clearurgent() to focus(), since it is
used only there).

have fun,

-- 


- yiyus || JGL .


urgentborder.diff
Description: Binary data


[dwm] Re: urgent windows border

2008-11-29 Thread yy
It had a bug. We don't want to set as urgent the sel client. Sorry for
the noise.



-- 


- yiyus || JGL .


urgentborder.diff
Description: Binary data


Re: [dwm] patch to hide sticky indicators, and add nofocus windows

2008-11-25 Thread yy
You could do something very similar just caling unmanage. The problem
is you can't call functions from the rules definition (though you
could use a keybinding to unmanage windows).

It could be interesting to modify applyrules and the Rule definition
in order to call functions, like buttons and keys:

typedef struct {
const char *class;
const char *instance;
const char *title;
void (*func)(const Arg *);
const Arg arg;
} Rule;

Of course, you would also have to tweak manage in order to make it work.

I'm not sure it would be a very good idea, but it probably is not
difficult to try. As a side effect, somebody could control dwm
creating windows with well chosen names (and probably somebody would
write a program to do it), I would find such a hack very unelegant...

-- 


- yiyus || JGL .



Re: [dwm] questions about DWM source

2008-11-09 Thread yy
2008/11/10 robert hickman [EMAIL PROTECTED]:
 Then I came across this pese of code in the manage function:

   Window trans = None;

   if(XGetTransientForHint(dpy, wind, trans))
   t = getclient(trans);
   if(t)
   clien-tags = t-tags;
   else
   applyrules(clien);

 what exactly does this do? and why is it doing it?

 Thanks.



The XGetTransientForHint function will tell us if the window to be
managed (wind) is a child window, in such a case the parent client is
stored in t. When the window has a parent, parent's tags will be
applied to the child (clien-tags = t-tags), else rules are applied
(as defined in config.h).
And btw, wx, wy, etc. comes from wax, way, etc for window area. It
is perfectly documented in dwm.c. Using sort names for geometric
variables is a common rule in many coding style guides.

hth,

-- 


- yiyus || JGL .



Re: [dwm] How to detect TAG activity?

2008-11-04 Thread yy
2008/11/4 Premysl Hruby [EMAIL PROTECTED]:
 On (04/11/08 16:37), yy wrote:
 To: dwm mail list dwm@suckless.org
 From: yy [EMAIL PROTECTED]
 Subject: Re: [dwm] How to detect TAG activity?
 Reply-To: dwm mail list dwm@suckless.org
 List-Id: dwm mail list dwm.suckless.org

 2008/11/4 markus schnalke [EMAIL PROTECTED]:
  I think it is worth to add this script (or an improved version) with
  explanations to the wiki.
  Any volunteer? (I don't have time atm.)
 
 
  meillo
 

 I could do it. I can submit it today or tomorrow, but then I think wmu
 should be included in the hg repository (the script could go inside
 the tarball). This is up to Anselm, of course.

 --


 - yiyus || JGL .


 In which repository do you mean that wmu should be included? I can add
 this script to wmu's repo, as it is pretty handy.

 -Ph

 --
 Premysl Anydot Hruby, http://www.redrum.cz/



There are 2 possible solutions:
1. Include the script in your repo, and we link to it from some dwm wiki page.
2. Move wmu repository to suckless hg, with the other tools.
I just want to avoid having the script and description in the suckless
wiki and the code in your own repository. I'd choose number 2, though
it is not a big deal anyway ;)


-- 


- yiyus || JGL .



Re: [dwm] make setlayout toggle

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


-- 


- yiyus || JGL .



Re: [dwm] slowness in moving windows OR vlc/mplayer crash

2008-09-09 Thread yy
2008/9/9 Anselm R Garbe [EMAIL PROTECTED]:
 The window moving/resizing code might be changed after dwm-5.2 which I
 plan to release tonight. My favorite is just keeping a server grab
 during the resize/move to prevent clients from redrawing since they
 won't receive any events during that time. The current code however
 has been implemented as is on purpose, because I kind of liked the
 idea to see terminal refreshing themselves during resizals. But I
 might never actually used this, since I'm normally in tiled mode
 only...

 Kind regards,
 --Anselm



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
a patch where you can define in rules if you want incremental resizes
for a given window class or something...
BTW, I think 5.2 will be a great release (and I haven't had any
problems with mplayer so far).

Greets,


-- 


- yiyus || JGL .



Re: [dwm] what about 'st'?

2008-09-05 Thread yy
2008/9/5 Donald Chai [EMAIL PROTECTED]:
 I have found something quite useful when working with lot of terminals
 that is having different background colors depending on the task they
 are designed to be. But currently i just change the background color of
 vim and use this to differentiate them. another stuff would be like
 changing the background color of the terminal depending on the focus.

 I also like when my display looks like farmland when viewed from above. :)

 I see no terminal able to do this in a simple way.


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:
http://y-i-y-u-s.deviantart.com/art/dwm-4-4-1-65928966


-- 


- yiyus || JGL .



[dwm] Re: [patch] arguments for ClkTagBar functions

2008-08-31 Thread yy
and this is the patch :)
sorry,


-- 


- yiyus || JGL .


dwm-5.2-tagbararg.diff
Description: Binary data


Re: [dwm] dwm: request to discuss

2008-08-30 Thread yy
2008/8/30 Maxim Vuets [EMAIL PROTECTED]:
 2008/8/29, yy [EMAIL PROTECTED]:
 Just to show you (and all the people who come here asking for
 workspaces from time to time) I have attached a config.h with a
 workspaces implementation. It hasn't been tested very much, but I
 think it works.

 Now you can change workspace with Mod+Tab (and Mod+Shift+Tab) or with
 the mouse wheel on the tags.

 Cool patch. Thank you. Almost that I want (:
 Add to the wiki.

 --
 Hoc est simplicissimum!
 maxim.vuets.name



http://www.suckless.org:8000/dwm/patches/workspaces.html

There was a bug in the config.h that I attached to my other message,
it was not setting mfact to 0 for non tiled layouts.

-- 


- yiyus || JGL .



Re: [dwm] dwm: request to discuss

2008-08-29 Thread yy
Just to show you (and all the people who come here asking for
workspaces from time to time) I have attached a config.h with a
workspaces implementation. It hasn't been tested very much, but I
think it works.

Now you can change workspace with Mod+Tab (and Mod+Shift+Tab) or with
the mouse wheel on the tags.

But as I have told in my previous message in this thread I think this
is over complicated. You will probably have problems to remember what
the different workspaces are (since you will probably modify it), and
you will finish changing your tags and layout instead of going to
another workspace.

Anyway, I think it is a good reference to have in the ml. If somebody
uses it, please report me any problems because I'm going to add it to
the wiki (maybe this weekend). Though I won't maintain it for future
releases, as I told IMO this is not a good idea, but it is a good
example of how easy is to extend dwm.

rgds,


-- 


- yiyus || JGL .


config.h
Description: Binary data


Re: [dwm] dwm: request to discuss

2008-08-28 Thread yy
2008/8/28 Maxim Vuets [EMAIL PROTECTED]:

 I think that mouse is not really important for dwm status bar.

Well, I think it is. I use dwm exclusively with the mouse without any
changes to dwm.c (have a look at the customisation/customfunctions
section in the wiki to see my config.h)


 Why you trying to escape just two optional operations of nav.?
 I'll try to explain my vision on an expamle.
 You have such tags: www, mail, irc, im, dev.
 The most time you spend on developing something.
 But from time to time you want to check irc and mail, maybe serf smth.
 And all the time you want to see your im client.
 What you do? Untag www, mail, irc; tag dev; change layout; change
 order of windows... ouch.
 Now you have two workspaces/desktops: one for the Internet (irc, im,
 www, mail), another one for a work (dev, im). The first has rstack layout
 with corresponding master width and windows order. The second has
 bstack layout with an editor in master area and two terminals on the
 bottom: one is tagged as dev (for output, debug...), another one is
 tagged as im. Now you use just one key to change between these
 desktops. Each one is comfortable for its purposes.
 No need to rearrange windows and so on.


You don't need any changes in dwm.c to achieve this functionality. You
just have to define your keys your way. e.g. (not tested) :

#define WORKSPACEKEYS(KEY,TAGS, LAYOUT, FACT) \
{ MODKEY,   KEY,  view,   {.ui = TAGS} 
}, \
{ MODKEY,   KEY,  setlayout,  {.v =
layouts[LAYOUT]} }, \
{ MODKEY,   KEY,  setmfact,   {.f = 1.FACT} 
},

And later:

WORKSPACEKEYS(  XK_q,  1  0 | 1
 1 | 1  2, 0, 55)
WORKSPACEKEYS(  XK_w,  1  2 | 1
 3, 1, 70)
...

This way you could chose workspaces with q, w,...
You could also write a little function to set this parameters and call
arrange just once to avoid flickering, or use a variable to be able to
cycle through them or change the values per workspace. I just want to
show that you can add all this without any complication.
OTOH, I have tried some similar approachs in the past (patching dwm)
and at the end I always come back to the original dwm tagging. If it
is easy enough choosing any set of tags (with view or tag), change
layouts, etc. having artifacts to remember the different states will
just complicate things.


 Look, one of the reasons why you want to keep status bar is that it's more
 simple to interact with it via mouse. It uses only mouse. But there is no way
 to manage windows using only mouse, because you need to hold some meta
 key, you know. Such title bars bring a possibility to manage windows
 w/o keyboard (;

 --
 Hoc est simplicissimum!
 maxim.vuets.name


As I have told before I completely use dwm _only_ with the mouse. I
use the clicks in the window title (or the root window) to call
move/resize window functions. Again, have a look at my config.h in the
customisation section if you want an example.

Why does everybody think dwm is not configurable? ;)

hth,



-- 


- yiyus || JGL .



Re: [dwm] Feature request: any way to change default values in config

2008-08-23 Thread yy
In my opinion, moving the seltags definition to config.h would be the
right thing to do. This way, with the right mouse and keys
configuration you could achieve things like, for example, having a tag
always visible. It is not something I'm gonna use myself, but moving
the definition of the variable won't hurt anybody ;)

hth,



-- 


- yiyus || JGL .



[dwm] Custom functions

2008-08-22 Thread yy
I have found the way to highly customize dwm to my taste just adding
some custom functions to config.h, without touching dwm.c. Since some
of this functions could be interesting for somebody I have added my
config.h to the wiki, in the customisation section.
(With this configuration, dwm is the most usable with the mouse window
manager I have never tried).

http://www.suckless.org:8000/dwm/customisation/customfuncs.html

I hope somebody will find this useful.
Have a nice weekend,

-- 


- yiyus || JGL .



Re: [dwm] some proposed changes

2008-08-10 Thread yy
2008/8/10 Premysl Hruby [EMAIL PROTECTED]:

 Hi,

 reason for using XConfigureWindow in restack() is setting border_width
 of client (and this is the only reason for not using XMoveResizeWindow
 as you propose).


Any of my windows change window border width since it is setted in
manage(), but anyway we could use XSetWindowBorderWidth() here. I
don't know if it would be better (it saves some loc, but nothing
significant), but I wonder why not.

 XLowerWindow was used in past, but it makes windows flickering in
 monocle layout, as windows are pushed to the bottom of the stack.
 Solution currently in use prevent flickering.


I hadn't noticed the flickering, and though I could really live with
it I see the point now.

 -Ph

 --
 Premysl Anydot Hruby, http://www.redrum.cz/



Thanks for your answers,



-- 


- yiyus || JGL .



[dwm] some proposed changes

2008-08-09 Thread yy
Attached there is a patch with some changes to dwm.c. It uses
XLowerWindow and XMoveResizeWindow instead of configure functions in
restack() and resize() respectively. I suposse there is a good reason
to use configure here, but since Anselm is on holidays I ask here if
somebody knows the reason. I'm using it this way and have found no
problems so far but they could appear with tricky programs. It removes
some loc and I think the code is a bit more consistent this way.
The other change is a new click option: ClkTagButton, this way you can
have buttons in the tags to see previous tags or to see all of them.
Anyway, the comment in config.def.h should be corrected to explain the
current behaviour with ClkTagBar. My config.h is attached too, with
some interesting custom functions.

Greets,

-- 


- yiyus || JGL .


noconfigure.diff
Description: Binary data


config.h
Description: Binary data


Re: [dwm] Tiled window moved/resized with mouse misbehaves. Bug?

2008-08-08 Thread yy
2008/8/8 RCarter [EMAIL PROTECTED]:
 5.1, with or without the patches I'm using:

 If a tiled window is resized or moved with the mouse, it stops obeying
 layout changes, remaining where it is and on top of other windows
 until the application is restarted. The other windows obey, but
 remain underneath.

 This is an unexpected behavior; shouldn't it be prevented?

 In the past, wasn't an automatic switch to floating layout done
 on these mouse-actions?



If a tiled window is resized or moved with the mouse it becomes
floating, so not obeying layout changes is the expected behaviour. I
think it makes sense, and is correctly documented in the man page.
BTW, you don't need to restart dwm in order to make that window tiled
again, you can toggle the isfloating flag of the client with Mod+Space
or with Mod+Button2.

-- 


- yiyus || JGL .



Re: [dwm] Being not so elitist

2008-07-29 Thread yy
From The Free On-line Dictionary of Computing (27 SEP 03) :

  elite

  1.  A term used to describe skilled crackers or
  hackers, or their deeds.  In the last sense, compare to
  elegant.

So, I think we can tell this community is elitist, and dunno why it
should be a problem. OTOH it could be a bit arrogant too, but that's
the way I like it.


-- 


- yiyus || JGL .



Re: [dwm] New layout

2008-07-02 Thread yy
2008/7/2, Anselm R. Garbe [EMAIL PROTECTED]:
 Looking into your patch I more and more come to the conclusion
 to add an extra void *aux field to Client for extensions like
 this (or the previous extensions proposed in the toggle{vert,horiz} patches.

 With this in 5.1 you could easily keep your patchset upwards
 compatible if you use Client-aux to store all the extensions to
 Client.

 What do you think?

 Then you could separate all your functions into dwmii.c which is
 included in config.h instead.

 Kind regards,
 Anselm


I like the idea, I think it would be well worth to give it a try.

-- 


- yiyus || JGL .



Re: [dwm] New layout

2008-07-02 Thread yy
2008/7/2, Anselm R. Garbe [EMAIL PROTECTED]:
 Another thing:

 I don't think that the design of dwm fits well with the
 layouting concept of wmii. This is because dwm depends on the
 assumption that the layout algorithm in use is dynamic enough to
 deal with arbitrary amounts of windows which are singly-linked,
 whereas wmii basically has more high-level data structures to
 organize windows and assumes the column concept in its
 definition. Thus its layout algorithm is less dynamic
 unfortunately.

 An algorithm I have in mind is more dwm-wmii like is somethink
 like:

    
  AACCBB
   CC
  DDCCEE
    

 This layout only shows 5 windows at maximum, and it uses slight
 overlapping to achieve a better screen real estate, the amount
 of overlapping could depend on mfact. The focused window is C
 and any focusstack() action will end up in a re-arrange().

 C is always the list center. It scales for less than 5 windows
 as well.

 Just a random idea.
 --
  Anselm R. Garbe  http://www.suckless.org/  GPG key: 0D73F361



Well, if we start with random ideas, I have one: we could have a new
lt[sellt]-restack (probably renamed to some better name I cannot
imagine now) and if it is NULL the floating behaviour will be used.
This way it would be easy to have layouts where focusstack rearrange
windows, or having a monocle where floating windows are resized.
Just an idea, but I would be glad to write tha patch if somebody finds
a better name than restack for the function.


-- 


- yiyus || JGL .



Re: [dwm] dwm-5.0 / dmenu-3.7

2008-06-18 Thread yy
I don't know how nobody found this one sooner. It has happened to me
just after the announcement, but there is a bug in 5.0. You shouldn't
be able to toggle tags when there is only one selected (a client
without tags will be lost for ever after an arrange...). In other
words, toggleview and toggletag need one more check.
OTOH, I have been using it for some time without even noticing it. I'm
attaching my config.h, just in case somebody is interested in the
pointer wrapping function.



-- 


- yiyus || JGL .


config.h
Description: Binary data


Re: [dwm] feature freeze, please test

2008-06-14 Thread yy
About the mouse warping issue we have discussed in #dwm, forget it, I
can get the desired behavior with a little config.h modifications.
I add:

void
warptosel(const Arg *arg) {
if(sel)
XWarpPointer(dpy, None, sel-win, 0, 0, 0, 0, 0, 0);
}

and then, in buttons definitions:

{ ClkWinTitle,  0,  Button1,warptosel, 
{0} },
{ ClkWinTitle,  0,  Button1,movemouse,  
{0} },
{ ClkWinTitle,  0,  Button3,resizemouse,
{0} },
{ ClkWinTitle,  0,  Button4,focusstack,
  {.i = -1 } },
{ ClkWinTitle,  0,  Button5,focusstack,
  {.i = +1 } },

and that's all. So I'd suggest to not touch dwm.c any more, and this
message will stay here as a reference for other people if they are
interested.

greets,


-- 


- yiyus || JGL .



Re: [dwm] click to focus no longer works

2008-06-14 Thread yy
2008/6/14 Johannes Hofmann [EMAIL PROTECTED]:
 Hi,

 with current tip (118ea4f4f554) it seems no longer possible to focus
 a client by clicking it with the left mouse button.
 To reproduce move the mouse over the stack, focus the main window
 using MODKEY-k, close that window e.g. using Ctrl-d. Now it is not
 possible to focus the window under the mouse by clicking on it.

 Regards,
 Johannes



It's true, this is something I changed in my dwm after sending the
patch to the list (I didn't know it was going to be applied). This (in
buttonpress()) will do the trick:

else if((c = getclient(ev-window))) {
click = ClkClientWin;
focus(c);
}




-- 


- yiyus || JGL .



Re: [dwm] patch

2008-06-10 Thread yy
2008/6/10, Anselm R. Garbe [EMAIL PROTECTED]:
 On Tue, Jun 10, 2008 at 10:58:40AM +0200, Premysl Hruby wrote:
  On (10/06/08 10:51), Anselm R. Garbe wrote:
   To: dynamic window manager dwm@suckless.org
   From: Anselm R. Garbe [EMAIL PROTECTED]
   Subject: Re: [dwm] patch
  
   On Tue, Jun 10, 2008 at 10:38:55AM +0200, Premysl Hruby wrote:
- reintroducion of union Arg
  
   I don't like this, because intialization gets slightly
   cumbersome, I really prefer void * here.
 
  Imho it's much more cleaner then these const void *, is it don't hinder
  the type etc. And initialization looks cleaner too. And union has been
  created just for this usage, as replace for type magic.

 Well for the predifined builtin key handlers this is right.
 However, const void * allows extensions to use structs of
 certain kinds directly as input, whereas the union needs to be
 redefined in such cases.

 However a solution to this problem is of course introducing void
 * as part of the union.

 So I'm open for introducing this change. The problem is, we
 should do that before 5.0 to keep updates to config.h at a
 minimum after 5.0.

 Kind regards,
 --
  Anselm R. Garbe  http://www.suckless.org/  GPG key: 0D73F361



If ther is plans to add mouse actions definitions after 5.0 I'm in
favor of this change, since it will simplify it in config.h too.

Greets,


-- 


- yiyus || JGL .



Re: [dwm] center scaling

2008-06-04 Thread yy
2008/6/4, pancake [EMAIL PROTECTED]:
 btw...mouse-related patches are not easy to be modular on current dwm.
 Do you plan to do it for the next release? together with the
 'mouse-clicks' patch?

 --pancake


I have written a patch to generalize mouse actions in the same way
that keys. I was waitting for the 5.0 release before submitting it to
the list, but if you are interested I can send it this evening.


-- 


- yiyus || JGL .



[dwm] getting rid of viewprev()

2008-05-31 Thread yy
Writing my patch to automatically see previous tags (attached,
extremely simple) I have noticed that you can get rid of viewprev() at
the same time that you simplify view(). The diff is attached too (the
only difference between both patches is an additional check in the if
statement in autoviewprev.diff).

-- 


- yiyus || JGL .


noviewprev.diff
Description: Binary data


autoviewprev.diff
Description: Binary data


Re: [dwm] getting rid of viewprev()

2008-05-31 Thread yy
2008/5/31 Anselm R. Garbe [EMAIL PROTECTED]:
 On Sat, May 31, 2008 at 05:43:36PM +0200, yy wrote:
 Writing my patch to automatically see previous tags (attached,
 extremely simple) I have noticed that you can get rid of viewprev() at
 the same time that you simplify view(). The diff is attached too (the
 only difference between both patches is an additional check in the if
 statement in autoviewprev.diff).

 So the autoviewprev patch is equal to Mod1-Tab if the same
 view() is called twice?

 I tend to prefer the noviewprev.diff.

 Kind regards,
 --
  Anselm R. Garbe  http://www.suckless.org/  GPG key: 0D73F361



Well, that's the idea. I find it very useful to temporarily see one
tag (mainly with the mouse). I realize that it is not an evident
feature and could cause some confusion and, though I have really get
used to it, this could be one of those things that fit better in a
patch (but I'd suggest everybody to give it a try).

-- 


- yiyus || JGL .



Re: [dwm] Bug in zoom()

2008-05-30 Thread yy
2008/5/29, Anselm R. Garbe [EMAIL PROTECTED]:
  - if(!lt-arrange || sel-isfloating)
  + if(!sel || !lt-arrange || ismax || sel-isfloating)
return;

Just a little remark. Now that maximizations are done in arrange() the
|| ismax check here is not neccessary any more (it will never happen:
if(ismax) ... else if(ismax) ...).

Is there any pending questions about dwm 5.0 or can we consider
current hg tip as a release candidate?

-- 


- yiyus || JGL .



[dwm] domax (again)

2008-05-25 Thread yy
domax is much better this way, using XMoveResizeWindow. I have removed
ban/unban and merged it into arrange and added my tagkeys macro, so at
the end it removes 25 lines to the dwm source.
Some questions:
1. wouldn't it be a good idea moving the tagset definition to
config.h? So everybody can chose the initial tags he wants.
2. has anybody tried any of my patches?

greets,

-- 


- yiyus || JGL .


dwm-5.0-domax+tagkeys
Description: Binary data


Re: [dwm] bitarray and void *arg (was: using bitaray for tags (PATCH))

2008-05-22 Thread yy
2008/5/22, Anselm R. Garbe [EMAIL PROTECTED]:
 Applied.
 Thanks a lot!


   void
  -toggletag(const char *arg) {
  - unsigned int i, j;
  +toggletag(void *arg) {
  + int i, m = *(int *)arg;
  + for(i = 0; i  sizeof(int) * 8; i++)
  + fputc(m  1  i ? '1' : '0', stdout);
  + puts();
  + for(i = 0; i  sizeof(int) * 8; i++)
  + fputc(TAGMASK  1  i ? '1' : '0', stdout);
  + puts(aaa);
 

Debug party? :)

-- 


- yiyus || JGL .



[dwm] tags definition

2008-05-22 Thread yy
I was too tired of defining 4 different keys for each tag inside
config.h, so I created a TAGKEYS macro. I vote for its inclusion in
main dwm. I was thinking about having the (uint[]){ 1  Tag} inside
the macro, or even (uint[]){ 1  (Key - 1)} , but since it is in
config.h all that is up to you and I think this is the most standard
way (the idea is having some consistency with the other key
definitions).

Attached is a modified config.def.h, I hope you like it,

-- 


- yiyus || JGL .


config.h
Description: Binary data


Re: [dwm] Freedom (was: Re: sic ipv6 patch)

2008-05-20 Thread yy
Being pragmatic, I think it is better the MIT style license. e.g.:
somebody wants to take the tile algorithm from dwm for some
proprietary project (yes, there are projects where the code cannot be
shared), if dwm is GPL they will just copy it without telling to
anybody, to avoid further legal problems; but if it is MIT they can
tell it is your code without any problem (and even report you
bugs/improvements, if that's the case).
Anyway, I think this whole discussion is pointless, because while
Anselm releases under the MIT licenses you can just take it and
re-release under GPL, if that makes you feel better.

Just my 2 cents,

-- 


- yiyus || JGL .



Re: [dwm] using bitaray for tags (PATCH)

2008-05-20 Thread yy
2008/5/20, Premysl Hruby [EMAIL PROTECTED]:
 Hi,

 This is realization of Gottox's proposal discuted on IRC today.
 It handles tags not as Bool [], but as bit-array saved in int.

 There's only one problem, as I don't find easy solution (in compile time)
 for check if there's no more tags than sizeof(int)*8.

 Maybe it can be asserted with someting like (possibly global, compiler
 take it away as it's not used anywhere):

 static char too_many_tags_test[sizeof(int)*8 - LENGTH(tags)];

 Has anyone better solution?

 -Ph

 --
 Premysl Anydot Hruby, http://www.redrum.cz/



But, why so many macros? I don't see TMASK(p) better than 1  (p),
the same with TOGGLE and ISSET, and I don't understand SET at all, you
are not using the v for anything (it is always 1), why not t = 1 
(p) ?
And about the int size, I think that since tags are defined in source
code it shouldn't be a problem.
The only problem I see is that the style doesn't fit too much with the
rest of the dwm code, but global Bools could also be changed to a
global bitarray with some Enum.

-- 


- yiyus || JGL .



[dwm] buttonpress patch

2008-05-19 Thread yy
This is the buttonpress patch I have just talked about (incremental to
the domax patch). It adds a lot of new functionality, i.e.:
- It reverts the old zooming with middle mouse button (or toggling
floating if not in tiled layout) with a click inside the window
(+ModKey) or in the bar.
- With the mouse wheel in the bar you focus prev/next client.
- Moving and resizing clients with buttons 1 and 3 also works with a
simple click (without modifier key) inside the bar, at the right of
the layout symbol.
- When moving windows, the pointer is wrapped to the top-left corner
of the client, this is also a convenience to go to a window from the
bar after focusing it with the wheel.
And all this in few lines and without damaging too much the code. I
know dwm is by definition keyboard driven, but if there is any
interest I will update the patch after the 5.0 release (adding the
corresponding patch for the man page). I find it pretty handy.
I also have patches to view previous tags when trying to view the
current tags (instead of losing the revert state) and to move windows
on screen when you focus a partly offscreen client (this one is like
having an ultra wide monitor :). With these changes I have everything
I want, but I won't send patches for 5.0 to the list if there isn't
any interest.

Have fun,

-- 


- yiyus || JGL .


dwm-5.0-buttonpress.diff
Description: Binary data


Re: [dwm] Documentation!

2008-05-17 Thread yy
While I partly agree with your critics, I think they are not very
helpful (with all the respect).
The 2 or 3 characters variable names have been there since the
beginning to define geometries, I don't understand what the problem
is, and I also find the 2kloc limit somewhat stupid, but it has shown
itself to be a good limit after all and when we have been near to it
in the past, it has been time to remove features. Maybe a
reorganization of the code is what is needed. I think it should be
more uniform: sometimes you have toggles, sometimes you have set
functions, almost every function does different things with NULL
arguments (this is the most unpredictable thing, IMO),...
I remember when dwm was going in the wrong direction with nmaster and
it was discussed in the list what features could be removed, and after
getting rid of it, window titles, etc, dwm was prettier than ever. I
think it is time to do it again.
This is a list of what I don't like/use in dwm:
- Geom stuff (already removed, I know), though I'm concerned people
with 2 monitors need a solution.
- Different layouts, the only one I occasionally use is monocle, but
because of it we needed(?) the ugly stuff of lt-isfloating and
remember floating geometries. The only use I do of the floating layout
is to raise a tiled window...
- I don't like at all remembering floating geometries (and I wrote the
patch, heh!)
- I have never used the reapply thing with Mod+R, but I can live with it.
So, to sum up, what I think is stopping dwm is a really good solution
for xinerama setups and maximize/monocle (maybe we could try with
Anselm's idea of restoring geometries in focus changes? I could give
it a try...).
Another interesting idea could be a list in the web of past dwm
releases with the features of each one, while there are no important
bugs I don't see any problem with using an old dwm.

Well, enough talking for now, let's write some patches, regards,


-- 


- yiyus || JGL .



[dwm] [patch] domax (was: Documentation!)

2008-05-17 Thread yy
As I told in my last message, I have implemented maximizations in a
different way.
It adds 3 loc and removes some flexibility, but I think it makes the
code clearer. With this patch, dwm doesn't remember floating windows
any more. Notice that in order to maximize windows you can use Mod+M
or the right mouse button in the tile symbol (which will then become
inverted). I don't know if it should go into main or not, I just
wanted to try it... be care because I didn't have time to do much
testing.

greets,

-- 


- yiyus || JGL .


dwm-5.0-domax.diff
Description: Binary data


Re: [dwm] [patch] domax (was: Documentation!)

2008-05-17 Thread yy
2008/5/17 yy [EMAIL PROTECTED]:
 As I told in my last message, I have implemented maximizations in a
 different way.
 It adds 3 loc and removes some flexibility, but I think it makes the
 code clearer. With this patch, dwm doesn't remember floating windows
 any more. Notice that in order to maximize windows you can use Mod+M
 or the right mouse button in the tile symbol (which will then become
 inverted). I don't know if it should go into main or not, I just
 wanted to try it... be care because I didn't have time to do much
 testing.

 greets,

 --


 - yiyus || JGL .


I forgot to make you a question: why am I getting EnterNotify events
maximizing windows (even if you don't raise them)? Or in other words,
why don't you get them when zooming with the cursor in the stack area?

-- 


- yiyus || JGL .



Re: [dwm] [patch] domax (was: Documentation!)

2008-05-17 Thread yy
2008/5/17 Anselm R. Garbe [EMAIL PROTECTED]:
 We did similiar work today ;)

Yes :) I'm very happy with your last changes.

( -- I'd like to see your domax
 patch as patch against the most recent hg tip.


Attached, now it is even better, because it doesn't let you to
move/resize windows while in domax. But it lets you to zoom windows,
maybe you want to change this.

 The reason why you don't receive the enternotify events in
 zoom() is because of restack() which performs the following
 loop at the end:

XSync(dpy, False);
while(XCheckMaskEvent(dpy, EnterWindowMask, ev));

 I recommend doing it this way, instead of counting enternotify's
 because it enforces our focus policy much cleaner than all this
 quirky enternotify counting in other WMs.


I have tried it this way, but there are 2 problems:
1. If RESIZEHINTS is True you can focus the other windows if you move
the pointer to the bottom of the screen, which is annoying.
2. The maximized window is resized when you move the pointer to the
bar window, causing some flicker.
So, I came back to the check in enternotify(), but feel free to find a
better solution.

 Kind regards,
 --
  Anselm R. Garbe  http://www.suckless.org/  GPG key: 0D73F361



salu!

-- 


- yiyus || JGL .


dwm-5.0-domax.diff
Description: Binary data


Re: [dwm] wildcard in client rules tags ref

2008-05-15 Thread yy
2008/5/15 Eric Davis [EMAIL PROTECTED]:
 On Thu, May 15, 2008 at 11:56:02AM +0200, Anselm R. Garbe wrote:
 On Tue, May 13, 2008 at 09:06:22PM -0700, Eric Davis wrote:
  DWM used to support regular expressions in the tags ref for client
  rules.  I agree that the feature was overkill but it was nice to be able
  to say * so a client is on all tags.  I used this for background
  notification popups from scripts with gxmessage.
 
  Is it possible to add a simple glob indicator back to DWM that specifies
  all tags?  Or is there another way to do this that I overlooked...?

 See attached patch, however I'm not sure I like this approach
 for the mainstream dwm.

 If you want the behavior it is possible with the following
 approach already in mainstream dwm, but you might not like it:

 { NULL, gxmessage, NULL, tags[0], True },
 { NULL, gxmessage, NULL, tags[1], True },
 { NULL, gxmessage, NULL, tags[2], True },
 { NULL, gxmessage, NULL, tags[3], True },
   ...
 { NULL, gxmessage, NULL, tags[8], True },


 Sometimes the simplest approaches are greatly overlooked!  Having the
 multiple tag rules works great and I think is a good solution.

 Note that, for me, you're patch caused dwm to hang.  It wouldn't take
 any keyboard input and no gxmessage windows were shown... but dwm did
 respond to HUP and came back to life.

 Another solution which might be even better is to use dzen.

 Thanks,
 - e




Of course it crashed, did you correct the typo?  The i++ in the for
loop should be j++

-- 


- yiyus || JGL .



Re: [dwm] Suggestion float my next window

2008-05-13 Thread yy
2008/5/13, Tri PLC [EMAIL PROTECTED]:
 Hi

 It's a suggestion to create a float next windows feature.


I think this has been discussed before. The problem is that you cannot
know who is opening the next window, so if a popup dialog appears in
that moment you won't have the expected behaviour (actually the
problem is not dwm related, but an old X window problem).

-- 


- yiyus || JGL .



Re: [dwm] snapping bugs with multiple screens

2008-05-05 Thread yy
I don't have a dualhead setup to test, but in case you cannot move the
mouse pointer out of the monitor borders you have a very easy
solution: wrap the mouse to the nearest window corner at the begining
of movemouse() (I wrote a patch for this once), then you will always
align your windows with the borders of the monitor. If there is a way
to not let the mouse pointer going outside of the window area during
mousemove (I know you can limit the pointer to a window, but I don't
know if you can define a region of the root window) then you could
completely remove snap. The only remaining issue would be positioning
a window in the barrier between monitors, but this solution could be
better than no snaping at all, and not too complicated.

hth,

-- 


- yiyus || JGL .



Re: [dwm] Yet another simplification, this time sel/prevtags

2008-04-27 Thread yy
2008/4/27 Anselm R. Garbe [EMAIL PROTECTED]:
 On Sun, Apr 27, 2008 at 07:41:08PM +0200, Anselm R. Garbe wrote:
   On Sun, Apr 20, 2008 at 10:24:32PM +0200, Premysl Hruby wrote:
void
view(const char *arg) {
seltags ^= 1;
memset(tagset[seltag], (NULL == arg), TAGSZ);
tagset[seltag][idxoftag(arg)] = True;
arrange();
}
  
   I simplified view() accordingly.

  With the current change in mind, do we still need viewprev()?

  Kind regards,


 --
   Anselm R. Garbe  http://www.suckless.org/  GPG key: 0D73F361



After the last change in hg tip, viewprev is the only way to view the
previous tags, the change when trying to view the currently selected
tag is not working any more, if you remove viewprev you can then
remove all the tagset stuff. Another thing, now if you press twice in
a tag to view it you will lose your previous tags, I don't think
that's the expected behavior.



-- 


- yiyus || JGL .



Re: [dwm] [PATCH] Add support for on-start actions

2008-04-26 Thread yy
2008/4/26 Jules Villard [EMAIL PROTECTED]:
 Hi all,

  This patch adds the ability to perform user-defined actions on
  startup.  In particular, you can launch some applications like a bunch
  of terms, a browser, you name it... or select a specific tag.  I found
  a need for it because I always perform the same actions when I start
  X :)  As the patch is very small --it only adds a structure and a
  small loop in dwm.c, amounting to 9 lines of code-- I'm (perhaps
  boldly) hoping that you might find it interesting too and consider it
  for inclusion.

  For my personal use, I have something similar to the following snippet
  of code in config.h:

  -8---

   /* tagging */
   const char tags[][MAXTAGLEN] = { 1, 2, 3, 4, #, zik, www };

   Rule rules[] = {
 /* classinstancetitle   tags ref
 isfloating */
 { Firefox,NULL,   NULL,   tags[6],False 
 },
 { rxvt,   NULL,   ncmpc,tags[5],False 
 },
 { rxvt,   NULL,   alsamixer,tags[5],False 
 },
 { rxvt,   NULL,   start,tags[0],False 
 },
 { rxvt,   NULL,   sudo, tags[4],False 
 },
   };

   /* actions to be performed on startup */
   Start start[] = {
 /* function argument */
 { spawn,exec rxvt -e mutt }, /* tagged 1 */
 { spawn,exec rxvt -e screen irssi }, /* same   */

 { spawn,exec rxvt -e alsamixer },/* tagged zik */
 { spawn,exec rxvt -e sudo su - },/* tagged #   */
 { spawn,exec firefox },  /* tagged www */

 /* tagged zik and zoomed */
 { spawn,exec rxvt -e ncmpc },
 /* tagged 1 and zoomed   */
 { spawn,exec rxvt -ls -title start },
 /* now select tag 4 to type my password */
 { view, tags[4]},
   };

  -8---

   This allows me to start my session with 3 terms tagged 1: mutt and
  irssi are stacked on the right-hand side and an empty term is readied
  on the left-hand side.  Timing is important, so the last term is
  spawned some time after the first two to be the last term indeed and
  get the zoom.  Likewise, some applications are launched between the
  alsamixer and the ncmpc instances, so that the latter ends up getting
  the zoom.  Moreover, since I like to start seeing tag 4, which
  corresponds to my sudo'd term --otherwise I tend to forget to type my
  password-- I force the tagging of the third term I want with tag 1
  by assigning that term a special title (rxvt -title start) which I add
  to the rules. This term might otherwise end up being spawned with
  tag 4.

   I think this really is a corner case and that you might not need to
  be bothered with such a level of details, e.g. if you do not mind
  having to re-tag some windows by hand.  I think my main point is that
  basic usage --for instance launching two terms, a browser and ncmpc at
  startup-- is very intuitive and that you can achieve more complex ones
  without heroic efforts, the other point being that the patch ended up
  being ridiculously simple.


  Thanks for reading this long email, -p1 patch against 4.9 follows.
  Cheers,

  Jules



I see your point, but IMHO .xinitrc is a better place to start
applications on startup. About tags, for me it would be better a
boolean visibleonstartup variable in the tag definition, but I don't
find too uncomfortable having to toggle 1 or 2 tag when I start the
computer. OTOH your patch is clean and easy to understand.

greets,

-- 


- yiyus || JGL .



Re: [dwm] faster focus to client

2008-04-21 Thread yy
I have found an useful tip related to this idea, if you are using the
patch I submitted yesterday (or any of the previous versions) to see
the previous tags when you try to see the currently selected tags.
I'll explain it with an example: you have clients with tags 1, 2 and
3, and you are viewing these three tags. Now, if you press Mod1+1
twice you will be focusing the first client with tag 1, if you press
Mod2+2 twice you will be focusing the first client with tag 2, etc.
This way, if you define enough tags in your config.h for the clients
that you want to access quickly, you can focus them with just two key
strokes. You can do it now with Mod1+Tab, but it is a bit less
comfortable.
As a side note, I have always wanted to give it a try to dynamic tags
in dwm, and I will probably write a patch once 5.0 is released, just
to see how it feels. OTOH, I think the needed complexity won't be well
worth, but let's see...

hth,

-- 


- yiyus || JGL .



Re: [dwm] Yet another simplification, this time sel/prevtags

2008-04-20 Thread yy
2008/4/20, Anselm R. Garbe [EMAIL PROTECTED]:
 On Sun, Apr 20, 2008 at 06:05:50PM +0200, Premysl Hruby wrote:
   attached patch makes one array for both sel and prevtags. So there is
   no need to swap them in memory in view() as we only change seltags
   pointer to point viewtags[0] or viewtags[1].
  
   It also with little change can support arbitrary number of saved tags
   set (3 save position can be usable, with modkey-shift-tab going on
   next state in queue).


 I like this solution and applied it with a slightly changed
  order of variable declarations. I intend to declare the variables
  in groups of same types.

  Kind regards,

 --
   Anselm R. Garbe  http://www.suckless.org/  GPG key: 0D73F361



I like this change, good work Premysl! But once you are using the
array, you don't need seltags any more. The attached patch saves 2 or
3 loc. It also includes the functionality of my patch to see prevtags,
but if you do the XOR inside memcpy you can save another line of code.
I have also changed a little your notation (because I don't like
underscores in variable names), but maybe you can think of better
names.
I think I will like dwm 5.0...


-- 


- yiyus || JGL .


tagset.diff
Description: Binary data


Re: [dwm] Yet another simplification, this time sel/prevtags

2008-04-20 Thread yy
2008/4/20, Premysl Hruby [EMAIL PROTECTED]:
 On (20/04/08 21:49), yy wrote:
   To: dynamic window manager dwm@suckless.org
   From: yy [EMAIL PROTECTED]
   Subject: Re: [dwm] Yet another simplification, this time sel/prevtags
   Reply-To: dynamic window manager dwm@suckless.org
   List-Id: dynamic window manager dwm.suckless.org

 
   I like this change, good work Premysl! But once you are using the
   array, you don't need seltags any more. The attached patch saves 2 or
   3 loc. It also includes the functionality of my patch to see prevtags,
   but if you do the XOR inside memcpy you can save another line of code.
   I have also changed a little your notation (because I don't like
   underscores in variable names), but maybe you can think of better
   names.
   I think I will like dwm 5.0...
  
  



 Hi

  -   if(memcmp(seltags, tmp, TAGSZ) != 0) {
  -   seltags = viewtags[viewtags_set ^= 1];  /* toggle tagset */
  -   memcpy(seltags, tmp, TAGSZ);
  -   arrange();
  -   }
  +   seltags ^= 1;  /* toggle sel tagset */
  +   if(memcmp(tagset[seltags ^ 1], tmp, TAGSZ) != 0)
  +   memcpy(tagset[seltags], tmp, TAGSZ);
  +   arrange();

  This doesn't do same thing, as seltags is always toggled, even if
  current and new tagset are same. So this will broke that change only if
  differ behaviour or I miss something? :)

  If we will throw away this behaviour, things can be even more simpler.
  We then can substitute whole view with:

  void
  view(const char *arg) {
 seltags ^= 1;
 memset(tagset[seltag], (NULL == arg), TAGSZ);
 tagset[seltag][idxoftag(arg)] = True;
 arrange();
  }

  (memset can be used, because tags are always only test if they are zero
  or nonzero, so it doesn't matter that tagset[i][j] (because Bool is defined
  as int) can be something like 0x01010101 on x86)

  -Ph


The idea is to have the same behavior that with my patch from April
7th. I like to view the previous tags when there is no difference.
This way you can temporally see one tag (or all of them) in a
convenient way. To sum up, the behavior would be: change if differ,
else viewprevtag Try it, please. This feature has become a must-have
for me. If this is not desired you could do memcpy(tagset[seltags ^=
1], tmp, TAGSZ) and remove the seltags ^= 1; line. I tried to explain
it in my previous message, I hope it is clearer now.


-- 


- yiyus || JGL .



Re: [dwm] faster focus to client

2008-04-17 Thread yy
2008/4/17, pancake [EMAIL PROTECTED]:
 What do you think about this feature? I think that could be really 
 interesting.

  When you have lot of windows opened it's mostly tedious to focus a desired 
 window
  with the keyboard. So why not tag windows with a key and make them accessible
  in a faster way?

  My idea is to create this code structure:

  void tagclient(char *);
  void focustag(char *);

  You can setup a keybinding for each function and then store a single char 
 inside
  the Client structure to make it accessible with it. And we can also use the 
 title
  of the window or a property like floating for selecting the next client to be
  focused.

  For example. Doing focustag(); we will toggle between the first client in 
 the
  list of the selected tags that are floating and non-floating clients. Like 
 in wmii :)

  If we call clienttag(M); we will focus the client tagged as 'M' or with a 
 title
  name starting with 'M' like mplayer.

  Another possibility is to call clienttag(-) and make dwm capture the next 
 key
  pressed and use it as argument focus it.

  I don't really think this is a good design concept, but derivated ideas are 
 welcome!





  --pancake



Well, we have already got tags in dwm, I don't think we need more. As
a simple solution, you could just add this to the end of view() (you
will need to declare c too):
for(c = clients; c  !c-tags[idxoftag(arg)]; c = c-next);
focus(c);
And you could have tags for lots of letter in your keyboard. I never
lose windows (I don't use many of them, and I focus mostly with the
mouse), but I understand it can be a problem for some people. Of
course, it wouldn't always work with my patch to view the previous
tags, but you get the idea.
Another option is having this in config.h:
{ MODKEY|ShiftMask,   XK_j,
focusnext,  NULL },
{ MODKEY|ShiftMask,   XK_j,
focusnext,  NULL },
{ MODKEY|ShiftMask,   XK_j,
focusnext,  NULL },
{ MODKEY|ShiftMask,   XK_j,
focusnext,  NULL },
so you can advance several clients with only one key stroke.


hth,

-- 


- yiyus || JGL .



Re: [dwm] fgeom patch

2008-04-15 Thread yy
There was an error in monocle, and the floating() definition hadn't
been removed... (ok, ok, yesterday it was not my day...). I have also
changed zoom() so that it does an arrange if lt-isfloating or
sel-isfloating; this way, after having manually resized windows while
in [M] (or = or |) you can rearrange your windows without
toggling layouts. I think the changes (which now only adds one loc if
you don't count the example layouts) allows much more flexibility in
dwm, especially in floating layouts (now you can have floating layouts
to arrange your windows in a grid, for example), and I won't need
defines to not remember floating layout (I can use =).
Well, now I will really wait to see what you have to say, going back
to plan9,,, sorry again for all this noise.


-- 


- yiyus || JGL .
diff -r 595ed1a4447c config.def.h
--- a/config.def.h	Tue Apr 08 11:49:35 2008 +0100
+++ b/config.def.h	Tue Apr 15 11:38:28 2008 +0200
@@ -35,8 +35,11 @@ Layout layouts[] = {
 Layout layouts[] = {
 	/* symbol		function	isfloating */
 	{ []=,		tilev,		False }, /* first entry is default */
+	{ =,		tilev,		True },
 	{ []|,		tileh,		False },
-	{ ,		floating,	True },
+	{ |,		tileh,		True },
+	{ ,		NULL,	True },
+	{ [m],		monocle,	False },
 	{ [M],		monocle,	True },
 };
 
diff -r 595ed1a4447c dwm.c
--- a/dwm.c	Tue Apr 08 11:49:35 2008 +0100
+++ b/dwm.c	Tue Apr 15 11:38:28 2008 +0200
@@ -66,6 +66,7 @@ struct Client {
 struct Client {
 	char name[256];
 	int x, y, w, h;
+	int fx, fy, fw, fh;
 	int basew, baseh, incw, inch, maxw, maxh, minw, minh;
 	int minax, maxax, minay, maxay;
 	long flags;
@@ -142,7 +143,6 @@ void enternotify(XEvent *e);
 void enternotify(XEvent *e);
 void eprint(const char *errstr, ...);
 void expose(XEvent *e);
-void floating(void); /* default floating layout */
 void focus(Client *c);
 void focusin(XEvent *e);
 void focusnext(const char *arg);
@@ -285,13 +285,17 @@ arrange(void) {
 	Client *c;
 
 	for(c = clients; c; c = c-next)
-		if(isvisible(c))
+		if(isvisible(c)) {
 			unban(c);
+			if(lt-isfloating || c-isfloating)
+resize(c, c-fx, c-fy, c-fw, c-fh, True);
+		}
 		else
 			ban(c);
 
 	focus(NULL);
-	lt-arrange();
+	if(lt-arrange)
+		lt-arrange();
 	restack();
 }
 
@@ -359,7 +363,7 @@ buttonpress(XEvent *e) {
 			movemouse(c);
 		}
 		else if(ev-button == Button2) {
-			if((floating != lt-arrange)  c-isfloating)
+			if(!lt-isfloating  c-isfloating)
 togglefloating(NULL);
 			else
 zoom(NULL);
@@ -668,15 +672,6 @@ expose(XEvent *e) {
 
 	if(ev-count == 0  (ev-window == barwin))
 		drawbar();
-}
-
-void
-floating(void) { /* default floating layout */
-	Client *c;
-
-	for(c = clients; c; c = c-next)
-		if(isvisible(c))
-			resize(c, c-x, c-y, c-w, c-h, True);
 }
 
 void
@@ -996,8 +991,8 @@ manage(Window w, XWindowAttributes *wa) 
 	/* geometry */
 	c-x = wa-x;
 	c-y = wa-y;
-	c-w = wa-width;
-	c-h = wa-height;
+	c-w = c-fw = wa-width;
+	c-h = c-fh = wa-height;
 	c-oldbw = wa-border_width;
 	if(c-w == sw  c-h == sh) {
 		c-x = sx;
@@ -1015,6 +1010,8 @@ manage(Window w, XWindowAttributes *wa) 
 			c-y = wy;
 		c-bw = BORDERPX;
 	}
+	c-fx = c-x;
+	c-fy = c-y;
 
 	wc.border_width = c-bw;
 	XConfigureWindow(dpy, w, CWBorderWidth, wc);
@@ -1110,8 +1107,11 @@ movemouse(Client *c) {
 ny = wy + wh - c-h - 2 * c-bw;
 			if(!c-isfloating  !lt-isfloating  (abs(nx - c-x)  SNAP || abs(ny - c-y)  SNAP))
 togglefloating(NULL);
-			if((lt-isfloating) || c-isfloating)
+			if(lt-isfloating || c-isfloating) {
+c-fx = nx;
+c-fy = ny;
 resize(c, nx, ny, c-w, c-h, False);
+			}
 			break;
 		}
 	}
@@ -1271,10 +1271,16 @@ resizemouse(Client *c) {
 nw = 1;
 			if((nh = ev.xmotion.y - ocy - 2 * c-bw + 1) = 0)
 nh = 1;
-			if(!c-isfloating  !lt-isfloating  (abs(nw - c-w)  SNAP || abs(nh - c-h)  SNAP))
+			if(!c-isfloating  !lt-isfloating  (abs(nw - c-w)  SNAP || abs(nh - c-h)  SNAP)) {
+c-fx = c-x;
+c-fy = c-y;
 togglefloating(NULL);
-			if((lt-isfloating) || c-isfloating)
+			}
+			if(lt-isfloating || c-isfloating) {
 resize(c, c-x, c-y, nw, nh, True);
+c-fw = nw;
+c-fh = nh;
+			}
 			break;
 		}
 	}
@@ -1294,16 +1300,11 @@ restack(void) {
 	if(!lt-isfloating) {
 		wc.stack_mode = Below;
 		wc.sibling = barwin;
-		if(!sel-isfloating) {
-			XConfigureWindow(dpy, sel-win, CWSibling|CWStackMode, wc);
-			wc.sibling = sel-win;
-		}
-		for(c = nexttiled(clients); c; c = nexttiled(c-next)) {
-			if(c == sel)
-continue;
-			XConfigureWindow(dpy, c-win, CWSibling|CWStackMode, wc);
-			wc.sibling = c-win;
-		}
+		for(c = stack; c; c = c-snext)
+			if(!c-isfloating  isvisible(c)) {
+XConfigureWindow(dpy, c-win, CWSibling|CWStackMode, wc);
+wc.sibling = c-win;
+			}
 	}
 	XSync(dpy, False);
 	while(XCheckMaskEvent(dpy, EnterWindowMask, ev));
@@ -1856,6 +1857,8 @@ view(const char *arg) {
 		memcpy(seltags, tmp, TAGSZ);
 		arrange();
 	}
+	else
+		viewprevtag(NULL);
 }
 
 void
@@ -1903,14 +1906,14 @@ zoom(const char *arg) {
 zoom(const char *arg) {
 	Client *c = sel;
 

Re: [dwm] fgeom patch

2008-04-14 Thread yy
2008/4/14, Anselm R. Garbe [EMAIL PROTECTED]:
 On Wed, Apr 09, 2008 at 07:41:53PM +0200, yy wrote:
   As discussed before, this is the patch with the floating geometry
   functionality. I removed some loc in restack, but I had to add more in
   other places to correctly manage mouse actions when in monocle layout


 I like the restack() simplification.


I have noticed that it lets you to get rid of floating(), saving some
loc. Have a look at the attached patch.


   (isn't a bug the current possibility of moving and resizing windows
   while in monocle layout?).


 I'd like to keep mouse manipulations dependend on
  lt-isfloating, instead of performing a hardcoded floating
  layout check.


Well, since I have completely removed the floating layout, it is done
in base on lt-isfloating in the new patch.


   Basically, the patch makes dwm to remember floating geometries when
   you change to tiled or monocle layout.
   I'm not sure about setting fx and fy on tileresize(), but note that if
   you don't do it you will need to add them in movemouse() and
   resizemouse() before togglefloating().


 Hmm I don't think that tileresize is the right place for setting
  fx, and fy.  Instead fx/fy/fw/fh should be used depending on
  lt-isfloating in resize and the layout itself, that's why I'd
  consider doing the following in struct Client:

  typdef struct {
  ...
 int x[2], y[2], w[2], h[2];
  ...
  } Client;

  #define BOOLTOIDX(x) (x) ? 1 : 0

  And then in resize:

 c-x[BOOLTOIDX(lt-isfloating || c-isfloating)] = x;
 ...

  etc.

  Kind regards,


I will think about it once you implement it in hg tip, this new
version of the patch doesn't touch the client floating geometry in
tileresize(), I think it works like expected, but I see the possible
simplification with the BOOLTOIDX method. And you would have the
possibility of having a #define REMEMBERFLOATS in config.h and then
BOOLTOIDX(REMEMBERFLOATS  (lt-isfloating || c-isfloating)), so
that this is configurable... (just rambling).

slds,

-- 


- yiyus || JGL .
diff -r 595ed1a4447c config.def.h
--- a/config.def.h	Tue Apr 08 11:49:35 2008 +0100
+++ b/config.def.h	Mon Apr 14 18:27:12 2008 +0200
@@ -36,7 +36,7 @@ Layout layouts[] = {
 	/* symbol		function	isfloating */
 	{ []=,		tilev,		False }, /* first entry is default */
 	{ []|,		tileh,		False },
-	{ ,		floating,	True },
+	{ ,		NULL,	True },
 	{ [M],		monocle,	True },
 };
 
diff -r 595ed1a4447c dwm.c
--- a/dwm.c	Tue Apr 08 11:49:35 2008 +0100
+++ b/dwm.c	Mon Apr 14 18:27:12 2008 +0200
@@ -66,6 +66,7 @@ struct Client {
 struct Client {
 	char name[256];
 	int x, y, w, h;
+	int fx, fy, fw, fh;
 	int basew, baseh, incw, inch, maxw, maxh, minw, minh;
 	int minax, maxax, minay, maxay;
 	long flags;
@@ -285,13 +286,17 @@ arrange(void) {
 	Client *c;
 
 	for(c = clients; c; c = c-next)
-		if(isvisible(c))
+		if(isvisible(c)) {
 			unban(c);
+			if(lt-isfloating || !lt-isfloating  c-isfloating)
+resize(c, c-fx, c-fy, c-fw, c-fh, True);
+		}
 		else
 			ban(c);
 
 	focus(NULL);
-	lt-arrange();
+	if(lt-arrange)
+		lt-arrange();
 	restack();
 }
 
@@ -359,7 +364,7 @@ buttonpress(XEvent *e) {
 			movemouse(c);
 		}
 		else if(ev-button == Button2) {
-			if((floating != lt-arrange)  c-isfloating)
+			if(!lt-isfloating  c-isfloating)
 togglefloating(NULL);
 			else
 zoom(NULL);
@@ -668,15 +673,6 @@ expose(XEvent *e) {
 
 	if(ev-count == 0  (ev-window == barwin))
 		drawbar();
-}
-
-void
-floating(void) { /* default floating layout */
-	Client *c;
-
-	for(c = clients; c; c = c-next)
-		if(isvisible(c))
-			resize(c, c-x, c-y, c-w, c-h, True);
 }
 
 void
@@ -996,8 +992,8 @@ manage(Window w, XWindowAttributes *wa) 
 	/* geometry */
 	c-x = wa-x;
 	c-y = wa-y;
-	c-w = wa-width;
-	c-h = wa-height;
+	c-w = c-fw = wa-width;
+	c-h = c-fh = wa-height;
 	c-oldbw = wa-border_width;
 	if(c-w == sw  c-h == sh) {
 		c-x = sx;
@@ -1015,6 +1011,8 @@ manage(Window w, XWindowAttributes *wa) 
 			c-y = wy;
 		c-bw = BORDERPX;
 	}
+	c-fx = c-x;
+	c-fy = c-y;
 
 	wc.border_width = c-bw;
 	XConfigureWindow(dpy, w, CWBorderWidth, wc);
@@ -1068,8 +1066,12 @@ monocle(void) {
 	Client *c;
 
 	for(c = clients; c; c = c-next)
-		if((lt-isfloating || !c-isfloating)   isvisible(c))
-			resize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw, RESIZEHINTS);
+		if(isvisible(c)) {
+			if(lt-isfloating)
+resize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw, RESIZEHINTS);
+			else if(!c-isfloating)
+tileresize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw);
+		}
 }
 
 void
@@ -1110,8 +1112,11 @@ movemouse(Client *c) {
 ny = wy + wh - c-h - 2 * c-bw;
 			if(!c-isfloating  !lt-isfloating  (abs(nx - c-x)  SNAP || abs(ny - c-y)  SNAP))
 togglefloating(NULL);
-			if((lt-isfloating) || c-isfloating)
+			if(lt-isfloating || (!lt-isfloating  c-isfloating)) {
+c-fx = nx;
+c-fy = ny;
 resize(c, nx, ny, c-w, c-h, False);
+			}
 			break;
 		}
 	}
@@ -1271,10 +1276,16 @@ resizemouse(Client *c) {
 nw = 1

Re: [dwm] fgeom patch

2008-04-14 Thread yy
2008/4/14, yy [EMAIL PROTECTED]:
 2008/4/14, Anselm R. Garbe [EMAIL PROTECTED]:

  On Wed, Apr 09, 2008 at 07:41:53PM +0200, yy wrote:
 As discussed before, this is the patch with the floating geometry
 functionality. I removed some loc in restack, but I had to add more in
 other places to correctly manage mouse actions when in monocle layout
  
  
   I like the restack() simplification.
  


 I have noticed that it lets you to get rid of floating(), saving some
  loc. Have a look at the attached patch.


  
 (isn't a bug the current possibility of moving and resizing windows
 while in monocle layout?).
  
  
   I'd like to keep mouse manipulations dependend on
lt-isfloating, instead of performing a hardcoded floating
layout check.
  


 Well, since I have completely removed the floating layout, it is done
  in base on lt-isfloating in the new patch.


  
 Basically, the patch makes dwm to remember floating geometries when
 you change to tiled or monocle layout.
 I'm not sure about setting fx and fy on tileresize(), but note that if
 you don't do it you will need to add them in movemouse() and
 resizemouse() before togglefloating().
  
  
   Hmm I don't think that tileresize is the right place for setting
fx, and fy.  Instead fx/fy/fw/fh should be used depending on
lt-isfloating in resize and the layout itself, that's why I'd
consider doing the following in struct Client:
  
typdef struct {
...
   int x[2], y[2], w[2], h[2];
...
} Client;
  
#define BOOLTOIDX(x) (x) ? 1 : 0
  
And then in resize:
  
   c-x[BOOLTOIDX(lt-isfloating || c-isfloating)] = x;
   ...
  
etc.
  
Kind regards,
  


 I will think about it once you implement it in hg tip, this new
  version of the patch doesn't touch the client floating geometry in
  tileresize(), I think it works like expected, but I see the possible
  simplification with the BOOLTOIDX method. And you would have the
  possibility of having a #define REMEMBERFLOATS in config.h and then
  BOOLTOIDX(REMEMBERFLOATS  (lt-isfloating || c-isfloating)), so
  that this is configurable... (just rambling).

  slds,


  --


Sorry for the noise, but there were some little errors in the previous
patch. Now it only adds 2 loc (plus 2 from my previous patch, plus 3
layout examples in config.def.h, they should be commented).

-- 


- yiyus || JGL .
diff -r 595ed1a4447c config.def.h
--- a/config.def.h	Tue Apr 08 11:49:35 2008 +0100
+++ b/config.def.h	Mon Apr 14 20:14:32 2008 +0200
@@ -35,8 +35,11 @@ Layout layouts[] = {
 Layout layouts[] = {
 	/* symbol		function	isfloating */
 	{ []=,		tilev,		False }, /* first entry is default */
+	{ =,		tilev,		True },
 	{ []|,		tileh,		False },
-	{ ,		floating,	True },
+	{ |,		tileh,		True },
+	{ ,		NULL,	True },
+	{ [m],		monocle,	False },
 	{ [M],		monocle,	True },
 };
 
diff -r 595ed1a4447c dwm.c
--- a/dwm.c	Tue Apr 08 11:49:35 2008 +0100
+++ b/dwm.c	Mon Apr 14 20:14:32 2008 +0200
@@ -66,6 +66,7 @@ struct Client {
 struct Client {
 	char name[256];
 	int x, y, w, h;
+	int fx, fy, fw, fh;
 	int basew, baseh, incw, inch, maxw, maxh, minw, minh;
 	int minax, maxax, minay, maxay;
 	long flags;
@@ -285,13 +286,17 @@ arrange(void) {
 	Client *c;
 
 	for(c = clients; c; c = c-next)
-		if(isvisible(c))
+		if(isvisible(c)) {
 			unban(c);
+			if(lt-isfloating || c-isfloating)
+resize(c, c-fx, c-fy, c-fw, c-fh, True);
+		}
 		else
 			ban(c);
 
 	focus(NULL);
-	lt-arrange();
+	if(lt-arrange)
+		lt-arrange();
 	restack();
 }
 
@@ -359,7 +364,7 @@ buttonpress(XEvent *e) {
 			movemouse(c);
 		}
 		else if(ev-button == Button2) {
-			if((floating != lt-arrange)  c-isfloating)
+			if(!lt-isfloating  c-isfloating)
 togglefloating(NULL);
 			else
 zoom(NULL);
@@ -668,15 +673,6 @@ expose(XEvent *e) {
 
 	if(ev-count == 0  (ev-window == barwin))
 		drawbar();
-}
-
-void
-floating(void) { /* default floating layout */
-	Client *c;
-
-	for(c = clients; c; c = c-next)
-		if(isvisible(c))
-			resize(c, c-x, c-y, c-w, c-h, True);
 }
 
 void
@@ -996,8 +992,8 @@ manage(Window w, XWindowAttributes *wa) 
 	/* geometry */
 	c-x = wa-x;
 	c-y = wa-y;
-	c-w = wa-width;
-	c-h = wa-height;
+	c-w = c-fw = wa-width;
+	c-h = c-fh = wa-height;
 	c-oldbw = wa-border_width;
 	if(c-w == sw  c-h == sh) {
 		c-x = sx;
@@ -1015,6 +1011,8 @@ manage(Window w, XWindowAttributes *wa) 
 			c-y = wy;
 		c-bw = BORDERPX;
 	}
+	c-fx = c-x;
+	c-fy = c-y;
 
 	wc.border_width = c-bw;
 	XConfigureWindow(dpy, w, CWBorderWidth, wc);
@@ -1068,7 +1066,7 @@ monocle(void) {
 	Client *c;
 
 	for(c = clients; c; c = c-next)
-		if((lt-isfloating || !c-isfloating)   isvisible(c))
+		if((lt-isfloating || !c-isfloating)   isvisible(c)) {
 			resize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw, RESIZEHINTS);
 }
 
@@ -1110,8 +1108,11 @@ movemouse(Client *c) {
 ny = wy + wh - c-h - 2 * c-bw;
 			if(!c-isfloating  !lt-isfloating  (abs(nx - c-x)  SNAP || abs(ny - c-y)  SNAP

Re: [dwm] togglemax substiute in 4.9?

2008-04-09 Thread yy
2008/4/9, Anselm R. Garbe [EMAIL PROTECTED]:
 On Tue, Apr 08, 2008 at 07:52:03PM +0200, Matthias-Christian Ott wrote:
  yy [EMAIL PROTECTED] wrote:
 
   Well, this is my proposal in patch form. I'm not sure about the
   convenience of setting fx and fy in tileresize, but you get the idea.
 
  I posted a similar patch on 31st March, so it is wasted effort.

 Hehe, indeed your both solutions are very close.


I'm not a fan of restoring floating geometries, that's why I didn't
look at Matthias' patch; I just wanted to show how once you implement
it, you don't need to change geometries in focus() to have the wanted
behaviour in monocle. The difference between his patch and mine is
that mine also restore geometries when coming back from monocle.
Anyway, I have already done some changes (but I have them in my
laptop, which I don't have at hand now). One is a check to not modify
geometries with the mouse while in monocle layout when lt-isfloating
is true, the other ones are some little improvements in the previous
patch (I think I even removed some loc). If you are interested I will
send them to the list this afternoon.

greets,

-- 


- yiyus || JGL .



[dwm] fgeom patch

2008-04-09 Thread yy
As discussed before, this is the patch with the floating geometry
functionality. I removed some loc in restack, but I had to add more in
other places to correctly manage mouse actions when in monocle layout
(isn't a bug the current possibility of moving and resizing windows
while in monocle layout?).
Basically, the patch makes dwm to remember floating geometries when
you change to tiled or monocle layout.
I'm not sure about setting fx and fy on tileresize(), but note that if
you don't do it you will need to add them in movemouse() and
resizemouse() before togglefloating().
I don't really like the idea of remembering floating geometries (at
least floating positions), as I don't like the idea of resizing
floating clients in the tile layout (as in monocle) but this is how I
would implement it.

I'd like to hear what do you think, greetings,

-- 


- yiyus || JGL .

PS: The patch adds 15 lines to dwm.c, but 2 of them comes from my
previous patch to viewprevtag() when you try to view the only selected
tag(s).
diff -r 595ed1a4447c dwm.c
--- a/dwm.c	Tue Apr 08 11:49:35 2008 +0100
+++ b/dwm.c	Wed Apr 09 19:18:24 2008 +0200
@@ -66,6 +66,7 @@ struct Client {
 struct Client {
 	char name[256];
 	int x, y, w, h;
+	int fx, fy, fw, fh;
 	int basew, baseh, incw, inch, maxw, maxh, minw, minh;
 	int minax, maxax, minay, maxay;
 	long flags;
@@ -285,8 +286,11 @@ arrange(void) {
 	Client *c;
 
 	for(c = clients; c; c = c-next)
-		if(isvisible(c))
+		if(isvisible(c)) {
 			unban(c);
+			if(!lt-isfloating  c-isfloating)
+resize(c, c-fx, c-fy, c-fw, c-fh, True);
+		}
 		else
 			ban(c);
 
@@ -676,7 +680,7 @@ floating(void) { /* default floating lay
 
 	for(c = clients; c; c = c-next)
 		if(isvisible(c))
-			resize(c, c-x, c-y, c-w, c-h, True);
+			resize(c, c-fx, c-fy, c-fw, c-fh, True);
 }
 
 void
@@ -996,8 +1000,8 @@ manage(Window w, XWindowAttributes *wa) 
 	/* geometry */
 	c-x = wa-x;
 	c-y = wa-y;
-	c-w = wa-width;
-	c-h = wa-height;
+	c-w = c-fw = wa-width;
+	c-h = c-fh = wa-height;
 	c-oldbw = wa-border_width;
 	if(c-w == sw  c-h == sh) {
 		c-x = sx;
@@ -1015,6 +1019,8 @@ manage(Window w, XWindowAttributes *wa) 
 			c-y = wy;
 		c-bw = BORDERPX;
 	}
+	c-fx = c-x;
+	c-fy = c-y;
 
 	wc.border_width = c-bw;
 	XConfigureWindow(dpy, w, CWBorderWidth, wc);
@@ -1068,8 +1074,12 @@ monocle(void) {
 	Client *c;
 
 	for(c = clients; c; c = c-next)
-		if((lt-isfloating || !c-isfloating)   isvisible(c))
-			resize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw, RESIZEHINTS);
+		if(isvisible(c)) {
+			if(lt-isfloating)
+resize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw, RESIZEHINTS);
+			else if(!c-isfloating)
+tileresize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw);
+		}
 }
 
 void
@@ -1110,8 +1120,11 @@ movemouse(Client *c) {
 ny = wy + wh - c-h - 2 * c-bw;
 			if(!c-isfloating  !lt-isfloating  (abs(nx - c-x)  SNAP || abs(ny - c-y)  SNAP))
 togglefloating(NULL);
-			if((lt-isfloating) || c-isfloating)
+			if((lt-arrange == floating) || (!lt-isfloating  c-isfloating)) {
 resize(c, nx, ny, c-w, c-h, False);
+c-fx = nx;
+c-fy = ny;
+			}
 			break;
 		}
 	}
@@ -1273,8 +1286,11 @@ resizemouse(Client *c) {
 nh = 1;
 			if(!c-isfloating  !lt-isfloating  (abs(nw - c-w)  SNAP || abs(nh - c-h)  SNAP))
 togglefloating(NULL);
-			if((lt-isfloating) || c-isfloating)
+			if((lt-arrange == floating) || (!lt-isfloating  c-isfloating)) {
 resize(c, c-x, c-y, nw, nh, True);
+c-fw = nw;
+c-fh = nh;
+			}
 			break;
 		}
 	}
@@ -1294,16 +1310,11 @@ restack(void) {
 	if(!lt-isfloating) {
 		wc.stack_mode = Below;
 		wc.sibling = barwin;
-		if(!sel-isfloating) {
-			XConfigureWindow(dpy, sel-win, CWSibling|CWStackMode, wc);
-			wc.sibling = sel-win;
-		}
-		for(c = nexttiled(clients); c; c = nexttiled(c-next)) {
-			if(c == sel)
-continue;
-			XConfigureWindow(dpy, c-win, CWSibling|CWStackMode, wc);
-			wc.sibling = c-win;
-		}
+		for(c = stack; c; c = c-snext)
+			if(!c-isfloating  isvisible(c)) {
+XConfigureWindow(dpy, c-win, CWSibling|CWStackMode, wc);
+wc.sibling = c-win;
+			}
 	}
 	XSync(dpy, False);
 	while(XCheckMaskEvent(dpy, EnterWindowMask, ev));
@@ -1657,6 +1668,8 @@ tileresize(Client *c, int x, int y, int 
 	if((RESIZEHINTS)  ((c-h  bh) || (c-h  h) || (c-w  bh) || (c-w  w)))
 		/* client doesn't accept size constraints */
 		resize(c, x, y, w, h, False);
+	c-fx = x;
+	c-fy = y;
 }
 
 void
@@ -1856,6 +1869,8 @@ view(const char *arg) {
 		memcpy(seltags, tmp, TAGSZ);
 		arrange();
 	}
+	else
+		viewprevtag(NULL);
 }
 
 void


Re: [dwm] togglemax substiute in 4.9?

2008-04-08 Thread yy
2008/4/8, Anselm R. Garbe [EMAIL PROTECTED]:
 On Mon, Apr 07, 2008 at 01:55:29PM +0200, Joerg van den Hoff wrote:
  as  `togglemax'   seems gone in 4.9: I agree, that `monocle'
  is very useful (and superior). the only problem is  (seems?)
  that one cannot easily toggle back and forth to the previous
  layout. rather, one needs to cycle  through  all  4  layouts
  right now, it seems. this is not so nice...

  question: is their a chance to get a kind of `togglemonocle'
  functionality into dwm without writing it myself? this would
  seem  a frequent demand: activate monocle for some time than
  switch back to tiling (or  whatever  layout  was  in  effect
  previously).

 What about direct layout activation using the layout symbol as
 setlayout argument?

 As for setlayout() I consider having (const char *)-1 for the
 previous layout, (const char *)1 for the next and NULL for
 toggling between the current and previous one, if any.

 The same concept might be adapted for setgeom as well.

 Any complains?


I think that using the proposedlayout function as it was done in the
past would be a better idea (and like it happens with tags if you use
the last patch I've sent to the list), but I don't use different
layouts any more, so my opinion is not important.

  w.r.t.  to `floating': I find it always rather annoying that
  leaving `floating' layout, i.e. going to some tiling layout,
  there is no way of going back to floating while getting back
  the previously manually selected arrangements of windows.  I
  admit,  I  use  `floating'  rarely, but when I do, the above
  behaviour comes into the way quite often.  the problem  with
  destroying   floating arrangements by selecting a diferent
  layout is,  of  course,  especially  severe  because  layout
  changes act global.
 
  question: any chance of making `dwm' remember any `floating'
  positioning information on a per-window  basis  which  would
  enable   restoration   of  positions  when  coming  back  to
  floating layout?

 Actually, I consider making an exception for floating and
 monocle alltogether. Monocle in 5.0 will only work on the
 focused client and restore after each unfocus to the previous
 geometry. So each client will have two geometries, the current
 and the previous one. This allows restoring the geometry when
 switching from tiled to monocle and back, resp. when switching
 from floating to tiled and back or vice versa.

 At manage() time I consider, that the previous geometry is the
 initial geometry as it would be for the floating case.

 Any complains?


If we are coming back to reverse geometries per client, what's the
point of resizing clients in focus changes? I think this will add
unnecesary complexity. But again, I don't think my opinion is
important.

 Kind regards,
 --
  Anselm R. Garbe  http://www.suckless.org/  GPG key: 0D73F361




-- 


- yiyus || JGL .



Re: [dwm] togglemax substiute in 4.9?

2008-04-08 Thread yy
2008/4/8, Anselm R. Garbe [EMAIL PROTECTED]:
 On Tue, Apr 08, 2008 at 01:35:40PM +0200, yy wrote:
  2008/4/8, Anselm R. Garbe [EMAIL PROTECTED]:
   Any complains?
  
 
  If we are coming back to reverse geometries per client, what's the
  point of resizing clients in focus changes? I think this will add
  unnecesary complexity. But again, I don't think my opinion is
  important.

 What if monocle is used to work on floating clients as well?

 I pretty much prefer the solution of only preserving the
 previous window geometry of a client window and not treating
 floating and managed geometries differently. If monocle works on
 all clients, this would lead to unrevertable maximised floating
 clients, which I dislike.

 On the other hand, preserving the geometry for each layout seems
 to be too memory-consuming, especially because the layout
 algorithms are heavily dynamic.


I think I didn't explain myself very well. Let's try again...
To restore all the clients to their previous position and size when
you change to the floating layout you will need a per client reverse
geometry where you store that data, I would call it floating
geometry (e.g.: fx, fy, fw, fh), setted to the initial value by
manage() like you suggested or by a mouse action. Then, when you
change to floating layout, all the clients are resized to that value;
when you change to tiled layout, floating clients are resized to that
value and tiled clients are tiled; and when you select the monocle
layout all the clients (or just the tiled ones, depending on the
lt-isfloating value) are resized to mox, moy, mow, moh.
As a personal preference, I wouldn't restore x and y values in non
floating windows.
I hope to have explained my idea better this time, I can write the
patch if you want to give it a try.

And about the setlayout behaviour, you are right that I was thinking
in the maximize toggle with Mod1-m (or the float toggle with
Mod1-Space), but as I told I don't really matter.

slds,


-- 


- yiyus || JGL .



Re: [dwm] togglemax substiute in 4.9?

2008-04-08 Thread yy
Well, this is my proposal in patch form. I'm not sure about the
convenience of setting fx and fy in tileresize, but you get the idea.


-- 


- yiyus || JGL .
diff -r 595ed1a4447c dwm.c
--- a/dwm.c	Tue Apr 08 11:49:35 2008 +0100
+++ b/dwm.c	Tue Apr 08 18:59:12 2008 +0200
@@ -66,6 +66,7 @@ struct Client {
 struct Client {
 	char name[256];
 	int x, y, w, h;
+	int fx, fy, fw, fh;
 	int basew, baseh, incw, inch, maxw, maxh, minw, minh;
 	int minax, maxax, minay, maxay;
 	long flags;
@@ -285,8 +286,11 @@ arrange(void) {
 	Client *c;
 
 	for(c = clients; c; c = c-next)
-		if(isvisible(c))
+		if(isvisible(c)) {
 			unban(c);
+			if(!lt-isfloating  c-isfloating)
+resize(c, c-fx, c-fy, c-fw, c-fh, True);
+		}
 		else
 			ban(c);
 
@@ -676,7 +680,7 @@ floating(void) { /* default floating lay
 
 	for(c = clients; c; c = c-next)
 		if(isvisible(c))
-			resize(c, c-x, c-y, c-w, c-h, True);
+			resize(c, c-fx, c-fy, c-fw, c-fh, True);
 }
 
 void
@@ -996,8 +1000,8 @@ manage(Window w, XWindowAttributes *wa) 
 	/* geometry */
 	c-x = wa-x;
 	c-y = wa-y;
-	c-w = wa-width;
-	c-h = wa-height;
+	c-w = c-fw = wa-width;
+	c-h = c-fh = wa-height;
 	c-oldbw = wa-border_width;
 	if(c-w == sw  c-h == sh) {
 		c-x = sx;
@@ -1015,6 +1019,8 @@ manage(Window w, XWindowAttributes *wa) 
 			c-y = wy;
 		c-bw = BORDERPX;
 	}
+	c-fx = c-x;
+	c-fy = c-y;
 
 	wc.border_width = c-bw;
 	XConfigureWindow(dpy, w, CWBorderWidth, wc);
@@ -1110,8 +1116,11 @@ movemouse(Client *c) {
 ny = wy + wh - c-h - 2 * c-bw;
 			if(!c-isfloating  !lt-isfloating  (abs(nx - c-x)  SNAP || abs(ny - c-y)  SNAP))
 togglefloating(NULL);
-			if((lt-isfloating) || c-isfloating)
+			if((lt-isfloating) || c-isfloating) {
 resize(c, nx, ny, c-w, c-h, False);
+c-fx = nx;
+c-fy = ny;
+			}
 			break;
 		}
 	}
@@ -1273,8 +1282,11 @@ resizemouse(Client *c) {
 nh = 1;
 			if(!c-isfloating  !lt-isfloating  (abs(nw - c-w)  SNAP || abs(nh - c-h)  SNAP))
 togglefloating(NULL);
-			if((lt-isfloating) || c-isfloating)
+			if((lt-isfloating) || c-isfloating) {
 resize(c, c-x, c-y, nw, nh, True);
+c-fw = nw;
+c-fh = nh;
+			}
 			break;
 		}
 	}
@@ -1657,6 +1669,8 @@ tileresize(Client *c, int x, int y, int 
 	if((RESIZEHINTS)  ((c-h  bh) || (c-h  h) || (c-w  bh) || (c-w  w)))
 		/* client doesn't accept size constraints */
 		resize(c, x, y, w, h, False);
+	c-fx = x;
+	c-fy = y;
 }
 
 void
@@ -1856,6 +1870,8 @@ view(const char *arg) {
 		memcpy(seltags, tmp, TAGSZ);
 		arrange();
 	}
+	else
+		viewprevtag(NULL);
 }
 
 void


Re: [dwm] Monocle question

2008-04-04 Thread yy
2008/4/4, Szabolcs Nagy [EMAIL PROTECTED]:
 On 4/4/08, Dashing [EMAIL PROTECTED] wrote:
  Hi
 
  I use monocle mode a lot, but I don't like how dialog boxes get
  maximized.
 
  I noticed two versions for going through the clients exist:
  * for(c = clients; c; c = c-next)
  * for(c = nexttiled(clients); c; c = nexttiled(c-next))
 
  Why does monocle use the first and not the second?

 the idea was to use monocle as togglemax() which should work on
 floating clients as well

 imho monocle is a perfectly valid layout, not just as a temporary
 maximize in which case the second is more apropriate (i use it that
 way too)



I also think that the second mode is better. As a matter of fact,
that's what I'm currently using. If I want to maximize floating
windows I just toggle floating after setting the monocle layout.
e.g.: when I'm using gimp (which I do very often) sometimes I want my
draw window to be maximized having the toolbars on top of it, but if
monocle maximizes the toolbars windows it makes gimp unusable.
For me, a floating window means: I don't want the tile algorithm to touch it.

my 2 cents,

-- 


- yiyus || JGL .



Re: [dwm] Monocle question

2008-04-04 Thread yy
After looking at the 4.9 release I have a suggestion which could
satisfy most of the people, in dwm.c:1071 you could change the
isvisible(c) condition to (lt-isfloating || !c-isfloating) 
isvisible(c), this way if you want to just maximize tiled windows you
just have to set the float value of monocle in config.h to False, else
you will have the current behavior.

What do you think?


-- 


- yiyus || JGL .



Re: [dwm] ii best practices

2008-04-01 Thread yy
2008/4/1, Matthias-Christian Ott [EMAIL PROTECTED]:
 Anselm R. Garbe [EMAIL PROTECTED] wrote:

   On Tue, Apr 01, 2008 at 03:24:44PM +0200, Matthias-Christian Ott wrote:
I want to start using ii for irc. What discouraged me from doing so was
a proper input method. Currently I know 2 methods to effectively input
text to ii: vim and dinput. I don't like both for some reason.
Do you have any best practices for using ii?
  
   echo(1), I'm not using ii but sic, but I usually create a fifo
   for sending input to sic using echo or sometimes cat(1), if I plan
   to have longer conversations than the usual hello.


 But this would require me to write something like each time I want to
  send something to the channel:

  $ echo 'Hello'  fifo
  # or
  $ cat  fifo
  Hello^D

  Of course you could do:
  $ while true; do cat  fifo; done

  But what about this:

   +---+
   |   |
   |   urxvt   |
   |tail -f fifo   |
   |   |
   |   |
   |...|
   |   input   |
   +---+

  The basic idea is to embedd the urxvt window in another window which also
  embedds an input window. The input window could be urxvt running a small
  programme or small X11 programme reading input and writing to the fifo.
  This is much nicer for tiling and feels more like an irc client.
  You could do this with screen of course.

  Any other ideas?


What I do when I use sic is:
In one dvtm window:
mkfifo /tmp/sicfifo; cat /tmp/sicfifo | sic
In another one:
cat -  /tmp/fifo
And you can also write to sic with:
echo blabla  /tmp/sicfifo
Or even have keystrokes like:
echo `dmenu /dev/null`  /tmp/sicfifo

Or something similar, I'm not testing it.

hth,

-- 


- yiyus || JGL .



Re: [dwm] a lone client could be borderless

2008-03-21 Thread yy
2008/3/21, Ralph E. Carter [EMAIL PROTECTED]:

  When only one client is in a workspace (or tagset, or view),
  it could be borderless.

  In the default geom, or in bottomstack, the border is unnecessary.
  In my favorite monocle, any border would remind that something is
  below.


That's a good idea.

-- 


- yiyus || JGL .



Re: [dwm] found a nice way to do the setgeom stuff

2008-03-19 Thread yy
2008/3/19, Szabolcs Nagy [EMAIL PROTECTED]:
 what's wrong with

 void growm(const char *arg) {
mw += 20;
 }

 ?


shouldn't it be
void growm(const char *arg) {
   mw += 20;
   setgeom(NULL);
}
?

But yes, I think this would be the right thing to do. This way we can
even have a check to not have mw  waw. Or you could use a mwfact
global variable, so you don't lost its value when you change geoms...



-- 


- yiyus || JGL .