- Dillo-dev - lists.mailman3.com

[patch] phrase search - take 2

by jcid＠dillo.org

On Mon, Apr 28, 2008 at 10:10:21PM +0200, Johannes Hofmann wrote: > Hi, > > here comes my second attempt on phrase search. As already described, > I changed CharIterator back to not return \0s. Instead blanks are > inserted when the space flag is set. > This way CharIterator always returns a smooth stream of chars > whether for normal html- or pre-text. > Then there was a bug in DeepIterator::prev() that took me some > time to find. > I also adjusted charsEqual() to treat all space-chars equally. > Finally I had to add a check in CharIterator::highlight() to avoid a > crash when searching for the last word in pre-text with a blank > appended. Great. Committed. With this miscelany of bug fixes within patches, it seems some bugs are starting to vanish as "side effects" of patches (as with what Jeremy reports happened with tables!). -- Cheers Jorge.-

April 29, 2008

patch: Re: patch: Re: [Dillo-dev] start on image maps (dw-part)

by jcid＠dillo.org

On Sun, Apr 27, 2008 at 06:36:31PM +0000, corvid wrote: > > /* BUG: if several ISMAP images follow each other without > > * being separated with a word, only the first one is ISMAPed > > */ > > PS I left this old comment in, but if I make a file containing a bunch of > ismap images in a row, they certainly _seem_ ismapped. I click on them and > dillo tries to go to http://[wherever]?x,y. Yes, comment was deleted. -- Cheers Jorge.-

April 29, 2008

patch: Re: patch: Re: [Dillo-dev] start on image maps (dw-part)

by jcid＠dillo.org

On Sun, Apr 27, 2008 at 06:22:48PM +0000, corvid wrote: > Jorge wrote: > > Yes, ISMAP. > > All right, here you go. It turned out to be a lot of work :) Committed. It'd be good to hook emitMotionNotify() to have URL feedback for ISMAP in the status box. -- Cheers Jorge.-

April 29, 2008

[patch]: remove redundant #include in fltkflatview.cc

by onepoint＠starurchin.org

A small cleanup: the "#include <fltk/damage.h>" in fltkflatview.cc is unnecessary. Regards, Jeremy Henty

April 29, 2008

dillo seems to close file descriptors twice

by joerg.sonnenberger＠web.de

On Tue, Apr 29, 2008 at 04:54:20PM +0200, Johannes Hofmann wrote: > The signal is delivered as dillo writes to a socket that has been > closed by the remote side. I rather wonder, why this does not happen > on Linux. Just set it to SIG_IGN. Joerg

April 29, 2008

FIXED: [PATCH]: call widget->layout_damage() from FltkWidgetView::allocateFltkWidget

by onepoint＠starurchin.org

D'oh! "||" where I should have used "|"! What a n00b! Here's the fixed patch. (And this time I have tested by running all the executables in dw/test/ .) Regards, Jeremy Henty

April 29, 2008

dillo seems to close file descriptors twice

by Johannes.Hofmann＠gmx.de

Hi, On Tue, Apr 29, 2008 at 10:40:18AM -0400, Jorge Arellano Cid wrote: > On Tue, Apr 22, 2008 at 08:27:39PM +0200, Johannes Hofmann wrote: > > Hi, > > > > I just noticed, that dillo seems to close file descriptors twice via > > IO_close_fd, which causes problems when other threads run in parallel > > for name server queries. > > Here are the two call stacks via which IO_close_fd is called > > for each fd: > > OK, I committed a commented patch for this. Please test it. Yes, the double close problem is gone with this patch. > I'd be also interested to know whether this fixes the SIGPIPE > problems you saw in your OS. > > I remember removing the ignore SIGPIPE code because it didn't > happen anymore in GNU/Linux. It'd be good to know where it comes > from. The SIGPIPE problem is still there: Program received signal SIGPIPE, Broken pipe. 0x283e1050 in write () from /usr/lib/libc.so.6 (gdb) bt #0 0x283e1050 in write () from /usr/lib/libc.so.6 #1 0x28297f2c in write () from /usr/lib/libpthread.so.0 #2 0x080712a2 in IO_callback (fd=<value optimized out>, io=0x282a18c0) at IO.c:226 #3 0x080713f7 in IO_fd_write_cb (fd=7, data=0x1) at IO.c:303 #4 0x080bd4b9 in fltk::wait () #5 0x080bd669 in fltk::run () #6 0x0804eadb in main (argc=Cannot access memory at address 0x0) at dillo.cc:110 The signal is delivered as dillo writes to a socket that has been closed by the remote side. I rather wonder, why this does not happen on Linux. I found this on the topic: http://www.developerweb.net/forum/showthread.php?t=2953 Cheers, Johannes

April 29, 2008

dillo seems to close file descriptors twice

by jcid＠dillo.org

On Tue, Apr 22, 2008 at 08:27:39PM +0200, Johannes Hofmann wrote: > Hi, > > I just noticed, that dillo seems to close file descriptors twice via > IO_close_fd, which causes problems when other threads run in parallel > for name server queries. > Here are the two call stacks via which IO_close_fd is called > for each fd: OK, I committed a commented patch for this. Please test it. I'd be also interested to know whether this fixes the SIGPIPE problems you saw in your OS. I remember removing the ignore SIGPIPE code because it didn't happen anymore in GNU/Linux. It'd be good to know where it comes from. -- Cheers Jorge.-

April 29, 2008

[patch] fix table destructor

by Johannes.Hofmann＠gmx.de

Hi, with memleaks in the news lately.... Here comes another one. Cheers, Johannes

April 29, 2008

patch: fltkimgbuf memleak

by Johannes.Hofmann＠gmx.de

