Re: [dwm] dwm's future
Ok, thanks again for continuing the discussion. My conclusion is as follows: 1) dwm will be slightly redesigned, code-wise. I consider having a less suckish font and drawing abstraction in order to be implemented in different ways (which will also be used by st and dmenu). Officially there will only be X font support as is. But due to this abstraction it'll be possible to implement cairo/pango backends if that seems more suitable for non western glyphs without the need to change any vanilla dwm code. 2) Similiarly I will separate the bar bits into a separate file to make it easy to get rid of the bar if someone prefers going with dzen+xdotool. 3) Regarding the broken apps I need to investigate further. If it's really related to reparenting, it's definately a bug in these apps or in the toolkit (JDK?) they rely on. If that's the case I WON'T introduce kludges to handle them, instead we should file bug reports that these apps get fixed. Particularly if these apps are of commercial nature, it should be the vendor's interest to fix their apps that you as a customer can use them in your preferred environment. You or your organization pays someone license fees I guess so that's just a totally valid request that the vendor fixes these apps. 4) Regarding multihead I will start a separate thread soon what a viable solution might be. Kind regards, Anselm
Re: [dwm] dwm's future
2009/4/28 pmarin pacog...@gmail.com: Try to make the new dependencies optionals. About the broken non-free apps, is not dwm's problem and one solution can be to use a qemu instance with another WM and connect to the host Xwindows server. That won't be a really good solution, the better solution is Xnest. And don't worry about the dependencies, there won't be any more than what we currently got. Kind regards, Anselm
Re: [dwm] dwm's future
Try to make the new dependencies optionals. About the broken non-free apps, is not dwm's problem and one solution can be to use a qemu instance with another WM and connect to the host Xwindows server. On Tue, Apr 28, 2009 at 10:01 AM, Anselm R Garbe garb...@gmail.com wrote: Ok, thanks again for continuing the discussion. My conclusion is as follows: 1) dwm will be slightly redesigned, code-wise. I consider having a less suckish font and drawing abstraction in order to be implemented in different ways (which will also be used by st and dmenu). Officially there will only be X font support as is. But due to this abstraction it'll be possible to implement cairo/pango backends if that seems more suitable for non western glyphs without the need to change any vanilla dwm code. 2) Similiarly I will separate the bar bits into a separate file to make it easy to get rid of the bar if someone prefers going with dzen+xdotool. 3) Regarding the broken apps I need to investigate further. If it's really related to reparenting, it's definately a bug in these apps or in the toolkit (JDK?) they rely on. If that's the case I WON'T introduce kludges to handle them, instead we should file bug reports that these apps get fixed. Particularly if these apps are of commercial nature, it should be the vendor's interest to fix their apps that you as a customer can use them in your preferred environment. You or your organization pays someone license fees I guess so that's just a totally valid request that the vendor fixes these apps. 4) Regarding multihead I will start a separate thread soon what a viable solution might be. Kind regards, Anselm
Re: [dwm] dwm's future
On Tue, Apr 28, 2009 at 12:19:05AM +0200, Preben Randhol wrote: One improvement I just remembered (unless I really have missed an option) would be to add invisible typing to dmenu. Useful if you want to type a password. Set -nb to -nf :-) Regards Christian -- Christian.Garbs.http://www.cgarbs.de Tue nie etwas, bei dem Du nicht tot erwischt werden möchtest.
Re: [dwm] dwm's future
Jeremy Jay wrote: Don't be a bigot, it just makes you look like a moron too. Free Software is about choice, forcing people to use an app just because you use it is pretty stupid and annoying and just gives people a negative association with it. Let people make their own choices. Last I checked it was very easy to save as .xls or .doc, and its much less hassle for those less tech literate. Professors choose to use the software they want because they're comfortable with it, not to spite you. Or maybe they're getting a kick back? -RPM
Re: [dwm] [OT] spp
Kris of wmii fame wrote a wonderful preprocessor/template in a few lines of awk. It is used in werc and I really love it, for some minimal docs see: http://werc.cat-v.org/docs/rc_template_lang The code is included as part of the werc distribution under bin/template.awk Enjoy uriel On Mon, Apr 27, 2009 at 2:45 PM, pancake panc...@youterm.com wrote: Some time ago I started to write a new program to implement a simple preprocessor for doing some over-cpp preprocessing allowing me to use specials preprocessor tags inside the comments of the C code generated by Vala to add some funny hacks on top of it. I was also thinking on many other applications for the same concept, so i tried to keep the code as minimal as possible being able to work with streams or files and in the same time being able to write CGI's using the same preprocessing language. After a month or so I think is time to make it public (it was public since the beggining, but not published :P) So I would like to hear from you ideas, tips, patches, simplifications, etc.. Actually spp works great and can partially emulate spp, pod and other preprocessors using a simple plugin-system (maybe dwm can get some ideas from this plugin system). So at the current state, spp is just a simple preprocessor engine whcih allows to implement different backends for multiple syntaxes or ways to parse the input in C at compile time and then use these rules to generate new data from a set of rules and some basic transformations. Actually i'm thinking on adding templates or some better way for scripting dataj to generate for example an index for a list of items or so, but I want first to let people play with it and the suckless community is probably the best one for getting decent feedback with this kind of minimalistic stuff. hg clone http://news.nopcode.org/miau/hgi/spp/ Thanks for listening ;) --pancake
Re: [dwm] dwm's future
On Tue, 28 Apr 2009 09:01:20 -0400 Ross Mohn rpm...@waxandwane.org wrote: Or maybe they're getting a kick back? -RPM Bullshit! Such slander doe not serve Open Source! The reason for choosing commercial packages is because they have done the job. It is fine to choose an open source alternative, but it has to be able to preform the task, which has not always been true for Octave f.ex. That said, in most cases there is now no reason no to choose Matlab over Octave.
Re: [dwm] dwm's future
On Tue, 28 Apr 2009 22:00:07 +0200 Preben Randhol rand...@pvv.org wrote: That said, in most cases there is now no reason no to choose Matlab over Octave. EDIT That said, in most cases there is now no reason to choose Matlab over Octave. /EDIT
Re: [dwm] dwm's future
On Tue, Apr 28, 2009 at 10:03:47PM +0200, Preben Randhol wrote: On Tue, 28 Apr 2009 22:00:07 +0200 Preben Randhol rand...@pvv.org wrote: That said, in most cases there is now no reason no to choose Matlab over Octave. EDIT That said, in most cases there is now no reason to choose Matlab over Octave. /EDIT Are there any BSD-style licensed equivalents?
Re: [dwm] dwm's future
On 4/28/09, Martin Oppegaard mar...@deathaven.com wrote: Are there any BSD-style licensed equivalents? scipy.org
