[dwm] nanox
I have been looking a bit for an alternative for X11, and I found nano-X quite interesting, but it is currently an abandoned project. 8000 LOCs, there's an abstraction library to wrap libX11 and there's support for some many IO devices (tty, gpm, ..) It runs directly writing on fb0, but it shouldnt be hard to make it run as Xnest (for testing purposes) or draw a xorg-driver layer to directly run with native graphics drivers. The source looks quite clean and I think we can use it as base for the minimal X replacement. ARG, what do you think about this? :) A dwm port to nano-X would be also interesting, so having all the primitives abstracted as we already discussed few mails ago would be necessary. I have seen screenshots of nanox running mozilla, so i can think that there's no opengl support and so on, but in reality...i never use opengl and everytime i try to use less the browser, so for low memory and resource usage a nanox with dwm-nanox and some nanoxterms somewhere would be nice. There's little movement in the mailing list nowadays, but the last release is from 1999. So I can think that the project is dead. Here's the last release of nanox (0.4) http://www.tucows.com/download.html?software_id=9833t=2 Actually the project has grown and it was renamed to microwindows which has become a much bigger project: ( iwas unable to compile it because of the outdated dependency against freetype (v1) ) ftp://microwindows.censoft.com/pub/microwindows/microwindows-full-0.91.tar.gz (10MB) this tarball contains nanox (but depends on freetype and such) and now is 16KLOC Official website: http://www.microwindows.org/ --pancake
[dwm] musca wm
another tiling manager with interesting features: http://aerosuidae.net/musca.html
Re: [dwm] musca wm
What I find interesting is the support for multi-screen. Actually I'm using wmii at work, because dwm cannot properly handle multiscreen layouts and this made me use the mouse too much. Wmii has some bugs, but at least is IMHO better for multiscreen layouts. I think this is the eternal discussion, because it is hard to find the 'best' approach to this problem for dwm. But for single-screen environments dwm still rocks :) I really miss the conceptual experimentation that dwm was in the past. But I agree that we should probably focus on other topics like 'st' or a full OS based on minimalist software (based on Linux without GNU craps) ... What do you think about creating an offtopic mailing list in suckless for discussing such kind of topics, instead of using the dwm@ one like nowadays happen. --pancake Benjamin Conner wrote: it's interesting. But I prefer dwm or wmii. On Fri, May 15, 2009 at 8:00 AM, Anselm R Garbe garb...@gmail.com mailto:garb...@gmail.com wrote: 2009/5/15 pancake panc...@youterm.com mailto:panc...@youterm.com: another tiling manager with interesting features: http://aerosuidae.net/musca.html Looks to me it's aiming the original WMI without tabbing a little bit. I definately prefer the dwm way after all ;) Kind regards, Anselm
Re: [dwm] musca wm
A friend of me is writing a pkgsystem that builds everything inside a chroot and allows to create a full usable distribution, the pkgsystem itself is not yet finished, but is pretty fast , written in C and shellscript and I really think it is a good project. But actually it is a single-man project. We can use this project as a tool to build the base system. http://repo.or.cz/w/xbps.git/ Actually i'm happy with arch linux, but, i really miss a non-gnu linux and minimalistic distribution. We should get a look on alternatives for glibc (google one? uclibc? ..) but maybe the biggest rock we will face it will be the X server...this is probably one of the interesting projects to work on, but without keeping the X compatibility. (just as an emulation layer) X11 is bloat. (as we have already discussed, we can reuse the drivers of xorg) but designing a better and simpler API. But this is probably a long topic to talk about, and we're of course not the first ones to claim for an X11 replacement. --pancake Benjamin Conner wrote: What do you think about creating an offtopic mailing list in suckless for discussing such kind of topics, instead of using the dwm@ one like nowadays happen. I agree with Anselm. I like a lot of your ideas in that message. I really miss the conceptual experimentation that dwm was in the past. But I agree that we should probably focus on other topics like 'st' or a full OS based on minimalist software (based on Linux without GNU craps) ... That's a good idea. Maybe do an lfs. I'd use wmii as the Wm, so you don't have to recompile. Or maybe have no WM and just X so that you can put one in yourself and customize it. IDK. On Fri, May 15, 2009 at 9:57 AM, Leandro Chescotta lchesco...@banelco.com.ar mailto:lchesco...@banelco.com.ar wrote: 2009/5/15 Anselm R Garbe garb...@gmail.com mailto:garb...@gmail.com : I'll provide a new multiscreen support this weekend in dwm. It's based on assigning specific tags to specific screens. I really like the idea La información del presente documento es clasificada como Confidencial.
Re: [dwm] musca wm
+1 :D nilp wrote: On Fri, May 15, 2009 at 05:38:51PM +0200, yy wrote: effort, but it would not give me any real benefit. There is a suckless alternative to GNU: Plan9. If I still run (arch)linux is because I often need things like a full featured web browser, pdflatex, the How about Glendix? Our ultimate goal is to create a minimalist Linux distribution that contains a Plan 9 userspace, instead of the GNU software that is usually provided by most distributions. http://www.glendix.org/
Re: [dwm] musca wm
On May 15, 2009, at 10:56 PM, Preben Randhol rand...@pvv.org wrote: On Fri, 15 May 2009 15:42:24 +0200 pancake panc...@youterm.com wrote: I really miss the conceptual experimentation that dwm was in the past. But I agree that we should probably focus on other topics like 'st' or a full OS based on minimalist software (based on Linux without GNU craps) ... Please, make a C, C++ etc.. compiler then. Tinycc is live again. You should check it. What do you think about creating an offtopic mailing list in suckless for discussing such kind of topics, instead of using the dwm@ one like nowadays happen. I like that the list is open to somewhat off topic discussions. Sometimes they lead to a less suckless life for people in that they solve problems for people :-) Yep me too :) Btw what about a minimal mua? Would be nice to build a database of minimal software and try to classify it and comment about it. This way we can get a list of the things 'we' have, and the ones missing. The wiki can be a good place, but maybe we should think on a new page ??.suckless.org
Re: [dwm] musca wm
On May 15, 2009, at 11:07 PM, Preben Randhol rand...@pvv.org wrote: On Fri, 15 May 2009 17:06:45 +0200 pancake panc...@youterm.com wrote: Actually i'm happy with arch linux, but, i really miss a non-gnu linux and minimalistic distribution. We should get a look on alternatives for glibc (google one? uclibc? ..) but maybe the biggest rock we will face it will be the X server...this is probably one of the interesting projects to work on, but without keeping the X compatibility. Any reason why you need a non-gnu distro? I don't see how that would make things suckless. I would wish for a perl-free world, but it would probably not happen any time soon. Gnu software is bloated by definition. You only need to take the 'true' program. Just type strings /bin/true :) I like perl but I agree but it is big for most of uses, but is fast and powerful. I would prefer to use nqp or miniperl which are minimal versions of p5 and p6 compiled at build time to compile itself and do some processing stuff that makes the build process more handful and controllable than using make. It is a huge sw, but miniperl is cool :) About busybox.. The reason to be a single binary with aliases is to memory usage. The problem maybe is that it ships program we will probably not use, but it is something to be ignorable on current hw. If you ever tried to build glibc,gdb,gcc,binutils... You will understand what I want a minimal distro. About vim, I like it but I really think that lot of features like screen handling, colors, ctags, should be external. Pipes are powerful, and speed can be pretty good if the core is smart enought. Using a prefork or similar technique done by apache f.ex can really accelerate such tasks, so a minimal vi editor with nice features can be really achieved by delegating all such features to external apps or libraries Anyway, it is easy to say that something is bloat, but when you cannot dictate the development of hardware, don't expect things not to be complicated. Suckless hardware will be the next step :P I find rewriting existing software to make it smaller is seldomly a productive way. Invent something different and novel in stead. What minimalistic sw offers to me is new point of view, because it is based on constant refactoring and brainstorming. We need new things, that's true, but we also need to build them on top of a decent base system. Or at least is what I think. And I know that it is not an easy task, but we are enought people to organize or discuss such kind of projects.
Re: [dwm] dwm's future
I want to feed the mailing with some more words about this topic... I don't really care about the font rendering, because I just use title bar to see what's going on the window (like for large builds or browser's page titles, ..) And I dont really read contents in chineese or russian, so i'm happy with ascii. But I understant that there's people wanting to use truetype fonts for fixing those issues. If we just implement this stuff into separated .c or .h files, so everybody can still use the basic x11 stuff, or just use cairo/pango or..maybe someone would like to use it on w32 or osx, so, these guys will just have to implement this little backend, and keep all the dwm internals clean and portable for all the systems and backends (also for ncurses?). The problem here is that actually all the keybinding stuff depends on X, and there are other stuff that is pretty linked to X11, and if we want to drop this hard X11 binding we should try to split it up into a set of callbacks. I really like to click on the statusbar, so the code that it is currently there is more thatn enought to me. As somebody told in another other mail maybe we should focus on the Xinerama problem, which is probably an endless issue, or maybe we should rewrite X into a new protocol and set of libs in a more minimalistic way and if someone wants to run an Xbased app just use Xnest/Xephyr or just provide a way to run Xbased windows inside the new 'graphical server'. THis last point is probably the way to go, but obviously is a long time project but i just wanted to throw few ideas more. About the buggy apps, well.. i really dont have any problem with any application, and maybe this is because i mostly use few graphical applications, and all the ones I use are free software which gives me the possibility to fix any issue or report it. (blame on privative solutions) (mathematica, ...) For me the solution for using those broken apps is just to run a fullscreen nested X server in a tag and run the application inside with no window manager or with another one. I want to keep dwm simple, i think that all the dependencies should be optional and minimal, so we should probably think on the basic primitives to work on X and wrap them as function pointers in a single structure, and allowing compile- time-plugins to overwrite those pointers with cairo, w32 api or so. And please, keep the statusbar and the clickable stuff functional or at least optional for those who dont want to use it, but maybe we can think in a more extensible design for it, but exporting/importing window manager stuff between processes is something stupid if you just need few things and they can be managed from inside the window manager, for me having this feature inside keeps the things easier. --pancake Anselm R Garbe wrote: Thanks for all the valueable input so far in this thread. I think here are the action points: 1) I plan to separate the bar stuff code-wise into two portions -- the tag bar with tags and layout info, and the title/status bar, but things will stay as they are from a user perspective, it's just some code cleanup which allows replacing the tagbar and/or title/status bar with something else (or avoiding to compile it in) There might be possible pango/cairo implementations of this stuff, I plan to have a font API interface, something like libsfont which is used by dwm and dmenu to start with, and which depends on either Xlib or some more fancy sucking stuff optionally. 2) I need to investigate into the reparent stuff first, I really dislike going the reparent route, because each parent window consumes much more X resource memory (basically twice the buffer sizes as we have already if you use a reparenting WM -- this makes everything slower). I really think bug the authors of the broken apps to fix their apps that they do not assume a reparenting WM. So the action here is: let's make a list of all apps which are known to be broken and behaving strange with dwm first, that I can investigate. - Mathematica (Version?) - ... please provide input 3) I agree multihead has got some preference, I like the approach to assign certain tags to specific screens. Kind regards, Anselm
Re: [dwm] dwm's future
When I was in the university I had to use matlab. Proffessors told me that I can use the windows boxes in place, but for personal reasons (time and so) I proposed them to use the telnet interface and use it remotely. It happened that their license didn't allowed them to export the application via network. Which is IMHO a very stupid and privative limitation. At this point I decided to install octave on a remote netbsd box, add some fixes to the package and I develop all the tasks finding equivalences between the sintaxes. The last page of my work was an explanation of the reasons for using it. I just explain that I don't support software that limits my freedom and possibilities, and I also explain how incorrect is to teech people with privative tools. They accept my project but things didn't changed. On Apr 27, 2009, at 9:05 PM, Amit Uttamchandani atu13...@csun.edu wrote: Except some of us don't have a choice and have to use this for their work or at uni... Well, what about GNU Octave? Mathematica seems to have become as much a disease as Fortran was in last decades. I once tried to explain to my professor if I could use Octave instead of Matlab but he wouldn't even hear of it...I even tried explaining that is compatible, etc., etc. but no luck...
[dwm] [OT]: /write in c/
http://www.youtube.com/watch?v=XHosLhPEN3k
Re: [dwm] Gemini Terminal manager for gnome
Hey thij! Congratulations for the 'public release' ;)
I find gemini a quite interesting approach for non-tiled environments
like OSX/W32 where you at the end dont want to use anything more
than terminals.
Vala+VTE+gee+WAF are funny dependencies that makes the code
funnier to read, but definitively the result is not that minimal, but
at least is nice to read. And if somebody plans to do it in a minimalistic
way supporting xwindow embedding inside he will have a good test
base to play with thanks to gemini.
About the keybindings i would make some changes:
meta+shift+{h,l} = remove shift (like in dwm)
meta+m = meta+b (like in dwm)
meta+{+,-} = change font size
The use of ^-[0-9] to move a terminal from one tag to another looks
strange to me, because im most close to the dwm default keybindings,
but looks shorter. i just need some time to accomodate ;)
BTW im actually using gemini as my default terminal inside dwm, and
works like a charm, the funny thing of vte is that properly stores
all the buffer of the terminal and there's no problems for resizing and
lose contents.
Another nice feature i would like to see is the possibility to change the
background color of a vte instance with a keystroke. this way i can
'mark' my terminals as for different tasks and i can find them faster
if i have multiple of them mixed between tags.
I also miss a contextual menu to use the gnome's clipboard and probably
any other minimal option.
--pancake
Thijs Vermeir wrote:
Hello all,
I did like to announce a project of mine, gemini terminal manager.
It's a terminal
manager for gnome heavily inspired by DWM window manager. (or at least
the behavior of it)
I started creating this because currently there is no alternative for
a tiled terminal manager
in gnome/kde/... and sometimes you need to run another window/desktop
manager for work or pleasure. Ok, there are some other terminal
programs like terminator that try todo something but I fail to use
them without the mouse, so they don't increase the speed of my
workflow in gnome.
It supports the main features from DWM like tiles, tags and layouts.
So you can have a terminal on multiple tags, switch layouts,...all
without using the mouse.
The bad part for suckless people, it's build with recent higher-level
technologies like waf, vala and vte. So it's not small and
minimalistic in the core, but that is also not my intension (and
probably does not make much sense if you need to run gnome), and it's
not finished yet. (you have to configure key bindings in the source
code). But I guess that last one can't be the problem ;-)
But It improves already my workflow when I'm inside a
gnome-environment, so it's usable already.
All feedback bad or good is welcome off course.
Gr,
Thijs
http://gemini.digitalmediaplanet.net/index.php/Main_Page
[dwm] minimalist bug tracker
Just thinking about the bug tracker tip for the GSoC.. A friend of me wrote a minimalist bug tracker for commandline called 'bug'. http://vicerveza.homeunix.net/~viric/soft/bug/ And some time later i just wrote a simple frontend in php: http://radare.org/tabs/bugs.php.txt (550LOC) Few weeks ago another colegue which is developing a simple and secure language for writing web pages and console applications by using templates called 'mcms' wrote a port of the bug+bugs.php.txt in his own language in about 320LOC. Here's the example and the source: http://www.yoire.com/mcms-convert/hgweb http://www.yoire.com/m/bug.mcms.cgi http://www.yoire.com/m/bug.mcms.cgi/showSource Hope it helps to somebody :) BTW I end up always using a single TODO and BUGS files O:) Enjoy
Re: [dwm] Suckess Code Management
Kurt H Maier wrote: On Fri, Mar 13, 2009 at 12:59 AM, Alan Busby thebu...@thebusby.com wrote: I am astounded by how many respondents regularly use file managers! Yeah, I'm starting to feel like I'm missing something here... Do file managers have some killer feature that the shells (bash/tcsh/zsh/etc) don't? Yep. When you have a big directory full of images, and you want to selectively delete some, it's pretty handy to have a big window full of thumbnails to ctrl+click at will and delete all at once. Same goes for auto-generated pdf files with near meaningless names. Kurt i use gqview for images. for pdfs i always try to name them in a proper way.
Re: [dwm] Suckess Code Management
i was using elvis so far until i started using vim. I was pretty happy with it, but the feeling was that it was keeping so much stuff in the core instead of delegating to external programs or scripts. But thats true, elvis is smaller than vim :) you can publish a git/bzr/hg branch of the last commit with your patches. I will happy try it and we can probably use it as a playground. Ali Gholami Rudi wrote: Hi, Amit Uttamchandani atu13...@csun.edu wrote: 3. Text Editor - Vim I mostly use elvis which, in my opinion, is much smaller, faster and more suckless vi-clone than vim. As a little example compare elvis.syn with vim syntax files. It even has interesting features that vim lacks (for instance see :display or smartargs). (they might be available in vim through scripts.) The only problem is it is not maintained anymore, AFAIK (I have sent a couple of patches to Steve Kirkendall but got no response; neither does the web page show any activity). I really hope it to be maintained once more :-( Regards, Ali
Re: [dwm] xgamma notify
Samuel Baldwin wrote: 2009/3/6 pancake panc...@youterm.com: I have been playing a bit with xgamma and I think it can be useful as a graphical notification for important alerts like low battery or so. The usage is quite simple. and we can 'flash' the screen in red for a fraction of a second with: What happens if you're not looking at the screen? The screen explodes.
Re: [dwm] xgamma notify
I use xterm and it is affected by xgamma, the grey letters become darker for a while. Sounds strange that urxvt isnt :? Alan Busby wrote: urxvt seems to ignore xgamma. So although it's a great idea, it isn't much help if you only have some terminals open. On Fri, Mar 6, 2009 at 9:05 AM, pancake panc...@youterm.com mailto:panc...@youterm.com wrote: Samuel Baldwin wrote: 2009/3/6 pancake panc...@youterm.com mailto:panc...@youterm.com: I have been playing a bit with xgamma and I think it can be useful as a graphical notification for important alerts like low battery or so. The usage is quite simple. and we can 'flash' the screen in red for a fraction of a second with: What happens if you're not looking at the screen? The screen explodes.
Re: [dwm] CLI color/font override patch
This can be easily done with radare: set the font in config.h to: FONTOFF (dots for padding) use this command to find the offset to this buffer: $ echo / FONTOFF | radare -n dwm and then you can just change it with: echo w 10x20 @ 0x1354 | radare -nw dwm 0x1354 is the offset t the fontoff buffer by using a endwatermark with a fixed length we can either do all this stuff in a single line without having to manually recover the fontoff. Font is a char[128+7]= ..FONTOFF FONT=10x20 echo / FONTOFF |radare -e cmd.hit=s-128w $FONT -nw dwm - original message - Subject:Re: [dwm] CLI color/font override patch From: Mate Nagy mn...@port70.net Date: 2009/02/24 19:32 On Tue, Feb 24, 2009 at 02:05:21PM -0500, Jeremy Jay wrote: If you want to avoid the compile I'm sure it'd be just as easy to use a hex-editor on the strings. we should write something like Dehacked for dwm :D Mate
[dwm] [OT] minimalist ruby?
in the description says: VM specs * Register based http://github.com/macournoyer/tinyrb/blob/master/vm/opcode.h, (like Lua) * Boehm GC http://www.hpl.hp.com/personal/Hans_Boehm/gc/ * Very small 64K, ~2000 sloc * Method caching and some inlining * Lexer in Ragel, parser in Lemon that ~2kloc sounds suckless :) http://code.macournoyer.com/tinyrb/ [+]
Re: [dwm] dwm-5.4 restart without close clients
while : ; do ( while : ; do date ; sleep 1 done ) | dwm done $ sudo cp dwm /usr/bin/dwm $ pkill dwm Luca wrote: Is there a way to restart dwm after recompiling source without closing clients? This is my current .xsession xsetroot -solid black xrandr -s 1024x768 uxterm firefox while true; do xsetroot -name `date '+%a %Y%m%d %H:%M'` sleep 1 done exec /home/lucapost/usr/bin/dwm /dev/null Thanks, Luca. On Tue, Jan 13, 2009 at 5:37 PM, dwm+h...@suckless.org mailto:dwm%2bh...@suckless.org wrote: Welcome! You have been subscribed to the dwm@suckless.org mailto:dwm@suckless.org mailinglist. To unsubscribe send a message to: dwm+unsubscr...@suckless.org mailto:dwm%2bunsubscr...@suckless.org And for help send a message to: dwm+h...@suckless.org mailto:dwm%2bh...@suckless.org -- Luca Postregna Via Postregna 6 33040 Stregna, UD - Italy Tel. +393381587782
Re: [dwm] how to float all gui programs
all the programs running on X are GUI ones :)
bill lam wrote:
At present I float common gui programs that I used into config.h like
static Rule rules[] = {
/* class instancetitle tags mask isfloating */
{ Abiword, NULL, NULL, 0,True },
{ Acroread, NULL, NULL, 0,True },
{ Gnumeric, NULL, NULL, 0,True },
I need to compile each time I add anthor gui program. Is there any
way to automatically float all gui program?
[dwm] nokia on android LOCs
/I was just reading some news and got shocked by this sentence: USA/ - According to Niklas Savander, executive vice president of services and software at Nokia, Google Android isn't yet ready for Nokia to make an assessment on. A platform has three to four million lines of code http://www.sfgate.com/cgi-bin/blogs/sfgate/detail?blogid=19entry_id=26740 Savander told SFGate.com http://www.sfgate.com/cgi-bin/blogs/sfgate/detail?blogid=19entry_id=26740. When Android has that many lines, we'll make an assessment. Until then it's just an announcement. fmi: http://conversations.nokia.com/home/2008/05/google-android.html --pancake
[dwm] 5.2 problems
I have just pull the 5.2 release and start trying it and find some nasty problems when handling the slave area.. Example: * open one pidgin and 20 terminals. the pidgin window changes it size all the time (not all slave windows have the same size). This is because: 1- with resizehints enabled it is possible to loose windows (located outside the screen) 2- without resizehints . the latest window in the slave area heres a shot without resizehints: http://news.nopcode.org/dwm52.png if i close some some terminals the latest window height (pidgin) is reduced, and after some more closed terminals it gets bigger again. is this how it should be? looks quite anoying to me. --pancake
[dwm] more problems with 5.2
i had similar ones with 5.0..but in 5.2 it performs worst. for resizing a window with alt+rightclick the client sometimes loses the focus and makes the cursor go outside the window.. btw for the rest (a part from these two bugs) i found dwm 5.2 a bit faster and more consistent :) --pancake
RE: [dwm] Re: keyboard input focus
What are you talking about? what is client switching for you? Which keys are you using? If youre talking about the default zoom and alt,tab keys. In dwm theres no random functionailty,but you can make a patch if you want :P. Check your conf and feed us with more concise information. But i think youre missing something - original message - Subject:[dwm] Re: keyboard input focus From: bill lam [EMAIL PROTECTED] Date: 2008/09/09 05:26 On Tue, 09 Sep 2008, bill lam wrote: I found that mouse click can switch current client (as shown in the top statusbar), but the keyboard input focus does not get switched. Is this bug? To be concise, the behaviour is random, sometimes it works. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Re: [dwm] slowness in moving windows OR vlc/mplayer crash
a friend of me had similar crashes with ubuntu 8 and fglrx when the screensaver was popping up. btw he is using gstreamer and have no problems for playing media. On Tue, 2008-09-09 at 14:55 +0200, Albert Cardona wrote: Hi all, I have an ATI FireGL and I use the fglrx binary driver, in ubuntu 8.04. That said: With these two arguments in the Section Device of xorg.conf: Option Textured2D On Option TexturedXrender On ... dwm drags windows around very slowly. But if those parameters are not there, then VLC and mplayer crash when opening any movie. Did anyone run onto the issues above? Albert
Re: [dwm] Asustek EEE PC 1000 Atom 1GB 40G SSD Linux Black
i would prefer a mips one f.ex: gdium.com, hvsco.com On Fri, 2008-09-05 at 11:34 +0200, Engin Tola wrote: I was also thinking about buying one and would be very interested in a programmers point of view. There are reviews around but I'll be using it daily to code and therefore want to hear a programmers opinion. Anselm R Garbe [EMAIL PROTECTED] writes: What do people think about such an EEE PC as low budget option to run dwm on? Any experiences already if the screen is big enough for daily work? I had an opportunity yesterday to try one, and I must admit I'm keen to order one. The keyboard and keys have surprisingly proper size. Kind regards, --Anselm
[dwm] what about 'st'?
Hey arg! what's on with ST? i'm really interested and looking forward the advances in the minimalistic terminal implementation. Do you plan to make some more advances? I have found something quite useful when working with lot of terminals that is having different background colors depending on the task they are designed to be. But currently i just change the background color of vim and use this to differentiate them. another stuff would be like changing the background color of the terminal depending on the focus. I see no terminal able to do this in a simple way. --pancake
[dwm] suckless mail
I have been thinking these days on writing something suckless for managing my mail. I don't know if any of you is happy with any mail client, but I do not feel comfortable with any of them. mutt is quite nice but is 'big' and there are so many open bugs like closing the connections when receiving a window-resize event. which is quite anoying.. sylpheed have some socket-locking problems, evolution is awesomely bloated and is not very nice when resizing the window. This is why I am thinking on writing a set of small tools for managing the mail in a minimalistic way. What I have in mind is something more simple that can be done without many LOCs and splitting the problem in multiple programs will achieve a better. - pop3 client - imap client - smtp client - mbox/mdir client with support for mime - frontend shell or so using inotify() on Linux is quite simple to get notifications of new files in certain directories, so it will be possible to get the events of new mails using maildir or mbox in this way. Extracting the headers of a mail is something really simple with any basic shell tools. Im currently out of time for coding such stuff, but I think that maybe there's more people interesting on finding an almost decent solution for reading the mail without those complications. The frontend for the mail should be able to follow mail threads, sort by date or grep by contents. following these concepts shouldnt be hard to create an usable frontend for the web or a phone/pda...squirrelmail is also to blame...and writing a simple cgi using these tools will be quite simple and useful. I hope this brainstorming helps somebody to start coding them. What do you think? are you happy with your MUA? --pancake
Re: [dwm] grab
On Wed, 6 Aug 2008 13:33:42 -0700 Evan Gates [EMAIL PROTECTED] wrote: I love dmenu, and just for the hell of it wanted a similar program, that didn't display anything. So I wrote grab (more like copied the code I needed from dmenu). It grabs all key presses until the user hits enter or escape, and then prints out whatever was typed. It's not foolproof, it's not very well tested, but it works for me. I run it from dwm the same way as dmenu. Have fun and do what you will with it. -Evan P.S. compile with gcc -lX11 why not just add a flag to dmenu to perform in this way?
[dwm] Coding styles
I wrote a random list of tips for coding (mostly in C) http://news.nopcode.org/miau/wk/BadCoding If you have some ideas/missing tips i'm open for discussion :) --pancake
Re: [dwm] Coding styles
precompilation checks for generating include files, documentation, hirearchy and so. which is nice imho, because with a C parser you cannot express all the pre-post conditions of a function. And having tools like these is good for software quality. I heared from someone that there was some software research which concluded, that usually all source code is read by at least 8 different people during the time -- so commenting hidden facts is really good. Yeah, but this should only happen on privative software. Include files are for signatures I know one exception here, extensions to dwm's config.h -- but I won't change it ;) and I agree with you in this case ;) Dont include more than once Use #ifndef _INCLUDE_FOO_H_ ; #define _INCLUDE_FOO_H_ to avoid including the same file twice. I hate this rule. Good software should not need these hacks (or #pragma once as alternative). It is a sign that something is seriously broken, if you include a header file multiple times, and you should refactor it. This is no issue for dwm, but you will notice that all wmii-related projects aren't affected by this issue. Sometimes is hard to do this on big projects. but sure it needs refactoring. But there's lot of people writing really weird hacks because they dont know this trick. Uppercase/Lowercase functions Agreed, though I even tend to minimize the underlines if possible. for huge apis is better to be more verbose-friendly. The GTK coding standards are really good from the hirearchy pov. and Vala is the best example of how to take profit of it :) Dont use labels Every switch-case is a label ;) I would consider labels ok as long as they are local inside a function and rarely used, eg. for error checking. Dozens of return's will make the machine code even worse, than a simple error goto. But use them with care. Yes, only for kernel stuff and some error checking conditions. Don't read this document Agreed, except that I like the UINT/BOOL/ etc stuff from MS. arg! :) --pancake
Re: [dwm] Coding styles
On Thu, 2008-07-31 at 17:00 +0200, markus schnalke wrote: [2008-07-31 16:41] pancake [EMAIL PROTECTED] I'll try to add some more precisse descriptions on the points :) and please use more easy words and less irony That makes the document clearer and so more useful. On Thu, 2008-07-31 at 14:14 +0100, Anselm R Garbe wrote: Mixed tab/spaces++ I use tabs for indentations and spaces to align things beginning at the indentation level, eg in multiline constructs or sometimes in variable declarations if it looks easier on the eyes. Though the latter case can't be found in open source stuff I wrote. Uhm. i dont like to mix spaces and tabs for indenting. Is better to let this job to the editor. And keep everything in tabs (smaller source files and easier editor integration) The mixing arg described has nothing to do with indention. There is clear separation: - tabs are for indention - spaces are for nice alignment of wrapped lines Editors should not try to align wrapped lines or similar stuff, cause they cannot do that properly. These spaces (after the indention tabs and before the wrapped part of the long line) should be controlled by the human. yes i agree with that. it was a missinterpretation :) On Thu, 2008-07-31 at 14:04 +, nilp wrote: On Thu, Jul 31, 2008 at 01:37:22PM +0200, pancake wrote: I wrote a random list of tips for coding (mostly in C) http://news.nopcode.org/miau/wk/BadCoding If you have some ideas/missing tips i'm open for discussion :) --pancake I'd remove the Comments are for humans paragraph -- code commenting is good, and sacrificing it for less lines of code (?) is IMO stupid and wrong (though you could add something about commeting _what_ code does, not _why_). Also, adding link to The Art of Unix Programming would be nice, there's lot of good points about code complexity etc. (100% must-read IMHO). We can maybe maintain this enumeration in the suckless wiki. I dont say that removing comments is good. And remove them to reduce LOCs is stupid. comments have nothing to do with code. The problem is that there're lot of unnecessary comments. And i found lot of them outdated when they are big comments, and sometimes is better change some variable names and remove a comment than having an unreadable code with a very explicative comment. I am also thinking on links to coding horror web blog and other I read few time ago from djb and so. I understand that the language can be a bit agressive sometimes, but it was just a braindump, it needs to be cleaned up. The english is not as good as it should O:) maybe we can start with a minimalistic replacement for ED and write a frontend for it a la vim with shell access for extensibility. it would be great to have a minimalistic vim replacement :) PD: http://news.nopcode.org/miau/wk/UseED --pancake
Re: [dwm] Coding styles
On Thu, 2008-07-31 at 17:28 +0200, Kai Großjohann wrote: I don't understand why IDEs are considered so bad. IDEs make it easy to shoot yourself in the foot (by clicking with the mouse, no less). But all C programmers know that it works to just avoid shooting yourself in the foot. Also, there may be bad IDEs. I use Eclipse for Java programming, with viPlugin. im some bad times of my life i have been using eclipse with a home-made crack for viplugin. I can look for it if you want. BTW, I never understood why viplugin is proprietary, paysoft and full of bugs. Its just anoying to have to pay for that so bad implementation. I have used javascript implementations for replacing textareas in webs emulating vi with more features than viplugin and for free. Regarding lock-in: Our build infrastructure is based on make, and I integrated Eclipse and the build infrastructure. This means all projects can be built using make. There is no lock-in. (In fact, some team members prefer Emacs, and some use vi. We all collaborate on the same projects.) Yeah, eclipse is a very standard tool. Using ANT is far more better than using make. IMHO make is also a weird tool that should be replaced anytime. Current GNU implementation is full of unnecessary stuff and it highly depends on the shell so, it breaks portability. Regarding power of the editor: With viPlugin, I get enough basic editor functionality so that I do not feel restrained. Yet, the Eclipse Java editor knows Java syntax and offers a much higher level of source code editing. Specifically, we have refactoring and quickfix support, and code completion and navigation. I miss lot of functionalities. And the bugs on it makes sometimes loss time trying to fail into insert mode. Quickfix means that the editor recognizes common compilation problems and offers corrections. I use that to speed up typing: I say String x = someObject.someMethod(someArg);, then wait for the editor to flag the compilation error, then let it correct the type of x. This means that I don't have to remember the exact type that someMethod returns, and also I get the import statement for free. My guidelines are mostly based on C, I know that coding for btw you can do all the same stuff inside vim with code autocompletion (there is an elcipse backend for vim), syntax highlighting, automatic indentation, etc.. I wrote some shellscript to replace all these features from the commandline to get list of methods, find strings on source files, enable/disable debug printfs, etc.. Most of these features are easy to implement in the shell and give you more control on the source than using the common user interfaces for code autocompletion and so. But I understand that maybe I'm a big freak on this. I'm just offering my POV over these topics. not trying to change the mind of anybody or anything else :) --pancake
Re: [dwm] DWMII layout for DWM 5.1, a better integration !!!
On Wed, 2008-07-30 at 13:14 +0200, QUINTIN Guillaume wrote:
Hi all,
This is the DWMII layout for DWM 5.1. It is a layout in the dwm way this
time ! The only modification is within the Client struct and holds in 11
chars : int dwmii;\n. This modification prevents from having a more
complex algorithm and more lines of code. The last release of my layout
for dwm 5.0.1 contained bugs that I found later. Now, I think it's bug
free and I review the code for cleaning ! I also added the row layout
because I missed it. Feel free to try it and send me all your comments.
Kind regards,
QUINTIN Guillaume.
Hi Quintin!
Looks you're working hard to make dwmii fit more in the dwm concepts.
I am currenty a dwm addict, and see no points for using the wmii
approach, but it is an interesting area to play and maybe is somebody
interested on it.
I'll try it :)
Just some comments:
- If its just a layout. distribute it in a separate file and include it
from config.h.
- Write the instructions in the header of your .c file to add the int
dwmii in dwm.c manually.
- I dont see any point for having a function called
dwmiinoinfiniteloop
- conditional and loop brackets should be in the same line (for () {...)
and if () { instead of for()\n{.
- upload it, give an url and update the wiki :)
Fix those minor tips and I'll play with it this night at home!
--pancake
plain text document attachment (dwmii.patch)
--- dwm.org.c 2008-07-30 12:48:52.0 +0200
+++ dwm.c 2008-07-30 12:56:10.0 +0200
@@ -91,6 +91,7 @@
Client *next;
Client *snext;
Window win;
+ int dwmii;
};
typedef struct {
@@ -201,6 +202,12 @@
static int xerrordummy(Display *dpy, XErrorEvent *ee);
static int xerrorstart(Display *dpy, XErrorEvent *ee);
static void zoom(const Arg *arg);
+static void dwmiitoggle(const Arg *);
+static void dwmiiinsertafter(Client *,Client *,int);
+static void dwmiikeypressed(const Arg *);
+static void dwmiinoinfiniteloop(void);
+static void dwmiilayoutcol(void);
+static void dwmiilayoutrow(void);
/* variables */
static char stext[256];
@@ -1742,3 +1749,127 @@
XCloseDisplay(dpy);
return 0;
}
+
+void dwmiitoggle(const Arg *arg)
+{
+ if ( !lt[sellt]-arrange || (sel sel-isfloating) ) { return; }
+ Client *firstclients = nexttiled(clients);
+ if ( sel == firstclients ) { return ; }
+ if ( sel-dwmii ) { sel-dwmii = 0; return; }
+ sel-dwmii = 1;
+ arrange();
+}
+
+void dwmiiinsertafter(Client *c,Client *after,int dwmii)
+{
+ if ( !c || !after ) { return; }
+ detach(c);
+ c-dwmii = dwmii;
+ c-next = after-next;
+ after-next = c;
+}
+
+void dwmiikeypressed(const Arg *arg)
+{
+ if ( !lt[sellt]-arrange || (sel sel-isfloating) ) { return; }
+ Client* firstclients = nexttiled(clients);
+ if ( ( (arg-i == XK_Up) (lt[sellt]-arrange == dwmiilayoutcol) ) ||
( (arg-i == XK_Left) (lt[sellt]-arrange == dwmiilayoutrow) ) )
+ {
+ if ( sel-dwmii ) { return; }
+ Client *t = firstclients,*s = 0;
+ for( ; t != sel ; s = t,t = nexttiled(t-next) );
+ sel-dwmii = s-dwmii;
+ dwmiiinsertafter(s,sel,0);
+ }
+ if ( ( (arg-i == XK_Right) (lt[sellt]-arrange == dwmiilayoutcol) )
|| ( (arg-i == XK_Down) (lt[sellt]-arrange == dwmiilayoutrow) ) )
+ {
+ Client *t = nexttiled(sel-next),*s = 0;
+ if ( !t ) { sel-dwmii = 1; arrange(); return; }
+ int i = 2;
+ for( ; t ((i -= ( t-dwmii ? 1 : 0 )) 0) ; s = t,t =
nexttiled(t-next) );
+ if ( sel-dwmii ) { t = nexttiled(sel-next); if ( t ) {
t-dwmii = 1; } }
+ dwmiiinsertafter(sel,s,( i == 2 ? 1 : 0 ));
+ }
+ if ( ( (arg-i == XK_Down) (lt[sellt]-arrange == dwmiilayoutcol) )
|| ( (arg-i == XK_Right) (lt[sellt]-arrange == dwmiilayoutrow) ) )
+ {
+ Client *t = nexttiled(sel-next);
+ if ( !t || t-dwmii ) { return; }
+ t-dwmii = sel-dwmii;
+ dwmiiinsertafter(sel,t,0);
+ }
+ if ( ( (arg-i == XK_Left) (lt[sellt]-arrange == dwmiilayoutcol) )
|| ( (arg-i == XK_Up) (lt[sellt]-arrange == dwmiilayoutrow) ) )
+ {
+ if ( sel == firstclients ) { return; }
+ Client *t = firstclients,*s = 0,*u = 0;
+ for( ; t != sel ; s = t,t = nexttiled(t-next),u = ( t-dwmii ?
s : u) );
+ if ( !u ) { return; }
+ if ( sel-dwmii ) { t = nexttiled(sel-next); if ( t ) {
t-dwmii = 1; } }
+ dwmiiinsertafter(sel,u,0);
+ }
+ arrange();
+}
+
+void dwmiinoinfiniteloop(void)
+{
+ Client* firstclients = nexttiled(clients),*t = firstclients;
+ for( ; t !t-dwmii ; t = nexttiled(t-next) );
+ firstclients-dwmii = 1;
+ if ( t (t != firstclients) ) { t-dwmii = 0; }
+}
+
+void dwmiilayoutcol(void)
+{
+ Client
Re: [dwm] Being not so elitist
For the meantime the statement has been restored in the original place ;) ow yeah ;)
[dwm] horitzontal split layout
I have written a new layout which i find very useful in two situations:
- Vertical panoramic screens (9:16)
- Working with terminals and dont want to loss the width.
The layout is quite simple and integrates very well with monocle. So it
can be used as a 'window selector' before switching to monocle layout.
Here's the layout code:
http://news.nopcode.org/hsplit-5.1.c
And my config:
http://news.nopcode.org/dwm-config.h
void
hsplit() {
Client *c;
unsigned int i, n;
for(n = 0, c = nexttiled(clients); c; c = nexttiled(c-next), n++);
if (n)
for(i = 0, c = nexttiled(clients); c; c = nexttiled(c-next),i++)
resize(c, 0, (showbar?bh:0) + ((wh/n)*i), ww-(c-bw1),
(wh/n)-(c-bw1),0);
}
My configuration is:
static Layout layouts[] = {
/* symbol arrange function */
{ [=], hsplit },/* first entry is default */
{ [M], monocle }, /* first entry is default */
{ []=, tile },/* first entry is default */
{ , NULL },/* no layout function means floating behavior
*/
};
...
{ MODKEY, XK_t, setlayout, {.v =
layouts[2]} },
{ MODKEY, XK_m, setlayout, {.v =
layouts[1]} },
{ MODKEY, XK_e, setlayout, {.v =
layouts[0]} },
{ MODKEY, XK_space, setlayout,
{0} },
You can use 'meta'+'space' to switch between monocle and hsplit
PD: I think that the patches available in the wiki are a bit outdated and needs
to be
upgraded to the 5.x series. Well. some of them are outdated like my
mouseontitle which
is not useful anymore with 5 because the feature is included in mainstream. Do
you want
to maintain old patches keeping the support for old dwm versions?
Feedback is welcome :)
Enjoy!
Re: [dwm] Apps Can't open X display
On Wed, 2008-06-25 at 03:40 -0700, Leandro Chescotta wrote: Hi! im having a problem with various apps that doesn't run saying that can't open DISPLAY, scrot for taking screenshots for example, im now using dwm and before i use wmii, with wmii i can take screenshots with no problem: [EMAIL PROTECTED] 13 ~]$ scrot -d 5 -q 75 -t 25 -c ~/desktop.jpg giblib error: Can't open X display. It *is* running, yeah? and: [EMAIL PROTECTED] 42 ~]$ n Gtk-WARNING **: cannot open display: i suspect it has something to do with the way i have my .xinitrc... #!/bin/sh # ~/.xinitrc # dwm while true do echo '|' CPU:$(get_cputemp Core0)C/$(get_cputemp Core1)C '|' Ram:$(get_freemem)/Swap:$(get_freeswap) '|' /downloads:$(get_diskinfo sdb1) /sdd1:$(get_diskinfo sdd1) /sde1:$(get_diskinfo sde1) /cdrom:$(get_cdrominfo cdrom) '|' PCM:$(get_volume PCM)% '|' $(date +'%R %d/%m/%Y') sleep 2 done | dwm i think it has to do with DISPLAY=my_host:0 exec dwm in DISPLAY is set automatically. you dont have to define it manually. the X server allocates it for you. btw if you want to force it (nosense) you can do it in this way: DISPLAY=:0 no need to define hostname. hostname is only for remote connections, and most of X servers currently run without TCP/UDP support. hope this helps /etc/X11/xinit/xinitrc as says here - http://wiki.archlinux.org/index.php/Dwm but i dont know if i need to edit that file because my says twm, i think that is the default, and if i have an .xinitrc file at my home dir, it jumps that file, right? # Post Installation After you have downloaded and installed dwm using pacman you go ahead and get started using it. It should be noted that currently dwm is configured through its source. If you simply download and install it, then you'll be given the default setup. Fire up your favorite text editor and add dwm to your xinitrc script: su nano -w /etc/X11/xinit/xinitrc Your's should look something like this: #!/bin/sh # $XConsortium: xinitrc.cpp,v 1.4 91/08/22 11:41:34 rws Exp $ userresources=$HOME/.Xresources usermodmap=$HOME/.Xmodmap sysresources=/usr/X11R6/lib/X11/xinit/.Xresources sysmodmap=/usr/X11R6/lib/X11/xinit/.Xmodmap # merge in defaults and keymaps if [ -f $sysresources ]; then xrdb -merge $sysresources fi if [ -f $sysmodmap ]; then xmodmap $sysmodmap fi if [ -f $userresources ]; then xrdb -merge $userresources fi if [ -f $usermodmap ]; then xmodmap $usermodmap fi # start some nice programs exec dwm When I installed it on my laptop I had to use the following line: DISPLAY=my_host:0 exec dwm instead of exec dwm Finally, now all you need to do is startx at the command line. Enjoy. # but i don't understand that if i edit that file, any user that logins will have dwm as wm? or why that file and not my ~/.xinitrc? my /etc/X11/xinit/xinitrc: # #!/bin/sh # $Xorg: xinitrc.cpp,v 1.3 2000/08/17 19:54:30 cpqbld Exp $ userresources=$HOME/.Xresources usermodmap=$HOME/.Xmodmap sysresources=/etc/X11/xinit/.Xresources sysmodmap=/etc/X11/xinit/.Xmodmap # merge in defaults and keymaps if [ -f $sysresources ]; then xrdb -merge $sysresources fi if [ -f $sysmodmap ]; then xmodmap $sysmodmap fi if [ -f $userresources ]; then xrdb -merge $userresources fi if [ -f $usermodmap ]; then xmodmap $usermodmap fi # start some nice programs twm xclock -geometry 50x50-1+1 xterm -geometry 80x50+494+51 xterm -geometry 80x20+494-0 exec xterm -geometry 80x66+0+0 -name login # THANKS!
Re: [dwm] debugger poll
On Wed, 2008-06-11 at 09:14 -0400, Ross Mohn wrote: 1. What debugger do you use for C programming? 2. What debugger do you use for Curses C programming? I recommend you to run the program in one terminal and the debugger in another one. or just use radare with tm (terminal mixer).
Re: [dwm] beta dwm-5.0
On Wed, 2008-06-11 at 09:13 -0500, Kevin Monceaux wrote: I'm a potential new DWM user who feels the same as the above. I've been playing musical window managers recently trying to find one that I really like. The main things I'm looking for are: musical window managers?!? is this somewhat synestesic? rez-like?
Re: [dwm] debugger poll
On Wed, 2008-06-11 at 17:21 +0200, Matthias-Christian Ott wrote: markus schnalke [EMAIL PROTECTED] wrote: Ross Mohn [EMAIL PROTECTED] wrote: 1. What debugger do you use for C programming? 2. What debugger do you use for Curses C programming? printf() :-) +1 But in my personal programmes I make frequent use of assert() for pre- and (sometimes) post-conditions which is quite useful in combination with gdb. For curses programming you could use log files or so. or just use stderr fprintf(stderr, log message...); $ ./your-app 2 log-file
[dwm] patch from pkgsrc
Maybe we can make happy the makefile for pkgsrc. This is the patch in
the current pkgsrc tree. I understand that all these vars can be changed
as make arguments. But why not let them be altered with environ vars or
so? adding so many flags (-std -pedantic, ... makes it less portable
(for other compilers), so i will encourage to use ?= instead of = for
this kind of options.
NetBSD/pkgsrc politics on patches are to try to maintain as less as
possible, sending them to the project for discussing :)
[EMAIL PROTECTED]:/usr/pkgsrc/wm# cat dwm/patches/patch-aa
$NetBSD: patch-aa,v 1.3 2007/11/25 23:23:25 wiz Exp $
--- config.mk.orig 2007-11-21 20:18:41.0 +
+++ config.mk
@@ -4,19 +4,18 @@ VERSION = 4.7
# Customize below to fit your system
# paths
-PREFIX = /usr/local
-MANPREFIX = ${PREFIX}/share/man
+MANPREFIX = ${PREFIX}/${PKGMANDIR}
-X11INC = /usr/X11R6/include
-X11LIB = /usr/X11R6/lib
+X11INC = ${X11BASE}/include
+X11LIB = ${X11BASE}/lib
# includes and libs
INCS = -I. -I/usr/include -I${X11INC}
-LIBS = -L/usr/lib -lc -L${X11LIB} -lX11
+LIBS = -lc -L${X11LIB} ${COMPILER_RPATH_FLAG}${X11LIB} -lX11
# flags
-CFLAGS = -Os ${INCS} -DVERSION=\${VERSION}\
-LDFLAGS = -s ${LIBS}
+CFLAGS += ${INCS} -DVERSION=\${VERSION}\
+LDFLAGS += ${LIBS}
#CFLAGS = -g -std=c99 -pedantic -Wall -O2 ${INCS} -DVERSION=
\${VERSION}\
#LDFLAGS = -g ${LIBS}
@@ -26,4 +25,4 @@ LDFLAGS = -s ${LIBS}
#CFLAGS += -xtarget=ultra
# compiler and linker
-CC = cc
+#CC = cc
[dwm] meta with mouse button
I think that it will be really nice if it was possible to define a secondary META key binded to a mouse button. Maybe is not useful for 5 button mouses (3+wheel), but for the ones having 7 or more it shuold be cool, so with a single hand you will be able to drag or resize windows. --pancake
[dwm] center scaling
This is just a tip I found curious while using claws-mail with dwm: The about dialog is always centered on screen, so if you try to resize it, it will grow for all the borders in the same way (X pointer and window border are not in the correct position. btw thinking about this feature i was thinking that this window resizal is optimal so, you will have to move the mouse the half of the other way (which is cool for touchpads). But you loss a bit of positioning if you try to tile floating windows. I understand that the changes required for this will not be that minimalistic, so i dont see the point of having this in mainstream, but just as a curious note :) or something to think on and i wanted to share with you. btw...mouse-related patches are not easy to be modular on current dwm. Do you plan to do it for the next release? together with the 'mouse-clicks' patch? --pancake
Re: [dwm] beta dwm-5.0
On Tue, 2008-05-27 at 10:11 +0200, Anselm R. Garbe wrote:
Well I see good reasons to abstract some mouse button hooks
into the bar. I'm open for proposals, but I think let's postpone
this idea for 5.1
Sweet.
I think that the current work done in awesome is a derivate of a dwm
patch that does that. But we can do something like:
BarClick clicks {
{ 1, zoom, NULL },
{ ... },
};
btw i also make the mouse wheel work when cursor in position 0,0.. maybe
we should think in how to split the statusbar to specify where this
event should be handled:
- clicking in tags (currently supported and no way/sense to change
this)
- clicking in message area
- clicking in title area
- clicking in the screen corner (X11 limits)
So this can be defined inside the BarClick typedef struct as an integer
filled from a enum.
--pancake
Kind regards,
Anselm
On Mon, May 26, 2008 at 07:29:01PM +0200, yy wrote:
2008/5/26 pancake [EMAIL PROTECTED]:
...
For those new users..my patch(which is currently removed from the web)
do something like:
1: zoom
2: new terminal
3: kill
4: next
5: prev
What do you think about this?
--pancake
For me, next/prev with the wheel is essential to zoom (I use the
middle button) and when in maximized or floating mode. I have button1
to move windows (wrapping the pointer to the upper-left corner) and
button3 to resize. I think our patches are very similar, but it could
be easily defined in config.h, in the same way than keys are (and
probably sharing some code). BTW, my reasons to use the mouse are:
1. acme/sam/rio
2. gimp
3. I smoke too much
It is also more comfortable when you are with more people.
IMO, it is somewhat stupid needing two hands to do something like
moving a window.
--
- yiyus || JGL .
Re: [dwm] way towards 5.0
The floating layout is totally useless when it comes to mouseless usage and even with the mouse there is no window manager that provides such weak functionality to manage floating windows. I disagree. I think the floating mode is as usable as in traditional WMs -- which functionality are you missing? I think he talks about the moveresize patch. http://www.suckless.org/wiki/dwm/patches/moveresize
[dwm] lost keyboard with dmenu
I usually install new versions of applications in my PREFIX, and dmenu needs to update most of time the cache. When this happens, dmenu takes the keyboard input and it's impossible to open a terminal or type things in a chat, etc.. The 'esc' key is not handled directly, so you have to wait until the running program finishes. This is quite anoying, I understand that I should do something like a static cache updated by me manually, and I will not suffer this problem. But maybe sounds reasonable to make dmenu not capturing the keyboard until something is readed from stdin. Just to make it more responsive. --pancake
Re: [dwm] command line tool to notify()
On Wed, May 07, 2008 at 01:15:15PM +0200, pancake wrote: what do you think about writing a tool for commandline to generate a notify() event to the X. This way we can call it from any program (irssi, mutt, our own shellscripts) and notify the tag where they are. it shouldnt be hard to do. but i have not many time these days :( I'd prefer a tiny input language read from stdin. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 my way is simpler and more portable between WMs. implementing a language based on strings is not that lightweight. imho stdin should remain as it is.
[dwm] bloq may used to ignore keybindings
Recently I tried wmii (for a few minutes :P) and notice that if I press bloq.mayus I was able to use alt-1, alt-2 to change between the tabs in firefox. This makes me think that we can probably take the same idea for dwm to make it ignore the keybindings. Maybe we can also let configurable this bloq. key in config.h and use any other locked key for this. --pancake
Re: [dwm] [OT] minimalistic bbs/forum
you don't like mailing lists? I can't see the use of a forum... -- hiro I love mailings and i dislike forums, but is what my users reclaim... and i dont want to install a fucking buggy/bloated phpbb or drupal. the nice thing of php is that is very common to find servers with php support and apps are easy/fast to write. and...I don't want ruby burning my cpu :) Any other alternative? --pancake
[dwm] mouse limits
Currently I have a dual head setup on my work which I find quite lovely. It is based on two dell monitors (4:3, 16:9), one of them supports an external VGA input. So i have added two geoms toggleable with control+alt+space DEFGEOM(dual2, 0, 0, sw,0,bh, sw, 1050-bh, wx, wy, mfact*sw, 1025-bh, mx+mw, wy, ww-mw, wh, wx, wy, ww, wh) DEFGEOM(single2,1280, 0, 1680, 1280, bh, 1680, sh-bh, wx, wy, mfact*sw, 1050-bh, mx+mw, wy, ww-mw, wh, wx, wy, ww, wh) This way I can stretch all the windows to a single monitor when I switch the left monitor to a single one. This works pretty fine and I'm happy with it, but I would like to know if it is possible to make dwm limit the mouse movement (via #define MOUSELOCK 1 or so). This way I will not be allowed to move the mouse outside the area defined by the GEOM. The only problem I found with this layout is when I use floating windows. Because they are not handled by the geoms. And maybe we can make the floating windows be relative to wx. What do you think? --pancake
Re: [dwm] ii best practices
i think scrollz already have this. Anselm R. Garbe [EMAIL PROTECTED] wrote: On Tue, Apr 01, 2008 at 03:24:44PM +0200, Matthias-Christian Ott wrote: I want to start using ii for irc. What discouraged me from doing so was a proper input method. Currently I know 2 methods to effectively input text to ii: vim and dinput. I don't like both for some reason. Do you have any best practices for using ii? echo(1), I'm not using ii but sic, but I usually create a fifo for sending input to sic using echo or sometimes cat(1), if I plan to have longer conversations than the usual hello. But this would require me to write something like each time I want to send something to the channel: $ echo 'Hello' fifo # or $ cat fifo Hello^D Of course you could do: $ while true; do cat fifo; done But what about this: +---+ | | | urxvt | |tail -f fifo | | | | | |...| | input | +---+ The basic idea is to embedd the urxvt window in another window which also embedds an input window. The input window could be urxvt running a small programme or small X11 programme reading input and writing to the fifo. This is much nicer for tiling and feels more like an irc client. You could do this with screen of course. Any other ideas? Regards Matthias-Christian
Re: [dwm] ii best practices
pancake [EMAIL PROTECTED] wrote: i think scrollz already have this. But scrollz is an ununix irc client. but scrollz is composed by two programs - a terminal control with the described functionality - an irc client that uses the terminal control tool imho the terminal control is what you described in the other mail
Re: [dwm] ntile layout for dwm hg tip
Io Nibble :)
I have tested your latest patch in my dwm 4.9 and configured xinerama properly
(thanks)
And I can say that for xinerama we will probably need to adapt it to support
also
vertical tiling. Using horitzontal it's mostly a waste of space on big screens.
But the port works fine :)
I would like to see something like vntile and hntile or just a toggle for it.
What do
you think about this?
--pancake
On Sun, 30 Mar 2008 01:41:06 +0100
Nibble [EMAIL PROTECTED] wrote:
Hi there,
I have adapted the nmaster ntile layout for the current dwm
hg tip. Maybe it could be useful for someone else.
You should modify config.h to include (after setting RESIZEHINTS):
#define NMASTER 1
#include nmaster.c
Add a new ntile layout
Layout layouts[] = {
...
{ -|= , ntile },
...
};
and, finally, two new keybinds:
{ MODKEY|ShiftMask , XK_j , setnmaster , +1 } ,
{ MODKEY|ShiftMask , XK_k , setnmaster , -1 } ,
I have adapted neither cpt nor tilecols. Of course, thanks for your patch
pancake.
Kind regards,
Nibble
Re: [dwm] Fibonacci in 4.8?
can you publish the fibonacci for =4.8 in the web?
On Wed, 26 Mar 2008 17:18:06 +0100
Valentin [EMAIL PROTECTED] wrote:
Thank you, that already removed a lot of errors, now I just have this
one left:
fibonacci.c:13: error: ‘Client’ has no member named ‘ismax’
The corresponding line is here:
for(i = 0, c = nexttiled(clients); c; c = nexttiled(c-next)) {
-- c-ismax = False;
if((i % 2 nh / 2 2 * c-border)
I commented it, and it seems to be working fine for now, is there some
situation where this change could have negative results?
Also, I can't find anything that seems to ban/unban anything, and
nexttiled() does get used, so I suppose there's no need to change
anything for that either.
Cheers, Valentin
On Wed, 26 Mar 2008 16:36:30 +0100
Anselm R. Garbe [EMAIL PROTECTED] wrote:
wax is wx
way is wy
waw is ww
wah is wh
now.
Though you might also check if that version you are trying to
adopt does ban/unban stuff -- if so, remove those portions
because that's done in arrange() now.
Also, use the nexttiled()-based loop through the client list,
there is no need to iterate over all clients anymore.
Kind regards,
Anselm
Re: [dwm] found a nice way to do the setgeom stuff
On Tue, 18 Mar 2008 12:18:21 -0700
[EMAIL PROTECTED] wrote:
The new setgeom stuff is nice, great work!
Here's a bottom stack setup:
nice! :)
Geom...
DEFGEOM(bottom, 0, 0, sw, 0, bh, sw, sh-bh, wx, wy, sw, 0.55*wh, wx, mh,
ww, wh-mh, wx, wy, ww, wh)
You missed the bar
DEFGEOM(bottom, 0, 0, sw, 0, bh, sw, sh-bh, wx, wy, sw, 0.70*wh, wx, mh+bh, ww,
wh-mh, wx, wy, ww, wh)
Layout...
{ TT, bottom },
this is Geoms
Nice!
--pancake
Re: [dwm] dwm-4.8 / dmenu-3.5 / slock-0.8
On Thu, 13 Mar 2008 23:22:41 -0400 Ralph E. Carter [EMAIL PROTECTED] wrote: pancake- Togglebar and mwfact are essential, and they are working great. Thanks. Also, I like your color scheme too; I might keep it. Thanks! The default blue looks too hard for my eyes =), btw I'm pretty sure the mwfact and togglebar codes can be enhaced, but they are functional, and this is just what I need. I have more ideas to do and patches to port. I'll feed the ml. When there is only one window, and togglebar removes the bar, a gap remains. If the window is floating, it doesn't move, and a gap is left where the bar was removed. If it isn't floating, the window moves up, creating a gap at the bottom. (The window is not resizing following the removal of the bar.) With two or more windows open, they resize, leaving no gap. I don't fixed that problem because it is a dwm bug I notified in some previous mails. I don't care about pixel-up / pixel-down problems atm. I update my config. take a look on it :) http://news.nopcode.org/dwm/config.h --pancake
Re: [dwm] still simplicity or featureitis?
On Fri, 14 Mar 2008 17:26:21 +0100 Joerg van den Hoff [EMAIL PROTECTED] wrote: and contrary to the initial post I'd say `monocle' is very useful indeed. but 'vertical tile' does not make sense, at least not on a single monitor, not for me in any case. (by- the-by, if 'vertical' is the 'new' tile and 'horizontal' is the standard tile, I'd say the names are swapped: in the standard tile the windows are vertically tiled one above the other, so why is this the 'horizontal tiling' ...) why not implement a master and tile area inside the tiling area? I mean...more than two vertical clients in the stack area for a single monitor (and most of the dual screen uses) will go. This is my idea: +--+---++ | | || | | || | | || +--+---++ Splitting this in two monitors can become into a two nice possibilities: +--+ +---+ | || | | | || |---| | || | | +--+ +---+ or just a master in the first screen and a 'dwm like tile' in the second. This concept is somewhat a dwm layout inside a dwm layout and don't know if this is a good idea, or it needs more flexibility, but it fits very well with the ideas in 4.8. The nmaster for more than two clients in the master area is useless, so we can just implement a two-client tile in master area as another layout. What I really miss is the cpt patch :) Anselm: what do you think about this idea? --pancake
Re: [dwm] still simplicity or featureitis?
On Thu, 13 Mar 2008 17:49:10 +0100 Anselm R. Garbe [EMAIL PROTECTED] wrote: On Thu, Mar 13, 2008 at 11:52:20AM -0400, Jeremy O'Brien wrote: On Thu, Mar 13, 2008 at 01:48:49PM +0100, Szabolcs Nagy wrote: On 3/13/08, markus schnalke [EMAIL PROTECTED] wrote: Personally, I've switched to wmii until dwm reaches a more usable state again... The changes are just too much for me to get used to and I feel like it has gone in a backwards direction... Well, this is not true for at least 2 weeks imho. Hey! Don't be tragic ;) The change between 4.7 and 4.8 is going to be more drastic than expected originally, but don't panic, you can still using 4.7. The development direction is imho going in a more flexible way and this will make dwm more flexible and extensible. The current config.h complexity can be easily reduced for single user monitors and the current idea permits to extend without increasing complexity extremely. We will probably need to rewrite the layouts and other stuff to match this new paradigm which I don't see definitive, because of the limitation of the master area that makes nmaster like layouts more hard to port. BTW I see some benefits on this new paradigm, but I cant test xinerama atm, and I understand the comminity wants a new release. But it's probably unnecessary. THe current dwm in hg has some pixel width problems, so I think it needs more work. What's your proposal to solve the xinerama problem? --pancake
Re: [dwm] dwm-4.8 / dmenu-3.5 / slock-0.8
On Thu, 13 Mar 2008 18:08:03 +0100 Anselm R. Garbe [EMAIL PROTECTED] wrote: Hi there, I'm glad to announce some new releases after months of development and absence: http://www.suckless.org/download/dwm-4.8.tar.gz http://www.suckless.org/download/dmenu-3.5.tar.gz http://www.suckless.org/download/slock-0.8.tar.gz updated togglebar and mwfact patches for 4.8. http://news.nopcode.org/mwfact.c http://news.nopcode.org/togglebar.c --pancake
Re: [dwm] recent changes
On Tue, 11 Mar 2008 23:05:56 +0100
Anselm R. Garbe [EMAIL PROTECTED] wrote:
On Fri, Mar 07, 2008 at 12:02:31PM +0100, Szabolcs Nagy wrote:
On 3/7/08, pancake [EMAIL PROTECTED] wrote:
* If we change these #defines to integer variables we will be able to
write
external
commands to swap master and slave area between two monitors, join both
areas, manage
setmwfact or creating mixed layouts. And everything without touching the
core :)
+togglebar
I agree on having the defines being assigned to specific
variables/I pushed a change accordingly some minutes ago.
Yeah! nice!
I have reimplemented the togglebar and setmwfact for current 4.8.
My config is attached too, it should work on mostly common configurations.
Obviously the mwfact plugin doesn't works well with multiple screens.
patches are attached.
Im not very proud of these codes, but they work and show how
to change the master/tile/bar variables.
However, the defines are useful as they are, because they are
allowed to depend on bh and s{x,y,w,h} which are initialized
before the assignments (otherwise things like int mw = sw; in
config.h won't work, because sw is not initialized in the global
scope already due to DisplayWidth() depending on dpy).
Yeah this is good :) we can ignore hardcoding the resolution if
we only use one monitor using:
#define SCRT sw*3/5
#define SCRW sw
#define SCRH sh
What do you think about the addition of a third area for static
applications that can be used for a third monitor or a second one
with a default dwm configuration in the first monitor. This would
be a sample configuration.
screen 1 screen 2
+---+ +-+-+
| || | | |
| || |-|-|
| || | | |
+--++ +-+-+
We can define a toggle to switch between the screen 1 and two with a
zoom key to move applications between static area and master one.
This way we can also enhace the layout configuration with a single
monitor with three areas in this way:
+---+
| | | M = Master
| M | T | T = Tiled
+-| | S = Static
| S | |
+-+-+
The simplest way I can imagine for this is by specifying a tag into a frame area
to make it visible in some place of the screen.
Maybe this is too many changes for 4.7 - 4.8 but I maybe good for single
and multiple screens.
--pancake/* See LICENSE file for copyright and license details. */
/* appearance */
#define BORDERPX 6
#define FONT -*-terminus-medium-r-normal-*-14-*-*-*-*-*-*-*
#define NORMBGCOLOR #cc
#define NORMFGCOLOR #00
#define NORMBORDERCOLOR #172
//#cc
#define SELBORDERCOLOR #cc
//#0066ff
#define SELBGCOLOR #172
//#0066ff
#define SELFGCOLOR #ff
#define SCRT sw*3/5
#define SCRW sw
#define SCRH sh
/* bar position */
#define BX 0
#define BY 0
#define BW MW
/* window area, including floating windows */
#define WX 0
#define WY bh
#define WW sw
#define WH sh - bh
/* master area */
#define MX WX
#define MY bh
#define MW SCRT
#define MH SCRH - bh
/* tile area, might be on a different screen */
// TX=MW
#define TX MW
#define TY 0
#define TW SCRW-SCRT
#define TH SCRH
/* monocle area, might be restricted to a specific screen */
#define MOX MX
#define MOY MY
#define MOW SCRW-8
#define MOH MH
/* tagging */
const char tags[][MAXTAGLEN] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
Rule rules[] = {
/* class:instance:title substr tags ref isfloating */
{ Firefox, tags[8], False },
{ Gimp, NULL, True },
{ MPlayer, NULL, True },
{ Acroread, NULL, True },
};
/* layout(s) */
#define RESIZEHINTS False /* False - respect size hints in tiled resizals */
#define SNAP 32 /* snap pixel */
Layout layouts[] = {
/* symbol function isfloating */
{ []=, tilev, False },
{ []|, tileh, False }, /* first entry is default */
{ [M], monocle, True },
};
//{ , floating, True },
#include mwfact.c
#include togglebar.c
/* key definitions */
#define MODKEY Mod1Mask
Key keys[] = {
/* modifier key function argument */
#if ANSELM_OFFICE
{ MODKEY, XK_p, spawn,
exec dmenu_run -fn 'FONT' -nb 'NORMBGCOLOR' -nf 'NORMFGCOLOR' -sb 'SELBGCOLOR' -sf 'SELFGCOLOR' -x 0 -y 0 -w 1280 },
#else
{ MODKEY, XK_p, spawn,
exec dmenu_run -fn 'FONT' -nb 'NORMBGCOLOR' -nf 'NORMFGCOLOR' -sb 'SELBGCOLOR' -sf 'SELFGCOLOR' },
#endif
{ MODKEY|ShiftMask, XK_Return, spawn, exec Eterm },
{ MODKEY, XK_j, focusnext, NULL },
{ MODKEY, XK_k, focusprev, NULL },
{ MODKEY, XK_r, reapply, NULL },
{ MODKEY, XK_Return, zoom, NULL },
{ MODKEY, XK_Tab, viewprevtag, NULL },
{ MODKEY, XK_m, setlayout, [M] },
{ MODKEY, XK_f, setlayout, },
{ MODKEY, XK_t, setlayout, []= },
{ MODKEY, XK_v, setlayout, []| },
{ MODKEY, XK_h, setmwfact, -64 },
{ MODKEY, XK_l, setmwfact, +64 },
{ MODKEY, XK_b, togglebar, NULL },
{ MODKEY|ShiftMask, XK_space, togglefloating, NULL },
{ MODKEY|ShiftMask, XK_c, killclient, NULL },
{ MODKEY, XK_0, view
Re: [dwm] and now for something completely different...
I would like to know how diverse are the people on the list in terms of the actual layouts and dwm features they use... I use my own branch, but sometimes I use the development version to try new ideas and update my patches. Patches I use: - clients per tag - mouse on statusbar Programs I use: - dmenu - yeahlaunch - yeahconsole Applications I use: - claws-mail - epiphany - radare - screen (with mutt and elinks for remote boxes) - pidgin - xterm - feh - vim I don't tend to view more than one tag at the same time. I try to limit the number of windows per tag and avoid using more than 2-4 active tags (I like to have some free tags to be able to use them when I don't bother were to place a window). I use a lot the alt-tab and alt-w/alt-e (to limit the clients per tag to 2 or 3). I only use floating for the ones I want to keep a fixed aspect ratio or size (like minicom terminals, mutt, gimp, mplayer) or to make a window visible on all tags (It sounds strange to me to share a window between different tags on tile layout), but I only use the floating with mouse. I dont feel the need to use nmaster with cpt variable height. I use it for my own (in my laptops), so mostly personal use and development box.
Re: [dwm] recent changes
My impressions about this commit are:
*) At the beggining I feel a bit confused until fixed the master and slave
resolutions on a single screen (because xinerama seems to crash my kernel
and I can't test it in all its glory atm)
*) Using this concept on a single screen looks a bit more claustrofobic
because of the lack of setmwfact.
- On my 20 screen, the lack of setmwfact doesnt affects to me, but
using a static mwfact with the proper values for the monocle layout
is imho much more clear than having a variable one which distracts.
- Dropping the statusbar from the slave area we can play with a bigger
area (we have some more pixels O:)
* We need a MOBW variable when single window is opened or using monocle layout.
*) I really miss the possibility to link mouse actions on the statusbar :(
it makes the use much more usable when you have a hand on the keyboard
and the another one in the mouse, so you don't have to move the pointer
to zoom, kill or select clients.
I would like to have this patch on mainstream too. I think my current patch
fits quite well for most uses and doesnt needs to be configurable, maybe
a little of feedback can help to adopt this functionality, which IMHO
for larger screen (or multiple ones) much more productive than moving the
mouse around the clients.
*) I also miss the clients per tag patch O:) but I will probably redesign it
for dwm 4.8, so we can probably change the concept of CPT to define the
number of windows to be shown in the master area.. But I understand that
this is not necessary in mainstream because can be replaced with correct
use of the tagging concept.
*) My general impression was a bit frustrating at the beggining, but after
reading some source, playing a bit with the configuration and thinking
in some solutions I come to the conclusion that I'm pretty happy with
this new concept.
Source comments:
* If we change these #defines to integer variables we will be able to write
external
commands to swap master and slave area between two monitors, join both areas,
manage
setmwfact or creating mixed layouts. And everything without touching the core :)
* We will be able to define a master layout, tile layout.
I know that not all layouts will work for all screen configurations, but we
can just
try to handle the most common uses.
* looks like the monocle layout doesnt works as expected so it eats some more
screen
than in should :) and the right/bottom borders are out of screen
* at line 1567 (nice number):
...
for(i = 0, c = nexttiled(clients); c; c = nexttiled(c-next), i++)
if(i 0) {
if(i 1 i == n) /* remainder */
...
This nested conditional looks ugly to my eyes, I would prefer to setup the
proper value for 'c' before starting the loop instead of checking the
conditional for every client.
Nice work!
--pancake
On Thu, 6 Mar 2008 20:20:00 +0100
Anselm R. Garbe [EMAIL PROTECTED] wrote:
I investigated further today and refactored a lot. First of all
I got rid of dozoom, I extended Layout to contain a Bool
isfloating flag as well, which roughly tells dwm that the
layout algorithm is floating (hence there are no layers of tiled
windows being treated differently if isfloating is True in Layout).
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
I decided to add a tileh() layout which does the following in my
multiscreen setup (and which is pretty much similiar to
bstack, except that it expands on my second bigger screen), see
this screenshot:
http://www.suckless.org/shots/dwm-hstack.png
I also changed setlayout that it toggles to the previous layout,
if it is called twice. Due the fact of tileh, I changed the
setlayout keybindings slightly as you will notice on the
screenshot.
Also, monocle() now works like a floating layout, except that it
maximizes all windows to MOX, MOY, MOW, MOH. I decided against
rectangle restoring, this is a dynamic WM anyways.
I will be offline till Tuesday. Please test the stuff, report
bugs and feedback on this list, I will have a look then and
consider releasing the stuff next week.
Btw. I also changed dmenu yesterday, -b is gone, instead I
introduced -x x -y y -w w as command line options.
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] visibility of focused windows
Btw. I plan to introduce 3 additional key bindings: Mod1-f (Apply floating layout) Mod1-m (Apply monocle layout) Mod1-t (Apply tiled layout) I agree with that Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Do you have a quick solution for maximizing floating windows? Maybe the monocle layout shuold handle floating and nonfloating windows in the same way.
Re: [dwm] regex in rules?
This was discussed some time ago. I think it's unnecessary. On Tue, Feb 26, 2008 at 10:28:15PM +0100, Antoni Grzymala wrote: Anselm R. Garbe dixit (2008-02-26, 22:17): I'd like to get rid of regexp matching in rules, any complains? Does anyone really uses them? I think I just use substring match. Will this be sufficient? Best, -- [a]
Re: [dwm] [ANNOUNCE] dvtm-0.4
On Mon, 25 Feb 2008 00:24:53 -0800 Charlie Kester [EMAIL PROTECTED] wrote: I've been catching up on the archives since joining this list. In Marc's announcement for dvtm-0.4 he included the following todo item: * terminal emulation fixes: make arrow keys work within vim (without the TERM=linux workaround). I think this is vim's bug, not dvtm's or madtty's or even rxvt's. I have the same problem when I run vim in iTerm with an rxvt profile and no dvtm. It seems to be related to vim's builtin terminal definitions. I checked the terminfo definitions for cub1, cuf1, cuu1 and cud1 with infocmp. They're exactly the same for xterm as for rxvt, yet the keys work in vim under xterm. It is not a bug in vim, it is a vim missconfiguration. I never use arrow keys in vim, they are absolutely inproductive. But for those who use it, some terminal configuration. Add set nocompatible to your .vimrc and let me know :) --pancake
Re: [dwm] We need a different Xinerama implementation
I have been using dwm with an external monitor for a while, just as is...using only the external monitor losing the screen resolution on my laptop screen. These days im rather busy and can take much care about dwm, but I hope to have some time to test all the xinerama changes in dwm 4.8. I have some ideas really closer to the ones exposed by you and yiyus, but I don't want to think on it until i have something to test and check how i feel with it. btw, maybe i'll have to check the repository instead of waiting for the release :) On Fri, 15 Feb 2008 09:21:18 +0100 y i y u s [EMAIL PROTECTED] wrote: My proposal about xinerama would be: you have the same set of tags in each monitor, but you can have selected a tag only in one monitor. So, if for example you have tag 2 selected in monitor a and you select tag 2 in monitor b it will be in unselected in a. You would need the possibility of not having any selected tag for this to work. The obious problem: what if a window has more than one tag and it is selected in two monitors? I think you could just put it in the first monitor. I don't have 2 monitors now, but when I did one of them was the main one and the other some sort of secondary screen, so this would have sense, but I'm not sure all you are using xinerama this same way. Anyway, I don't have a strong opinion about this, I would need a second monitor to test my ideas. A proposal: what if you release some sort of 4.8 and we implement different xinerama approachs and after some testing you decide which one is better? I'm glad to see some movement in dwm again. Greets, -- - yiyus || JGL . --pancake
[dwm] dwm on openmoko
I have recently adquired an OpenMoko device (neo1973) and managed to build dwm 4.7 on it: http://news.nopcode.org/mokodwm.png http://news.nopcode.org/mokodwm2.png I find quite interesting the zoom feature which makes the interface quite interesting for finger use together with the mouse-on-title patch, but there are some problems, i'll think/try to fork dwm for finger use and use openmoko and n810 as testing environments. The most anoying problem is the miss of right and center buttons and some openmoko-related problems that I think are related to a self modified matchbox which sucks to me.. I think is funny to test things like that, btw i think that current free environments for mobile gadgets are slow and bloated..android looks fast and stable, but i think that a minimalistic approach would be interesting for a phone interface. a problem i found with openmoko ...and probably for other environments is that the keyboard popups only when a entry widget is selected, the keyboard should not get focus and become a floating window, but dwm does not and the keyboard applications starts to start/stop all the time having to zoom single to return to a stable state. weird. Is any X11 event to avoid a window taking focus? should be this managed by dwm? I shoud have to get a look on the virtual keyboard code.. Small devices claim small software :) my line to build dwm for openmoko was: $ make CC=$CC CFLAGS=-I. -I/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/include/ -DVERSION=4.7 LDFLAGS=-L /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib -Wl,-R /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib -lX11 after setuping the environment have fun! --pancake
Re: [dwm] [ANNOUNCE] dvtm-0.4
* Compilation fix for NetBSD (hopefully) Confirmed! it builds and works nicely! I just had to add CFLAGS+=-I/usr/pkg/include LDFLAGS+=-L/usr/pkg/lib -Wl,-R/usr/pkg/lib but these flags should be handled by pkgsrc, so, no problem with that :) Now the program runs really nice! :D Good work! --pancake
Re: [dwm] patch: don't update prevtags if nothing changed
I'm with this patch! :) I send a proposal for this few months ago.. i'll try't at night Thanks --pancake On Wed, Jan 30, 2008 at 01:03:33PM +, David Edmondson wrote: MODKEY-Tab is very nice for bouncing between tags, but sometimes I re-select the current tag using MODKEY-n (where n is 1-9). Now both seltags and prevtags contain the same set, meaning that MODKEY-Tab does nothing useful. This patch modifies the view() function so that it doesn't change prevtags unless the new set of tags is different from the old. I'm a new dwm user, so it's entirely possible that I've missed something in the zen of it all - feedback appreciated. dme. dme. -- David Edmondson, http://dme.org
Re: [dwm] dietline - minimalistic readline implementation
Updats for dietline: http://news.nopcode.org/dietline.c * cursor support - move around the line with arrow keys - insert text inside the line from the cursor index * new keybindings - ^W - remove last word from cursor - ^H - remove a char from cursor * Fixups for autocompletion Actually the autocompletion doesn't works well at all, but it performs better than before. I have to implement the modular autocompletion functions and after this I'll start refactoring the code to reduce LOCs and dupped code. I would like to make all the keybindings be configurable easily to be able to add/remove or change the key interface in an easy way to support vi mode and so. With some modifications would be effort-less to write a text editor using this input-handling :) BTW I expect to have everything done in ~500 LOCs I don't exactly know how i'll handle special keys or utf yet, any tips? --pancake On Wed, Jan 23, 2008 at 07:38:02PM +0100, pancake wrote: On Wed, Jan 23, 2008 at 03:13:28PM +0100, Enno Gottox Boland wrote: Very nice idea. What about collecting all these baseutilities and put them on suckless.org? If we can write more utilities we may get a complete suckless userspace... :) Sure! When I implement all the basic stuff like nested autocompletions, emacs mode and so I'll publish a working/stable version. A whole suckless userspace would be really cool :) Maybe we can start organizing efforts for implementing it. --pancake
[dwm] inherit floating
What do you think about make dwm inherit the floating attribute? if we are working on a floating window we usually want that all the windows opened from a floating window be floating. I dont know if it's possible to know the parent window for a client, but we can abstract the concept just saying that the new window will inherit the floating attribute, so if we focus a floating client and open a new window, the new one will be floating too. --pancake
Re: [dwm] dietline - minimalistic readline implementation
Oops I forgot to say that it supports a dmenu-mode (this code inherits from
the old eread program I send to the list few months ago).
Usage is quite simple:
int main(int argc, char **argv)
{
char *ret;
dl_init();
dl_prompt = $ ;
do {
ret = dl_readline(argc, argv);
if (ret) {
printf( [line] '%s'\n, ret);
dl_hist_add(ret);
}
} while(ret!=NULL);
dl_free();
}
Have fun!
--pancake
On Wed, Jan 23, 2008 at 04:31:57PM +0100, pancake wrote:
As I request in a previous mail I have developed a readline-like
library in a minimalistic way avoiding the unnecessary overhead
and dependency with a single portable c file.
I have tested this on NetBSD, GNU/linux and native w32 and works
pretty fine.
The library currently supports autocompletion of a single word
using argc, argv (this is just a PoC). Allows to change the prompt,
and change some configuration stuff for it.
No vi or emacs mode yet (should i read inputrc?).
Current support:
- history log
- navigate history with ^n/^p or up/down keys
- autocompletion for one keyword (no nested yet)
- tab key hooked for autocompletion
- support to change the prompt
- handle ^C and ^D
You can download the implementation here:
http://news.nopcode.org/dietline.c
To test it on w32 just put __UNIX__ to 0 and __WINDOWS__ to 1 :)
$ gcc dietline.c
$ ./a.out foo bar foobar foocowblob foocowguai
= footab
foo foobar foocowblob foocowguai
= foocowtab
foocowblob foocowguai
= foocowbtab
= foocowblob
I plan to use this library instead of readline for radare (radare.nopcode.org)
so I plan to continue working on it.
Patches and ideas are welcome.
--pancake
Re: [dwm] a patch to solve the java issue (gray windows) with dwm?
This patch is not a solution. is just a hack. If you read the patch, and the archives in tihs mailing list you'll find the reason and some snippets of java code (and the path to the buggy code into the java source). The patch obviously is not affordable for dwm because monad is written in Haskell...but a patch for dwm would be probably a single line in C. So the solution is not to hack into the window manager because its a bug in the virtual machine..well..in reality its not a bug, its an ugly hack :P And fix hacks with hacks is ugly. :P FYI: What Java does is to check for the window manager name and if it's known perform correctly and if not show a grey screen. The solution is just to remove these lines or add dwm as a valid window manager. Any X11 guru to provide a hack for those unhappy users? I have no time to look at it now, and my Java works fine. --pancake On Thu, Jan 24, 2008 at 12:51:08AM +0900, Renick Bell wrote: Stated as explicitly as possible: 1. I need to be able to use java gui apps and dwm at the same time. My justification is in the extended footnote. 2. This post seems to explain why java apps only appear as gray windows in dwm, and it provides a patch for the Xmonad window manager: http://article.gmane.org/gmane.comp.lang.haskell.xmonad/1790 3. I have been unable to locate a similar patch for dwm. 4. Has such a patch been written by anyone? 5. I currently am unable to write such a patch. 6. I certainly wouldn't expect such a hack to become part of the official dwm source. 7. Hacking the java source would be a waste of time. 8. Java's own 1.7.0 appears to be pre-beta. http://java.sun.com/downloads/ea/ I don't want to be an early adopter/tester of Sun's software. I want to use my package manager's icedtea package for license reasons; however, for practical reasons I would use any of my package manager's java packages. Those don't include another 1.7.0 java. 9. The dwm source, because of its conciseness, seems to be an appropriate place to apply a patch. 9. Is there an alternative solution to the problem such that I could use dwm, have properly functioning java apps, and avoid hassle with java source or pre-beta Sun products? Thanks for assistance. The justification for using java is below. Renick --- ...my justification for use of java and dwm simultaneously. If you would like to reply to this section, please start a new off-topic thread. I don't mind discussing it, but please don't foul the on-topic thread about java and dwm. Again, stated as explicitly as possible: 1. I use SuperCollider for realtime audio work. SuperCollider is a programming language. http://supercollider.sourceforge.net/ 2. People develop GUI applications using SuperCollider. On Macs, users have access to the native GUI toolkit from within SuperCollider. 3. Those using Windows and Linux don't have access to native GUI toolkits from within SuperCollider at the moment. There is no gtk, qt, or other toolkit binding/library for Linux users which is also cross-platform. 4. Linux and Windows users can use SwingOSC, which is a cross-platform GUI toolkit based on Swing. http://www.sciss.de/swingOSC/ 5. Using SwingOSC allows me to use programs written by Mac and Windows users. It also allows those users to use my code. 6. Making another toolkit available within SuperCollider, such as gtk, is significant work which will require weeks, if not months. 7. I don't like using java for license reasons, performance reasons, and aesthetic reasons. 8. I would like to eventually develop a concise, efficient, and lightweight alternative. 9. In the meantime, I want to use GUI code written by other SuperCollider users. 10. I also want to use code which I wrote while using wmii, under which java apps functioned properly. 11. That means I must use SwingOSC until I have developed an alternative. 12. That means I must have java. 13. I think dwm is the best window manager for me. 14. Therefore, I want to use java and dwm together until I can be free from java. -- Renick Bell http://the3rd2nd.com
Re: [dwm] dietline - minimalistic readline implementation
On Wed, Jan 23, 2008 at 03:13:28PM +0100, Enno Gottox Boland wrote: Very nice idea. What about collecting all these baseutilities and put them on suckless.org? If we can write more utilities we may get a complete suckless userspace... :) Sure! When I implement all the basic stuff like nested autocompletions, emacs mode and so I'll publish a working/stable version. A whole suckless userspace would be really cool :) Maybe we can start organizing efforts for implementing it. --pancake
Re: [dwm] Minimalism
On Thu, Jan 17, 2008 at 12:37:56PM +0100, Sylvain Bertrand wrote: Hi, I'm looking to reduce my software stack and I'm targeting the C library. I know I just need to perform direct Linux syscalls and it will be fine. But, I would like to load ELF shared objects in my process space and for that, the only way I know is to use the dynamic linking lib from the C library. Has anybody heard about something like that? lolsome, libraries are here to avoid code duplication in memory, i know that most of GNU ones are blobs, but the solution is not coding like gcc -static does. This is a task of the compiler and what you're proposing is a bad software design rule. About the shared object loading..it's not inside libC on GNU systems. This task is delegated to libdl. so it's an standalone library. I think that system elf loader (ld.so) should be able to do it so..if you're writing a virus or playing with low-level stuff on *nix you can get a look on it. And for dwm, I don't know what would be the cost to build directly the X11 packets or to recode the XCB lib straight on Linux syscalls. This will make dwm unportable and we should implement the different ways to communicate with X11 (socket file, network,..)
Re: [dwm] dzen replacing dwm status bar
On Mon, Dec 24, 2007 at 01:01:23PM +0100, [EMAIL PROTECTED] wrote: hum... doesn't seem to work (nothing appearing). I tried with svn rev 178 : echo test | dzen2 -p -expand l did I miss something ? How length variations are on a single word? :)
[dwm] dwm and gnome
In a box of my parent's home I have an ubuntu box with gnome.
They feel comfortable with metacity because it doesn't needs
to learn any keybinding, but when i'm using it I feel really
uncomfortable and I have to use dwm.
I have decided to try to adapt dwm to fit with metacity and
gnome-menu and make it boot dwm instead of metacity.
Copypasta these lines to avoid metacity:
gconftool --type string -s /desktop/gnome/applications/window_manager/current
/usr/bin/dwm
gconftool --type string -s /desktop/gnome/applications/window_manager/default
/usr/bin/dwm
When gnome-session boots gnome-panel/dwm/nautilus it comes into
a broken environment.. The nautilus --desktop starts as a fullscreen
floating window so, it hides the dwm statusbar and the gnome-panel
gets focus, so the desktop is on top and unfocused.. So you have to
alt+j, alt+return.
What I propose is to force the metacity desktop window to be tiled.
I have tried to add a rule for it getting the window title with xwininfo
and inserting a row inside the rules array:
Rule rules[] = {
/* class:instance:title regex tags regex isfloating */
{ Firefox,www, False },
{ Escritorio, NULL, False },
...
You should use Desktop instead.
The problem is that this rule is ignored ://
So we can try to figure why this happens, or try to find to avoid fullscreen
floating windows overlap the statusbar (so , we have alt+b to fix this)..
Another strange thing I see is that the desktop window has no border.
the same happens with openoffice and some splash screen windows. Is
this a normal issue?
The window list menu bar and notification area doesn't works.
About the gnome-panel...the default desktop menu gets something inusable
because its handled as a normal tiled window, and I think they should be
floating and borderless or implementing a static area in dwm to make all
'static' windows live there. Something like this:
+---+ - dwm status bar
| | |
| |-| - tiled area
| | |
|_|_|
+---+ - static area
This way we can allow windows with a certain title be stacked there like
the cpt patch does to avoid interfering with other windows.
Not only for gnome, but this way we can provide hybrid environment with
tiled desktop and menubar and will be compatible with any available desktop
environment or menu implementation.
I can add a new tag called 'desktop' replacing the first one and it can
be accessed by toggling the first tag (ctrl+alt+1). This feature comes
extremely productive when using (alt+tab).
What do you think about all this random brainstorming?
--pancake
Re: [dwm] [announce] sltar-0.2.1
Yay :) awesome source :) It works fine for me. The gzip/bzip support is useless so you can pipe't with zcat/bzcat, the only thing i miss is the 'c' flag :) I usually like to untar with verbose mode which (theorically) would be the same than specifying -t and -x (list contents and extract). If you want to add compatibility with standard tar or pax you should add -v -z and -j...but srsly..these flags looks like a joke to me, but sometimes is useful for comodity. - v : verbose.. why if we have -t ? .. maybe we should rename t as v? - z : gzip ( !gzip~=/^z/ ) - j : bzip2 ( !bzip2~=/j/ ) About security...i must say that it will need some file creation checks. - It doesn't stops or warns if a mknod/chown fails - does not checks for crosspath filenames like ../../../etc/passwd - does not checks for headers or invalid data - can cause the creation of wrong filenames (binary stuff) PD: Can you add RSS to your blog? :) PD2: This program makes me think about a future suckless-like OS --pancake On Wed, Dec 19, 2007 at 05:09:43PM +0100, Enno Gottox Boland wrote: Hi! I wrote a very small tarball extractor: (73sloc). tar.gz: http://s01.de/~gottox/files/sltar/sltar-0.2.1.tar.gz Mercurial: http://s01.de/~gottox/hg/sltar Project page: http://s01.de/~gottox/index.cgi/proj_sltar Please notice that sltar can only extract and list contents of an uncompressed tarball. It's very minimalistic, but it works very well :) Please report any bugs. regards Gottox -- http://www.gnuffy.org - Real Community Distro http://www.gnuffy.org/index.php/GnuEm - Gnuffy on Ipaq (Codename Peggy)
Re: [dwm] [ANNOUNCE] cmarkdown-0.3
On Fri, Dec 14, 2007 at 09:37:58AM +0100, Sebastian A. Liem wrote: What's bad about markdown? I've got minimal experience with it, it was cmarkdown that got me interested in txt2html converters. Little related ..but maybe this project may interest you: http://news.nopcode.org/miau/pvc.cgi?prj=xml2doc http://news.nopcode.org/miau/pvc.cgi?prj=rss2html Enno Gottox Boland [EMAIL PROTECTED] wrote: I use pre for displaying a block segment of code. Markdown.pl uses precode. I really don't know if I should use that too. I agree with meillo, it should be precode. More semantically correct. -- Sebastian A. Liem http://www.liem.se/
Re: [dwm] maximize problem
On Mon, Dec 10, 2007 at 04:10:24PM +0100, Antoni Grzymala wrote: pancake dixit (2007-12-10, 16:50): climit / clientspertag also has this problem. In case of climit, a climit of 1 starts the monocle mode so things are better. However, for 1 climit number of visible tiled clients, changing the focus can go to a client not being shown (which is still useful to zoom on that client... but you need to know that climit is activated). Are you from the past? Actually, *you* are from the future. Check your clock :). hahaha yes :) you catch me. I'm from the future and I'm comming with a new detergent! ;) --pancake
Re: [dwm] Xinerama support
Why not just keep it simple and store a seltags[] for each monitor and a single variable indicating which is the current monitor selected? This way you can achieve any of the possibilities (show the same client in both monitors, move a window from one to another, etc.. For me this approach looks the simpler one and fits all my needs. which situations are not handled by this approach? On Sun, 9 Dec 2007 23:10:14 +0100 Antoni Grzymala [EMAIL PROTECTED] wrote: Anselm R. Garbe dixit (2007-12-09, 18:27): [snip] One idea I was playing in my mind with for a while was assigning some of the tags to the other display and move between the displays seamlessly as if moving between the tags - I guess I'll still have the problem of not being able to move the programs between other-display-tags but it'd look more natural and I won't have to invoke switchscreen separately. For my taste, treating different displays as different tag sets is a better solution than defining a very large display where one tag spreads over both of the screens. But of course the ability to move program windows between the displays is quite handy, too. One problem with using a subset of your tags for a different screen occures, if a window is tagged with a tag from one screen and with another tag from a different screen. We cannot display a window on two screens, at least not mirrored (Xinerama allows to display portions of windows on different screens however) ;) I think this discussion is going in the right direction. My suggestion to marry those two contradicting views would be like this: - in normal circumstances two heads act like two separate dwm instances (the way I guess most people are doing now), you can jump between them the usual way (ie. sh -c 'DISPLAY=:0.1 swarp 512 384'); - both heads have their own freely settable sets of tags (like two separate dwm instances); - add another property to a client (called head, for example), signifying which head a client should appear on (mutually exclusive, so that we don't try do display a client on both heads; - allow changing the head property for a client with a keyboard-bound function while preserving other attributes of the client (tagset, float/non-float); Do you think this makes sense? Regards, -- [a] --pancake
[dwm] maximize problem
I find quite anoying the maximize command. Because allows you to hide windows to the user. I don't know if the right solution for this would be to make maximize act as monocle, or avoid changing the focus of the maximized client for the current tag, or making the maximized flag be inheritable for the following created/switched clients. You can achieve this problem by: - open two windows - maximize() - nextclient() (focused client is hidden for the user) --pancake
Re: [dwm] nmaster-4.7 updated
Oops. Fixed On Mon, Dec 03, 2007 at 09:58:46AM +0100, Szabolcs Nagy wrote: On 12/3/07, pancake [EMAIL PROTECTED] wrote: http://www.suckless.org/wiki/dwm/patches/push there is an error: push-4.7.c: 404-NotFound
Re: [dwm] nmaster-4.7 updated
Thanks!
I have included the push.c into my own branch and made it available in the
dwm wiki:
http://www.suckless.org/wiki/dwm/patches/push
Configuration is done by typing:
#include push-4.7.c
{ MODKEY|ControlMask, XK_j, pushdown, NULL }, \
{ MODKEY|ControlMask, XK_k, pushup, NULL }, \
Have fun!
On Sun, 2 Dec 2007 12:45:09 +0200
Szabolcs Nagy [EMAIL PROTECTED] wrote:
On 12/1/07, Rickard Gustafsson [EMAIL PROTECTED] wrote:
Something like swap has been posted before done by k-zed and Szabolcs
Nagy. It was done for DWM 4.1 I think.
here is the pushup/pushdown code for dwm 4.7
(include push.c in config.h if you find it useful)
--pancake
[dwm] nmaster-4.7 updated
Some users noticed me a bug that makes zoom() inusable when switching between floating and ntile or tilecols. I missed to type: domwfact = dozoom = True; I have also added a new optional variable in config.h called CPT to define the initial value for the cpt variable. I think that #define CPT 5 is probably the most useful value, but when using nmaster, the CPT should be 6 or 7,..so maybe i can mix cpt with nmaster, will be interesting to see if it's cleaner or not to use. I have also added some new functions enabled by EXPERIMENTAL. All of them are buggy and not currently working, but are tests im doing and want to receive feedback. #define EXPERIMENTAL True The new function available into EXPERIMENTAL is swap() which receives +1 or -1 as argument, and it just swaps two clients inside the clients list. This is a cp from awesome. So it doesn't works with the dwm base, but now i have no time to implement it. So if anybody of us want to play with it. Send me the patch O:) I feel that the swap() function of awesome is really useful, and imho should be implemented into the dwm base. With swapnext() and swapprev(). Does anybody have tested this functionality? --pancake
Re: [dwm] stacked cpt patch updated!
Thanks for the updated cpt patch; I only had to change the default CPTH
value.
I have updated the patch with a new function that allows to modify the Cpth
value on the fly:
{ MODKEY, XK_n, setcpth, +32 }, \
{ MODKEY|ShiftMask, XK_n, setcpth, -32 }, \
There are a few things that could be made clearer / changed.
1. Your example configuration of '{ MODKEY|ShiftMask, XK_q,
clientspertag, 0 },' conflicts with the default binding for quit.
You're right, I remove the mod+shift+q key of my config.h coz i never use this
functionality. I prefer to kill the X or just type 'pkill dwm'. btw i'll
change it for another value.
2. I understand that, for me to successfully use nmaster.c, I must
include it before Layout layouts[], as stated in your documentation.
However, what was not made apparent was that #RESIZEHINTS must be
specified before you include nmaster.c. Therefore, I recommend you
change the following:
You should modify your config.h to include nmaster.c from it after
setting the NMASTER, NCOLS and NROWS macro defintions.
to this (or something similar):
You should modify your config.h to include nmaster.c AFTER setting
the NMASTER, NCOLS, NROWS, BORDERPX, and RESIZEHINTS macro definitions.
changed!
This would make it a lot easier to compile dwm without trial and error,
especially for a person like me who is not very familiar with C.
ok :) done
Apart from that, thanks for the patch: it works well.
WHen using setcpth you can see that it's still buggy. but almost ok :)
ill fix these minor issues soon :)
Sincerely,
Antony Jepson.
--pancake
Re: [dwm] stacked cpt patch updated!
I have updated the patch again fixing the 1 pixel gap and the height calculation
of slave area clients. Now it looks pretty perfect. The setcpth function has
been
set cleaner by limitting the maximum and minimum sizes for the bottom stack
area.
I have also updated the documentation with some ascii stuff:
http://news.nopcode.org/nmaster-4.7.c
TITLE
-
descrp: ntile/tilecols layouts with clientspertag for dwm-4.7
author: pancake youterm.com
update: 2007-11-26
CONFIGURATION
-
You should modify your config.h to include nmaster.c AFTER setting
the NMASTER, NCOLS, NROWS, BORDERPX, and RESIZEHINTS macro definitions
and BEFORE the layouts definition.
A sample configuration with ntile will be:
#define NMASTER 1
#define NCOLS 1
#define NROWS 1
#define CPTH 32
#include nmaster-4.7.c
Layout layouts[] = {
{ -|= , ntile },
// ...
};
// keys
{ MODKEY|ShiftMask , XK_j, setnmaster , +1 } , \
{ MODKEY|ShiftMask , XK_k, setnmaster , -1 } , \
{ MODKEY , XK_q , clientspertag ,^1 } , \
{ MODKEY , XK_w , clientspertag , 2 } , \
{ MODKEY , XK_e , clientspertag , 3 } , \
{ MODKEY , XK_n , setcpth , +32 } , \
{ MODKEY|ShiftMask , XK_n , setcpth , -32 } , \
clientspertag:
both of them features the new cpt patch (clients per tag) which enables
to define the maximum number of clients you want to focus, the rest are
stacked at the bottom of the screen. This area has CPTH height and this
value can be changed on the fly using the setcpth function.
+--++
| || Valid values are:
| ||-1 - show all clients
| || 0 - show all clients in the bottom stack area
+---+--^+---+0 - show N clients
+---+---+---+
#define CPTH 32 // num of pixels of the height of the stacked cpt area
{ MODKEY , XK_q , clientspertag ,^1 } , \
{ MODKEY , XK_w , clientspertag , 2 } , \
{ MODKEY , XK_e , clientspertag , 3 } , \
{ MODKEY , XK_r , clientspertag , 4 } , \
{ MODKEY , XK_t , clientspertag , 5 } , \
{ MODKEY , XK_n , setcpth , +32 } , \
{ MODKEY|ShiftMask , XK_n , setcpth , -32 } , \
This source adds two new layouts:
ntile:
+-+--+
|_|--|
| |--|
+-+--+
#define NMASTER 1
{ -|=, ntile } , \
{ MODKEY|ShiftMask , XK_j, setnmaster , +1 } , \
{ MODKEY|ShiftMask , XK_k, setnmaster , -1 } , \
tilecols:
+--+--+--+
|__| |__|
| | | |
+--+--+--+
#define NCOLS 2
#define NROWS 1
{ E|], tilecols } , \
{ MODKEY|ShiftMask , XK_j , setnrows , +1 } , \
{ MODKEY|ShiftMask , XK_k , setnrows , -1 } , \
{ MODKEY|ShiftMask , XK_h , setncols , +1 } , \
{ MODKEY|ShiftMask , XK_l , setncols , -1 } , \
--pancake
Re: [dwm] cpt alternative proposal
Nope, sry, if you havent tried the rfigura fork you can't see what i'm talking about.. Here's a shot about what i'm talking about...maybe stack is not the proper name, but i think that using the stack-mode like wmii makes can be better, so small windows are useless for the eye unless you show the title. But if you're working with terminals, the title of the window does not always reflects what's going on, like wget's or so..so no until testing it i don't know which will be the best way to do it. This is a shot: http://news.nopcode.org/dwm-rfigura-stack.gif --pancake On Fri, 23 Nov 2007 12:43:13 -0500 Antony Jepson [EMAIL PROTECTED] wrote: pancake, When you say stacking are you referring to something like wmii's default stacking mode? Sincerely, Antony Jepson On Nov 23 12:56, pancake wrote: On Fri, Nov 23, 2007 at 07:38:22AM +0100, Robert Figura wrote: pancake [EMAIL PROTECTED] wrote: I was thinking about the stacking feature of dwm-rfigura and cpt, and maybe they can coexist, so, this way will make stack mode easier to use and flexible, and will fix the problem of the hidden clients out of the cpt range. I'm not sure what feature you're referring to. The cpt idea appeals to me but until now i haven't tried to implement it myself. My idea is to mix cpt and rfigura-stack patch in this way: ^w = clientspertag(^2) +-++ +-++ +-++ | || | || | || | ++ ^w | || ^w | ++ | || |_|| | || +-++ +--+ +-++ ^e = clientspertag(^3) +-++ +-++ +-++ | || | || | || | || ^e | ++ ^e | || | || |_|| | || +-++ +-++ +-++ This way non-visible windows are stacked in the bottom of the screen, so they still being visible and you can focus them and zoom them as in any other mode. So, the stacked clients remain on the tail of the clients list and you can keep focus on the N clients you want with clientspertag. I have not written any line of code yet. rfigura, what do you think about this? It is much difficult to port it from dwm-rfigura to dwm? Are there much changes on the source? There are many (unrelated) changes on the source which is the reason i stopped writing patches and moved on to fork dwm. If i'd grok what you're looking for i'd be happy to help backporting ideas. Uhm, thats what I think.. its a bit hard to follow dwm -mainstream after these latest versions patches...But I prefer to port patches than fork it. I like to test forks to get ideas and so, but I like to work on the mainstream branch and try to make the minimum number of changes to fit my needs. I don't have much time these days..so, if you want porting the nmaster+stack patch as a new mode for dwm (or just patch my nmaster-4.7.c) feel free to do it. :) --pancake --pancake
[dwm] stacked cpt patch updated!
Now the cpt patch of nmaster-4.7.c support stacking, i think this is better way to handle this. let me know what do you think :) http://news.nopcode.org/nmaster-4.7.c http://news.nopcode.org/nmaster.gif --pancake
Re: [dwm] stacked cpt patch updated!
bugs fixed, only needs code cleanup ;) have fun trying it, and let me know what do you think about this feature. On Sat, 24 Nov 2007 22:16:04 +0100 pancake [EMAIL PROTECTED] wrote: NOTE that it's full of bugs i have to go now, but i'll fix it asap ;) On Sat, 24 Nov 2007 21:56:54 +0100 pancake [EMAIL PROTECTED] wrote: Now the cpt patch of nmaster-4.7.c support stacking, i think this is better way to handle this. let me know what do you think :) http://news.nopcode.org/nmaster-4.7.c http://news.nopcode.org/nmaster.gif --pancake --pancake --pancake
Re: [dwm] cpt alternative proposal
On Fri, Nov 23, 2007 at 12:44:57PM +0100, Anselm R. Garbe wrote:
I thought about this proposal for a while, but I tend to the
fact that such functionality belongs to a dwm.c patch (esp.
because the mouse-based tagging is intended to be as is).
A hook interface to mouse events for the status bar seems a
little bit overengineered to me.
You could even separate the handling if you write a
buttonpress(XEvent *) replacement.
And what about make dwm call a user-defined function instead if
replacing it? What i'm thinking about is something like:
config.h
#define MOUSEONTITLE mouseontitle
dwm.c
void
buttonpress(XEvent *e) {
unsigned int i, x;
Client *c;
XButtonPressedEvent *ev = e-xbutton;
+ MOUSEONTITLE(e);
if(ev-window == barwin) {
This will allow me to just add a new function called mouseontitle
to handle all the mouse events in the title bar without having to
modify dwm.c
--pancake
Re: [dwm] cpt alternative proposal
On Fri, Nov 23, 2007 at 07:38:22AM +0100, Robert Figura wrote: pancake [EMAIL PROTECTED] wrote: I was thinking about the stacking feature of dwm-rfigura and cpt, and maybe they can coexist, so, this way will make stack mode easier to use and flexible, and will fix the problem of the hidden clients out of the cpt range. I'm not sure what feature you're referring to. The cpt idea appeals to me but until now i haven't tried to implement it myself. My idea is to mix cpt and rfigura-stack patch in this way: ^w = clientspertag(^2) +-++ +-++ +-++ | || | || | || | ++ ^w | || ^w | ++ | || |_|| | || +-++ +--+ +-++ ^e = clientspertag(^3) +-++ +-++ +-++ | || | || | || | || ^e | ++ ^e | || | || |_|| | || +-++ +-++ +-++ This way non-visible windows are stacked in the bottom of the screen, so they still being visible and you can focus them and zoom them as in any other mode. So, the stacked clients remain on the tail of the clients list and you can keep focus on the N clients you want with clientspertag. I have not written any line of code yet. rfigura, what do you think about this? It is much difficult to port it from dwm-rfigura to dwm? Are there much changes on the source? There are many (unrelated) changes on the source which is the reason i stopped writing patches and moved on to fork dwm. If i'd grok what you're looking for i'd be happy to help backporting ideas. Uhm, thats what I think.. its a bit hard to follow dwm -mainstream after these latest versions patches...But I prefer to port patches than fork it. I like to test forks to get ideas and so, but I like to work on the mainstream branch and try to make the minimum number of changes to fit my needs. I don't have much time these days..so, if you want porting the nmaster+stack patch as a new mode for dwm (or just patch my nmaster-4.7.c) feel free to do it. :) --pancake
Re: [dwm] cpt alternative proposal
On Fri, Nov 23, 2007 at 11:26:48AM +0100, Anselm R. Garbe wrote: Most of the changes since dwm-4.3 have been made to easy patching it and allow patches to access all variables and functions without the need to change dwm.c. This has been done especially for the layout integration. Actually I only need to patch dwm.c for the mouseontitle which I would like to see a way to implement or configure it without having to do it. rfigura has made a proposal for it, but I don't know if it's the best approach, but hooking actions to mouse button actions on titlebar in a similary way keybindings are done..sth like mousebindings or so. What do you think? I know that dwm wants to be keyboard friendly, but i find this patch quite useful and handy (mostly when i'm smoking or with people and i prefer to use one hand and few clicks instead of typing things. btw thanks Anselm for the release. I am very happy with it. This latest releaes looks perfect, like _always_ ;) --pancake
[dwm] cpt alternative proposal
I was thinking about the stacking feature of dwm-rfigura and cpt, and maybe they can coexist, so, this way will make stack mode easier to use and flexible, and will fix the problem of the hidden clients out of the cpt range. I have not written any line of code yet. rfigura, what do you think about this? It is much difficult to port it from dwm-rfigura to dwm? Are there much changes on the source? --pancake
[dwm] dwm-4.7 nmaster/cpt/tilecols patch
I have update the nmaster.c to fit with dwm-4.7.. After some time of testing I
can
say that the dinamic cpt is an absolutely wrong idea and I have dropped.
The code has been reduced thanks to ISTILE and isarrange(). The wiki has been
updated
but here's the source:
http://news.nopcode.org/nmaster-4.7.c
I have fixed the master area gaps between clients. I think the tilecols mode
is the best one for my needs. I'm currently on a 20 16:10 TFT and 3 columns
and i'm pretty happy with it.
Here's my current configuration is:
--
#define NMASTER 1
#define NCOLS 3
#define NROWS 1
#include nmaster-4.7.c
Layout layouts[] = {
{ E|],tilecols }, /* first entry is default */
};
(...)
{ MODKEY|ShiftMask, XK_j, setnmaster, +1}, \
{ MODKEY|ShiftMask, XK_j, setnrows, +1 },
\
{ MODKEY|ShiftMask, XK_k, setnmaster, -1}, \
{ MODKEY|ShiftMask, XK_k, setnrows, -1 },
\
{ MODKEY|ShiftMask, XK_h, setncols, +1 },
\
{ MODKEY|ShiftMask, XK_l, setncols, -1 },
\
--pancake
Re: [dwm] experimental release: dwm-rfigura
Here'r my shots: http://news.nopcode.org/dwm-rfigura.png http://news.nopcode.org/dwm-rfigura2.png http://news.nopcode.org/dwm-rfigura3.png http://news.nopcode.org/dwm-rfigura4.png Some random comments about it: - I'm starting to love the toggleplaced functionality - I have modified the keybindings to be more similar to the dwm one. standard ones are quite confusing to me. - The WWW mode is quite awesome - sometimes is - the mouse interaction needs more work. - would be nice to toggleplace with mouse - also to zoom/close with mouse at title bar (mouseontitle patch) - the lens layout together with the toggleplaced and togglebar is quite practic. - there are some gaps if you play with the nmaster value. - i miss the original dwm's setmwfact here. --pancake On Thu, 15 Nov 2007 22:56:49 +0100 Michael Muster [EMAIL PROTECTED] wrote: On Thu, Nov 15, 2007 at 10:55:52PM +0100, Robert Figura wrote: markus schnalke [EMAIL PROTECTED] wrote: Robert Figura [EMAIL PROTECTED] wrote: I just put my current work in progress version online: http://spuerwerk.dyndns.org/~rfigura/dwm/ Screenshots desired! :-) okay. cludged together some ad hoc bad quality shots. Regards - Robert Figura http://spuerwerk.dyndns.org/~rfigura/dwm/screenshots/tile4.gif no access: 403 - Forbidden Best regards Michael --pancake
Re: [dwm] experimental release: dwm-rfigura
On Thu, 15 Nov 2007 22:55:52 +0100 Robert Figura [EMAIL PROTECTED] wrote: Screenshots desired! :-) okay. cludged together some ad hoc bad quality shots. 403 - Forbidden --pancake
Re: [dwm] DWM 4.6 Using 45% CPU on idle???
This is ~100% of a single cpu on a dual core. So you'll be looping up a cpu, check the while : ; do .. done loop in your .xinitrc. Does it contains a sleep N ? On Sun, Nov 11, 2007 at 06:29:06PM -0800, Jonny Gerold wrote: Hello, I have a big problem. I have a brand new Thinkpad X61, and I'm using DWM 4.6 on Archlinux, and on idle something uses 45% of my CPU. And it's only when I use dwm. I tried starting up fluxbox, and there is no issue? I have an intel core duo, and I don't know what might be causing the problem. Any help would be much appreciated. Thanks, Jonny
[dwm] viewprevtag bug
It doesn't check if the previous and the current seltags are the same: - for example: * META+1 * META+2 * META+1 * META+1 * META+Tab - useless a simple memcmp before the memcpy should fix that. --pancake
Re: [dwm] RESIZEHINTS gone in 4.6, how to get the old behaviour?
I think this is the best option. Thanks On Fri, Nov 02, 2007 at 10:45:04AM +0100, Anselm R. Garbe wrote: Well I decided that 4.7 will include the RESIZEHINTS macro again, but they will be enabled by default (like 4.6 default behavior). hg tip includes a patch accordingly. Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