On Tue, Apr 29, 2008 at 01:24:49AM +0000, corvid wrote: > You should see a significant decrease in memory used. Wow, indeed! > > diff -pur dw2/dw/fltkimgbuf.cc dw2-cur/dw/fltkimgbuf.cc > --- dw2/dw/fltkimgbuf.cc 2008-01-16 02:57:23.000000000 +0000 > +++ dw2-cur/dw/fltkimgbuf.cc 2008-04-29 00:40:04.000000000 +0000 > @@ -119,11 +119,10 @@ FltkImgbuf::~FltkImgbuf () > //else > // printf("FltkImgbuf[root %p]: deleted\n", this); > > - if (!isRoot()) { > + if (!isRoot()) > root->detachScaledBuf (this); > - delete rawdata; > - } > > + delete rawdata; > delete copiedRows; > > if (scaledBuffers) > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 29, 2008

Future of dillo2

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote: > On Sun, Apr 27, 2008 at 05:33:33AM +0200, Justus Winter wrote: >> Somewhat related I would suggest to get rid of the location dialog (ctrl >> + l). As far as I can see it has offers nothing more than entering the >> address directly into the url bar, so whats the point? Make ctrl + l a >> shortcut that moves the cursor to the url bar instead. > > On the other hand the dialogs allow to use dillo without panel > (Ctrl-Space). That's a nice feature, indeed. What about getting rid of the dialog box and just showing the panel on demand in "without panel" mode? >> Flickering... there was a thread about fltk and double buffer >> something... there is no flickering when scrolling a page on my machine >> (there are some artifacts in the scrollbar, it looks like it is jumping >> around a little or changing its size) but if I move the whole window it >> flickers a lot. > > Both are fltk bugs I think. I also see this with fltk test > applications if I add clear_double_buffer(). > We should submit bug reports for that. If you have a small patch ready that introduces this behavior into one of their test programs I nominate you for this task :) >> And one more obscure bug I just noticed while playing around with the >> scrollbar: When I switch from one virtual desktop (my window manager is >> e17) to another with a dillo window on it and try to scroll the page it >> doesn't work. Most of the time it selects text on the page (it didn't >> when I recorded the movie, typical...). The problem goes away if I move >> or resize the window so I would guess that it has something to do with >> window coordinates / dimensions not being correct. I compiled dillo with >> fltk2 revision 6101. >> >> http://teythoon.cryptobitch.de/stuff/virtual-desktops.ogg > > I don't see this with dwm. Can you try whether fltk test > applications show this behaviour too? http://teythoon.cryptobitch.de/stuff/virtual-desktops-fltk2-problem.ogg You are right, this seems to be a fltk2 bug. I will file a bug report for this problem. Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIFyr6oPmwNWhsaZYRArM/AJ44W5nWh1xekGLtM1RrfmC9ujW3eACfTVbx OlU9NERtkjeQqraFwc96M2c= =pMct -----END PGP SIGNATURE-----

April 29, 2008

DO NOT: [PATCH]: call widget->layout_damage() from FltkWidgetView::allocateFltkWidget

by onepoint＠starurchin.org

D'oh! > This patch makes FltkWidgetView::allocateFltkWidget mark the FLTK > widget's layout as damaged. This fixes > dw::fltk::ui::FltkListResource (which is necessary to implement > MULTIPLE SELECT inputs in forms). And it also makes TextResources crash. Augh! Let me try and figure this out. Regards, Jeremy Henty

April 29, 2008

[PATCH]: call widget->layout_damage() from FltkWidgetView::allocateFltkWidget

by onepoint＠starurchin.org

This patch makes FltkWidgetView::allocateFltkWidget mark the FLTK widget's layout as damaged. This fixes dw::fltk::ui::FltkListResource (which is necessary to implement MULTIPLE SELECT inputs in forms). Currently a dw::fltk::ui::FltkListResource widget fails to display itself. (You can run test/dw-resource-test to see this). This is because the resource's fltk::MultiBrowser widget is created with a tiny size and later reallocated to the correct size. The viewport calls layout() each time, but this doesn't call widget->layout() unless the widget's layout is damaged. Unfortunately the layout is marked as damaged when the widget is created but *not* after it is resized, so MultiBrowser::layout() gets called when the widget is tiny, but not when it is the right size. Alas, MultiBrowser::draw() uses size information that was cached by MultiBrowser::layout() , so it behaves as though the widget is still tiny, concludes that none of the Items are visible and doesn't draw anything. This bug potentially bites all widgets, it's just sheer luck that only MultiBrowser is visibly affected. Other widgets are either simple enough to survive their layout() being called when they were a different size, or else smart enough to mark *themselves* as damaged so that the viewport calls their layout() at the right time. Regards, Jeremy Henty

April 29, 2008

patch: fltkimgbuf memleak

by corvid＠lavabit.com

You should see a significant decrease in memory used.

April 29, 2008

patch: motionNotify and LEAVE

by corvid＠lavabit.com

Since findtext has been in the news lately, I might as well at least provide this bit so that my code behaves better with dialogs.

April 28, 2008

Future of dillo2

by Johannes.Hofmann＠gmx.de

On Sun, Apr 27, 2008 at 05:33:33AM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Johannes Hofmann wrote: > > On Mon, Apr 21, 2008 at 03:39:50PM +0000, corvid wrote: > >> I think the very first thing is to update the main dillo.org > >> page so that visitors will know that dillo shows signs of life. > > I agree. We should update the front page and make it a bit more > > optimistic :-). > +1 > > Also I'd like to see some infrastructure changes like a more advanced > bug tracker / modify the existing one (user comments come to mind, and > *please* get rid of the background image in the search results). > > > What is still missing for an official release apart from image maps? > I like the way firefox is getting rid of more and more dialog boxes. > Like the "find in page" command. In firefox the user enters the search > string into a input field embedded in a bar emerging from the bottom of > the screen. > > This has several advantages: > * avoid cluttering the desktop (this is even more important if the > screen is very small [think mobile phones]) > * avoid to cover the search result (this is possible if it isn't > possible to scroll the windows content in a way that the search result > is visible) > * you always know which search box belongs to which browser window > since the search bar is a part of that window (this gets even worse with > tabs) > > Somewhat related I would suggest to get rid of the location dialog (ctrl > + l). As far as I can see it has offers nothing more than entering the > address directly into the url bar, so whats the point? Make ctrl + l a > shortcut that moves the cursor to the url bar instead. On the other hand the dialogs allow to use dillo without panel (Ctrl-Space). > > Flickering... there was a thread about fltk and double buffer > something... there is no flickering when scrolling a page on my machine > (there are some artifacts in the scrollbar, it looks like it is jumping > around a little or changing its size) but if I move the whole window it > flickers a lot. Both are fltk bugs I think. I also see this with fltk test applications if I add clear_double_buffer(). We should submit bug reports for that. > > And one more obscure bug I just noticed while playing around with the > scrollbar: When I switch from one virtual desktop (my window manager is > e17) to another with a dillo window on it and try to scroll the page it > doesn't work. Most of the time it selects text on the page (it didn't > when I recorded the movie, typical...). The problem goes away if I move > or resize the window so I would guess that it has something to do with > window coordinates / dimensions not being correct. I compiled dillo with > fltk2 revision 6101. > > http://teythoon.cryptobitch.de/stuff/virtual-desktops.ogg I don't see this with dwm. Can you try whether fltk test applications show this behaviour too? Cheers, Johannes

