[dwm] controlling dwm via emacs
I have some vague recollection of someone posting a library for emacs to control a tiling WM. I thought that that WM was dwm. Googling around, even substituting wmii, awesome, xmonad, etc I have found no trace of such a beast. Am I simply mistaken or can anyone provide a pointer? TIA, /john
Re: [dwm] visibility of focused windows
I have not looked at the code in a good while but wanted to suggest
the following code concept. My thought sprang from Anselm writing
> I propose using setlayout("[M]") and setlayout("[]=")
and then later
> I plan to introduce 3 additional key bindings:
>
> Mod1-f (Apply floating layout)
> Mod1-m (Apply monocle layout)
> Mod1-t (Apply tiled layout)
There already is a notion of the current layout. Imagine that
there is also a saved layout and the following function:
char *resolvelayout(char *proposed)
{
if (proposed == current)
proposed = saved;
else
saved = current;
current = proposed;
return proposed;
}
With this function I can have every target layout toggle:
setlayout( resolvelayout("[M]") );
setlayout( resolvelayout("[]=") );
setlayout( resolvelayout("<><") );
Just a thought,
/john
Re: [dwm] Status of DWM 4.8?
On Thu, 24 Jan 2008 15:38:25 +0100, Anselm wrote: >sorry but I relocated to the UK during Dec/Jan to start a new >job and so things slowed down somewhat. I will be back working >soon on dwm, so a release is likely to happen in the next two >weeks (including all planned features). Best o' luck in a new job! Any word on st? /john
Re: [dwm] Screenshot suggestion for the wiki
On Mon, 5 Nov 2007 15:37:52 -0700, Asbjørn Clemmensen wrote: >Perhaps adding the option to attach .Xdefaults/.Xresources along with .vimrc >and whatever else might be relevant when discussing color themes. Much of these personalizations are independent of dwm. A scheme that you find attractive would continue to be attractive in nearly any tiling window manager. The same would be true of a scheme you found unattractive. The xmonad community already has a page of screenshots: http://haskell.org/haskellwiki/Xmonad/Screenshots And more particularly a page of user configurations: http://haskell.org/haskellwiki/Xmonad/Config_archive If we are displaying color schemes and the like I would really love to see the various tiling wm communities find a means of "sharing the wealth". /john
Re: [dwm] [OT] which font are you using
On Sat, 26 May 2007 05:02:46 -0700, you wrote: >Which fonts are you guys using? Dina: http://www.donationcoder.com/Software/Jibz/Dina/index.html http://forums.gentoo.org/viewtopic-t-533782-highlight-dina.html http://ahri.net/static/dina.pcfs.tar.bz2 Nice monospaced font with full bold, italic and bold-italic variants. Emacs loves it. /john
[dwm] bstack for dwm-3.8?
Ross, On Mon, 26 Feb 2007 07:51:57 -0500, you wrote: >I'll get bstack for dwm-3.7 out later this week. . . . >-RPM dwm-3.8 is a fairly small delta from 3.7. It has been out and stable for a week. Anselm seems to have turned his attention to other projects. Any chance of a 3.8 bstack patch anytime soon? /john
[dwm] bstack for dwm-3.8?
Ross, On Mon, 26 Feb 2007 07:51:57 -0500, you wrote: >I'll get bstack for dwm-3.7 out later this week. . . . >-RPM dwm-3.8 is a fairly small delta from 3.7. It has been out and stable for a week. Anselm seems to have turned his attention to other projects. Any chance of a 3.8 bstack patch anytime soon? /john
Re: [dwm] [st] some wishes
On Fri, 2 Mar 2007, I posted a note that opened with this sentence: > Now that you seem to be actively working on st I hope that we can > discuss the envisioned functionality. The intent was to make it clear that though I was posting to the dwm list I was broaching the topic of st functionality. I do not know of a better forum in which to raise such issues. I expect that those drawn to dwm will likely be those most interested in influencing and using st. On Sat, 3 Mar 2007, "Szabolcs Nagy" replied: > > - some way to change the font-size on the fly; when I make a term > > small I would like to use a tiny font; when I grow it I would > > in xterm: ctrl + right mousebtn > firefox: ctrl + +/- > ... > > (i don't think dwm should do anything about it, it's client specific) "Szabolcs Nagy", by failing to quote the remainder of my wish bullet made it clear that he did not understand my point: > in keeping with the > dwm philosophy it might be nice to have some rule-based scheme > for automatically picking font-size (similar to a dwm layout) > with some way to control font-size manually (analogous to making > a window floating and later returning it to layout-controlled) This is a suggestion of functionality that might be included in st. The notion is that instead of manually changing the font size in conjunction with shuffling a window it could respond to resizing by possibly using a different font size. I tried to point out the extent to which such behavior would be consistent with the general dwm philosophy. The final mention of manual capability was simply and acknowledgement that even with a rule-based scheme one would still want manual capability for rare / atypical situations. I should point out that this suggestion was entirely speculative. I do not currently have a proposal for how one might express or encode such rules. But this does seem to be the right time to get folk thinking about and discussing broad functionality questions. /john
[dwm] [st] some wishes
Anselm, Now that you seem to be actively working on st I hope that we can discuss the envisioned functionality. Here are a few features that I would love to see: - truncated lines properly redrawn when window size changes; this should work correctly whether the resizing is via a change in layout or via mouse dragging; this should work properly for growth in both horizontal and vertical directions; if font change is implemented (see next wish) this should work properly when dropping down to a smaller font - some way to change the font-size on the fly; when I make a term small I would like to use a tiny font; when I grow it I would like to be able to switch to a larger font; in keeping with the dwm philosophy it might be nice to have some rule-based scheme for automatically picking font-size (similar to a dwm layout) with some way to control font-size manually (analogous to making a window floating and later returning it to layout-controlled) - urxvt-like fading: I have my non-focused terms fade a few percent; I find this makes for much more intuitive next/prev navigation and location of the currently focused window following a new layout /john
Re: [dwm] Text selection I-beam is hard to see
On Thu, 22 Feb 2007 12:59:41, Antoni Grzymala wrote: >Emerge a set of cursors (like gentoo-xcursors for example) then: > > mkdir /usr/share/cursors/xorg-x11/default/ > vim /usr/share/cursors/xorg-x11/default/index.theme > >And in that file: > > [Icon Theme] > Inherits=gentoo-silver > >(or, alternatively, any other directory from the gentoo-xcursors >package). Hope this helps, > >[a] Thanks so much! This is exactly the information that I needed. /john
Re: [dwm] Text selection I-beam is hard to see
On Thu, 22 Feb 2007 09:44:45(GMT), David Tweed wrote: > Usual disclaimer: I only understand vague bits of X I've > needed to use. However, I was looking at this issue in > connect with an application I was writing and _AIUI_ all > the basic cursors (I-beam, pointer, etc) X applications/ > wm's use are special "cursor designs" supported specially > by the graphics card (so the cover/uncover caused by pointer > movement is handled super efficiently). Whilst you can get > different pointers I think some code somewhere, eg, X > toolkit, has to emulate the cursor functions in software. > At least, that's the impression digging through the fltk > toolkits source and code gave me; I could be completely > wrong though. When running Windows I get a very similar fine I-beam but instead of being colored cyan it is black. The difference in visibility is enormous. So just finding a way to alter the color would be a great leap forward. /john
[dwm] Text selection I-beam is hard to see
I posted this plea to both the Gentoo and Sabayon forums: > I run dwm as my window manager. Of course this reflects > the fact that the vast majority of my windows are text > (emacs or urxvt xterms). When the pointer is not over > selectable text it is an hovering cyan arrow pointing > up and to the left with a subtle shadow. Over selectable > text the pointer changes to a very fine vertical cyan > I-beam with a ghost of a shadow. This I-beam is hard > enough to see when the screen's brightness is cranked > down. It becomes nearly invisible if I increase the > brightness. Is there anything I can do to improve this > situation? Change color to black? Use a thicker stroke > to draw the I-beam? I have successfully changed the pointer theme for Gnome and KDE sessions. But when I log out and return to the KDM greeter screen the original cyan pointer and nearly invisible I-beam return. These remain in effect when I start dwm. What do I need to do to use a different set of pointer icons with dwm? /john
Re: [dwm] recent changes to dwm (since dwm-3.5)
On Mon, Feb 19, 2007 at 11:56:18AM I wrote: > Scanning the bundles showing up on [hackers] it is clear that > those of us who have any significant investment in dwm patches > are in for rough sledding trying to track this refactoring. To which Anselm replied with a detailed list of his changes explaining that none should be a significant impediment to propagating patches. In that same posting I further wrote: > Will there be appreciable new functionality or is this just > gilding the lily? At what point will st get any real > attention? So what is the motivation for this refactoring? Personally I have much more interest in st reaching a minimal level of utility than in a refactoring of dwm that really presents us nothing new. Don't get me wrong, I love dwm. And I program for a living -- begriming 35 years ago with systems written entirely in assembler -- so I believe I can appreciate finely crafted code. But an st that we can all help evolve will make much more of a difference to the suckless community than an endlessly polished dwm. /john
Re: [dwm] Let's do some refactoring
Scanning the bundles showing up on [hackers] it is clear that those of us who have any significant investment in dwm patches are in for rough sledding trying to track this refactoring. Will there be appreciable new functionality or is this just gilding the lily? At what point will st get any real attention? /john
Re: [dwm] bundle section in wiki
On Thu, 15 Feb 2007 15:31:32 +0100, you wrote: >Hi, >we all know that dwm code base is frozen since several months ago ;) > >But the reality is that every other week I am patching the vanilla sources >with a non-fixed combination of patches (bstack, grid, warp...etc.) >When we apply more than one patch is very easy to find a rejection that >should be fixed manually. The more the patches applied, the more the >rejections, the more complex get to fix it. Been there. Done that. Know the phenomenon quite well. >Then, what about sharing bundles (mercurial bundles) with applied and >working patches? Everyone can then get the bundle and run the corresponding >unbundle against a clean copy of dwm. With a lot of time saving. I do indeed integrate multiple patches. I have developed a set of scripts to provide some structure to the process. Nothing as fancy as Andrew Morton's quilt scripts, but enough to save me from making too many cockpit errors. >Anyone has an opinion? arg, it's the wiki the place for these files? For starter I would like to see a page with a more structured set of links to available patches and the dwm releases supported. Ideally this would not be a set of links to individual contributor's web spaces but a repository at suckless.org. Similarly I would like to see a collected repository of interesting config files. >As a side efect people will find less resistance trying feature cocktails >and then reporting their feedback to the list. What I understand you to be suggesting is if I integrate patches X, Y, and Z that I would post a bundle providing the results of my integration efforts. Is this correct? If it existed I would be both a client and a contributor. /john
Re: [dwm] program notification
On Mon, 5 Feb 2007 14:27:01 +0100, "Julian Romero" <[EMAIL PROTECTED]> wrote: >For status bar notifications I recommend any inotify based monitor (can be >used to detect any filesystem change: new messages in your inbox, new log >messages in your IM directory...) It's the best in terms of resource >consumption (but require a modern kernel). I am aware of the inotify system call and have a new enough kernel. Can you point me to any of there "inotify based monitors"? TIA, /john
[dwm] What happened to "patches written by Gottox "
http://dwm.suckless.org/view.sh/patches includes a "patches written by Gottox" link pointing to http://81.209.164.44/pmwiki/pmwiki.php?n=Main.DwmPatches . While 81.209.164.44 responds to ping there has been no http response for days. Have these patches been lost? /john
Re: [dwm] yet another random ideas
On Thu, 4 Jan 2007 16:36:13 + (GMT), you wrote: > I keep meaning to learn how patch-stack based pg > (from git works) to see if that's suitable.. Given that Anselm is using hg (mercurial) I recommend learning its mq extension. It is essentially the git patch queue properly embedded into the rcs instead of just an add-on. I made the effort and like it a lot! The hg website has 3 or 4 mq (Mercurial Queues) pages and chapter 6 of the draft handbook is devoted to the subject. /john
Re: [dwm] Removing the titlebar?
>Don't know any graphic solution for the focus problem. Only a partial solution, but... I use a light background for my terminal windows. urxvt provides a "-fade %" option. I use -fade 10. This leaves unfocused terminals that remain very legible yet distinctly different in appearance from the focused client. /john
Re: [dwm] urxvt zoom vs resize
On Tue, 7 Nov 2006 18:04:13 +0100, you wrote: >John S. Yates, Jr. --> dwm (2006-11-06 22:13:49 -0500): >> Can anyone explain why urxvt can accommodate window size >> changes via zoom but not via drag-resizing? >> >> E.G. I have urxvt term open in master position displaying >> wide lines. I zoom it away, the wide lines wrap. I zoom >> it back the wide lines unwrap. Sweet! But if I resize >> via MODKEY-Mouse-3 dragging the wide lines do not wrap :-( > >I can't reproduce this with urxvt v8.0 (and I'm sure it worked with >v7.x, too); i.e. lines are wrapped when resizing a urxvt window. But >only if the scrollback buffer is in [1]use... > > >Regards, Jukka > >[1] http://lists.schmorp.de/pipermail/rxvt-unicode/2006q3/000327.html Well... I am not sure what has changed. But you are correct, it does work. Sorry for the noise. /john
[dwm] urxvt zoom vs resize
Can anyone explain why urxvt can accommodate window size changes via zoom but not via drag-resizing? E.G. I have urxvt term open in master position displaying wide lines. I zoom it away, the wide lines wrap. I zoom it back the wide lines unwrap. Sweet! But if I resize via MODKEY-Mouse-3 dragging the wide lines do not wrap :-( Is the problem here the fact that the window contents is being displayed as it is resized? Might "rubber-banding" -- dragging a window outline and only repainting window contents when Mouse-3 is released -- solve the problem? /john
