Re: [dev] dwm
On Sat, May 7, 2011 at 7:43 AM, m1...@web.de wrote: i like wmii :) but it seems to become more and more unmaintained Kris is still around, but very busy it seems. I would guess that he will have enough free time motivation to work on wmii this summer. and there are some minor issues which are bothersome Please report these minor issues on the issue tracker: http://code.google.com/p/wmii/issues/list it seems there are more suitable wm out there which are like wmii. ArchLinux maintains a comparison table of tiling WMs here: https://wiki.archlinux.org/index.php/Comparison_of_Tiling_Window_Managers
Re: [dev] dwm
On Sat, May 7, 2011 at 11:21 AM, m1...@web.de wrote: fix wmii. don't try to turn dwm into it. this wuld be a solution if wmii would be documented..which is not really the case..sorry but there is nearly no documentation in it Really? wmii has a manpage, user guide, and wiki of documentation. i dont have time to re-engineer it. Switching my wm seems a better sollution. Finally, we arrive at the truth. Not having the time, energy, or motivation to hack on wmii is reasonable; accusing wmii of being undocumented (there is a manpage, user guide, and website) is not.
Re: [dev] [wmii][rumai] Error using default wmiirc
On Wed, Apr 27, 2011 at 11:21 AM, Aurélien Aptel aurelien.ap...@gmail.com wrote: I wanted to try the ruby wmiirc, so I followed the steps in the README, installed latest wmii/libixp from the repo, installed rumai 3.3.1 (since wmiirc require 4), checkout the strict branch It seems you are using the ruby wmiirc that was shipped with wmii (which is ancient!) because the current ruby wmiirc on GitHub[1] no longer maintains the strict branch and requires Rumai 4.1.2, so try [1] instead. [1]: https://github.com/sunaku/wmiirc
Re: [dev] Why dwm or wmii over xmonad, etc., or not?
On Thu, Apr 21, 2011 at 9:04 AM, dtk d@gmx.de wrote: Suraj Kurapati wrote: If your Ruby config is based on mine[1], I think it kind of is. iirc it's based on the one that ships with wmii per default, which again is based on yours, isn't it? The version that ships with wmii is *ancient*! My config on GitHub is much better, having since undergone several bursts of evolution. I recommend upgrading to both wmii-hg and my config on GitHub. :) then perhaps I could help: That would be ultra sweet (and fix the one big issue I have with wmii) I just installed wireshark-gtk in ArchLinux and ran `sudo wireshark`: it started up just fine; no crashes. My env: # wireshark -v wireshark 1.4.6 # wmii -v wmii-hg2786+, ©2010 Kris Maglione # ruby -v ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux] # rumai -v 4.1.1 # uname -a Linux ratham 2.6.38-ARCH #1 SMP PREEMPT Wed Mar 30 08:47:36 CEST 2011 x86_64 Genuine Intel(R) CPU U7300 @ 1.30GHz GenuineIntel GNU/Linux What wmii, ruby, and wmiirc versions are you using? Actually, I reported the problem some time ago on this very mailing list. Do you have this[0] thread available for reference? I recommend compiling wmii from its source code repository. The 3.9.2 stable release in your Linux distro is ancient, IMHO. And is your config available online somewhere u can haz it over herre[3]. Your config seems fine. I don't see any glaring problems in it.
Re: [dev] [st] 0.1 Feedback - Was: A few small patches
On Thu, Apr 21, 2011 at 7:53 AM, Rob robpill...@gmail.com wrote: I usually use plain text mode and edit the email externally - I use vimperator, which is a Firefox plugin, and it allows you to edit text fields with a external editor. Unfortunately the Chromium browser lacks an external editor plugin for HTML textareas, so I copy the textarea to the clipboard, run this helper script[1] to edit in GVim, and paste back to the textarea. [1] https://github.com/sunaku/home/blob/master/bin/edit-gmail-message
Re: [dev] Why dwm or wmii over xmonad, etc., or not?
On Thu, Apr 21, 2011 at 4:59 PM, dtk d@gmx.de wrote: \o/ you fixed it!! :D actually I only built master just yet, so haven't thrown neither your current config nor my mods at it yet, but so far wireshark runs just nicely :) *yaaay!!* :D Correction: Kris fixed it. :) It was a bug inside wmii, after all. thanks for the tip! wouldn't have thought that the stable release was that old (especially since it's advertised on http://wmii.suckless.org/). Yes that is unfortunate, it is high time for a new stable release. I always use wmii-hg, so I'm not bothered by wmii's release cycle. haven't seen much yet, but master (is it called like that in mercurial?) looks really nice! Mercurial calls the master branch as tip. you got a systray thingy and a history in the menu. sweet! Yes, status bar applets are really easy now. (screenshot: http://ompldr.org/vODNuag) thanks again for your patient support! thanks alot dtk My pleasure. I can port your config to git master if you want. :)
Re: [dev] Why dwm or wmii over xmonad, etc., or not?
On Wed, Apr 20, 2011 at 7:27 AM, Eitan Goldshtrom wrote: Why are dwm and wmii better than other tiling WMs? I like wmii because it (1) has dynamic tagging, views, and columns; and (2) is configurable in any programming language (I use Ruby[1]). I've been using wmii since 2005; occasionally trying other tiling and WIMP WMs to get a feeling of the status quo. But I always find something lacking in them; something I dearly missed from wmii. wmii is not perfect, but it does more of what I want than other WMs I've tried (perhaps I haven't tried enough of them). I hope Kris returns someday to continue its development; I fear it's abandoned. [1]: https://github.com/sunaku/wmiirc
Re: [dev] Why dwm or wmii over xmonad, etc., or not?
On Wed, Apr 20, 2011 at 2:00 PM, dtk d@gmx.de wrote: Excerpts from Suraj Kurapati's message: is configurable in any programming language (I use Ruby[1]). so do i, but it segfaults on me when i start wireshark -.- dunno, maybe it's due to my modifications (added 'toggle last view' patch and some namespacing) If your Ruby config is based on mine[1], then perhaps I could help: What wmii, ruby, and wmiirc versions are you using? And is your config available online somewhere so I can look at it? Cheers. [1]: https://github.com/sunaku/wmiirc
Re: [dev] [wmii] Ignoring key presses
On Mon, Apr 18, 2011 at 6:01 AM, Jay Mundrawala jdmundraw...@gmail.com wrote: On Sun, Apr 17, 2011 at 6:08 PM, pod p...@nervous-energy.org.uk wrote: If by dev version you mean 2785:327e87c7bb2b (current tip from http://hg.suckless.org/wmii) then I believe there is a bug in wmiir when it is run in a non-UTF-8 locale. If your event loop is dispatching on keypresses as reported from wmiir read /event and that wmiir has been invoked in a non-UTF-8 locale then this bug may be the issue. Thanks, That fixed it. Very nice. Please submit this info as a bug/patch here: http://code.google.com/p/wmii/issues/list
Re: [dev] [wmii] Ignoring key presses
On Fri, Apr 15, 2011 at 11:35 AM, Thomas Dahms da...@ymail.com wrote: Am 15.04.2011, 20:14 Uhr, schrieb Jay Mundrawala jdmundraw...@gmail.com: The contents of wmiir read /keys: ... All there. I am afraid I cannot help anymore then. Try an alternate wmiirc[1] such as my Ruby wmiirc[2] or the Python wmiirc that comes installed with wmii. That way you can isolate the problem to rc/sh on your system. [1]: http://wmii.suckless.org/alternative_wmiirc_scripts [2]: https://github.com/sunaku/wmiirc
Re: [dev] [PATCH] wmii hg - witray in normcolors
On Sun, Apr 3, 2011 at 7:36 AM, Kris Maglione maglion...@gmail.com wrote: Hm. I have to admit that I think I chose selcolors because that's the color of my clock panel to the far right of my bar. Interesting, so you draw your clock bar with selcolors? It may have something to do with the fact that hardly any of the bar is visible for me, Do you have a lot of bar applets/widgets running? Do they take up so much room that wmii doesn't have any space to draw them? but I don't see how changing the colors would make it more or less distracting... although you do tend towards a blue and black color scheme, don't you? Yes, I'm currently using colors from Vim's wombat colorscheme for wmii: http://ompldr.org/vODNuag https://bbs.archlinux.org/viewtopic.php?pid=912802#p912802 Selcolors are used in the left bar to indicate the current view. That's why drawing witray with selcolors doesn't make sense to me: the tray isn't selected / current at any time. It should just be there, in the background, not shouting for attention, IMHO.
Re: [dev] Re: [PATCH] wmii - client mapping events
On Sun, Apr 3, 2011 at 7:38 AM, Kris Maglione maglion...@gmail.com wrote: I like this idea, but I don't like that it only applies to the selected view. I'll add an attach event that includes the client and the view. Sure, emitting an event like that should be sufficient for my needs: event(ArrangeView %s %#C\n, f-view-name, f-client); I need this to know when to reapply an automated arrangement (like LarsWM style tiling) whenever the managed layer changes in the current view in my wmiirc, for example: event ArrangeView do |tag, client_id| apply_larswm_arrangement if tag == curr_tag end I'm not sure I see the point of the map and unmap events. The map/unmap events are not necessary; they are vestiges from my first try of the patch. Thanks for your consideration.
[dev] Re: [PATCH] wmii - client mapping events
On Mon, Mar 28, 2011 at 3:53 PM, Suraj Kurapati sun...@gmail.com wrote: On Sun, Mar 27, 2011 at 1:04 AM, Suraj Kurapati sun...@gmail.com wrote: The following patch against wmii-hg r2785 allows my wmiirc to know when clients are added to or removed from the current view. Here is an updated patch that [...] fires those events only when the current view is actually changed. No need for special logic to detect valid boundaries of MapClient and UnmapClient events. Here is another updated patch that also deals with moving clients from the floating layer to the managed layer and vice versa. The two events from before have been reduced to a single ArrangeView event that is emitted with no arguments. Cheers. diff -r 327e87c7bb2b cmd/wmii/area.c --- a/cmd/wmii/area.c Thu Oct 28 09:55:54 2010 -0400 +++ b/cmd/wmii/area.c Sat Apr 02 00:41:37 2011 -0700 @@ -218,6 +218,10 @@ area_detach(f); + if(from-floating ^ to-floating) + event(ArrangeView\n); + /* Temporary kludge. */ if(!to-floating to-floating != from-floating diff -r 327e87c7bb2b cmd/wmii/view.c --- a/cmd/wmii/view.c Thu Oct 28 09:55:54 2010 -0400 +++ b/cmd/wmii/view.c Sat Apr 02 00:41:37 2011 -0700 @@ -416,6 +416,10 @@ if(c-sel == nil) c-sel = f; view_update(v); + + if (v == selview !a-floating) + event(ArrangeView\n); } void @@ -426,6 +430,10 @@ v = f-view; c = f-client; + if (v == selview !f-area-floating) + event(ArrangeView\n); + area_detach(f); if(c-sel == f) c-sel = f-cnext;
[dev] Re: [PATCH] wmii - client mapping events
I posted this patch on the wmii issue tracker: http://code.google.com/p/wmii/issues/detail?id=232 Sorry for the noise thus far.
[dev] Re: [PATCH] wmii hg - witray in normcolors
I posted this patch on the wmii issue tracker: http://code.google.com/p/wmii/issues/detail?id=234 Sorry for the noise thus far.
Re: [dev] wmii fix changing resolution
On Fri, Apr 1, 2011 at 6:23 AM, Ming Wang wangjiaom...@hotmail.com wrote: So here's a patch that works fine for me. http://pastebin.com/WkPJfxaK It seems your patch is against wmii 3.9.2. Did you see if the problem occurs with wmii built from its source repository? An equivalent of your patch might already be in the repository.
Re: [dev] Re: [ANN] ruby wmiirc - improved status bar applets
On Thu, Mar 31, 2011 at 11:19 AM, Nathan Neff nathan.n...@gmail.com wrote: If I would persist the first arrangement, then the arrangement would /remain/ as 1 2 3 But the firefox would push one of the other clients out of the view? Is that what this feature does? No, persistence means the reapplication of your chosen arrangement when clients enter/leave the current view. For example, if you started out with a single column like this: 1 2 3 And chose rightward in the arrange status barlet: 1 2 3 And started a new client in the second column: 1 2 3 4 Then, wmii tells us a client has entered the current view through the ClientAttach event. The arrange barlet (which listens for ClientAttach and ClientDetach events) is triggered and it reapplies the rightward arrangement that you chose earlier. As a result, your view now looks like this: 1 2 4 3 Start another client in the second column: 1 2 4 3 5 And the status barlet again reapplies the rightward arrangement: 1 2 5 3 4 Start another client in the second column: 1 2 5 3 4 6 And once again, the status barlet kicks in: 1 2 6 3 5 4 This is what I mean by persistence.
[dev] Re: [PATCH] wmii - client mapping events
On Sun, Mar 27, 2011 at 1:04 AM, Suraj Kurapati sun...@gmail.com wrote: The following patch against wmii-hg r2785 allows my wmiirc to know when clients are added to or removed from the current view. Here is an updated patch that renames the events to ClientAttach and ClientDetach and, more importantly, fires those events only when the current view is actually changed. No need for special logic to detect valid boundaries of MapClient and UnmapClient events. Cheers. ff -r bb26a51ba0c3 cmd/wmii/view.c --- a/cmd/wmii/view.c Sun Mar 27 14:18:21 2011 -0700 +++ b/cmd/wmii/view.c Mon Mar 28 15:41:56 2011 -0700 @@ -363,6 +363,9 @@ c = f-client; + if (v == selview) + event(ClientAttach %#C\n, c); + oldsel = v-oldsel; a = v-sel; if(c-floating == Never) @@ -426,6 +429,9 @@ v = f-view; c = f-client; + if (v == selview) + event(ClientDetach %#C\n, c); + area_detach(f); if(c-sel == f) c-sel = f-cnext;
[dev] [PATCH] wmii - client mapping events
Hello,
The following patch against wmii-hg r2785 allows my wmiirc to know
when clients are added to or removed from the current view. Using
that information it can persist[1] the application of automated client
arrangements (such as emulating LarsWM tiling layout, for example) as
the current view's population changes over time.
diff -r 327e87c7bb2b cmd/wmii/client.c
--- a/cmd/wmii/client.c Thu Oct 28 09:55:54 2010 -0400
+++ b/cmd/wmii/client.c Sun Mar 27 00:48:51 2011 -0700
@@ -492,14 +492,17 @@
client_map(Client *c) {
if(!c-w.mapped) {
mapwin(c-w);
+ event(MapClient %#C\n, c);
client_setstate(c, NormalState);
}
}
void
client_unmap(Client *c, int state) {
- if(c-w.mapped)
+ if(c-w.mapped) {
unmapwin(c-w);
+ event(UnmapClient %#C\n, c);
+}
client_setstate(c, state);
}
Also, note that only those mapping events that occur (1) after the
first subsequent ClientFocus event and (2) before the next UnfocusTag
event correspond to clients added to and removed from the current
view. Mapping events which occur outside the mentioned boundaries are
transient (occurring while a view is being switched to).
Cheers.
[1]:
https://github.com/sunaku/wmiirc/commit/6b9ef9c0727a66f02afe975195d1b8ff0b9ad8d4
Re: [dev] Re: [dwm] reload configuration?
On Sun, Mar 27, 2011 at 2:42 PM, Benjamin R. Haskell suckl...@benizi.com wrote: while true ; do _setup_wm_command # usually sets cmd=( consolekit-session dbus-session dwm ) $cmd || urxvt done I use a similar approach, but ask the user if the WM termination was intended: xterm -e tail -F ~/.wmii/wmiirc.log while true; do ck-launch-session wmii xmessage 'Do you really want to quit wmii?' \ -buttons 'Yes:0,No:1' -center \ -default 'No' -timeout 30 \ break done Also, if an unrecoverable exception occurs in my WM configuration, I launch an xterm to give the user the chance to fix the problem and then I offer to reload the WM configuration for them: https://github.com/sunaku/wmiirc/blob/master/lib/wmiirc/loader.rb#L25 https://github.com/sunaku/wmiirc/blob/master/lib/wmiirc/loader.rb#L99 Cheers.
[dev] [ANN] ruby wmiirc - improved status bar applets
Hello, Status bar applets have greatly improved in my Ruby wmiirc[1]: * Added support for rendering Unicode characters in bar labels. * Support both Linux and FreeBSD in various status bar applets. * Actions and keyboard/mouse controls are now bound to particular instances of status bar applets. This means you can use `self` to refer to the Wmiirc::Status object in your action handlers. * Status bar applet parameters are now (1) written with a '@' prefix in YAML files and (2) are made available as instance variables for use by the Ruby code therein. Cheers. [1] http://github.com/sunaku/wmiirc
[dev] [PATCH] wmii hg - witray in normcolors
Hello, I became tired of seeing witray render itself in selcolors (by default) and changed it to use normcolors as shown below. That's one less distraction and more productivity for me. diff -r 327e87c7bb2b cmd/tray/tray.c --- a/cmd/tray/tray.c Thu Oct 28 09:55:54 2010 -0400 +++ b/cmd/tray/tray.c Thu Mar 24 16:21:56 2011 -0700 @@ -123,9 +123,9 @@ borderwidth = 1; r = rectsetorigin(r, ZP); - border(tray.pixmap, r, borderwidth, tray.selcolors.border); + border(tray.pixmap, r, borderwidth, tray.normcolors.border); r = insetrect(r, borderwidth); - fill(tray.pixmap, r, tray.selcolors.bg); + fill(tray.pixmap, r, tray.normcolors.bg); XClearWindow(display, tray.win-xid); } Enjoy.
Re: [dev] wmii / tip bug - gnome-terminal loses focus + no updates when fullscreen
On Wed, Mar 9, 2011 at 10:36 AM, Armando Di Cianno arma...@goodship.net wrote: When I use wmii-tip and I engage fullscreen, gnome-terminal takes up the full screen, but simultaneously seems to cease updating and/or lose focus. Do you observe any difference when you engage fullscreen using the conventional Gnome fullscreen shortcut (F11) vs. running the following command in gnome-terminal? wmiir xwrite /client/sel/ctl fullscreen toggle
Re: [dev] wmii noob key binding help
On Thu, Feb 24, 2011 at 12:14 PM, Benjamin R. Haskell suckl...@benizi.com wrote: running the 'wmiirc' action just spawned a second instance of wmiirc (resulting in event doubling, e.g. keystroke that spawns a new terminal spawned two new terminals). Traditionally, this was solved by making wmiirc (1) emit Start wmiirc to /event at startup and later (2) exit if they see Start wmiirc inside their /event processing loop. In this manner, new instances of wmiirc terminate previously existing ones. I don't know why that mechanism was removed from the default SH wmiirc. It did exist in the past, however.
[dev] wmii issue tracker cleanup
I went through the wmii issue tracker, closed some (already) fixed issues, and categorized the remaining ones. I hope this helps Kris someday. Cheers.
Re: [dev] Config files
Connor Lane Smith wrote: Nick wrote: So, what's a good, simple format to store config files? you could just make the config file valid shell: key1=value1 key2=value2 Trivial to parse in C Why bother parsing? Make those environment variables and use getenv(3).
Re: [dev] Config files
On Wed, Feb 9, 2011 at 4:28 PM, Suraj Kurapati sun...@gmail.com wrote: Connor Lane Smith wrote: key1=value1 key2=value2 Trivial to parse in C Why bother parsing? Make those environment variables and use getenv(3). Sigh, next time I'll read the whole thread before replying. Many others pointed out the same idea. Sorry for the noise!
Re: [dev] [wmii] force 3 apps into 2 columns on start?
On Fri, Feb 4, 2011 at 3:35 PM, Larry Gagnon lggag...@uniserve.com wrote: I use .xinitrc to launch 2 instances of urxvt and my browser automatically on startup. I would like the browser to startup in a second column on the right. Assuming your browser takes longer to start than your terminal, this should do: wmiir read /event | grep -m 2 CreateClient wmiir xwrite /client/sel send right
Re: [dev] Problem starting wmii with fresh ruby github wmiirc
On Sun, Nov 14, 2010 at 6:04 PM, Armando Di Cianno arma...@goodship.net wrote: ... now if I could only figure out why Ruby 1.9.2 is constantly at around 50% CPU utilization ... blech! ;-) I reported this problem on the Ruby issue tracker: http://redmine.ruby-lang.org/issues/show/3919 It seems to be a regression from 1.8.7 onwards.
Re: [dev] [wmii] Prevent losing of windows on crash/hang
On Sun, Oct 17, 2010 at 5:01 AM, Rob robpill...@gmail.com wrote: while true; do exec wmii xmessage 'Restart the Window Manager?' \ -buttons 'Yes:1,No:0' -center \ -default 'Yes' -timeout 30 \ break done You're using exec, once that line is reached, bash replaces itself with wmii. Just use wmii instead, or even: Correct. wmii || xmessage Restart... that way (assuming wmii returns 0 on successful exit) when you mean to exit, it's all fine. I recommend showing the xmessage in all cases (not just for non-zero exit status) because sometimes you might accidentally exit wmii when you did not really intend to (thinking about something + your brain on auto-pilot + your fingers acting with muscle memory).
Re: [dev] Re: [dvtm] buffered text on resize
On 9/8/10, Niki Yoshiuchi aplu...@gmail.com wrote: even a Gnome user should be able to figure out how to fix it. Haha, well said, that quote is an instant classic! :-)
Re: [dev] Stripping html from email
On Mon, Aug 23, 2010 at 8:46 PM, Anthony J. Bentley anthonyjbent...@gmail.com wrote: Is there currently a tool or script that I can use to strip html from emails? mhshow-show-text/html: lynx -dump %F | less Lynx sucks but it sorta works well enough here, I guess. I find that w3m does a much better job of HTML to plain-text conversion than Lynx. It even renders HTML tables using Unicode box-drawing characters! http://w3m.sourceforge.net/
Re: [dev] Usable typesetting system?
On Sun, Aug 22, 2010 at 4:15 AM, Martin Kopta mar...@kopta.eu wrote: I am currently looking for some replacement with: * input as plain text (NOT xml) * simple syntax/commands/language * output as PDF (acceptable as thesis), may be indirectly * usable compilator (readable overall output, warnings and errors) * overall good design Try AsciiDoc http://www.methods.co.nz/asciidoc/ Its PDF output is horrible (looks like something created in M$ Word *vomit*), but it can emit plain old LaTeX as well. Since you already know LaTeX, I'm sure you could take AsciiDoc's LaTeX output and somehow typeset in the beautiful, classic Knuth style that we love. I guess my demands are too high, but if you know about something interesting, please, let me know. In my case, I wrote my masters thesis using LyX http://www.lyx.org/ It's a What You See Is What You Mean system, better than WYSIWYG. And it was so good and easy that I never had to learn LaTeX! :-)
Re: [dev] Re: Digest of dev@suckless.org issue 40 (5783-5832)
Please trim your quoted text and do not top-post. http://catb.org/~esr/jargon/html/T/top-post.html
[dev] Re: [dev] Re: [dev] Re: [dev] [dev] Usage, -h, --hel p, help, synopsis, …
On Sat, Aug 21, 2010 at 4:22 AM, yy yiyu@gmail.com wrote: 2010/8/19 Suraj Kurapati sun...@gmail.com: On Tue, Aug 17, 2010 at 7:54 PM, Suraj Kurapati sun...@gmail.com wrote: #!/bin/sh # your program description usage documentation here # nicely formatted and beautified to fit 80 columns # NOTE: the blank line below is the end of the file comment header sed -n '2,/^$/s/^# \?//p' $0 # show this file's comment header I find this solution really convoluted. Why not using echo? You can use an USAGE variable, or even a here-document and cat if you feel like it. I like to put documentation at the head of a file because that's only part anyone will read before deciding if it's worth spending their time to delve into the rest of the shell script. Also, I don't like messing up my program's indentation because I have to emit a big block of text in it: if ...; then# ugly! cat EOF your documentation here EOF fi And btw, it would probably be a good idea to redirect the help message to stderr. Good idea.
[dev] Re: [dev] Re: [dev] [dev] Usage, -h, --help, help, s ynopsis, …
On Sat, Aug 21, 2010 at 2:12 AM, pancake panc...@youterm.com wrote: 80 or 78? :) Good point. I personally use 78 because, if you follow the Python suggestion of 79 characters and reserve 1 more character for +/-/ indicators in diff(1) output, then your code will be readable in terminals, editors, and also in patches.
Re: [dev] flo - a command line program for organizing events, to-dos, and deadlines
On Tue, Aug 17, 2010 at 10:19 AM, Alexander Teinum atei...@gmail.com wrote: On Tue, Aug 17, 2010 at 6:50 PM, Andreas Wagner andreasbwag...@gmail.com wrote: I would like a system for managing a task dependency graph Yeah, I did think about having some sort of dependency graph today. it requires [...] that the items must have ids that don’t change. uuidgen(1) for the win.
Re: [dev] flo - a command line program for organizing events, to-dos, and deadlines
On Tue, Aug 17, 2010 at 2:56 PM, Nikhilesh S s.nikhil...@gmail.com wrote: On Tue, 17 Aug 2010, Suraj Kurapati wrote: uuidgen(1) for the win. I don't see why they should be univrsally unique - just unique within the input file should do. All that is required is adding an additional integer 'id' field to the 'item' struct, using that as the id instead, and using 'lowest unused whole number id' for generating new ids. Oh, I forgot flo was a C program. I was thinking it was a shell script, in which case, I would argue that it is the UNIX way to invoke specialized tools --- such as uuidgen --- that do the job rather than reinventing logic poorly in your shell script. :)
[dev] Re: [dev] [dev] Usage, -h, --help, help, synopsis, …
On Tue, Aug 17, 2010 at 8:40 AM, Alexander Teinum atei...@gmail.com wrote: What is the most concise way of outputting a usage and help text? For my programs, the --help option simply displays their manpage. :-) man(1) is better suited for information display (text-wrapping to 80 characters or $COLUMNS, pagination, and emphasis with bold, reverse video, underline, etc.) than anything I could care to reinvent poorly in each of my programs.
[dev] Re: [dev] Re: [dev] [dev] Usage, -h, --help, help, s ynopsis, …
On Tue, Aug 17, 2010 at 8:27 PM, Kris Maglione maglion...@gmail.com wrote: GNU man has the annoying and difficult to stop habit of filling the entire width of the terminal rather than wrapping at 80 chars. And if you set $MANWIDTH or $COLUMNS to 80 and the terminal isn't that wide, you wind up with badly broken wrapping. Agreed. GNU man really should do something like CSS's max-width: 80em. As for bold, fortunately my terminal has it disabled, I set up nice colors for bold and underline so things are easy to read (see the attached screenshot). If anyone is interested, my Xdefaults file is here: http://github.com/sunaku/home/blob/master/.Xdefaults and reverse video has no place in manual pages. Hehe, I went a little overboard there. :-) attachment: man_colors.png
Re: [dev] flo - a command line program for organizing events, to-dos, and deadlines
On Sat, Aug 14, 2010 at 5:18 AM, Alexander Teinum atei...@gmail.com wrote: http://github.com/alexanderte/flo Congratulations on choosing the ISC license for your project. Too many projects still use MIT/X these days when ISC is clearly more suckless IMHO: because it has less LOL (lines of license ;-) Cheers.
Re: [dev] [wmii] Between tiling and floating
On Mon, Jul 26, 2010 at 3:17 AM, LuX lux.onthe...@free.fr wrote: I am wondering if it would be possible: 1) to increase dynamically the width of the focused column of a given percentage, say; You can do this now by reading /event and growing/shrinking the client in first column accordingly. 2) or otherwise to make the focused column overlap the others of a given percentage while the others columns keep the same width. You can keep the overlapping client in the floating area and use wmii-2 style detaching (replace its tags with something, say |) and attaching (replace first client's tags in the, say |, view with current tag) actions to bring the overlapping client into your view when you need it. Here is an example from my wmiirc: http://github.com/sunaku/wmiirc/blob/master/control/action/detach.yaml http://github.com/sunaku/wmiirc/blob/master/control/keyboard/common/detach.yaml
Re: [dev] wmii: dash, bash and tests in wmiirc
On Mon, Jul 19, 2010 at 11:46 AM, LuX lux.onthe...@free.fr wrote: I wanted to add to wmii some basic ability to deal with USB pens: - mount and open them automatically when plugged in; I use ConsoleKit (by way of the Thunar file manager) for this, but I don't know how it works internally. I would imagine that there is a ck-* executable which emits USB device discovery/(un)mounting events to STDOUT and you can read and react to that output accordingly. Here's the relevant snippet from my .xinitrc: # the ck-launch-session is for proper automounting of USB drives # see http://bbs.archlinux.org/viewtopic.php?id=84635p=3 ck-launch-session wmii - show them as buttons in the right bar, with focus or normal colors depending on whether their file system is mounted or unmounted; - unmount/remount them by simple clicks on their buttons. If you can tap into the ConsoleKit event stream, these seem possible to do. Cheers.
Re: [dev] [wmii] Locale problem with uptime (loadavg in status bar) and a suggestion
On Wed, Jul 14, 2010 at 5:08 AM, nico n...@lifeisabug.com wrote: i changed my systems locales to de_DE.UTF-8 and now the command uptime is using , instead of . because of LC_NUMERIC now being set to German too. As a result of this the loadavg part of the default statusbar looks like 131 087 071 (no dots since commas are removed by sed). You're in luck. Kris recently fixed this issue in wmii-hg: http://hg.suckless.org/wmii/rev/af46181238ec
Re: [dev] [wmii] Mouse problems
On Tue, Jul 13, 2010 at 7:46 AM, Tom Kazimiers t...@voodoo-arts.net wrote: Indeed, wmii was the not the cause, nor was Rumai. I switched the mouse driver in xorg.conf Driver evdev Prior to that I used mouse as driver. Good to know! Thanks for resolving this.
Re: [dev] Re: [ANN] wmii 3.9.1 released
On Tue, Jun 8, 2010 at 10:49 AM, David Engster d...@randomsample.de wrote:
wmiir read /event | awk '/./ { print; fflush() } END { print }'
What's the purpose of awk here? I see the same result both with and
without awk in Arch Linux with awk = GNU Awk 3.1.8.
# i=0; wmiir read /event | while read; do i=`expr $i + 1`; echo $i-$REPLY; done
# i=0; wmiir read /event | awk '/./ { print; fflush() } END { print
}' | while read; do i=`expr $i + 1`; echo $i-$REPLY; done
Re: [dev] Re: [wmii]wmii-hg2647 won't start
On Fri, May 28, 2010 at 12:19 AM, pascal lepasca...@gmail.com wrote: I started over by uninstalling wmii, removing the source directory and pulling the source again and now wmii runs just fine +1 I also do clean builds and complete re-installs every time to avoid problems.
[dev] wmii hg 2630 install error
I see the following set of errors in `make install` output: MAKE install man/ Install directories: Man: /home/sun/app/wmii/share/man /bin/sh: 1##*.: command not found INSTALL man/wmii.1 /bin/sh: 1##*.: command not found INSTALL man/wmiir.1 /bin/sh: 1##*.: command not found INSTALL man/wmii9menu.1 /bin/sh: 1##*.: command not found INSTALL man/wimenu.1 And the final exit status is strangely 0.
[dev] Re: wmii hg 2630 install error
Suraj Kurapati wrote: /bin/sh: 1##*.: command not found INSTALL man/wmii.1 /bin/sh: 1##*.: command not found INSTALL man/wmiir.1 /bin/sh: 1##*.: command not found INSTALL man/wmii9menu.1 /bin/sh: 1##*.: command not found INSTALL man/wimenu.1 I confirm that wmii hg 2631 fixes these errors. Thanks.
[dev] wmii hg 2622 compile error
Hey Kris, I think you forgot to add stuff/base.h in this changeset: http://hg.suckless.org/wmii/rev/ebbfca4f7874 s...@yantram ~/l/s/wmii make MAKE all libstuff/ CC libstuff/buffer.o CC libstuff/clientutil.o In file included from ../include/stuff/util.h:5:0, from libstuff/clientutil.c:7: ../include/stuff/geom.h:3:24: fatal error: stuff/base.h: No such file or directory compilation terminated. make[1]: *** [clientutil.o] Error 1 make: *** [dall] Error 2 Thanks. P.S. Welcome back to wmii! :-)
Re: [dev] about handling the event loop of wmii
On Wed, May 5, 2010 at 8:14 AM, Emmanuel Oga emmanuel...@gmail.com wrote: I'm doing some experiments on scripting wmii with the help of eventmachine. I mounted the wmii fs [...] Then, I came up with this: http://gist.github.com/390396 Why not talk directly to wmii via 9P instead of going through a mount (which will invalidate any benefits you might gain from eventmachine)? In a way EM feels like a natural way of handling an event loop. Agreed. I would suggest grabbing Rumai's message library[1] and building your own transport layer[2] using EventMachine on top. However, note that Rumai already uses a single-threaded re-entrant transport strategy following the XCB cookie approach[3], so I don't know how much more benefit EventMachine will provide. [1] http://github.com/sunaku/rumai/blob/master/lib/rumai/ixp/message.rb [2] http://github.com/sunaku/rumai/blob/master/lib/rumai/ixp/transport.rb#L116 [3] http://www.x.org/releases/X11R7.5/doc/libxcb/tutorial/#requestsreplies this voice on the back of my mind that keeps telling my this might be overkill ... EM = mounted 9P = wmii(overkill) EM= wmii(maybe not)
Re: [dev] [wmii] disable mouse resizing in non-floating mode
On Thu, Mar 25, 2010 at 5:07 AM, Jonas H. jo...@lophus.org wrote: how can I disable resizing windows with the mouse in non-floating mode? Good point. Why do we have 2 ways of resizing: (1) the traditional WIMP way of putting your cursor on the client border and dragging and (2) pressing grabmod key and right clicking on a client (which is much more user-friendly IMHO because the entire client acts as the target of the click+drag, rather than the tiny 1-pixel client border)? I really hate this feature that I can't remember was there in wmii 3.6 because I frequently resize layers accidentally when using a scroll bar. Agreed. I also make the same mistake sometimes. Maybe we can delete resizing method #1 from the wmii source code and have one less annoying feature and less LOC to boot? Two birds for one stone. :-)
[dev] [wmii][ANN] Rumai 3.2.2 (2010-04-01)
Rumai 3.2.2 (2010-04-01) Ruby interface to the wmii window manager http://snk.tuxfamily.org/lib/rumai/ Rumai is a [1]Ruby interface to the [2]wmii window manager. Version 3.2.2 (2010-04-01) This release fixes some warnings that appeared during installation and performs some minor housekeeping. Bug fixes * Warnings of the following form appeared during gem installation: Unrecognized directive '...' in lib/rumai/inochi.yaml Thanks to [3]ghedamat for reporting this. Housekeeping * Upgrade to Inochi 2.0.0-rc2 for managing this project. References 1. http://ruby-lang.org/ 2. http://wmii.suckless.org/ 3. http://github.com/ghedamat
Re: [dev] [wmii] Reproducible crashes with dead windows
On Wed, Feb 24, 2010 at 1:29 PM, Tom Kazimiers t...@voodoo-arts.net wrote: I will add error checking, to detect a missing label section, right at the beginning when the status bar applet is initialized. That would be great. Improvements in robustness are most of tho time a good thing. Done: http://github.com/sunaku/wmiirc/commit/84c268c427d146b8e8b7297e90ba6e4db152b759 7. Run the gdb commands on the core dump file. if I understand the output correct, wmii is not the problem: Core was generated by `/usr/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/lib/flashplugin-'. Program terminated with signal 11, Segmentation fault. I hate the Adobe flash player :-) I don't know what the gdb means for my problem (I even had flash not running). Like I said before: It is reproducable by having a window in moving (grab/pan?) mode (so they are floating) while closing it. I am able to reproduce this by opening an xterm in the floating area, running sleep 3; exit command in the xterm, then grabbing it and moving it around. After 3 seconds, the xterm body disappears, leaving behind the window manager decorations and a solid window body. This zombie client remains in the floating area. If I right click its title bar and choose kill, nothing happens. If I choose slay, wmii crashes (core dumped) just as Tom described. You should file this as a bug on the wmii issues tracker: http://code.google.com/p/wmii/issues/list E, [2010-02-17T02:08:29.687682 #31728] ERROR -- : Broken pipe (Errno::EPIPE) This is a harmless error, which says that wmii abruptly closed the 9P socket through which it and Rumai communicate. Oh, ok thanks. But this also sounds not very common or good, but maybe I'm wrong. Yeah, it's uncommon, but nothing to worry about. Just ignore it. :-)
Re: [dev] Re: [ANN] Ruby wmiirc - YAML import feature
On Tue, Jan 5, 2010 at 9:22 AM, Armando Di Cianno arma...@goodship.net wrote: The default keybindings for column arrangment (e.g. Mod-z,s/d), are reused later in the arrange section. Thanks, fixed: http://github.com/sunaku/wmiirc/commit/098496db7253ebd409faa7eb5fc9584ae8563b91
Re: [dev] Re: [ANN] Ruby wmiirc - YAML import feature
On Mon, Jan 4, 2010 at 11:41 AM, Armando Di Cianno arma...@goodship.net wrote: * BUG: reload (from /lib/wmiirc, i.e. the menu) does not work -- it attempts to launch .wmii/wmiirc (which is $0) instead of the full path, e.g. ~/.wmii/wmiirc or /home/fafhrd/.wmii/wmiirc. Thanks. I also noticed this yesterday and fixed it. * ANNOYANCE: It was really surprising to see the defaults for max/stack/default be Mod-z,X. I don't follow HEAD of wmii development (maybe I should), but this really confused me for a minute. Maybe I use column client shifting more than most, but I'll probably be changing this back. (The addition of Mod-z,Shift-X is interesting, btw.) That's a strange shortcut indeed; where are you getting it? I assume you are using the control/keyboard/qwerty partial. * BUG: Related to above, but Mod-z,s/d don't seem to work right at all, creating new columns willy-nilly (although Mod-z,m seems to work). For e.g., if I have 2 columns, the right most with 4 clients, and one is focused, then I do Mod-z,d, I get a new middle column with 3 clients, and the focused one of the 4, is now in its own column, rightmost. Thanks, fixed. * ANNOYANCE: the default move of cycling through tags went from Mod-b and n to Mod-, and .. This would've been fine, but Mod-b is now move to temporary view, which was confounding for a minute as I made sense of the new environment Thanks. I changed prev/next to b/n and -b to -w for the temp view. * BUG: running ~/.wmii/wmiirc doesn't return -- not /explicitly/ a bug, but I'd expect it to do so, after killing/cleaning up the last instance. Yes, because it is not a daemon, but maybe it should be since I tee stdout and stderr to the log file anyway. I do agree with Emmanuel's point, that generally, editting Ruby-code in the YAML file is somewhat irritating. Hopefully, as this reorganization and cleanup continues, we might be able to massage that a bit. Sure, let's see how things go. Thanks for your efforts in Ruby + wmii! Cheers, You're welcome. :) Thanks for reporting these issues.
Re: [dev] Re: [ANN] Ruby wmiirc - YAML import feature
On Mon, Jan 4, 2010 at 11:57 AM, Armando Di Cianno arma...@goodship.net wrote: * BUG: Given the README doc located at the github repo (http://github.com/sunaku/wmiirc), it'd be nice if the example crash recovery .xinitrc supported a clean shutdown -- i.e. if I select quit from the menu, then wmii should always quit, without asking if I'd like to restart the window manager. I don't know how to implement this. If the wmiirc's exit status is reflected in wmii's exit status, then we could check that and break out of the loop instead of showing the recovery dialog. But this doesn't protect us from accidental exits: what if you run the kill action (or wmiir xwrite /ctl kill) by accident -- how can xinitrc recognize this? In this instance, all my clients are dead anyway, so restarting wmii at that point is somewhat pointless. Agreed. But it's a minor inconvenience IMHO, considering the difficulty of solving the ambiguity mentioned above. Patches are welcome. :-) Cheers.
Re: [dev] Re: [ANN] Ruby wmiirc - YAML import feature
On Mon, Jan 4, 2010 at 4:43 PM, Suraj Kurapati sun...@gmail.com wrote: On Mon, Jan 4, 2010 at 11:41 AM, Armando Di Cianno arma...@goodship.net wrote: * ANNOYANCE: the default move of cycling through tags went from Mod-b and n to Mod-, and .. I changed prev/next to b/n and -b to -w for the temp view. By the way, I don't actually use the QWERTY layout, so the keyboard shortcuts I chose are probably uncomfortable and unoptimal. Feel free to adjust them however you like and submit a patch.
[dev] Re: [ANN] Ruby wmiirc - YAML import feature
Suraj Kurapati wrote:
I'm pleased to announce the next evolution of my YAML-based Ruby wmiirc:
http://github.com/sunaku/wmiirc
I forgot to mention that the YAML structure has changed in this new
version, so your old config.yaml will not work as-is. In particular,
the following incompatible changes have been mode.
(1) The script section now defines an array:
# Arbitrary logic to execute either before or after processing this file. Any
# number of before and after subsections may be defined within this section.
#
# script:
# - before: Ruby code to execute before processing this file
# - after: Ruby code to execute after processing this file
# # ...
#
(2) Keys in thedisplay:status section have changed, and the code is
evaluated inside a Wmiirc::Status object (see display/status.yaml
for details).
# Status bar applets.
#
# - name:
#
# refresh: number of seconds to wait before updating the label
#
# script: Ruby code to evaluate in the Wmiirc::Status
# object that corresponds to this definition.
#
# label:Ruby code whose result is displayed as the
# content. This code is placed inside a
# label() method in the Wmiirc::Status object
# that corresponds to this definition.
#
# mouse_action:
# mouse event: name of action
#
# You can refresh a particular status bar applet in Ruby using:
#
# Status[your applet name].refresh
#
status:
(3) The control:grab section was moved to control:keyboard:grabmod.
(4) The control:key section was split into control:action and
control:keyboard_action so that the same logic can be shared among
keyboard shortcuts and mouse events.
# Keyboard shortcuts.
#
# key sequence: name of action
#
# A key sequence may contain ${...} expressions which
# are replaced with the value corresponding to '...' in
# the control:keyboard section of this configuration.
#
# For example, if the control:keyboard section was:
#
# control:
# keyboard:
# foo: Mod4
# bar: y
#
# and the following key sequence was used:
#
# ${foo}-${bar},${bar}
#
# then after ${...} expression replacement,
# that key sequence would appear like this:
#
# Mod4-y,y
#
keyboard_action:
(5) The program section was renamed to prefer.
I think that's about it. Cheers.
Re: [dev] Re: [ANN] Ruby wmiirc - YAML import feature
On Sun, Jan 3, 2010 at 7:33 PM, Emmanuel Oga emmanuel...@gmail.com wrote: On Sun, Jan 3, 2010 at 5:32 PM, Suraj Kurapati sun...@gmail.com wrote: I'm pleased to announce the next evolution of my YAML-based Ruby wmiirc: http://github.com/sunaku/wmiirc Thanks a lot for your hard work. I just recently started using your ruby based wmiirc and I'm enjoying a lot being able to configure my wmii with ruby so easily. Thanks for the kind words. I'm glad this project was useful to you. At the same time, I must point out that I find very annoying the usage of YAML for the configuration files. I suppose you choose to use it because it seemed to make sense for a configuration file. Yes, since the problem domain here is to describe a configuration, YAML felt like a better tool for the job because it let us describe the configuration declaratively, with minimal added syntax to distract us from the task at hand. But this configuration is so overcharged with ruby scripts that IMHO is not very practical to use YAML. wmii audiance is clearly programmers, and I think so called power users need to know at least a little about programming to be able to use the wmiirc. Good point. Mauricio Fernandez's ruby-wmii took the full-Ruby approach in the past, providing an internal DSL to configure wmii. And wmiircs written in other languages (Python, Lua, etc.) have basically followed the same approach. I guess I just wanted to try something different. However, I did not intend to dumb down the configuration by using YAML (and I do not think of it that way) because I consider myself as the primary target audience. i.e. I eat my own dog food, and like it. :-) Using YAML, the scripts end up looking like python (i.e., how you use white space matters), which is very annoying. I'm sorry to hear this. I was happy with the declarative YAML exterior and imperative Ruby cream filling because they felt like a good balance of both worlds (i.e. using the right tool for the job): declarative to get straight to point and imperative to do the heavy lifting. I had a goal to convert your YAML scripts to plain old ruby code, ... good thing I procrastinated it this time, now I'll be able to use your new code as a starting point! :-) Sure, this sounds interesting. I would imagine that only the interface through which we humans describe our configuration to the machine would change: from an external DSL to an internal one. Hopefully we can share the internals beneath these two interfaces. Cheers.
[dev] [ANN] Ruby wmiirc - YAML import feature
Fellow wmii users, I'm pleased to announce the next evolution of my YAML-based Ruby wmiirc: http://github.com/sunaku/wmiirc The big idea, suggested by Nathan Neff, is that the config.yaml file should be able to import other YAML files (partials as I call them). This allows us to share and maintain common code while having a different mix of status applets, keyboard shortcuts, color schemes, and so on. I also refactored the Ruby side of this wmiirc into namespaced modules, and moved the logic for keyboard shortcuts into the control:action section. This allows the same logic to be shared between different shortcuts (e.g. Qwerty vs Dvorak) and also between mouse actions (clicking on status bar applets). And finally, I reorganized the Git repository so that the user creates their own config.yaml based off the provided example.yaml file. This way they can check it into their own Git repo/branch without having conflicts with my stuff later on. Furthermore, I can continue updating everything else and the user can pull those changes without getting into merge conflicts and vice versa. I hope these changes make it easier for us to share and improve this wmiirc without stepping on each other's toes. :-) Please read the installation section of the README, as we are not using the 4-branch setup anymore. Cheers.
Re: [dev] [wmii] [rumai] view last tag
On Sat, Dec 19, 2009 at 12:30 PM, Yuval Hager yha...@yhager.com wrote: In rumai, is there a way to view the last tag viewed? Yes, it's available in both dvorak qwerty branches: http://github.com/sunaku/wmiirc/commit/dadff33db868c2986c0db3c27f5dbb5babb529af Note this is a very rough (uses globals; needs refactoring) and simple (only 1-level of history; no sorting) implementation. This existed in wmii-ruby, but I can't figure out how to do it in rumai. If you want to port the smarter working set algorithm[1] from ruby-wmii, patches are welcome! :-) [1]: http://eigenclass.org/hiki/ruby-wmii+0.2.1
Re: [dev] suckless password manager
On Thu, Dec 10, 2009 at 2:14 PM, Nibble nibble...@gmail.com wrote: It is just a little toy, but maybe it could be useful for someone else ;) http://nibble.develsec.org/hg/toys/file/da45af463c1c/passman I've done a similar toy with VIM + GPG back in the day: :-) http://snk.tuxfamily.org/bin/secure-edit.sh It's very important that the intermediate unencrypted file is destroyed upon script termination!
Re: [dev] [wmii] Firefox new windows
On Mon, Nov 23, 2009 at 9:57 AM, Joseph Xu joseph...@gmail.com wrote: On Mon, Nov 23, 2009 at 09:11:50AM -0800, Suraj Kurapati wrote: On Mon, Nov 23, 2009 at 8:58 AM, Yannic Haupenthal you might use /Firefox.*/ - sel # and/or /Shiretoko.*/ - sel in your tagrules. Awesome! This is the best solution. :-) Please disregard my other email in this thread. This doesn't seem to be working for me. Here's my tagrules: $ wmiir read /tagrules /Shiretoko.*/ - sel Sorry, I didn't actually try Yannic's suggestion; I just assumed it worked. Oh well, back to the drawing board. I solved this problem in my Ruby wmiirc by watching for the ClientCreate event and forcing the new window onto the current view by writing the value of the current tag to that new window's /client/.../tags file. Hope that helps.
Re: [dev] [wmii] Firefox new windows
On Mon, Nov 23, 2009 at 2:22 PM, Nick Guenther kou...@gmail.com wrote: Uh, I'm on 3.6 and the default wmiirc comes with a trailing tagrule of /.*/ - sel, followed by /.*/ - 1, which I'm guessing means that everything not matched previously gets sent to the selected view, but if there is no selected view (sel = nil) that second last rule won't apply, so instead it'll send the window to tag '1'. Ah! This makes sense. Thanks for the explanation. My wmii's behaviour is what you're looking for, so maybe the problem is just that you had Your sentence/email seems to have been truncated. Please retransmit.
Re: [dev] wmii9menu shows foo at top left
On Thu, Nov 19, 2009 at 5:22 PM, Kris Maglione wrote: On Wed, Nov 18, 2009 at 10:29:55PM -0800, Suraj Kurapati wrote: I see a gray foo string inside the first item in wmii9menu Works for me. Also, `hg grep -r tip foo` doesn't show any results. Thanks for fixing this! http://hg.suckless.org/wmii/rev/51dc80598d5450885c48e87bd82aa20c47b2b852
[dev] wmii9menu shows foo at top left
Hello, I see a gray foo string inside the first item in wmii9menu, using: % wmii -v wmii-hg2592, ©2009 Kris Maglione % wmii9menu -v @(#) wmii9menu version 1.8 Thanks for your consideration.
[dev] [wmii][ANN] Rumai 3.1.1
Rumai 3.1.1 Ruby interface to the wmii window manager http://snk.tuxfamily.org/lib/rumai/ Rumai is a [1]Ruby interface to the [2]wmii window manager. Version 3.1.1 (2009-11-16) This release fixes bugs in automated view arrangements and updates the user manual. Thank you * Nathan Neff reported the client ordering bug in automated view arrangements. Bug fixes * The relative order of clients was not being preserved during view arrangements. * Focus on the current view was lost after automated view arrangement was applied if the current view was not the first view on which the initially focused (before the automated arrangement was applied) client appeared. References 1. http://ruby-lang.org/ 2. http://wmii.suckless.org/
Re: [dev] [wmii][ANN] Rumai 3.1.1
On Tue, Nov 17, 2009 at 10:13 AM, Aditya Mahajan adi.maha...@gmail.com wrote: I recently updated to ruby 1.9 and rumai started crashing every few hours. wmii just froze, the mouse and keyboard still worked, but none of the keyboard shortcuts worked. Yes, this recently became a known problem: http://github.com/sunaku/wmiirc/issues/#issue/1 I just rewrote the send/recv methods in Rumai's IXP layer to be thread-less: http://github.com/sunaku/rumai/commit/951983523bc1debea78216e18f361878c1136020 Let's see if this solves the problem. Cheers.
Re: [dev] [wmii][ANN] Rumai 3.1.1
On Tue, Nov 17, 2009 at 12:09 PM, Aditya Mahajan adi.maha...@gmail.com wrote: For the record, I am also using Arch Linux. Same here. Not sure if that makes any difference or not. It should not matter. I just rewrote the send/recv methods in Rumai's IXP layer to be thread-less: http://github.com/sunaku/rumai/commit/951983523bc1debea78216e18f361878c1136020 Let's see if this solves the problem. Thanks. In case you're wondering how to try out that patch: cd ~/.wmii-hg git clone git://github.com/sunaku/rumai.git Then make this change to your config.rb file and restart the wmiirc: diff --git a/config.rb b/config.rb index c86797a..73d9ee3 100644 --- a/config.rb +++ b/config.rb @@ -8,8 +8,9 @@ require 'shellwords' require 'pathname' require 'yaml' -require 'rubygems' -gem 'rumai', '~ 3' +#require 'rubygems' +#gem 'rumai', '~ 3' +$LOAD_PATH.unshift File.join(File.dirname(__FILE__), 'rumai', 'lib') require 'rumai' include Rumai
[dev] [wmii][ANN] Rumai 3.2.0
Rumai 3.2.0 Ruby interface to the wmii window manager http://snk.tuxfamily.org/lib/rumai/ Rumai is a [1]Ruby interface to the [2]wmii window manager. Version 3.2.0 (2009-11-17) This release adds a new automated view arrangement, simplifies the IXP transport layer, and cleans up the code and API documentation. New features * Add Rumai::View#arrange_in_stacks automated view arrangement. * Convert :stack and :max arguments into wmii 3.9 syntax in Rumai::Area#layout=. Bug fixes * Rewrote IXP transport layer (Rumai::IXP::Agent) to not use a background thread, according to [3]the XCB cookie approach. Housekeeping * Clean up some code and API docs. * Reduce amount of string concatenation in Struct#to_9p. References 1. http://ruby-lang.org/ 2. http://wmii.suckless.org/ 3. http://www.x.org/releases/X11R7.5/doc/libxcb/tutorial/#requestsreplies
Re: [dev] JOE editor was: a little bit of vi+zsh magic
On Wed, Nov 4, 2009 at 11:33 AM, hiro 23h...@googlemail.com wrote: Today I was forced to use the joe editor for java. In the search-and-replace dialog (see s in ed) joe seemed to change my input to upper case automatically. Eventually I found out it was just auto-completion. If you don't want auto-completion you can add rare characters and delete them when you are ready. On a similar note, I recently installed Wine to play Deus Ex, an old favorite of mine. It was great fun re-living my past gaming experience, but soon the nostalgia wore off and my patience dwindled. Back to work... I was using the Epiphany browser to test some JavaScript in a web page that I generated, when I accidentally pressed Control-U: the view source command. To my horror, *Notepad* (from the Wine package) appeared on my screen! Of all the text editors available on my system, Epiphany chose Notepad as my default text editor. Perhaps I should hang myself...
[dev] [wmii] color themes wiki deleted?
Hello, There used to be a wiki page listing wmii color themes: http://wmii.suckless.org/scripts_n_snips/themes But that seems to have been deleted. Luckily, I found a copy (attached) of the source for that wiki page from an old checkout of the wiki. Please restore this wiki page. Thanks. themes.md Description: Binary data
Re: [dev] [wmii] color themes wiki deleted?
On Wed, Oct 7, 2009 at 8:40 AM, Marco Rucci marco.ru...@gmail.com wrote: The page is now here: http://wmii.suckless.org/themes. Thanks for restoring that page.
Re: [dev] [dwm] [wmii] Prompt for client to add to current view
On Tue, Oct 6, 2009 at 12:41 PM, Nathan Neff nathan.n...@gmail.com wrote: I don't quite understand how config.yaml gets turned into real ruby code See load_config() in config.rb
Re: [dev] wmii: Question on wmiirc_local.py
On Tue, Oct 6, 2009 at 1:49 PM, Kris Maglione maglion...@gmail.com wrote: I've thought about changing them all to Mod4, actually. Hurray! +1
Re: [dev] [wmii] rumai qwerty keys overlap
On Mon, Oct 5, 2009 at 7:34 AM, Nathan Neff nathan.n...@gmail.com wrote:
I'm trying out the qwerty branch of http://github.com/sunaku/wmiirc
I think that the {mod}-t and {mod}-{up} keys overlap
{mod}-t is bound to focus previous client
{mod}-{up} is bound to focus view chosen from a menu
Thanks, this has been fixed now:
http://github.com/sunaku/wmiirc/commit/87bf25ef7335cdbaa74015fe2ba7fc046974a2f6
Re: [dev] [wmii] rumai qwerty keys overlap
On Mon, Oct 5, 2009 at 1:01 PM, Suraj Kurapati sun...@gmail.com wrote:
On Mon, Oct 5, 2009 at 7:34 AM, Nathan Neff nathan.n...@gmail.com wrote:
{mod}-t is bound to focus previous client
{mod}-{up} is bound to focus view chosen from a menu
Thanks, this has been fixed now:
http://github.com/sunaku/wmiirc/commit/87bf25ef7335cdbaa74015fe2ba7fc046974a2f6
Sorry, I got my HJKL keys mixed up (I use [left, up, down, right] in
Dvorak and thought it was the same logical sequence in Qwerty). Here
is the corrected commit:
http://github.com/sunaku/wmiirc/commit/e62f40731dc5de047d53b654fb340ca2ff51d3fc
Re: [dev] [wmii] rumai qwerty keys overlap
On Mon, Oct 5, 2009 at 1:49 PM, Nathan Neff nathan.n...@gmail.com wrote:
However, the mod-j and mod-k keys conflict with the open browser and open
file manager shortcuts.
Can I suggest the following patch?
${mod}-i: | # launch a web browser
launch CONFIG['program']['browser']
${mod}-m: | # launch a file manager
launch CONFIG['program']['filer']
${mod}-n: | # launch a note taker
launch CONFIG['program']['editor']
Thanks. Your patch is applied:
http://github.com/sunaku/wmiirc/commit/8b08dd4694106a15fc149810111003119e8b126e
Feel free to totally rewire all shortcuts so they make more sense in a
QWERTY layout. Don't be constrained by the defaults I chose (such as
mod-x for launching terminal). Cheers.
Re: [dev] [dwm] [wmii] Prompt for client to add to current view
On Mon, Oct 5, 2009 at 1:30 PM, Nathan Neff nathan.n...@gmail.com wrote:
I'd like to have a menu that shows all the currently running clients,
and when I select a client, the current tag is applied to that client.
You can do it like this now in my Ruby wmiirc:
your_chosen_shortcut: | # bring a chosen client into current view
client = client_menu('invite client:') and client.tag curr_tag
The rumai wmiirc has a similar feature that will show a list of clients,
and when you choose a client, the selected client is shown.
I refactored that functionality into a common client_menu() method
(used in the above example) that is shared by all branches:
http://github.com/sunaku/wmiirc/commit/72c464daed724ee045d2112f865d66c4e7602d36#diff-1
Re: [dev] [ANN] Ruby (Rumai) based wmiirc now distributed with wmii
On Sun, Oct 4, 2009 at 8:45 AM, Yuval Hager yha...@yhager.com wrote: git checkout -b CHOICE --track # possible choices are: Shouldn't that be git checkout -b CHOICE --track origin/CHOICE Good catch. Fixed now. Thanks. http://github.com/sunaku/wmiirc/commit/02430a6099f6c4369824f1d5de0971a752638ad7
[dev] [ANN] Rumai 3.1.0
Rumai 3.1.0 Ruby interface to the wmii window manager http://snk.tuxfamily.org/lib/rumai/ Rumai is a [1]Ruby interface to the [2]wmii window manager. Version 3.1.0 (2009-10-02) This release adds new methods, fixes some bugs, and revises the manual. * [3]New features * [4]Bug fixes * [5]Housekeeping New features * Add Client#float methods to manipulate floating status. * Add Client#manage methods to manipulate managed status. * The Client#tags= method now accepts '~' and '!' tag prefixes. Bug fixes * There is no View#move_focus method, only View#select. * Assertion failure in test suite because all files in /rbar (inside wmii's IXP filesystem) contain an automatic color header when read. Housekeeping * Use simpler Copyright reminder at the top of every file. * Open source is for fun, so [6]be nice: speak of related works instead of competitors. References 1. http://ruby-lang.org/ 2. http://wmii.suckless.org/ 3. http://snk.tuxfamily.org/lib/rumai/#New-features 4. http://snk.tuxfamily.org/lib/rumai/#Bug-fixes 5. http://snk.tuxfamily.org/lib/rumai/#Housekeeping 6. http://loiclemeur.com/english/2009/03/never-criticize-your-competitors.html
Re: [dev] [ANN] Ruby (Rumai) based wmiirc now distributed with wmii
Suraj Kurapati wrote: I will move my eccentric setup to a personal branch on GitHub and merge your patches onto my GitHub master branch. I went further to replicate the stock sh wmiirc functionality for your convenience, and ended up with the following organization: # choose cd ~/.wmii-hg git checkout -b CHOICE --track # possible choices are: +++ | CHOICE | DESCRIPTION| +++ | dvorak | sunaku's personal configuration; DSK friendly! | | qwerty | QWERTY port of sunaku's personal configuration | | strict | port of the default wmiirc shipped with wmii | | master | barebones template for starting from scratch | +++ The 'strict' branch can be directly rolled into the next wmii release. It's currently missing the Mod1-Control-t functionality to disable/enable all shortcuts. I'll be adding that soon. The 'master' branch has a blank config.yaml file (with documentation). The 'dvorak' branch is what I use daily. It has the MPD integration. The 'qwerty' branch is the same as the 'dvorak' branch, plus my lame attempts to guess what key bindings QWERTY users are comfortable with (it's been too long since I was a QWERTY user... I don't know anymore!). Please feel free to improve and submit back. Cheers.
Re: [dev] [ANN] Ruby (Rumai) based wmiirc now distributed with wmii
On Tue, Sep 29, 2009 at 9:39 PM, Kris Maglione maglion...@gmail.com wrote: wmii now includes a ruby-based wmiirc by Suraj Kurapati. The distributed version contains minor changes so that the default configuration more closely resembles the default wmii configuration. Thanks, I am honored. I'm maintaining the changes as a Mercurial patch queue on a mirror of Suraj's repo at suckless.org: http://hg.suckless.org/wmiirc-rumai/ I will move my eccentric setup to a personal branch on GitHub and merge your patches onto my GitHub master branch. This way, my GitHub repo will stay in sync with your official wmii one and newcomers won't be scared away by my eccentric defaults. ;-) Cheers.
Re: [dev] [ANN] Ruby (Rumai) based wmiirc now distributed with wmii
On Wed, Sep 30, 2009 at 1:32 AM, Suraj Kurapati sun...@gmail.com wrote: I will move my eccentric setup to a personal branch on GitHub and merge your patches onto my GitHub master branch. This is done. master = http://github.com/sunaku/wmiirc/ personal = http://github.com/sunaku/wmiirc/tree/personal By the way, Kris, these two patches got mixed up in your quilt: tag: remove-proc-loadavg files: config.yaml description: Use uptime(1) in favor of linux-specific /proc/loadavg. tag: remove-mpd description: Remove MPD integragion. The remove-mpd patch was empty, and the remove-proc-loadavg patch seems to contain what remove-mpd should have contained. Cheers.
Re: [dev] [wmii] upcoming release and fullscreen bugs
On Fri, Sep 11, 2009 at 12:31 PM, Thomas Dahms da...@gmx.com wrote: - Switch from ~/.wmii-hg to ~/.wmii. +1
Re: [dev] A lightwieight and working typesetting system.
On Sat, Sep 5, 2009 at 3:29 AM, Antoni Grzymalaant...@chopin.edu.pl wrote: Mate Nagy dixit (2009-09-05, 12:17): Books on paper are great, although the interface is a bit dated; I'd much rather have the 90dpi PDA screen that remembers my position in multiple books, and sometimes I can even search for stuff. Position in books I read is remembered by a simple device called a bookmark. No need for advanced tech on silicon+software on that. :) Your answer reminds me of The Complicator's Gloves story[1], quite suckless! [1]: http://thedailywtf.com/Articles/Classic-WTF-The-Complicators-Gloves.aspx
Re: [dev] wmii next release
On Mon, Aug 10, 2009 at 2:30 AM, Michalm...@infosec.pl wrote: I really believe that it would be a good idea to cut off another release so various distributions can put it into their's packaging systems and therefore make life easier for end users (like me). Kris tagged version 3.9a1 in the HG repo: http://hg.suckless.org/wmii/rev/91b71c707eb284f7a9a5dbabededf38c06223860 So I suspect we'll be seeing a release soon.
Re: [dev] wmii next release
On Sun, Aug 30, 2009 at 11:25 PM, Suraj Kurapatisun...@gmail.com wrote: Kris tagged version 3.9a1 in the HG repo: So I suspect we'll be seeing a release soon. Ugh, sorry, you guys already discussed this in the future! /me catching up on email chronologically...
[dev] Xft in HG - no 9P socket
Hello, The following changeset in HG prevents the creation of the 9P server socket on my machine. http://hg.suckless.org/wmii/rev/61414254ec5904d9b2942258a85a343f18fbb448 Neither my wmiirc nor the plain old `wmiir` command are able to connect to the 9P server socket at /tmp/ns.$USER.:$DISPLAY/wmii. Does this happen to anyone else? Thanks for your consideration.
Re: [dev] Xft in HG - no 9P socket
On Mon, Aug 31, 2009 at 2:35 PM, Kris Maglionemaglion...@gmail.com wrote: On Mon, Aug 31, 2009 at 01:41:15PM -0700, Suraj Kurapati wrote: Neither my wmiirc nor the plain old `wmiir` command are able to connect to the 9P server socket at /tmp/ns.$USER.:$DISPLAY/wmii. No such problems here. Can you provide any more info? Thanks, your confirmation helped me find the problem: there was a bad mixture of old new installs from HG because I always run `hg pull -u make install`. This time I ran `make uninstall clean install` and wmii works without problems. Sorry for the confusion.
Re: [dev] Reload wmiirc.py on the fly?
On Sun, Aug 16, 2009 at 7:22 PM, Nathan Neffnathan.n...@gmail.com wrote: I'd like to know if there's a way to reload the configuration script without restarting wmii? The classic approach to solve this problem has been to have every wmiirc: 1. Write Start wmiirc\n to /event 2. Begin reading /event and self-terminate when Start wmiirc\n is found Then, the process of reloading becomes as simple as running `wmiirc`.