April 28, 2008

[patch] phrase search - take 2

by Johannes.Hofmann＠gmx.de

Hi, here comes my second attempt on phrase search. As already described, I changed CharIterator back to not return \0s. Instead blanks are inserted when the space flag is set. This way CharIterator always returns a smooth stream of chars whether for normal html- or pre-text. Then there was a bug in DeepIterator::prev() that took me some time to find. I also adjusted charsEqual() to treat all space-chars equally. Finally I had to add a check in CharIterator::highlight() to avoid a crash when searching for the last word in pre-text with a blank appended. Cheers, Johannes

April 28, 2008

Since we've been talking about name clashes, what about "assert"

by onepoint＠starurchin.org

On Sun, Apr 27, 2008 at 06:58:22PM +0200, Johannes Hofmann wrote: > On Sun, Apr 27, 2008 at 08:52:31AM +0100, Jeremy Henty wrote: > > > > Because lout::misc defines an inline assert function, including > > dw/core.hh fails if you've already included anything that defines > > the standard assert macro (such the C++ iostream stuff). > > I also see this with gcc 3.4.6, but not with gcc 4.1.2. That's surprising (at least to me). I guess gcc4 must resolve names differently? Or maybe it's smart enough not to macro-expand anything that looks like a macro token but appears somewhere where no macro token should? Anyway, I have no axe to grind on this, I just raised it as a concern. Regards, Jeremy Henty -- What is Jewish decision theory? Maximize regrets. -- Sidney Morgenbesser

April 27, 2008

patch: Re: patch: Re: [Dillo-dev] start on image maps (dw-part)

by corvid＠lavabit.com

> /* BUG: if several ISMAP images follow each other without > * being separated with a word, only the first one is ISMAPed > */ PS I left this old comment in, but if I make a file containing a bunch of ismap images in a row, they certainly _seem_ ismapped. I click on them and dillo tries to go to http://[wherever]?x,y.

April 27, 2008

patch: Re: patch: Re: [Dillo-dev] start on image maps (dw-part)

by corvid＠lavabit.com

Jorge wrote: > Yes, ISMAP. All right, here you go. It turned out to be a lot of work :)

April 27, 2008

Since we've been talking about name clashes, what about "assert"

by Johannes.Hofmann＠gmx.de

On Sun, Apr 27, 2008 at 08:52:31AM +0100, Jeremy Henty wrote: > > Because lout::misc defines an inline assert function, including > dw/core.hh fails if you've already included anything that defines the > standard assert macro (such the C++ iostream stuff). > > You can work around it by including dw/core.hh first, but that feels > pretty fragile as it depends on nothing subsequently using the > standard assert. What's the best fix? > > (Example appended.) I also see this with gcc 3.4.6, but not with gcc 4.1.2. Regards, Johannes > > Regards, > > Jeremy Henty > > > For example: > > #include <ios> > #include <dw/core.hh> > > yields (with GCC 3.4.3): > > In file included from ./../Source/current/dw2/dw/../lout/object.hh:7, > from ./../Source/current/dw2/dw/core.hh:39, > from dw_assert.cc:9: > ./../Source/current/dw2/dw/../lout/misc.hh:36:55: macro "assert" passed 3 arguments, but takes just 1 > In file included from ./../Source/current/dw2/dw/../lout/object.hh:7, > from ./../Source/current/dw2/dw/core.hh:39, > from dw_assert.cc:9: > ./../Source/current/dw2/dw/../lout/misc.hh:37: error: invalid function declaration > ./../Source/current/dw2/dw/../lout/misc.hh:185:30: macro "assert" passed 4 arguments, but takes just 1 > ./../Source/current/dw2/dw/../lout/misc.hh:198:30: macro "assert" passed 4 arguments, but takes just 1 > ./../Source/current/dw2/dw/../lout/misc.hh:213:30: macro "assert" passed 4 arguments, but takes just 1 > ./../Source/current/dw2/dw/../lout/misc.hh: In member function `T* lout::misc::SimpleVector<T>::getRef(int)': > ./../Source/current/dw2/dw/../lout/misc.hh:184: error: `assert' undeclared (first use this function) > ./../Source/current/dw2/dw/../lout/misc.hh:184: error: (Each undeclared identifier is reported only once for each function it appears in.) > ./../Source/current/dw2/dw/../lout/misc.hh: In member function `T lout::misc::SimpleVector<T>::get(int)': > ./../Source/current/dw2/dw/../lout/misc.hh:197: error: `assert' undeclared (first use this function) > ./../Source/current/dw2/dw/../lout/misc.hh: In member function `void lout::misc::SimpleVector<T>::set(int, T)': > ./../Source/current/dw2/dw/../lout/misc.hh:212: error: `assert' undeclared (first use this function) > make[1]: *** [dw_assert-dw_assert.o] Error 1 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 27, 2008

