- Dillo-dev - lists.mailman3.com

use C locale for LC_CTYPE

by furaisanjin＠gmail.com

Hello corvid. I gave you wrong information. I don't explicitly set locale but implicitly set locale (probably through LANG but I'm not sure). locale command shows current my locale setting like these. LANG=ja_JP.eucJP LC_CTYPE="ja_JP.eucJP" LC_COLLATE="ja_JP.eucJP" LC_TIME="ja_JP.eucJP" LC_NUMERIC="ja_JP.eucJP" LC_MONETARY="ja_JP.eucJP" LC_MESSAGES="ja_JP.eucJP" LC_ALL= Your locale patch (c6cbf3ae7ffd) has side effect on my dillo and while converting to Kanji, font width is half and it's not easy to recognize. Could you add locale setting on preference to make dillo use the preference locale rather than default "C" at start up? Regards, furaisanjin

Oct. 22, 2011

Dillo on Cygwin/X

by obeythepenguin＠gmail.com

I should probably resist the bait here, but... Jorge wrote: > > Is there any interest to support this target on a source code basis? > I'd like to have a way to run dillo on Win*, but not sacrificing > current portability [2], nor having to write a completely different > code path for Win*. I'll just say patches 2, 6, 7, 8, 9, 11, and maybe 14 will get you 85% of that, without sacrificing *any* existing portability, and with only minimal changes to the existing Dillo code: http://dillo-win32.sourceforge.net/dillo/dillo3-patches.php Patches 7 and 8, the sockets abstraction layer, are the big ones; the rest of them are small tweaks. The remaining 29 patches are things like UI tweaks and moving DPIs back into the browser, which you are free to leave out. Oh, and I do regularly test my code on Unix, if you're wondering: http://obeythepenguin.users.sourceforge.net/openbsd/files/screenshot.png http://dillo-win32.sourceforge.net/dillo/screenshots.php?closeup=unix-openb… > An API that works in both would be a good solution. For instance, > we know that some dpi servers already work in Win* (with cygwin). > There may even be a way to achieve it natively, and I seem to > recall the FLTK3 team had this in mind. It would be more than > worth to ask them about their plans on the subject. > Again, as I'm not a Win* developer, I don't qualify > to lead this effort on the Win* side. > HTH. Well, frankly I don't think most of the current DPIs belong outside the browser in the first place, as I've explained here: http://dillo-win32.sourceforge.net/dillo/dpi.php (If I have any technical details about the implementation wrong, please let me know.) I have started work on a native Windows DPI patch if you'd like to see it, though I'm afraid it's not functional yet, and it's *very* ugly code. Regards, ~Benjamin

Oct. 22, 2011

Address bar keys (bug #1012)

by obeythepenguin＠gmail.com

Rogutes wrote: > Benjamin Johnson (2011-10-21 00:03): > > >> >Having it consistent over all text inputs and configurable > > >via> >keysrc sounds reasonable to me. I don't know the keysrc > > >details> >though, so I might miss something.> >Cheers,> > > >>JohannesHaving input/insert mode and macros in keysrc would be > > >interesting, if nottoo complex. > Look how indecipherable your quotations are. Sorry about that. My mail client (Opera Mail) seems to mangle things from time to time, but frankly I'm not too sure why. > Other than that, I have to agree with most points, because you seem to > have done more homework than I have. I lose sleep over this sort of thing. It's the little things that make or break a user interface; big problems aren't as bad, because if they're obvious enough you can learn to work around them. (Not that I mean that to imply anything about Dillo's UI!) > Shift-{Left,Right} doesn't do anything here and I would expect it to > select text [I guess conventionally]. > Ctrl-A selects all text in other FLTK apps, so dillo must have most > input > boxes covered with the CustInput class. > ---- Rogut?s Sparnuotos Looking through the code, there appear to be three(!) different classes: - CustInput in src/ui.cc - CustInput2 in src/dialog.cc - CustInput3 in dw/fltkui.cc Thanks for mentioning that -- I hadn't noticed the other two. Somehow, it seems just a little excessive... ~Benjamin

