Re: [dev] [dwm] [patch] Fix for retarded clients that send unmapnotify events
On 8 August 2011 18:10, Valentin Ochs a...@0au.de wrote:
On Mon, Aug 08, 2011 at 04:43:31PM +0100, Connor Lane Smith wrote:
if((c = wintoclient(ev-window))) {
if(ev-send_event)
setclientstate(c, WithdrawnState);
else
unmanage(c, False);
}
That way we abide by the standard, even if that means we set the state
to Withdrawn when it, well, isn't. I blame Mathematica for that one.
(Valentin, could you check whether this breaks the patch for Mathematica?)
Nope, still works fine.
I'm happy to incorporate those changes. Thanks for your investigation!
Cheers,
--garbeam
Re: [dev] [patch] Xinerama bugfix + map new window *after* arrange(), again
Hi Peter, On 29 July 2011 19:15, Peter Hartlich bq...@hartlich.com wrote: So here's another go at mapping new windows after everything has been arranged. This time, floating windows are stacked correctly and there are no flickers or redraws of the title bar or the new window. The two patches add 8 short lines. Seems not too gross as an interim solution. The line c-mon-sel = c; also fixes a vanilla dwm bug on Xinerama setups: 1. Focus a floating window w belonging to a client c 2. Focus another monitor with focusmon() 3. When c pops up a transient window w' on the unfocused monitor, w' is stacked behind w. For testing, transient.c opens a floating window and then after 5 seconds a transient one. Excellent work Peter! I applied your patches and added the transient driver for debugging purposes (it'll be useful for 6.0 development as well). Let's wait a couple of days and test this further, then I will do a dwm-5.9.1 bugfix release, before going ahead with the 6.0 development. Cheers, Anselm
Re: [dev] [dwm] code cleanup
Hi, On 27 July 2011 00:23, anonymous p37si...@lavabit.com wrote: Fixed patch attached. Thanks, applied. --garbeam
Re: [dev] dwm 5.9 small patch for non xinerama users
On 26 July 2011 15:55, Connor Lane Smith c...@lubutu.com wrote: On 26 July 2011 14:36, mauro tonon tono...@gmail.com wrote: Sorry, i didn't mean the declaration but the pre-declaration or the prototype or how it is called... Yeah, it's missing. (grep says it's the only prototype missing, btw.) Yes, the whole lot xinerama stuff and the Monitor stuff will be decoupled for 6.0. I will incorporate these suggestions and patches. For the xr_* stuff I intend to put it into a separate file as well. Cheers, --garbeam
Re: [dev][dwm] Floating window center position fix
Hi lolilolicon,
On 20 July 2011 17:53, lolilolicon loliloli...@gmail.com wrote:
I have a rule in config.h for MPlayer to always float. The bug was
observed when I played a 720p video whose window was 1280 pixels so it
filled the width of my laptop screen. The MPlayer window was supposed to
be centered, but a border line on the left was clearly visible. For
further confirmation, I set borderpx to 20. My observation was obviously
right. The patch is appended at the end.
Thanks, applied.
Another thing I've observed but didn't care to fix when playing the video:
If the MPlayer window is always created in tag 4 (as per a rule), but I
run the mplayer command in xterm in tag 1, the visibility of the MPlayer
window border depends on some timing:
1) If I switch from tag 1 to tag 4 _after_ the MPlayer window is created,
the border is visible.
2) If I switch from tag 1 to tag 4 _before_ the MPlayer window is created,
the border is invisible. It seems for dwm the border exists, just not
drawn. If I switch to another tag and back, or do a focusstack()
using the default mod1+j combo or pretty about anything, the border
will then be drawn.
Relevant entries in my test config.h are:
static const unsigned int borderpx = 20;
static const Rule rules[] = {
{ MPlayer, NULL, NULL, 1 3, True, -1 },
};
Thanks for your bug report, this needs further investigation.
Cheers,
Anselm
Re: [dev] [dwm] [bug] 5.9's first bug: magic float mode
Hi Peter,
On 11 July 2011 01:02, Peter John Hartman peterjohnhart...@gmail.com wrote:
Actually, this bug goes way back, but I thought I'd be the first to report
it, just to ruin dwm's birthday. The culprit is this chunk of code in
manage():
if(c-w == c-mon-mw c-h == c-mon-mh) {
// c-isfloating = True; pjh
c-x = c-mon-mx;
c-y = c-mon-my;
c-bw = 0;
}
Commenting out that line fixes it.
How you reproduce it is the fun bit.
(1) You have to have borderpx set to 0.
(2) You have to be in monocle mode.
[(3) You might also have to have statusbar hidden.]
(4) Open up a couple of apps.
Now, hit MODKEY+Shift+q, provided you have the dwm loop thing in your
.xinitrc. The windows all come back in floating mode, lovely enough.
Thanks for spotting. I applied it despite the fullscreen rework plans for now.
Current discussion on the mailing list is leaning to just eliminating that
chunk of code. Apparently, flash fullscreen requires it (which I haven't
been able to reproduce!) But why on earth is that code there, and can't
flash fullscreen be handled via a Rule?
I need to investigate when I added this chunk of code to remember why :)
Cheers,
--garbeam
Re: [dev] Re: dwm aesthetic 'bug'
On 19 July 2011 17:49, Connor Lane Smith c...@lubutu.com wrote: And here's a usability bug. (I don't have a patch for this one.) If you have the following clients: A (tag 1) B (tag 2) C (tags 1,2) Whenever you switch from tag 1 to 2, client C will *always* be focused, even if it your last two focused clients were A and B. It seems that dwm chooses to focus C because it's common to both tags, even though it ought to be at the bottom of the focus stack. This results in me having to refocus A or B *every time* I switch tag. That seems broken to me. This is annoying indeed, I'm thinking about a good solution. Cheers, Anselm
Re: [dev] dwm aesthetic 'bug'
On 12 July 2011 15:34, Connor Lane Smith c...@lubutu.com wrote: I noticed a slight aesthetic 'bug' in dwm's tile layout, which can cause the stack to 'shake' when your master changes, if your config.h respects resizehints, because it uses c-w instead of mw. Patch attached. (If I'm honest I don't know what corner case the inline ifs are for.) Thanks, applied. --garbeam
Re: [dev] dmenu-4.4
On 20 July 2011 10:43, ilf i...@zeromail.org wrote: On 07-19 21:48, Connor Lane Smith wrote: tarball: http://dl.suckless.org/tools/dmenu-4.4.tar.gz Thanks for all. Could the releasers please start providing checksums (or PGP signatures) for releases? We coped very well without it for many years, why is the lack of md5 files a concern now? Anyhow, I'm fine to create md5 files for all downloadable tar.gz's that you can check the integrity. If you don't trust our DNS records, I don't intend to go this PGP signing route... Cheers, Anselm
Re: [dev] dmenu-4.4
On 20 July 2011 21:11, ilf i...@zeromail.org wrote: On 07-20 20:52, garbeam wrote: Could the releasers please start providing checksums (or PGP signatures) for releases? We coped very well without it for many years, why is the lack of md5 files a concern now? I always wondered if this had been discussed and rejected or just never thought about. Seems pretty helpful for some basic verification. Also seems good practive in the FLOSS world. Plus there have been cases of pwned and backdoor'd FLOSS repositories/releases. Anyhow, I'm fine to create md5 files for all downloadable tar.gz's that you can check the integrity. Cool! Tough SHA(1|256) seem more reasonable to me. :) Well, what you get is this from now on: http://dl.suckless.org/dwm/md5sums.txt http://dl.suckless.org/dwm/sha1sums.txt This can also be found in other directories. I hate having a sum file per tar.gz... Cheers, --garbeam
[dev] dwm 5.9
Hi there, after exactly 5 years since the first commit into the current dwm mercurial repository I'm glad to announce the new dwm-5.9 release which comes packed with lot's of community driven bugfixes. It can be obtained from the following download URL: http://dl.suckless.org/dwm/dwm-5.9.tar.gz After this release, I plan more radical changes to the multiscreen code for the upcoming 6.0 series. Have fun! Cheers, --garbeam
Re: [dev] [patch] map new window *after* arrange()
On 10 July 2011 03:39, Peter Hartlich bq...@hartlich.com wrote: To prevent the first restack, maybe something like the attached patch? ... which causes the title bar to flicker, as restack calls drawbar before bailing out. Not sure why that's needed. I reverted your map modifications in the 5.9 release. I think this is a good candidate for the upcoming 6.0 series, which will incorporate several structural changes. Cheers, --garbeam
Re: [dev] [patch] map new window *after* arrange()
Hi Peter, On 9 July 2011 00:40, Peter Hartlich bq...@hartlich.com wrote: I reviewed your patch and concluded I can't apply it as is, because focus() would be called twice, once on the unmapped window, and then on again. It seems to me that focusing and arranging should be independent operations. So here comes another patch to remove focus(NULL) from arrange and add it, if missing, everywhere arrange is called after either a window might have vanished from selmon's view, or selmon itself might have vanished. I agree with this and applied both patches. It is not my ideal solution, but I postpone an ideal version for 6.0. All, please test hg tip. If there are no issues this will become 5.9 tomorrow. Cheers, --garbeam
Re: [dev] [patch] map new window *after* arrange()
Hi Peter, I reviewed your patch and concluded I can't apply it as is, because focus() would be called twice, once on the unmapped window, and then on again. I'm thinking about modifying your patch to avoid this. Cheers, garbeam PS: On Sunday there is dwm's official 5th birthday and I consider dedicating the 5.9 release for this purpose :)
Re: [dev] [patch] map new window *after* arrange()
Hi Peter, On 6 July 2011 23:15, Peter Hartlich bq...@hartlich.com wrote: Couldn't dwm map newly created windows *after* they have been moved to their proper position? Less flickering (especially noticeable with the attachabove/attachaside patches), and it feels snappier on a slow computer. I haven't experienced any problems with the attached patch so far. your patch looks alright to me, I intend to apply it. Cheers, --garbeam
Re: [dev] [dwm] sloppy focus
Well, dwm had focus follows mouse since its first minute. I'm not going to change this when it is approaching the age of 5 tomorrow. Cheers, Anselm
Re: [dev] [dwm] sloppy focus
Am 04.07.2011 03:11 schrieb Connor Lane Smith c...@lubutu.com: I don't know about all you, but I find dwm's sloppy focus can be really annoying at times -- focusing a window when I accidentally nudge my atrophying pointer -- and would rather click-to-focus. The great thing about dropping dwm's sloppy focus is it saves 20 lines of code! So how about we make dwm less mousy and a bit simpler, too? No I totally disagree. Click to focus makes the life uneccessary harder. Doing this just for the rare corner case of touching your pointing device by accident doesn't sound like a very sound reason for it. Also there are chances your patch doesn't cover all cases for click to focus behavior correctly. In my impression the proper way would increase LOC overall. But I need to do a detailed look at it first. I appreciate this as a patch though. Cheers --garbeam
[dev] Please test dwm master
Hi there, I'm planning the dwm-5.9 release very shortly, prior to a major overhaul of the multiscreen handling and the draw.c introduction in dwm 6.0. I'd like you to test it and let me know any issues. Thanks in advance, --garbeam
Re: [dev] Cleanup of (hg.)suckless.org - wmii libixp mirror
On 21 June 2011 20:05, Kris Maglione maglion...@gmail.com wrote: On Tue, Jun 21, 2011 at 12:00:06PM -0700, Suraj Kurapati wrote: On Tue 21 Jun 2011 09:54:15 AM PDT, Nick wrote: given that you're disowning wmii, and are skeptical of libixp. I have mirrored wmii and libixp source repositories on GitHub: https://github.com/sunaku/wmii https://github.com/sunaku/libixp There's no need. They've been available on Google Code for some years now: http://wmii.googlecode.com/ http://libixp.googlecode.com/ Ok great, that's good news then. Cheers, --garbeam
Re: [dev] Re: Cleanup of (hg.)suckless.org
On 20 June 2011 07:48, Petr Sabata con...@redhat.com wrote: On Sat, Jun 18, 2011 at 10:33:02PM +0100, garbeam wrote: On 3 June 2011 17:35, garbeam garb...@gmail.com wrote: RELOCATE - last (google code) ?? - libixp (google code) ?? - r9p (google code) ?? - vp (google code) ?? - wmii (google code) ?? - wmiirc-rumai (google code) ?? - skvm (dunno, don't get it) ?? I would like to hear about the status. Are things started to relocate those repos? And why do you want to move them, actually? I don't consider those repositories a good fit with the suckless philosophy anymore and I intend to sharpen the scope of suckless.org. Cheers, --garbeam
Re: [dev] Experimental editor
On 18 June 2011 09:44, Robert Ransom rransom.8...@gmail.com wrote: On Sat, 18 Jun 2011 09:34:42 +0100 garbeam garb...@gmail.com wrote: On 18 June 2011 09:21, pancake panc...@youterm.com wrote: The plan for swk was to move all drawing stuff to draw.c at some point. I will be happy to hear from what you are writing for. I stopped writing it because i didnt wanted to reimplement a text editor stuff.. But i think that conceptually swk can fit well in different emvironments like desktops or phones.. But it really need a rebump to emhace layouts. Another thing is that its redrawing everything all the time. There's no use of damaged areas or so. I was waiting for anselm here. I would like to hear from your project. It looks interesting and it can be a swk2.. Well, my swk conclusion is, that its interface as of now is some yet another GUI TK interface with limitations, but not really what I have concluded it should be. I believe the most important aspect of a potential revised swk is, that it should only be totally text based -- this limitation should be good enough. Starting dealing with bitmaps etc. makes its purpose blurry and might leat to the yet another GUI TK interface idea once again. The closest thing that came to my mind is this idea of seeing swk as a curses replacement. With this, the clients that are written with it, could also run perfectly fine in text mode, but if you have a graphical environment at hand, the implementation could pack the UI more efficiently into graphical use. I really think, the inner workings of such a library should be cursor based, in that regard it is a question of abstracting the cursor movements into a drawing interface and to define higher level stuff using this approach. So the basic thing is a monospaced matrix. This could also be used for a terminal and of course editor... That library already exists -- it's called ‘pdcurses’. We don't need more curses. I did not intend to say it should be curses compliant as this would be a nightmare. I was rather referring to the concept of being cursor and matrix based in the core as this will make a very simple interface, that can work across a range of devices. --garbeam
[dev] Re: Cleanup of (hg.)suckless.org
Hi there again, On 3 June 2011 17:35, garbeam garb...@gmail.com wrote: DELETE - 9libs - diri - genosite - gentoo - godwm - libdraw.old - make - stali-toolchain (this is outdated and better stuff is in the works) - wmii-2.5 (obsolete) - wmii-3 (obsolete) - wmii-3.5 (obsolete) - wmii-3.6 (obsolete) I deleted those repos now. RELOCATE - last (google code) ?? - libixp (google code) ?? - r9p (google code) ?? - vp (google code) ?? - wmii (google code) ?? - wmiirc-rumai (google code) ?? - skvm (dunno, don't get it) ?? I would like to hear about the status. Are things started to relocate those repos? @Kris: Please let me know how much time you need for the transition and if you need any help. I guess a transition could take a couple of months quite easily and requires some time on your side as well. Any news on this please? Cheers, --garbeam
Re: [dev] [dwm] [patch] bugfix in status bar width problem
Hi Rudy, On 13 June 2011 10:45, Rudy Matela r...@matela.com.br wrote: There is a bug in the last version of dwm (verified on 5.8, 5.8.2 and r1549) regarding the bar width. By reading the BUGS file, I can see that it may be similar to the bug reported by voltaic. In my case, it appears whenever I change the orientation (rotation of the monitor). For example: $ xrandr --output LVDS1 --rotate left $ sleep 2 $ xrandr --output LVDS1 --rotate normal The bar is like cut off. I can't see the text in my statusbar. By verifing the code, I saw that dc.drawable is not updated correctly when these rotations happen. So, when changing from 600x800 to 800x600, the dc.drawable keeps the dimension of 600x16 (instead of the necessary 800x16). Attached goes a patch (against revision 1549) that resolves a status bar width problem. It's a quick fix and perhaps the changes I've made should be relocated inside updategeom() function. Maybe this also resolves the issue reported by voltaic. I applied your patch. It seems to be sensible, though a real fix is a bit of reworking the multscreen support, which I plan for 6.0. Cheers, --garbeam
Re: [dev] Re: [dwm] dwm-hg, layouts, setfocus and pertag patch
Hi,
On 25 May 2011 13:26, Nicolas Capit cap...@free.fr wrote:
I think this part of the code comes from the NetActiveWindow feature added
in
hg recently.
I just tried the current hg dwm version and now everytime I click on an URL in
my mailer the tag changes automatically and go where firefox is opened
(firefox
may call the NetActiveWindow).
So it is not a behaviour that I like so I modified a little bit the code:
##
diff -r ba590e72eb2a dwm.c
--- a/dwm.c Sat May 21 20:26:26 2011 +0100
+++ b/dwm.c Wed May 25 14:22:26 2011 +0200
@@ -556,8 +556,10 @@
}
else if(cme-message_type == netatom[NetActiveWindow]) {
if(!ISVISIBLE(c)) {
- c-mon-seltags ^= 1;
- c-mon-tagset[c-mon-seltags] = c-tags;
+ //if(0) {
+ c-isurgent = True;
+ // c-mon-seltags ^= 1;
+ // c-mon-tagset[c-mon-seltags] = c-tags;
}
pop(c);
##
Is it possible to put something in the config.h which will say what to do with
the different netatom like NetActiveWindow (and maybe others) and so everyone
can manage them in config.h? (I think it is not so simple, but...
I like the approach c-isurgent = True, but without the pop(c); The
problem however with your approach is, that c-isurgent will trigger a
clearurgent() on that window once it is focused, which is a bit
unclean.
Best regards,
--garbeam
Re: [dev] Suckless Smartphone?
On 6 June 2011 17:45, Dieter Plaetinck die...@plaetinck.be wrote: non-electronic books suck because you can't easily search in, or copypaste from them. Let's talk again in 40 years if you can still read your ebooks by then :) I stay loyal to real books. --garbeam
Re: [dev] Distribution
On 3 June 2011 12:41, Sir Cyrus sircy...@gmail.com wrote: What's the most suckless Linux distribution? http://bellard.org/jslinux/ --garbeam
[dev] Cleanup of (hg.)suckless.org
Hi there, I'm reviewing the cruft that we have collected during the years at hg.suckless.org and identified some candidates I would like to delete and some other candidates that should be relocated elsewhere: DELETE - 9libs - diri - genosite - gentoo - godwm - libdraw.old - make - stali-toolchain (this is outdated and better stuff is in the works) - wmii-2.5 (obsolete) - wmii-3 (obsolete) - wmii-3.5 (obsolete) - wmii-3.6 (obsolete) RELOCATE - last (google code) ?? - libixp (google code) ?? - r9p (google code) ?? - vp (google code) ?? - wmii (google code) ?? - wmiirc-rumai (google code) ?? - skvm (dunno, don't get it) ?? I think the candidates for deletion raise no questions. The candidates for relocation are mainly wmii related, which I don't consider suckless anymore -- its code base became quite huge and the whole concept to configure a WM through a 9P interface seems overkill after reconsideration. I don't want to be rude, but I really believe that wmii should be hosted at google code, it really does fit better there than on suckless.org. @Kris: Please let me know how much time you need for the transition and if you need any help. I guess a transition could take a couple of months quite easily and requires some time on your side as well. As an alternative, I'd like to suggest that wmii 4.0 could also well share the code of dwm 6.0 without any changes, but I guess such a path won't be of anyones taste. I think with this cleanup, suckless.org will remain more consistent wrt to our philosophy. Please let me know any thoughts on the issue. Also feedback of people that welcome this cleanup is welcome. Cheers, --garbeam
