- Dillo-dev - lists.mailman3.com

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

view src

by obeythepenguin＠gmail.com

Jeremy wrote: > corvid wrote: > >> I viewed source, edited the page, reloaded, and view source keeps >> showing me the old source. >> >> I thought this used to work. > > It may have worked once but my impression is that it has been like > this for quite a while. I have certainly had a note about it in my > TO-DO list for a long time. > > Regards, > Jeremy Henty Funny, the old view source dialog doesn't have that problem at all... ;-) ~Benjamin

Oct. 20, 2011

Address bar keys (bug #1012)

by obeythepenguin＠gmail.com

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. > > 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 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. 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. 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

Oct. 20, 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. 20, 2011

view src

by corvid＠lavabit.com

Jorge wrote: > A quick trick to avoid viewing source of the "view source" page. > A proper solution would be appreciatted. Does that break things, or do you just dislike it?

Oct. 20, 2011

Dillo 3 on OpenBSD

by obeythepenguin＠gmail.com

Just wanted to let you know that dillo-3.0 runs quite nicely on OpenBSD (tested with both mainline and Dillo-Win32, on OpenBSD 4.9/i386). Here are some quick build instructions for mainline if anyone wants to try it out. Note that I like to install things to my home directory, but you can remove the --prefix= and --bindir= options if you want to install it system-wide. 1. Download the Dillo and FLTK 1.3 sources to a convenient location -- I use ~/download. Note that OpenBSD doesn't currently have an FLTK 1.3 package. 2. Install some dependencies from OpenBSD's packages: $ sudo pkg_add -i bzip2 jpeg png 3. Build and install FLTK: $ cd /tmp $ tar -xzvf ~/download/fltk-1.3.0-source.tar.gz $ cd fltk-1.3.0 $ CFLAGS='-Os' CXXFLAGS='-Os' ./configure \ --prefix=$HOME/download/fltk --bindir=$HOME/bin --enable-xft $ make && make install 4. Build and install Dillo: $ cd /tmp $ tar -xjvf ~/download/dillo-*.tar.bz2 $ cd dillo-* $ CFLAGS='-Os' CXXFLAGS='-Os' ./configure \ --prefix=$HOME/download/dillo --bindir=$HOME/bin \ --disable-threaded-dns $ make && make install && strip $HOME/bin/dillo Dillo should be installed and ready to go. By the way, I don't know if you *need* --disable-threaded-dns in step 4. I usually add it, and I'm sure there's a reason, but I don't remember exactly why. So if you try it, let me know if Dillo runs without that option. :-) Cheers, ~Benjamin

Oct. 20, 2011

view src

by jcid＠dillo.org