Oct. 22, 2011

mailing list trivia (Re: [REPOST] Re: Dillo Win32

by rogerx.oss＠gmail.com

Thoughts) Reply-To: In-Reply-To: <20111021073336.GA12742 at local> > On Fri, Oct 21, 2011 at 07:33:36AM +0000, corvid wrote: > >I see what the problem was now with the strange little chunk of a msg. >When Roger wrote: >> [...] >> required either. >> >> From here, mintty's code is likely an excellent resource to figure how they >> worked around the Window's issues with mouse copy & pasting. > >Pipermail saw a blank line followed by "From ", and thought "new msg!" and >got all confused when generating the archive. IIRC, mail(1) always had a hard >time with that one as well. This is explicitly Google's fault then. I use mutt with gmail, and I find GMail likes blank lines on copy & paste. There might be something within my muttrc causing this too, but I doubt it as I never seen so many problems with blank lines and extended long lines after pasting within a Mutt session. (Only using Mutt with GMail IMAP have I seen this! Never in an ordinary local Mutt session. I also use VIM as the editor: set editor = '/usr/bin/vim --noplugin +/^$' # default: '(empty)' I think it happens during the IMAP session, IMAP/terminal are interpretting newlines incorrectly on paste. As to why this occurred within the From: field makes this even more strange as copy/paste would likely not have occurred there. Personally, I consider this a GMail bug. -- Roger http://rogerx.freeshell.org/

Oct. 21, 2011

use C locale for LC_CTYPE

by corvid＠lavabit.com

Jorge wrote: > FWIW, I don't remember the details but it seems to me that long ago > we had a thread on the problems of changing the locale set by the user. *has a look through the archives* What I could find was: - In downloads dpi, having to set C locale in the environment before exec()ing wget in order to parse the log correctly. - Dillo resetting to C locale for gtk cmdline option parsing. - Temporarily resetting LC_NUMERIC to C locale for prefs parsing. I don't believe LC_NUMERIC is currently set in the fltk-1.3 era, although it might be good to reset in general because of the strtod() in Html_parse_length_or_multi_length().

Oct. 21, 2011

