Re: [dwm] dwm's future
On Thu, Apr 30, 2009 at 03:44:46PM +0200, Matthias Kirschner wrote: > hi Szabolcs, > > * Szabolcs Nagy [2009-04-29 13:37:17 +0200]: > > > On 4/28/09, Matthias Kirschner wrote: > > > I am very interested in that list. Can you please sent it to me? > > > > > > > cad softwares (and many related formats are closed as well) > > Was already on my list. > > > fpga tool chain > > Thanks, added to my list. Well, for certain ATMEL fpga exists Free Software tools [1], because someone published the bytestream. > Best wishes, > Matthias Regards, Matthias-Christian [1] http://research.cs.berkeley.edu/project/slipway/
Re: [dwm] dwm's future
hi Szabolcs, * Szabolcs Nagy [2009-04-29 13:37:17 +0200]: > On 4/28/09, Matthias Kirschner wrote: > > I am very interested in that list. Can you please sent it to me? > > > > cad softwares (and many related formats are closed as well) Was already on my list. > fpga tool chain Thanks, added to my list. Best wishes, Matthias -- Deputy German Coordinator, Fellowship Coordinator Free Software Foundation Europe (FSFE) [] (http://fsfeurope.org) Join the Fellowship of FSFE! [][][] (http://fsfe.org/join) Your donation powers our work! || (http://fsfeurope.org/donate)
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 10:54:35PM +0200, markus schnalke wrote: > Further more, I want to say, that there are more important things to > focus on, instead of trying to improve (or dis-improve) dwm. `st' is > the best example, of course. Amen to that! It would be nice to see some progress on the st front. Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 04:07:55PM +0200, pancake wrote: > 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?). >From my experience of "porting" dwm to win32[1] I can only say that in theory this sounds like a perfect solution but in practice it won't work because you will have to work around some random misfeatures of the target platform. > 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. Depending on how much callbacks you would need, this will just clutter the dwm source for now obvious benefit. Regards, Marc [1] http://lists.suckless.org/dwm/0904/7891.html -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [dwm] dwm's future
On Wed, Apr 29, 2009 at 7:11 AM, Matthias-Christian Ott wrote: > On Wed, Apr 29, 2009 at 01:37:17PM +0200, Szabolcs Nagy wrote: >> cad softwares (and many related formats are closed as well) > Well, they are not superior or unique. Their formats are just proprietary > and there's no Free Software for that, because the vendors try by all means > to prevent this. This is flat-out wrong. There's nothing in the FOSS world that remoteley competes with something like AutoDesk NavisWorks. Like most of us here, I use mostly free software, but I have to maintain a Windows installation for my wife, who is and engineer. She's really excited about NavisWorks (I could provide a list of other engineering software that has no FOSS competition, too). I've experimented with showing her FOSS alternatives to CAD packages, but she quickly explains (convincingly) why they are basically toys. Take SewerCad. The package name sounds like a joke, but drainage and sewage design is obviously very important, and there's basically nothing out there in the FOSS world. Reverse-engineering the document format is the smallest fraction of the tiniest problem. NavisWorks specifically really is superior and unique. If you're familiar at all with CAD or engineering software watch the screencast[1] (requires flash) and it will blow your mind. [1]-http://www.adskmedia.com/navisworks-engineering/ # Kurt H Maier
Re: [dwm] dwm's future
2009/4/29 Martin Oppegaard : > On Wed, Apr 29, 2009 at 02:08:20PM +0200, Matthias-Christian Ott wrote: >> On Wed, Apr 29, 2009 at 01:05:40PM +0200, Martin Oppegaard wrote: >> > On Wed, Apr 29, 2009 at 12:58:23PM +0200, Preben Randhol wrote: >> > > On Wed, 29 Apr 2009 10:45:35 +0200 >> > > Martin Oppegaard wrote: >> > > >> > > > On Wed, Apr 29, 2009 at 10:35:12AM +0200, Preben Randhol wrote: >> > > > > On Wed, 29 Apr 2009 10:25:55 +0200 >> > > > > Martin Oppegaard wrote: >> > > > > >> > > > > > I like free software. >> > > > > >> > > > > But not GPL? >> > > > > >> > > > It's just another lock in which is getting too big. >> > > > >> > > >> > > Sure, if you want to make proprietary software... >> > > >> > If you want to be free from wacko organisations. >> >> Are you sure, you know what you are talking about? At least all people I >> know from Free Software Foundation Europe are quite friendly and really care >> about Free Software and fight actively against proprietary software. They >> are by no means wackos. > > Of course they are! I'm just being sceptical. > >> >> But as mentioned this discussion could go on and on without a result. >> >> > > -- >> > > Preben Randhol >> >> Regards, >> Matthias-Christian >> > > All opensource license are crap, don't use any of them, keep you're source secure by not publishing it. I mean, these guys who use open source have apparently a very small penis. my 2 cents. -- http://gnuffy.chaotika.org - Real Community Distro
Re: [dwm] dwm's future
On Wed, Apr 29, 2009 at 02:08:20PM +0200, Matthias-Christian Ott wrote: > On Wed, Apr 29, 2009 at 01:05:40PM +0200, Martin Oppegaard wrote: > > On Wed, Apr 29, 2009 at 12:58:23PM +0200, Preben Randhol wrote: > > > On Wed, 29 Apr 2009 10:45:35 +0200 > > > Martin Oppegaard wrote: > > > > > > > On Wed, Apr 29, 2009 at 10:35:12AM +0200, Preben Randhol wrote: > > > > > On Wed, 29 Apr 2009 10:25:55 +0200 > > > > > Martin Oppegaard wrote: > > > > > > > > > > > I like free software. > > > > > > > > > > But not GPL? > > > > > > > > > It's just another lock in which is getting too big. > > > > > > > > > > Sure, if you want to make proprietary software... > > > > > If you want to be free from wacko organisations. > > Are you sure, you know what you are talking about? At least all people I > know from Free Software Foundation Europe are quite friendly and really care > about Free Software and fight actively against proprietary software. They > are by no means wackos. Of course they are! I'm just being sceptical. > > But as mentioned this discussion could go on and on without a result. > > > > -- > > > Preben Randhol > > Regards, > Matthias-Christian >
Re: [dwm] dwm's future
On Wed, Apr 29, 2009 at 01:37:17PM +0200, Szabolcs Nagy wrote: > On 4/28/09, Matthias Kirschner wrote: > > I am very interested in that list. Can you please sent it to me? > > > > cad softwares (and many related formats are closed as well) > > fpga tool chain Well, they are not superior or unique. Their formats are just proprietary and there's no Free Software for that, because the vendors try by all means to prevent this. Regards, Matthias-Christian
Re: [dwm] dwm's future
On Wed, Apr 29, 2009 at 01:05:40PM +0200, Martin Oppegaard wrote: > On Wed, Apr 29, 2009 at 12:58:23PM +0200, Preben Randhol wrote: > > On Wed, 29 Apr 2009 10:45:35 +0200 > > Martin Oppegaard wrote: > > > > > On Wed, Apr 29, 2009 at 10:35:12AM +0200, Preben Randhol wrote: > > > > On Wed, 29 Apr 2009 10:25:55 +0200 > > > > Martin Oppegaard wrote: > > > > > > > > > I like free software. > > > > > > > > But not GPL? > > > > > > > It's just another lock in which is getting too big. > > > > > > > Sure, if you want to make proprietary software... > > > If you want to be free from wacko organisations. Are you sure, you know what you are talking about? At least all people I know from Free Software Foundation Europe are quite friendly and really care about Free Software and fight actively against proprietary software. They are by no means wackos. But as mentioned this discussion could go on and on without a result. > > -- > > Preben Randhol Regards, Matthias-Christian
Re: [dwm] dwm's future
On 4/28/09, Matthias Kirschner wrote: > I am very interested in that list. Can you please sent it to me? > cad softwares (and many related formats are closed as well) fpga tool chain
Re: [dwm] dwm's future
> I like free software. But not GPL? >>> It's just another lock in which is getting too big. >> Sure, if you want to make proprietary software... > If you want to be free from wacko organisations. this fruitful discussion shall end here
Re: [dwm] dwm's future
On Wed, Apr 29, 2009 at 12:58:23PM +0200, Preben Randhol wrote: > On Wed, 29 Apr 2009 10:45:35 +0200 > Martin Oppegaard wrote: > > > On Wed, Apr 29, 2009 at 10:35:12AM +0200, Preben Randhol wrote: > > > On Wed, 29 Apr 2009 10:25:55 +0200 > > > Martin Oppegaard wrote: > > > > > > > I like free software. > > > > > > But not GPL? > > > > > It's just another lock in which is getting too big. > > > > Sure, if you want to make proprietary software... > If you want to be free from wacko organisations. > -- > Preben Randhol >
Re: [dwm] dwm's future
On Wed, 29 Apr 2009 10:45:35 +0200 Martin Oppegaard wrote: > On Wed, Apr 29, 2009 at 10:35:12AM +0200, Preben Randhol wrote: > > On Wed, 29 Apr 2009 10:25:55 +0200 > > Martin Oppegaard wrote: > > > > > I like free software. > > > > But not GPL? > > > It's just another lock in which is getting too big. > Sure, if you want to make proprietary software... -- Preben Randhol
Re: [dwm] dwm's future
Hi yiyus, * yy [2009-04-28 00:03:27 +0200]: > But it is not always possible. I can give you a (quite long) list of > software that doesn't have a free equivalent. I am very interested in that list. Can you please sent it to me? Thanks, Matthias
Re: [dwm] dwm's future
On Wed, Apr 29, 2009 at 10:35:12AM +0200, Preben Randhol wrote: > On Wed, 29 Apr 2009 10:25:55 +0200 > Martin Oppegaard wrote: > > > I like free software. > > But not GPL? > It's just another lock in which is getting too big.
Re: [dwm] dwm's future
On Wed, 29 Apr 2009 10:25:55 +0200 Martin Oppegaard wrote: > I like free software. But not GPL?
Re: [dwm] dwm's future
On Wed, Apr 29, 2009 at 06:52:46AM +0100, Szabolcs Nagy wrote: > On 4/28/09, Martin Oppegaard wrote: > > Are there any BSD-style licensed equivalents? > > > > scipy.org > And use Ipython!
Re: [dwm] dwm's future
On Wed, Apr 29, 2009 at 09:24:14AM +0200, Preben Randhol wrote: > On Tue, 28 Apr 2009 23:41:48 +0200 > Martin Oppegaard wrote: > > > Are there any BSD-style licensed equivalents? > > Why do you need that? > I like free software. > You could also have a look at: http://www.sagemath.org/index.html > Thanks, I'll take a look. > -- > Preben >
Re: [dwm] dwm's future
On Tue, 28 Apr 2009 23:41:48 +0200 Martin Oppegaard wrote: > Are there any BSD-style licensed equivalents? Why do you need that? You could also have a look at: http://www.sagemath.org/index.html -- Preben
Re: [dwm] dwm's future
On 4/28/09, Martin Oppegaard wrote: > Are there any BSD-style licensed equivalents? > scipy.org
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 wrote: > > > That said, in most cases there is now no reason no to choose Matlab > > over Octave. > > > > That said, in most cases there is now no reason to choose Matlab > over Octave. > > Are there any BSD-style licensed equivalents?
Re: [dwm] dwm's future
On Tue, 28 Apr 2009 22:00:07 +0200 Preben Randhol wrote: > That said, in most cases there is now no reason no to choose Matlab > over Octave. > That said, in most cases there is now no reason to choose Matlab over Octave.
Re: [dwm] dwm's future
On Tue, 28 Apr 2009 09:01:20 -0400 Ross Mohn 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 12:46:16 +0200 Christian Garbs wrote: > 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 :-) *Banging head on the desk* Of course! I didn't even think of that! Thanks! Preben
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] 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
2009/4/28 pmarin : > 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 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
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 Sun, Apr 26, 2009 at 5:43 PM, Kurt H Maier wrote: > On Sun, Apr 26, 2009 at 10:01 AM, Mate Nagy wrote: >> I strongly believe that the major problem of dwm currently is >> not font handling (8bit ascii bitmap fonts are perfectly fine thank >> you); > > Agree 100%. Folks, if you want unicode support, develop a sane, > working implementation. Exactly. > I've never seen one that matches both "sane" and "working." http://doc.cat-v.org/plan_9/4th_edition/papers/utf There you go ;) But I agree with your point in the X11 context (although see http://plan9.us) uriel > >> 1. Complete lack of proper xrandr and multi monitor support - this is >> solved in multiple tiling wms, there's no reason other than lack of >> interest or obscure ideology not to do this. > > Here's a patch to make DWM work fine on a two-monitor side-by-side setup: > > --- dwm.c~ 2009-02-08 06:10:49.0 -0600 > +++ dwm.c 2009-02-25 18:54:17.0 -0600 > @@ -1415,7 +1415,7 @@ > c = nexttiled(clients); > mw = mfact * ww; > adjustborder(c, n == 1 ? 0 : borderpx); > - resize(c, wx, wy, (n == 1 ? ww : mw) - 2 * c->bw, wh - 2 * c->bw, > resizehints); > + resize(c, wx, wy, mw - 2 * c->bw, wh - 2 * c->bw, resizehints); > > if(--n == 0) > return; > > > ...that's from dwm 5.4.1, using xrandr --output DVI-0 --right-of > DVI-1. Problem solved. > > # Kurt H Maier > >
Re: [dwm] dwm's future
On Sun, Apr 26, 2009 at 1:57 PM, Haomin Wen wrote: > Hello, > > I am sorry but I really hope dwm can switch to using pango. > > X fonts are broken and not well supported, at least in Ubuntu. I have six > Chinese fonts shown in xlsfonts, but only two of them can be displayed. Then file a bug with the Ubuntu people, why should dwm be forced to depend on a huge mountain of crud just because people building distributions can't even provide working fonts? Peace uriel
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 04:05:36PM -0400, 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. I agree with you on almost all. You don't have to make choice for others. But there is also the concept of mid-path, finding the solution who hasle the less both people. Most of the time you can easily make of doc or xls even if you have to export to a txt or csv and do a little formatinf but this is not always the case. There is no reason to refuse a pdf and ask for doc, in particular in academic world if you have mathematical contents in. I've tryed more than one time to use the Word and OpenOffice equation editor and it take very long time to write even a small formula, when it's almost to cost to write it in tex and compile to pdf. In this case it's almost impossible to convert to doc and pdf is enough used to be an acceptable format for almost anyone. But I've seen people refusing it in such case and ask or doc. In this case I send a screen capture of the formula but I will never take a long time to make a doc for such 'bigot'. This is a special case but it's not the only one. I'm not fanboy of free softwares, I use the best soft for my needs I can find and try to make all I can to adapt to other people, but I think there is some limits people have to understand and accept to also make a little effort. -- Thomas Lavergne"Entia non sunt multiplicanda praeter necessitatem." (Guillaume d'Ockham) [email protected]://oniros.org
OT: Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 08:55:04PM +0200, Matthias-Christian Ott 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. > this is abit off topic, but fortran is still king for numerical computing :P many major numerical simulations for computational chemistry and physics (maths too i guess) are written in f90 and continue to be written in the newer fortran standards. and octave as nice as it is often isn't prefered by scientists as it at times lacks features that these people want (for whatever reason either performance or features). jimmy. -- Sent from my Nokia mobile phone pgprrKS7BMGnX.pgp Description: PGP signature
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 08:47:33PM +0200, Matthias-Christian Ott wrote: > That's mainly proprietary software. dwm shouldn't support that kind of > software, but instead expose their bare brokenness to the user. Maybe users > will realise then that proprietary software is not worth using, because you > can't even fix trivial bugs like this. > i wouldn't say no to supporting such software tbh, there are some commercial/propietry software where there is just has no opensource equivalent too that would give the same amount of productivity. it should be at least considered. some people have no choice but to use such programs. jimmy -- Sent from my Nokia mobile phone pgpCEgsd794Q8.pgp Description: PGP signature
Re: [dwm] dwm's future
On Mon, 27 Apr 2009 22:54:35 +0200 markus schnalke wrote: > Important is IMO to define a clear goal and to follow a straight path > to this goal. This is not only for the competition with other WMs but > also for keeping the software clear. Yes, I wanted at one point to try out xmonad, but when that entailed installing 64Mb worth of packages (ubuntu) I canceled the installed. 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.
Re: [dwm] dwm's future
2009/4/27 Matthias-Christian Ott : > At least you didn't loose your dignity, carried out your principles and > proofed that Free Software is as powerful as an expensive proprietary > software. > But it is not always possible. I can give you a (quite long) list of software that doesn't have a free equivalent. Between other things, my work involves a lot of mechanical testing, and even if developing your own easy solution would be straightforward you have to use the nonsense 1gb of ram proprietary (and usually windows) application because it is the industry standard. The argument about free software is a non-end disucssion. The matter is: there are broken applications, do we want to use dwm to manage their windows? I would prefer keeping it as suckless as possible, as somebody else suggested. dwm makes a great job managing windows, it is not its job to fix font handling or work around broken applications. However, I liked the idea of a "suckless font library", but it will have to suck a lot (i.e. include pango) to work perfectly with every language on earth. -- - yiyus || JGL .
Re: [dwm] dwm's future
I thought you mentioned stopping in the email you sent before this one? (Or was that only applicble to other people?) On Mon, Apr 27, 2009 at 10:30 PM, Matthias-Christian Ott wrote: > On Mon, Apr 27, 2009 at 10:58:31PM +0200, pancake wrote: >> 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. > > At least you didn't loose your dignity, carried out your principles and > proofed that Free Software is as powerful as an expensive proprietary > software. > > Regards, > Matthias-Christian > >> On Apr 27, 2009, at 9:05 PM, Amit Uttamchandani >> 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... >>> >> > > -- cheers, dave tweed__ computer vision reasearcher: [email protected] "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 10:58:31PM +0200, pancake wrote: > 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. At least you didn't loose your dignity, carried out your principles and proofed that Free Software is as powerful as an expensive proprietary software. Regards, Matthias-Christian > On Apr 27, 2009, at 9:05 PM, Amit Uttamchandani > 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... >> >
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 04:05:36PM -0400, Jeremy Jay wrote: > > Don't be a bigot, it just makes you look like a moron too. Free Software Well, you are a moron if you get bad marks, because you didn't hand in your papers, because you refuse to use proprietary software: You don't change anything and just hurt yourself. I always found someone to typeset my texts or just printed them out. It worked in the majority of cases. > is about choice, forcing people to use an app just because you use it is No, not because I use it, just because it's Free Software. That's the fact that matters. > 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 They don't let their students choose either. > easy to save as .xls or .doc, and its much less hassle for those less > tech literate. Still you are using pragmatic arguments to invalidate my fundamental arguments. We'll never come to an agreement then. It's not about the ease of use, it's about the nature of the software itself. I would even use Free Software if it's harder to use and less powerful. In fact I do this on daily basis. I partially agree that this is hard to explain these kind of persons (not because they are to stupid or not skilled enough to understand this, but because they don't want to listen or understand it). > Professors choose to use the software they want because they're > comfortable with it, not to spite you. But its their duty to provide equal access and opportunity to their students. If they require their students to use proprietary software, don't fullfil that duty, despite the fact that proprietary software is a contradiction to education. Well, this discussion will lead is just more E-Mail traffic and wasted time, so I suggest to do everyone a favour and stop here. All relevant arguments have been mentioned and further discussion won't yield a result. > Jeremy Regards, Matthias-Christian > On Mon 27 Apr 2009 - 09:38PM, Matthias-Christian Ott wrote: > > On Mon, Apr 27, 2009 at 12:05:57PM -0700, Amit Uttamchandani 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... > > > > Most teachers are morons. I tried to convince some of mine to switch to Free > > Software or accept non-Microsoft formats, such as PDF or PostScript, but > > they either refused to listen or thought Free Software is evil and accused > > me of using pirated software, etc. (of course I listed all four freedoms > > they have with Free Software and tried explain to them what Free Software > > licenses are about). > > > > The problem with them seems to be that they have been an educational > > authority > > for so long that they think they know everything better and don't have to > > listen. When I was supposed to hand in yet another Microsoft Word or Excel > > file > > (that's quite common), I tried to explain that to one of them, but She said: > > "That's bad luck, search for someone who let's you use his computer!" and > > walked away. > > > > Well, I could go on. However, morons don't justify the use or the > > introduction > > of fixes for this software. > > > > Regards, > > Matthias-Christian > > >
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 06:57:13PM +0200, Preben Randhol wrote: > On Mon, 27 Apr 2009 13:51:24 +0200 > Martin Oppegaard wrote: > > > On Mon, Apr 27, 2009 at 11:47:19AM +0200, Preben Randhol wrote: > > > Personally I would like to have one dwm as is, and one gdwm (or some > > > better name) with more bells and whistles and dependencies. > > > > http://wmii.suckless.org/ > > > > Or is Wmii dead in the water? > > > > Well actually I wan't thinking of wmii as it behaves differently from > dwm. > I can't even remember how Wmii feels like anymore, after changing to Dwm less than a year ago.
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 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...
Re: [dwm] dwm's future
[ pretty off topic ] Three days off-line and now ... *eek* ... 75 new messages. It was interesting to read all those opinions and comments. I think it was even fun, because I'm not directly affected ... not anymore. I already found what I was looking for, more than a year ago. dwm then was already good enough (with some personal modifications). Nonetheless, reading this list is great inspiration and motivation for staying on the suckless track. Now to say some words about the actual topic: Important is IMO to define a clear goal and to follow a straight path to this goal. This is not only for the competition with other WMs but also for keeping the software clear. My personal opinion is that dwm should try to stay small and accept to lose users to the ``fancy'' tiling WMs if this increases the internal clarity and integrity of dwm and the path of its development. But anyway, I don't care much anymore as I stopped with dwm 3.4. So, you may not care about my opinion -- I don't mind. Further more, I want to say, that there are more important things to focus on, instead of trying to improve (or dis-improve) dwm. `st' is the best example, of course. Wish you all a good sleep (if you're from Europe) or a good morning or a nice evening (if you're from somewhere else). meillo signature.asc Description: Digital signature
Re: [dwm] dwm's future
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. Jeremy On Mon 27 Apr 2009 - 09:38PM, Matthias-Christian Ott wrote: > On Mon, Apr 27, 2009 at 12:05:57PM -0700, Amit Uttamchandani 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... > > Most teachers are morons. I tried to convince some of mine to switch to Free > Software or accept non-Microsoft formats, such as PDF or PostScript, but > they either refused to listen or thought Free Software is evil and accused > me of using pirated software, etc. (of course I listed all four freedoms > they have with Free Software and tried explain to them what Free Software > licenses are about). > > The problem with them seems to be that they have been an educational authority > for so long that they think they know everything better and don't have to > listen. When I was supposed to hand in yet another Microsoft Word or Excel > file > (that's quite common), I tried to explain that to one of them, but She said: > "That's bad luck, search for someone who let's you use his computer!" and > walked away. > > Well, I could go on. However, morons don't justify the use or the introduction > of fixes for this software. > > Regards, > Matthias-Christian >
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 12:05:57PM -0700, Amit Uttamchandani 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... Most teachers are morons. I tried to convince some of mine to switch to Free Software or accept non-Microsoft formats, such as PDF or PostScript, but they either refused to listen or thought Free Software is evil and accused me of using pirated software, etc. (of course I listed all four freedoms they have with Free Software and tried explain to them what Free Software licenses are about). The problem with them seems to be that they have been an educational authority for so long that they think they know everything better and don't have to listen. When I was supposed to hand in yet another Microsoft Word or Excel file (that's quite common), I tried to explain that to one of them, but She said: "That's bad luck, search for someone who let's you use his computer!" and walked away. Well, I could go on. However, morons don't justify the use or the introduction of fixes for this software. Regards, Matthias-Christian
Re: [dwm] dwm's future
Kurt H Maier dixit (2009-04-27, 13:54): > "$subject is broken, therefore we must bloat up dwm to work around it" > is bad reasoning, even if $subject is "x11 font rendering" or "some > expensive app my school is forcing on me" The only difference is that you *have* to use X11 font rendering while you do not necessarily have to run above mentioned apps directly in dwm (yes, nested X server with or without a wm seems like a cool solution). So the above is a fallacy. And no, it's not only about displaying weird firefox window titles. There's also the status bar, tag names and such. Displaying unicode (which solution to settle on is another discussion) is not bloating but is realizing the basic fact that 7bit ASCII is too limited for a worldwide dwm audience. Best, -- [a] pgp0x1RweiKfd.pgp Description: PGP signature
Re: [dwm] dwm's future
> > 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...
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 08:50:49PM +0200, Valentin wrote: > On Mon, Apr 27, 2009 at 08:47:33PM +0200, Matthias-Christian Ott wrote: > > On Mon, Apr 27, 2009 at 10:35:20AM +0100, Anselm R Garbe wrote: > > > > That's mainly proprietary software. dwm shouldn't support that kind of > > software, but instead expose their bare brokenness to the user. Maybe users > > will realise then that proprietary software is not worth using, because you > > can't even fix trivial bugs like this. > > 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. > > Regards, > > Matthias-Christian > > Regards, > Valentin Regards, Matthias-Christian
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 1:47 PM, Matthias-Christian Ott wrote: > Could you please briefly explain why you are opposed to XRandR. It seems > pretty common and usable. > Not only that, xinerama is going to be entirely supplanted by xrandr. Developing for xinerama is a dead end. On Mon, Apr 27, 2009 at 1:50 PM, Valentin wrote: > Except some of us don't have a choice and have to use this for their > work or at uni... Perfect candidate for a different window manager, or at least a different window manager in a nested X display. "$subject is broken, therefore we must bloat up dwm to work around it" is bad reasoning, even if $subject is "x11 font rendering" or "some expensive app my school is forcing on me" # Kurt H Maier
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 08:47:33PM +0200, Matthias-Christian Ott wrote: > On Mon, Apr 27, 2009 at 10:35:20AM +0100, Anselm R Garbe wrote: > > That's mainly proprietary software. dwm shouldn't support that kind of > software, but instead expose their bare brokenness to the user. Maybe users > will realise then that proprietary software is not worth using, because you > can't even fix trivial bugs like this. Except some of us don't have a choice and have to use this for their work or at uni... > Regards, > Matthias-Christian Regards, Valentin
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 10:35:20AM +0100, 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 That's mainly proprietary software. dwm shouldn't support that kind of software, but instead expose their bare brokenness to the user. Maybe users will realise then that proprietary software is not worth using, because you can't even fix trivial bugs like this. > 3) I agree multihead has got some preference, I like the approach to > assign certain tags to specific screens. Could you please briefly explain why you are opposed to XRandR. It seems pretty common and usable. > Kind regards, > Anselm Regards, Matthias-Christian
Re: [dwm] dwm's future
On Mon, 27 Apr 2009 13:51:24 +0200 Martin Oppegaard wrote: > On Mon, Apr 27, 2009 at 11:47:19AM +0200, Preben Randhol wrote: > > Personally I would like to have one dwm as is, and one gdwm (or some > > better name) with more bells and whistles and dependencies. > > http://wmii.suckless.org/ > > Or is Wmii dead in the water? > Well actually I wan't thinking of wmii as it behaves differently from dwm.
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 5:45 AM, Preben Ran > well, what is the purpose of a stausbar? It is a minority of the > worlds population that adheres to 7-bit ASCII. Which just makes it more mysterious that nobody has fixed xlib font rendering. > or that one just patch dwm for pango like one need to do for all other > useful patches. As I can see from a patch I got the code won't change > more than a few lines... I hadn't thought of this, but I strongly support a patch like bstack or pertag. That way we can leave the core of dwm alone and people who require hacks and workarounds to display their language can apply them at compile-time. # Kurt H Maier
Re: [dwm] dwm's future
I have been following all the recent discussions and I agree with this 100%. Sent from my BlackBerry -Original Message- From: pancake Date: Mon, 27 Apr 2009 16:07:55 To: dwm mail list Subject: 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
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
On Mon, Apr 27, 2009 at 10:35:20AM +0100, Anselm R Garbe wrote: > - Mathematica (Version?) 7 breaks on the help window - it doesn't get keyboard focus, mouse focus still works. First the layout gets applied to it, then the other windows move back below it. I'm pretty sure that 6 did not have this behaviour, but I can't check because I don't have the install CD anymore. The only other app I can remember at the moment would be netbeans, but that worked with the environment variable trick that I can't remember anymore ;)
Re: [dwm] dwm's future
* David E. Thiel [2009-04-25 13:27:51 -0701]: > On Sat, Apr 25, 2009 at 08:29:12PM +0200, Dusan wrote: > > Please keep bar, that's why dwm is great out of the box. > > Agreed. A window manager should be usable on its own, and have sensible > defaults. Ability to customize is great, but it shouldn't be depended > upon to make for a decent user experience. + 1 to keep the bar. Best wishes, Matthias
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 12:05:11PM +0200, Preben Randhol wrote: > What about xft? Wasn't there a patch for 4.7 (can't find it anymore). > I don't know much about the font systems. I've been using this patch for quite some time with no issues. If anyone wants to see the implementation for reference, it lives here: http://rootshell.be/~polachok/code/dwm-4.7-xft.diff
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 11:47:19AM +0200, Preben Randhol wrote: > Personally I would like to have one dwm as is, and one gdwm (or some > better name) with more bells and whistles and dependencies. http://wmii.suckless.org/ Or is Wmii dead in the water?
Re: [dwm] dwm's future
On Sun, 26 Apr 2009 10:49:55 -0500 Kurt H Maier wrote: > I keep hoping to > see dwm go into a 'steady state' where the only patches are to > maintain compatibility with latest x.org, etc., but instead every time > it seems 'done' we shoot forward into crazy-ass ideas like requiring > an extra 0.5 MB of libraries for a 2k SLOC program, just so people's > firefox titles look better. well, what is the purpose of a stausbar? It is a minority of the worlds population that adheres to 7-bit ASCII. > Instead of porting everything to pango, I suggest leaving it alone, > and the affected users can turn the built-in bar off and use another > status bar program. or that one just patch dwm for pango like one need to do for all other useful patches. As I can see from a patch I got the code won't change more than a few lines...
Re: [dwm] dwm's future
On Mon, 27 Apr 2009 11:10:47 +0100 Anselm R Garbe wrote: > 2009/4/27 Preben Randhol : > > What about xft? Wasn't there a patch for 4.7 (can't find it > > anymore). I don't know much about the font systems. > > One option, though quite half hearted in my opinion. I found on the net that there is an pango patch also. Couldn't one just have pango support as an official supported patch? Then it would be easy to patch the dwm if one wants pango support in dwm and dmenu. I mean pertag, bstack etc... are patches I rather would see incorporated into dwm than pango, but I don't mind that they are not. Keep up the excellent work!
Re: [dwm] dwm's future
Hi there ! 2009/4/27, Anselm R Garbe : > 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) Nice idea. I ever thought dwm's status bar is to deep in the code. > 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. I would prefer plain xlib, but otherwise, as you said, it really sucks for fonthandling. So, yea, it's ok for me :) > 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 What about an compile time switch which turns reparenting on and off globally? I don't see any sense to differ between broken and not broken apps clientwise. This would add to much complexity. And I believe someone who uses Mathematica should not care about some KB of stuctures. Otherwise on an embedded device where one need every free kb, nobody would use these kinds of apps. > 3) I agree multihead has got some preference, I like the approach to > assign certain tags to specific screens. You already tried this between 4.7 and 4.8. That was the time I detached my branch, because there was just no sane way to implement it. I prefere the approach of dwm-gtx, because it's very simple and does not fuck up the tagging concept. > Kind regards, > > Anselm > > -- http://gnuffy.chaotika.org - Real Community Distro
Re: [dwm] dwm's future
2009/4/27 Preben Randhol : > On Sun, 26 Apr 2009 11:11:03 +0100 > Anselm R Garbe wrote: > >> So there are only three ways: >> >> - stick with what we got (don't care if some langs look ugly) >> - use pango and/or cairo or something like that >> - invest some effort into a new font rendering lib (seems to be a hard >> job, esp. if one asks for proper font support which can't be done by >> us) > > What about xft? Wasn't there a patch for 4.7 (can't find it anymore). > I don't know much about the font systems. One option, though quite half hearted in my opinion. Kind regards, --Anselm
Re: [dwm] dwm's future
On Sun, 26 Apr 2009 11:11:03 +0100 Anselm R Garbe wrote: > So there are only three ways: > > - stick with what we got (don't care if some langs look ugly) > - use pango and/or cairo or something like that > - invest some effort into a new font rendering lib (seems to be a hard > job, esp. if one asks for proper font support which can't be done by > us) What about xft? Wasn't there a patch for 4.7 (can't find it anymore). I don't know much about the font systems. Preben
Re: [dwm] dwm's future
On Sat, 25 Apr 2009 19:23:50 +0100 Anselm R Garbe wrote: > Hi there, > > I discussed several stuff on IRC recently but wanted to share my > thoughts here. > > 1. One idea is getting rid of the dwm bar altogether and to print the > dwm state to stdout when it changes, however after thinking carefully > about it I conclude that having the bar build-in is definately a > stayer. It's so much simpler than the hassle with an external bar, not > worth it. So very unlikely. Yes, please please keep the bar. I really like it and that it works out of the box. > 2. Another idea is to switch to another dependency for the rendering > bit which could possibly be cairo. After all I'm nearly giving up the > hope that X font handling will ever be fixed and work properly, so > that relying on a pile of other crap seems to become a solution. cairo > is a dependency for firefox and I guess that every dwm user uses > firefox occasionally. And we might benefit from a little bit smoother > looking dwm (same for dmenu of course and my ongoing st efforts). I > think this idea is quite likely. I have no problem with how dwm looks now (except for unicode problems, but that is a font issue). I like the simpler more retro look. Do you mean to use cairo for rendering fonts or also the dmenu itself? Personally I would like to have one dwm as is, and one gdwm (or some better name) with more bells and whistles and dependencies. Or that one can patch cairo support if one want it. For older computers/netbooks (power saving) it is nice to still have a simple wm that is not dependent on MSLOC of libraries. For modern computers it could be nice with some better font handling I guess. I mean I have cairo installed on all my computers, but I don't have the development packages, so if I need that as well to compile dwm, then there will be a lot of extra Mbs. For my worksstation that is fine, but for a netbook with limited SSD... For me the great selling point of dwm is that it makes me more productive as I don't need to do any window moving/resizing etc... > 3. A third idea for legacy support is, that I tend to add a > compile-time option or a specific Rule extension that let's you set to > reparent all clients or certain clients which are broken such as > Mathematica or various Swing apps, though I'm not absolutely sure how > likely that is. Somehow my inner feelings are against it, because it's > not a dwm problem and those broken apps should be fixed. Not a problem for me now, so I don't know if this is needed. For me it is more important to have working patches to add pertag, bstack and perhaps fibonaccio (will test this when I change to dwm on my workstation).
Re: [dwm] dwm's future
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
On Sun, Apr 26, 2009 at 08:15:40AM -0500, Kurt H Maier wrote: > I may be be in the minority here, but ASCII works wonderfully, and I'm > happy with the state of font rendering in dwm. +1 -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [dwm] dwm's future
On Sun, Apr 26, 2009 at 4:26 PM, Evgeny Grablyk wrote: > Why not make statusbar a (default) compile-time option, and add > possibility to export all statusbar information? This way user can > choose between builtin statusbar, or make his own. To make things more > simple, mouseclick support for statusbar should be removed. One thing that's interesting is that no-one ever quantifies in what manner things become simpler: for the programmers, for the user or some other metric? I'll reiterate a point that I've made in the past that I don't really care about number of lines of code providing that the application provides the appropriate level of self-consistent functionality (ie, the amount of functionality that makes sense at this point in the software stack). Some of my custom tile() implementations involve many more lines of quite intricate code that nevertheless gives a "sophisticated but predictable" behaviour when I'm a user. In particular, when I'm on a desktop machine with a mouseI often use clicks on the tags to manipulate the view. I'd be sad if that simple, predictable functionality were removed simply because it means a lower SLOC number can be quoted. (This is probably flamebait, but for some reason the phrase "Cargo Cult" comes to mind.) -- cheers, dave tweed__ computer vision reasearcher: [email protected] "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
Re: [dwm] dwm's future
On Sun, Apr 26, 2009 at 2:08 PM, David E. Thiel wrote: > Agreed. Proven fact: non-English-speaking people exist. Minimalism and > simplicity shouldn't exclude basic functionality like displaying > characters in the language the user speaks. Rendering thousands of different codesets is not "basic functionality." Proven (in this very thread) fact: nobody has yet come up with a suckless way to display unicode. If x11's font rendering is broken, fix it -- don't bloat up client software to work around it. # Kurt H Maier
Re: [dwm] dwm's future
On Sun, Apr 26, 2009 at 05:09:26PM +0200, Antoni Grzymala wrote: > Mate Nagy dixit (2009-04-26, 17:01): > > However, I strongly believe that the major problem of dwm currently is > > not font handling (8bit ascii bitmap fonts are perfectly fine thank > > you); > > This is a very selfish view. 8-bit character sets suck big way, even not > considering anything outside accented latin characters (which either > work or not, usually not quite). Agreed. Proven fact: non-English-speaking people exist. Minimalism and simplicity shouldn't exclude basic functionality like displaying characters in the language the user speaks.
Re: [dwm] dwm's future
Hi There! > 3. A third idea for legacy support is, that I tend to add a > compile-time option or a specific Rule extension that let's you set to > reparent all clients or certain clients which are broken such as > Mathematica or various Swing apps, though I'm not absolutely sure how > likely that is. Somehow my inner feelings are against it, because it's > not a dwm problem and those broken apps should be fixed. I believe that a compile time switch in rules is unneccessary. If we want to support these b0rken apps, why not reparent any client? regard Gottox
Re: [dwm] dwm's future
Hi, I never look at the windows titles. I only look at the tags in the status bar. So for me, this font rendering problem is less important than this problem : handling several monitors. I agree with Mate Nagy about dwm handling correctly several monitors. My point of view is that we should have Client *clients[NUMBER_OF_MONITORS] and manage each monitor independantly. But we should be able to move a window from a monitor to another and alsa an entire tag. I agree with Jeremy Jay about a system of plugins... So that dwm stay very simple and one can build a nice status bar with cairo or pango dependencies if he wants. Why not implement this ? -- Kind regards Guillaume Quintin
Re: [dwm] dwm's future
On Sun, Apr 26, 2009 at 10:45 AM, Mate Nagy wrote: >> ...that's from dwm 5.4.1, using xrandr --output DVI-0 --right-of >> DVI-1. Problem solved. > well obviously i had something more sophisticated in mind :) > like, horribile dictu, displaying different tags or different layouts > on different monitors. or supporting more monitors than 2... Okay, so I was being a bit of a smartass there :) I really think that such cases are best left to a window manager that tries to 'do everything' -- dwm is perfect for one (or two, in my case) large monitor, and it handles it very well. I keep hoping to see dwm go into a 'steady state' where the only patches are to maintain compatibility with latest x.org, etc., but instead every time it seems 'done' we shoot forward into crazy-ass ideas like requiring an extra 0.5 MB of libraries for a 2k SLOC program, just so people's firefox titles look better. Instead of porting everything to pango, I suggest leaving it alone, and the affected users can turn the built-in bar off and use another status bar program. # Kurt H Maier
Re: [dwm] dwm's future
> ...that's from dwm 5.4.1, using xrandr --output DVI-0 --right-of > DVI-1. Problem solved. well obviously i had something more sophisticated in mind :) like, horribile dictu, displaying different tags or different layouts on different monitors. or supporting more monitors than 2... M.
Re: [dwm] dwm's future
On Sun, Apr 26, 2009 at 10:01 AM, Mate Nagy wrote: > I strongly believe that the major problem of dwm currently is > not font handling (8bit ascii bitmap fonts are perfectly fine thank > you); Agree 100%. Folks, if you want unicode support, develop a sane, working implementation. I've never seen one that matches both "sane" and "working." > 1. Complete lack of proper xrandr and multi monitor support - this is > solved in multiple tiling wms, there's no reason other than lack of > interest or obscure ideology not to do this. Here's a patch to make DWM work fine on a two-monitor side-by-side setup: --- dwm.c~ 2009-02-08 06:10:49.0 -0600 +++ dwm.c 2009-02-25 18:54:17.0 -0600 @@ -1415,7 +1415,7 @@ c = nexttiled(clients); mw = mfact * ww; adjustborder(c, n == 1 ? 0 : borderpx); - resize(c, wx, wy, (n == 1 ? ww : mw) - 2 * c->bw, wh - 2 * c->bw, resizehints); + resize(c, wx, wy, mw - 2 * c->bw, wh - 2 * c->bw, resizehints); if(--n == 0) return; ...that's from dwm 5.4.1, using xrandr --output DVI-0 --right-of DVI-1. Problem solved. # Kurt H Maier
Re: [dwm] dwm's future
Hi, Why not make statusbar a (default) compile-time option, and add possibility to export all statusbar information? This way user can choose between builtin statusbar, or make his own. To make things more simple, mouseclick support for statusbar should be removed. As about cairo/pango, again, why not make that optional? Or will that add much code and so increase dwm's own complexity? -- Evgeny
Re: [dwm] dwm's future
On Sun, 26 Apr 2009, Haomin Wen wrote: > I do not care antialias or hinting if there are bitmap fonts, but they > are necessary when using some truetype fonts. I use dmenu to show how > fonts are broken. > > https://www.getdropbox.com/gallery/957017/1/dwm?h=fb5e6b Thanks, I follow you example by echo "nei hou" but the "nei" always become "Dc", not sure if this a problem in dmenu or not. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 唐詩013 王維 送別 下馬飲君酒 問君何所之 君言不得意 歸臥南山陲 但去莫復聞 白雲無盡時
Re: [dwm] dwm's future
Mate Nagy dixit (2009-04-26, 17:01): > However, I strongly believe that the major problem of dwm currently is > not font handling (8bit ascii bitmap fonts are perfectly fine thank > you); This is a very selfish view. 8-bit character sets suck big way, even not considering anything outside accented latin characters (which either work or not, usually not quite). Agree with the rest of your points. -- [a]
Re: [dwm] dwm's future
Hi all, I'm sure there is a severe risk of this piece being understood as flamebait (this is not my intention). However, I strongly believe that the major problem of dwm currently is not font handling (8bit ascii bitmap fonts are perfectly fine thank you); not the status bar (it's great); instead, it's twofold: 1. Complete lack of proper xrandr and multi monitor support - this is solved in multiple tiling wms, there's no reason other than lack of interest or obscure ideology not to do this. 2. Handling of broken applications (reparenting). Not many tiling wms get this right. I believe a good solution is to unconditionally reparent all windows. This adds some code, but means no difference to the user (the window "frame" can still be a single pixel border, if you like), however it fixes all/most incompatibility problems in a single stroke. NB. the added complexity of unconditional reparenting is massively smaller than using pango (especially if you consider the dependencies); the achieved improvement in perceived user experience is also arguably much larger. Regards, Mate
Re: [dwm] dwm's future
I do not care antialias or hinting if there are bitmap fonts, but they are necessary when using some truetype fonts. I use dmenu to show how fonts are broken. https://www.getdropbox.com/gallery/957017/1/dwm?h=fb5e6b On Sun, Apr 26, 2009 at 10:13 PM, bill lam wrote: > On Sun, 26 Apr 2009, Haomin Wen wrote: >> Hello, >> >> I am sorry but I really hope dwm can switch to using pango. >> >> X fonts are broken and not well supported, at least in Ubuntu. I have six >> Chinese fonts shown in xlsfonts, but only two of them can be displayed. Two >> of them only support 16 pixel and 24 pixel size. They are too large, given >> that my dpi is as low as 75. The other font is arphic ukai, but it is not >> bitmap font, and therefore broken. WenQuanYi Bitmap Song is a nice bitmap >> font and covers many encodings, but I can use it for no obvious reason. >> >> It seems to me that pango's powerfulness comes with almost no cost. >> >> For programmers, there is little difference, or at least it generally will >> not increase SLOC. >> >> For users, they just need to set the font to something like "Sans-10" or >> "Monosapce-10". It is much simpler than setting X fonts. Besides, fontconfig >> is powerful. User can set spacing, priority, antialias, hinting, and a lot >> more properties of fonts, which is necessary for certain fonts. > > Can you give examples, eg url where its title failed to displayed > properly using firefox? I use debian and previosly ubuntu and found > no problems. Not sure why correlate bitmap font to broken or not? > What do you mean by broken? Can you give some screen shoot. Does > that really matter to have antialias or hinting in the single line > bar? > > -- > regards, > > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > 唐詩150 劉禹錫 蜀先主廟 >天地英雄氣 千秋尚凜然 勢分三足鼎 業復五銖錢 >得相能開國 生兒不象賢 淒涼蜀故妓 來舞魏宮前 > >
Re: [dwm] dwm's future
On Sun, 26 Apr 2009, Haomin Wen wrote: > Hello, > > I am sorry but I really hope dwm can switch to using pango. > > X fonts are broken and not well supported, at least in Ubuntu. I have six > Chinese fonts shown in xlsfonts, but only two of them can be displayed. Two > of them only support 16 pixel and 24 pixel size. They are too large, given > that my dpi is as low as 75. The other font is arphic ukai, but it is not > bitmap font, and therefore broken. WenQuanYi Bitmap Song is a nice bitmap > font and covers many encodings, but I can use it for no obvious reason. > > It seems to me that pango's powerfulness comes with almost no cost. > > For programmers, there is little difference, or at least it generally will > not increase SLOC. > > For users, they just need to set the font to something like "Sans-10" or > "Monosapce-10". It is much simpler than setting X fonts. Besides, fontconfig > is powerful. User can set spacing, priority, antialias, hinting, and a lot > more properties of fonts, which is necessary for certain fonts. Can you give examples, eg url where its title failed to displayed properly using firefox? I use debian and previosly ubuntu and found no problems. Not sure why correlate bitmap font to broken or not? What do you mean by broken? Can you give some screen shoot. Does that really matter to have antialias or hinting in the single line bar? -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 唐詩150 劉禹錫 蜀先主廟 天地英雄氣 千秋尚凜然 勢分三足鼎 業復五銖錢 得相能開國 生兒不象賢 淒涼蜀故妓 來舞魏宮前
Re: [dwm] dwm's future
You could add an option to print the window title to stdout. This way if somebody wants to pipe it to an external program to show window titles (like dzen on top of the dwm bar), they can. -- - yiyus || JGL .
Re: [dwm] dwm's future
On Sun, Apr 26, 2009 at 9:15 PM, Kurt H Maier wrote: > > On Sun, Apr 26, 2009 at 6:57 AM, Haomin Wen wrote: > > For programmers, there is little difference, or at least it generally will > > not increase SLOC. > Yes, but at the cost of dragging in a huge chain of libraries, which > is insanity. Just because you can't see the complexity doesn't mean > it's not there. > > > For users, they just need to set the font to something like "Sans-10" or > > "Monosapce-10". It is much simpler than setting X fonts. Besides, fontconfig > > is powerful. User can set spacing, priority, antialias, hinting, and a lot > > more properties of fonts, which is necessary for certain fonts. > > Not only can the user set these things, the user *has to*, because > otherwise his screen is an unreadable mess. Most users need not set these things by themselves. Distributions and font makers can do this work for them. Many students in my school said that they are well pleased with the default Chinese font looking in Ubuntu 9.04. Of course distributions and font makers could have provide better support for X fonts, but it seems that they are losing interests on X fonts. I prefer X fonts years ago. At that time Debian support X fonts fairly well, but now some tools, dfontmgr for example, are no longer supported. Even if some people have certain special needs, dwm built with pango will probably not be a problem for them. Anyway most people use firefox or some other soft which also depend on fontconfig, hence they need to tune fontconfig soon or later. > > I may be be in the minority here, but ASCII works wonderfully, and I'm > happy with the state of font rendering in dwm. > > # Kurt H Maier >
Re: [dwm] dwm's future
On Sun, Apr 26, 2009 at 6:57 AM, Haomin Wen wrote: > For programmers, there is little difference, or at least it generally will > not increase SLOC. Yes, but at the cost of dragging in a huge chain of libraries, which is insanity. Just because you can't see the complexity doesn't mean it's not there. > For users, they just need to set the font to something like "Sans-10" or > "Monosapce-10". It is much simpler than setting X fonts. Besides, fontconfig > is powerful. User can set spacing, priority, antialias, hinting, and a lot > more properties of fonts, which is necessary for certain fonts. Not only can the user set these things, the user *has to*, because otherwise his screen is an unreadable mess. I may be be in the minority here, but ASCII works wonderfully, and I'm happy with the state of font rendering in dwm. # Kurt H Maier
Re: [dwm] dwm's future
Oh, sorry. There is a typo. Three but not two Chinese fonts can be displayed. Two of them are too large, and the third one is not bitmap font. On Sun, Apr 26, 2009 at 7:57 PM, Haomin Wen wrote: > Hello, > > I am sorry but I really hope dwm can switch to using pango. > > X fonts are broken and not well supported, at least in Ubuntu. I have six > Chinese fonts shown in xlsfonts, but only two of them can be displayed. Two > of them only support 16 pixel and 24 pixel size. They are too large, given > that my dpi is as low as 75. The other font is arphic ukai, but it is not > bitmap font, and therefore broken. WenQuanYi Bitmap Song is a nice bitmap > font and covers many encodings, but I can use it for no obvious reason. > > It seems to me that pango's powerfulness comes with almost no cost. > > For programmers, there is little difference, or at least it generally will > not increase SLOC. > > For users, they just need to set the font to something like "Sans-10" or > "Monosapce-10". It is much simpler than setting X fonts. Besides, fontconfig > is powerful. User can set spacing, priority, antialias, hinting, and a lot > more properties of fonts, which is necessary for certain fonts. > > Of course pango is not as comman as xlib, and it even depends on Cairo, but > it works. > > Sincerely, > > Haomin Wen > > On Sun, Apr 26, 2009 at 6:38 PM, Anselm R Garbe wrote: > >> 2009/4/26 Szabolcs Nagy : >> > On 4/25/09, Anselm R Garbe wrote: >> >> 1. One idea is getting rid of the dwm bar altogether and to print the >> >> dwm state to stdout when it changes, however after thinking carefully >> >> about it I conclude that having the bar build-in is definately a >> >> stayer. It's so much simpler than the hassle with an external bar, not >> >> worth it. So very unlikely. >> > >> > if external bar is a hassle then inter-process communication is broken >> > in our systems >> > >> > if built-in bar is a hassle then x is broken (unable to display text) >> >> Well, an external bar is a hassle because it would increase the >> overall complexity if it's assumed to be implemented properly (or in a >> fashion like what we got). One has to specify handling where the bar >> appears, which size, and all kinds of interface handling between the >> bar and dwm. >> >> >> 2. Another idea is to switch to another dependency for the rendering >> >> bit which could possibly be cairo. After all I'm nearly giving up the >> >> hope that X font handling will ever be fixed and work properly, >> > >> > $ du -h /usr/lib/libcairo.a >> > 608K/usr/lib/libcairo.a >> > >> > pango seems to be slightly smaller, but i don't know what these libs >> > do exactly.. >> >> They do fairly more than what we need for a single bar. So let's stick >> to what we got. >> >> > imo it's not suckless, but it can be a temporary solution until x is >> fixed >> >> Knowing who drives the X development I gave up any hope that X will >> ever be fixed, more the contrary. >> >> I think the only solution is dws, which needs more assistance and >> which can be based on legacy crap. Important is that dws provides >> decent interfaces and possibly a legacy X interface on top of it. I >> think that's the long term plan we should achieve. But it'll take a >> long time with the resources we got atm (I hoped GSoC would sponsor us >> somehow to get started into that direction). >> >> >> 3. A third idea for legacy support is, that I tend to add a >> >> compile-time option or a specific Rule extension that let's you set to >> >> reparent all clients or certain clients which are broken >> > >> > rule extension won't work as these applications tend not to set >> > class,instance,name properly >> >> Yea that's a pity and that makes the rules more questionable, perhaps >> I should make them simpler or changing the mechanism eg having a >> "catch next map" function instead which applies a certain rule to the >> next window which is mapped. >> >> Kind regards, >> --Anselm >> >> >
Re: [dwm] dwm's future
Hello, I am sorry but I really hope dwm can switch to using pango. X fonts are broken and not well supported, at least in Ubuntu. I have six Chinese fonts shown in xlsfonts, but only two of them can be displayed. Two of them only support 16 pixel and 24 pixel size. They are too large, given that my dpi is as low as 75. The other font is arphic ukai, but it is not bitmap font, and therefore broken. WenQuanYi Bitmap Song is a nice bitmap font and covers many encodings, but I can use it for no obvious reason. It seems to me that pango's powerfulness comes with almost no cost. For programmers, there is little difference, or at least it generally will not increase SLOC. For users, they just need to set the font to something like "Sans-10" or "Monosapce-10". It is much simpler than setting X fonts. Besides, fontconfig is powerful. User can set spacing, priority, antialias, hinting, and a lot more properties of fonts, which is necessary for certain fonts. Of course pango is not as comman as xlib, and it even depends on Cairo, but it works. Sincerely, Haomin Wen On Sun, Apr 26, 2009 at 6:38 PM, Anselm R Garbe wrote: > 2009/4/26 Szabolcs Nagy : > > On 4/25/09, Anselm R Garbe wrote: > >> 1. One idea is getting rid of the dwm bar altogether and to print the > >> dwm state to stdout when it changes, however after thinking carefully > >> about it I conclude that having the bar build-in is definately a > >> stayer. It's so much simpler than the hassle with an external bar, not > >> worth it. So very unlikely. > > > > if external bar is a hassle then inter-process communication is broken > > in our systems > > > > if built-in bar is a hassle then x is broken (unable to display text) > > Well, an external bar is a hassle because it would increase the > overall complexity if it's assumed to be implemented properly (or in a > fashion like what we got). One has to specify handling where the bar > appears, which size, and all kinds of interface handling between the > bar and dwm. > > >> 2. Another idea is to switch to another dependency for the rendering > >> bit which could possibly be cairo. After all I'm nearly giving up the > >> hope that X font handling will ever be fixed and work properly, > > > > $ du -h /usr/lib/libcairo.a > > 608K/usr/lib/libcairo.a > > > > pango seems to be slightly smaller, but i don't know what these libs > > do exactly.. > > They do fairly more than what we need for a single bar. So let's stick > to what we got. > > > imo it's not suckless, but it can be a temporary solution until x is > fixed > > Knowing who drives the X development I gave up any hope that X will > ever be fixed, more the contrary. > > I think the only solution is dws, which needs more assistance and > which can be based on legacy crap. Important is that dws provides > decent interfaces and possibly a legacy X interface on top of it. I > think that's the long term plan we should achieve. But it'll take a > long time with the resources we got atm (I hoped GSoC would sponsor us > somehow to get started into that direction). > > >> 3. A third idea for legacy support is, that I tend to add a > >> compile-time option or a specific Rule extension that let's you set to > >> reparent all clients or certain clients which are broken > > > > rule extension won't work as these applications tend not to set > > class,instance,name properly > > Yea that's a pity and that makes the rules more questionable, perhaps > I should make them simpler or changing the mechanism eg having a > "catch next map" function instead which applies a certain rule to the > next window which is mapped. > > Kind regards, > --Anselm > >
Re: [dwm] dwm's future
2009/4/26 Szabolcs Nagy : > On 4/25/09, Anselm R Garbe wrote: >> 1. One idea is getting rid of the dwm bar altogether and to print the >> dwm state to stdout when it changes, however after thinking carefully >> about it I conclude that having the bar build-in is definately a >> stayer. It's so much simpler than the hassle with an external bar, not >> worth it. So very unlikely. > > if external bar is a hassle then inter-process communication is broken > in our systems > > if built-in bar is a hassle then x is broken (unable to display text) Well, an external bar is a hassle because it would increase the overall complexity if it's assumed to be implemented properly (or in a fashion like what we got). One has to specify handling where the bar appears, which size, and all kinds of interface handling between the bar and dwm. >> 2. Another idea is to switch to another dependency for the rendering >> bit which could possibly be cairo. After all I'm nearly giving up the >> hope that X font handling will ever be fixed and work properly, > > $ du -h /usr/lib/libcairo.a > 608K /usr/lib/libcairo.a > > pango seems to be slightly smaller, but i don't know what these libs > do exactly.. They do fairly more than what we need for a single bar. So let's stick to what we got. > imo it's not suckless, but it can be a temporary solution until x is fixed Knowing who drives the X development I gave up any hope that X will ever be fixed, more the contrary. I think the only solution is dws, which needs more assistance and which can be based on legacy crap. Important is that dws provides decent interfaces and possibly a legacy X interface on top of it. I think that's the long term plan we should achieve. But it'll take a long time with the resources we got atm (I hoped GSoC would sponsor us somehow to get started into that direction). >> 3. A third idea for legacy support is, that I tend to add a >> compile-time option or a specific Rule extension that let's you set to >> reparent all clients or certain clients which are broken > > rule extension won't work as these applications tend not to set > class,instance,name properly Yea that's a pity and that makes the rules more questionable, perhaps I should make them simpler or changing the mechanism eg having a "catch next map" function instead which applies a certain rule to the next window which is mapped. Kind regards, --Anselm
Re: [dwm] dwm's future
Hi, 2009/4/26 Szabolcs Nagy : > On 4/26/09, Christian Garbs wrote: >> On Sat, Apr 25, 2009 at 11:06:08PM +0100, Szabolcs Nagy wrote: >>> On 4/25/09, Christian Garbs wrote: >>> > work, even without pango or cairo. I have German umlauts as well as >>> > Japanese characters (eg. web page titles from Firefox). >>> >>> try greek or cyrillic >>> i had trouble with those when fonts were loaded with XCreateFontSet >> >> Looks ok to me: >> https://www.cgarbs.de/tmp/dwm-ru.png > > no, that is ugly bold font, same problem with greek > >> Wrong font here? >> https://www.cgarbs.de/tmp/dwm-ar.png > > most likely your font does not cover arabic fonts (iso8859-6) in the given > size > >> Korean does look broken, though: >> https://www.cgarbs.de/tmp/dwm-ko.png > > yes, i get the same result using fixed-14 With the font spec: "-*-*-medium-*-*-*-14-*-*-*-*-*-*-*" I'm able to get proper results including Japanese, Chinese, Korean, Greek, Russian, Hebrew, and Thai with that. Though not all of them are monospaced (Gree and Russian for instance). Arabic doesn't work for me if I'm not increasing the size to 17 or above which is huge... and that's hard to be monospaced anyways. I had a look into pango, well and I agree having such a dependency is not very nice, pango is quite complex for what we need, cairo is bad either for what we require. These achieve pseudo-monospace'ing through scaling, which ends up in more or less equally bad results as using plain X fonts, though perhaps looking a little bit smoother because one doesn't need to declare large fonts. So there are only three ways: - stick with what we got (don't care if some langs look ugly) - use pango and/or cairo or something like that - invest some effort into a new font rendering lib (seems to be a hard job, esp. if one asks for proper font support which can't be done by us) So I think, we stick to what we got after all. The bar stays at it is. I agree there are more interesting problems. Kind regards, --Anselm
Re: [dwm] dwm's future
On 4/26/09, Christian Garbs wrote: > On Sat, Apr 25, 2009 at 11:06:08PM +0100, Szabolcs Nagy wrote: >> On 4/25/09, Christian Garbs wrote: >> > work, even without pango or cairo. I have German umlauts as well as >> > Japanese characters (eg. web page titles from Firefox). >> >> try greek or cyrillic >> i had trouble with those when fonts were loaded with XCreateFontSet > > Looks ok to me: > https://www.cgarbs.de/tmp/dwm-ru.png no, that is ugly bold font, same problem with greek > Wrong font here? > https://www.cgarbs.de/tmp/dwm-ar.png most likely your font does not cover arabic fonts (iso8859-6) in the given size > Korean does look broken, though: > https://www.cgarbs.de/tmp/dwm-ko.png yes, i get the same result using fixed-14
Re: [dwm] dwm's future
On Sat, 25 Apr 2009, Christian Garbs wrote: > On Sat, Apr 25, 2009 at 09:37:56PM +0200, yy wrote: > > > I don't think nobody needs unicode glyphs in their tag names or tile > > symbols, you wouldn't need cairo in dwm > > I'm still using dwm-4.7 (because I did not yet have time to port all > patches to the current version), but Unicode glyphs in status bar > work, even without pango or cairo. I have German umlauts as well as > Japanese characters (eg. web page titles from Firefox). I can display unicode chinese in dwm 5.xx using x11 unicode font (not xft) without patch. It doesn't matter if those fonts are a little ugly compared to xft fonts. So I don't think cairo is needed. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 唐詩146 李益 喜見外弟又言別 十年離亂後 長大一相逢 問姓驚初見 稱名憶舊容 別來滄海事 語罷暮天鐘 明日巴陵道 秋山又幾重
Re: [dwm] dwm's future
On Sat, Apr 25, 2009 at 11:06:08PM +0100, Szabolcs Nagy wrote: > On 4/25/09, Christian Garbs wrote: > > work, even without pango or cairo. I have German umlauts as well as > > Japanese characters (eg. web page titles from Firefox). > > try greek or cyrillic > i had trouble with those when fonts were loaded with XCreateFontSet Looks ok to me: https://www.cgarbs.de/tmp/dwm-ru.png The missing character seems to be a long dash - it's missing in German, too: https://www.cgarbs.de/tmp/dwm-de.png Japanese is perfect: https://www.cgarbs.de/tmp/dwm-ja.png Wrong font here? https://www.cgarbs.de/tmp/dwm-ar.png Korean does look broken, though: https://www.cgarbs.de/tmp/dwm-ko.png Regards Christian -- Christian.Garbs.http://www.cgarbs.de Wenn ein Mann im Wald ruft, und keine Frau hört es, hat er trotzdem Unrecht? signature.asc Description: Digital signature
Re: [dwm] dwm's future
On 4/25/09, Anselm R Garbe wrote: > 1. One idea is getting rid of the dwm bar altogether and to print the > dwm state to stdout when it changes, however after thinking carefully > about it I conclude that having the bar build-in is definately a > stayer. It's so much simpler than the hassle with an external bar, not > worth it. So very unlikely. if external bar is a hassle then inter-process communication is broken in our systems if built-in bar is a hassle then x is broken (unable to display text) > 2. Another idea is to switch to another dependency for the rendering > bit which could possibly be cairo. After all I'm nearly giving up the > hope that X font handling will ever be fixed and work properly, $ du -h /usr/lib/libcairo.a 608K/usr/lib/libcairo.a pango seems to be slightly smaller, but i don't know what these libs do exactly.. imo it's not suckless, but it can be a temporary solution until x is fixed > 3. A third idea for legacy support is, that I tend to add a > compile-time option or a specific Rule extension that let's you set to > reparent all clients or certain clients which are broken rule extension won't work as these applications tend not to set class,instance,name properly
Re: [dwm] dwm's future
In spanish we have a sentence for this: gunfire to kill flies On Sun, Apr 26, 2009 at 12:06 AM, Szabolcs Nagy wrote: > On 4/25/09, Christian Garbs wrote: >> work, even without pango or cairo. I have German umlauts as well as >> Japanese characters (eg. web page titles from Firefox). > > try greek or cyrillic > i had trouble with those when fonts were loaded with XCreateFontSet > >
Re: [dwm] dwm's future
On 4/25/09, Christian Garbs wrote: > work, even without pango or cairo. I have German umlauts as well as > Japanese characters (eg. web page titles from Firefox). try greek or cyrillic i had trouble with those when fonts were loaded with XCreateFontSet
Re: [dwm] dwm's future
Anselm R Garbe wrote: > 2. Another idea is to switch to another dependency for the rendering > bit which could possibly be cairo. After all I'm nearly giving up the > hope that X font handling will ever be fixed and work properly, so > that relying on a pile of other crap seems to become a solution. cairo > is a dependency for firefox and I guess that every dwm user uses > firefox occasionally. And we might benefit from a little bit smoother > looking dwm (same for dmenu of course and my ongoing st efforts). I > think this idea is quite likely. Please, don't depend on such huge library just to get nifty fonts and smooth look, dwm is great because it's very small and depend only on really small range of things - x11-dev, optional xinerama, libc - those are things that you can find everywhere, but linking to cairo will destroy this beauty and simplicity in my opinion. Please, don't do it. btw, fonts are fixed now for me in Debian/Sid
Re: [dwm] dwm's future
On Sat, Apr 25, 2009 at 07:23:50PM +0100, Anselm R Garbe wrote: > > 2. Another idea is to switch to another dependency for the rendering > bit which could possibly be cairo. After all I'm nearly giving up the > hope that X font handling will ever be fixed and work properly, so > that relying on a pile of other crap seems to become a solution. cairo > is a dependency for firefox and I guess that every dwm user uses > firefox occasionally. And we might benefit from a little bit smoother > looking dwm (same for dmenu of course and my ongoing st efforts). I > think this idea is quite likely. > Please keep the dependencies the least, I don't think I can stay with dwm if it needs cairo, I don't have it installed. -- Hi, Wu, Yue
Re: [dwm] dwm's future
On Sat, Apr 25, 2009 at 09:37:56PM +0200, yy wrote: > I don't think nobody needs unicode glyphs in their tag names or tile > symbols, you wouldn't need cairo in dwm I'm still using dwm-4.7 (because I did not yet have time to port all patches to the current version), but Unicode glyphs in status bar work, even without pango or cairo. I have German umlauts as well as Japanese characters (eg. web page titles from Firefox). http://www.cgarbs.de/cgi-bin/gitweb.cgi/dwm-mitch.git?a=blob;f=05_patch_dwm_mitch_utf8widechars.diff Regards Christian -- Christian.Garbs.http://www.cgarbs.de "Der Kopf ist rund, damit das Denken die Richtung ändern kann." (Picabia) signature.asc Description: Digital signature
Re: [dwm] dwm's future
On Sat 25 Apr 2009 - 07:23PM, Anselm R Garbe wrote: > Hi there, > > I discussed several stuff on IRC recently but wanted to share my thoughts > here. > > 1. One idea is getting rid of the dwm bar altogether and to print the > dwm state to stdout when it changes, however after thinking carefully > about it I conclude that having the bar build-in is definately a > stayer. It's so much simpler than the hassle with an external bar, not > worth it. So very unlikely. Don't know how I myself feel about this, but just going to throw it out there... how about a modular plugin-like system? simplify dwm to just call hook lists at various places, and then move the status bar into statusbar.c (or config.h if you're crazy) > 2. Another idea is to switch to another dependency for the rendering > bit which could possibly be cairo. After all I'm nearly giving up the > hope that X font handling will ever be fixed and work properly, so > that relying on a pile of other crap seems to become a solution. cairo > is a dependency for firefox and I guess that every dwm user uses > firefox occasionally. And we might benefit from a little bit smoother > looking dwm (same for dmenu of course and my ongoing st efforts). I > think this idea is quite likely. I think that the plugin system has even more merit in light of this, dwm can stay clean and simple, and the new statusbar.c can expand to have pretty fonts without affecting the size/complexity of dwm.c > 3. A third idea for legacy support is, that I tend to add a > compile-time option or a specific Rule extension that let's you set to > reparent all clients or certain clients which are broken such as > Mathematica or various Swing apps, though I'm not absolutely sure how > likely that is. Somehow my inner feelings are against it, because it's > not a dwm problem and those broken apps should be fixed. > > Please feel free to comment or add other ideas to this list. > > Kind regards, > --Anselm >
Re: [dwm] dwm's future
On Sat, Apr 25, 2009 at 08:29:12PM +0200, Dusan wrote: > Please keep bar, that's why dwm is great out of the box. Agreed. A window manager should be usable on its own, and have sensible defaults. Ability to customize is great, but it shouldn't be depended upon to make for a decent user experience. > No. Adding exceptions will increase code and you can't possibly cover > all broken applications. Yeah, I wouldn't bend over backwards to support these. With wmname, Java apps work fine for me. > > Please feel free to comment or add other ideas to this list. Only things I can think of are better integrated multi-head support (I have yet to try Guillaume's patch) and XCB. It's basically perfect otherwise.
Re: [dwm] dwm's future
2009/4/25, yy : > There is a middle way solution. I just thought about it, and will > probably have its drawbacks, but here it goes: keep a bar with only > the tags and tile symbol and print the sel client title to stdout. > This way you can use an external program (dzen) to render the title > (and status text, of course). I don't think nobody needs unicode > glyphs in their tag names or tile symbols, you wouldn't need cairo in > dwm (but could add it to dzen) and would remove a lot of loc getting > ride of status text and window title. One can export tag names, active tags, layout and active window via root window properties, and handle them with a bunch of shell scripts and dzen2, like it's done in echinus.
Re: [dwm] dwm's future
2009/4/25 yy : > There is a middle way solution. I just thought about it, and will > probably have its drawbacks, but here it goes: keep a bar with only > the tags and tile symbol and print the sel client title to stdout. > This way you can use an external program (dzen) to render the title > (and status text, of course). I don't think nobody needs unicode > glyphs in their tag names or tile symbols, you wouldn't need cairo in > dwm (but could add it to dzen) and would remove a lot of loc getting > ride of status text and window title. > About the reparent call, I don't think is a good idea. There are lots > of dwm similar wms around, and it is very easy changing between them. > I would keep dwm as pure as possible and would let the others to > handle the dirty stuff, but of course I'm not the one who needs to use > those broken apps... Well I like and hate that idea. Those who do not like relying on some other apps won't see the title anymore (just ignoring the status text). On the other hand, purists might not be interested in the title and status text anyways. So definately worth considering! Kind regards, --Anselm
