[dev] [dwm] [patch] bugfix in status bar width problem
Hello,
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.
Regards,
Rudy
diff -r d7ffa0c01b44 -r e03349ad91a7 dwm.c
--- a/dwm.c Sat Jun 11 08:33:20 2011 +0100
+++ b/dwm.c Mon Jun 13 05:27:05 2011 -0400
@@ -585,11 +585,13 @@
configurenotify(XEvent *e) {
Monitor *m;
XConfigureEvent *ev = &e->xconfigure;
+ Bool dirty;
if(ev->window == root) {
+ dirty = (sw != ev->width);
sw = ev->width;
sh = ev->height;
- if(updategeom()) {
+ if(updategeom() || dirty) {
if(dc.drawable != 0)
XFreePixmap(dpy, dc.drawable);
dc.drawable = XCreatePixmap(dpy, root, sw, bh, DefaultDepth(dpy, screen));
Re: [dev] ideas on suckless file manager
On Sun, 12 Jun 2011 11:53:32 +0200, Nicolai Waniek wrote: > On 06/07/2011 07:09 PM, pancake wrote: > > Its anti natural. > > It's not. > > Because I asked myself which is the best working environment regarding > ones eyes some time ago, I looked around for some scientific research on > the topic of black-background vs white background. > > There's not that much research to be cited (and to be honest, after > reading the papers I removed them) but the overall conclusion is that > most probants had a higher reading speed and slightly less reading > errors with black text on white background. Nevertheless, the > differences are very small. Was there any mention of ambient lighting? I suspect these tests weren't conducted at 4am in a typical coder's cave, but rather in some fluorescent tube infested lab... Just take your laptop outside for a while, that's all the research you need ;) > [SNIP] > The only clear direction stated was that when you have to work with a > monitor and feel that your eyes are tiring, you should probably go to an > optician as you might have a minor amblyopia (+.25, -.25 something like > that) and proper way to work against it is to try eyeglasses. "The only clear direction stated was that when you have to walk and feel that your legs are aching, you should probably go to a radiologist as you might have a broken leg and proper way to work against it is to try immobilization." OR "You mean your eyes get tired after staring at a bright light for long stretches of time? That's not normal, you have bad eyes dude..." I'm aching to see that study :D > > > regards Peace -- Pieter
Re: [dev] ideas on suckless file manager
On Sun, 12 Jun 2011 22:23:03 +0200, pancake wrote: > Just to add my 5c to the thread.. > > I remember in the msdos5.0 age where everybody was using a 80x25 text console > to run programs and graphical mode was just for games.. > > Many text editors used a blue background. This is: > wordperfect/wordstar/edit.com .. > > I remember my teacher arguing this as something medically prooft that white > or black on blue is better than b/w or w/b. Your teacher is full of shit. Google "photoreceptor cell apoptosis induced by in vivo blue light exposure". Hint: "apoptosis" means DEATH. > Another point in this topic is that many ebook readers (iBooks) allow to > change the background color to 'sepia'. Which is good for long readings, as > the contrast is lower than b/w. > > I think that for long readings you use to be in a fixed position and your > eyes get more tired if there's more bright on the screen. > > Also crt and lcd/tft screens have differet brightness effects. Tft are less > damaging to eyes than crt.. So i think discussion about colors on text moved > to only stethical and personal issue because its no longer dramatic as it was > in the crt era. > > > --pancake > > On 12/06/2011, at 12:20, Connor Lane Smith wrote: > > > On 12 June 2011 10:53, Nicolai Waniek wrote: > >> Quite the opposite, that they could not detect any difference. > > > > So uh, not *quite* the opposite. > > > > I'm willing to believe people have a higher reading speed with > > black-on-white, though I suspect this is in part because that's how we > > read the vast majority of the time. However, especially when I'm > > tired, I can *feel* my eyes strain against the brightness (and if you > > lower the brightness you get an unreadable grey-on-grey). We may be > > good at reading black-on-white, but perhaps not black-on-fluorescent. > > > > It's possible I'm an outlier, being almost blind in one eye, but I > > doubt that has much of an effect in this case. > > > > Thanks, > > cls > > > Peace -- Pieter
Re: [dev] 2surf, an experiment in tiled browsing
On Sun, Jun 12, 2011 at 1:38 AM, Bjartur Thorlacius wrote: > On 6/11/11, Peter John Hartman wrote: >> Why not just utilize dwm's tile mode and have each link open in a new >> window? > Presumably so you don't have to close a window after every article you > examine, and resize the search results window. If you're going to > resize the parent window every time before you use it, you could just > as well hide it. > A two-pane setup however mandates the common workflow of skimming the > results, selecting an entry for examination, examining the linked > article, and then either reading article or returning to the results > page for continued skimming. Opening a new window for every activated > link would allow for the alternative workflow of continuous skimming > and then reading articles one after another. > But resizing a pager's window will Note that whatever the implementation mechanism, this kind of streamlined workflow would also be very useful for reading hyperlinked tutorial documents/reference manuals (as I'm doing now). Quite often some section will refer to something that is explained somewhere else in the manual (eg, file handling might have limits due to index sizes, which might link to a discussion about integer type sizes in general). I agree that it would be nice to get "you don't have to explicitly close this window" behaviour, whether in the browser only or in combination with the tiling WM. -- cheers, dave tweed__ computer vision researcher: david.tw...@gmail.com "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
[dev] does anyone else think that suckless.org is more about bare-bones minimalism than unix philosophy
Most people here seem more concerned with and interested in radical minimalism than modularity. Don't get me wrong, I think suckless software is on many points in the spirit of the unix philosophy. I just think the principles of composition and as a result modularity and separation are being neglected.
Re: [dev] does anyone else think that suckless.org is more about bare-bones minimalism than unix philosophy
On Mon, Jun 13, 2011 at 09:38:26AM -0400, Andreas Wagner wrote: > I just think the principles of composition and as a result modularity > and separation are being neglected. Can you give some examples of where you see this in suckless.org's software?
Re: [dev] does anyone else think that suckless.org is more about bare-bones minimalism than unix philosophy
Andreas Wagner writes: > Most people here seem more concerned with and interested in radical > minimalism than modularity. Don't get me wrong, I think suckless > software is on many points in the spirit of the unix philosophy. I > just think the principles of composition and as a result modularity > and separation are being neglected. This is true, but http://suckless.org/manifest/ only mentions Unix philosophy a single time, and not as the centerpiece of the manifest, so I don't think this is a great revelation. It happens that many principles of Unix philosophy lend themselves well to simplicity and frugality, but there are also some (such as file system interfaces and extreme interpretations of the tool philosophy) that create a degree of complexity. Whether or not you believe this complexity to be worthwhile (I do) is a question of taste, but most people of Suckless seem to take the frugal road. -- \ Troels /\ Henriksen
Re: [dev] does anyone else think that suckless.org is more about bare-bones minimalism than unix philosophy
On Mon, Jun 13, 2011 at 9:38 AM, Andreas Wagner wrote: > Most people here seem more concerned with and interested in radical > minimalism than modularity. Don't get me wrong, I think suckless > software is on many points in the spirit of the unix philosophy. I > just think the principles of composition and as a result modularity > and separation are being neglected. That's a bit of 'begging the question' there. There are no universal 'principals of composition'. Modularity is useful to a degree, but it requires careful consideration to implement. That's what the discussion of draw.c v. libdraw was about. "Separation" is meaningless if your data structures are sane. -- # Kurt H Maier
Re: [dev] does anyone else think that suckless.org is more about bare-bones minimalism than unix philosophy
Nick writes: > On Mon, Jun 13, 2011 at 09:38:26AM -0400, Andreas Wagner wrote: >> I just think the principles of composition and as a result modularity >> and separation are being neglected. > > Can you give some examples of where you see this in > suckless.org's software? dwm has a built-in status bar rather than using an external program. dmenu doesn't use sselp anymore (maybe a stretch). Surf has a built-in progress bar. There are probably some examples in wmii, but I do not know it well. And all of the above have very good reasons for being the way they are. -- \ Troels /\ Henriksen
Re: [dev] does anyone else think that suckless.org is more about bare-bones minimalism than unix philosophy
On Mon, Jun 13, 2011 at 9:42 AM, Nick wrote: > On Mon, Jun 13, 2011 at 09:38:26AM -0400, Andreas Wagner wrote: >> I just think the principles of composition and as a result modularity >> and separation are being neglected. > > Can you give some examples of where you see this in > suckless.org's software? > > The biggest example is the huge number of patches for dwm, dmenu, surf etc. I agree that these features should not be included in the core software, but naturally these patches often do not work anymore and cannot be used together. IMHO many of these should be organized into very small non-overlapping programs that can be used together.
Re: [dev] 2surf, an experiment in tiled browsing
On Sun, 12 Jun 2011 00:38:14 + Bjartur Thorlacius wrote: >On 6/11/11, Peter John Hartman wrote: >> Why not just utilize dwm's tile mode and have each link open in a new >> window? >Presumably so you don't have to close a window after every article you >examine, and resize the search results window. If you're going to >resize the parent window every time before you use it, you could just >as well hide it. >A two-pane setup however mandates the common workflow of skimming the >results, selecting an entry for examination, examining the linked >article, and then either reading article or returning to the results >page for continued skimming. Opening a new window for every activated >link would allow for the alternative workflow of continuous skimming >and then reading articles one after another. >But resizing a pager's window will > It could be implemented as a mode of window manager. - on new client hide and close current master - if master client is closed do not move other windows (master area remain blank) - new client becomes new master Limitation: programs with exit dialogs, but dialogs can be displayed anyway.
Re: [dev] does anyone else think that suckless.org is more about bare-bones minimalism than unix philosophy
On 6/13/11, Andreas Wagner wrote: > The biggest example is the huge number of patches for dwm, dmenu, surf > etc. I agree that these features should not be included in the core > software, but naturally these patches often do not work anymore and > cannot be used together. IMHO many of these should be organized into > very small non-overlapping programs that can be used together. > https://github.com/patrickhaller/no-wm
Re: [dev] ideas on suckless file manager
Then the easiest to read is amber on black. There is a lot we can learn from the sharp shooters, and the old dumb terminals. On Mon, Jun 13, 2011 at 2:52 AM, Pieter Praet wrote: > On Sun, 12 Jun 2011 22:23:03 +0200, pancake wrote: > > Just to add my 5c to the thread.. > > > > I remember in the msdos5.0 age where everybody was using a 80x25 text > console to run programs and graphical mode was just for games.. > > > > Many text editors used a blue background. This is: wordperfect/wordstar/ > edit.com .. > > > > I remember my teacher arguing this as something medically prooft that > white or black on blue is better than b/w or w/b. > > Your teacher is full of shit. > > Google "photoreceptor cell apoptosis induced by in vivo blue light > exposure". > > Hint: "apoptosis" means DEATH. > > > Another point in this topic is that many ebook readers (iBooks) allow to > change the background color to 'sepia'. Which is good for long readings, as > the contrast is lower than b/w. > > > > I think that for long readings you use to be in a fixed position and your > eyes get more tired if there's more bright on the screen. > > > > Also crt and lcd/tft screens have differet brightness effects. Tft are > less damaging to eyes than crt.. So i think discussion about colors on text > moved to only stethical and personal issue because its no longer dramatic as > it was in the crt era. > > > > > > --pancake > > > > On 12/06/2011, at 12:20, Connor Lane Smith wrote: > > > > > On 12 June 2011 10:53, Nicolai Waniek wrote: > > >> Quite the opposite, that they could not detect any difference. > > > > > > So uh, not *quite* the opposite. > > > > > > I'm willing to believe people have a higher reading speed with > > > black-on-white, though I suspect this is in part because that's how we > > > read the vast majority of the time. However, especially when I'm > > > tired, I can *feel* my eyes strain against the brightness (and if you > > > lower the brightness you get an unreadable grey-on-grey). We may be > > > good at reading black-on-white, but perhaps not black-on-fluorescent. > > > > > > It's possible I'm an outlier, being almost blind in one eye, but I > > > doubt that has much of an effect in this case. > > > > > > Thanks, > > > cls > > > > > > > Peace > > -- > Pieter > >
Re: [dev] does anyone else think that suckless.org is more about bare-bones minimalism than unix philosophy
Reading this group for a while I can see that it has a certain practical mindset that you can find elsewhere on the internet. For instance, the Surly folks in the bike touring groups who talk about wool paniers and shorts along with leather saddles as the best technology around. And, to be honest, they are probably right. You may not find more durable, maintainable materials for those purposes. They believe in steel bikes, steel bike racks, and heavy duty because you can find anyone anywhere in the world to weld/solder/etc.. it together if it breaks. And you won't develop hidden stress fractures over time to ruin an otherwise perfectly good day. Another example is the Mustang groups, who still tout their Ox-Cart live axle rwd technology as comparable if not better than what people have today. It is simple, straight forward, and understood. Indeed, Rouch's team chalked up yet another win in the current Grand-Am series against BMW's, Lexus, etc... who's to say they are wrong? Its a lot like the old RISC vs CISC days in hardware design even. This group just seems to like static binaries, and straight forward C. Dmenu is their idea of modularity, and who's to say it doesn't work? Dmenu is one of the best straight forward tools out there, and it is bundled with a number of programs. And it got that way because of the mindset, not that features are bad, but there is no use to a feature that isn't durable, straight forward, and nails a general need (rather than a specific that is really a contrivance of other tools you want to use it with). At least on a good day that is how I like to see this bunch. On a bad day I just see a bunch of crusty old curmudgeons who can't see past their own noses and love to have a group called "suckless" because they really like talking about how much everything sucks. Either way...
Re: [dev] ideas on suckless file manager
Dnia 13 czerwca 2011 20:14 Michael Farnbach napisał(a): > Then the easiest to read is amber on black. There is a lot we can > learn from the sharp shooters, and the old dumb terminals. Wondering if this concept is related to "selective yellow" [1] [1] http://en.wikipedia.org/wiki/Selective_yellow "The intent of selective yellow is to improve vision by removing shorter, blue wavelengths from the projected light, as these wavelengths are difficult for the human visual system to process properly(...)" On the side note, I use white on black with selective yellow cursor. W&B is no-brainer for me, maximizes contrast while minimizing screen brightness. To add another one, I'm not entirely sure LCD vs CRT eyes health debate is settled. regards, - Jakub Lach
Re: [dev] ideas on suckless file manager
On Mon, Jun 13, 2011 at 08:49:45PM +0200, Jakub Lach wrote: > To add another one, I'm not entirely sure LCD vs CRT > eyes health debate is settled. > I'm fairly sure the "Cathode ray cannon pointed at your head; is it safe ?" debate is well over.. djp
[dev] [st] mutt and cursor
Since revision 202 cursor is hidden after I quit from mutt. If I do "update 201", everything is ok. I don't know how to fix it right way. Also "reset" command don't help, cursor is still hidden. Is it a bug? http://hg.suckless.org/st/rev/0f21f57006c9
