2008/8/28, Alexander Polakov [EMAIL PROTECTED]:
What you do?
Press Alt-o which brings my IM-client to me. Then press alt-o to hide it
back.
That is not what I meant.
Such title bars bring a possibility to manage windows
w/o keyboard (;
2 paragraphs before you said mouse is not important.
2008/8/29, Donald Chai [EMAIL PROTECTED]:
I think that mouse is not really important for dwm status bar.
So we can neglect of such feedback.
I can not agree we you that shared libraries and some ABI is so bad.
But agree that it is too heavy for such program as dwm. It is useless
here. On the
2008/8/29, Matthias-Christian Ott [EMAIL PROTECTED]:
If you want to seperate dwm and status bar you have to come up with a
practical protocol.
Definitely! (:
Assumed that dwm still manages the tags and
status bar is just responsible for displaying the data, I propose (not
perfect, just to
2008/8/29, yy [EMAIL PROTECTED]:
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) :
...
This way you could chose workspaces with q, w,...
You could also write a little function to set this parameters and call
Donald Chai wrote:
- tags/workspaces are a straightforward addition to dvtm, since it was
derived from dwm. (I have it mostly working for myself, but I had to rip
out a lot of dvtm-specific things like 'minimize')
Why had you to rip out these things? There is a git branch which
should mostly
Hi Filippo,
2008/8/27 Filippo Erik Negroni [EMAIL PROTECTED]:
In applyrules(), the return value of XGetClassHint is not checked.
Agreed.
ch is also initialised to {0}, which, I believe, is reduntant if
XGetClassHint is successful.
Well, I think we should keep this and also the checks for
Maxim Vuets wrote:
2008/8/29, Donald Chai [EMAIL PROTECTED]:
I think that mouse is not really important for dwm status bar.
So we can neglect of such feedback.
I can not agree we you that shared libraries and some ABI is so bad.
But agree that it is too heavy for such program as dwm. It
Anselm R Garbe wrote:
Hi Filippo,
2008/8/27 Filippo Erik Negroni [EMAIL PROTECTED]:
In applyrules(), the return value of XGetClassHint is not checked.
Agreed.
ch is also initialised to {0}, which, I believe, is reduntant if
XGetClassHint is successful.
Well, I think we should
2008/8/29 Anselm R Garbe [EMAIL PROTECTED]
ch is also initialised to {0}, which, I believe, is reduntant if
XGetClassHint is successful.
Well, I think we should keep this and also the checks for res_class
and res_name, since it is not mandatory to set both or any of these
WM_CLASS
2008/8/29 Anselm R Garbe [EMAIL PROTECTED]
Hi Filippo,
2008/8/27 Filippo Erik Negroni [EMAIL PROTECTED]:
In applyrules(), the return value of XGetClassHint is not checked.
Agreed.
If XGetClassHint is not successful, you cannot make any assumptions about
the values of ch's members.
They
See hg tip for reference. applyrules() is returned if XGetClassHint fails.
Kind regards,
Anselm
2008/8/29 Filippo Erik Negroni [EMAIL PROTECTED]:
2008/8/29 Anselm R Garbe [EMAIL PROTECTED]
Hi Filippo,
2008/8/27 Filippo Erik Negroni [EMAIL PROTECTED]:
In applyrules(), the return value of
Aarm I mean, the applyrules() stuff isn't executed in such a case,
just the current tag is applied.
--Anselm
2008/8/29 Anselm R Garbe [EMAIL PROTECTED]:
See hg tip for reference. applyrules() is returned if XGetClassHint fails.
Kind regards,
Anselm
2008/8/29 Filippo Erik Negroni [EMAIL
- The implementation of tagging is contrary to the suckless
philosophy:
http://www.suckless.org/common/
I agree, however this is because the various functions take char*
arrays
instead of an Arg union. This makes it impossible to specify bit
masks.
We could of course change this but it
Donald Chai wrote:
- The implementation of tagging is contrary to the suckless philosophy:
http://www.suckless.org/common/
I agree, however this is because the various functions take char* arrays
instead of an Arg union. This makes it impossible to specify bit masks.
We could of course change
2008/8/28 Maxim Vuets [EMAIL PROTECTED]:
2008/8/28, Anselm R Garbe [EMAIL PROTECTED]:
The reason for the built-in status bar is simplicity. In theory it would be
possible to externalize it, but then you would end up with adding some
kind of command interface to dwm to aim the mouse interaction
On Fri, Aug 29, 2008 at 10:40 AM, Anselm R Garbe [EMAIL PROTECTED] wrote:
I think that mouse is not really important for dwm status bar.
So we can neglect of such feedback.
I use the mouse quite often in dwm, so for me it is. It feels more
natural to me to right click a tag, than performing
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
Hey, when I do a fresh clone of dwm, I don't see any of the changes
marked as merge in the web interface. Am I doing something wrong?
--
James Turner
BSD Group Consulting
http://www.bsdgroup.org
18 matches
Mail list logo