Address bar keys (bug #1012)

by rogutes＠googlemail.com

Benjamin Johnson (2011-10-21 00:03): > >> >Having it consistent over all text inputs and configurable > >via> >keysrc sounds reasonable to me. I don't know the keysrc > >details> >though, so I might miss something.> >Cheers,> > >>JohannesHaving input/insert mode and macros in keysrc would be > >interesting, if nottoo complex. Look how indecipherable your quotations are. Other than that, I have to agree with most points, because you seem to have done more homework than I have. Shift-{Left,Right} doesn't do anything here and I would expect it to select text [I guess conventionally]. Ctrl-A selects all text in other FLTK apps, so dillo must have most input boxes covered with the CustInput class. -- -- Rogut?s Sparnuotos

Oct. 21, 2011

use C locale for LC_CTYPE

by jcid＠dillo.org

On Fri, Oct 21, 2011 at 05:29:49AM +0000, corvid wrote: > > If you've been following along on fltk.general, you'll know we've been > in discussion over some unpleasantness regarding Turkic locales and > strcasecmp/toupper/tolower where 'i' and 'I' are different letters. No I haven't, but if you were into the subject, please patch as necessary. > > ( http://en.wikipedia.org/wiki/Dotted_and_dotless_I ) > > The typical solution is to make sort of ASCIIfied versions where you > force i<->I. > > I think that, for our purposes, we can just use the ordinary POSIX locale > and save ourselves the trouble. FWIW, I don't remember the details but it seems to me that long ago we had a thread on the problems of changing the locale set by the user. -- Cheers Jorge.-

Oct. 21, 2011

Dillo on Cygwin/X

by jcid＠dillo.org

Hi Stephan, Sorry for the delayed answer. I've been quite busy these days... On Fri, Oct 14, 2011 at 12:54:56PM +0200, Stephan G?tter wrote: > Hello, > > I just gave Dillo another try on Cygwin/X11 and got it working at > least partially with cygwin 1.7.9. Ack. Disclaimer: I haven't used cygwin, nor developed in a Win* platform, but have read about the socket portability problems between Win* and POSIX before. > You need to compile FLTK using Cygwin libraries and X11: > ./configure --enable-cygwin --enable-x11 && make install > > Because the dpis are installed with ".exe" extension (eg > hello.dpi.exe) they aren't found by dpid. The extension is added by > automake: http://www.gnu.org/s/hello/manual/automake/EXEEXT.html > The Makefiles look like this: bookmarks_PROGRAMS = bookmarks.dpi$(EXEEXT) > > I don't know how to break automake of doing this for the dpis only, so > I modified dpid to use .exe-extension on cygwin (see attached patch). > After starting the XServer (/usr/bin/XWin -multiwindow) you can run > Dillo. Plain browsing with http using proxy and the bookmark & cookie > dpis does work. The other dpi currently fail. > > - hello-dpi shows the dialog and without pressing any button the > resultpage (Answer received: Window was closed). After pressing Yes > dpid logs "ERROR: [a_Capi_dpi_send_data] No open connection found" > - vsource just crashes > - file, ftp and https can't connect: > Dpi_get_server_port: can't read server port from dpid. > ** ERROR **: dpi.c: can't start dpi daemon At first sight it looks like dpi "servers" work and dpi "filters" not. Except for the file dpi which is a dpi "server". Does the download dpi work for you? > Looks like the socket implementation of cygwin still has some quirks > which can maybe tracked down. Could be. This is a very complex area (e.g. fork [1]). On POSIX I've implemented dpis at least like: * filter * servers * select based * threaded * forked and it's very tricky to get them to work reliably across different platforms/OSes. If we were to find a way to make it work (for instance with dpi servers) it may be worth to switch dpi filters to servers. > Is there any interest to support this target on a source code basis? I'd like to have a way to run dillo on Win*, but not sacrificing current portability [2], nor having to write a completely different code path for Win*. An API that works in both would be a good solution. For instance, we know that some dpi servers already work in Win* (with cygwin). There may even be a way to achieve it natively, and I seem to recall the FLTK3 team had this in mind. It would be more than worth to ask them about their plans on the subject. Again, as I'm not a Win* developer, I don't qualify to lead this effort on the Win* side. HTH. [1] http://cygwin.com/faq/faq-nochunks.html#faq.api.fork [2] http://www.dillo.org/Compatibility.html -- Cheers Jorge.-

Oct. 21, 2011

mailing list trivia (Re: [REPOST] Re: Dillo Win32 Thoughts)

by corvid＠lavabit.com

I see what the problem was now with the strange little chunk of a msg. When Roger wrote: > [...] > required either. > > From here, mintty's code is likely an excellent resource to figure how they > worked around the Window's issues with mouse copy & pasting. Pipermail saw a blank line followed by "From ", and thought "new msg!" and got all confused when generating the archive. IIRC, mail(1) always had a hard time with that one as well.

Oct. 21, 2011

[REPOST] Re: Dillo Win32 Thoughts

by rogerx.oss＠gmail.com

(According to Corvid, this goody tidbit about mintty got snipped when posted to the list. Resending.) >> 2) Copy & paste work only within the displayed page and not within the >> urlfield. (Although I really miss middle button pasting in Windows.) > >The keyboard shortcuts (Ctrl-C and Ctrl-V, respectively) should work for >both the page and URL field. > >Windows doesn't support X's select-and-middle-click mechanism. I agree >that it would be really nice to have -- that and a decent terminal >emulator like aterm would make my life so much nicer. Might want to check-out mintty. I just found-out about this new package within cygwin, and it's a replacement for the usual cygwin+windows commandline window. The reason it's so great, it allows mouse buttons to be used for copy & pasting within Windows! And, it put's a nice icon of itself on your desktop, similar to the cygwin+windows_commandline after installing from within cygwin. No X is required either.

Oct. 21, 2011