Re: [dev] [surf] next release
2009/10/21 Uriel : > Surf should *not* handle downloads or display source, this are clearly > and obviously best handled by external tools and there is zero reason > for them to be part of any browser. I disagree with downloads, because several stuff can't be download without dealing with a valid session and it is a pain to download stuff that requires session info using wget. I have no strong feeling about source viewing, doesn't need to be build-in, but since it's already implemented by webkit the source viewing and profiling info of WebKit might be worth being made accessible through surf, it'll help those who have to debug some web stuff from time to time or that are masochists about analysing JS and overall download performance similar to firebug. Usually no external tool can provide this information correctly. Kind regards, Anselm
Re: [dev] [dwm] Xinerama autocenter issue
2009/10/22 Alex Matviychuk : > I'm floating eclipse across the length of 1.5 monitors using xinerama. > Whenever I use a dialog inside eclipse, it tries to center itself and > considers the center as the center of the first monitor. Is there a > way to fix this? Or is there a better way of streaching apps across > monitors? The dialog that pops up belongs to the monitor of the parent window (eclipse). Hence it's centered on the monitor it belongs to. Stretching things across monitors is not intended to be supported well by dwm's Xinerama support. The best solution for this is buying a bigger screen and telling the monitor vendor that you bought this screen because you are a dwm user ;) Perhaps some screen manufacturer will ring some day when it realises the critical dwm user base ;) Kind regards, Anselm
Re: [dev] [dmenu] Putting key combinations in config.h
2009/10/21 markus schnalke : > [2009-10-21 14:48] Peter John Hartman >> On Wed, 21 Oct 2009, Colin Shea wrote: >> > On Wed, Oct 21, 2009 at 1:15 PM, Peter John Hartman >> > wrote: >> > >> > Can we put the various keybindings used in dmenu >> > in config.h rather than dmenu.c? > >> > But more >> > generally most other suckless apps have the keybindings in config.h, >> > so why >> > not dmenu? > >> > As I stated, it would be better than a parameter passed to dmenu on the >> > command line. > >> 1. I'm glad we agree on the config.h vs. argument-from-commandline vs. >> dmenu.c question. > > Do we really agree? At least, I do not, and I hope you don't also when > you read this mail. Here is my proposal: The insert script execution shortcut will be hard wired into dmenu.c and be ^p. By default it will do nothing. There might be a command line switch to the insert script/command that is executed and read by dmenu to insert at current position. Kind regards, Anselm
[dev] [OFFTOPIC] CAPSLOCKDAY
sORRY FOR THE NOISE, BUT I FIND IT INTERESTING TO SHARE THIS CELEBRATION WITH ALL YOU. tODAY IS THE INTERNATIONAL CAPS LOCK DAY. HTTP://CAPSLOCKDAY.COM hOPE YOU ALL ENJOY. hOPEFULLY THERE IS NO HTML/XML DAY. --PANCAKE
Re: [dev] [OFFTOPIC] CAPSLOCKDAY
On 22/10/2009, pancake wrote: > sORRY FOR THE NOISE, BUT I FIND IT INTERESTING TO SHARE THIS CELEBRATION > WITH > ALL YOU. tODAY IS THE INTERNATIONAL CAPS LOCK DAY. > > HTTP://CAPSLOCKDAY.COM > OH...THANKS! -- = http://jessta.id.au
Re: [dev] [OFFTOPIC] CAPSLOCKDAY
WHEE, THIS PAGE DISPLAYS WHAT CAPSLOCK IS ON A MODEL M :) WHAT IF ONE HAS REMAPPED HIS CAPSLOCK AND USES IT AS DWM MODKEY LIKE ME? REGARDS MORITZ WILHELMY On Thu, Oct 22, 2009 at 09:21:19PM +1100, Jessta wrote: > On 22/10/2009, pancake wrote: > > sORRY FOR THE NOISE, BUT I FIND IT INTERESTING TO SHARE THIS CELEBRATION > > WITH > > ALL YOU. tODAY IS THE INTERNATIONAL CAPS LOCK DAY. > > > > HTTP://CAPSLOCKDAY.COM > > > > OH...THANKS! > > -- > = > http://jessta.id.au >
Re: [dev] [OFFTOPIC] CAPSLOCKDAY
2009/10/22 Moritz Wilhelmy : > WHAT IF ONE HAS REMAPPED HIS CAPSLOCK AND USES IT AS DWM MODKEY LIKE ME? I USE IT AS A CONTROL KEY, AS IT SHOULD BE. Also, this is a highly obnoxious holiday. -- Samuel Baldwin - logik.li
Re: [dev] [surf] next release
On Thu, 22 Oct 2009, Anselm R Garbe wrote: 2009/10/21 Uriel : Surf should *not* handle downloads or display source, this are clearly and obviously best handled by external tools and there is zero reason for them to be part of any browser. I disagree with downloads, because several stuff can't be download without dealing with a valid session and it is a pain to download stuff that requires session info using wget. I have no strong feeling about source viewing, doesn't need to be build-in, but since it's already implemented by webkit the source viewing and profiling info of WebKit might be worth being made accessible through surf, it'll help those who have to debug some web stuff from time to time or that are masochists about analysing JS and overall download performance similar to firebug. Usually no external tool can provide this information correctly. Kind regards, Anselm I agree with Anselm. An in-suff download solution is needed for precisely the reason he gives. Peter
Re: [dev] [surf] next release
On Thu, 22 Oct 2009 08:11:54 -0400 (EDT) Peter John Hartman wrote: > > > On Thu, 22 Oct 2009, Anselm R Garbe wrote: > > > 2009/10/21 Uriel : > >> Surf should *not* handle downloads or display source, this are > >> clearly and obviously best handled by external tools and there is > >> zero reason for them to be part of any browser. > > > > I disagree with downloads, because several stuff can't be download > > without dealing with a valid session and it is a pain to download > > stuff that requires session info using wget. > > > > I have no strong feeling about source viewing, doesn't need to be > > build-in, but since it's already implemented by webkit the source > > viewing and profiling info of WebKit might be worth being made > > accessible through surf, it'll help those who have to debug some web > > stuff from time to time or that are masochists about analysing JS > > and overall download performance similar to firebug. Usually no > > external tool can provide this information correctly. > > > > Kind regards, > > Anselm > > > > I agree with Anselm. An in-suff download solution is needed for > precisely the reason he gives. > > Peter > what consitutes a "session" ? it's something that is maintained serverside and the only way to "stay in it" is usually one or more of: - keeping and sending cookie data - keeping the same ip (and maybe user agent) - requesting the urls they tell you to afaik both curl and wget can use existing cookie storages on your hard disk (and can use the useragent you tell them to), so don't really see the problem. Dieter
Re: [dev] [OFFTOPIC] CAPSLOCKDAY
How annoying, now I have press shift all the time so I get correctly cased characters. What a retarded idea. --Valentin pgpriaBLy6Avt.pgp Description: PGP signature
Re: [dev] [surf] next release
The source looks better in vim (R) This list is write-only and sometimes read is permitted. The problem is that I find no way to get the source of the page from the webkit API. This is why surf implements this by using the API to watch the source. And this is also producing a page reload. So you can keep browsing in source mode if you like which is probably unexpected. About downloads, te only issue to get it right is the cookies, so I would like to be able to get the cookie for a session to use with wget or curl. Btw I still find necessary the contextual menu to get URL of image, URL of link .. Download in a separated window/client/app. Displaying highlighted code on a surf with predefined CSS is weird. On Oct 21, 2009, at 11:54 PM, hiro <23h...@googlemail.com> wrote: But the source looks so neat in the browser... :( This list is not worth reading any more. On Wed, Oct 21, 2009 at 11:47 PM, Uriel wrote: Surf should *not* handle downloads or display source, this are clearly and obviously best handled by external tools and there is zero reason for them to be part of any browser. uriel On Wed, Oct 21, 2009 at 10:14 AM, Enno Boland (Gottox) > wrote: Hi! I'm going to release 0.3 this or next week, depending on how much time I can investigate. Please recheck tip and give feedback, as there are some bigger changes. * persistant/concurrent cookies are working (hopefully) * removing urlbar/searchbar and using dmenu instead * if the window is shrinked below a defined size, the zoom factor is automaticly decreased. This is usefull on small screens and tiling window manager. * searching works from an XProperty now. ToDo for 0.3 release: * get downloads working again. regards Enno
Re: [dev] [dwm] Xinerama autocenter issue
On Thu, Oct 22, 2009 at 08:14:40AM +0100, Anselm R Garbe wrote: > 2009/10/22 Alex Matviychuk : > > I'm floating eclipse across the length of 1.5 monitors using xinerama. > > Whenever I use a dialog inside eclipse, it tries to center itself and > > considers the center as the center of the first monitor. Is there a > > way to fix this? Or is there a better way of streaching apps across > > monitors? > > The dialog that pops up belongs to the monitor of the parent window > (eclipse). Hence it's centered on the monitor it belongs to. > Stretching things across monitors is not intended to be supported well > by dwm's Xinerama support. The best solution for this is buying a > bigger screen and telling the monitor vendor that you bought this > screen because you are a dwm user ;) Perhaps some screen manufacturer > will ring some day when it realises the critical dwm user base ;) > > Kind regards, > Anselm > And the dwm community will get the real big screens cheaper? I like it :-D Regards Moritz Wilhelmy
Re: [dev] [surf] next release
2009/10/22 pancake : > The source looks better in vim (R) I am not 100% sure Webkit does this, though Firefox certainly does. view-source fixes some problems in HTML, so when you copy and paste Web content, it's likely to be actually valid or tidied. `vim http://suckless.org` is good, though I think view-source: could be enabled for the above reason.
Re: [dev] [dwm] Xinerama autocenter issue
yeah, what a great idea... On Thu, Oct 22, 2009 at 2:44 PM, Moritz Wilhelmy wrote: > On Thu, Oct 22, 2009 at 08:14:40AM +0100, Anselm R Garbe wrote: >> 2009/10/22 Alex Matviychuk : >> > I'm floating eclipse across the length of 1.5 monitors using xinerama. >> > Whenever I use a dialog inside eclipse, it tries to center itself and >> > considers the center as the center of the first monitor. Is there a >> > way to fix this? Or is there a better way of streaching apps across >> > monitors? >> >> The dialog that pops up belongs to the monitor of the parent window >> (eclipse). Hence it's centered on the monitor it belongs to. >> Stretching things across monitors is not intended to be supported well >> by dwm's Xinerama support. The best solution for this is buying a >> bigger screen and telling the monitor vendor that you bought this >> screen because you are a dwm user ;) Perhaps some screen manufacturer >> will ring some day when it realises the critical dwm user base ;) >> >> Kind regards, >> Anselm >> > > And the dwm community will get the real big screens cheaper? I like it :-D > > Regards > Moritz Wilhelmy > >
Re: [dev] [OFFTOPIC] CAPSLOCKDAY
On Thu, Oct 22, 2009 at 7:22 AM, Valentin wrote: > How annoying, now I have press shift all the time so I get correctly > cased characters. What a retarded idea. JUST SELECT A FONT THAT DOESN'T INCLUDE LOWER-CASE LETTERS -- # KURT H MAIER
Re: [dev] [surf] next release
* pancake [2009-10-22 14:43]: > The source looks better in vim (R) +1 > About downloads, te only issue to get it right is the cookies, so I > would like to be able to get the cookie for a session to use with wget > or curl. +1 > Btw I still find necessary the contextual menu to get URL of image, URL > of link .. Download in a separated window/client/app. +0.5: 0.5 goes for vimperator keysequence ;y -- stanio_
Re: [dev] [surf] next release
Your way cannot use cookies or keep sessions. The most interesting HTML sources are usually after a login page On Oct 22, 2009, at 2:50 PM, Kai Hendry wrote: 2009/10/22 pancake : The source looks better in vim (R) I am not 100% sure Webkit does this, though Firefox certainly does. view-source fixes some problems in HTML, so when you copy and paste Web content, it's likely to be actually valid or tidied. `vim http://suckless.org` is good, though I think view-source: could be enabled for the above reason.
Re: [dev] [surf] next release
On Thu 22 Oct 2009 at 05:20:44 PDT Dieter Plaetinck wrote: what consitutes a "session" ? it's something that is maintained serverside and the only way to "stay in it" is usually one or more of: - keeping and sending cookie data - keeping the same ip (and maybe user agent) - requesting the urls they tell you to afaik both curl and wget can use existing cookie storages on your hard disk (and can use the useragent you tell them to), so don't really see the problem. It seems to me that the problems being discussed in this subthread arise because the "browser" combines two very distinct concerns: - managing the http traffic to and from the website, which includes the administrative details pertaining to the session - rendering the documents obtained from the website Perhaps we should be thinking about separating them?
Re: [dev] [surf] next release
On 22-10-2009 09:09:25, Charlie Kester wrote: > On Thu 22 Oct 2009 at 05:20:44 PDT Dieter Plaetinck wrote: > > > >what consitutes a "session" ? it's something that is maintained > >serverside and the only way to "stay in it" is usually one or more of: > >- keeping and sending cookie data > >- keeping the same ip (and maybe user agent) > >- requesting the urls they tell you to > > > >afaik both curl and wget can use existing cookie storages on your hard > >disk (and can use the useragent you tell them to), so don't really see > >the problem. > > It seems to me that the problems being discussed in this subthread arise > because the "browser" combines two very distinct concerns: > > - managing the http traffic to and from the website, which includes the > administrative details pertaining to the session > > - rendering the documents obtained from the website > > Perhaps we should be thinking about separating them? > Then we will end up with some shit like uzbl - the browser which cannot browse the web. Regards -- === () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: [dev] [surf] next release
2009/10/22 Charlie Kester : > On Thu 22 Oct 2009 at 05:20:44 PDT Dieter Plaetinck wrote: >> >> what consitutes a "session" ? it's something that is maintained >> serverside and the only way to "stay in it" is usually one or more of: >> - keeping and sending cookie data >> - keeping the same ip (and maybe user agent) >> - requesting the urls they tell you to >> >> afaik both curl and wget can use existing cookie storages on your hard >> disk (and can use the useragent you tell them to), so don't really see >> the problem. > > It seems to me that the problems being discussed in this subthread arise > because the "browser" combines two very distinct concerns: > - managing the http traffic to and from the website, which includes the > administrative details pertaining to the session > > - rendering the documents obtained from the website > > Perhaps we should be thinking about separating them? I'm not against providing a nice integration of external tools like wget into surf, however I have seen downloads that were triggered by some JavaScript and making that work with an external tool sounds like a challenge (unless you don't hack into webkit's resource handler layer). That's why I think having both (built-in default) and possibility for seamless integration of external tool would be best. I'd go that far to keep external tool integration that simple to avoid dealing with session propagation. Kind regards, Anselm
Re: [dev] [surf] next release
On Thu, 22 Oct 2009 18:15:58 +0200 Tadeusz Sośnierz wrote: > On 22-10-2009 09:09:25, Charlie Kester wrote: > > On Thu 22 Oct 2009 at 05:20:44 PDT Dieter Plaetinck wrote: > > > > > >what consitutes a "session" ? it's something that is maintained > > >serverside and the only way to "stay in it" is usually one or more > > >of: > > >- keeping and sending cookie data > > >- keeping the same ip (and maybe user agent) > > >- requesting the urls they tell you to > > > > > >afaik both curl and wget can use existing cookie storages on your > > >hard disk (and can use the useragent you tell them to), so don't > > >really see the problem. > > > > It seems to me that the problems being discussed in this subthread > > arise because the "browser" combines two very distinct concerns: > > > > - managing the http traffic to and from the website, which includes > > the administrative details pertaining to the session > > > > - rendering the documents obtained from the website > > > > Perhaps we should be thinking about separating them? > > > > Then we will end up with some shit like uzbl - the browser which > cannot browse the web. > > Regards > it can browse the web just fine, thank you very much. thanks for the kind words, but let's not go offtopic here.
Re: [dev] [surf] next release
On Thu, Oct 22, 2009 at 02:42:49PM +0200, pancake wrote: > Btw I still find necessary the contextual menu to get URL of image, URL > of link .. Download in a separated window/client/app. I totally agree, it was a good feature that I would also welcome back. At the moment the two lower items of the context menu : Paste URI and Copy URI are doing pretty much the same as ctrl-y ctrl-p but are IMHO not as convenient as the keybindings, replacing these two items with something like "Download linked file" and "Copy link" would be more usefull.
Re: [dev] [surf] next release
[2009-10-22 08:08] Anselm R Garbe > > I have no strong feeling about source viewing, doesn't need to be > build-in, but since it's already implemented by webkit the source > viewing and profiling info of WebKit might be worth being made > accessible through surf, [...] It it's something that bumps the required Webkit version up, then I disagree. IMO the main problem with uzbl/surf is that very new versions of Webkit, which are often not included in operating system distributions, are required. If it is possible to hold the version number down, then it would be nice to do so. meillo
[dev] [surf] SIGSEGV with newest webkit on arch
Hi, I updated my arch-system one minute ago and surf seems to segfault with the newest webkit (1.1.15.3). I recompiled the newest surf from hg, and the same happens. GDB said: Program received signal SIGSEGV, Segmentation fault. 0xb6a8f3de in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 Does anybody have the same problem? Regards Moritz Wilhelmy
Re: [dev] [surf] next release
[2009-10-22 14:42] pancake > > The problem is that I find no way to get the source of the page from > the webkit API. This is why surf implements this by using the API to > watch the source. The right way is to get the download problem solved and then download the source. meillo
Re: [dev] [surf] next release
[2009-10-22 18:15] Tadeusz =?utf-8?B?U2/Fm25pZXJ6?= > On 22-10-2009 09:09:25, Charlie Kester wrote: > > On Thu 22 Oct 2009 at 05:20:44 PDT Dieter Plaetinck wrote: > > > > > >what consitutes a "session" ? it's something that is maintained > > >serverside and the only way to "stay in it" is usually one or more of: > > >- keeping and sending cookie data > > >- keeping the same ip (and maybe user agent) > > >- requesting the urls they tell you to > > > > > >afaik both curl and wget can use existing cookie storages on your hard > > >disk (and can use the useragent you tell them to), so don't really see > > >the problem. > > > > It seems to me that the problems being discussed in this subthread arise > > because the "browser" combines two very distinct concerns: > > > > - managing the http traffic to and from the website, which includes the > > administrative details pertaining to the session > > > > - rendering the documents obtained from the website > > > > Perhaps we should be thinking about separating them? > > Then we will end up with some shit like uzbl - the browser which cannot > browse the web. You should know, it's not uzbl's fault, so don't blame it! meillo P.S. Usually it's simple: If it can't be done right, one should think about not using it at all. ... /me thinks about it.
Re: [dev] [surf] next release
Tadeusz Sośnierz dixit (2009-10-22, 18:15): > > Perhaps we should be thinking about separating them? > > Then we will end up with some shit like uzbl - the browser which cannot > browse the web. Why not? Just curious, haven't been using any of those yet. -- [a]
Re: [dev] [surf] next release
* Tadeusz Sośnierz [2009-10-22 18:17]: > Then we will end up with some shit like uzbl - the browser which cannot > browse the web. What web do you have there? It must be a strange one. I haven't used any other X browser at home for months (except for testing surf). Please consider to try to localise the problem in the system consisting of you, the browser, and the web. And then report again. -- stanio_
Re: [dev] [surf] next release
On 22-10-2009 19:14:10, sta...@cs.tu-berlin.de wrote: > * Tadeusz Sośnierz [2009-10-22 18:17]: > > Then we will end up with some shit like uzbl - the browser which cannot > > browse the web. > > What web do you have there? It must be a strange one. I haven't used any > other X browser at home for months (except for testing surf). Please > consider to try to localise the problem in the system consisting of you, > the browser, and the web. And then report again. > Well, looks like I have to apologize. For some unknown reason I was thinking that uzbl is handling link-clicking through some external scripts, but I just cloned the git version and looks like I was wrong. Sorry for my trolling, mea culpa. Regards -- === () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: [dev] [surf] SIGSEGV with newest webkit on arch
hi! It seems this is caused by archlinux libwebkit release. Downgrade you're webkit to an earlier release. uzbl has the same problem. For some strange reason midori still works... regards 2009/10/22 Moritz Wilhelmy : > Hi, > > I updated my arch-system one minute ago and surf seems to segfault with > the newest webkit (1.1.15.3). > > I recompiled the newest surf from hg, and the same happens. > > GDB said: > Program received signal SIGSEGV, Segmentation fault. > 0xb6a8f3de in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 > > > Does anybody have the same problem? > > Regards > Moritz Wilhelmy > > -- http://gnuffy.chaotika.org - Real Community Distro
Re: [dev] [surf] next release
On Thu, 22 Oct 2009, Julien Steinhauser wrote: On Thu, Oct 22, 2009 at 02:42:49PM +0200, pancake wrote: Btw I still find necessary the contextual menu to get URL of image, URL of link .. Download in a separated window/client/app. I totally agree, it was a good feature that I would also welcome back. At the moment the two lower items of the context menu : Paste URI and Copy URI are doing pretty much the same as ctrl-y ctrl-p but are IMHO not as convenient as the keybindings, replacing these two items with something like "Download linked file" and "Copy link" would be more usefull. I second this. It took me a moment to realize not only that said Paste URI/Copy URI items didn't do what you propose and then to realize that, as far as a quick glance to the codebase allowed, surf has no way of doing this. But it is an obvious need: sometimes you want to cut into x buffer the link's url without actually navigating to the site, e.g.\ when you want to navigate to the site via wget or some other agent. Yours, Peter
[dev] UTF-8 copyright symbol
Dwm, surf, and probably more suckless projects contain the copyright symbol as UTF-8 character. In most cases, if not always, it is the only non-ASCII character in those files. I suggest to replace it with ``Copyright'' or ``Copyright (c)''. (``(c)'' alone is not enough from the lawyer POV, AFAIK.) Although most modern software can deal with UTF-8 chars, why use them when not necessary? In this case, we'll not lose anything but may avoid problems. What speaks against? meillo
Re: [dev] UTF-8 copyright symbol
On Thu, Oct 22, 2009 at 09:40:13PM +0200, markus schnalke wrote: > Dwm, surf, and probably more suckless projects contain the copyright > symbol as UTF-8 character. In most cases, if not always, it is the only > non-ASCII character in those files. > > I suggest to replace it with ``Copyright'' or ``Copyright (c)''. > (``(c)'' alone is not enough from the lawyer POV, AFAIK.) > > Although most modern software can deal with UTF-8 chars, why use them > when not necessary? In this case, we'll not lose anything but may avoid > problems. What 'problems'? I think that the © is necessary, as it shows the copyright notice, and it's a lot shorter than writing our 'copyright (c) blah'. > What speaks against? > > > meillo > -- Jake Todd // If it isn't broke, tweak it! pgpsHDK8mbOzC.pgp Description: PGP signature
Re: [dev] UTF-8 copyright symbol
On Thu, Oct 22, 2009 at 2:40 PM, markus schnalke wrote: > Dwm, surf, and probably more suckless projects contain the copyright > symbol as UTF-8 character. In most cases, if not always, it is the only > non-ASCII character in those files. > > I suggest to replace it with ``Copyright'' or ``Copyright (c)''. > (``(c)'' alone is not enough from the lawyer POV, AFAIK.) > > Although most modern software can deal with UTF-8 chars, why use them > when not necessary? In this case, we'll not lose anything but may avoid > problems. > > What speaks against? > > > meillo > > Then again, why bother appealing to copy "rights" and similar hooey in the first place? I always consider it to be enough simply to appeal to good sense, good manners, and social pressure to ensure credit is given where credit is due. Something like "Notice: So-and-so created this work. Do what you like with it, but don't claim you came up with it 'cause that's lying. And nobody likes a liar. Thanks." Different strokes for different folks, I guess. A.J.
Re: [dev] UTF-8 copyright symbol
On Thu, Oct 22, 2009 at 3:00 PM, A.J. Gardner wrote: > Then again, why bother appealing to copy "rights" and similar hooey in > the first place? I always consider it to be enough simply to appeal to > good sense, good manners, and social pressure to ensure credit is > given where credit is due. Something like "Notice: So-and-so created > this work. Do what you like with it, but don't claim you came up with > it 'cause that's lying. And nobody likes a liar. Thanks." > > Different strokes for different folks, I guess. Excuse me, this thread is clearly destined to turn into a character encoding flamewar, not a software licensing flamewar. -- # Kurt H Maier
Re: [dev] [surf] SIGSEGV with newest webkit on arch
chromium also works. Maybe this is intended to piss every uzbl and surf-user off? :D Regards On Thu, Oct 22, 2009 at 08:23:01PM +0200, Enno Boland (Gottox) wrote: > hi! > > It seems this is caused by archlinux libwebkit release. Downgrade > you're webkit to an earlier release. uzbl has the same problem. For > some strange reason midori still works... > > regards > > 2009/10/22 Moritz Wilhelmy : > > Hi, > > > > I updated my arch-system one minute ago and surf seems to segfault with > > the newest webkit (1.1.15.3). > > > > I recompiled the newest surf from hg, and the same happens. > > > > GDB said: > > Program received signal SIGSEGV, Segmentation fault. > > 0xb6a8f3de in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 > > > > > > Does anybody have the same problem? > > > > Regards > > Moritz Wilhelmy > > > > > > > > -- > http://gnuffy.chaotika.org - Real Community Distro >
Re: [dev] UTF-8 copyright symbol
To attempt to bring it back on topic, here are my thoughts: Any software that can't handle utf-8 should be replaced with software that sucks less. However, anything that can be done to make the source code for suckless projects suck less (in regards to its interactions with software, some of which may suck) is a Good Thing. Since this change requires no real effort and can slightly improve its interactions with other software, why not just do it? On Thu, Oct 22, 2009 at 4:14 PM, Kurt H Maier wrote: > On Thu, Oct 22, 2009 at 3:00 PM, A.J. Gardner > wrote: > > Then again, why bother appealing to copy "rights" and similar hooey in > > the first place? I always consider it to be enough simply to appeal to > > good sense, good manners, and social pressure to ensure credit is > > given where credit is due. Something like "Notice: So-and-so created > > this work. Do what you like with it, but don't claim you came up with > > it 'cause that's lying. And nobody likes a liar. Thanks." > > > > Different strokes for different folks, I guess. > > Excuse me, this thread is clearly destined to turn into a character > encoding flamewar, not a software licensing flamewar. > > > -- > # Kurt H Maier > >
Re: [dev] [surf] SIGSEGV with newest webkit on arch
Actually chromium does not use libwebkit. 2009/10/22 Moritz Wilhelmy : > chromium also works. > > Maybe this is intended to piss every uzbl and surf-user off? :D > > Regards > > On Thu, Oct 22, 2009 at 08:23:01PM +0200, Enno Boland (Gottox) wrote: >> hi! >> >> It seems this is caused by archlinux libwebkit release. Downgrade >> you're webkit to an earlier release. uzbl has the same problem. For >> some strange reason midori still works... >> >> regards >> >> 2009/10/22 Moritz Wilhelmy : >> > Hi, >> > >> > I updated my arch-system one minute ago and surf seems to segfault with >> > the newest webkit (1.1.15.3). >> > >> > I recompiled the newest surf from hg, and the same happens. >> > >> > GDB said: >> > Program received signal SIGSEGV, Segmentation fault. >> > 0xb6a8f3de in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 >> > >> > >> > Does anybody have the same problem? >> > >> > Regards >> > Moritz Wilhelmy >> > >> > >> >> >> >> -- >> http://gnuffy.chaotika.org - Real Community Distro >> > > -- http://gnuffy.chaotika.org - Real Community Distro
Re: [dev] UTF-8 copyright symbol
On Thu, Oct 22, 2009 at 03:00:34PM -0500, A.J. Gardner wrote: Then again, why bother appealing to copy "rights" and similar hooey in the first place? I always consider it to be enough simply to appeal to good sense, good manners, and social pressure to ensure credit is given where credit is due. Something like "Notice: So-and-so created this work. Do what you like with it, but don't claim you came up with it 'cause that's lying. And nobody likes a liar. Thanks." That's not the point. The point is that without claiming copyright and granting explicit license to use and modify the software as you will, you legally don't have that right. Perhaps the likelihood of being sued by small time programmers isn't very great, but it's a major distribution problem. No respectable distrobution is willing to carry such software (look at DJB-ware) without some extra hassle on the user's part. -- Kris Maglione Projects promoting programming in natural language are intrinsically doomed to fail. --Edsger W. Dijkstra
Re: [dev] UTF-8 copyright symbol
On Thu, Oct 22, 2009 at 04:17:19PM -0400, Niki Yoshiuchi wrote: However, anything that can be done to make the source code for suckless projects suck less (in regards to its interactions with software, some of which may suck) is a Good Thing. Since this change requires no real effort and can slightly improve its interactions with other software, why not just do it? How would it make the software suck less? How would it improve interactions with other software? No one's even posed a good case for this causing problems at all. So, in a non-UTF-8 locale you don't see a copyright sign. In 8859-1, you see ©; what a nightmare! Seriously, this isn't an issue. People with a UTF-8 locale get a nice copyright sign, for everyone else, the legal validity is the same. If they don't like it, they can piss off, or read up on how to turn on a UTF-8 locale. -- Kris Maglione It is practically impossible to teach good programming style to students that have had prior exposure to Basic; as potential programmers they are mentally mutilated beyond hope of regeneration. --Edsger W. Dijkstra
Re: [dev] UTF-8 copyright symbol
On 10/22/09, A.J. Gardner wrote: > given where credit is due. Something like "Notice: So-and-so created > this work. Do what you like with it, but don't claim you came up with > it 'cause that's lying. And nobody likes a liar. Thanks." let me guess.. you are not a lawyer berne convention (1886) "copyrights for creative works do not have to be asserted or declared, as they are automatically in force at creation. In these countries, there is no requirement for an author to "register" or "apply for" a copyright, or to mark his or her works with a copyright symbol or other legend." universal copyright convention (1952) "[copyright holds] if from the time of the first publication all the copies of the work published with the authority of the author or other copyright proprietor bear the symbol © accompanied by the name of the copyright proprietor and the year of first publication placed in such manner and location as to give reasonable notice of claim of copyright." wikipedia "The United States initially refused to become party to the [Berne] Convention since it would have required major changes in its copyright law, particularly with regard to moral rights, removal of general requirement for registration of copyright works and elimination of mandatory copyright notice. This led to the Universal Copyright Convention in 1952 to accommodate the wishes of the United States. But on March 1, 1989, the U.S. "Berne Convention Implementation Act of 1988" came into force and the United States became a party to the Berne Convention, making the Universal Copyright Convention obsolete." all parties of ucc have joined to berne convention by 2000 conclusion: explicit copyright notice is not needed any more
Re: [dev] [surf] SIGSEGV with newest webkit on arch
On Thu, 22 Oct 2009 20:23:01 +0200 "Enno Boland (Gottox)" wrote: > hi! > > It seems this is caused by archlinux libwebkit release. Downgrade > you're webkit to an earlier release. uzbl has the same problem. For > some strange reason midori still works... > > regards what makes you think this is an archlinux problem? the pkgbuild looks very simple. no special tricks. http://repos.archlinux.org/wsvn/packages/libwebkit/repos/extra-i686/PKGBUILD
Re: [dev] UTF-8 copyright symbol
2009/10/22 markus schnalke : > Dwm, surf, and probably more suckless projects contain the copyright > symbol as UTF-8 character. In most cases, if not always, it is the only > non-ASCII character in those files. > > I suggest to replace it with ``Copyright'' or ``Copyright (c)''. > (``(c)'' alone is not enough from the lawyer POV, AFAIK.) > > Although most modern software can deal with UTF-8 chars, why use them > when not necessary? In this case, we'll not lose anything but may avoid > problems. > > What speaks against? Nothing, but the copyright character will stay, it is less verbose and the official character for copyright notices. I'm not concerned that in some exotic setups this character hasn't got a glyph in the font or isn't part of 7bit ASCII. Kind regards, Anselm
Re: [dev] UTF-8 copyright symbol
On Thu, Oct 22, 2009 at 09:50:05PM +0100, Anselm R Garbe wrote: 2009/10/22 markus schnalke : Dwm, surf, and probably more suckless projects contain the copyright symbol as UTF-8 character. In most cases, if not always, it is the only non-ASCII character in those files. I suggest to replace it with ``Copyright'' or ``Copyright (c)''. (``(c)'' alone is not enough from the lawyer POV, AFAIK.) Although most modern software can deal with UTF-8 chars, why use them when not necessary? In this case, we'll not lose anything but may avoid problems. What speaks against? Nothing, but the copyright character will stay, it is less verbose and the official character for copyright notices. I'm not concerned that in some exotic setups this character hasn't got a glyph in the font or isn't part of 7bit ASCII. Well, that was decisive and clear. But don't try to spoil our flame war. -- Kris Maglione Beware of bugs in the above code; I have only proved it correct, not tried it. --Donald Knuth
Re: [dev] UTF-8 copyright symbol
This whole thread is stupid: the complaint about UTF-8 chars is stupid, and the "copyright notice" is stupid. A simple mention in the readme like: "This code is released to the public domain and under the MIT and ISC licenses, pick whichever option suits you." should be enough, or if you feel really obnoxious put it in a LICENSE file at the root of the project. That is what I do for all my code, it is short, simple, and works no matter how retarded the laws are in your country. uriel On Thu, Oct 22, 2009 at 9:40 PM, markus schnalke wrote: > Dwm, surf, and probably more suckless projects contain the copyright > symbol as UTF-8 character. In most cases, if not always, it is the only > non-ASCII character in those files. > > I suggest to replace it with ``Copyright'' or ``Copyright (c)''. > (``(c)'' alone is not enough from the lawyer POV, AFAIK.) > > Although most modern software can deal with UTF-8 chars, why use them > when not necessary? In this case, we'll not lose anything but may avoid > problems. > > What speaks against? > > > meillo > >
Re: [dev] automatic tagging on executing a program
On Wed, Sep 23, 2009 at 04:41:24PM +0200, Davide Anchisi wrote: I created the tagrule: /gimp/ -> gimp in rc.wmii.local So to tag gimp as gimp when executing it. It works, but the program does not begin to start until I open the newly created view. It turns out that if you run 'gimp -s', this isn't an issue. -- Kris Maglione Never attribute to malice that which is adequately explained by stupidity. --Hanlon's razor
Re: [dev] UTF-8 copyright symbol
Hi, 2009/10/23 Kris Maglione : > On Thu, Oct 22, 2009 at 04:17:19PM -0400, Niki Yoshiuchi wrote: >> >> However, anything that can be done to make the source code for suckless >> projects suck less (in regards to its interactions with software, some of >> which may suck) is a Good Thing. >> >> Since this change requires no real effort and can slightly improve its >> interactions with other software, why not just do it? > > How would it make the software suck less? How would it improve interactions > with other software? No one's even posed a good case for this causing > problems at all. So, in a non-UTF-8 locale you don't see a copyright sign. > In 8859-1, you see ©; what a nightmare! Seriously, this isn't an issue. > People with a UTF-8 locale get a nice copyright sign, for everyone else, the > legal validity is the same. If they don't like it, they can piss off, or > read up on how to turn on a UTF-8 locale. Did you think about fonts, not locale? [SNIP]
Re: [dev] [dwm] Xinerama autocenter issue
Sorry I should of been more clear. I can understand and accept the dialog centering, but the whole app is being recentered and part of it is going off screen. I started detaching tabs and dragging them to the second monitor, but when I switch tags and then switch back, all the detached tabs jump back to the first monitor @_@ haha, anyway, maybe it's time to look at emacs. Also, found a link to a plugin for eclipse that fixes some xinerama issues in KDE (http://linux.softpedia.com/get/Utilities/3-5-x-Xinerama-improvements-27124.shtml), but I'll switch to Windows ME before I switch to KDE cheers -Alex On Thu, Oct 22, 2009 at 4:14 PM, Anselm R Garbe wrote: > 2009/10/22 Alex Matviychuk : >> I'm floating eclipse across the length of 1.5 monitors using xinerama. >> Whenever I use a dialog inside eclipse, it tries to center itself and >> considers the center as the center of the first monitor. Is there a >> way to fix this? Or is there a better way of streaching apps across >> monitors? > > The dialog that pops up belongs to the monitor of the parent window > (eclipse). Hence it's centered on the monitor it belongs to. > Stretching things across monitors is not intended to be supported well > by dwm's Xinerama support. The best solution for this is buying a > bigger screen and telling the monitor vendor that you bought this > screen because you are a dwm user ;) Perhaps some screen manufacturer > will ring some day when it realises the critical dwm user base ;) > > Kind regards, > Anselm > >
Re: [dev] UTF-8 copyright symbol
On Fri, Oct 23, 2009 at 09:54:07AM +0900, KIMURA Masaru wrote: How would it make the software suck less? How would it improve interactions with other software? No one's even posed a good case for this causing problems at all. So, in a non-UTF-8 locale you don't see a copyright sign. In 8859-1, you see ©; what a nightmare! Seriously, this isn't an issue. People with a UTF-8 locale get a nice copyright sign, for everyone else, the legal validity is the same. If they don't like it, they can piss off, or read up on how to turn on a UTF-8 locale. Did you think about fonts, not locale? Well, I was expecting an encoding flame war. At any rate, most fonts have the © character. Even the exceedingly paltry ProggyClean (my favorite) displays it properly. The standard X fonts (namely fixed) contain vast swaths of the Unicode spectrum. Hell, even MS's console font has ©, and has since the early DOS days. If someone wants to use such an impoverished font as to make this an issue, well, that's his problem. -- Kris Maglione Common sense is the collection of prejudices acquired by age 18. --Albert Einstein
[dev] [ANN] wmii 3.9b1 released
Hi, wmii 3.9 Beta 1 has just been released. As usual, the source is available at suckless.org: http://dl.suckless.org/wmii/wmii+ixp-3.9b1.tbz http://dl.suckless.org/wmii/wmii+ixp-3.9b1.tbz.sum http://dl.suckless.org/wmii/wmii+ixp-3.9b1.tbz.sig A new Ununtu repo is also available, which already contains the Beta: https://launchpad.net/~maglione-k/+archive/ppa The packages hosted there may or may not also work with your debian system, depending on your configuration. New since the last Alpha: * wmii9menu is now Xinerama aware. * Install READMEs to $(PREFIX)/share/doc/wmii/. * Documentation updates. Add wmiir.1, wmii9menu.1. * Allow dragging floating clients from anywhere in their titlebars. * Allow specifying screen in area specs. * Change default $MODKEY to Mod4. * Minor changes to pygmi.events API. * Allow client to follow tag change in python wmiirc. * Update /tag/*/index to be more useful on Xinerama. * Add showkeys action to shell and python wmiirc. * Restore windows from floating layer to their original Xinerama screen. * Hide bar on non-primary Xinerama screens. * Allow resizing of rightmost and leftmost column dividers. New since the 3.6 release: * Add Suraj's Rumai-based wmiirc. * Move rc.wmii to alternative_wmiircs/plan9port/wmiirc. * Install wmii.pdf to $(PREFIX)/share/doc/. * Focus windows regardless of whether they form a new group. * Update selection and execution of wmiirc: no more magic. * Update wmii.1 * Add alternative_wmiircs READMEs. * Add new wmii guide. See doc/wmii.pdf * Allow for programmable completion in wimenu. * Use pkg-config globally. * Add Xft (antialiased font) support. * Add python wmiirc/9P client library * Allow bindings to work regardless of caps lock. * Add M-f fullscreen toggle key binding. * Augment /client/*/ctl Fullscreen command. * Allow setting of increment display from /ctl. * Show a client's extra tags in its titlebar. * Darken background when floating area selected. * Allow bar on top or bottom. * Allow for wmiirc_local. * Add grow and nudge commands to /tag/*/ctl. * Cascade windows when the floating layer fills. * Support alpha-transparant windows. * Add regex tag support. * It is now possible to float/unfloat windows with the mouse. * Make the bar Xdnd aware; DND between views is now possible. Fixed some window raising/moving bugs. * Add a notification bar. * Improved floating mouse resizing. * Improved mouse move/resize support for managed mode. * Better return from floating/fullscreen to managed mode. * Allow comments (#.*\n) in rules and ctl files. * Add /client/*/ctl ‘slay’ command. * Detect unresponsive clients on ‘kill’. * Draw titlebars of floating clients differently. * Add wihack: LD_PRELOAD hack to set window properties of programs: * Respect window groups * Add ‘Kill’ to client right-click menu * wmii9menu now takes similar args to wimenu * Document grow/nudge commands. * Add wimenu with history and caret support * Add wistrut. Undocumented, not built by default. * EWMH strut support. * Basic EWMH support. * Better fullscreen support. * XRandR support. * Xinerama support. -- Kris Maglione The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code. --Paul Graham
Re: [dev] UTF-8 copyright symbol
2009/10/23 Kris Maglione : > On Fri, Oct 23, 2009 at 09:54:07AM +0900, KIMURA Masaru wrote: >>> >>> How would it make the software suck less? How would it improve >>> interactions >>> with other software? No one's even posed a good case for this causing >>> problems at all. So, in a non-UTF-8 locale you don't see a copyright >>> sign. >>> In 8859-1, you see ©; what a nightmare! Seriously, this isn't an issue. >>> People with a UTF-8 locale get a nice copyright sign, for everyone else, >>> the >>> legal validity is the same. If they don't like it, they can piss off, or >>> read up on how to turn on a UTF-8 locale. >> >> Did you think about fonts, not locale? > > Well, I was expecting an encoding flame war. At any rate, most fonts have > the © character. Even the exceedingly paltry ProggyClean (my favorite) > displays it properly. The standard X fonts (namely fixed) contain vast > swaths of the Unicode spectrum. Hell, even MS's console font has ©, and has > since the early DOS days. If someone wants to use such an impoverished font > as to make this an issue, well, that's his problem. Most cjk guys always use multi-bytes characters w/ non-UTF8 encoding. If we should think about fonts, we'd have to go nuts. Most european people make a token effort for i18n w/ saying "that's his problem". Yes, you're right. That's "that's our problem". I'm jap, and really tired that situation. So I'd like to keep my code in pure ASCII. For only keeping t3h copyright symbol properly, there is no need to use problematic encoding, even if it's UTF-8. I'd like to type "(c)" or "(C)", if I need to write copyright notice. It suck less, at least for me. Just my two cents.
Re: [dev] [surf] next release
Is stupid to make two http queries because the second one doesn't have to contain the same as the first one. Think on a page doing some random contents at every refresh. Think on referers while refreshing a page. Think on losing the network link after getting the page rendered. I hate to not being able to save the page that it's in front of me because the network is down. On Oct 22, 2009, at 7:07 PM, markus schnalke wrote: [2009-10-22 14:42] pancake The problem is that I find no way to get the source of the page from the webkit API. This is why surf implements this by using the API to watch the source. The right way is to get the download problem solved and then download the source. meillo
Re: [dev] [dwm] Xinerama autocenter issue
2009/10/23 Alex Matviychuk : > Sorry I should of been more clear. I can understand and accept the > dialog centering, but the whole app is being recentered and part of it > is going off screen. I started detaching tabs and dragging them to the > second monitor, but when I switch tags and then switch back, all the > detached tabs jump back to the first monitor @_@ > > haha, anyway, maybe it's time to look at emacs. Also, found a link to > a plugin for eclipse that fixes some xinerama issues in KDE > (http://linux.softpedia.com/get/Utilities/3-5-x-Xinerama-improvements-27124.shtml), > but I'll switch to Windows ME before I switch to KDE I use Eclipse at work sometimes and always run it in floating mode. Kind regards, Anselm