On Wed, Oct 19, 2011 at 08:47:28PM +0000, corvid wrote: > Jeremy wrote: > > corvid wrote: > > > > > I viewed source, edited the page, reloaded, and view source keeps > > > showing me the old source. > > > > > > I thought this used to work. > > > > It may have worked once but my impression is that it has been like > > this for quite a while. I have certainly had a note about it in my > > TO-DO list for a long time. > > It mustn't have ever worked, since a_Capi_open_url() says > > } else if (Capi_url_uses_dpi(web->url, &server)) { > /* dpi request */ > if ((safe = a_Capi_dpi_verify_request(web->bw, web->url))) { > if (dStrcasecmp(scheme, "dpi") == 0) { > if (strcmp(server, "vsource") == 0) { > /* don't reload the "view source" page */ > } else { > > for some reason. A quick trick to avoid viewing source of the "view source" page. A proper solution would be appreciatted. -- Cheers Jorge.-

Oct. 20, 2011

view src

by corvid＠lavabit.com

Jeremy wrote: > corvid wrote: > > > I viewed source, edited the page, reloaded, and view source keeps > > showing me the old source. > > > > I thought this used to work. > > It may have worked once but my impression is that it has been like > this for quite a while. I have certainly had a note about it in my > TO-DO list for a long time. It mustn't have ever worked, since a_Capi_open_url() says } else if (Capi_url_uses_dpi(web->url, &server)) { /* dpi request */ if ((safe = a_Capi_dpi_verify_request(web->bw, web->url))) { if (dStrcasecmp(scheme, "dpi") == 0) { if (strcmp(server, "vsource") == 0) { /* don't reload the "view source" page */ } else { for some reason.

Oct. 19, 2011

[patch]: bind Ctrl-{PageUp, PageDown} to {left, right}-tab

by onepoint＠starurchin.org

Another case of "let's be like the other browsers". See: http://www.google.com/support/forum/p/Chrome/thread?tid=16c23e5647c48367&hl… This will require an update to the help page on the web site. Congratulations on the keysrc code, it was very easy to understand and modify. Next I was going to look at binding Ctrl-[1-8] to "go to the <n>-th tab" and Ctrl-9 to "go to the rightmost tab" for the same reasons as this patch - the other browsers do it. Comments? Regards, Jeremy Henty

Oct. 19, 2011

view src

by onepoint＠starurchin.org

corvid wrote: > I viewed source, edited the page, reloaded, and view source keeps > showing me the old source. > > I thought this used to work. It may have worked once but my impression is that it has been like this for quite a while. I have certainly had a note about it in my TO-DO list for a long time. Regards, Jeremy Henty

Oct. 19, 2011

Address bar keys (bug #1012)

by Johannes.Hofmann＠gmx.de

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. 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

Oct. 19, 2011

Address bar keys (bug #1012)

by obeythepenguin＠gmail.com

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. I'll be happy to write the patch, I just wanted to see if anyone would be willing to commit it first. :-) Cheers, ~Benjamin

Oct. 19, 2011

text-transform

by johannes.hofmann＠gmx.de

On Wed, Oct 19, 2011 at 07:04:01AM +0000, corvid wrote: > > I guess I must've gotten bored... > > http://www.dillo.org/test/text-transform.diff > http://www.dillo.org/css_compat/tests/text-transform.html Oh, very nice!

Oct. 19, 2011

text-transform

by corvid＠lavabit.com

I guess I must've gotten bored... http://www.dillo.org/test/text-transform.diff http://www.dillo.org/css_compat/tests/text-transform.html

Oct. 19, 2011

view src

by corvid＠lavabit.com

I viewed source, edited the page, reloaded, and view source keeps showing me the old source. I thought this used to work.

Oct. 19, 2011

Dillo Win32 Thoughts

by obeythepenguin＠gmail.com

Just as an update to my earlier post: I've just uploaded a new dillo-win32-3.0p2 release that fixes the dFcntl() bug on Unix, among other small changes. Sorry again for any inconvenience. ~Benjamin

Oct. 18, 2011

Dillo Win32 Thoughts

by obeythepenguin＠gmail.com

By the way, if you want to try Dillo-Win32 on Linux/Unix, download and apply this patch before you compile it: http://dillo-win32.sourceforge.net/TODO/dfcntl.diff This fixes the dFcntl implementation on Unix, so nonblocking I/O works correctly and the browser won't lock up. I only noticed this bug today, but I'm going to put up an updated release with the fix included when I get a chance. Apologies for any inconvenience, ~Benjamin

Oct. 18, 2011

Dillo Win32 Thoughts

by obeythepenguin＠gmail.com

Georg wrote: > Benjamin, > you mention that your Win32 version will also compile with Linux. I > tried to compile it on Linux and did not have much success. Your source > code package does not include a configure file for that such as the main > version does. I have doubts too that you frequently test if your version > still works on Linux. You can generate the configure script yourself by running autogen.sh (requires autoconf and automake). I don't include a pregenerated configure script mainly because I build my source tarballs using 'hg archive', and Mercurial is set not to track those files. I may change my release process in future versions to make installation from source easier. Technically, you're correct that I don't test Dillo-Win32 on *Linux*. I do, however, use it quite often on OpenBSD, as you can see in this (quite large) screenshot from my development machine: http://obeythepenguin.users.sourceforge.net/openbsd/files/screenshot.png > Will this version when compiled for Linux also use the sockets > abstraction layer and not use the dpi parts? > Georg The sockets abstraction layer and DPI are two entirely separate things. The sockets layer is just some low-level network code that lets Dillo connect whether it's on Unix or Windows. Dillo doesn't know the difference, and that's the entire point -- it behaves exactly the same on both systems. As far as DPI, it's a little more complicated. In a nutshell: - Bookmarks, cookies, and HTTPS are built into the browser, and don't use DPI. - Downloads are built in by default, but you can disable the built-in downloader and use the DPI. - Everything else will fall back on DPI if it's available. Dillo-Win32 doesn't build dpid and DPI programs by default, but it will use mainline's DPIs if they're installed on the system. I haven't removed DPI support from Dillo -- I just moved most of their functionality into the browser. Hope this helps, ~Benjamin

Oct. 18, 2011

Fwd: RE: keysrc broken in dillo 3?

by obeythepenguin＠gmail.com

Here's an interesting one for you guys... I had a user email me this morning saying his keysrc file stopped working after he upgraded from Dillo 2.2 to 3.0. Neither his existing keysrc nor a fresh one would work on his machine, while I couldn't reproduce the problem on mine. We just now discovered by chance it wasn't his keysrc that was the problem, but -- strangely enough -- that he had set start_page=about:blank in his dillorc. I've forwarded his original message below (with names and headers removed for privacy), which includes a more detailed explanation. I was just curious if anyone could reproduce this in mainline before I filed a bug report, or if this behavior was specific to Dillo-Win32. I don't have a Unix system handy now, or else I'd just test it myself. :-) Cheers, ~Benjamin ------- Forwarded message ------- I tracked down the source of the behavior and I think it should be reproducible now. In dillorc I had the following line: start_page=about:blank (By now you've probably figured out I'm a Firefox user..) Apparently Dillo 3 does not like for start_page to have this value, and will only load keysrc after a non-blank page is loaded?! This doesn't happen in Dillo 2.2 (20110630) but I'm not sure if this is an intentional change in behavior; probably not, considering the following weirdness: These values allow keysrc to be loaded without having to load a non-blank page: start_page=about:blank#any comment start_page= Sorry, I haven't had a chance to try any of this out in Linux, so still not sure whether this is an upstream regression.. For completeness my old cookiesrc, dillorc, and keysrc files are all attached (files that reproduce the artifact).

Oct. 18, 2011

[patch]: download window resizes its contents to its width

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > On Sun, Oct 16, 2011 at 11:27:54AM +0100, Jeremy Henty wrote: > > > > Bump! Any reason not to push this? I do not see any issues. > > Please commit. Done! Regards, Jeremy Henty

Oct. 17, 2011

Scrollable view without scrollbar

by Hole.destructor＠gmx.de

On Mon, Oct 17, 2011 at 08:43:42PM +0200, Johannes Hofmann wrote: > Hm, it works fine for me here. > Any details (dillo version, window manager, etc)? I'm using Window manager: fvwm 2.5.30 Operating system: Debian squeeze with Linux 2.6.32-5-amd64 FLTK version: 1.3.0 Compiler: gcc (Debian 4.4.5-8) 4.4.5 I'm also using the default geometry of the Dillo window (I did not touch the geometry line in dillorc) and panel size tiny. What I also noticed: If I open the site and change the window width (increase or decrease it) the issue disappears, i.e. I can't scroll anymore with the <left> and <right> buttons. Kind regards, Alexander

Oct. 17, 2011

small panel_size, small_icons, progress boxes don't fit.

by corvid＠lavabit.com

Just noticed that with small panel_size and small_icons, the labels in the progress boxes don't fit.

Oct. 17, 2011

Scrollable view without scrollbar

by Johannes.Hofmann＠gmx.de

On Mon, Oct 17, 2011 at 08:29:52PM +0200, Alexander Voigt wrote: > Dear Dillo developers, > > I found a site today (see appendix), which is scrollable in Dillo, > i.e. you can press <left> and <right> and the view scrolls left and > right, but the view has no horizontal scrollbar. What is also strange > here is that the site has no fixed width elements, so the view should > not be scrollable. > > What's happening here? Hm, it works fine for me here. Any details (dillo version, window manager, etc)? Regards, Johannes

Oct. 17, 2011

Scrollable view without scrollbar

by Hole.destructor＠gmx.de

Dear Dillo developers, I found a site today (see appendix), which is scrollable in Dillo, i.e. you can press <left> and <right> and the view scrolls left and right, but the view has no horizontal scrollbar. What is also strange here is that the site has no fixed width elements, so the view should not be scrollable. What's happening here? Kind regards, Alexander P.S.: The site is a boiled down version from today's blog.fefe.de

Oct. 17, 2011

[patch]: download window resizes its contents to its width

by jcid＠dillo.org

On Sun, Oct 16, 2011 at 11:27:54AM +0100, Jeremy Henty wrote: > > Bump! Any reason not to push this? I do not see any issues. Please commit. -- Cheers Jorge.-

Oct. 17, 2011

Dillo Win32 Thoughts

by mailbox＠georgpotthast.de

Benjamin, you mention that your Win32 version will also compile with Linux. I tried to compile it on Linux and did not have much success. Your source code package does not include a configure file for that such as the main version does. I have doubts too that you frequently test if your version still works on Linux. Will this version when compiled for Linux also use the sockets abstraction layer and not use the dpi parts? Georg

Oct. 17, 2011

Dillo Win32 Thoughts

by rogerx.oss＠gmail.com

>> 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. 17, 2011

Dillo Win32 Thoughts

by obeythepenguin＠gmail.com

Hmm, looks like I picked the wrong week to unsubscribe... (it's been a busy semester so I'm trying to cut back on distractions and inbox clutter) Roger wrote: > I had the pleasure of trying out Dillo win32 and I must say I like it. > (Itstarts a heck of alot faster then that bloated green lizard thing ... > sorry,the name doesn't come to mind right now. ;-) >Only one or two things. >1) When I first installed it. I was completely stumped as to how to use > thebookmarks. I was trying to add a bookmark without going to the > actual sitefirst. One thing that could really eleviate all this, is by > setting a fewpreset default bookmarks (ie. www.google.com, and other > favorite searchengines.) Notice, there's no "add bookmark" within the > menu and you have tohave the insight to right click on the displayed > page to get this menu.) Thanks for the suggestion -- I'll add some presets in the next release. One small correction: there *is* an "add bookmark" option, but it's labeled "Bookmark this page" for consistency with the right-click menu. You can also press Ctrl-D to get it, like in Firefox or Opera. I based my bookmarks interface on Opera's, since that's what I'm personally most familiar with (I think Firefox's is similar). So it makes sense to me, but it's probably a bit of a change from mainline Dillo's. I'll have to see what other users think so I know if I need to tweak it. > 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. > 3) One thing I really dislike about Windows, there's no main package > managerlike the Linux distributions for updating all of your other win32 > open sourcepackages. Think most packages & drivers have been all > implementing their ownupdate check routine within their Help menus, > etc. Now, they just have to getthe idea of updating their own packages, > such as Adobe Reader. That would be nice too, although I'm not a fan of the Linux distribution system where you're depending on the distribution maintainers rather than the individual package developers to provide updates. Of course, that all goes back to the lack of proper binary compatibility on the platform, which is a completely different story altogether. > Dillo win32, installs within a few seconds or so. Dillo starts within a > fewseconds too. Dillo win32 is functional as well. Glad you like it! Georg wrote: > what I like about the Win32 version is the fact that it compiles to one > standalone executable file. No dpi is used. > > Georg I rather like that, too ;-) Stephan wrote: > Hello, >I just gave Dillo another try on Cygwin/X11 and got it working at > least partially with cygwin 1.7.9. >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). You can't get rid of the ".exe" extension, because Windows relies on the extension to identify executable files (rather than file permissions, like on Unix). > 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 >Looks like the socket implementation of cygwin still has some quirks > which can maybe tracked down. First of all, I'll just say from my own experience: sockets on Windows are a mess. The main problem is socket and file handles aren't interchangeable on Windows, so you can't e.g. dup2() stdio handles to a socket. DPI relies heavily on that trick, which is the main technical reason there's no native DPI on Windows. As I understand it, Cygwin implements a bunch of clever tricks to emulate the Unix sockets behavior, but they're quirky at best because of technical differences in the underlying system design. > Is there any interest to support this target on a source code basis? >Thanks and Greets, > Stephan From what I've seen, the Dillo developers aren't interested in Windows at all, via Cygwin or otherwise. Of course, I don't want to put words into their mouths; Cygwin will probably require less extensive patching than a native port like mine, so you may have better luck than I have. I will say I'm personally not a fan of Cygwin, since it negates all the advantages Dillo provides: speed, efficiency, small size, easy installation. A native port like Dillo-Win32 doesn't involve any of Cygwin's complexity or overhead, so it's much more useful to the vast majority of Windows users. Side note: I'm working on a patch to provide native DPI on Windows. So far it compiles, but it's not functional yet, and it's *extremely* ugly code. Email me if you want a copy. Georg wrote: > I suggest to implement a configure option that causes the dpi functions > tobe linked with the main dillo code. The dpic then needs to be adapted > tocall these functions directly instead of forking a new process. This > wouldgreatly simplify porting Dillo to other platforms. >I guess the Dillo developers have already done this for their > development sothey can step through the entire code with GDB. >Georg It's not quite as simple to do as you've described, but that's essentially what I've done with Dillo-Win32: move all the DPI functionality into the browser. Some of it, like HTTPS support and the downloader, is new code, but a lot of it is straight copy-and-paste -- for example, cookies, and the bookmarks backend (but not the user interface). I've also introduced some new features like a sockets abstraction layer that greatly help Dillo's portability. Dillo-Win32's a bad name for my project, because it's not _only_ for Windows, but since that was my original target the name stuck. I'd like to get my code into mainline (that was my goal from the start), but it requires extensive changes to Dillo's inner workings, and the DPI thing has been a bit of an issue. I'm not absolutely opposed to it, but I think the current implementation is deeply flawed, and I don't believe in implementing required functionality through an extension mechanism since required functionality is by definition not an extension. Anyway, sorry for the _obscenely_ long email, but I hope this covers everything. :-) Thanks again for all the feedback, suggestions, discussions, distractions, etc. Cheers, ~Benjamin

