[dwm] Can someone explain how FONT configuration works in Status Bar?
Hi! /*The following is my experience with DWM in the past 6 hours. If you have no interest, please skip and look at the real questions of mine. */ First, I have to claim that I am not a program at all. DWM is such a project requires programming knowledge, if my questions seem too stupid, please let me know. I have been convert to Linux for a while. First, I was attracted by eyecandies such as Beryl (mainly on KDE). It was the main reason of my switch. I told myself that Linux can beat Windows, just look at the Beryl cube effect. However, the more I use linux, the more I realized that the greatness of linux and thousands of opensource applications doesn't come from the fancy feature, but their SIMPLICITY and SMART DESIGN. So, I felt eyecandies like Beryl sort of violate the simplicity rule. So, I began to try out other WMs, I like E17 very much. Today, I found DWM on Osnews and just apt-get install dwm from (K)ubuntu repo. my first impression of DWM was confusion because I never used something like this. However, I get used to DWM after reading the man page. SO SIMPLE!!! SO FAST and VERY PRODUCTIVE. Also, I was amazed that the source code is only 11k. I will give up on Beryl and stick to this great WM. /*END*/ Well, I cannot wait to try compiling the latest DWM myself although it seems very daunting for me. I removed the DWM in Ubuntu repo and downloaded version 4.2 The compiling process is very easy after read some ABCs on howto install from source code in Ubuntu. Ok, I met my first bug. In DWM, Firefox cannot display Chinese character in statusbar correctly. The symptom seems that it cannot recognize the coding of Chinese characters. Some characters are displayed correctly, but not all. Some are in different fonts (different language). So, I did some research and tried to figure out the problem. Here comes the comments I left in config.h. /* OriginalFONT configuration */ /* #define FONT-*-fixed-medium-r-normal-*-13-*-*-*-*-*-*-* */ /* New FONT configuration referring /etc/gtk/gtkrc.zh_CN This one works! */ /*#define FONT-*-*-medium-r-normal--16-*-*-*-*-*- gb2312.1980-0,*-r-**/ /*Then, I tried to adjust the font size, Hmmm... the size is not the problem, though changing size seemed to change the fonts selection. For an example, which choose 14, the fonts looks like LCD digital watch. So, I suspected that the locale is the problem, so I replaced the gb2312 part with * . Still, it is not the problem */ /*Conclusion :It is the format of the FONT configuation caused the problem. */ /*The following line is the final version which I decided to use*/ #define FONT-*-*-medium-r-normal--16-*-*-*-*-*-*,*-r-* 1. I am wondering if my FONT configuration will work only in Ubuntu or will work in other distro also? 2. My configuration seems not much different from the original line. Can some one explain why my version works? It will be appreciated if someone can give me some reference on linux fonts mechanism. Thanks a lot!
Re: [dwm] Can someone explain how FONT configuration works in Status Bar?
Ok, I met my first bug. In DWM, Firefox cannot display Chinese character not a bug you must select a font which have the proper glyphs for your encoding 1. I am wondering if my FONT configuration will work only in Ubuntu or will work in other distro also? will work if the given font is installed correctly 2. My configuration seems not much different from the original line. Can some one explain why my version works? It will be appreciated if someone can give me some reference on linux fonts mechanism. you can use xfontsel to see which fonts are installed and as you can see there it has an encoding option you must select the proper encoding if you want to see chinese characters ps: you don't have to tell us your life story when you have a problem
Re: [dwm] dmenu with mouse support?
Hi pancake, On Fri, Jun 01, 2007 at 05:45:47PM +0200, pancake wrote: dmenu: - up/down keys act as left/right keys I don't see the point in enabling two different keys for the same thing. - mouse wheel act as left/right keys too - mouse left click activates the selected word - mouse right click closes dmenu (like ESC) I don't see much sense in this proposal for several reasons. First of all dmenu is designed for keyboard input. Second, your proposal would make it necessary to check the pointer position on release every time and calculating the right item under the pointer. This will introduce some bloat, at least yet another 100 LOC, which seems to be too much overkill. Also, such thing might introduce new cornercases and so new bugs. dwm: - mouse wheel on tags allows to change between desktops (without having to click) This is not possible, simply because there is no previous or next tag. Tags are a set of unordered alphanumeric strings. - left click on status bar (where the stdin is printed) executes a program. Which program? - left click on title bar swaps current window between floating and tiled mode - right click on title bar closes the window Those things would be rather simple to achieve, but I'm not sure it is really worth the effort, simply because there are already certain mouse actions on the bar. But your last three proposals seem to be the only ones, which might be considered useful and minor improvements. All others, esp. the dmenu-related proposals seem to be overhead - simply because dmenu is keyboard-driven by design. What i don't know how to do is how to emulate alt+click options (move and resize) or how to zoom a window (alt+intro) without using the keyboard. (I really love these two actions x) There is no way to resize/move windows without the keyboard. The only solution would implementing a builtin menu and do it like 9wm, but honestly, this would mean more bloat, so I don't like it. To your gestures proposal, - I don't like mouse gestures, they are too sloppy for my taste. Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
[dwm] focus changes
I have noticed that when switching between different windows the window under the mouse pointer gets focus for a moment before focusing the right window. The window does not draws the focused border but acts as if it gets focus. I have noticed this opening 5 terminals, letting the mouse pointer on the master area and switching between windows with alt+j and alt+k. The commandline cursor blinks. The same happens when switching between tags. Maybe dwm calls twice to focus when switching between windows based on the mouse pointer position and later using the internal structures of dwm. I have no time to get a look on the source now. Sorry. --pancake
Re: [dwm] focus changes
On Sat, Jun 02, 2007 at 05:04:58PM +0200, pancake wrote: I have noticed that when switching between different windows the window under the mouse pointer gets focus for a moment before focusing the right window. The window does not draws the focused border but acts as if it gets focus. I have noticed this opening 5 terminals, letting the mouse pointer on the master area and switching between windows with alt+j and alt+k. The commandline cursor blinks. The same happens when switching between tags. Maybe dwm calls twice to focus when switching between windows based on the mouse pointer position and later using the internal structures of dwm. No, this is not dwm related, but X reports enter/focusin events to the client windows, so this is the reason why those clients draw themselve looking like accepting input during a glance - but this is only until dwm focuses the right client. (I know that one could grab the server, but this sucks - in usual situations this is a no issue, so there won't be a change.) Regards. -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] Can someone explain how FONT configuration works in Status Bar?
Szabolcs Nagy [EMAIL PROTECTED] wrote: ps: you don't have to tell us your life story when you have a problem oh, I loved to read about his experiences ... he even included this hint for you to skip this first paragraph -- very polite, I think markus
Re: [dwm] Can someone explain how FONT configuration works in Status Bar?
On 6/2/07, markus schnalke [EMAIL PROTECTED] wrote: Szabolcs Nagy [EMAIL PROTECTED] wrote: ps: you don't have to tell us your life story when you have a problem oh, I loved to read about his experiences ... he even included this hint for you to skip this first paragraph -- very polite, I think ok true sorry it was harsh but it's hard to figure out what's the problem if he writes a long mail imho a bug report should be brief and clear he can tell us his story and experiences separately and then there are more chances he'll get simles and love :)
Re: [dwm] Monocle patch for dwm-4.2
XLowerWindow is called for every tiled win at every lt-arrange() call which moves the window back in the X window stack this is not a problem for other tiled layouts or when only one window is visible, but when we have more windows all the hidden windows got an Expose event which causes annoying blinking eg it occures whenever a popup dialog appears or disappears solutions: ban() the invisible windows or don't call restack (it may cause problems with floating windows but i don't use many) btw i like this layout very much, it can be used as togglemax for tiled windows
Re: [dwm] Monocle patch for dwm-4.2
On (02/06/07 22:51), Szabolcs Nagy wrote:
XLowerWindow is called for every tiled win at every lt-arrange() call
which moves the window back in the X window stack
this is not a problem for other tiled layouts or when only one window
is visible, but when we have more windows all the hidden windows got
an Expose event which causes annoying blinking
eg it occures whenever a popup dialog appears or disappears
solutions: ban() the invisible windows or don't call restack (it may
cause problems with floating windows but i don't use many)
btw i like this layout very much, it can be used as togglemax for tiled
windows
I know this problem for a long time, but this is not easily solvable. If
every windows which is visible!focused !floating is banned too,
the focus() MUST be changed too, to unban focused window, this is imho
the best solution. Other solution is not calling restack() and do some
sort of Inteligent Restack (TM) :DD but hey, this will render monocle()
to be not only the layout manager ;(. I'm thinking about both solutions
for some time but i don't have much spare time to solve it, maybe in
next ~2 weeks ;).
But if we do feel of mouse focus of floating windows same as keyboard
focus - mouse focused floating window will be on top (so, in enternotify
after calling focus(c) there will be restack() too), some sort of
incrementaly restacking can be done, and the whole restack() can be
thrown away. There are only few actions which change stack order:
enternotify+keyboard focus change, managing of new window,
resizing/moving with window. Instead of this, there will be
restackfocused() called on the changed/added client
this can look like this:
restackfocused()
{
XEvent ev;
drawstatus(); /* Maybe not needed? */
if(!sel)
return;
if(sel-isfloating || lt-arrange == floating)
XRaiseWindow(dpy, sel-win);
else
XLowerWindow(dpy, sel-win);
XSync(dpy, False);
while(XCheckMaskEvent(dpy, EnterWindowMask, ev));
}
So, if that thinkg with mouse focusing is acceptable (and why not? there
will be then same behaviour while focusing with keyboard or mouse) then
this can be simplification and speedup too. (and it will solve blinking
windows in monocle layout too ;D).
So arg, is THIS acceptable to you?
PS: sorry for that longthy letter ;)
--
Premysl Anydot Hruby http://na.srck.net
Re: [dwm] Monocle patch for dwm-4.2
On (02/06/07 23:55), Anydot wrote: I know this problem for a long time, but this is not easily solvable. If every windows which is visible!focused !floating is banned too, the focus() MUST be changed too, to unban focused window, this is imho the best solution. Other solution is not calling restack() and do some This is not solution too, because if we focus enought window in turn, the blinking will be back. So in focus, the old selected window must be banned if lt==monocle !c-isfloating c != previous selected client. And this is very very DIRTY HACK -- Premysl Anydot Hruby http://na.srck.net
Re: [dwm] Monocle patch for dwm-4.2
I know this problem for a long time, but this is not easily solvable. If
ok i didn't think much about the problem previously
sort of Inteligent Restack (TM) :DD but hey, this will render monocle()
yes probably restack should be rethinked because sometimes it is
called unnecessaryly in lt-arrange() (togglebar, inc(n)master(w),
zoom, configurenotify, ..).
restackfocused()
{
XEvent ev;
drawstatus(); /* Maybe not needed? */
if(!sel)
return;
if(sel-isfloating || lt-arrange == floating)
XRaiseWindow(dpy, sel-win);
else
XLowerWindow(dpy, sel-win);
XSync(dpy, False);
while(XCheckMaskEvent(dpy, EnterWindowMask, ev));
}
it looks ok, but if the focused tiled window is lowered then that's
still not good for monocle (or fullscreen as it's called in my src)
may be XRestackWindows[1] can be used to place the tiled window
exactly where we want (below the floating layer but on top of the
tiled windows)
or we can call a full restack when a tiled window appears and do
nothing with it in restackfocused()
well it still needs some thinking (it would be easier if the X window
stack could be manipulated more straightforwardly)
[1]: http://tronche.com/gui/x/xlib/window/XRestackWindows.html
[dwm] Anyway to launch a program with specific tags?
Hi! Is there a command to launch a program from console (xterm) and assign certain tag number(s) to that program at the same time. Thanks.
Re: [dwm] focus changes
No, this is not dwm related, but X reports enter/focusin events to the client windows, so this is the reason why those clients draw themselve looking like accepting input during a glance - but this is only until dwm focuses the right client. Does dwm can get the focused window by the pointer and switch to it directly? this will fix some issues like when you click on the roster list and the window gets focus (at x11 level), but dwm does not changes the focused window. This can be assumed as a bug or a feature :) (I know that one could grab the server, but this sucks - in usual situations this is a no issue, so there won't be a change.) Yup. maybe. --pancake
Re: [dwm] Anyway to launch a program with specific tags?
On (02/06/07 17:14), Ning Bao wrote: Hi! Is there a command to launch a program from console (xterm) and assign certain tag number(s) to that program at the same time. Thanks. There's no way as you tag WINDOWS not the program. And WM can get anything from the program's environment (for example). It was once discussed here, iirc. -- Premysl Anydot Hruby http://na.srck.net
Re: [dwm] Monocle patch for dwm-4.2
On (03/06/07 01:22), Anydot wrote: hm, with XRestackWindows we will get bunch of problems and it will bloat code as there must be then malloc-ed memory and then filled with windows from snext linked list in right order. All we need is some form of layers on for raising up floating windows while second for raising up !floating windows. Is there something like this in Xlib? We can use XRaiseWindow for floating windows and: XWindowChanges wc; wc.sibling = barwin; wc.stack_mode = Below; XConfigureWindow(dpy, c-win, CWSibling | CWStackMode, wc); to raise focused window right below barwin, so in this way, we easily get sort of 2 layers, one for floating windows on top and one for other, non-floating clients. Between them, the barwin is placed. So imho whole this way with throwing restack() away is imho now solvable and it will (imho) easy and clear many things (the code get even smaller and quicker). and as side-efect flicker in monocle will disappear (the flicker is imho observable in tile mode + some isfloating windows, but is not so obvious). -- Premysl Anydot Hruby http://na.srck.net
Re: [dwm] Anyway to launch a program with specific tags?
On Sun Jun 03, 2007 at 02:37:35AM +0200, Anydot wrote: On (02/06/07 17:14), Ning Bao wrote: Hi! Is there a command to launch a program from console (xterm) and assign certain tag number(s) to that program at the same time. Thanks. There's no way as you tag WINDOWS not the program. And WM can get anything from the program's environment (for example). It was once discussed here, iirc. it was suggested that X resources could carry tag information.. my only missing need is getting stuff launched with the right tags.. in a flat file that can be edited without recompiling source and mucking around finding the right regex matches..think 'dynamic' config.. -- Premysl Anydot Hruby http://na.srck.net