Re: patch: various IN_*s

by jcid＠dillo.org

Hi, On Sun, Apr 27, 2008 at 02:15:37PM +0000, corvid wrote: > - disallow <button> or <input> inside <button>. > Nested buttons and image inputs inside buttons don't come out right, > and they aren't legal anyway. OK. > - disallow <input> inside <select>. > As I mentioned before, </select> does not like that, and it isn't legal. ok. > - disallow <isindex> inside <form>. > It's legal (%block goes inside form, and isindex is a %block), > but it splits a form into pieces, given dillo's current implementation. > Firefox handles it as a form within a form, but I don't want to add > complexity, and I know you don't want to add complexity :) ok. Committed. -- Cheers Jorge.-

April 27, 2008

Since we've been talking about name clashes, what about "assert"

by onepoint＠starurchin.org

Because lout::misc defines an inline assert function, including dw/core.hh fails if you've already included anything that defines the standard assert macro (such the C++ iostream stuff). You can work around it by including dw/core.hh first, but that feels pretty fragile as it depends on nothing subsequently using the standard assert. What's the best fix? (Example appended.) Regards, Jeremy Henty For example: #include <ios> #include <dw/core.hh> yields (with GCC 3.4.3): In file included from ./../Source/current/dw2/dw/../lout/object.hh:7, from ./../Source/current/dw2/dw/core.hh:39, from dw_assert.cc:9: ./../Source/current/dw2/dw/../lout/misc.hh:36:55: macro "assert" passed 3 arguments, but takes just 1 In file included from ./../Source/current/dw2/dw/../lout/object.hh:7, from ./../Source/current/dw2/dw/core.hh:39, from dw_assert.cc:9: ./../Source/current/dw2/dw/../lout/misc.hh:37: error: invalid function declaration ./../Source/current/dw2/dw/../lout/misc.hh:185:30: macro "assert" passed 4 arguments, but takes just 1 ./../Source/current/dw2/dw/../lout/misc.hh:198:30: macro "assert" passed 4 arguments, but takes just 1 ./../Source/current/dw2/dw/../lout/misc.hh:213:30: macro "assert" passed 4 arguments, but takes just 1 ./../Source/current/dw2/dw/../lout/misc.hh: In member function `T* lout::misc::SimpleVector<T>::getRef(int)': ./../Source/current/dw2/dw/../lout/misc.hh:184: error: `assert' undeclared (first use this function) ./../Source/current/dw2/dw/../lout/misc.hh:184: error: (Each undeclared identifier is reported only once for each function it appears in.) ./../Source/current/dw2/dw/../lout/misc.hh: In member function `T lout::misc::SimpleVector<T>::get(int)': ./../Source/current/dw2/dw/../lout/misc.hh:197: error: `assert' undeclared (first use this function) ./../Source/current/dw2/dw/../lout/misc.hh: In member function `void lout::misc::SimpleVector<T>::set(int, T)': ./../Source/current/dw2/dw/../lout/misc.hh:212: error: `assert' undeclared (first use this function) make[1]: *** [dw_assert-dw_assert.o] Error 1

April 27, 2008

Cheering some recent improvements in table layout

by onepoint＠starurchin.org

Just to say that I'm seeing much better table rendering now. I have a page with a large two-column table. For a while recently this rendered very strangely in Dillo: it appeared with the two columns at opposite sides of the page, then the second column would move over to the left, one item at a time, to sit next to the first. But now the table immediately appears with both columns in the right place. I don't know what caused the strange realignment behaviour but I'm glad it's gone. Regards, Jeremy Henty

April 27, 2008

