October 2011 - Dillo-dev - lists.mailman3.com

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

No subject

by bogus＠does.not.exist.com

worked around the Window's issues with mouse copy & pasting. --- Roger http://rogerx.freeshell.org/

Oct. 21, 2011

use C locale for LC_CTYPE

by corvid＠lavabit.com

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. ( 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. To see this behaviour: export LC_ALL=tr_TR and then look at: <span style="font-size: 0.5IN">these letters should be big</span> <p> <I>This text should be italic</I>

Oct. 21, 2011

Address bar keys (bug #1012)

by obeythepenguin＠gmail.com

Rogutes Sparnuotos wrote: > Benjamin Johnson (2011-10-20 15:56):How should dillo behave when a user > binds Ctrl-A? It should perform the action bound to Ctrl-A, of course. Just to clarify, the only thing I want to change is the key bindings when the user is typing in the URL input box. Specifically, I'm talking about the CustInput::handle() function in ui.cc: http://hg.dillo.org/dillo/file/e82663b3c477/src/ui.cc#l96 Dillo intercepts several key bindings normally handled by the input box itself. The problem is, some of these key bindings conventionally have different meanings than Dillo assigns (see below). Not all the bindings are bad. I'd keep the binding for Ctrl-L, for example, which rehighlights the input text when you're typing in the box. That's pretty intuitive, and matches the behavior of other browsers. On the other hand, most users aren't familiar with Unix command line bindings, and even those who are usually don't expect that behavior in a graphical application such as Dillo. It might be convenient, but usability isn't always about convenience; it's about doing what users *expect*. Basically, a good interface is one an unwitting mere mortal could figure out without ever reading the manual, or even thinking too hard. Joel Spolsky explains it a lot better than I do: http://www.joelonsoftware.com/uibook/fog0000000249.html > > >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. It would be interesting, but it certainly would be complex, and I'm not sure the benefits outweigh the costs. I suspect most users are probably fine with just the basic key bindings FLTK already provides. There's also the matter of consistency, not just within Dillo, but between Dillo and other FLTK applications. Part of the advantage of using a toolkit *is* the consistency; that was the original motivation behind KDE, for example. > > I was thinking just a simple boolean option in dillorc -- and turn> it > OFF by default (i.e., no Unix keys), because it's not typical GUI> > behavior, and anyone who wants it on can quite easily set it in his> or > her own dillorc.Would be a strange dillorc option. A real patch would > implement this inkeysrc :) Hard-coding is much stranger than either of those, and much uglier, too. The dillorc option would actually make sense here, because these particular bindings usually go together as a group (it seems weird to do the Unix Ctrl-A, but not the others). Though it would make more sense still just to leave well enough alone, since there's no real need to change the input box's behavior. > Somehow I failed to notice that Ctrl-A for select all is "typical GUI > behavior", perhaps I am not using GUIs enough... > [...snip...] >Here, Ctrl-A goes to the beginning of the line in all the input boxes > ("find text", "web search", <input> in forms). Ctrl-A is conventionally used for select all, and at least on Windows, FLTK binds it to select all in input boxes. It may be that FLTK uses the Unix bindings (Ctrl-A for beginning of line, Ctrl-E for end, etc.) on those platforms, in which case Dillo's hard-coding that behavior is pointless and redundant. I haven't booted into Unix in a while, so offhand I haven't checked. Now, I know there will likely never be Windows support in mainline Dillo, and so you're probably wondering why Windows' key bindings should matter to you. While Unix doesn't have any formal standards for graphical user interface design -- indeed, the X Window System was deliberately designed that way -- most toolkits tend to follow what Windows does. Windows has explicit formal standards for command names, menu layouts, shortcut keys, etc., and not only are they standardized (at least on that platform), they're also well known since roughly 97% of desktop computer users run a Windows operating system. (Microsoft also helped design Motif, if anyone remembers that -- which is kind of weird for me to say, since I was roughly two years old at the time. Moving on...) For reference, here's FLTK's human interface guidelines, which borrow "common elements from the CDE/Motif, GNOME, KDE, MacOS, and Windows environments": http://www.fltk.org/hig.php And here's a list of standard accelerator keys from Qt's documentation, which explicitly recommends following Microsoft's recommendations: http://doc.qt.nokia.com/5.0-snapshot/accelerators.html To get back on topic, what does all this mean for Dillo? My own opinion is, the toolkit designers put a lot of thought into this stuff, and probably know more about how their widgets should behave than you and I do. So personally, I don't think we should override that behavior at all unless there's a really good reason to do so. > > Although I will add, the Shift-{Left,Right} bindings in the address> > bar *have* to go. They're fine elsewhere, if a bit quirky, but in> the > address bar they interfere with text selection. Ctrl-Tab and> > Ctrl-Shift-Tab are much more logical and convenient, anyway.> ~Benjamin > Are we using different versions of dillo? Shift-{Left,Right} doesn't do > anything here. I'm talking about this block of code right here: http://hg.dillo.org/dillo/file/e82663b3c477/src/ui.cc#l117 Pressing Shift-{Left,Right} in the address bar moves between tabs, rather than selecting text as expected. (Maybe something left over from dillo2?) > For the arguments sake, how would having to press Ctrl-Shift-Tab be more > "logical and convenient" than Shift-Left? It's a matter of taste (habit). > In my opinion, both bindings have a disadvantage: Ctrl-Shift-Tab is > difficult for the fingers, Shift-Left is unusual to most people. That's > why it is configurable, isn't it?---- Rogut s Sparnuotos Well, Ctrl-Tab's nice because of the obvious mnemonic; because it's really easy to type; and (you can probably guess what's coming) because it's familiar, since lots of other browsers use it. In contrast, the Shift-{Left,Right} keys are much harder to type, especially on a cramped laptop keyboard where your fingers are right on top of each other. And of course, it's a bit weird because I (and probably most users) associate those keys with "select text," not "change tabs." Basically, what all this boils down to is that consistency is key. Yes, it may be the hobgoblin of little minds, but when faced with an unfamiliar interface, *every* user has a little mind. So anyway, there's my rant for tonight. :-) Regards & cheers, ~Benjamin

Oct. 21, 2011

Address bar keys (bug #1012)

by rogutes＠googlemail.com

Benjamin Johnson (2011-10-20 15:56): > Johannes wrote: > > >On Wed, Oct 19, 2011 at 11:16:34AM -0400, Benjamin Johnson wrote: > >>Hi again, > >> > >>I was just wondering, could we add an option to control the address > >>bar key bindings? I know they're set to behave like a Unix command > >>line, which can be convenient, but it also interferes with some custom > >>key bindings (as one of my users mentioned in bug #1012). > >> > >>I've also noticed that the address bar bindings confuse a lot of > >>people, since they're not used to the Unix behavior. Conventionally, > >>Ctrl-A is "select all," and other input boxes in Dillo follow that, so > >>they aren't expecting it to go to the beginning of the line instead. How should dillo behave when a user binds Ctrl-A? > >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, > >Johannes Having input/insert mode and macros in keysrc would be interesting, if not too complex. > I was thinking just a simple boolean option in dillorc -- and turn > it OFF by default (i.e., no Unix keys), because it's not typical GUI > behavior, and anyone who wants it on can quite easily set it in his > or her own dillorc. Would be a strange dillorc option. A real patch would implement this in keysrc :) Somehow I failed to notice that Ctrl-A for select all is "typical GUI behavior", perhaps I am not using GUIs enough... > Making it consistent globally would be a bit tricky, since we'd have > to replace all Fl_Inputs with our custom widget (including in FLTK's > stock dialogs). Besides that, there's the matter of other FLTK > applications -- would users expect them to behave our way, too? > > Personally, I'd just as soon ditch the Unix keys altogether, but if > we must keep them, let's let the address bar remain the exception. > That way, we're not breaking the behavior either way -- new users > aren't surprised, and old users can keep it as it was. Here, Ctrl-A goes to the beginning of the line in all the input boxes ("find text", "web search", <input> in forms). > Although I will add, the Shift-{Left,Right} bindings in the address > bar *have* to go. They're fine elsewhere, if a bit quirky, but in > the address bar they interfere with text selection. Ctrl-Tab and > Ctrl-Shift-Tab are much more logical and convenient, anyway. > > ~Benjamin Are we using different versions of dillo? Shift-{Left,Right} doesn't do anything here. For the arguments sake, how would having to press Ctrl-Shift-Tab be more "logical and convenient" than Shift-Left? It's a matter of taste (habit). In my opinion, both bindings have a disadvantage: Ctrl-Shift-Tab is difficult for the fingers, Shift-Left is unusual to most people. That's why it is configurable, isn't it? -- -- Rogut?s Sparnuotos

Oct. 20, 2011