Oct. 17, 2011

text selection and images

by corvid＠lavabit.com

I wrote: > > I think this may be a different problem, but I discovered that moving the > mouse about a lot while selecting text (I think it helps if the page is > shorter than the viewport) can get: > [...] The valgrind complaints go away if we check the case where we're in the space following the word specially. I'm guessing that the nextGlyph() loop happens to 'work' but shouldn't.

Oct. 16, 2011

text selection and images

by corvid＠lavabit.com

I think this may be a different problem, but I discovered that moving the mouse about a lot while selecting text (I think it helps if the page is shorter than the viewport) can get: ==14918== Conditional jump or move depends on uninitialised value(s) ==14918== at 0x80F6F65: fl_utf8fwd (fl_utf.c:228) ==14918== by 0x8090434: dw::fltk::FltkPlatform::nextGlyph(char const*, int) (fltkplatform.cc:558) ==14918== by 0x808F671: dw::Textblock::sendSelectionEvent(dw::core::SelectionState::EventType, dw::core::MousePositionEvent*) (layout.hh:302) ==14918== by 0x808F849: dw::Textblock::motionNotifyImpl(dw::core::EventMotion*) (textblock.cc:539) ==14918== by 0x809EDA2: dw::core::Layout::motionNotify(dw::core::View*, int, int, dw::core::ButtonState) (layout.cc:795) ==14918== by 0x8097BB3: dw::fltk::FltkViewBase::handle(int) (fltkviewbase.cc:272) ==14918== by 0x80A8AFE: send(int, Fl_Widget*, Fl_Window*) (Fl.cxx:1035) ==14918== by 0x80A92A5: Fl::handle_(int, Fl_Window*) (Fl.cxx:1347) ==14918== by 0x80A8B6B: Fl::handle(int, Fl_Window*) (Fl.cxx:1115) ==14918== by 0x80DBD1C: do_queued_events() (Fl_x.cxx:198) ==14918== by 0x80DC15B: fd_callback(int, void*) (Fl_x.cxx:340) ==14918== by 0x80DBFF1: fl_wait(double) (Fl_x.cxx:257)

