[dwm] horizontal/vertical tiling behaviour
Hi, I'm using the latest dwm version from the repository and I noticed the following behaviour when switching between vertical and horizontal tiling. When in vertical tiling mode and then pressing mod-h and then repeatedly pressing mod-h the tiling toggles between horizontal and vertical. The same can be done with mod-v. From the function names in config.h I assume this is not the intended behaviour? cheers, Anthony
Re: [dwm] java 7 and dwm
On Tue, Jan 22, 2008 at 12:07:51PM +0100, Richard Pöttler wrote: With this Java and dwm-4.7, I'm still getting the gray windows. java -version java version 1.7.0 IcedTea Runtime Environment (build 1.7.0-b21) IcedTea Client VM (build 1.7.0-b21, mixed mode, sharing) Any suggestions? Is IcedTea based on the Sun source code? According to [1], yes (at least most of the parts, it seems): The JDK I tried is: java version 1.7.0-ea Java(TM) SE Runtime Environment (build 1.7.0-ea-b24) Java HotSpot(TM) 64-Bit Server VM (build 12.0-b01, mixed mode) cheers, Anthony
[dwm] java 7 and dwm
Hi All, FYI: I just downloaded and early binary release of JDK 7 and it looks like the new Java version behaves properly with dwm (using 'standard' dwm-4.7). I tried using some Gui apps that gave me the infamous grey windows with Java6 (or Java5 without setting AWT_TOOLKIT=MToolkit) and so far no problems occured. cheers, Anthony
Re: [dwm] column layout revival?
Hi Anselm, I never really view more than 1 tag at a time so I would certainly be interested in giving your suggestions a try. cheers, Anthony On Tue, Sep 04, 2007 at 05:57:49PM +0200, Anselm R. Garbe wrote: A couple of weeks ago I decided to cancel my mail concerning about changing dwm the wmii-way somewhat, because I got afraid for some reason. But now I wanna ask you as dwm-community, what do you think about the idea to change dwm more into the wmii-way? What I have in mind from time to time, esp. when being forced to work with a standard resolution monitor is, that I'd like to see the basic wmii column layout - but without column modes (simply equal) and without all other clunk. To achieve this, we would loose the ability to view more than one tag - but gaining the layout preservation on the other side and having a real column layout, which means allowing to move windows between the columns left- and right-wards (which may create new columns) resp. up- and down-wards to move them in the stack. For simplicity reasons I won't like to see any layout modes (they won't work anyways with decor-less windows). So what do you think about this idea? Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] Please test hg tip
On Tue, Feb 13, 2007 at 03:02:50PM +0100, Anselm R. Garbe wrote: On Tue, Feb 13, 2007 at 02:28:48PM +0100, Anthony Brown wrote: On Tue, Feb 13, 2007 at 01:49:16PM +0100, Anselm R. Garbe wrote: I made configurerequest() simplier, so please test hg tip, would like to know if dwm behaves still correctly. For me it works so far correctly (having tested gvim, emacs, ff, mplayer, uxterm)... If there are no complains I'll release 3.5 in the evening... Hi, I have a problem with gvim. It starts up fine but as soon as a switch to a different tag the window is resized to a size larger than the screen size (I start gvim with a keyboard shortcut, specifying a geometry and position for the window). Please recheck, I pushed a fix. Yes, works fine now, I also tested a few other floating apps and found no problems. cheers, Anthony
Re: [dwm] Please test hg tip
On Tue, Feb 13, 2007 at 03:02:33PM +0100, Anselm R. Garbe wrote: On Tue, Feb 13, 2007 at 03:57:22PM +0200, Can Burak Cilingir wrote: On Tue, Feb 13, 2007 at 01:49:16PM +0100, Anselm R. Garbe wrote: I made configurerequest() simplier, so please test hg tip, would like to know if dwm behaves still correctly. For me it works so far correctly (having tested gvim, emacs, ff, mplayer, uxterm)... If there are no complains I'll release 3.5 in the evening... Regards, I do not have idea about the code background ow dwm, but I spotted a bug. http://www.canb.net/s/tmp/dwm-firefox/ I get a fresh dwm copy, and confirmed the bug. Hehe, that is a great bug report! Thanks for your work. I think I fixed it in hg tip. Please recheck. Just out of curiousity I tried the same thing with seamonkey (using hg tip) and after closing the second window the one in the master area gets resized to the whole screen, so far so good, but then when I press F11 it occupies only the master area (the stack area shows the remnants of the full screen seamonkey window and when I switch to another tag and then back the stack area shows whatever was there in the other tag). Anthony
Re: [dwm] Please test hg tip
On Tue, Feb 13, 2007 at 05:41:52PM +0100, Anselm R. Garbe wrote: Hehe, that is a great bug report! Thanks for your work. I think I fixed it in hg tip. Please recheck. Just out of curiousity I tried the same thing with seamonkey (using hg tip) and after closing the second window the one in the master area gets resized to the whole screen, so far so good, but then when I press F11 it occupies only the master area (the stack area shows the remnants of the full screen seamonkey window and when I switch to another tag and then back the stack area shows whatever was there in the other tag). I believe the F11 handling in ff is totally broken, I can't speak of seamonkey, but F11 does not respects the client window geometry in all cases as far as I tested it. And I believe it is not a dwm issue, because it also occures in earlier dwm issues and in other wms, which I tested so far. Well, it's not a useful sequence of operations in any case, so not much to worry about I guess. Anthony
Re: [dwm] uriel sez the default config is retarded
On Fri, Feb 09, 2007 at 10:32:35AM +0100, Anselm R. Garbe wrote: So out of curiosity, I ask, who uses the default config? And if not, what changes do you make (you can diff the default config to mine, I use dmenu and some different shortcuts). Maybe it would be time to rethink some values of the default config, esp. some shortcuts? 1. You stick with default config? 2. You basically stick with default config, but a) use different colors/font b) use dmenu c) use some different shortcuts d) use more rules 3. You use totally different shortcuts? 4. You use totally different config? Hi Anselm, Option 2 in my case. I use dmenu and have my specific shortcut for a new xterm. Otherwise I only change the colours and add rules for clients that I often use that need to be in float mode. regards, Anthony
Re: [dwm] Again client titles and nmaster indicator
On Sun, Jan 14, 2007 at 07:33:42PM +, David Tweed wrote: Anyway, the nice thing about title windows is that they provide the SAME visual interface for various applications. For example, my xterms are configured with only a $ as the visible prompt and put the current directory into the window title; otherwise I'd have to find the line with the cursor on to find out what the current directory is. With vim, if the current file isn't put in the title I've got to find it on the line at the bottom of the screen. With an document viewer (eg, evince, etc) I've got to open the file menu. Etc. The point I'm trying to make here is that there's a different thing to do to find out the window title for each application, rather than one global action for all the applications. That's why window managers ( to an extent toolkits) exist right? So each application doesn't define it's own way of performing common acitons like moving windows, etc. Anway, I wouldn't object to titles being configured out by default but I don't see much actual practical gain (as opposed to LOC bragging) in removing the code. I agree that window title bars remain very useful, even if they are annoying sometimes for small windows. I do like the added visual clue for focus with a different border colour. I see now that the status area has the same colour as the unselected tags. In previous versions my colours for the status area were the reverse from those for unselected tags, making the status area stand out more. Maybe you could consider such a reverse video scheme for the status area? (I admit this depends on the colour scheme one uses) cheers, Anthony
Re: [dwm] Java Saga Continues...
On Wed, Dec 20, 2006 at 09:35:50PM -0500, Pavel Tatashin wrote: Good day everyone! I understand Arg has done a good investigation into Java problem, but it is still an actual problem. To set AWT_TOOLKIT=MToolkit Is a good solution until you need to use Java's drag 'n drop operations. I spent half night debugging my JTree to find out that DnD does not work because of Java vs. DWM issues... Is this is not enough? Well here is a more serious problem on Java's side. If AWT_TOOLKIT=MToolkit is set Java VM 6, 64 bit version segfaults... At least on Linux (checked with FC6) (JDK 5 64 bit works fine) While the later one is purely Sun's fault, has anyone found a solution to the first issue? I so got used to DWM and really hate to start other WM just to work on my project.. :-( Same here, on my amd64 system with Java6 and MToolkit my java app crashes. Without MToolkit the behaviour of the app (reaction to menu button clicks) is not quite as I would expect so Java6 seems to have even more problems with dwm. I seem to remember from what I read on Sun's web pages that MToolkit will be removed from Java in the future (maybe it's already gone) so this problem will remain. cheers, Anthony
Re: [dwm] Java Saga Continues...
On Thu, Dec 21, 2006 at 12:44:28PM +0100, Anselm R. Garbe wrote: On Thu, Dec 21, 2006 at 12:41:03PM +0100, Anselm R. Garbe wrote: On Thu, Dec 21, 2006 at 12:15:42PM +0100, Sander van Dijk wrote: On 12/21/06, Anselm R. Garbe [EMAIL PROTECTED] wrote: I fear there is no simple solution unless Sun don't fixes the JDK properly. Introducing frames for each client would mean much more resource consumption of X, and the dwm codebase would get more complex - one would need to change nearly all resize-related stuff, manage() and unmanage(), besides extending Client struct with Client-fwin. Just a (probably silly) idea: would reparenting to the parent help? I haven't read Sun's sources myself, but from what I understand these java progs discard all configurenotify's and resizes if they are not reparented (or rather, _until_ they are reparented). If one would reparenting such a window to what already is its parent, this java stuff might still react to the ReparentNotify this generates. For the rest nothing would change, so dwm's codebase wouldn't need to change any further. If this works, a nice /* stupid hack to work around java issue */ above the code would suffice I think. Note that I don't really have a clue about this stuff, so this might all be nonsense; decided to share it anyway in case it isn't garbage though :-) I checked this already a while ago, but no that won't help. In the Java Odyssey discussion I pointed to the Insets method, which performs an XQueryTree(3X11) to check the window hierarchy. We need a real parent window which is not the root window. One ugly trick which comes to my mind is, using a parent window for all, which is not the root window. This could be a solution, but I'm not sure about its impacts yet. Will investigate further during 23c3 into this issue. Nah nah nah, when remembering how the insets were calculated, that's not a solution... This stupid Java crap would determine a window decoration of the rest screen space which is not covered by a client window in such a situation. I don't think dwm should be adjusted to the fact that Java developers did such a poor job at writing the backend for X. Complaints should be directed to Sun. That's of course all fine as a principle but in the meantime some sort of practical solution would be nice (although for now continuing with Java5 is just fine). I'll try and experiment a bit more over the holliday period. cheers, Anthony
Re: [dwm] Please check no-gravitate() hg tip
On Tue, Dec 12, 2006 at 07:55:43AM +0100, Anselm R. Garbe wrote: I'd like to see people testing hg tip, I removed gravitate(). Does this break anything? Hi Anselm, Worked without gravitate() for a whole day now (using xterms, seamonkey, vim, eclipse, acrobat) and didn't notice any problems so far. Anthony
Re: [dwm] Fwd: Re: dwm + java
On Fri, Dec 08, 2006 at 10:52:17AM +0100, Anselm R. Garbe wrote: - Forwarded message from Anselm R. Garbe [EMAIL PROTECTED] - Date: Fri, 8 Dec 2006 10:51:50 +0100 From: Anselm R. Garbe [EMAIL PROTECTED] To: Sander van Dijk [EMAIL PROTECTED] Subject: Re: dwm + java User-Agent: Mutt/1.5.9i Another idea which could be related to it? Maybe this Java toolkit stuff has trouble if the client window border is set to 1px? That might also be an interesting check, because it might be that those apps work fine without a WM, because in such a situation no border is set (however, usually any WM sets the border of client windows at least to 0). Regards, Anselm Hi Anselm, Does this require a straightforward change to the DWM code (setting the border to 0px or not setting a border)? I'd be happy to test what the affect on my Java app would be. regards, Anthony
Re: [dwm] Fwd: Re: dwm + java
On Fri, Dec 08, 2006 at 12:30:01PM +0100, Anselm R. Garbe wrote: On Fri, Dec 08, 2006 at 12:21:56PM +0100, Anthony Brown wrote: On Fri, Dec 08, 2006 at 10:52:17AM +0100, Anselm R. Garbe wrote: - Forwarded message from Anselm R. Garbe [EMAIL PROTECTED] - Date: Fri, 8 Dec 2006 10:51:50 +0100 From: Anselm R. Garbe [EMAIL PROTECTED] To: Sander van Dijk [EMAIL PROTECTED] Subject: Re: dwm + java User-Agent: Mutt/1.5.9i Another idea which could be related to it? Maybe this Java toolkit stuff has trouble if the client window border is set to 1px? That might also be an interesting check, because it might be that those apps work fine without a WM, because in such a situation no border is set (however, usually any WM sets the border of client windows at least to 0). Regards, Anselm Hi Anselm, Does this require a straightforward change to the DWM code (setting the border to 0px or not setting a border)? I'd be happy to test what the affect on my Java app would be. No, I think consider all places which match 'Border' being uncommented (and in manage being set to 0 instead of 1)... But I'm not sure those Java apps really have problems with border=1... Let me know! Hi, I changed the value of BORDERPX in dwm.h to 0 and then to 3, this has no effect on the Java app. Without setting AWT_TOOLKIT to MToolkit I still get the same problems. I will do the other test later when I have more time on my hands. cheers, Anthony
Re: [dwm] unicode characters in status
On Thu, Dec 07, 2006 at 10:23:43AM +0100, Anselm R. Garbe wrote: Hi there, I've good news, I believe I have fixed all locale/UTF-8 related problems in dwm and dmenu. Actually for me it works fine, if I use en_US.UTF-8 as locale and the terminus-UTF-8 capable font. All glyphs are rendered correctly when visiting following URLs with firefox in the dwm title rendering: http://www.goettingen.de http://www.kk.dk http://saint-petersburg.ru The following does not work: http://www.beijing.cn/ (but related to terminus font that does not contain fontsets for chinese) Well, how does the fix look like? I moved the setlocale(LC_CTYPE, ); from draw.c to main.c, and I use locale.h instead of Xlocale.h - basically that's all already. Xlib seems to work improperly if that is not done explicitely... Yep, works for me (I can't check the russian though, no cyrillic fonts installed). thanks! Anthony
Re: [dwm] unicode characters in status
On Thu, Dec 07, 2006 at 12:20:00PM +0100, Anselm R. Garbe wrote: I'm not sure if something like a -u toggle for dwm and dmenu could be considered useful for such people, which has the effect to disable the whole locale/UTF-8 handling. But who uses such locales still today? Or in other words, who uses a font which is not compatible with the locale in use? Shall we ignore the problem? Hi, I think the best way to tackle this issue is to point the fonts/locale issue out in the manpages for dwm and dmenu (or in a readme) so that people are at least encouraged to look into their font setups before complaining about dwm. I have had lots of trouble in the past with font in other WMs and at least with dwm things are relatively simple (if one is happy with a font like terminus and simple xterms). I don't think dwm should try to anticipate all possible font/locale setups. Given that dwm will be used by people who are already happy to configure and compile it by themselves, they should also be willing to invest a little effort in getting the fonts right. cheers, Anthony
Re: [dwm] tag-used indicator dots
On Fri, Dec 01, 2006 at 04:54:25PM +0100, Anselm R. Garbe wrote: On Fri, Dec 01, 2006 at 04:53:45PM +0100, Anselm R. Garbe wrote: On Fri, Dec 01, 2006 at 04:26:22PM +0100, Sander van Dijk wrote: On 12/1/06, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Fri, Dec 01, 2006 at 03:29:11PM +0100, Antoni Grzymala wrote: Making a release? No, let's wait some days... This change needs a mental settle first ;) Hm, this is better than the full rectangle, yet I find it visually unpleasing; I'd like to see the following (I'd already have tried it if I were at a unix box, but I am not): - dot in the bottom right. - line on top 3/4 width, line on the left side 1/2 height, both 1 px from the side, joining at the topleft corner. This would be pretty much like some of the stuff we've seen today, but less 3d and maybe nicer to see than the current situation (basically I just don't like the line being angleless). Yeah, I also don't feel so well with the hg tip atm. I got a different idea, which basically would work as follows: - no dot at all - tags of focused client are indicated through border and bottom s/border/top/ Hi Anselm, This does not work for me. It's not clear to which the tags the vertical lines belong and I find I have to look at the status bar longer to figure out what's going on. The original set-up with the dots was quite satisfactory as far as I'm concerned. A combination of dots for occupied tags and a rectangle for the tags of the focussed client is also okay but more obtrusive than just the dots. cheers, Anthony
Re: [dwm] Interesting idea by Gottox
On Thu, Nov 30, 2006 at 10:54:27AM +0100, Enno Gottox Boland wrote: Hi! I don't want to get rid of view() completely. I only wouldn't use it in my environment anymore, because it let me work in a workspace way. I don't think kicking view out of the main distribution is the way to make non-power-users happy. My idea is to make it easier to work only the tagging way. Not to make it difficult to use dwm's tags as workspaces. Hi, I basically use tags as workspaces, i.e., as a way to organize the clients depending on what they are used for. So for me removing view() would be annoying, although I could live with it if the CTRL would be dropped from the shortcut for adding/removing clients from the view (to keep the number of keystrokes down). (I know I could configure this myself but it would be a nice default if view() is removed.) cheers, Anthony
