[dev] [dwm] shiftview patch (shifting tagset left/right )
Hi,
I've got what I think might be a better implementation of the
nextprevtag.c patch.
It's just a simple bitwise left/right circular shift of the tagset,
avoiding the loop that the older patch used and with the additional
benefit of working also for switching tagset with multiple tags
selected.
I did it before realizing there was already a "nextprevtag.c", and
although it's very simple, since it's a bit different in functionality
I thought that maybe it would be useful for someone else.
--
Fernando Carmona Varo
/** Function to shift the current view to the left/right
*
* @param: "arg->i" stores the number of tags to shift right (positive value)
* or left (negative value)
*/
void
shiftview(const Arg *arg) {
Arg shifted;
if(arg->i > 0) // left circular shift
shifted.ui = (selmon->tagset[selmon->seltags] << arg->i)
| (selmon->tagset[selmon->seltags] >> (LENGTH(tags) - arg->i));
else // right circular shift
shifted.ui = selmon->tagset[selmon->seltags] >> (- arg->i)
| selmon->tagset[selmon->seltags] << (LENGTH(tags) + arg->i);
view(&shifted);
}
Re: [dev] wmii as a prepatched dwm (Was: segfault)
2011/6/27 a.l.e : > this is the main reason why i prefer wmii to dwm: i don't want to keep track > of > versions of dwm and of the patches i have applied. I've been using dwm-sprinkles, it's a nice mashup of patches and maintained up to date. http://0mark.unserver.de/projects/dwm-sprinkles/ -- Fernando
Re: [dev] tabbed - why?
On Mon, Feb 17, 2014 at 8:26 PM, Calvin Morrison wrote: > If tabbing is just a form of window management, why don't we seperate > all tiling modes into separate programs. I'd say that dwm's monocle layout could already be considered a "tab" mode, since it overlaps several windows (you'd only miss having the titles of all the windows/tabs in the status bar, but I believe there's a patch for that). It's just that dwm is designed to be simple and clean, no layouts inside of other layouts. Which IMHO is unnecessary. You may want to create a specific layout for your particular case if you need several groups of windows overlapped in a specific way different than monocle (or you might as well just use the floating layout). -- Fernando
Re: [dev] tabbed - why?
On Tue, Feb 18, 2014 at 12:17 AM, Fernando C.V. wrote: > You may want to create a specific layout for your particular case if you need > several > groups of windows overlapped in a specific way different than monocle I just remembered about the deck layout [1], it's another example of a particular case of stacked windows in a tab-like way. It might be useful to you. The issue might be that you don't immediately know what overlapped windows there are, and fancybar patch [2] might help there. Sorry for the double mail. [1]: http://dwm.suckless.org/patches/deck [2]: http://dwm.suckless.org/patches/fancybar -- Fernando
Re: [dev] A dmenu that includes all additional features
On Sun, Sep 11, 2011 at 11:09 PM, Dieter Plaetinck wrote:
> * 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)
I'm not really sure what does "stable sort" means, but I modified my
dmenu_run script to make it have some sort of history in
most-recently-used order.
Here it is, in case it's useful:
## Begin of script
#!/bin/sh
HISTORY=${XDG_CONFIG_HOME:-"$HOME/.config"}/dmenu_run.history
CACHE=${XDG_CACHE_HOME:-"$HOME/.cache"}/dmenu_run
(
IFS=: # for $PATH :-sepparated entries
if test "`ls -dt $PATH "$HISTORY" "$CACHE" 2> /dev/null | sed 1q`" !=
"$CACHE"; then
# Add all the executables in PATH
mkdir -p "`dirname "$CACHE"`" && lsx $PATH | sort -u >> "$CACHE"
fi
)
cmd=$(tac "$HISTORY" "$CACHE" | dmenu "$@") || exit
{ # Update history in background
(echo "g/${cmd}/d"; echo 'wq') | ex -s "$HISTORY"
echo "$cmd" >> "$HISTORY"
} &
exec sh -c "$cmd"
## End of script
--
Fernando Carmona Varo
Re: [dev] smessage
I've been wanting for a long time some simple tool to replace the libnotify popups. Using xsetroot is just not enough for me to notice the warnings (and I do need to be warned when my battery is running out or the temperature is too high). Both xmessage and smessage use a window that steals the focus as soon as it appears, so it's not very nice. I didn't play too much with X11 API.. would it be even possible to modify smessage.c to draw directly on the display without using a window? if so.. any help on how would I do this? -- Fernando
Re: [dev] [dmenu] What is the status of the project?
A feature that would be a nice improvement would be to extend the behaviour of the -f flag to not only grab the keyboard but also draw the window already and start adding entries to the menu as they are received from stdin. That way, we bring dmenu to the user at the instand t=0, even while a extremely long list of items that would take long to reach EOF is sent to dmenu (sometimes this happens for my dmenu_run script, which cats a history file in addition to the list of executables). I believe there was some mail at some point from someone that was trying to do something like this, but I'm not sure how far did it went. -- Fernando
Re: [dev] [dwm] Running dwm in KDE
On Tue, May 21, 2013 at 12:53 AM, Martin Miller wrote: > I guess this system is a combo of Gnome and KDE. > I spent a little time unsuccessfully configuring gdm from the settings > panel. If you have the choice, I would recommend getting something like "slim" and just tweak your xinitrc to your liking, setting the environment variables you need and the stuff you want and have a "startkde" at the bottom. Also instead of slim you can just add "[[ $TTY == "/dev/tty1" ]] && exec xinit" to your bashrc and get rid of the display manager completely. -- Fernando
Re: [dev] [st] problem reading man pages
On Wed, May 22, 2013 at 11:23 AM, G David Modica wrote: > I believe it defaults to "less". Maybe you have some custom less settings? try this: echo $LESS echo $LESS_TERMCAP_mb - $LESS_TERMCAP_md - $LESS_TERMCAP_so - $LESS_TERMCAP_us echo $LESS_TERMCAP_me - $LESS_TERMCAP_se - $LESS_TERMCAP_so - $LESS_TERMCAP_ue -- Fernando
Re: [dev] [st] problem reading man pages
or better: set | grep LESS -- Fernando On Wed, May 22, 2013 at 11:48 AM, Fernando C.V. wrote: > On Wed, May 22, 2013 at 11:23 AM, G David Modica > wrote: >> I believe it defaults to "less". > > Maybe you have some custom less settings? > try this: > > echo $LESS > echo $LESS_TERMCAP_mb - $LESS_TERMCAP_md - $LESS_TERMCAP_so - > $LESS_TERMCAP_us > echo $LESS_TERMCAP_me - $LESS_TERMCAP_se - $LESS_TERMCAP_so - > $LESS_TERMCAP_ue > > > -- > Fernando
Re: [dev] [st] problem reading man pages
Maybe you altered your st colors somehow and the highlights make the characters hard to see... my guess is that the words are there rendered, but unreadable.. can you copy-paste the invisible spaces between the "[-c ]"? (sorry for the 3 mails in a row... I just I kept thinking about it) -- Fernando
Re: [dev] Re: Why HTTP is so bad?
On Fri, May 24, 2013 at 11:58 AM, Prakhar Goel wrote: > Anybody take a look at the /browser idea? > > Site:http://blog.ezyang.com/2012/10/get-browser-exe/ That looks interesting. But then it would also compromise the openness and "hackability" of the web. I like that I can easily inject my own javascript or css on any website to make it do what I want, remove whatever advertising or any sections I don't want. To make it readable and adaptable to my environment. Or parse them myself and extract some data from it, include them in a script and process the text with UNIX tools. If a new stack were to replace web browsers, I wouldn't want it to be designed to send me a closed mess of binary bloat from some company that might not care to consume all my computer resources to show some flashy shit. -- Fernando
Re: [dev] Re: Why HTTP is so bad?
On Fri, May 24, 2013 at 1:02 PM, Dmitrij Czarkoff wrote: > But even if there is no protocol better then HTTP, it doesn't necessarily > mean that HTTP > is OK. The best possible solution to a particular problem should be OK for the purpose of solving the problem. IMHO, the thing is that multiple problems are being mixed and forced to work through a solution that wasn't designed for that. And this is not efficient. -- Fernando Carmona Varo
Re: [dev] Re: Why HTTP is so bad?
On Sun, May 26, 2013 at 3:21 PM, Dmitrij Czarkoff wrote: > How does this problem differ from downloading a file from URI in IRC chat or > from mail? Why should it be solved differently in browser then? Doesn't have to be solved differently, but then, for the sake of convenience, network efficiency and QoS, it would be indeed preferable to those big files to be accessible without being completely downloaded, both in IRC, browser or wherever. Normally this means (for videos at least), the link is actually a html page with a flash plugin or a tag. Either that or you will need a video player that speaks http.
Re: [dev] Re: Why HTTP is so bad?
On Mon, May 27, 2013 at 12:38 PM, Dmitrij Czarkoff wrote: > There can be a gentler solution similar to the way some network protocols > are handled in FUSE, Plan 9 and HURD: they create a pseudo fs and let normal > file I/O on it. *Much* cleaner approach IMO. On Mon, May 27, 2013 at 12:34 PM, Hadrian Węgrzynowski wrote: > [1] http://httpfs.sourceforge.net/ Thanks awesome. How come surf is not based on this idea? -- Fernando
Re: [dev] lynx?
I use elinks. It's not suckless, but it's the text browser that handles the web better, from my experience. Also you can write rules for it that allow you to preprocess certain websites or handle some of them differently, like running external viewers for images, using youtube-dl when you open youtube urls, etc. -- Fernando On Tue, May 28, 2013 at 1:06 PM, markus schnalke wrote: > Hoi, > > these days, lynx was often mentioned when a text browser was meant. > Is there really someone (apart from mirabilos) who uses lynx? Don't > you rather use w3m? > > I am just wondering ... > > > meillo >
[dev] Is there any plan on a shell for sbase?
Probably I'm talking shit here... or maybe this is something you are considering with sbase already... but I kept thinking about this. Would it make sense to create a whole shell infrastructure based on little small commands? I mean, not just replacing no-brainer builtin things like "echo", etc, but also things like "if", "while", "for", "set", by doing system() calls to an extremelly minimal shell. Would it make sense? maybe even a command for creating pipes. It wouldn't be POSIX-conformant, but then just as long as the names don't conflict and the commands were available the script would run on normal shells too. Then you could have a damn small /bin/sh core that only takes care of finding things in PATH and doing variable and filename expansion. Then also you could get rid of some of the irregularities in shell syntax that make it kind of weird for something that should be so simple. Would this make sense or would it be extremely inefficient and stupid? -- Fernando
[dev] Re: Is there any plan on a shell for sbase?
> by doing system() calls to an extremelly minimal shell. Would it make sense? uh.. I mean, something like a while-cmd like this: while-cmd 'test whatever' <
Re: [dev] suckless dotfiles approach
> * When symlinking files i get problems when moving/backing up the > configfiles in $HOME since it will move the symlink and maybe write an > actual file to $HOME instead.label:l-dwm dot The files are already under version control, if you need backup you could use some remote repository to sync with. Why would you need to move them? they are dotfiles, they usually need to have a fixed path to be usable anyway.
Re: [dev] suckless dotfiles approach
On Sat, Jun 8, 2013 at 12:22 PM, Markus Teich wrote: > I'm not exclusively talking about me. Some random script (software update?) > or anything could move them. Are you talking about dotfiles from $HOME/? If some software update or random scripts starts manipulating my home directory like that I would prefer to know so I can avoid such software. > Also http://harmful.cat-v.org/software/symlinks That's a valid argument against the current implementation of symlinked directories. If you just symlink files and not directories, this wouldn't happen. For hardlinks, directory linking is even worse, since it leads to recursivity. That's why they are usually disabled. -- Fernando
Re: [dev] Re: Maintaining sbase
>> It's for people that don't know how to use FIFOs/process substitution >> properly ;-) >> > > should suffice: > > cat file | tee >(sort -u > sorted) >(sort -R > unsorted) > That's a bashism, not POSIX. Not much better than using pee -- Fernando Carmona Varo
[dev] [dwm] changing the current view from a function
Hello,
I realised that since several revisions ago (like months ago,
actually), the shiftview.c patch [1] is messing up the layouts.
Doing something like the following also shows the same issue (should
switch to the Tag 5):
void
shiftview(const Arg *arg) {
Arg shifted;
shifted.ui = 1 << 5;
view(&shifted);
}
Did anything change in the code? what would be the right way to write
a function to switch views without messing up the tiled layout?
The view switches but then only the monocle and floating layouts work
properly, all other possible layouts (like tiled) show the windows
tiled in a single vertical column, with no master window. Not being
possible to have one window at the left and another at the right.
--
Fernando
Re: [dev] New utility "when"
On Wed, Dec 11, 2013 at 10:36 PM, Rob wrote:
> [local-machine %] ssh user@host & && xmessage connected
> [ssh-machine %] ...
>
> `xmessage connected' will be executed even though ssh hasn't exit(0)'d
> yet.
bash: syntax error near unexpected token `&&'
You probably meant this:
$ { ssh user@host &; } && xmessage connected
Still, you would always be running "xmessage connected" even in the
case of "ssh user@host" failing, which is not what he wants.
--
Fernando
Re: [dev] New utility "when"
On Thu, Dec 12, 2013 at 12:56 AM, Fernando C.V. wrote:
> $ { ssh user@host &; } && xmessage connected
Whoops, it's:
$ { ssh user@host & } && xmessage connected
Btw, what "when" does is that it considers that the program is running
successfully if it didn't exit with error after X seconds.
Sounds like a little nice useful utility, even thoguh I don't like
that the commands have to be passed "quoted", as arguments just like
that. Not sure if there's a much better way to do it, though.
--
Fernando
Re: [dev] New utility "when"
An alternative would be to read one of the commands from stdin. This way could do something like: $ when -t ssh host > xmessage DONE! You won't get tab-completion and other interactive fancyness, but it won't be missed for simple notification commands. -- Fernando
Re: [dev] New utility "when"
On Thu, Dec 12, 2013 at 10:49 PM, Fernando C.V. wrote: > This way could do something like: > > $ when -t ssh host >> xmessage DONE! Well... even if you didn't prompt it to the user interactively, it would still be nice for aliases. Probably most of the time you just want to get notfications: $ alias retry='echo "xmessage DONE" | when' $ retry ssh host -- Fernando
Re: swc library to implement dwm under Wayland (was Re: [dev] gtk3 support for surf?)
On Sun, Jan 12, 2014 at 11:39 AM, FRIGN wrote: > I am still wondering if Wayland really is the way to go, given the fact > it requires a lot of dependencies for "basic" tasks (*(E)GL, dbus, PAM, > DRI (mostly)) and hogs memory. I believe most of the implementation details are up to the compositor, Wayland is just a protocol. At least in archlinux, the wayland package has only 2 dependencies: libffi and expat Regards, -- Fernando
