April 2008 - Dillo-dev - lists.mailman3.com

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