Oct. 16, 2011

[patch]: download window resizes its contents to its width

by jcid＠dillo.org

On Sun, Oct 16, 2011 at 11:27:54AM +0100, Jeremy Henty wrote: > > Bump! Any reason not to push this? I do not see any issues. Sorry for the delay, I've been quite busy these days. Will try to look at it today... -- Cheers Jorge.-

Oct. 16, 2011

[patch]: download window resizes its contents to its width

by onepoint＠starurchin.org

Bump! Any reason not to push this? I do not see any issues. Regards, Jeremy Henty Jeremy Henty wrote: > > Purely cosmetic, but I dislike it when the contents ignore their > container, even in only one out of two dimensions. Comments? > > Regards, > > Jeremy Henty > # HG changeset patch > # Parent 1a801718e0ab473a3a891f3b79b70ddb29c02eef > downloads DPI: make the download items resize horizontally with the main window. > > diff -r 1a801718e0ab dpi/downloads.cc > --- a/dpi/downloads.cc Thu Oct 06 18:59:52 2011 +0100 > +++ b/dpi/downloads.cc Thu Oct 06 21:42:29 2011 +0100 > @@ -1087,6 +1087,29 @@ > } > > /* > + * A Scroll class that resizes its resizable widget to its width. > + * see http://seriss.com/people/erco/fltk/#ScrollableWidgetBrowser > + */ > +class DlScroll : public Fl_Scroll > +{ > +public: > + void resize(int x_, int y_, int w_, int h_) > + { > + Fl_Widget *resizable_ = resizable(); > + if (resizable_) > + resizable_->resize(resizable_->x(), > + resizable_->y(), > + w() - scrollbar_size(), > + resizable_->h()); > + Fl_Scroll::resize(x_, y_, w_, h_); > + } > + DlScroll(int x, int y, int w, int h, const char *l = 0) > + : Fl_Scroll(x, y, w, h, l) > + { > + } > +}; > + > +/* > * Create the main window and an empty list of requests. > */ > DLWin::DLWin(int ww, int wh) { > @@ -1097,12 +1120,13 @@ > // Create the empty main window > mWin = new Fl_Window(ww, wh, "Downloads:"); > mWin->begin(); > - mScroll = new Fl_Scroll(0,0,ww,wh); > + mScroll = new DlScroll(0,0,ww,wh); > mScroll->begin(); > mPG = new Fl_Pack(0,0,ww-18,wh); > mPG->end(); > mScroll->end(); > mScroll->type(Fl_Scroll::VERTICAL); > + mScroll->resizable(mPG); > mWin->end(); > mWin->resizable(mScroll); > mWin->callback(dlwin_esc_cb, NULL); > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Oct. 16, 2011

