Anselm R. Garbe dixit (2007-12-08, 20:16):
Hi there,
I implemented a reapply() function which is bound to Mod1-r by
default in config.def.h. It unsets all tags of all clients and
performs an applyrules() on each client in the global client
list. Afterwards it calls arrange().
Let me
Well, the only thing which is missing that dwm keeps state of
the currently selected tags. The idea is that dwm putenv's the
currently selected tags whenever they change and a newly spawned
dwm instance looks for that environment variable and pre-selects
those tags. Then a clean restart will
There comes my old idea into mind to implement a tiny command
language understood by the status text reader, e.g. to provide a
very basic configuration interface -- which would work similiar
to wmii's ctl files. One could do:
tag=2
status=foo bar baz
selcolor=#336677
etc.
Does that make
On Dec 6, 2007 11:23 AM, Anselm R. Garbe [EMAIL PROTECTED] wrote:
Ok, but the DWMTAGS idea is ok for everyone?
Would that work? If the new dwm is a child of the old one it would,
but when the dwm restart is controlled by a shell loop such as
while true
do
dwm
done
I believe this wouldn't
Ok, but the DWMTAGS idea is ok for everyone?
it's ok. how about saving the state for viewprevtags, too, in a similar
manner?
Mate
Anselm R. Garbe dixit (2007-12-06, 09:54):
This way, when I do a total mess with tagging and floating my clients
(sometimes it happens and I get lost) I could get my everyday dwm state
with one keystroke or command.
Well, the only thing which is missing that dwm keeps state of
the
Sander van Dijk [EMAIL PROTECTED] writes:
On Dec 6, 2007 11:23 AM, Anselm R. Garbe [EMAIL PROTECTED] wrote:
Ok, but the DWMTAGS idea is ok for everyone?
Would that work? If the new dwm is a child of the old one it would,
but when the dwm restart is controlled by a shell loop such as
n Dec 6, 2007 5:23 AM, Anselm R. Garbe [EMAIL PROTECTED] wrote:
On Thu, Dec 06, 2007 at 11:18:49AM +0100, Sander van Dijk wrote:
On Dec 6, 2007 10:06 AM, Marc Andre Tanner [EMAIL PROTECTED] wrote:
No. At least not in my opinion, please keep it simple stupid.
Thanks for the excellent
On Dec 6, 2007 10:07 AM, Ritesh Kumar [EMAIL PROTECTED] wrote:
n Dec 6, 2007 5:23 AM, Anselm R. Garbe [EMAIL PROTECTED] wrote:
On Thu, Dec 06, 2007 at 11:18:49AM +0100, Sander van Dijk wrote:
On Dec 6, 2007 10:06 AM, Marc Andre Tanner [EMAIL PROTECTED] wrote:
No. At least not in my
Anselm R. Garbe [EMAIL PROTECTED] wrote:
There comes my old idea into mind to implement a tiny command
language understood by the status text reader, e.g. to provide a
very basic configuration interface -- which would work similiar
to wmii's ctl files. One could do:
[...]
I'm planning to
On Thu, Dec 06, 2007 at 10:56:56AM +, Chris Webb wrote:
Sander van Dijk [EMAIL PROTECTED] writes:
On Dec 6, 2007 11:23 AM, Anselm R. Garbe [EMAIL PROTECTED] wrote:
Ok, but the DWMTAGS idea is ok for everyone?
Would that work? If the new dwm is a child of the old one it would,
On Thu, Dec 06, 2007 at 08:42:03PM +0100, Szabolcs Nagy wrote:
On 12/6/07, Anselm R. Garbe [EMAIL PROTECTED] wrote:
dwm is not intended being restarted that frequently which would
justify tag persistence in an X property based way.
what about a store_state function (can be user defined in
On Thu, Dec 06, 2007 at 05:32:58PM +, Robert Figura wrote:
So the next interesting thing would be to implement the other way
around: Let dwm print events like focus change, window creation and
maybe some more on stdout.
I've always thought this would be fun, in order to implement tracking
On 12/6/07, Anselm R. Garbe [EMAIL PROTECTED] wrote:
On Thu, Dec 06, 2007 at 08:42:03PM +0100, Szabolcs Nagy wrote:
for restore_state some kind of startup event handler is needed in
config.h (pressing keys for restoring is a bit uncomfortable)
Only as a patch, not as mainstream
Hi,
Let me think about this proposal. Restarting dwm should do the
job, maybe it's a good idea to have a restart function in
opposite to quit as well.
Regards,
Anselm
On Wed, Dec 05, 2007 at 12:44:38AM +0100, Antoni Grzymala wrote:
Hi,
just came across another idea. How about
Hi,
just came across another idea. How about implementing a function in dwm
that would reapply all the predefined rules (float/non-float, tagging)
to all clients in a dwm session.
This could either be a function bindable to a keystroke, or dwm reacting
to a signal (say, HUP), or what not.
This
antoni:
Hi,
just came across another idea. How about implementing a function in dwm
that would reapply all the predefined rules (float/non-float, tagging)
to all clients in a dwm session.
This could either be a function bindable to a keystroke, or dwm reacting
to a signal (say, HUP), or
On Dec 4, 2007 6:44 PM, Antoni Grzymala [EMAIL PROTECTED] wrote:
Hi,
just came across another idea. How about implementing a function in dwm
that would reapply all the predefined rules (float/non-float, tagging)
to all clients in a dwm session.
This could either be a function bindable to a
18 matches
Mail list logo
