[dev] dmenu-vertical (meillo) slow
Hi all is it just me or does dmenu with meillo's vertical patch applied get slower and slower the more lines you specify with the "-l" option? Anything more than about ten lines is unusable on my t42 using Ubuntu Karmic development version. Cheers Arian
Re: [dev] dmenu-vertical (meillo) slow
Thanks for the confirmation guess there is something wrong with my system then, will have to have a closer look. But nice work anyway (to Fresch or whoever), the vertical patch makes dmenu much more useful for certain things. Cheers Arian On Sun 18, 10:30 +0200, markus schnalke wrote: > [2009-10-17 12:55] Arian Kuschki > > > > is it just me or does dmenu with meillo's vertical patch applied get slower > > and > > slower the more lines you specify with the "-l" option? Anything more than > > about ten lines is unusable on my t42 using Ubuntu Karmic development > > version. > > I don't see any performance change if I use `-l 30'. > > > However I didn't write the patch myself and didn't have deep looks into > the code, I just used fresch's patch and removed everything I found > useless or disturbing the design of dmenu. > > That's what my patch is: fresch's patch made conforming to the software > style we have here. > > > meillo > --
Re: [dev] [patch] xmms like pattern matching for dmenu (update to hg tip)
Excerpts from Uriel's message of 2010-08-10 02:01:40 +0200: > This seems like a rather clumsy, non-standard and silly way to > implement globbing. > > Implementing * and ? wildcards would be a much better idea. I've been using the original patch for a while already and I find it easier and quicker to type "dme atc" than "dme*atc". Also personally I never needed the increased granularity of "*" and "?" for filtering, neither for bookmarks, file names, contacts nor executables. And finally, with shell-like globbing the sub strings could not be in arbitrary order I guess which would be inconvenient. What is your use case? (And by the way if you want to see a truly borked matching algorithm, try the Command-T Vim plugin) --
Re: [dev] [wmii] wimenu custom completion
Excerpts from LuX's message of 2010-08-16 00:37:54 +0200: > Example: In bash I have always been missing a history behaving like in > vim. Let me explain this. If you have typed a long command 'cmd' at put "\C-n": history-search-forward "\C-p": history-search-backward and/or "\e[B":history-search-forward "\e[A":history-search-backward into ~/.inputrc to get vim-like completion with Control-P/N and/or up/down keys. Read "man readline" for more info. --
Re: [dev] [patch] dmenu - support for xft font rendering
Excerpts from Henri Mannerberg's message of 2010-09-01 12:10:06 +0200:
>
> This patch adds support for xft font rendering to dmenu (4.1.1).
>
> Shouts go out to lattenwald (utf8 support) and R. Kyle Murphy (fg color fix)
>
> The patch can also be found at:
> http://aur.archlinux.org/packages.php?ID=28745
>
> diff -up ../dmenu-4.1.1/config.def.h ../dmenu-4.1.1-xft/config.def.h
> --- ../dmenu-4.1.1/config.def.h2010-05-29 14:56:51.0 +0300
> +++ ../dmenu-4.1.1-xft/config.def.h2010-09-01 12:05:27.51064 +0300
> @@ -7,3 +7,4 @@ static const char *normfgcolor = "#0
> static const char *selbgcolor = "#0066ff";
> static const char *selfgcolor = "#ff";
> static unsigned int spaceitem = 30; /* px between menu items */
> +static const char *fontxft = "Monospace-10:normal"; /*if set xft is used
> */
> diff -up ../dmenu-4.1.1/config.mk ../dmenu-4.1.1-xft/config.mk
> --- ../dmenu-4.1.1/config.mk2010-05-29 14:56:51.0 +0300
> +++ ../dmenu-4.1.1-xft/config.mk2010-09-01 12:05:27.51363 +0300
> @@ -15,8 +15,8 @@ XINERAMALIBS = -L${X11LIB} -lXinerama
> XINERAMAFLAGS = -DXINERAMA
>
> # includes and libs
> -INCS = -I. -I/usr/include -I${X11INC}
> -LIBS = -L/usr/lib -lc -L${X11LIB} -lX11 ${XINERAMALIBS}
> +INCS = -I. -I/usr/include -I${X11INC} -I/usr/include -I/usr/include/freetype2
> +LIBS = -L/usr/lib -lc -L${X11LIB} -lX11 ${XINERAMALIBS} -lXft -lX11
> -lXrender -lfreetype -lz -lfontconfig -lXrender -lX11
>
> # flags
> CPPFLAGS = -D_BSD_SOURCE -DVERSION=\"${VERSION}\" ${XINERAMAFLAGS}
> diff -up ../dmenu-4.1.1/dmenu.1 ../dmenu-4.1.1-xft/dmenu.1
> --- ../dmenu-4.1.1/dmenu.12010-05-29 14:56:51.0 +0300
> +++ ../dmenu-4.1.1-xft/dmenu.12010-09-01 12:05:27.51563 +0300
> @@ -7,6 +7,7 @@ dmenu \- dynamic menu
> .RB [ \-b ]
> .RB [ \-l " "]
> .RB [ \-fn " "]
> +.RB [ \-fa " "]
> .RB [ \-nb " "]
> .RB [ \-nf " "]
> .RB [ \-p " "]
> @@ -34,6 +35,9 @@ The given number of lines will be displa
> .B \-fn
> defines the font.
> .TP
> +.B \-fa
> +defines the xft font.
> +.TP
> .B \-nb
> defines the normal background color (#RGB, #RRGGBB, and color names are
> supported).
> .TP
> diff -up ../dmenu-4.1.1/dmenu.c ../dmenu-4.1.1-xft/dmenu.c
> --- ../dmenu-4.1.1/dmenu.c2010-05-29 14:56:51.0 +0300
> +++ ../dmenu-4.1.1-xft/dmenu.c2010-09-01 12:05:27.52063 +0300
> @@ -13,6 +13,7 @@
> #ifdef XINERAMA
> #include
> #endif
> +#include
>
> /* macros */
> #define CLEANMASK(mask) (mask & ~(numlockmask | LockMask))
> @@ -29,6 +30,7 @@ typedef struct {
> int x, y, w, h;
> unsigned long norm[ColLast];
> unsigned long sel[ColLast];
> +Bool selected;
> Drawable drawable;
> GC gc;
> struct {
> @@ -38,6 +40,16 @@ typedef struct {
> int descent;
> int height;
> } font;
> +XftDraw *xftdraw;
> +XftColor xftselcolor;
> +XftColor xftcolor;
> +XGlyphInfo gi;
> +struct {
> +XftFont *xft_font;
> +int ascent;
> +int descent;
> +int height;
> +} xftfont;
> } DC; /* draw context */
>
> typedef struct Item Item;
> @@ -135,18 +147,23 @@ calcoffsetsh(void) {
> void
> calcoffsetsv(void) {
> static unsigned int h;
> +int h2;
>
> if(!curr)
> return;
> -h = (dc.font.height + 2) * (lines + 1);
> +if(fontxft)
> + h2 = dc.xftfont.height;
> +else
> + h2 = dc.font.height;
> +h = (h2 + 2) * (lines + 1);
> for(next = curr; next; next=next->right) {
> -h -= dc.font.height + 2;
> +h -= h2 + 2;
> if(h <= 0)
> break;
> }
> -h = (dc.font.height + 2) * (lines + 1);
> +h = (h2 + 2) * (lines + 1);
> for(prev = curr; prev && prev->left; prev=prev->left) {
> -h -= dc.font.height + 2;
> +h -= h2 + 2;
> if(h <= 0)
> break;
> }
> @@ -185,9 +202,14 @@ cleanup(void) {
> free(allitems);
> allitems = itm;
> }
> +if(fontxft) {
> +XftColorFree (dpy, DefaultVisual(dpy, screen),
> DefaultColormap(dpy, screen), &dc.xftcolor);
> +XftFontClose (dpy, dc.xftfont.xft_font);
> +XftDrawDestroy(dc.xftdraw);
> +}
> if(dc.font.set)
> XFreeFontSet(dpy, dc.font.set);
> -else
> +else if(!fontxft)
> XFreeFont(dpy, dc.font.xfont);
> XFreePixmap(dpy, dc.drawable);
> XFreeGC(dpy, dc.gc);
> @@ -198,8 +220,15 @@ cleanup(void) {
> void
> drawcursor(void) {
> XRectangle r = { dc.x, dc.y + 2, 1, dc.font.height - 2 };
> +int h2;
>
> -r.x += tex
Re: [dev] [patch] dmenu - support for xft font rendering
Excerpts from Ethan Grammatikidis's message of 2010-09-01 19:00:17 +0200: > Connor Lane Smith wrote: > > If someone were to write a simple clean xft patch for libdraw it could > > be useful, perhaps even integrated into mainline. > This may just be my limited perspective, or it may be my upset stomach > talking, but I'm very surprised to see xft seriously suggested in this > mailing list. Xft is (to me) synonymous with the transition of X.org > from something bad but usable into a black box nightmare best left to > distro tools to cope with. Maybe it wasn't so bad for other people, > maybe it got better. I can't comment on the code complexity, but I do wish there was support for proportional fonts and other typographical niceties in terminal/ncurses apps. Not directly related to Xft I guess, but longer texts (email/rss feeds...) in monospace look rather unpleasant. It would be awesome if swk could reconcile the simplicity and efficiency of suckless tools with some basic regard for typography. --
Re: [dev] [patch] dmenu - support for xft font rendering
Excerpts from Connor Lane Smith's message of 2010-09-01 21:33:23 +0200: > I'm sympathetic with this view, being a lover of typography myself. But > you're in luck! dmenu, dwm, and libdraw already do support variable-width > fonts. My desktop system runs dmenu in Helvetica. :) great news, glad to hear there is a like-minded soul here with the programming chops to actually make stuff happen! --
Re: [dev] [patch] dmenu - support for xft font rendering
Good stuff! (sorry, Android mail) Am 02.09.2010 16:52 schrieb "Henri Mannerberg" : > > The patch has been updated: fg highlighting now works in vertical mode. > > -- > Henri > > On Wed, Sep 01, 2010 at 07:57:03PM +0300, Henri Mannerberg wrote: >> My pleasure. I will take a look at the issue with the '-l' switch when I have >> the time. >> >> ... >> >> On Wed, Sep 01, 2010 at 01:29:37PM +0200, Arian Kuschki wrote: >> > >> > Thanks for this, Henri. The only issue I have is that the font colour >> > does not change when highlighted when I call dmenu with the '-l' option. >> > -- >> >
Re: [dev] Sandy editor
On 27 May 2011 10:46, Aurélien Aptel wrote: > On Fri, May 27, 2011 at 10:29 AM, Aurélien Aptel > wrote: > > arrows on them. A triangle layout (wqsd or ijkl for example) is much > > easier to type. > > I meant wasd (on qwerty), obviously. > > that would be just sweet for the myriads of colemak users like myself
[dev] [dwm] segfault
Hi, after happily having used dwm for years it started to segfault on me in regular intervals since I switched to a new laptop (T43 -> T420s). Not sure what the trigger is yet, /var/log/everything looks shows this: Jun 22 15:25:32 localhost kernel: [11636.771129] dwm[1325]: segfault at 0 ip 004030b8 sp 7fff84382650 error 4 in dwm[40+c000] hg summary shows parent: 1560:e181c9cf318e tip Also, I applied the 'pertag' patch and maybe another one that I can't remember right now. How can I diff my local version against tip? Sorry am more of a git user. Any hints?
Re: [dev] [dwm] segfault
On 22 June 2011 15:44, Andrew Hills wrote: > On Wed, Jun 22, 2011 at 9:32 AM, Arian Kuschki > wrote: > > How can I diff my local version against tip? > > Check out tip: > > hg clone http://hg.suckless.org/dwm > > Then diff: > > diff /path/to/your/dwm.c /path/to/tip/dwm.c > > yeah, I guess I was being stupid there.. I was looking for something analogous to git diff, but obviously this works and is very simple, thanks. > --Andrew Hills > >
Re: [dev] [dwm] segfault
On 22 June 2011 16:10, Rob wrote: > Build with debug flags (-g in Makefile) > > Enable coredumps in your .xinitrc > ulimit -c unlimited > > Wait until dwm segfaults > $ gdb --core=path/to/core dwm > > bt > > Voila, you've got the bug's location. > > when i enter ulimit without arguments, the output is 'unlimited'. I assume that means coredumps should be enabled already on my machine? Anyway, so when dwm segfaults next time, where will I find the coredump file?
Re: [dev] [dwm] segfault
On 22 June 2011 15:44, Bogdan Ionuț wrote: > > it segfaults only when "reloading" dwm? then it's pertag related. i > use pertag2 and adding m->mfacts[0] = mfact; in createmon() solves the > issue. > > not sure what you mean by "reloading"? I have a suspicion that the problem has to do with dual displays, but I guess I will know as soon as dwm segfaults next time, which shouldn't be too long judging by recent experience..
[dev] [slock] segfault
Hi, I get a segfault when running slock via my acpi handler script: Dec 4 23:15:00 localhost kernel: [26284.789539] slock[13389]: segfault at 0 ip 7f12b8b57879 sp 7fff74d6d810 error 4 in libnss_files-2.14.1.so[7f12b8b5+b000] It runs fine when called from the command line etc. Any ideas? Cheers, Arian
Re: [dev] [slock] segfault
On 4 December 2011 23:55, Rob wrote: > On 4 December 2011 22:19, Arian Kuschki wrote: >> I get a segfault when running slock via my acpi handler script: >> >> Dec 4 23:15:00 localhost kernel: [26284.789539] slock[13389]: >> segfault at 0 ip 7f12b8b57879 sp 7fff74d6d810 error 4 in >> libnss_files-2.14.1.so[7f12b8b5+b000] > > Can you get a coredump and give us a stack trace? > > In your script: > ulimit -c unlimited > Then when slock segfaults, hunt around for a file named "core". > Probably in $HOME > > Then: > $ gdb path/to/slock path/to/core > (gdb) bt > > > You might want to compile slock with debug flags too (replace -s with > -g in config.mk) > Rob Thanks for the timely response Rob, but I think I found the reason: calling slock like so export DISPLAY=:0 && sudo -u $USER slock in my acpi handler script fixes the problem. So it seems it is not slocks fault, but rather some X-specific knowledge I guess I should have had. Cheers, Arian
[dev] what's your opinion on Go
Hi all, I would like to learn a new programming language. I do not know C. As I remember positive reactions on this list when Go came out, I would like to know if people still think it might be a 'better C'. One thing I like about Go is that is seems more suitable for server/web stuff, which is where I 'earn my bread' (working in Java and Javascript mainly, also Python) . But is it also good for building stuff like dmenu, dwm, cli tools in general etc? Or is C still king here? Cheers, Arian
Re: [dev] [dwm] systray in upstream dwm?
On 4 April 2012 22:29, Jan Christoph Ebersbach wrote: > ** > Hi, > > What needs to be done to get the systray patch upstream into dwm? Is there > any chance of getting it upstream or is it a total no go? > > The patch proved to be stable and I continued to refine it over last week. > Please let me know in case you discover any issues. > > Jan Christoph > > This message was sent using Zarafa WebApp. > The patch does not apply to dwm-6.0 cleanly, could you update it to 6.0 or tip? I for one am tired of running a standalone tray just to be able to use network-manager and am grateful for this. Cheers, Arian
Re: [dev] [dwm] systray in upstream dwm?
On 5 April 2012 19:18, Micheal Smith wrote: > Just updated the patch to apply cleanly with 6.0. Hope that helps. > > Thanks, > Micheal > Thanks for this, unfortunately it still does not apply for me. Actually I think I lost interest in this patch already, it feels too complex. I don't want to make this dance everytime there is a new dwm version. But just out of interest, does the following work for you? mkdir test cd test wget http://dl.suckless.org/dwm/dwm-6.0.tar.gz tar xf dwm-6.0.tar.gz cd dwm-6.0/ wget http://dwm.suckless.org/patches/dwm-6.0-systray.diff patch -p1 < dwm-6.0-systray.diff
Re: [dev] [dwm] systray in upstream dwm?
On 5 April 2012 20:42, Micheal Smith wrote: > On Thu, Apr 05, 2012 at 08:40:55PM +0200, Arian Kuschki wrote: > > On 5 April 2012 19:18, Micheal Smith wrote: > > > > > Just updated the patch to apply cleanly with 6.0. Hope that helps. > > > > > > Thanks, > > > Micheal > > > > > > > Thanks for this, unfortunately it still does not apply for me. Actually I > > think I lost interest in this patch already, it feels too complex. I > don't > > want to make this dance everytime there is a new dwm version. But just > out > > of interest, does the following work for you? > > > > mkdir test > > cd test > > wget http://dl.suckless.org/dwm/dwm-6.0.tar.gz > > tar xf dwm-6.0.tar.gz > > cd dwm-6.0/ > > wget http://dwm.suckless.org/patches/dwm-6.0-systray.diff > > patch -p1 < dwm-6.0-systray.diff > > It does indeed work for me (copy / pasted your process with no errors). > The > patch doesn't seem overly complicated to me. I think originally the author > may have simply created a patch of an already patched version. > > Ok, I am stupid. It works now, thanks for your help Michael.
Re: [dev] Multimedia keys doesn't send proper keycodes
On 17 April 2012 20:17, Ivan Kanakarakis wrote: > > > On 17 April 2012 21:16, Ivan Kanakarakis wrote: > >> try adding >> >> #include >> >> before the keys array >> >> > > or use the keycode directly, instead of the keysymbol > or use xbindkeys to bind those keys, e.g. a ~$ cat .xbindkeysrc "amixer set Master unmute; amixer set Master 10%+" XF86AudioRaiseVolume "amixer set Master unmute; amixer set Master 10%-" XF86AudioLowerVolume "amixer set Master toggle" XF86AudioMute
[dev] [dwm] tag changes when applications are activated
Hi, for some time now, not sure how long, dwm changes the displayed tag when an application is activated. E.g. I click a link that is opened in an external program and that program comes into view even if its tag was not visible before. Dwm behaves like OS X now in this regard. Is this a bug or a feature? How can I turn it off? Cheers, Arian
[dev] Re: [dwm] tag changes when applications are activated
On 18 April 2012 09:57, Arian Kuschki wrote: > Hi, > > for some time now, not sure how long, dwm changes the displayed tag when > an application is activated. E.g. I click a link that is opened in an > external program and that program comes into view even if its tag was not > visible before. Dwm behaves like OS X now in this regard. Is this a bug or > a feature? How can I turn it off? > > Cheers, > Arian > I should have mentioned that I am using 6.0. No patches.
Re: [dev] [dwm] tag changes when applications are activated
On 18 April 2012 12:52, Connor Lane Smith wrote: > On 18 April 2012 08:57, Arian Kuschki > wrote: > > for some time now, not sure how long, dwm changes the displayed tag when > an > > application is activated. > > The blame here is either with dwm or the application, depending on the > way you look at it. Essentially, dwm supports the _NET_ACTIVE_WINDOW > EWMH client message, and your application sends it. I'm not sure dwm > should support this, as it doesn't really make sense given dwm's > tagging paradigm. > > You can disable it by commenting out lines 543 to 549 in dwm.c, the > "else if(cme->message_type == netatom[NetActiveWindow])" block. > That seems to work, thank you.
Re: [dev] dwm tip changes
On 23 June 2012 20:06, Anselm R Garbe wrote: > Also, dwm now disallows resizing/moving/float fullscreen windows, as > this doesn't seem very useful anyways. I haven't tested the changes yet, I just want to say that I find resizing full screen windows useful sometimes. For some apps (e.g. Evince) going full screen seems to be the only way to hide menu bars etc. This means when you want to efficiently use your screen (e.g. half/half editor/pdf file), it makes sense to put an app into full screen and then make it smaller again. I know there are probably apps in every category that allow one to do this without going full screen. So, just my 2 cents. Cheers, Arian > > Please test hg tip and let me know any issues you encounter. > > > Thanks, > Anselm >
Re: [dev] dwm tip changes
On 24 June 2012 11:01, Anselm R Garbe wrote: > I understand your remark. The newly introduced limitation addresses > the moving/resizing by mouse only. Ah, I see. I don't use the mouse for what I described, so as long as full screen windows can still be tiled my use case is covered. Great! > The issue here is really that we are dealing with broken concepts. > Apps that provide a better UI in fullscreen mode should be fixed to do > so in normal screen mode imho. > > The new approach seems conceptually clearer, as it makes no compromise > for the category of clients that destroy the window on re-adjustment. I cannot judge the cost of additional complexity to dwm's source. But I think being able to use certain sucky apps in 'full-screen-tiling' mode actually makes the world suck a little bit less. I don't believe e.g. evince or chromium will be 'fixed' anytime soon in this regard. Cheers, Arian