Future of dillo2

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote: > On Mon, Apr 21, 2008 at 03:39:50PM +0000, corvid wrote: >> I think the very first thing is to update the main dillo.org >> page so that visitors will know that dillo shows signs of life. > I agree. We should update the front page and make it a bit more > optimistic :-). +1 Also I'd like to see some infrastructure changes like a more advanced bug tracker / modify the existing one (user comments come to mind, and *please* get rid of the background image in the search results). > What is still missing for an official release apart from image maps? I like the way firefox is getting rid of more and more dialog boxes. Like the "find in page" command. In firefox the user enters the search string into a input field embedded in a bar emerging from the bottom of the screen. This has several advantages: * avoid cluttering the desktop (this is even more important if the screen is very small [think mobile phones]) * avoid to cover the search result (this is possible if it isn't possible to scroll the windows content in a way that the search result is visible) * you always know which search box belongs to which browser window since the search bar is a part of that window (this gets even worse with tabs) Somewhat related I would suggest to get rid of the location dialog (ctrl + l). As far as I can see it has offers nothing more than entering the address directly into the url bar, so whats the point? Make ctrl + l a shortcut that moves the cursor to the url bar instead. Flickering... there was a thread about fltk and double buffer something... there is no flickering when scrolling a page on my machine (there are some artifacts in the scrollbar, it looks like it is jumping around a little or changing its size) but if I move the whole window it flickers a lot. And one more obscure bug I just noticed while playing around with the scrollbar: When I switch from one virtual desktop (my window manager is e17) to another with a dillo window on it and try to scroll the page it doesn't work. Most of the time it selects text on the page (it didn't when I recorded the movie, typical...). The problem goes away if I move or resize the window so I would guess that it has something to do with window coordinates / dimensions not being correct. I compiled dillo with fltk2 revision 6101. http://teythoon.cryptobitch.de/stuff/virtual-desktops.ogg For automated regression testing and other cool stuff I'd love to see a feature to render pages directly to an image without opening any windows. That would be totally awesome (hint, hint). > A problematic thing is that there are no official fltk2 packages for > many distributions - or has that changed recently? Not that I am aware of any (debian has no packages) and since there is no fltk2 release yet I wouldn't get my hopes up... thing > I think, if we can then manage to get CSS support in, we will get > many new users. I personally don't need TABS. I agree that CSS is more important but it is also much harder. Tabs should be relatively straight forward since there is a tabs widget for fltk2 (judging by playing around with fluid2) and the dillo code is able to create new windows. I think that creating snapshots is a good idea since it allows users to test dillo and see any improvements. In fact I was thinking about making (daily?) builds of dillo and fltk2 and creating a 0install stream for them. I was trying to build dillo on solaris the other day (as a die hard portability test... It is amazing how hard it is to get anything compile on solaris out of the box... some blame this on linuxisms, but I say this is just solaris being stubborn) but fltk2 spoiled all the fun by being the failing component. I filed a bug report but since then (that was like 8 weeks ago) there is no reaction :( Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIE/QNoPmwNWhsaZYRAiV4AKCEWdN3FV1uClZJcUF5pWYB7cCLnwCeK43S dcA6i4YiWOub7E7W1iGgpdA= =S+kv -----END PGP SIGNATURE-----

April 27, 2008

"View Page source" scrolling problem

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey folks :) I found another bug / feature... I use a trackstick with mouse wheel emulation. This allows me to scroll text by pressing the middle button and moving the stick. Someone in the xorg input layer maps this to buttons 4 - 7 (up, down, left, right). Problem is that it is impossible to just scroll up. You end up being off by some degree and you get a event for left and right every now and then (confirmed using xev). Unfortunately this kills the scrolling in the view page source window: http://teythoon.cryptobitch.de/stuff/scroll-problem.ogg It would also be nice to be able to scroll left/right with buttons 6 and 7. Since there are mouses that have special navigation buttons (most likely also being number 6 and 7) it would be nice to be able to configure the mapping (firefox does this) for these buttons. That would make trackstick users happy and also those of us that are stuck with a mouse with those navigation buttons (I have access to one of those and the buttons are located at the left side so that you can press them with your thumb [not a very left-handed friendly design]. To make a long story short you just end up pressing them by accident the moment you filled out some huge form...). But then again, some people might find them useful. Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIE+EdoPmwNWhsaZYRArv+AJ0ZO6hR5Caw/eaHXtnwWv9RFEgETACfYn6v FcJ5rxwibEXoAK5ZLtmTNEs= =t0nP -----END PGP SIGNATURE-----

April 27, 2008

dillo-fltk on x86_64

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jorge Arellano Cid wrote: > After reviewing the thread, and a head scratching phase, I > committed the following code. please test it: > > +/* For some unknown reason, this doesn't compile on some 64bit platforms: > + * > + * if (sizeof (int) == sizeof (void*)) > + * return (int)value; > + * else > + * return ((int*)value)[0] ^ ((int*)value)[1]; > + */ > +#if SIZEOF_VOID_P == 4 > + return (int)value; > +#else > + return ((int*)value)[0] ^ ((int*)value)[1]; > +#endif Works like a charm :) > + choice5_answer = VOIDP2INT(number); dito. Dillo2 builds out of the box on linux/x86_64. Nice work everyone :) > Does it work for you with a: > > +downloads_dpi_CXXFLAGS = @LIBFLTK_CXXFLAGS@ It does. >> With my three patches applied dillo compiles and runs fine, however I >> had to create ~/.dillo and manually start dpid. Did I miss something here? > No, I forgot porting the creation of ~/.dillo from dillo1 to dillo2! > (as we all run dillo1 before, ~/.dillo was there :-) > dpid didn't start because it most probably wasn't in your path. Yes, that was indeed the problem. Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIE9quoPmwNWhsaZYRAqiwAJ9SMrcSOeK0TThwYnXVJq3xd+EHgQCggVtu 99J/iZXynpKWOYEwhBBAqPU= =SFEG -----END PGP SIGNATURE-----

April 27, 2008

Future of dillo2

by jcid＠dillo.org

On Mon, Apr 21, 2008 at 08:40:45PM +0200, Johannes Hofmann wrote: > On Mon, Apr 21, 2008 at 06:32:52PM +0000, corvid wrote: > > Johannes wrote: > > > What is still missing for an official release apart from image maps? > > > > For one thing, I think text search needs to work for phrases. > > Yes, and <Esc> should consistently close dialogs... But that's just > a minor issue. Oh, I forgot to mention that closing dillo's main windows with Escape is disabled to avoid accidentally closing the browser. -- Cheers Jorge.-

April 27, 2008

Future of dillo2

by jcid＠dillo.org

On Mon, Apr 21, 2008 at 08:40:45PM +0200, Johannes Hofmann wrote: > On Mon, Apr 21, 2008 at 06:32:52PM +0000, corvid wrote: > > Johannes wrote: > > > What is still missing for an official release apart from image maps? > > > > For one thing, I think text search needs to work for phrases. > > Yes, and <Esc> should consistently close dialogs... But that's just > a minor issue. With the latest patch in CVS, it seems to do. Please test. The save dialog sometimes refuse to close when the focus is in the text input area and Escape works to restore what was there. I don't know whether this is standard or desired behaviour. I find this dialog bindings strange anyway, as it loses the filename when changing directory. If enough people find it odd, we may try to change it. -- Cheers Jorge.-