text selection and images

by Johannes.Hofmann＠gmx.de

There seems to be a problem with images and text selection. When you select the text in foo bar <img src="foo" alt="img"> foo bar the second foo gets selected completely while the mouse is in the space after the <img>. The relevant code seems to be Textblock::sendSelectionEvent(), but I couldn't spot the error yet. Any ideas? Cheers, Johannes

Oct. 15, 2011

Dillo Win32 Thoughts

by rogerx.oss＠gmail.com

> On Fri, Oct 14, 2011 at 07:14:06PM +0200, Georg Potthast wrote: >I suggest to implement a configure option that causes the dpi functions to >be linked with the main dillo code. The dpic then needs to be adapted to >call these functions directly instead of forking a new process. This would >greatly simplify porting Dillo to other platforms. > >I guess the Dillo developers have already done this for their development so >they can step through the entire code with GDB. ah. I forgot about that. I'm a big fan of easy debugging! ;-) -- Roger http://rogerx.freeshell.org/

Oct. 15, 2011

Dillo Win32 Thoughts

by mailbox＠georgpotthast.de

I suggest to implement a configure option that causes the dpi functions to be linked with the main dillo code. The dpic then needs to be adapted to call these functions directly instead of forking a new process. This would greatly simplify porting Dillo to other platforms. I guess the Dillo developers have already done this for their development so they can step through the entire code with GDB. Georg

