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

Re: [Dillo-dev] fltk c binding

by Indan Zupancic

You still have to compile the program with a C++ compiler, also it won't be supported in the future, not sure if it is now. Xforms seem to make things only more complex without any real benefits. Take a look at FLTK's code, from what I saw it's just c with classes. If all you use is classes from c++, and no STL or other stuff, then you can compile a program that doesn't link to standard c++ libraries and isn't bloated by c++.

Oct. 27, 2003

Re: [Dillo-dev] HTTPS patch

by Indan Zupancic

> Which version does the patch require? I tried against 0.7.3 and got some > errors - one in each of IO.c, Url.c and capi.c. Quote: "It was made against the current cvs" I guess that's pre 0.8. it shouldn't be much work to get it working with 0.7.3, if you want that then just say, I'll make another patch then. The current cvs version seems very stable, and Frank's patches are also cvs only, so it seems more than logical to me that if you want experimental new features, you use the cvs version. Two things I forgot to mention: If you want a lean and mean Dillo, then comment out or, remove "#define DEBUG_MSG 5" at the top of IO.c, the extra overhead of the spam isn't negligible on my 233 mhz computer (it also makes the https code much bigger). The openssl licence is a "GPL-Incompatible, Free Software Licenses", so it's needed to add an exception that says that DIllo may be linked to the openssl library, see for more info: http://www.gnu.org/philosophy/license-list.html#TOCGPLIncompatibleLicenses

Oct. 27, 2003

Re: [Dillo-dev] HTTPS patch

by Mike Eriksen

Which version does the patch require? I tried against 0.7.3 and got some errors - one in each of IO.c, Url.c and capi.c. Mike On Mon, 27 Oct 2003, Indan Zupancic wrote: > Get it here: http://www.xs4all.nl/~dorinek/dillo/dillo-ssl.diff.gz > > It's not as nice and simple as I wanted it to be, thanks to three things: > > 1) SSL can always read and write, meaning that SSL_write may want to read. > 2) Dillo uses two IOData structures per file descriptor. > 3) There is no efficient way of (un)registering file descriptor events in > GTK. (FLTK has a perfect interface). > > This three facts contribute a lot to the complexity of the code. > > There is one known bug, you may try to find it. ;) > Dillo will not crash, I made it exit with a message. > > This patch adds also generic ssl/tls support to Dillo, most work was done > in IO.c, http.c has hardly changed. The current way to tell the IO engine > that it should use ssl is by giving a negative fd to a_IO_new. This avoids > extra interface, is simple, and doesn't clash with anything else. > > Dillo is about 2K bigger after the patch. It was made against the current > cvs, apply it with 'patch -p1 < dillo-ssl.diff' while you're in the dillo > dir. Run configure with --disable-ssl if you don't want https... > > Have fun. > > p.s. > I hate glib ;), it's totally worthless, the most complex piece Dillo uses > is a hash table, and glib implements it as a linked list, look in the code > yourself if you don't believe me. Since when is ansi c not good enough? > Please switch to FLTK. :) > > p.s.s > This mail was sent from webmail with a patched Dillo. :) > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS

Oct. 27, 2003

fltk c binding

by cesar

Fltk was modeled following XForms and has a XForms compatibility layer: http://fltk.org/documentation.php/doc-1.1/forms.html#forms http://fltk.org/documentation.php/doc-2.0/forms.html#forms You can learn more about XForms here: http://world.std.com/~xforms/ pd: I don't know how to program using Fltk or XForms. I only was aware of this compatibility layer. Both also have a GUI designer. I only know of very few apps using XForms, the most important of those being LyX. cesar;

Oct. 27, 2003

HTTPS patch

by Indan Zupancic

Get it here: http://www.xs4all.nl/~dorinek/dillo/dillo-ssl.diff.gz It's not as nice and simple as I wanted it to be, thanks to three things: 1) SSL can always read and write, meaning that SSL_write may want to read. 2) Dillo uses two IOData structures per file descriptor. 3) There is no efficient way of (un)registering file descriptor events in GTK. (FLTK has a perfect interface). This three facts contribute a lot to the complexity of the code. There is one known bug, you may try to find it. ;) Dillo will not crash, I made it exit with a message. This patch adds also generic ssl/tls support to Dillo, most work was done in IO.c, http.c has hardly changed. The current way to tell the IO engine that it should use ssl is by giving a negative fd to a_IO_new. This avoids extra interface, is simple, and doesn't clash with anything else. Dillo is about 2K bigger after the patch. It was made against the current cvs, apply it with 'patch -p1 < dillo-ssl.diff' while you're in the dillo dir. Run configure with --disable-ssl if you don't want https... Have fun. p.s. I hate glib ;), it's totally worthless, the most complex piece Dillo uses is a hash table, and glib implements it as a linked list, look in the code yourself if you don't believe me. Since when is ansi c not good enough? Please switch to FLTK. :) p.s.s This mail was sent from webmail with a patched Dillo. :)

Oct. 27, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Melvin Hadasht wrote: >> A >> . >> . . B . C >> . . . >> D . E . F >> . . . >> G . H . I >> >>When moving focus DOWN from A, it will land in B (because that is the >>next LOWER link closest to A). >> >> > >I agree with this. It is also the common behaviour in text editors and >text processors. > > > >>Moving it down again lands it in C (NOT >>E), as that is the next LOWER link closest to the original x-coordinate. >> >> > > > Of course I meant D, not C... >I would expect that moving down will bring me to one of the links in the >D.E.F line, the link which x position is the closest to A's. As this is >a geometrical/(geographical) navigation, I'd expect a behaviour similar to >cursor motion in text editors. > > Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 26, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Jorge Arellano Cid