April 27, 2008

[PATCH]: lout::misc::min

by jcid＠dillo.org

On Sun, Apr 27, 2008 at 12:15:05AM +0100, Jeremy Henty wrote: > > I mean, this *has* to be a typo, right? Fix committed. -- Cheers Jorge.-

April 27, 2008

patch: Re: patch: Re: [Dillo-dev] start on image maps (dw-part)

by jcid＠dillo.org

On Sat, Apr 26, 2008 at 07:27:18PM +0000, corvid wrote: > Johannes wrote: > > What about deleting coords earlier? I think they are no longer > > needed once the shape has been constructed. > > attached. > Committed. -- Cheers Jorge.-

April 27, 2008

[PATCH]: lout::misc::min

by jcid＠dillo.org

Hi, On Sun, Apr 27, 2008 at 12:30:18AM +0100, Jeremy Henty wrote: > > Followup: the dillo source doesn't use the 3-argument min, only the > 3-argument max, so this bug didn't break anything. Probably it wasn't worth calling it after all... :-) -- Cheers Jorge.-

April 27, 2008

[PATCH]: lout::misc::min

by onepoint＠starurchin.org

Followup: the dillo source doesn't use the 3-argument min, only the 3-argument max, so this bug didn't break anything. Jeremy Henty > diff -pru -- 00_pre/lout/misc.hh 01_post/lout/misc.hh > --- 00_pre/lout/misc.hh 2008-04-26 21:42:59.000000000 +0100 > +++ 01_post/lout/misc.hh 2008-04-27 00:03:02.000000000 +0100 > @@ -20,7 +20,7 @@ template <class T> inline T max (T a, T > > template <class T> inline T min (T a, T b, T c) > { > - return (min (a, max (b, c))); > + return (min (a, min (b, c))); > } > template <class T> inline T max (T a, T b, T c) > {

April 27, 2008

[PATCH]: lout::misc::min

by onepoint＠starurchin.org

I mean, this *has* to be a typo, right? Jeremy Henty

April 27, 2008

Docs question: dw::core::ui::ListResource::SelectionMode::SELECTION_AT_MOST_ONE

by onepoint＠starurchin.org

On Sat, Apr 26, 2008 at 03:08:21PM -0400, Jorge Arellano Cid wrote: > On Sat, Apr 26, 2008 at 10:46:26AM +0100, Jeremy Henty wrote: > > > > That's my guess too. If someone comfirms this I'll make a patch. > > Committed! Gosh, I appear to have developed the magical super-power to cause patches to appear merely by thinking about them! :-) (Thinks: tabs, tabs, tabs...) Regards, Jeremy Henty

April 27, 2008

dillo-fltk on x86_64

by jcid＠dillo.org

Hi Justus, > It's hard to get anything past you guys... revised patches are attached. :-) No, you just had bad luck. 64bit is a complex matter that looks simple. BTW, I'm quite happy that a few patches made dillo2 run on 64bit. On Wed, Apr 23, 2008 at 11:53:24PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey@all :) > > I ran into some issues compiling dillo. I solved / worked around them, > patches are attached. Here are my findings and my interpretations (let > me know in case I am way off somewhere): > > dw2 > === > gcc-4.2 on linux/x86_64 complained about two casts in lout/object.cc: > > object.cc:118: error: cast from ???void*??? to ???int??? loses precision > > I felt it was nonsense to check the size of void* at runtime and used > the preprocessor to choose which instruction to use based on the value > of SIZEOF_VOID_P. After reviewing the thread, and a head scratching phase, I committed the following code. please test it: +/* For some unknown reason, this doesn't compile on some 64bit platforms: + * + * if (sizeof (int) == sizeof (void*)) + * return (int)value; + * else + * return ((int*)value)[0] ^ ((int*)value)[1]; + */ +#if SIZEOF_VOID_P == 4 + return (int)value; +#else + return ((int*)value)[0] ^ ((int*)value)[1]; +#endif > dillo2 > ====== > There was another complaint by gcc: > > dialog.cc:249: error: cast from ???void*??? to ???int??? loses precision > > A parameter of type void* for a callback is used to carry a small > integer (most likely the number of the button pressed or something). I > solved this one by first casting to long and then to int. I saw this > somewhere on the net, don't know if this is too hacky. Committed as: + choice5_answer = VOIDP2INT(number); > dillo2/dpi > ========== > downloads.cc failed to compile since gcc couldn't find the fltk includes > (I chose not to install them to /usr/local/lib), so I poked around in > dpi/Makefile.am and managed to include LIBFLTK_CXXFLAGS into cxxflags > (/me is an automake n00b). Yeah, auto* is not simple. Does it work for you with a: +downloads_dpi_CXXFLAGS = @LIBFLTK_CXXFLAGS@ instead? (CVS has this tentative patch). > > With my three patches applied dillo compiles and runs fine, however I > had to create ~/.dillo and manually start dpid. Did I miss something here? No, I forgot porting the creation of ~/.dillo from dillo1 to dillo2! (as we all run dillo1 before, ~/.dillo was there :-) dpid didn't start because it most probably wasn't in your path. With regard to a missing SSL, yes, it'd be good not to try to compile https the. Patches are welcomed! :-) -- Cheers Jorge.-

April 26, 2008

[patch] phrase search

by Johannes.Hofmann＠gmx.de