Oct. 14, 2011

Dillo on Cygwin/X

by keepalive＠gmail.com

Hello, I just gave Dillo another try on Cygwin/X11 and got it working at least partially with cygwin 1.7.9. 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 Looks like the socket implementation of cygwin still has some quirks which can maybe tracked down. Is there any interest to support this target on a source code basis? Thanks and Greets, Stephan

Oct. 14, 2011

Dillo Win32 Thoughts

by rogerx.oss＠gmail.com

> On Thu, Oct 13, 2011 at 06:04:14PM +0200, Georg Potthast wrote: >what I like about the Win32 version is the fact that it compiles to one >standalone executable file. No dpi is used. You have a really good point here. I've been caught one too many times with a stale dpid daemon on Linux! ... still think there should be one or two default bookmarks within win32 Dillo for easier user comprehension of the bookmarks feature. Although, I hinder at the thought of the additional 3rd party stuff. (For me, I just use a bookmarked www.google.com with this also set to the home & startup site. No Bing pushing here.) -- Roger http://rogerx.freeshell.org/

Oct. 13, 2011

Dillo Win32 Thoughts

by mailbox＠georgpotthast.de

what I like about the Win32 version is the fact that it compiles to one standalone executable file. No dpi is used. Georg

Oct. 13, 2011