On Sat, 25 Oct 2003, Frank de Lange wrote: > Jorge Arellano Cid wrote: > > > For instance: placing the nav cursor in the [gtk_type_new] link > >inside the "struct GtkTypeObject" section and pressing DOWN, > >brings the cursor to the leftmost [GtkType] under gtk_type_unique > >but it is possible to get to the leftmost [GtkType] too! That is > >focusing the leftmost one, then going UP then DOWN again. > > > You mean left- and right-most link? As in... > > A > . > . > B . . C > > Going from A sometimes lands you in B, sometimes in C, depending where > you came from? Yes! > If so, that is by design. The code only modifies the 'x' cursor > coordinate when the link is explicitly moved to the left or right, NOT > when it is moved up or down. The reason for this is best explained in > yet another ASCII-graphic: > > A > . > . . B . C > . . . > D . E . F > . . . > G . H . I > > When moving focus DOWN from A, it will land in B (because that is the > next LOWER link closest to A). Moving it down again lands it in C (NOT > E), as that is the next LOWER link closest to the original x-coordinate. > If you now were to move focus to link E (by moving it to the right), it > would update the 'x' cursor coordinate, so the next move DOWN after that > would end up on H. > > The cursor is ALWAYS set to the current link's 'y' coordinate. In case > focus is moved out of context (eg when it is set by the search feature) > it should be set to the current link's 'x' coordinate as well. Thanks for the accurate explanation. If updating both coordinates helps to go from A to B and then to E (in the previous example), it'd be worth a try. > That's the theory, which is followed in the code - mostly. It might be > that there are some cases where context is retained while it should be > discarded. Combined with the unknown-location-problems this can lead to > unexpected behaviour. I understand. What worried me most was being able to reach a state where it was possible to jump over a set of links... > > The gain I see with this scheme is that you can scroll down a > >page, and when you find an interesting link "call" the keyboard > >navigation cursor and quickly select the link. Otherwise you're > >carried to the top of the page (or to wherever the cursor was > >left) and will have to start finding the scrolled region where > >the to-be-clicked link is. > > > Ah, that's what you mean. Yes, this will be implemented in the next > version as well. Good! Cheers Jorge.-

Oct. 25, 2003

Re: [Dillo-dev] Thanks

by Maurice McCarthy

Frank, I'll do my best to give you the most accurate description that I can but I'm afraid I'll be away from my machine for 3 to 4 weeks. (I work in the North Sea oil fields. There is no linux machine there and we have only email but no internet accesss.) Maybe I can sort it myself as partly it does compile OK but I've not got frames support. Best Maurice On Sat, Oct 25, 2003 at 03:40:18PM +0200 or thereabouts, Frank de Lange wrote: > Maurice McCarthy wrote: > > >The invitation is nice but I don't think I have the skill. Where I work > >if something is not functioning then you > > > >a) hit it with a scaffold pole > >b) if its too small, hit it with a shifter (adjustable spanner) > >c) take it apart and clean it > >d) if its electrical push every button in sight > >e) when you know you've really broken it then > >f) call the maintenance dept. > > > > > Good! Do this to my tab/frame and keyboard_navigatino patches and tell > me what you've managed to break! > > I'll release new versions of the patches RSN (tm) which should apply to > current CVS. > > Cheers//Frank >

Oct. 25, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Paul Pelzl

On Sat, Oct 25, 2003 at 03:14:22PM +0200, Frank de Lange wrote: > Jorge Arellano Cid wrote: > > Note: we use to work heavily on patches and commit only after > >they're stable or polished. All this with a view to keep a > >relatively stable CVS source tree to work with. This is different > >to the usual model, but it has its rewards. With regard to the > >keyboard navigation patch, it probably can be polished better > >when on CVS, so here my remarks to make the next version into the > >sources. > > > > > I agree with screening patches for bugs, but I think there should be a > way for patches to get more exposure than they currently do. Many eyes > make all bugs shallow, release early release often, rinse, repeat, etc. > I test te patches, but I can only try so many sites and combinations. > Several bugs have been found by users (eg. the LOCALE bug in > GtkFrameset) which I probably would not have found. Aren't these sorts of problems generally solved by using CVS branches? The main tree can remain stable, and the development code would be (marginally) easier to obtain and work with if it could be tracked via a CVS branch. Paul

Oct. 25, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Melvin Hadasht

> A > . > . . B . C > . . . > D . E . F > . . . > G . H . I > > When moving focus DOWN from A, it will land in B (because that is the > next LOWER link closest to A). I agree with this. It is also the common behaviour in text editors and text processors. > Moving it down again lands it in C (NOT > E), as that is the next LOWER link closest to the original x-coordinate. I would expect that moving down will bring me to one of the links in the D.E.F line, the link which x position is the closest to A's. As this is a geometrical/(geographical) navigation, I'd expect a behaviour similar to cursor motion in text editors. > If you now were to move focus to link E (by moving it to the right), it > would update the 'x' cursor coordinate, so the next move DOWN after that > would end up on H. OK. > The cursor is ALWAYS set to the current link's 'y' coordinate. In case > focus is moved out of context (eg when it is set by the search feature) > it should be set to the current link's 'x' coordinate as well. I came across the User Agent Accessibility Guideline 1.0 (http://www.w3.org/TR/WAI-USERAGENT/cover.html#toc) but there is not much information in it that could help deciding what behaviour is to be expected with the cursor motion (but again, those are guidelines).

Oct. 25, 2003