On Sat, Apr 26, 2008 at 01:10:46PM -0400, Jorge Arellano Cid wrote: > Hi, > > Committed. > > On Tue, Apr 22, 2008 at 06:12:55PM +0200, Johannes Hofmann wrote: > > Hi, > > > > attached is a patch that make phrase search work. I'm not 100% sure > > about the CharIterator::prev() change. CharIterator::next() returned > > \0 between words, prev() didn't. So something was wrong. > > I decided to go with current next() behaviour and made prev() return > > \0 as word separator too. > > It looks reasonable. > > BTW, while working on fixing the parsing of " " (a not yet > committed work), I found that it's not clear how non-breaking > whitespace is handled/represented. Currently we have a parser/dw > mix that tries to render it "right" for HTML. The idea is to > decide how to render inside the HTML parser and to use dw for > that. Now there's some HTML logic built in dw, which would be > good not to have (an idea we talked with Sebastian long ago). > > For instance dillo1 handles NBSP better in some cases and worse > in others than dillo2. > > I think it'll have to wait until I find some time to dig into > it... > > > > > Also the current implementation only works if one enters exactly one > > blank between words in the search dialog. Should we collapse multiple > > blanks into one automatically? > > As a workaround, I don't see why not. > > BTW, the phrase search doesn't work with text wrapped by the > PRE element. This probably is related to a whole sentence/line > stored as a single dw word. Ah yes. I totally forgot about PRE. In normal text spaces are encoded using the "space" flag in Content. In PRE there is a separate Content object for each space. I think I will revert my change to CharIterator and make prev() work as next() originally did (i.e. not return any '\0'). Instead CharIterator will generate a ' ' if the space flag is set in a Content object. This way CharIterator will always create a stream of chars (no '\0's) with words in normal text separated by blanks. Then phrase search should work for PRE sections too. And it should even be possible to search for something like three blanks in a row within PRE sections. Patch will follow... Cheers, Johannes

April 26, 2008

patch: Re: patch: Re: [Dillo-dev] start on image maps (dw-part)

by corvid＠lavabit.com

Johannes wrote: > What about deleting coords earlier? I think they are no longer > needed once the shape has been constructed. attached.

April 26, 2008

Docs question: dw::core::ui::ListResource::SelectionMode::SELECTION_AT_MOST_ONE

by jcid＠dillo.org

On Sat, Apr 26, 2008 at 10:46:26AM +0100, Jeremy Henty wrote: > On Sat, Apr 26, 2008 at 10:31:51AM +0200, Johannes Hofmann wrote: > > On Sat, Apr 26, 2008 at 09:27:01AM +0100, Jeremy Henty wrote: > > > > > > The description of > > > dw::core::ui::ListResource::SelectionMode::SELECTION_AT_MOST_ONE > > > does not make sense. Should "The user may not the only selected > > > item." read "The user may unselect the only selected item."? > > > > I guess so. Maybe the comment was copied from > > SELECTION_EXACTLY_ONE_BY_USER and "unselect" was deleted instead of > > "not"? > > That's my guess too. If someone comfirms this I'll make a patch. Committed! -- Cheers Jorge.-

April 26, 2008

Re: patch: Accept-Charset: utf-8,*;q=0.8

by jcid＠dillo.org

On Sat, Apr 26, 2008 at 04:56:45PM +0000, corvid wrote: > Jorge wrote: > > Committed, assuming: > > > > "Accept-Charset: utf-8,*;q=0.8\r\n" > > > > means dillo2 leaves the door open to also receive iso-8859-1. > > Yes. Here's what the RFC says: > > The special value "*", if present in the Accept-Charset field, > matches every character set (including ISO-8859-1) which is not > mentioned elsewhere in the Accept-Charset field. If no "*" is present > in an Accept-Charset field, then all character sets not explicitly > mentioned get a quality value of 0, except for ISO-8859-1, which gets > a quality value of 1 if not explicitly mentioned. OK. -- Cheers Jorge.-

April 26, 2008

patch: /* todo: don't create things if button type is unknown */

by jcid＠dillo.org

Hi, Committed. -- Cheers Jorge.-

April 26, 2008

patch: Re: [Dillo-dev] start on image maps (dw-part)

by jcid＠dillo.org

On Sat, Apr 26, 2008 at 05:26:58PM +0000, corvid wrote: > Jorge wrote: > > On Tue, Apr 22, 2008 at 04:50:32AM +0000, corvid wrote: > > > dw: I added motionNotifyImpl() and currLink > > > > > > dillo: > > > - I imagine the setUseMap() in open_img() is probably supposed to be > > > routed through DilloImage. > > > - Html_read_coords() was borrowed from 0.8.6 and modified a fair amount. > > > For one thing, the old code couldn't handle whitespace preceding a comma. > > > - I didn't really like that dReturn_if_fail so far down in open_area() > > > since coords is dynamically allocated now, but I left it there. > > > > Committed this patch and also scroll_motionNotify.dw2. > > > > Shape image-mapped links work so far. Coordinates are not > > yet being sent. If I missed something, please repost the patch. > > (I assume this is a work in progress). > > What's not working exactly? We didn't do ISMAP yet, if that's what > you're saying... Yes, ISMAP. -- Cheers Jorge.-

April 26, 2008

Re: the last patch that I sent you BREAKS isindex.

by corvid＠lavabit.com

Jorge wrote: > On Thu, Apr 17, 2008 at 06:17:04AM +0000, corvid wrote: > > I shouldn't have moved isindex's connectActivate to close_form. > > If you wish, I can make a new version. > > Yes, please. I just wanted to let people on the list know that that patch wasn't sent to the list, so this isn't about anything that you might have applied to your tree. > > By the way, I found that the top of open_input needs > > if (html->InFlags & IN_SELECT) { > > MSG_HTML("INPUT inside SELECT\n"); > > return; > > } > > Otherwise, if another input sneaks in there, close_select will crash. > > Please include it in the patch. I'm planning to make a patch that contains a few IN_* tests that are needed here and there...

