Re: [dev] unsubscribe
You have been successfully trolled on this mailing list.
Re: [dev] Re: ... and then i go and spoil it all by saying somethingstupid ...
On Wed, 15 Feb 2012 19:02:20 +0100 Jakub Lach wrote: > Dnia 15 lutego 2012 17:54 hiro <23h...@googlemail.com> napisał(a): > > > > Now you get sucked less, I guess. > > > > It's not a bug, it's a feature. > > Deleted relationship is debugged relationship. > > awesome thread
Re: [dev] FOSDEM
On Mon, 30 Jan 2012 12:31:33 + suckless-...@njw.me.uk wrote: > So, FOSDEM is this weekend. Is anyone on the list coming? > > I'm looking forward to going, and it'd be fun to meet up > with like-minded folks. > > Nick > I'm going.
Re: [dev] Siemens RTL Tiled Window Manager
On Mon, 19 Dec 2011 18:20:49 +0100 Connor Lane Smith wrote: > On 19 December 2011 18:11, Christoph Lohmann <2...@r-36.net> wrote: > > before you guys start using rtl like dwm, here's a presentation > > video[0] about how it was intended to be used. > > Ellis Cohen wins. I demand that 1:00 - 1:25 be used to introduce every > talk on dwm from here on out. what a funny guy. that ^^ or somebody creates a parody video for dwm. (oh wait that wouldn't be suckless, yeah just cut the part from the rtl video)
Re: [dev] dmenu's lsx binary naming conflicts with lrzsz!
On Mon, 28 Nov 2011 07:52:17 -0500 Kurt H Maier wrote: > On Mon, Nov 28, 2011 at 4:48 AM, Dieter Plaetinck > wrote: > > If you can avoid conflicts, that's better than expecting packagers > > (of each distro) to fix it. > > I disagree. lsx-lrzsz is clearly less useful or important than > lsx-dmenu. Just because some idiot camped out on a three-letter > string doesn't mean his symlink is suddenly sacred and immutable. > It's the whole job of a distribution maintainer to decide which side > he's on. > > In short: screw 'em. > I was talking in general. The case where an "idiot" "stole" a 3-letter string is a very specific case where it can be justified to reuse the same name.
Re: [dev] dmenu's lsx binary naming conflicts with lrzsz!
On Sun, 27 Nov 2011 17:51:03 -0500 Kurt H Maier wrote: > Just call it 'stest'. If there's a collision, that's what packagers > are for. If you can avoid conflicts, that's better than expecting packagers (of each distro) to fix it.
Re: [dev] [dmenu] Keyboard Bindings
On Mon, 21 Nov 2011 09:59:49 +0100 Yoshi Rokuko wrote: > +--- Dieter Plaetinck ---+ > > I don't understand... Are you saying "I agree the > > token matching works fine and is the fastest, but I > > still want you to implement an inferior and more > > complicated approach (regexes)" ? > > i don't want you to implement regexp, i'm quite happy > with v4.3.1, i will even upgrade in the future and if > you have some token matching implemented i will get > used to it - have no fear. > > however for me regexp is not inferior to your token > matching, it is more versatile and people are used to > it - it is common. i'm just sceptical about this 'yet > another matching scheme' ... > FWIW, re "yet another": token matching is also implemented in xmms, firefox (awesomebar), chromium/chrome and with uzbl/luakit(/surf?) by using dmenu and AFAIK users love it. probably even some more cases i'm not aware of.. Dieter
Re: [dev] [dmenu] Keyboard Bindings
On Sun, 20 Nov 2011 20:28:14 +0100 Yoshi Rokuko wrote: > i use dmenu only on url and program names, i used it for file names too, > but my files do not have whitespaces, and i agree that typing 'hg ta' > is much faster then 'hg.*ta', but i think one should not touch REGEXP(7) > in a single program that is part of a toolkit ... you know what i mean. > > i am not talking about legacy support or change in general, i would > love it if dmenu would support REGEXP(7) patterns. > > best regards, yoshi > I don't understand... Are you saying "I agree the token matching works fine and is the fastest, but I still want you to implement an inferior and more complicated approach (regexes)" ? Dieter
Re: [dev] [dmenu] Keyboard Bindings
On Sun, 20 Nov 2011 14:43:59 +0100 Yoshi Rokuko wrote: > i think we all expect dmenu to match patterns as grep (?) nope.
Re: [dev] [dwm] 2000 SLOC
On Mon, 31 Oct 2011 10:11:28 +0100 Anselm R Garbe wrote: > 3. Quality: the project must aim to be a quality finished product once > exceeding the 1.0 version number and be maintained afterwards. > Unmaintained projects will be removed after a grace period of one > year. those kind of version numbers are usually pretty arbitrary. why not just use date based versions, and call it beta software as long as it doesn't meet the appropriate criteria. Dieter
Re: [dev] Linux sucks!
On Fri, 28 Oct 2011 13:16:33 +0100 Connor Lane Smith wrote: > On 28 October 2011 12:46, Kurt H Maier wrote: > > this is the biggest part of why he's an asshole. if you're not > > willing to learn how to use a computer don't buy a computer. if > > your biggest complaint about a piece of software is "I can't > > immediately use it" then you are an asshole, full stop. > > Plus there's the problem with 'intuitive' systems that once you've > learned one system (Windows), 'intuitive' is now overloaded with the > meaning "like things I already know." Learning how to use computers is > difficult. I for one grew up with Windows, and was taught to use > Office in ICT lessons and so on... Urgh. > > (The only truly intuitive interface is a nipple.) > > So people look at Linux and say it's unintuitive, etc, but for the > most part it's just unfamiliar. There are certain things which are > certainly more difficult in Linux, but I'd argue package managers, for > instance, are far nicer for novice users. People seem to want Linux to > be identical to Windows, except better. That's just not possible. > > Nor is it even desirable. Windows already exists; let's make something > which suits those of us who do not find it easy to use. I certainly > don't, and if every interface were 'intuitive' in the sense that > Windows is, I doubt I'd be able to use a computer as well as I do. > > So much for intuition. > > cls > Well said. However about a nipple being the only truly "intuitive" interface, that's because our instincts are carried in our DNA, which - one could argue - is also a form of memory and acclimatization (mammals have learned to breastfeed over a long time), an acclimatization just as your windows example, except that it forms (and is maintained) accross generations and generations, not just during the life of a single person. Now that I think about it, I think that if generations of people use windows, this acclimatization also slowly grows in their DNA, I believe I recently read an article that supports this thought. So basically, any kind of acclimatization leaves its traces in DNA and gets inherited, and manifests itself under the form of "intuition". see also http://wakeup-world.com/2011/07/12/scientist-prove-dna-can-be-reprogrammed-by-words-frequencies/ So knowing this, I would classify the expectations that arise as a consequence of being indoctrinated by years of windows usage, under the category of intuition :) Dieter
Re: [dev] Linux sucks!
On Fri, 28 Oct 2011 09:25:48 +0200 Pieter Praet wrote: > On Fri, 28 Oct 2011 08:54:12 +0200, Dieter Plaetinck > wrote: > > On Thu, 27 Oct 2011 22:33:18 +0100 > > Guilherme Lino wrote: > > > > > latex is cool, vim, dwm, but no one out of the professional > > > field of computer sience have the time or patience to learn this > > > unix philosophy.. > > > > are you trolling or what? > > "nobody will ever need more then 64k of memory".. > > now "no professional computer scientist knows the unix philosophy" ? > > > > I may be mistaken, but I think he meant the exact inverse, > which is of course equally ludicrous. > > > Peace > Oh now you mention in it. One can interpret "out of" in two ways.. but agreed with what you said :) Dieter
Re: [dev] Linux sucks!
On Thu, 27 Oct 2011 22:33:18 +0100 Guilherme Lino wrote: > latex is cool, vim, dwm, but no one out of the professional > field of computer sience have the time or patience to learn this unix > philosophy.. are you trolling or what? "nobody will ever need more then 64k of memory".. now "no professional computer scientist knows the unix philosophy" ?
Re: [dev] Linux sucks!
that guy is wrong in so many ways I won't even bother to mention any specifics. Sure, the stuff he mentions is somewhat correlated to the real problems with "spare time open source software", but his interpretations and "solutions", oh my. He doesn't really know what he's talking about. Dieter
Re: [dev] Formatting emails
On Mon, 3 Oct 2011 15:37:15 + Bjartur Thorlacius wrote: > On Sun, Oct 2, 2011 at 9:52 PM, Ethan Grammatikidis > wrote: > > On another note entirely, would you mind not wraping your text so > > wide, please? My eyes aren't too good so I use larger text, and > > anything wrapped over about 75-80 columns double-wraps which is > > unpleasant to read. It's not just you, there's quite a few people > > wrapping their emails too wide. > > > fmt(1) > > Can we unify our evangelist forces and standardize on a message > format? What about RFC 2646: text/plain; format=flowed? > Embedding any more formatting characters in emails than strictly > necessary sucks, and autogenerated HTML sucks hard. > +1
Re: [dev] Re: suckless.org freeze
On Thu, 29 Sep 2011 08:05:00 +0200 Anselm R Garbe wrote: > Hi there, > > suckless.org is back online now. > > Best regards, > Anselm hooray, thanks Anselm. Dieter
Re: [dev] A dmenu that includes all additional features
On Mon, 12 Sep 2011 16:34:04 +0200 sta...@cs.tu-berlin.de wrote: > * Connor Lane Smith [2011-09-12 15:52]: > > How do people feel about tok in mainline? Might be worth discussing. > > token matching? almost meaningless for program names. very helpful for > natural language, structured entries (directory tree, URIs). So: I love it. The longer the input strings, the more efficient and convenient token matching becomes, and the more cumbersome the normal matching becomes. like Stanio said, long things like paths, uri's, artist-songname things, etc benefit greatly from token matching. Dieter
Re: [dev] A dmenu that includes all additional features
On Mon, 12 Sep 2011 10:51:48 +0100
Connor Lane Smith wrote:
> On 12 September 2011 10:20, Dieter Plaetinck
> wrote:
> > Thank you for that bloat patch!
> > I didn't realise it could be this simple.
>
> dmenu is very easy to hack. ;)
>
> > I did see a bug:
> > when using token matching, it seems dmenu will always do stable
> > sort, even when -s is not given.
>
> Yeah, that's true. I think 'unstable' token matching would be quite
> slow (comparative to the rest of dmenu), and involve a lot of code
> ("). Maybe if someone's interested they can give it a shot.
>
> > May I suggest you add these patches to
> > http://tools.suckless.org/dmenu/patches? If you want, I could
> > improve your patch by also updating the man page.
>
> I've stolen the tokenise manpage from the 4.2.1 patch and pushed it.
> You can choose what to do with the other patch -- I'm not sure what
> I'd name it, anyway. :p
pushed where?
I wonder if we could restructure the code a bit in such a way, that all patches
can be independent again and user can combine the patches they want without
hitting conflicts. I mean, personally I have what I want now, but for others
that seems more useful.
Maybe already renaming the match() to matchstr() function in dmenu would be a
start. but then there is the command argument parsing where each patch adds an
entry right below each other, this also commonly gives conflicts. And the
usage function, where all changes are on the same line.
But I guess if the conflicts are this trivial, it might be easier for users to
just resolve them by hand each time.
Dieter
Re: [dev] A dmenu that includes all additional features
On Sun, 11 Sep 2011 22:49:38 +0100 Connor Lane Smith wrote: > Attached are two diffs, my token patch updated to 4.4, and a bloat > patch ;) which provides everything you wanted. > > cls Thank you for that bloat patch! I didn't realise it could be this simple. I did see a bug: when using token matching, it seems dmenu will always do stable sort, even when -s is not given. May I suggest you add these patches to http://tools.suckless.org/dmenu/patches? If you want, I could improve your patch by also updating the man page. Dieter
Re: [dev] A dmenu that includes all additional features
On Thu, 8 Sep 2011 15:09:45 -0400 Peter John Hartman wrote: > I'm a lazy list reader, but aren't all of those already in dmenu > tip? Can't you list the features that *aren't* in "dmenu as we know > it"? not included: * multi select, but the argument of Hiro (that this is not really needed) makes sense, so you can ignore this one. * stable sort. @CLS why I want this: say, for an application launcher, if I provide input to dmenu ordered by frequency, that means commands at the top are more important then those that come after. (where important means: is more likely to be the option the user is looking for) When using the dmenu-based application launcher, I will use whatever string that comes up in my mind that matches the command (somewhere), and type that into dmenu. it sometimes happens the string I input happens to be at the beginning of a command I never use, and dmenu will consider that a better match and put it at the top, which is inconvenient. * pasting from clipboard. * token matching On Fri, 9 Sep 2011 10:21:24 +0100 Connor Lane Smith wrote: > 1. "XMMS-style" token matching > 2. "Stable sort" > 3. Multi-select > > 1 and 3 are both available as patches [1][2]. 2 strikes me as > pointless. I'm not sure where we're going with this. Are you using a > really old version of dmenu? > > [1]: > http://tools.suckless.org/dmenu/patches/xmms-like_pattern_matching > [2]: http://tools.suckless.org/dmenu/patches/multiselect_and_newline The patches you link to are written for old dmenu versions. Like I said, there currently is no single version of dmenu that supports all these things at once, that's my problem. I want one version that supports all of the options (minus multi-select, Hiro is right it's not needed) On Fri, 9 Sep 2011 00:47:54 +0200 hiro <23h...@googlemail.com> wrote: > what the fuck is multi select, token matching and best match? > multi select => allow outputing multiple choices from the menu before exiting. token matching => matches all tokens separately, i.e. "aw bar" will match "this bar is awesome" best match => this is default dmenu behavior. if you run this: echo -e 'ab\nb\na' | dmenu, and type 'b', then it will first show option 'b' and then 'ab', even though 'ab' was first in the input and also matches the given input. this can be useful in some cases, but in others it gets in the way (like the application launcher example I gave above). Dieter
[dev] A dmenu that includes all additional features
Hi, in an attempt to get a dmenu that includes all features I want, I've been trying to combine patches from various sources to various versions of dmenu. This has proven to be a pain, as patches conflict with each other (or sometimes apply, but still break functionality) and/or loose compatibility with newer upstream releases. Interestingly, all of the features I want actually already have corresponding patches, it's just integrating everything that's so hard. Myself, I'm a bad C coder so I hope there are some dmenu hackers out there that share the same goal and can help out. Here's my list of features: * horizontal mode (i.e. dmenu as we know it) * vertical mode, with flag for how many lines long the menu can be * string matching (dmenu as we know it) and token matching (aka xmms-like and awesomebar-like) * toggle flag for stable sort: (should work with all matching modes) * stable: order matched results like they are ordered in the input * unstable: order by "best match" (match at beginning is better than in the middle) * case sensitivity toggle * custom colors * cursor and "unix shortcuts" (ctrl-e, ctrl-a, ctrl-w, ..) * traversing results list (going up and down) with arrow up/down and alt+j and alt+k * multi select * unicode support * paste support (from either primary selection with shift-insert and clipboard, maybe with ctrl-V) Dieter
Re: [dev] ideas on suckless file manager
On Tue, 7 Jun 2011 10:53:03 -0400 Le Tian wrote: > Continuing these threads about suckless "anything" > I've been looking quite a long time for fast and lightweight file > manager for dwm. There are occasions, when u need to see or show some > lovely icons. MC and derivatives are the last resort here. I liked > pcmanfm, but it just lacks functionality. Rox-filer is nice, but then > again I needed something else. Recently I've installed Xfe, and it > looks like I'm pretty happy with it. > Xfe has decent configuration options and decent look. So I wonder, is > there any chance that we shall see a suckless file manager in the > future? Does anybody plan or think about developing it? > (Just a thought) ranger is quite okay. http://ranger.nongnu.org/ though it's limited by the typical shell/terminal limitations we've talked about earlier (i.e. previewing images is done with an external tool, which uses inefficient conversion to vague escape-character-based terminal sequences) Dieter
Re: [dev] Suckless Smartphone?
I agree with that. phone screens are the least sucky to read ebooks on. Dieter On Mon, 06 Jun 2011 19:34:20 +0200 pancake wrote: > I do, but only in phone, laptop/desktop/ebook screens sucks for > reading. > > On 06/06/11 19:24, Guilherme Lino wrote: > > electronic books suck because you dont actually read them > > > > -- > > Guilherme Lino > > > > > > On Mon, Jun 6, 2011 at 5:45 PM, Dieter Plaetinck > > mailto:die...@plaetinck.be>> wrote: > > > > non-electronic books suck because you can't easily search in, or > > copypaste from them. > > > >
Re: [dev] Best way to serialize data
On Mon, 06 Jun 2011 19:19:56 +0200 Džen wrote: > I was wondering about which way would be the easiest/simplest to > serialize data, f.e. being read via a file or stdin (data being a > table of x rows and y columns, each cell a string). I thought of > using NULL bytes as cell delimiters and newline characters as row > delimiters. This way it wouldn't be possible to use \0 nor \n > inside the "cells", but I couldn't think of a simpler solution. > > Something like: > a \0 b \0 c \n > d \0 e \0 f \n > ... > > What would you recommend? How'd you do it? > > Reason why I'm asking is because I was wondering how a dmenu-alike > utility would read data, where each items has multiple values, not > just one. Kinda like a search utility for table-structured data. > the alternative is using implicit boundaries (i.e. hardcoding field lengths). you gain simplicity for the expense of space consumption. you could look how databases like mysql, berkelydb or sqlite store their tables on disk. these things are quite well thought-through. Dieter
Re: [dev] Suckless Smartphone?
that's only because i have no ebook reader yet. because they all suck. On Mon, 6 Jun 2011 18:24:16 +0100 Guilherme Lino wrote: > electronic books suck because you dont actually read them > > -- > Guilherme Lino > > > On Mon, Jun 6, 2011 at 5:45 PM, Dieter Plaetinck > wrote: > > > non-electronic books suck because you can't easily search in, or > > copypaste from them. > > > >
Re: [dev] Suckless Smartphone?
non-electronic books suck because you can't easily search in, or copypaste from them. maybe you need a tablet or one of those ebook readers. Dieter On Mon, 6 Jun 2011 17:42:29 +0100 Guilherme Lino wrote: > a book about plan9? > > -- > Guilherme Lino > > > On Mon, Jun 6, 2011 at 5:23 PM, Andrew Hills > wrote: > > > On Mon, Jun 6, 2011 at 12:20 PM, Guilherme Lino > > wrote: > > > whene you dont have your pc, read a book.. i think thats the most > > suckless > > > way > > > > No, not really... > > > > --Andrew Hills > > > >
Re: [dev] Sandy editor
On Fri, 27 May 2011 10:29:17 +0200 Aurélien Aptel wrote: > On Fri, May 27, 2011 at 4:52 AM, John Matthewman > wrote: > > Yea, probably a good idea (of course, ignoring Emacs' chained > > keybindings). Sandy would benefit from a better set of default > > bindings. Though for reference you might want to look at something > > like mg [http://www.openbsd.org/cgi-bin/man.cgi?query=mg], or one of > > the other micro Emacs implementations, as they'll have the most > > important bindings and commands, and you won't have to sift through > > all of the extra garbage that is Emacs. > > *Please*, use sane keybindings. Emacs and vi were made with a specific > keyboard from the 70s in mind. A time were the hjkl keys had little > arrows on them. A triangle layout (wqsd or ijkl for example) is much > easier to type. > > Highly recommended readings from the (in?)famous Xah Lee: > http://xahlee.org/emacs/keyboard_hardware_and_key_choices.html > http://xahlee.org/kbd/vi_emacs_keybinding_design.html > http://xahlee.org/comp/keyboard_shortcut_design.html > > Keyboard related (prepare for some time warp if you start reading): > http://xahlee.org/Periodic_dosage_dir/keyboarding.html > how ironic you pledge for "sane" keybindings and suggest bindings optimized for qwerty users... I use dvorak, so I would prefer bindings optimized for that, but I realise different people use different layouts, so everyone should be able to choose how they like it. Dieter
Re: [dev] TermKit
On Fri, 20 May 2011 15:19:00 +0100 Connor Lane Smith wrote: > On 20 May 2011 14:54, Kurt H Maier wrote: > > I don't understand why. If you want stderr to be combined into > > stdout, suffix 2>&1 to your command. By default, I think different > > filehandles should land in different outputs. > > I just think the stdout and stderr ought to be visible at the same > time. Or perhaps it would suffice to show stderr above stdout, or > automatically switch, or something. this could be configurable by the user. or at least changeable at runtime.
Re: [dev] TermKit
On Fri, 20 May 2011 14:40:39 +0100 Connor Lane Smith wrote: > On 20 May 2011 14:27, Dieter Plaetinck wrote: > > I think a fd to write something to like "here's an image, please > > render it somewhere" is better than cls's suggestion of having apps > > directly write to the terminal. I think the latter idea would get > > messy quickly. It's as if X windows would draw themself to the > > screen rather then having a window manager take care of it. > > I disagree. Your approach is as if X windows would have no control > over their interface besides "draw me now!" My approach would probably > involve Xembed: the program creates a new window, the terminal embeds > it into the right place, and then the program can draw to this (like > how tabbed works, only downward-scrolling). Each process can ask for a > little space in the canvas and they can draw only within that. I think I misunderstood your previous mail. If you mean that the terminal/shell is the one who can say "this region is where you can draw your image", and the app can draw the image, that's fine for me. Maybe that's even better (less complicated) than the app passing an image to the shell/terminal and asking to draw it. This is in fact mandatory for apps who want to draw nice graphs/graphics/interfaces, the terminal isn't even able to do that anyway. I thought earlier you meant that the apps should decide also _where_ (as in: position on screen / inside terminal window) they write output to.
Re: [dev] TermKit
On Fri, 20 May 2011 12:51:35 +0100
David Tweed wrote:
> it always depresses me that it's
> kind of taken as a virtue that the interactive shell and the terminal
> are know almost nothing about each other (at least for almost all
> modern computing devices, I can see if you genuinely are using a
> 1970's dumb terminal you don't have the wiggle room for more). At the
> very least, it would be very productive to
I fully agree, David.
> 1. Have a terminal/shell combination that, upon resizing, actually
> redisplays text properly rather than just chops off stuff in
> vanished/newly visible space.
>
> 2. Had the _option_ for shell history to pop up in another window,
> rather than _only_ being available as a command output, so that it
> scrolls other stuff you've been doing off the screen.
>
> 3. Had more flexible context-sensitive cutting support. (Eg, let me
> somehow copy a sequence of commands text without including either the
> prompt or command output.)
If you do something like showing a time display for each prompt, but on
the right of the screen, this causes:
*) a bunch of needless space characters, as the terminal has no better
way to "push something to the right"
*) when you copypaste, you copy paste all empty spaces and the time
display. the timestamps should be optional, the space characters
should not be in there at all.
So 4) datetime info (and last exit code, etc) could all be made
available as data by the shell, but how and when to render it should be
up to the terminal.
>
> Obviously it's not clear what the best way to provide greater
> information flow between interactive shells and terminals, and it
> may/may not be that the Plan9 or emacs-shell approach is the way to
> go, but it'd be nice if there was some increase in terminal
> productivity in the coming years. (Of course, the other problem is
> it's a large number of shells and terminals to change
we could just write a new terminal-shell system that fixes all this,
that doesn't mean we need to fix all other shells and terminals out
there.
> and if
> additional "metadata" needs adding to commands that's a huge number of
> programs to change, so it's unlikely to happen...)
we could start with a few proof of concept apps. but this could be a
next step. I think modifying applications mostly to those programs
that want to draw images or use ncurses. We could scratch quite
some itches mentioned in this thread by only creating a new
shell/terminal system, without touching the actual apps.
Here are some more wishes / ideas:
5)I often want to treat output of a previous command as menu, to pick
something and use it in the command string of the next command.
and I do not necessarily know in advance I will do this.
For example:
Suppose I sometimes see a FooError and suspect one of my scripts is the
culprit.
I then do something like: grep -Rn FooError ~/scripts/
If this output tells me that indeed I have a script emitting a
FooError, and I want to edit that script at the location (line number)
grep reported, then I want to be able to type 'vim ' and then to get a
dmenu-like menu using the output of grep. In this case feeding the
literal output to dmenu would be fine, in other cases there could be
other output that should get stripped first.
When I picked the entry, it should add the right arguments for vim
('+ ')
In some cases grep might return nothing [useful], so I don't want to be
forced to see the menu if I don't want it (which means something like
'vim $(grep -Rn FooError ~/scripts | dmenu | sed/awk/blah)' is not an
option. And there's no reason to be restricted to only pick from the
last command. at some point I might want to get a menu listing output
from N commands earlier. Or I want to pick multiple entries from one
menu.
I don't think we need to modify applications like grep for this. Their
output can be parsed in a fairly straightforward and consistent way.
We do need a better shell/terminal system though.
6)non sucky rendering. I think applications should be able to have
pixel-precise control of what the output should be (other than maybe a
terminal-imposed resize factor, and also not _where_ it should be), to
i.e. render images in the terminal.
I think a fd to write something to like "here's an image, please
render it somewhere" is better than cls's suggestion of having apps
directly write to the terminal. I think the latter idea would get
messy quickly. It's as if X windows would draw themself to the screen
rather then having a window manager take care of it.
Dieter
Re: [dev] [dmenu] tip
On Sun, 15 May 2011 22:46:17 +0100 Connor Lane Smith wrote: > Hey all, > > I've been tinkering with dmenu the last few days. I think it would be > good to get a 4.3 release out at some point soon, so if anyone could > report any bugs to me that would be swell. > A brief list of changes: > > In terms of SLOC, tip is about the size of 4.0 and most of the 3.x > series, with a current count of 683 lines of C and 7 of shell script. > (Which is quite small, considering it now has a cursor, vertical > lines, and paste.) > > It ought to be a lot faster. The main data structure now uses an > array, and I've optimised incremental search, so the longer you type > the quicker matching will become; and jumping to the last menu item is > now O(1). It only starts to get noticeably sluggish on an Atom netbook > when dealing with half a million items or so. > > dmenu_path is a shell script again. Based on my tests it's slightly > slower than the C version, but is still a lot faster than the original > script, so I think that's acceptable -- I don't notice a cache miss, > with a few thousand executables. (Use '-f' or a watcher process and > you're golden.) > > For portability, dmenu is now ANSI C90, which more compilers support > than C99, and dmenu_path is POSIX compliant, whereas the old script > wasn't. I also checked the Makefile is POSIX compliant and works with > BSD make. ;) > > Any bugs, tell me! > > Thanks, > cls > Sounds good! Dieter
Re: [dev] [dmenu] Patch for XDG Base Directory specification of dmenu_path
On Fri, 7 Jan 2011 19:01:24 + Connor Lane Smith wrote: > dmenu tip now has an option in config.mk allowing you to specify the > path of dmenu_path's cache, either absolute or relative to $HOME. It > doesn't let you do anything involving environment variables, as true > XDG would require, but you can at least make it dump the cache in a > directory of your choosing. > > (Right now it doesn't actually mkdir -- is that desired?) > > Thanks, > cls > yeah, if dir doesn't exist, try to create it. Dieter
Re: [dev] [hack] Having dmenu provide hints about current selected entry
On Fri, 26 Nov 2010 16:33:51 +0100 Christophe-Marie Duquesne wrote: > On Fri, Nov 26, 2010 at 3:04 PM, Dieter Plaetinck > wrote: > > the delay caused by dmenu waiting for stdin input to be complete > > is noticeable. > > Actually, while performance also matters, the thread thing is not > primarily a matter of fast processing. It is just that if you wait for > the input to finish before allowing the user to interact, you miss the > point of allowing feeding additional entries to this input from the > suggestions (since these suggestions can only happen once user can > interact). Yes, I just wanted to explain my use case, which is different then yours. Anselm questioned earlier whether the writer (dmenu_path and whatnot) or the reader (dmenu) is the slow one, as far as i've seen it's always the writer. But that doesn't change my point at all. I just want to be able to start typing asap, the input writer is usually fast enough to catch up before I'm done typing anyway. But I don't like to needlessly wait before dmenu appears. Again, this is the concern in my use case, which is different then yours. Dieter
Re: [dev] [hack] Having dmenu provide hints about current selected entry
On Fri, 26 Nov 2010 14:38:10 +0100 Christophe-Marie Duquesne wrote: > Hi there, > > I wanted a menu that would allow me to select entries both from the > uzbl history and from google suggest 'as you type' (like in firefox). > While dmenu allows selecting entries in a static list (like uzbl > history) easily, modifying this list and providing hints to google > suggest did not seem to be possible. Since I did not see any other way > to do that, I wrote a patch to dmenu. It adds 2 features: > > 1) if invoked with the option -s (-s for stream) dmenu will output > selected entry on every keystroke (so you can feed a tool with the > current entry). > 2) in order to avoid waiting for the input stream to finish before > allowing the user for select entries (and so that you can continue > feeding it from stdin while you type), dmenu reads stdin in a thread. > > The idea is to feed dmenu with hints deduced from its stdout. As an > example, here is how this can be used: > > #!/bin/bash > > socat UNIX-LISTEN:/tmp/dmenu_suggest - | dmenu -s | tee /tmp/results > | \ while read line; do echo $line | ./google_suggest; done | \ > socat - UNIX-CONNECT:/tmp/dmenu_suggest > > tail -n1 /tmp/results && rm /tmp/results > > google_suggest is a python script I wrote. It reads search terms from > stdin and outputs suggestions from google suggest API (I have attached > it). > > If you are interested, you can pull my dmenu patch from > https://bitbucket.org/chmduquesne/dmenu. Although the script above > works correctly on my machine, the patch breaks dmenu in other > situations. I would be interested if the persons who find this idea > interesting would be kind enough to provide some constructive advices > about the way to do that, e.g. if you see any cleaner method or if you > have suggestions for doing that in a better way without patching > dmenu. Advices like "don't do that" or "stop rewriting firefox" will > probably not help. Cool. I've been pondering this feature before. Because if feeding dmenu stdin is time-consuming (i have some sorts and whatnot when reading my "most often invoked entries") the delay caused by dmenu waiting for stdin input to be complete is noticeable. I would prefer if it works like this: - when you invoke dmenu, it immediately appears, and user can start typing input. as soon as dmenu is started, it starts reading stdin, however fast or slow it goes until EOF. - anytime anything happens (user changes his query or new line is read on stdin) the search results are updated in realtime accordingly. I think the code/algorithms to realize this must be pretty complicated for it to work nicely (high performance).. But your patches seem trivial, so did I miss something? Also, what do you do if the user types something, you feed google suggest results to stdin, and then the user erases the line and types something completely different? the old suggestions are still in dmenu's datastructure so they can still appear in the search result? And how exactly do you make sure the suggestions are shown for the corresponding query? I would expect you would prefix the suggestions with the query, but don't see anything like that in your python code. Dieter
Re: [dev] Re: [dmenu] [patch] add xft and fix possible memory leak in version 4.2.1
On Mon, 22 Nov 2010 14:26:56 + Connor Lane Smith wrote: > On 22 November 2010 12:01, Anselm R Garbe wrote: > > I prefer to keep cleanup() even if it slows down the performance > > (which I doubt will be noticeable) just for the sake of keeping the > > symmetry that the code that allocates resources also deallocates > > them. This might sound a bit pedantic and useless in case of dmenu, > > but I prefer to be consistent here. > > I think that pedantic and useless code for the sake of consistency is > more at home in GNU software than in Suckless. If code is provably a > waste of time and space it should have no place in dmenu. If memory > was allocated during use I would agree with you, as a leak would be > possible. But it isn't. > > Besides, asymmetry is beautiful. > > cls > I agree with cls on this one. Keep the code simple. Dieter
Re: [dev] git dmenu mirror with feature branches instead of separate patches
On Sun, 21 Nov 2010 19:56:07 + Connor Lane Smith wrote: > On 21 November 2010 19:33, wrote: > > Another kinda heretic idea might be to have fairly feature-rich > > branches and feature-removing patches. Just thinking loud > > Trunk, a branch per patch, a spicy branch, and a plain branch? (Names > pending.) > > Trunk would be mainline dmenu, a stable version to be packaged. The > spicy would have every patch merged, I guess for people who just can't > be bothered to mess around merging patches. And the plain would have > only the essence of what makes dmenu dmenu, for people who want the > simplest and smallest version. Read: no flags, no Xinerama. > > I'm thinking out loud too. :p > > cls > I think we should just try it. We can easily create new branches to create new versions, and we'll see soon what works and what doesn't. With the right choice of branches we can come up with a situation that is relatively easy to maintain, yet flexible and robust enough. Dieter
Re: [dev] git dmenu mirror with feature branches instead of separate patches
On Sun, 21 Nov 2010 16:30:55 +0100 v4hn wrote: > On Sun, Nov 21, 2010 at 04:14:26PM +0100, sta...@cs.tu-berlin.de > wrote: > > Often, issues arise when applying multiple patches. The prposal > > doesn't solve this, does it? For single features -- sure, it's > > beneficial, but the work to keep stuff up to date with master > > remains. > > Yes, there are problems with multiple patches. In my opinion > we should spend some more time on making the optional patches as > compatible as possible. - I did that with a couple of dwm-patches > some time ago. Right, there can still be merge conflicts when merging multiple patches, but git (not sure about hg) is pretty smart about it, i.e. if a block to be patched moved a bit downwards, it still applies fine. So conflicts are less frequent, whereas normal patches break completely as soon as a slight detail has changed. Also, conflicts are easier to solve (or maybe i just don't have the right tools to work with .rej files) And, agreed with v4hn. Patches should be made "compatible" (but that's not really related to the patchfiles vcs feature branches topic) > > > Set of branches based on multiple patches, representing different > > dmenu flavours -- like surf-flavour (e.g. vertical and token match > > and xyz ), dwm-flavour, someones-music-player-flavour -- might make > > more sense... not sure. > > That's another option, but keeping track of applied patches on each > branch will become a pile of work imho, so this again would result in > making the patches compatible. Actually that's a step I had in mind also. If we start off with normal feature branches (i.e. master + 1 feature), you can get "multiple-feature" branches by merging some feature branches together. I could imagine in some cases features are so connected to each other it makes more sense to maintain them together rather then trying to separate them. I would say we would make branches for single/multiple features based on what makes most sense for each particular case. Dieter
[dev] git dmenu mirror with feature branches instead of separate patches
Hi, I'm not sure if this is a good idea or not, but at least it's an interesting experiment. For the following reasons... - It's easier to maintain and update separate versions/features using vcs branches rather then separate patch files. (unless all the patches posted are generated by vcs systems, but in that case we should at least publish the corresponding branches) - by merging branches you can more easily mix featuresets - tested and committed source feels more safe and robust then patches which may not always apply or function as expected - I personally like git and am not interested in learning hg ...I made a git-based dmenu mirror @ https://github.com/Dieterbe/dmenu The master branch contains an exact copy of the official hg repository (using the hg-git bridge) separate branches are made for the separate patches. I'm not sure if other folks like git, but at least the idea of maintaining alternate versions through vcs branches seems pretty beneficial to me. Dieter
Re: [dev] Re: [dmenu] [patch] add xft and fix possible memory leak in version 4.2.1
On Sun, 21 Nov 2010 01:22:46 -0800 Dan Brown wrote: > 3) adds 2 other features that I want (but may not be generally > popular): filter mode and token matching "token matching" seems to be the same as the xmms-style matching: http://tools.suckless.org/dmenu/patches/xmms-like_pattern_matching (although that patch has no 4.2 compatible version yet) Dieter
Re: [dev] dmenu patch to return all matching items (for a new dmenu-powered music player interface)
On Thu, 11 Nov 2010 14:53:32 +0100 markus schnalke wrote: > [2010-11-11 14:36] Dieter Plaetinck > > On Thu, 11 Nov 2010 14:12:59 +0100 > > markus schnalke wrote: > > > > > Note that the user might not be able to know in which mode dmenu > > > acts at run-time. > > > > why wouldn't he? if a dmenu appears on a users' screen, it appears > > because the user configured/installed a script/keybinding/tool that > > spawns the dmenu. Isn't "know your own system" a fair assumption? > > People may have different scripts launch dmenus. One will have to give > them different colors to divide them apart. > > If dmenu would be a tool that is usually invoked directly on the > command line, then I would agree with you. Because this is not the > case I do not. > > Think about vi behaving differently whether invoked from crontab or > visudo or hg ci. I would consider this bad. > > In any way, wasn't dmenu designed to behave the same everywhere? Such > as `i' in vi should mean ``insert'' on every system. If on any system > I use dmenu pops up, I'd like to know what it does when I hit Enter. > > If in filter mode, all entries on the right side would be highlighted, > then I am pleased. The clear rule would be: Each highlighted entry > gets printed. Think this is how is should be. > > > meillo > Hmm I understand your point. I'm not sure I agree because I consider dmenu the extenstion UI of another tool/script. e.g.: dmenu_run; and I know how dmenu_run behaves (it will get 1 line). I never use dmenu as a general purpose tool on it's own, it's always part of something else, of which i know how it behaves. However, your color suggestion is not bad. Users who want a visual differentiator can call dmenu with a different color setting for filter mode. Dieter
Re: [dev] dmenu patch to return all matching items (for a new dmenu-powered music player interface)
On Thu, 11 Nov 2010 14:12:59 +0100 markus schnalke wrote: > Note that the user might not be able to know in which mode dmenu acts > at run-time. why wouldn't he? if a dmenu appears on a users' screen, it appears because the user configured/installed a script/keybinding/tool that spawns the dmenu. Isn't "know your own system" a fair assumption? Dieter
Re: [dev] dmenu patch to return all matching items (for a new dmenu-powered music player interface)
On Thu, 11 Nov 2010 12:36:23 +0100 sta...@cs.tu-berlin.de wrote: > * Anselm R Garbe [2010-11-11 12:19]: > > On 11 November 2010 06:25, Dan Brown wrote: > > > As part of a project to create a simple and fast music player > > > interface, I patched dmenu to allow it to return all matching > > > items instead of just the one at the cursor. dmenu is the browsing > > > > This patch looks kinda useful to me and I'll think about probably > > supporting this in mainstream dmenu. > > +1 > > Can be very useful bound to some modkey + enter > you mean you want to choose between "return current result" vs "return all current matches" at run-time? What's a use case for that? I think this should be configured with a commandline argument, because the script that calls dmenu needs to know in advance what kind of output it will get anyway and it depends on what task the script will do. Or am I missing something? Dieter
Re: [dev] dmenu patch to return all matching items (for a new dmenu-powered music player interface)
On Wed, 10 Nov 2010 21:25:09 -0800
Dan Brown wrote:
> Hello and thanks everyone.
>
> As part of a project to create a simple and fast music player
> interface, I patched dmenu to allow it to return all matching items
> instead of just the one at the cursor. dmenu is the browsing
> interface; and there is another mode of operation that takes keywords
> as hints for a partial match on filenames. The items then get loaded
> into a mpc/mpd playlist with a shell script. See
> http://github.com/dbro/muss for that code.
>
> Why is this patch of interest? I call it "filtermode" because it uses
> dmenu to generate a list of matches, with interactivity similar to the
> trendy "instant" style of searching. For applications working with
> sets of items, this method could be faster than the existing
> dmenu-multiselect patch, in that it doesn't require the user to
> manually select each item they want. The basis for the patch is dmenu
> v4.1.1 .
>
> Suggestions, comments welcome.
> Dan
>
> --
>
> --- dmenu.c 2010-11-09 11:58:12.0 -0800
> +++ dmenu.c 2010-11-09 13:10:54.0 -0800
> @@ -98,6 +98,7 @@
> static unsigned int numlockmask = 0;
> static Bool running = True;
> static Bool xmms = False;
> +static Bool filtermode = False;
> static Display *dpy;
> static DC dc;
> static Item *allitems = NULL; /* first of all items */
> @@ -620,6 +621,12 @@
> case XK_Return:
> if((e->state & ShiftMask) || !sel)
> fprintf(stdout, "%s", text);
> + else if(filtermode) {
> +for(Item *i=sel; i; i=i->right)
> + fprintf(stdout, "%s\n", i->text);
> +for(Item *i=item; i&&(i!=sel); i=i->right)
> + fprintf(stdout, "%s\n", i->text);
> +}
> else
> fprintf(stdout, "%s", sel->text);
> fflush(stdout);
> @@ -939,10 +946,12 @@
> }
> else if(!strcmp(argv[i], "-xs"))
> xmms = True;
> + else if(!strcmp(argv[i], "-f"))
> + filtermode = True;
> else if(!strcmp(argv[i], "-v"))
> eprint("dmenu-"VERSION", © 2006-2010 dmenu
> engineers, see LICENSE for details\n");
> else
> - eprint("usage: dmenu [-i] [-b] [-e ]
> [-l ] [-fn ] [-fa ] [-nb ]\n"
> + eprint("usage: dmenu [-i] [-b] [-e ]
> [-f] [-l ] [-fn ] [-fa ] [-nb ]\n"
> " [-nf ] [-p
> ] [-sb ] [-sf ] [-xs] [-v]\n");
> if(!setlocale(LC_CTYPE, "") || !XSupportsLocale())
> fprintf(stderr, "warning: no locale support\n");
> --- dmenu.1 2010-11-09 08:11:29.0 -0800
> +++ dmenu.1 2010-11-09 13:14:06.0 -0800
> @@ -6,6 +6,7 @@
> .RB [ \-i ]
> .RB [ \-b ]
> .RB [ \-l " "]
> +.RB [ \-f ]
> .RB [ \-fn " "]
> .RB [ \-nb " "]
> .RB [ \-nf " "]
> @@ -32,6 +33,10 @@
> activates vertical list mode.
> The given number of lines will be displayed. Window height will get
> adjusted. .TP
> +.B \-f
> +activates filter mode.
> +All matching items currently shown in the list will be selected,
> starting with the item that is highlighted and wrapping around to the
> beginning of the list.
> +.TP
> .B \-fn
> defines the font.
> .TP
>
Cool. it's a bit like interactive grep :)
Dieter
Re: [dev] flo - a command line program for organizing events, to-dos, and deadlines
On Wed, 18 Aug 2010 01:27:22 +0200 Alexander Teinum wrote: > How many of these small tools are there? moreutils rock. they really fill some gaps. niche, but still. Dieter
Re: [dev] [patch] xmms like pattern matching for dmenu (update to hg tip)
On Tue, 10 Aug 2010 03:20:57 +0200 Arian Kuschki wrote: > 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? You just nailed it imho. Dieter
Re: [dev] [patch] xmms like pattern matching for dmenu (update to hg tip)
On Sat, 7 Aug 2010 22:27:31 +0100 StephenB wrote: > On 7 August 2010 20:36, Robert Ransom wrote: > > > On Sat, 7 Aug 2010 17:23:13 +0100 > > StephenB wrote: > > > > > Just to make clear, this patch is an updated version of the one > > > here: > > > http://tools.suckless.org/dmenu/patches/xmms-like_pattern_matching > > > > http://suckless.org/wiki/ > > > > > > Robert Ransom > > > > Thanks, I've added my patch to the wiki and updated the page. > > StephenB this pattern matching style is pretty cool. Is there no interest in merging this in the mainline? Dieter
Re: [dev] Suckless operating system
On Tue, 15 Jun 2010 10:18:20 -0400 Kris Maglione wrote: > On Tue, Jun 15, 2010 at 04:05:24PM +0200, Dieter Plaetinck wrote: > >On Tue, 15 Jun 2010 08:43:31 -0400 > >Kurt H Maier wrote: > >> This is what makes the suckless list better. Otherwise you wind up > >> with shit like http://www.archhurd.org/ > >> > > > >What's wrong with arch hurd? > > The HURD part, obviously. > hmm. i'm not too familiar with hurd, but afaik it's supposed to be simpler and more elegant then Linux Dieter
Re: [dev] Suckless operating system
On Tue, 15 Jun 2010 08:43:31 -0400 Kurt H Maier wrote: > This is what makes the suckless list better. Otherwise you wind up > with shit like http://www.archhurd.org/ > What's wrong with arch hurd? Dieter
Re: [dev] Re: XDG directories
On Fri, 11 Jun 2010 16:09:55 +0200 David Engster wrote: > Dieter Plaetinck writes: > > yes, both the app data and user data (can) end(s) up in > > $XDG_DATA_HOME > > I see that in my .local/share as well. It's a complete mess. > > So what they tried to do is to separate configuration settings from > user data. But then they took a quick look at other systems (like OS > X) and wanted the possibility to override/add application data (like > fonts) in a local share hierarchy. I guess they also wanted you to be > able to install software locally by using '--datadir=~/.local/share > --sysconfdir=~/.config'. Now you got somehow everything, and every > application will just do what it deems right, or only implements a > subset of the spec, so that when you really want to profit from such a > complicated setup, it probably won't work anyway. hmm. with application data i meant data generated by the application, which is somehow related to the user and how the user uses the application. i haven't seen data which would usually be in /usr/local (like binary executables) in ~/.local/, probably because i never installed anything in there? > > personally I don't mind the mixed nature of data in $XDG_DATA_HOME > > and as long as apps don't automatically update manually written > > files, it's all good for me. > > The problem is that data is even more spread than it was before, and > often cannot be tracked anymore to the application which generated > it. So if you're worried about applications littering your $HOME with > dotfiles, you now have a littered .local/share and often do not even > know if you can delete that stuff. > > -David > I don't find my ~/.local/share problematic. there are only a handful subdirs which are not app-specific (mime, desktop-directories, applications, Trash, icons) and it's not a big mystery where they come from. Dieter
Re: [dev] Re: XDG directories
On Fri, 11 Jun 2010 09:29:41 -0400
Kris Maglione wrote:
> On Fri, Jun 11, 2010 at 03:17:18PM +0200, David Engster wrote:
> >David Engster writes:
> >> I'm trying to understand which problem exactly is solved by this. I
> >> tried to read the "XDG Base Directory Specification" [1] but I
> >> admit I didn't get past "Basics". How is fiddling with
> >> XDG_DATA_HOME, XDG_CONFIG_HOME, XDG_DATA_DIRS, XDG_CONFIG_DIRS and
> >> XDG_CACHE_HOME better than a dotfile or dot-directory in your
> >> $HOME?
> >
> >OK, I've tried the next section.
> >
> >Can someone explain to me what XDG_DATA_HOME really is for? I know
> >what the spec says ("directory relative to which user specific data
> >files should be stored"), but then it doesn't make sense to me that
> >its default is '~/.local/share'. Since XDG_DATA_DIRS default is
> >'/usr/share:/usr/local/share', and data in XDG_DATA_HOME overrides
> >those, it seems they want to mimic the share hierarchy locally? They
> >somehow want to separate configuration from user data, but then they
> >mix user data with application data? I don't get it.
>
> Like I said, the spec is verging on batty as is. I still haven't
> figured that out myself, and that's after searching the
> directories on my computer and seeing what other apps've done.
> My best guess on the matter is that .config should be more for
> user-editable things, and .local/share for — other local crap, I
> guess. Current apps don't really seem to discriminate.
>
yes, both the app data and user data (can) end(s) up in $XDG_DATA_HOME
to make matters worse, many apps automatically write stuff into
$XDG_CONFIG_HOME (mostly state information like window size, last
opened files, ..), often even in the same file where the user edits his
settings. very irritating when you put that file under version control.
I've proposed them already quite a few times to at least add a
recommendation to the spec to put automatically generated data (like
application state) in a separate file, but they wouldn't listen...
personally I don't mind the mixed nature of data in $XDG_DATA_HOME and
as long as apps don't automatically update manually written files, it's
all good for me.
Dieter
Re: [dev] XDG directories
On Fri, 11 Jun 2010 10:33:51 +0100
Connor Lane Smith wrote:
> Hey,
>
> On 11 June 2010 10:19, Kris Maglione wrote:
> > While on the one hand, I think that the people who wrote the XDG
> > spec are raving mad[1], on the other, I hate applications clogging
> > up my home directory with dot-files. I'm considering moving ~/.wmii
> > to ~/.config/wmii. I'd really prefer something of a non-dot-dir
> > flavor, but since there's no such standard, there's really no
> > point. Does anyone have any arguments, or even any half decent
> > rants, either way?
>
> I completely support this (dotfiles anger me). If you move
> "$HOME/.wmii" to "${XDG_CONFIG_HOME:-$HOME/.config}/wmii", as per the
> XDG spec, then anyone can set the config dir to whatever they want
> (such as ~/lib) and be dotfile-free. The path looks pretty ugly with
> all its environs but it's the closest we have to a standard.
>
> As a sidenote I was wondering whether we should do this with
> dmenu_cache.
>
> cls
>
+1 for following the xdg basedir spec.
i recommend it to everyone. yes, also dmenu_cache could be moved to
${XDG_CACHE_HOME:-$HOME/.cache}/dmenu
Dieter
Re: [dev] dmenu_path rewrite in C
On Wed, 19 May 2010 21:01:54 +0900 Renick Bell wrote: > > Slow how? How large is this history file? > > Sorry, I am exaggerating. My patience gets ever shorter: a bit over a > second for a file for a 49,856 line file at the moment. Maybe I should > prune my history. Subjectively, I often feel annoyed by it though, so > a faster version is welcome for me. > note that this thread is about dmenu_path, not dmenu. Dieter
Re: [dev] dmenu -m "new%patch" -d "%"
On Tue, 11 May 2010 11:58:12 +0100 Martin Ellis wrote: > Hi, > > We had a strange situation where putting the menu in stdin was > difficult. > > For our situation supplying the menu on the command line would be > easier. > > Attached is a patch that provides this. > > The new syntax is > > dmenu -m "hello\nworld" > > or use the -d flag to specify the seperator > > dmenu -m "hello%world" -d "%" > > The old style still works. > > Hope this helps someone. > > Mex. maybe you should mention what problem you had where writing to stdin did not work. it's likely it can be fixed. Dieter
Re: [dev] SWK: The simple widget kit
On Mon, 10 May 2010 10:00:12 +0200 pancake wrote: > I really prefer to tap my phone than open the keyboard and type a 4 > pipe command. Which is not the same situation on desktop...where > keyboard is preferible. +1 Dieter
Re: [dev] Suckless BT client(s)?
On Tue, 4 May 2010 16:09:22 +0600 mikhail maluyk wrote: > Take a look at transmission. > i think rtorrent is "ok". lightweight, but lacks some advanced features such as webseeds. Personally i prefer support for DHT, webseeds, encryption and whatnot. i just had a look at transmission, using it with its ncurses interface seems to be pretty similar to rtorrent, except that it has more features. furthermore it * supports the xdg basedir spec (i hate things that pollute my ~) * has a socket protocol (http://trac.transmissionbt.com/browser/trunk/doc/rpc-spec.txt) but i wonder: * does it have an event reporting/hooks system? so that i can execute scripts/code when a torrent completed, stalled, is added, ... * does it automatically update its own configuration? i hate it when programs do that. Dieter
Re: [dev] [surf] What Works
On Thu, 22 Apr 2010 13:25:04 -0400 Jacob Todd wrote: > On Thu, Apr 22, 2010 at 05:47:07PM +0400, anonymous wrote: > > Do we really need that "What Works" list on > > http://surf.suckless.org/? It tells reader what sites works with > > WebKit? > > > Some sites do silly things with cookies, and they don't work, or > don't work too well with surf. I think it's somewhat usefull. > then maybe it's better to list what *doesn't* work, with a short note why. Dieter
Re: [dev] [dmenu] A clickable dmenu is a dream?
On Sun, 28 Mar 2010 20:14:56 +0100 Connor Lane Smith wrote: > I was thinking of perhaps trying a dmenu-derivative which spawns a > shell to interact with, becoming an extremely simple one-line 'dterm'. > Could be interesting, anyway. bashrun? http://bashrun.sourceforge.net/ Dieter
Re: [dev] Why use Mercurial?
On Mon, 15 Feb 2010 10:52:09 +0100 Aurélien Aptel wrote: > On Mon, Feb 15, 2010 at 10:02 AM, Kris Maglione > wrote: > > Ooh! Uriel 2.0! > > You mean, Uriel changeset 42 dead0beef15d ? > touche
Re: [dev] [SLOCK] is not safe
On Tue, 19 Jan 2010 12:11:24 +0100 Premysl Hruby wrote: > Problem here is not using exec startx or startx & exit, not using or > not using exec in xinitrc/xsession! > > -Ph say what?
Re: [dev] suckless real time file sync system (or dropbox alternative)
and what about sshfs, ftpfs, etc?
Re: [dev] suckless real time file sync system (or dropbox alternative)
> I can't see why you want this instead of a traditional > fileserver+clients, but never question a crazy idea. :) true that. so, how do dropbox-ish things work? 1) they automagically do some synchronizing when you put something in a directory 2) you [or a script] has to put something in the directory. Since you - or a script - has to do "something" anyway, why don't you just skip a step? and instead of putting something in a dir and let the magic happen, just call a script to upload/synchronize the files whereever you want, directly ?!? Dieter
Re: [dev] Less Sucking X Window System?
On Tue, 15 Dec 2009 10:54:03 +0100 Frederik Caulier wrote: > Hello dev@ > > Some of you might be interested in alternatives to the X Window > System, so I thought I'd just share [0] with you. > Although Y-Windows being currently unmaintained it might still be > worth a look. > > [0] http://www.y-windows.org/ > > Best regards, > F. Caulier > h... not entirely suckless http://www.y-windows.org/faq.html What features does Y have that X11 doesn't? The major features include: * Server-side widgets * Unicode support * True 32bit alpha-blending (allowing semi-transparent windows, drop shadows, etc.) * Hot-pluggable module system for video, input and ipc drivers (change video drivers on-the-fly, ...) there are also: http://en.wikipedia.org/wiki/Wayland_%28display_server%29 http://en.wikipedia.org/wiki/MicroXwin which may or may not be[come] less sucky then Xorg resp X11 Dieter
Re: [dev] suckless password manager
FYI recently the fd.o guys started working on a "secrets storage spec" http://www.freedesktop.org/wiki/Specifications/secret-storage-spec i find it quite interesting because they want to have a spec that multiple applications will start using. If you want to help steering them to be compatible with a "no-bloat" setup, it's still not too late. my initial thoughts: http://lists.freedesktop.org/archives/authentication/2009-July/03.html Dieter
Re: [dev] [surf] editing textboxes with external command
On Fri, 20 Nov 2009 15:51:41 +0300 Michael wrote: > On Fri, Nov 20, 2009 at 15:47, Anselm R Garbe wrote: > > Aehm I was saying vertical will become mainstream... > > Sorry, got to read more English. Happy to hear it, thanks. > I also read the original message as "will take it upstream (but not the vertical stuff)" so found it confusing. anyway, great news to see the vertical patch being included.
Re: [dev] [OT]: Go programming language
On Fri, 13 Nov 2009 06:16:00 +1100 Jessta wrote: > The thing is that human beings don't really work well with lots of > things that are very similar, we get confused. Human beings prefer > things to be similar enough that we can use our previous knowledge to > figure them out but different enough that they aren't easily confused > with other things. > > Unix's 'everything is a file' isn't really true it's more of a guiding > principle than a hard and fast rule and it's more like "everything is > a block or char device" anyway. If you try to shoe-horn everything in > to being a 'file' you end up with some very confusing and unintutitive > behaviour like the OOP crowd and their 'everything is an object'. > > Lisp has the 'everything is a list' problem and there is lots of > behaviour that doesn't fit well in to this. Consistancy can make > things intuitive, but you shouldn't sacrifice intuitiveness for > consistancy. > > - Jessta > well said. you should always keep the end goal in mind. and "stay confirm to how we've been doing it" should not be a goal. take network interfaces on Linux for example. they have no device file and it makes perfect sense. Dieter
Re: [dev] dev+unsubscr...@suckless.org
On Mon, 9 Nov 2009 19:30:54 -0500 Kris Maglione wrote: > On Mon, Nov 09, 2009 at 06:16:43PM -0600, tosh wrote: > >unsubscribe > > For fuck's sake! It's not that hard, and we've just had this > discussion. Well, I hope you can figure this one out yourself, > or I suppose you'll have to stay subscribed. > i thought it was a joke :P Dieter
Re: [dev] [surf] segmentation fault
On Sat, 31 Oct 2009 19:31:58 +0100 cryptix wrote: > Hi, > > libwebkit-1.1.15.3-1 breaks surf (and i heard uzbl, too). > try to get 1.1.15.2-1, which might be in /var/cache/pacman/pkg/ if > you haven't cleaned after the update or just installed. > > > no problem, > > C. > > On 31.10.2009, at 19:03, Lorenzo Bolla wrote: > > > Hi all, > > > > I've tried to compile the latest surf version with > > libwebkit-1.1.15.3-1 and gtk-1.2.10-9. > > Compilation went fine, but running surf from the command line gets > > me a "Segmentation fault". > > Any hints? > > I'm running Arch Linux 2.6.31-ARCH > > > > Thanks, > > L. > > blame zemberek see http://www.uzbl.org/news.php?id=17 for solution/workaround
Re: [dev] [surf] xprop (was: few bugs)
On Thu, 29 Oct 2009 20:04:57 +0100 Tadeusz Sośnierz wrote: > On 29-10-2009 19:59:17, markus schnalke wrote: > > The quoted mail makes me share my thoughts on surf's xprop > > interface: > > > > > > At first, it seems pretty nice how surf communicates with the > > outside. But on closer looks, I dislike the xprop stuff more and > > more. > > > > What is shown above does surely not look nice; it's pretty obscure > > when you compare it to most of the suckless software we know. > > > > You may say that this does not matter much, as you only once need to > > find out how it has to be done. > > > > > > But -- and this my main point -- the xprop interface is a break on > > unleashing the leverage of surf! > > > > Uzbl may not be as small as surf, it's ``command language'' on the > > interface may be a bit too big, but it does one thing right where > > surf fails: It *encourages* to combine it with other programs! > > > > > > Surf is able to interface all kinds of programs through xprop, but > > not in an easy/flexible enough way. The large number of user > > scripts that extend uzbl is not the result of the larger community, > > but the result of the interface that makes you want to write > > ``handler'' scripts. > > > > Instead of staying hooked to xprop, surf should create a fifo for > > input and write stuff to stdout in order to make it easier/more > > flexible to combine it with helper scripts. This would improve surf > > much. > > > > Here (possibly) more code leads to less complexity combined with > > more flexibility. > > > > > > It's not enough to just offer possibilities; important is to > > encourage to use them ... by design. In this point surf fails, > > whereas uzbl does it right. > > > > > > meillo > > Agreed. As now the looks like the only place in which surf uses xprop > is actually this uri and find handling. It's not really useful for > setting the address remotely, as we have better or worse patches for > bookmarks, we can open new surf instances in tabbed, etc. > Regards, > Ted > i always think of 'uzbl & surf' as 'wmii and dwm'. basically they both encourage you to write things to interact/integrate with, but wmii and uzbl recommend doing it with separate programs by providing interfaces such as fifo/socket/virtual filesystem etc. whereas dwm and surf recommend you to change the source code to provide the behaviour you want. both are fine approach, both have pros and cons and both appeal to different people. but IMHO they both provide a means to change the behavior of the program as a whole (note i haven't actually looked at surf's source code yet, but i suspect that's how it works) Dieter
Re: [dev] [surf] SIGSEGV with newest webkit on arch
On Thu, 22 Oct 2009 20:23:01 +0200 "Enno Boland (Gottox)" wrote: > hi! > > It seems this is caused by archlinux libwebkit release. Downgrade > you're webkit to an earlier release. uzbl has the same problem. For > some strange reason midori still works... > > regards what makes you think this is an archlinux problem? the pkgbuild looks very simple. no special tricks. http://repos.archlinux.org/wsvn/packages/libwebkit/repos/extra-i686/PKGBUILD
Re: [dev] [surf] next release
On Thu, 22 Oct 2009 18:15:58 +0200 Tadeusz Sośnierz wrote: > On 22-10-2009 09:09:25, Charlie Kester wrote: > > On Thu 22 Oct 2009 at 05:20:44 PDT Dieter Plaetinck wrote: > > > > > >what consitutes a "session" ? it's something that is maintained > > >serverside and the only way to "stay in it" is usually one or more > > >of: > > >- keeping and sending cookie data > > >- keeping the same ip (and maybe user agent) > > >- requesting the urls they tell you to > > > > > >afaik both curl and wget can use existing cookie storages on your > > >hard disk (and can use the useragent you tell them to), so don't > > >really see the problem. > > > > It seems to me that the problems being discussed in this subthread > > arise because the "browser" combines two very distinct concerns: > > > > - managing the http traffic to and from the website, which includes > > the administrative details pertaining to the session > > > > - rendering the documents obtained from the website > > > > Perhaps we should be thinking about separating them? > > > > Then we will end up with some shit like uzbl - the browser which > cannot browse the web. > > Regards > it can browse the web just fine, thank you very much. thanks for the kind words, but let's not go offtopic here.
Re: [dev] [surf] next release
On Thu, 22 Oct 2009 08:11:54 -0400 (EDT) Peter John Hartman wrote: > > > On Thu, 22 Oct 2009, Anselm R Garbe wrote: > > > 2009/10/21 Uriel : > >> Surf should *not* handle downloads or display source, this are > >> clearly and obviously best handled by external tools and there is > >> zero reason for them to be part of any browser. > > > > I disagree with downloads, because several stuff can't be download > > without dealing with a valid session and it is a pain to download > > stuff that requires session info using wget. > > > > I have no strong feeling about source viewing, doesn't need to be > > build-in, but since it's already implemented by webkit the source > > viewing and profiling info of WebKit might be worth being made > > accessible through surf, it'll help those who have to debug some web > > stuff from time to time or that are masochists about analysing JS > > and overall download performance similar to firebug. Usually no > > external tool can provide this information correctly. > > > > Kind regards, > > Anselm > > > > I agree with Anselm. An in-suff download solution is needed for > precisely the reason he gives. > > Peter > what consitutes a "session" ? it's something that is maintained serverside and the only way to "stay in it" is usually one or more of: - keeping and sending cookie data - keeping the same ip (and maybe user agent) - requesting the urls they tell you to afaik both curl and wget can use existing cookie storages on your hard disk (and can use the useragent you tell them to), so don't really see the problem. Dieter
Re: [dev] [surf] next release
On Wed, 21 Oct 2009 11:04:48 -0400 (EDT) Peter John Hartman wrote: > > > On Wed, 21 Oct 2009, Anselm R Garbe wrote: > > > 2009/10/21 pancake : > >> I always use shift+insert or middleclick for pasting, what's the > >> unix way to paste? > >> ^p is already supported in surf, and mozilla load pages if you > >> paste them in the > >> web canvas...so which is the 'correct' one? :) > >> > >> And yeah i didn't mention ^C^V because I never use them and can > >> break other keybindings of the underlying app. Like the > >> unix-editing for textentries on gtk > >> apps, because ^W is the default keybinding for closing windows on > >> Gnome apps. > > > > In dmenu we don't need to worry about other apps, because dmenu > > grabs the keyboard and during the time until ungrabbing it we can > > override any key combination we like. That's why I propose having a > > Key interface in dmenu like in dwm that can be used to execute a > > command to insert at current text position and good is. I prefer ^p > > to Shift-Insert by default. > > > > Kind regards, > > Anselm > > > > Ctl-p is fine by me as long as it is established in config.h (i.e.\ > as long as the user has an easy chance at over-riding it). > > Peter > what about commandline flags? dmenu --bind ^p /path/to/script.sh --bind shift-insert /path/to/other-script.sh i like the general idea, though i'm not sure if it's worth the hassle (bloat?). Dieter
Re: [dev] [surf] next release
On Wed, 21 Oct 2009 16:24:55 +0200 Julien Steinhauser wrote: > On Wed, Oct 21, 2009 at 09:17:52AM -0400, Peter John Hartman wrote: > > > > What about cases in which one wishes to both type a few words and > > then paste? For example, when I want to do a smart prefix search > > (via dmenu) on Bob McCrue (who sits in my selection buffer) but I > > also want to do something like "University of Wherever" + "Bob > > McCrue" where the first part is something I type in by hand and the > > second part is something I want to just "paste" in? The same > > argument could be launched with respect to the find feature (which > > now utilizes dmenu). > > > > Or maybe you have something else in mind when you talk of > > "integrating into dmenu's cache"? > > > > Peter > > sselp does it also in case you wish to paste "and" write. > Select something, then run echo `sselp` | dmenu, tab, space > and what you write after that follows your selection, > terminate dmenu and all is printed out. and what if you want to have first the string you type yourself, and then the pasted stuff? i also think paste support in dmenu would be nice. Dieter
Re: [dev] [surf] next release
On Wed, 21 Oct 2009 11:19:42 +0100 Anselm R Garbe wrote: > If this decision remains stable in surf, I'm willing to accept the > vertical menu patch in vanilla dmenu. that would be awesome <3 Dieter PS: uzbl also relies on dmenu with vertical patch and that probably won't change
Re: [dev] Suckless mail client solution?
On Tue, 20 Oct 2009 18:53:04 +0200 pancake wrote: > The current state of my minimalist email solution is quite hacky and > incomplete > but is starting to be functional and usable. I plan to publish the hg > repo where > the source is being developed in a week or two.. > > Actually I have a pop3 implementation in 100 LOC and imap4 in 130LOC, > for smtp i have delegated the task to msmtp (i will write the smtp > protocol later), > and a main shellscript that manages all the rest. this will rewritten > to C at > some point. But actually i want the functionality. > > pop3/imap4 works on plain and ssl connections by using nc and > openssl. No extra security checks (like IP and certificate changes), > but this will be done soon too. > > There is no decent syncronization mechanisms, just basic folder > fetching from > pop3 and imap4. For the attachments Nibble will write a mime > packer/unpacker, > so this will be about 100LOC more. > > At the end I think that the first working version will be about > 1000LOC, but the code can be easily improved and cleaned up. But ATM > i'm priorizing the functionaility. > > About threads I think the best way is to grep for a subject and sort > by date. > The problem I see in threads is that you loss the timeline and for > long threads > you get just lines (no text) because of the recursively nesting > nature of the > threads. If you want to 'ban' somebody comments, its just another > grep filter > to the list, etc... > > I don't plan to add threading support at the moment, just plain and > filtered lists. > > The code of 'dmc' the 'dynamic mail client' that im actually writing > is going to > work only on *nix-based systems (no plans for w32 atm) > > About functionalities I dont want to chop any of them, but I want to > keep the > core as simple as possible, keeping the configuration minimal, and > make the core actions enought to be extended by user scripts. > > About the frontend..well i would like to write a simple gtk-based > GUI, but it > will relay on the core dmc. So it will be plain simple to write web > based interfaces, > commandline ones, or whatever. > > There's a long way to go, but half of it is already known :) > > --pancake > sounds great! Dieter
Re: [dev] Alternative for tabbing in web-browsers?
On Thu, 8 Oct 2009 11:13:38 +0200 Szabolcs Nagy wrote: > tell those ppl on the archlinux forum that there is already a > dedicated forum to dmenu, if they have some code modification in mind > they might want to share it here, and not on some random web forum > where noone finds it > > not to mention, that it's arrogant to spread modifications of an open > source software without giving feedback to the original author.. > actually the patch was announced on this ML. at least once. Dieter
Re: [dev] wmii: fullscreen window, new window becomes floating?
On Sat, 26 Sep 2009 04:33:02 +0200 hiro <23h...@googlemail.com> wrote: > how about changing the code and keeping your own awesome patch? > I suck at C. I think that adding some customizability would be a good thing. Dieter
Re: [dev] wmii: fullscreen window, new window becomes floating?
On Thu, 24 Sep 2009 19:58:58 -0400
Kris Maglione wrote:
> On Thu, Sep 24, 2009 at 11:09:10PM +0200, Dieter Plaetinck wrote:
> >Thanks Kris,
> >but:
> >if my current layout is fullscreen, why doesn't the new window become
> >fullscreen as well? (instead it takes up about 1/4th of my screen)
>
> I can't see a reason for the new window to be fullsceen unless
> it requests it. New windows in floating mode get whichever size
> they request. If you want them fullscreen, press Mod-f. I tend
> to open terminals over fullscreen windows fairly often, and the
> current arrangement works perfectly for me.
for me it's about what i (the user) want and expect, not the window.
if i'm working in fullscreen layout i do it because i like so (e.g.
because i want to be totally focused on 1 thing), and wish to continue
so.
just like when you're in stacked layout, when you spawn a new
window, it is also in stacked layout.
to make it worse, if the new window appears but is not fullscreen, you
can't use it to it's full potential, and the window behind it gets
pretty unusable as well too. (because you see only a part of it)
Surely you can do some keybinds to correct the situation but it would
be so more convenient to just have it do what i want right away.
>
> >what do i have to do to spawn new windows but have them not focused?
> >("almost" in your point 4) or keep the current window the top of the
> >stack, always? even when spawning new windows?
>
> Currently, new windows from an existing group aren't focused
> unless a window from that group is focused. Now that you mention
> it, though, I think I'll disable it before the next alpha. It
> seems to cause more trouble than it solves. Other than that, new
> windows (except for splash windows and docks) are always focused
> and raised.
>
I think this point and the issue above are subject to personal
taste and workflow. Why not make things like these configurable?
It would be pretty awesome to have more control over small details like
these.
Dieter
Re: [dev] wmii: fullscreen window, new window becomes floating?
On Tue, 22 Sep 2009 14:16:27 -0400
Kris Maglione wrote:
> On Sun, Sep 20, 2009 at 04:40:13PM +0200, Dieter Plaetinck wrote:
> >Hi,
> >in wmii, let's say I go to a new tag, open a window, make sure it's
> >not floating but rather the default layout. then i fullscreen this
> >window. then i launch a new window (using dmenu or whatever)
> >
> >result: new window opens, but:
> >1) it's floating
> >2) it has focus
> >
> >If I then unfloat this window, 2 things happen:
> >1) it goes to the fullscreet layout (hooray)
> >2) it doesn't get focus (it's "behind" the first window)
> >
> >Why is manual intervention needed? Can't it just spawn fullscreen in
> >the background?
>
> I'm really confused by this message. I'm not quite sure what
> you're describing or what the problem is.
>
> Fullscreen mode works more or less like this:
>
>1. Fullscreen windows are in the floating layer.
>2. Other floating layer windows may be in front of or behind
> any other floating layer windows, including fullscreen
> ones.
>3. When a floating window is focused, new windows open in the
> floating layer.
>4. New windows (almost) always receive focus when they open.
>5. New floating windows always open at the top of the stack.
>
Thanks Kris,
but:
if my current layout is fullscreen, why doesn't the new window become
fullscreen as well? (instead it takes up about 1/4th of my screen)
what do i have to do to spawn new windows but have them not focused?
("almost" in your point 4) or keep the current window the top of the
stack, always? even when spawning new windows?
Dieter
Re: [dev] [surf] SearchEngines patch
On Thu, 24 Sep 2009 16:28:15 +1000 Jessta wrote: > On 24/09/2009, Nils wrote: > > On Thu, Sep 24, 2009 at 10:16:28AM +1000, Jessta wrote: > >> I don't think url parameter replacement is really the domain of the > >> web browser > > > > Oh yeah, you're right. My window manager should do it. > > > I don't think url parameter replacement is really the > domain of the window manager either. I thought Nils was being sarcastic or something
[dev] wmii: fullscreen window, new window becomes floating?
Hi, in wmii, let's say I go to a new tag, open a window, make sure it's not floating but rather the default layout. then i fullscreen this window. then i launch a new window (using dmenu or whatever) result: new window opens, but: 1) it's floating 2) it has focus If I then unfloat this window, 2 things happen: 1) it goes to the fullscreet layout (hooray) 2) it doesn't get focus (it's "behind" the first window) Why is manual intervention needed? Can't it just spawn fullscreen in the background? Thanks, Dieter
Re: [dev][surf] Next schedule?
On Wed, 16 Sep 2009 15:55:22 +0200 poz wrote: > 2009/9/16 Anselm R Garbe : > > > I think tab support in firefox/IE/chrome/Safari/Opera is just a ugly > > workaround due to the limitations present in floating desktop > > environments. Tab support is the WMs job -> use dwm and it'll work > > like a charm to use tags and layouts in conjunction with surf. > > Mmh. I do agree with your point, in part. I use the awesome window > manager, but I often open *many* tabs (ie. 30+), and in this case, > even a nice lightweight tilling WM does not fit with my (crazy) usage > of a browser. :-) > your WM is not doing it's job well enough Dieter
[dev] wmii: open new windows unfocused
Hi, is there any way to start new clients without giving them focus? Right now i use a workaround: $app & sleep 0.3s wmiir xwrite /tag/sel/ctl 'select up' Thanks. Dieter
Re: [dev] Talk about sane web browsers
On Tue, 8 Sep 2009 01:16:10 +0200 Uriel wrote: > No, I'm saying that I wish people would write or help write a browser > that sucks less. My point is that adding a coat of paint on top of an > existing browser (>90% of the browser is the rendering/js/etc. engine) > is not the same as writing that sucks less at all, it is a lazy and > meaningless gesture of little practical value and that contributes > little to the sorry state of things. Well, it's more a pragmatic thing for me: "how much can I improve my own browsing experience without doing too much effort". I just don't have the time, nor the skills to work on a new (or the netsurf) rendering engine. But yet, I find that uzbl is well on it's way to dramatically improve my browsing experience (of course it can always be better, but like we do it now I think we have a good compromise). Dieter
Re: [dev] Talk about sane web browsers
On Mon, 7 Sep 2009 21:35:50 +0200 markus schnalke wrote: > > Read my slides, I clearly state this: Take the broken render engine as > black box and add sane interfaces around. > (..) > > It's the web browser that complies better with the Unix Philosophy > than any other I've seen. Only the render engine sucks (of course). > But it may get exchanged ... it's only a black box anyway. > > > meillo "black box" may be just a bit too far, but generally I think yes, if the library you depend on works, and you only need to work with it, not on it, then it doesn't matter much how ugly or big the codebase is. (as long as the api is reasonable). I definitely wouldn't like to work on webkitgtk+ because of the complex codebase, but I don't have to... There are other people maintaining it and they seem to handle it okay. > P.S. > I see `uzbl' as an example. It may not exactly be as I describe it. > (In fact, it has it's dark corners. E.g. `--geometry'.) > > There might also be other browsers that are similar (surf). I did a lot of research before starting uzbl. I couldn't find any browser that matched what I was looking for. (surf came after uzbl) Dieter
Re: [dev] Re: [surf] cookie race condition for multiple instances?
On Thu, 3 Sep 2009 21:52:02 -0400 Ray Kohler wrote: > On Sun, Aug 30, 2009 at 9:53 PM, Ray Kohler wrote: > > I'm curious as to whether a race condition is created for access to > > the soup cookie jar file when multiple instances of surf are running. > > libsoup's docs don't mention any safety mechanisms for this object, so > > I'm expecting trouble is possible. Does anyone actually know for sure? > > To answer my own question, after reading libsoup's source, I can say > that this race does exist. Adding a cookie opens the file for append > and writes it. Deleting one rewrites the file and filters the target > cookie while doing so. Updating a cookie is just a delete and an add. > Both kinds of writes open the file immediately before writing and > close it immediately afterward, so at least it's not as big a problem > as if it kept it open for the lifetime of the session. > > The easiest way to workaround this (suckless or not) is to use > libsoup's sqlite cookie jar instead, so that's what I'm going to do. > There is still another problem not solved by this - running sessions > sharing a cookie jar trust their own memory cache of the file's > contents never to get stale. Using sqlite will make sure the cookie > jar ends up as the union of the outputs of all sessions, but it won't > allow all these sessions to take advantage of each other's changes in > real time. I don't consider this to be anywhere near as much of a > problem as corruption or loss of data from the on-disk jar, though. > FWIW, in uzbl we use an external script to take care of cookie storage and retrieval. wmich makes it easy to support concurrency and multiple instances can easily share the same script (storage). Dieter
Re: [dev] mapping keyboard buttons to move the mouse?
On Wed, 26 Aug 2009 03:29:34 - (UTC) hessi...@hessiess.com wrote: > I was wondering if it was possible to map keyboard buttons to move the > mouse cursor/ send mouse button events. For example, I was thinning of > having alt gr and the arrow buttons move the mouse cursor, and alt gr > + "z", "x" and "c" send left, middle, right mouse button events. > > thanks. > > maybe you can use xbindkeys in combination with xdotool. Dieter
Re: [dev] [last] lastfm interface
On Tue, 25 Aug 2009 13:58:30 +0200 Yoshi Rokuko wrote: > On Mon, Aug 24, 2009 at 02:49:55PM -0400, Kris Maglione wrote: > > On Mon, Aug 24, 2009 at 08:27:05PM +0200, Yoshi Rokuko wrote: > > >just to clarify - my problem wasn't factotum, but to tell last to > > >play a certain station. > > > > Wrong thread, I guess. In that case: > > > > station lastfm://some/station/url > > > > or > > > > tag some-global-tag > > > > or > > > > artist Some Artist Name > > well then i don't know what my problem is ;-) > > i tested my lastfm account with shell-fm and it works, if i use the > same account and your script 'pass' and then start last i get > something like that: > > | % ./o.last > | > help > | Commands: start, stop, skip, love, ban, info, time, tag , > artist | , station > | > artist CocoRosie > | Response: OK > | > start > | > Can't get stream: Connection refused > | > 29583: signal: sys: segmentation violation > | % ./o.last > | > station lastfm://artist/CocoRosie/similarartists > | Response: OK > | > start > | > Can't get stream: Connection refused > | > 29863: signal: sys: segmentation violation > | % > > no one else has this problem? > > regards, y0shi > I know that last.fm stopped doing the free streaming. since march or something you could still play a few hundred songs but then it stopped working. unless you upgraded to a paid account. Dieter
[dev] suckless @ conferences?
Hey, do any of the surf/wmii/.. hackers attend conferences? Dieter
Re: [dev] Surf development
On Thu, 20 Aug 2009 08:11:27 + Jacob Todd wrote: > I could never get vimpression to compile. I've been using uzbl for a > while now and have never had problems with it, the only thing it's > really missing for me is good cookie support. > What are you missing? I think cookie_daemon.py is pretty nice (it's in uzbl mainline git). It uses pythons cookie lib for correct cookie handling and it uses a socket for fast communication. If you want "policies" or white/black-lists you have to hack the code a bit, which I think is okay. Note that this daemon can also be used by other browsers, it has a simple socket interface. DIeter
Re: [dev] [last] lastfm interface
On Tue, 11 Aug 2009 19:48:02 +0200 Markus Maria Miedaner wrote: > On Mon, Aug 10, 2009 at 09:22:06PM +0200, you (Yoshi Rokuko) wrote: > > a few days ago i tried out last[1]. i found out that it uses factotum > > and i managed to give factotum my lastfm-id but the sourcecode and/or > > the lastfm API is to complex for me to know how to use last[1]. > > > > i know inside last[1] there is the help command, but how do i set a > > station with the station command? i tried a few things but nothing > > worked out for me. > > > > regards, y0shi > > > > [1] http://hg.suckless.org/last/ > > > > > Ciao Yoshi, > > please have a look at the lastfm communities / groups. theres is a wmii-group > where uriel posted a shell script to > use lastFM. That might help setting stations etc... > > cheers, > markus > I can't find this? http://www.last.fm/group/wmii/forum it says there are no forums. Dieter
Re: [dev] suckless touchscreen window manager
On Thu, 23 Jul 2009 23:41:51 - (UTC) hessi...@hessiess.com wrote: > > the thing is that i'll love to try archlinux > Arch won't work, it has no support for ARM processors, Gentoo maby? unofficial ARM port: http://www.archmobile.org/
Re: [dev] OT - suckless or not ? :)
On Wed, 15 Jul 2009 16:45:49 +0200 pmarin wrote: > Well, I think the "suck less" term is not original from our comunity. > The same happens with "the Unix philosophy" of XFCE (http://www.xfce.org/): > > "Xfce 4.6 embodies the traditional UNIX philosophy of modularity > and re-usability..." > Not to mention the duplicty: - something is suckless (completely void of suck) - something does suck less (still some suck in it) These things are very different, and I think it's very, very hard to reach the first meaning I think option 2 is the commonly accepted one here, but meaning 1 sounds most natural to me. Dieter
Re: [dev] surf: web browser on archlinux
On Sat, 4 Jul 2009 10:57:47 +0200 markus schnalke wrote: > [2009-07-03 22:51] Jacob Todd > > On Fri, Jul 03, 2009 at 10:39:41PM +0200, hiro wrote: > > > > > > Web browsers suck more and more. > > > > And that's where uzbl, surf, and vimpression come in. > > No. Leandro Chescotta said it already: It's the modern web that sucks. > > Thus web browsers do suck also ... they have no chance. > > > meillo These browsers make the web somewhat less sucky. not entirely suckless but with less suck. Sometimes you need to make the best with what you got, instead of waiting for perfection that will never come. imho. Dieter
Re: [dev] dwm / add tabs / attach/detach functionality
On Mon, 22 Jun 2009 14:38:22 -0400 Alex Kilgore wrote: > hiro wrote: > > What's wmii-X? > > > > > I think he meant X as in , and anyways, I think > that in this case, the whole "dwm v wmii" thing is merely a matter of > personal preference > Anyways, I at first thought in a similar fashion about > stacking as the OP until I got used to it, and eventually I found I > like the stacking better because it makes long titlebars more > readable for one, and in terms of workspaces vs tagging, I don;t see > why having "workspaces" instead of tagging would be advantageous. > Alex > Yeah the stacked layout in wmii is pretty good. I just find it bothersome that other (unfocused) windows' titles can appear both at the top and at the bottom of the screen. I would prefer it if they would all be at the top. Dieter
Re: [dev] dmenu / enso
On Mon, 22 Jun 2009 11:09:39 +0200
Antoni Grzymala wrote:
> Donald Chai dixit (2009-06-22, 01:59):
>
> > I would admit that an interesting extension to dmenu would be the
> > ability to provide possible completions after each space, i.e.:
> > - open dmenu, list of commands shows up
> > - I type "opensshwi"
> > - dmenu calls getcompletions("opensshwindow"), which returns a list
> > of my favorite hosts: "suckless.org" and "whitehouse.gov"
> > - dmenu displays said list
> > - I type "s"
> > - dmenu prints "opensshwindow suckless.org" to stdout
>
> +1 (not that I have the skills to contribute in this department)
>
If you want such features, you may consider running a mini-terminal
with a shell running in it, such as bashrun.
Then you get all bash features such as
functions, aliases, readline/history support, argument completion etc.
Those who don't like bash could implement the same with their favorite
shell.
Dieter
Re: [dev] dmenu / enso
On Mon, 22 Jun 2009 08:45:11 +0100 (BST) "Kevin Nagel" wrote: > Dmenu shows you only a list of commands specified by PATH. It opens > the app then without any parameters and while selecting for an app > (or command) there is no description what it does. I think sth like > code completion + brief description + argument specification is the > value of enso. > > Another neat thing is you could open, e.g. open openoffice writer, > type in "2+3/5", highlight, type in enso-terminal "calc this", and > the result replaces the "2+3/5" string in your document. They claim > that you can do this with other programs as well. I believe I can > program the parser as a unix command, but when it is run from dmenu, > then I need to specify arguments. > > Kev > You can perfectly use a wrapper script that also shows you a description You can also load a command by selecting it and then pressing tab, then type any additional arguments and they will be used. (eg try xmess foobar) to call 'xmessage foobar'. you can also perfectly do your 2nd example by combining tools such as xdotool, xbindkeys etc. Or use snippits (http://rubyforge.org/projects/snippits/) Dieter
Re: [dev] Suckless (*NIX|*BSD) Distribution?
On Sat, 20 Jun 2009 04:10:41 -0300 Leandro Chescotta wrote: > arch linux here... :P but looking at freebsd lately, only not trying > it because of the hardware of my msi wind, that has more linux support > > > On Sat, Jun 20, 2009 at 2:27 AM, Kurt H Maier > wrote: > > On Fri, Jun 19, 2009 at 11:21 PM, Antony Jepson > > wrote: > >> I'm not sure if this has been asked before (although I did do a > >> quick search of ) but what distributions do you > >> guys use on a daily basis? I recently built a new computer and > >> I'm looking for a good OS to install on there. > > > > I use Slackware primarily because Pat doesn't molest upstream code > > very much. I like Arch okay but I don't really see the point of a > > ports system. > > -- > > # Kurt H Maier > > > > > > > Arch here too. I wouldn't know anything better then Crux or Arch. Maybe Nixos? Though nixos has fancy tools that may not fit the "kiss" label anymore. Dieter
Re: [dev] last request for a dev-only list
On Fri, 12 Jun 2009 12:39:37 +0200 "Claudio M. Alessi" wrote: > On Fri, Jun 12, 2009 at 01:46:20PM +0800, Samuel Baldwin wrote: > > Why can't people filter out messages with [OT] is the subject line? > Why can't people just stay on-topic? > > To me, people should avoid OT posts, should use filters (since the > list configuration can't satisfy all users, while personal filters > do) and should just read the archives when they only read the list > without never write something. The stfu rule suggested by Gottox is > also fine, at this point. > > Regards, > Claudio M. Alessi > I have a totally different POV on this whole matter. Imho all the threads about these issues are very entertaining reading material, so I hope the lists stay as they are :) Dieter
[dev] stacked mode: all titlebars on top of screen?
Hi, when using the stacked layout in wmii is it possible to see all titlebars of the other windows always on top? I find it rather confusing that there can be titles above and below the focused window. Thanks, Dieter