Dillo Win32 Thoughts

by rogerx.oss＠gmail.com

I had the pleasure of trying out Dillo win32 and I must say I like it. (It starts a heck of alot faster then that bloated green lizard thing ... sorry, the name doesn't come to mind right now. ;-) Only one or two things. 1) When I first installed it. I was completely stumped as to how to use the bookmarks. I was trying to add a bookmark without going to the actual site first. One thing that could really eleviate all this, is by setting a few preset default bookmarks (ie. www.google.com, and other favorite search engines.) Notice, there's no "add bookmark" within the menu and you have to have the insight to right click on the displayed page to get this menu.) 2) Copy & paste work only within the displayed page and not within the url field. (Although I really miss middle button pasting in Windows.) 3) One thing I really dislike about Windows, there's no main package manager like the Linux distributions for updating all of your other win32 open source packages. Think most packages & drivers have been all implementing their own update check routine within their Help menus, etc. Now, they just have to get the idea of updating their own packages, such as Adobe Reader. Dillo win32, installs within a few seconds or so. Dillo starts within a few seconds too. Dillo win32 is functional as well.

Oct. 12, 2011

Digest authentication

by furaisanjin＠gmail.com

2011/10/12 corvid <corvid at lavabit.com>: > Changes committed. Thanks for digging into what was going wrong in detail... I tried the new codes and my DVD recorder is happy with the changes. Thank you for the update. Regards, furaisanjin

Oct. 11, 2011

Digest authentication

by corvid＠lavabit.com

Changes committed. Thanks for digging into what was going wrong in detail...

Oct. 11, 2011

Digest authentication

by corvid＠lavabit.com

furaisanjin wrote: > The problems of my DVD recorder are > 1 it doesn't allow extra space characters between '='. My impression has been that rfc 2617, following rfc 2616's rules, permits implied linear whitespace in such places. But we can take the spaces out. > 2 uri needs to have quote I was sure this was wrong. And it turns out that this is in the errata (http://www.rfc-editor.org/errata_search.php?rfc=2617) 'Errata ID: 2600 Status: Verified Type: Technical Reported By: Victor S. Osipov Date Reported: 2010-11-02 Verifier Name: Peter Saint-Andre Date Verified: 2011-07-14 Section 3.2.2 says: digest-uri = "uri" "=" digest-uri-value digest-uri-value = request-uri ; As specified by HTTP/1.1 It should say: digest-uri = "uri" "=" <"> digest-uri-value <"> digest-uri-value = request-uri ; As specified by HTTP/1.1 Notes: This is an error here that the digest-uri-value is not enclosed in quotation marks' > 3 the order of parameter seems to have strict rule (username, realm, > nonce, uri, cnonce, nc, algorithm, response, qop) > > Both IE and firefox follow 1 and 2 but only IE follows 3. We could try it and see whether all of the stupid software (or at least most of the stupid software) likes that order.

Oct. 11, 2011