April 26, 2008

Re: the last patch that I sent you BREAKS isindex.

by jcid＠dillo.org

On Thu, Apr 17, 2008 at 06:17:04AM +0000, corvid wrote: > I shouldn't have moved isindex's connectActivate to close_form. > If you wish, I can make a new version. Yes, please. > > By the way, I found that the top of open_input needs > if (html->InFlags & IN_SELECT) { > MSG_HTML("INPUT inside SELECT\n"); > return; > } > Otherwise, if another input sneaks in there, close_select will crash. Please include it in the patch. -- Cheers Jorge.-

April 26, 2008

[patch] introduce lout namespace (was: namespace problem)

by jcid＠dillo.org

On Thu, Apr 24, 2008 at 09:18:30PM +0200, Johannes Hofmann wrote: > Hi, > > while trying to implement a fix to the namespace problem I came to > the conclusion that the easiest and least intrusive way is to keep > the existing namespaces in the lout directory and just wrap them in > another namespace "lout". > This fixes the name collision with signal. Committed. BTW, now the documentation should mention this "lout" namespace. ;-) -- Cheers Jorge.-

April 26, 2008

patch: /* todo: don't create things if button type is unknown */

by corvid＠lavabit.com

April 26, 2008

patch: Re: [Dillo-dev] start on image maps (dw-part)

by corvid＠lavabit.com

Jorge wrote: > On Tue, Apr 22, 2008 at 04:50:32AM +0000, corvid wrote: > > dw: I added motionNotifyImpl() and currLink > > > > dillo: > > - I imagine the setUseMap() in open_img() is probably supposed to be > > routed through DilloImage. > > - Html_read_coords() was borrowed from 0.8.6 and modified a fair amount. > > For one thing, the old code couldn't handle whitespace preceding a comma. > > - I didn't really like that dReturn_if_fail so far down in open_area() > > since coords is dynamically allocated now, but I left it there. > > Committed this patch and also scroll_motionNotify.dw2. > > Shape image-mapped links work so far. Coordinates are not > yet being sent. If I missed something, please repost the patch. > (I assume this is a work in progress). What's not working exactly? We didn't do ISMAP yet, if that's what you're saying...

April 26, 2008

I figured out why charset handling has been all broken lately.

by jcid＠dillo.org

On Thu, Apr 24, 2008 at 01:57:41AM +0000, corvid wrote: > The top of Nav_open_url has > > bool_t ForceReload = (URL_FLAGS(url) & > (URL_E2EReload + URL_ReloadFromCache)); > > When repushing URLs, URL_FLAGS contains URL_ReloadFromCache, > which is 0x100. And remember how Jorge changed bool_t from > int to unsigned char? I'd forgotten about it, too, which meant > I wasted some time looking in the wrong places for this bug. Ooops, sorry. I thought the parenthesis wrapping was returning a boolean value. Patch committed. diff -pru dillo2/src/nav.c dillo2-cur/src/nav.c --- dillo2/src/nav.c 2008-04-08 17:50:25.000000000 -0400 +++ dillo2-cur/src/nav.c 2008-04-26 13:19:27.000000000 -0400 @@ -204,14 +204,14 @@ static void Nav_stack_clean(BrowserWindo static void Nav_open_url(BrowserWindow *bw, const DilloUrl *url, int offset) { DilloUrl *old_url; - bool_t MustLoad; + bool_t MustLoad, ForceReload; int x, y, idx, ClientKey; DilloWeb *Web; - bool_t ForceReload = (URL_FLAGS(url) & - (URL_E2EReload + URL_ReloadFromCache)); MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); + ForceReload = (URL_FLAGS(url) & (URL_E2EReload + URL_ReloadFromCache)) != 0; + /* Get the url of the current page */ idx = a_Nav_stack_ptr(bw); old_url = a_History_get_url(NAV_UIDX(bw, idx)); -- Cheers Jorge.-

April 26, 2008

[patch] phrase search

by jcid＠dillo.org

Hi, Committed. On Tue, Apr 22, 2008 at 06:12:55PM +0200, Johannes Hofmann wrote: > Hi, > > attached is a patch that make phrase search work. I'm not 100% sure > about the CharIterator::prev() change. CharIterator::next() returned > \0 between words, prev() didn't. So something was wrong. > I decided to go with current next() behaviour and made prev() return > \0 as word separator too. It looks reasonable. BTW, while working on fixing the parsing of " " (a not yet committed work), I found that it's not clear how non-breaking whitespace is handled/represented. Currently we have a parser/dw mix that tries to render it "right" for HTML. The idea is to decide how to render inside the HTML parser and to use dw for that. Now there's some HTML logic built in dw, which would be good not to have (an idea we talked with Sebastian long ago). For instance dillo1 handles NBSP better in some cases and worse in others than dillo2. I think it'll have to wait until I find some time to dig into it... > Also the current implementation only works if one enters exactly one > blank between words in the search dialog. Should we collapse multiple > blanks into one automatically? As a workaround, I don't see why not. BTW, the phrase search doesn't work with text wrapped by the PRE element. This probably is related to a whole sentence/line stored as a single dw word. -- Cheers Jorge.-

April 26, 2008

Re: patch: Accept-Charset: utf-8,*;q=0.8

by corvid＠lavabit.com

Jorge wrote: > Committed, assuming: > > "Accept-Charset: utf-8,*;q=0.8\r\n" > > means dillo2 leaves the door open to also receive iso-8859-1. Yes. Here's what the RFC says: The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets not explicitly mentioned get a quality value of 0, except for ISO-8859-1, which gets a quality value of 1 if not explicitly mentioned.

April 26, 2008