- Dillo-dev - lists.mailman3.com

SEGFAULT with mouse click
by jcid＠dillo.org Sept. 26, 2008

Sept. 26, 2008

Hi, I just came accross an easy to reproduce segfault, that's present since long ago. Middle-clicking works OK right? Well, try middle-clicking a link with a two mouse button (i.e. pressing both at the same time). The link menu stays open and after a second click (e.g. left click to make it dissapear) it segfaults. -- Cheers Jorge.-

2 3

patch: Re: [Dillo-dev] what's next
by corvid＠lavabit.com Sept. 25, 2008

Sept. 25, 2008

Johannes wrote (way back in June!): > * The cursor is not always updated properly when over a link. This > happens while page is rendered and also when drag-scrolling with > the middle mouse button. How about updating it from layout()?

3 6

release packaging
by akemnade＠tzi.de Sept. 25, 2008

Sept. 25, 2008

Hi, I have a question about release packaging: Currently you need to download three tarballs to compile dillo (fltk,dw,dillo). I doubt that any linux distribution has fltk2 packages at the moment. (and also not openembedded) What's the plan about that? Make one big tarball of everything (with some selected fltk snapshot) or do you expect the distributions to include a fltk2 package as soon as they see dillo-fltk? The question came to during thinking how to make bitbake files for openembedded. Regards, ndreas Kemnade

7 12

Redraw storms
by onepoint＠starurchin.org Sept. 23, 2008

Sept. 23, 2008

Since dillo got tabs I'm seeing "redraw storms": sometimes after opening a new tab every movement of the mouse triggers a redraw. It doesn't seem to depend on the number of tabs. Usually it will go away eventually (just after a tab is closed). I upgraded to the latest FLTK2 snapshot but it has made no difference. Is anyone else seeing this? Regards, Jeremy Henty

4 11

Redraw storms: the trigger
by onepoint＠starurchin.org Sept. 23, 2008

Sept. 23, 2008

I think the redraw storms start whenever the main window is resized horizontally and there are too many tabs to fit in the horizontal space (so that the tab menu button has appeared). Vertical resizes do not cause the problem. It is also safe to resize horizontally or vertically before the tab menu button appears. Once the storm has started it stops whenever the tab menu button disappears, whether this is due to closing some tabs or widening the window. The storm starts again whenever the tab menu button reappears, whether or not there has been any more resizing. Do other people see this? Jeremy Henty

1 0

patch: fonts, utf-8 tabs
by corvid＠lavabit.com Sept. 21, 2008

Sept. 21, 2008

The ui.cc changes are so that I can make a tabs screenshot with Asian script at some point. Similarly, the dialog.cc change is so that I can see Asian characters in source. Kept forgetting to deal with that...

1 0

patch: making some concessions to aesthetics...
by corvid＠lavabit.com Sept. 21, 2008

Sept. 21, 2008

I've decided to admit that highlighting checkboxes and radio buttons is always hideous. I had been trying to avoid the special case, but I know the horribleness would jump right out at someone trying dillo2... (And I decreased the RELIEF_X_THICKNESS because 5 makes <button>s look weird at my low resolution)

1 0

[patch] minor optimization in StyleAttrs::equals()
by Johannes.Hofmann＠gmx.de Sept. 20, 2008

Sept. 20, 2008

Hi, this patch adds a missing optimization to StyleAttrs::equals(). Similar checks are already in place in other equals() methods. Cheers, Johannes

2 1

[patch] fixup resizable of after tab removal
by Johannes.Hofmann＠gmx.de Sept. 19, 2008

Sept. 19, 2008

Hi, I was seeing crashes when removing tabs. The reason is that when we accidentally remove and delete the resizable of the TabGroup, fltk still tries to access it. Attached patch fixes that. It also moves the hide/showLabel functionality into CustTabGroup. Cheers, Johannes

1 0

8.68% of my time in assert()?
by corvid＠lavabit.com Sept. 19, 2008

Sept. 19, 2008

Turning off bounds checking for get and getRef does get rid of nearly all of the assert()s, but I was just trying -Winline and discovered: ./lout/misc.hh: In function 'void lout::misc::assert(bool, const char*, ...)': ./lout/misc.hh:36: warning: function 'void lout::misc::assert(bool, const char* , ...)' can never be inlined because it uses variable argument lists .. Earlier I'd said assert() was not cheap, but I was still uncertain about how -g and -pg might be affecting inlining. Now I _know_ that assert() is not cheap.

3 10

Confused by the comment to CustInput::handle()
by onepoint＠starurchin.org Sept. 19, 2008

Sept. 19, 2008

In dillo2/src/ui.cc, CustInput::handle() has a comment saying that it disables CTRL+{o,r,HomeKey,EndKey}, yet it only seems to disable CTRL+o . I think CTRL+r used to be disabled too, so that CTRL+r would reload the page even if the URL widget had the focus. Here's a one-line patch to restore that. What should we do about CTRL+{HomeKey,EndKey}? I prefer HomeKey and EndKey to scroll the main window even when the URL has the focus. Wasn't that the behaviour originally? It certainly doesn't happen now. Regards, Jeremy Henty

2 2

Latest libpng fixes crashes
by onepoint＠starurchin.org Sept. 18, 2008

Sept. 18, 2008

I recently looked at why dillo almost always crashed when viewing http://www.packtpub.com/article/transaction-model-of-postgresql and discovered it was happening in the depths of libpng. Luckily libpng-1.2.32 fixes this problem, so if you have been seeing unexpected crashes that might be due to PNG images then I recommend upgrading libpng. Regards, Jeremy Henty

1 0

patch: scroll upon resize
by corvid＠lavabit.com Sept. 17, 2008

Sept. 17, 2008

You know how - you are scrolled down or to the right - you make the viewport larger - the scrollbar disappears - you can only get the rest of the document back by hitting some arrow keys or something This seems to fix it, although my usual dw disclaimer applies: I don't know whether this is necessarily the right place for the change. PS When making the viewport very narrow and then maximizing, I notice that the location bar does not go back to showing the whole address. I don't know whether that's dillo's fault or fltk's fault. PPS Amazing how much code we need for dealing with scrolling and scrollbars...

3 4

load_images and multiple windows
by Johannes.Hofmann＠gmx.de Sept. 16, 2008

Sept. 16, 2008

Hi, the load_images button toggles the global prefs.load_images variable but the buttons of other browser windows are not updated accordingly. Should load_images be a per window variable, or should we update the buttons in all other windows? Also, when switching to load_images=true, the "Load images" entry in the popup menu get's deactivated, even though the images of the current page are not yet loaded. Cheers, Johannes

3 6

[patch] findbar appearance
by Johannes.Hofmann＠gmx.de Sept. 15, 2008

Sept. 15, 2008

Hi, attached path adjusts the findbar to match the appearance of the panel. Cheers, Johannes

1 0

patch: small mem leaks
by corvid＠lavabit.com Sept. 13, 2008

Sept. 13, 2008

Jeremy kindly provided the memory checking output that went with the valgrind logs from the other day. (I knew about the FullScreen one, but might as well comment it out until someone hooks it up.)

1 0

More Cache memory corruption
by onepoint＠starurchin.org Sept. 12, 2008

Sept. 12, 2008

Hi everyone! No, I'm not dead. I am sorry I haven't been able to spend much time on Dillo recently. I've been lurking and it's good to see Dillo getting lots of developer love. Now the bad news: this HTML almost invariably crashes Dillo: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" /> </head> <body> </body> </html> The culprit is the <meta...> tag. Dillo always crashes in one of two ways: segmentation fault or glibc detecting memory corruption and aborting. In each case the backtrace from gdb is the same (verified by running Dillo 100 times (it only failed to crash twice)). The backtraces show that the Cache_* functions are freeing things they should not. Valgrind confirms this. I'm attaching backtraces and a valgrind log. I'm not sure how to debug this further. If anyone can suggest ways to trace this further I'll have a go. Looking forward to the dill2 release! This will be a great milestone. Jeremy Henty

3 3

Missing include directive for OpenBSD?
by Christian.Kellermann＠nefkom.net Sept. 12, 2008

Sept. 12, 2008

Dear List, I have not updated dillo2 for a long time. Now that I have done so I see that I have missed a lot! I needed the following tiny patch to allow compilation on my OpenBSD 4.3 System: Index: dw/style.cc =================================================================== RCS file: /sfhome/cvs/dillo/dw2/dw/style.cc,v retrieving revision 1.10 diff -b -u -p -r1.10 style.cc --- dw/style.cc 5 Sep 2008 12:58:52 -0000 1.10 +++ dw/style.cc 7 Sep 2008 11:50:08 -0000 @@ -24,6 +24,7 @@ #include <string.h> #include <unistd.h> #include <ctype.h> +#include <sys/stdint.h> #include "core.hh" I am not sure whether this should have been caught by an autoconfig check. Can someone point me into the right direction so this can be changed to a proper patch? Thanks for your efforts and please keep up the good work! Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

3 6

patch: more widget coloring
by corvid＠lavabit.com Sept. 11, 2008

Sept. 11, 2008

My main forms testing page has bg #00ffff from when I was first experimenting with widget colors. Some time ago, fltk changed so that selected checkboxes and radio buttons use selection_color(). I had this set to the inverse of the background. Red. Not a good combination to say the least. Well, I finally got around to trying to fix it up a little. By the way, I was looking at that big page of inputs with differently-colored backgrounds that I made in February... At the time, I wrote that you guys had gotten the page down to 0:06 to load with clear_double_buffer(), immediate to load without it, and 0:09 to destroy the page. The good news is that it now takes the same amount of time with or without clear_double_buffer(), but the bad news is that it takes 0:12 to load and 0:48 to close.

3 7

[patch] remove asap parameter
by Johannes.Hofmann＠gmx.de Sept. 10, 2008

Sept. 10, 2008

Hi Jorge, any objections to remove the asap parameter as in attached patch? It has been disabled for quite some time now. Cheers, Johannes

2 6

assertion failed during wildly clicking on links
by akemnade＠tzi.de Sept. 10, 2008

Sept. 10, 2008

Hi, I have seen the following, when clikling multiple times very fast on a link: Nav_open_url: new url='http://www.dwd.de/sid_520SLCXTTJJbtdSgR7JTsLGvkNt6TkS9ssWxDtLpSvVZtPCcyjPG!…' Connecting to 141.38.3.62 DilloHtml(): content type: text/html; charset=UTF-8 *** [unknown] Assertion failed! *** anchor 'headline_color_324A92' not defined Aborted I tried www.dwd.de and then to click Wetter&Warnungen and the corresponding link. I have not looked into the source yet, but I think there is a ressource management problem. Greetings Andreas Kemnade

2 3

default font_factor
by Johannes.Hofmann＠gmx.de Sept. 8, 2008

Sept. 8, 2008

Hi, recently the the default font_factor was changed from 1.0 to 1.2. Is there a reason for this change? Cheers, Johannes

3 4

an example of page redraw problem when images load
by corvid＠lavabit.com Sept. 8, 2008

Sept. 8, 2008

With automatic image loading turned off, if I go to http://genode.org/documentation/developer-resources/walk_through , page down to the [IMG] below "The launchpad application starter", and click on it, the space to the right of the image still contains remnants of the text that used to be there.

3 7

Fixed FltkViewBase::drawRectangle()
by Johannes.Hofmann＠gmx.de Sept. 7, 2008

Sept. 7, 2008

Hi Jorge, regarding the last change in fltkviewbase.cc: --- a/dw/fltkviewbase.ccSat Sep 06 19:51:25 2008 +0200 +++ b/dw/fltkviewbase.ccSun Sep 07 10:51:04 2008 +0200 @@ -384,7 +384,9 @@ setcolor(((FltkColor*)color)->colors[shading]); int x1 = translateCanvasXToViewX (x); int y1 = translateCanvasYToViewY (y); - ::fltk::Rectangle rect (x1, y1, width, height); + int x2 = translateCanvasXToViewX (x + width); + int y2 = translateCanvasYToViewY (y + height); + ::fltk::Rectangle rect (x1, y1, x2 - x1, y2 - y1); if (filled) fillrect (rect); else To me it looks like this change is only necessary, if translateCanvasXToViewX() would do some sort of scaling. Was there a real problem, or did you change it just for consistency? Cheers, Johannes

2 1

[patch] fix compilation on OpenBSD
by Johannes.Hofmann＠gmx.de Sept. 7, 2008

Sept. 7, 2008

Hi, this fixes compilation on OpenBSD. Please verify on Linux. Cheers, Johannes

1 0

8.68% of my time in assert()?
by corvid＠lavabit.com Sept. 6, 2008

Sept. 6, 2008

Recompiled with -O2 -pg. Moved back and forth between two pages (10k and 130k) repeatedly. gprof said: % cumulative self self total time seconds seconds calls ms/call ms/call name 27.43 0.79 0.79 517177 0.00 0.00 dw::Textblock::wordWrap(int) 10.42 1.09 0.30 45 6.67 51.95 Html_write_raw(DilloHtml*, char*, int, int) 8.68 1.34 0.25 5845490 0.00 0.00 lout::misc::assert(bool, char const*, ...) 5.38 1.50 0.16 183777 0.00 0.00 dw::Textblock::addWord(int, int, int, dw::core::style::Style*) 3.47 1.60 0.10 158682 0.00 0.01 dw::Textblock::addText(char const*, dw::core::style::Style*) 2.78 1.68 0.08 151303 0.00 0.00 Html_process_space(DilloHtml*, char const*, int) 2.78 1.76 0.08 143 0.56 0.70 dw::Textblock::sizeAllocateImpl(dw::core::Allocation*) 2.78 1.84 0.08 21 3.81 4.91 dw::Textblock::~Textblock() 2.43 1.91 0.07 145864 0.00 0.00 dw::Textblock::addSpace(dw::core::style::Style*) 2.43 1.98 0.07 38885 0.00 0.00 Html_tag_index(char const*) 2.43 2.05 0.07 utf8towc 1.74 2.10 0.05 517177 0.00 0.00 dw::Textblock::getWordExtremes(dw::Textblock::Word*, dw::core::Extremes*) 1.74 2.15 0.05 158682 0.00 0.00 dw::Textblock::calcTextSize(char const*, dw::core::style::Style*, dw::core::Requisition*) 1.74 2.20 0.05 75140 0.00 0.00 dw::Textblock::addLine(int, bool) 1.74 2.25 0.05 utf8decode 1.74 2.30 0.05 DilloHtml::HtmlLinkReceiver::~HtmlLinkReceiver() 1.56 2.34 0.05 13231 0.00 0.01 Html_get_attr2(DilloHtml*, char const*, int, char const*, int) 1.22 2.38 0.04 13351 0.00 0.00 dw::core::style::StyleAttrs::hashValue() 1.04 2.41 0.03 31375 0.00 0.00 Html_push_tag(DilloHtml*, int) 1.04 2.44 0.03 3861 0.01 0.02 a_Html_set_top_font(DilloHtml*, char const*, int, int, int) 1.04 2.47 0.03 193 0.16 0.23 dw::Textblock::rewrap() 0.69 2.49 0.02 73744 0.00 0.00 dStr_append_c 0.69 2.51 0.02 3020 0.01 0.02 a_Url_new ..(total 2.88 sec.) Naturally I thought that's a lot of time to spend in assert(). I wonder what would happen if I turned off BOUND_CHECKING in SimpleVector in lout/misc.hh. This gave % cumulative self self total time seconds seconds calls ms/call ms/call name 20.75 0.50 0.50 572066 0.00 0.00 dw::Textblock::wordWrap(int) 8.71 0.71 0.21 50 4.20 36.14 Html_write_raw(DilloHtml*, char*, int, int) 6.02 0.86 0.15 83051 0.00 0.00 dw::Textblock::addLine(int, bool) 5.81 1.00 0.14 202074 0.00 0.00 dw::Textblock::addWord(int, int, int, dw::core::style::Style*) 5.60 1.13 0.14 174493 0.00 0.01 dw::Textblock::addText(char const*, dw::core::style::Style*) 5.39 1.26 0.13 157 0.83 0.83 dw::Textblock::sizeAllocateImpl(dw::core::Allocation*) 4.56 1.37 0.11 utf8towc 3.53 1.46 0.09 42701 0.00 0.00 Html_tag_index(char const*) 2.90 1.53 0.07 14483 0.00 0.01 Html_get_attr2(DilloHtml*, char const*, int, char const*, int) 2.90 1.60 0.07 fltk::setfont(fltk::Font*, float) 2.49 1.66 0.06 174493 0.00 0.00 dw::Textblock::calcTextSize(char const*, dw::core::style::Style*, dw::core ::Requisition*) 2.49 1.72 0.06 34442 0.00 0.00 Html_tag_cleanup_at_close(DilloHtml*, int) 2.07 1.77 0.05 174517 0.00 0.00 dw::fltk::FltkPlatform::textWidth(dw::core::style::Font*, char const*, int ) 2.07 1.82 0.05 23 2.17 3.54 dw::Textblock::~Textblock() 2.07 1.87 0.05 fltk::getwidth(char const*, int) 1.66 1.91 0.04 166375 0.00 0.00 Html_process_space(DilloHtml*, char const*, int) 1.66 1.95 0.04 9528 0.00 0.01 Url_object_new 1.24 1.98 0.03 14615 0.00 0.00 dw::core::style::StyleAttrs::hashValue() 1.24 2.01 0.03 7820 0.00 0.00 dw::core::style::StyleAttrs::equals(lout::object::Object*) 1.24 2.04 0.03 212 0.14 0.14 dw::Textblock::rewrap() 0.83 2.06 0.02 160393 0.00 0.00 dw::Textblock::addSpace(dw::core::style::Style*) 0.83 2.08 0.02 11374 0.00 0.00 dw::core::style::drawBackground(dw::core::View*, dw::core::Rectangle*, int , int, int, int, dw::core::style::Style*, bool) 0.83 2.10 0.02 9521 0.00 0.00 a_Url_free .. [snip] .. 0.00 2.41 0.00 44 0.00 0.00 lout::misc::assert(bool, char const*, ...) ..(total 2.41 sec.) I don't know whether -pg affects the ability to inline... and bounds checking is important... but it makes one think that maybe SimpleVector's get() and getRef() might be made cheaper, or we might at least avoid gratuitously making repeated get()s, since it turns out that they are not free. (_and_ I could have run many more trials, but the idea that assert() was even capable of reaching that high was alarming)

3 5

a little experiment in showing form encoding as a tooltip
by corvid＠lavabit.com Sept. 5, 2008

Sept. 5, 2008

Currently, there's a MSG that tells you what encoding a form was submitted as -- once it's submitting it. Obviously that's of limited usefulness when you want to know beforehand what will happen to any Japanese that you might type in, but on other hand, so many pages have forms that MSGs ahead of time would be annoying, besides the fact that a page may have multiple forms with different accept-charset attrs... Add to that the fact that one has to learn the hard way that you should only paste utf-8 into dillo2 and not, say, windows-1257. (and latin-1 works because fltk assumes it's latin-1 and does the conversion) So my quick little experiment: text/password/textarea form controls display a tooltip that reads enter: UTF-8 when UTF-8 will be submitted, and enter: UTF-8 send as: [some other encoding] otherwise. And it would clear things up for every person who tried to use google.com and wondered why non-latin-1 wasn't working when the oh-so-glorious dillo2 is supposed to be all UTF-8ed up. After all, it works in Firefox, right? (I've read that google pulls this idiocy with all of the little browsers. w3m, elinks, etc. Ignores the Accept-Charset header and does what it wants based on the User-Agent.) A different option might be to have a form popup menu to show info such as submission encoding, hidden inputs, and so on. As for the code, unfortunately I have setTooltip()s all over the place because Style's Tooltip field is for real tooltips, not for char*s to stuff into pre-existing tooltips such as the fltk widgets have.

2 2

Keyboard scrolling and focus patch
by jcid＠dillo.org Sept. 4, 2008

Sept. 4, 2008

On Thu, Sep 04, 2008 at 10:51:56PM +0200, Johannes Hofmann wrote: > > > > Please test, and enjoy. > > Nice. Thanks you! :-) > > PS: I've also made some experiments with tabs, but it seems FLTK2 > > has problems to handle window widgets inside the tabs... > > Why do You need a window (instead of a simple widget) inside the > tabs? Currently dillo2 uses window, so Ctrl-N can open a new window. It would have been convenient not to change the current code base, and to reuse that already tested part for both tabs and new windows (with the idea of being able to open tabs or new windows with the same code). It may be possible by switching class UI to derive from Group, and to add an enclosing window only when necessary, and thus arrange for widgets inside Tabs and Window for windows. The problem I foresee with the latter scheme is messing with the event passing between widgets and windows... I'll have to experiment with it, and get some working code. Now, if *somebody* wants to help then, that'd be great! ;-) -- Cheers Jorge.-

1 0

Keyboard scrolling and focus patch
by jcid＠dillo.org Sept. 4, 2008

Sept. 4, 2008

Hi there, Finally a patch for fixing keyboard scrolling, and focus change with the keyboard, was committed. I had hopes to be able to commit before the release, and so I'm happy. :) Now switching focus from the viewport to the location bar, using the keyboard, works consistently (Try TAB/Shift-TAB) and also the scrolling keys (Up, Down, Left, Right, PgUp/b, PgDn/space, etc) are kept in a responsive state. It's been a long time, and I almost forgot the nice feeling of scrolling with the keyboard (e.g. try the space bar to skip past the links menu most pages have these days). Please test, and enjoy. -- Cheers Jorge.- PS: I've also made some experiments with tabs, but it seems FLTK2 has problems to handle window widgets inside the tabs...

1 0

patch: make image inputs less of a special case
by corvid＠lavabit.com Sept. 1, 2008

Sept. 1, 2008

- have the complex button resource remember its click x,y. - just use the Activate signal instead of Clicked - don't have to carry x,y through so much of the form code. - use appendValues instead of that special case in buildQueryData. (Jorge: I have another version of the form action url display patch, but this jumped ahead of it somehow)

2 1

init_rawdatabuffer is slow.
by corvid＠lavabit.com Sept. 1, 2008

Sept. 1, 2008

That's the code that paints the stripes that you see initially in images. Here's what gprof said when I loaded a 2 meg jpeg: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 34.76 0.57 0.57 1 570.00 570.00 dw::fltk::init_rawdatabuffer(int, int, int, int, unsigned char 26.83 1.01 0.44 1536 0.29 0.29 dw::fltk::FltkImgbuf::copyRow(int, unsigned char const*) 25.00 1.42 0.41 379 1.08 1.08 dStr_insert_l 7.32 1.54 0.12 rgb_to_565d(unsigned char const*, unsigned char*, int, int) 0.61 1.55 0.01 7759 0.00 0.00 lout::container::untyped::Iterator::hasNext() .. If I take out the init_rawdatabuffer() call and put in a bzero() instead, I get: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 51.43 0.54 0.54 1536 0.35 0.36 dw::fltk::FltkImgbuf::copyRow(int, unsigned char const*) 34.29 0.90 0.36 373 0.97 0.97 dStr_insert_l 5.71 0.96 0.06 rgb_to_565d(unsigned char const*, unsigned char*, int, int) 1.90 0.98 0.02 a_Image_imgbuf_new 0.95 0.99 0.01 10868 0.00 0.00 lout::container::untyped::Collection0::AbstractIterator::unref() .. Any objections, then, to having pictures start out black instead of striped?

3 2

Bugtrack DB updated
by jcid＠dillo.org Aug. 30, 2008

Aug. 30, 2008

Hi, The Bugtrack DB was updated for dillo2 too. -- Cheers Jorge.-

2 9

web site partial update
by jcid＠dillo.org Aug. 28, 2008

Aug. 28, 2008

Hi, With a view to prepare our next dillo2 release, the web site has been partially updated. From the links column, these sections: Developers, Users, Related and "Hosted at" are up to date. Even the downloadable alternative icons work, and pages were bug-meter validated too. BTW, what version number should we give to dillo2? 2.0 seems like a good candidate. -- Cheers Jorge.-

2 1

patch: make prefs.c and dillorc2 consistent
by corvid＠lavabit.com Aug. 26, 2008

Aug. 26, 2008

The proposal here is to have everything commented out in the rc by default, and show what the default settings are so that people don't have to spend as much time experimenting when they want to configure their nifty superbrowser. When resolving inconsistencies, I generally picked the rc setting when uncommented, and the prefs one otherwise. Figured it would be a fair approximation of what Jorge might accept... Also, I remember Jorge once saying that maybe it should be named dillo2rc instead of dillorc2. I think so too.

2 4

Re: patch: disallow textarea/button inside select
by jcid＠dillo.org Aug. 25, 2008

Aug. 25, 2008

On Sun, Aug 24, 2008 at 01:25:02AM +0000, corvid wrote: > Putting aside the Stash one for something easy > (with Stash, the html file is like 90K, and it > seems like touching any of it makes the crashing > stop, so...), I find that textarea or button inside > select is bad because close_select assumes that > current input is a select. > > An alternative would be to make close_select > check the current input, but then other > controls aren't supposed to be inside it anyway... > > I feel like we already had this bug and fixed it, > but I must be thinking of whatever specifically made > us add the IN_SELECT test to open_input. We may find a canonical way to implement this constraints in the future (e.g. only OPTION|OPTGROUP in SELECT), maybe inside Html_process_tag()... Committed... -- Cheers Jorge.-

1 0

a list of what dillo2 runs on
by jcid＠dillo.org Aug. 25, 2008

Aug. 25, 2008

On Tue, Aug 19, 2008 at 08:22:54PM +0000, corvid wrote: > > The key is to be informative and that page construction > > and updating is a breeze to do. > > > > > Is it officially obsolete, or should parts of Current Plans > > > migrate over there eventually? > > > > I agree that "current plans" fits the goal better. If you can > > think of a _simple_ way to make it better, go ahead. > > > > This is, in principle I agree that removing the achieved goals > > link, and favouring "Current Plans" improves the site. Now, if we > > find a simple way to keep "Current Plans" up to date and not > > bloated, better. > > I haven't been able to think of anything good... in order to > at least have something, though, how about if I add a link like > "Goals reached since last update" to the bottom of achieved goals, > pointing to current plans? > (where they get migrated over hopefully whenever a release is made, > or at least when they are so old that they can no longer be ignored...) ... or we may switch to this scheme: [Current Plans] // as it is [Changelog Highlights] // for last release [Changelog] // full changelog This looks simple to maintain and understand. (removing achieved goals). -- Cheers Jorge.-

1 0

Problem compiling on FreeBSD
by christopher.illies＠ki.se Aug. 25, 2008

Aug. 25, 2008

Hi, on FreeBSD-7.0-STABLE, fltk-2.0.r6149 from ports I get the following error while compiling the newest dillo from CVS: > cd dw2-cur; ./autogen.sh && ./configure && make aclocal found autoheader found autoconf found automake found [Checks passed] Generating... /usr/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE /usr/local/share/aclocal/audiofile.m4:12: run info '(automake)Extending aclocal' /usr/local/share/aclocal/audiofile.m4:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal autoheader-2.62: error: AC_CONFIG_HEADERS not found in configure.in checking build system type... i386-unknown-freebsd7.0 [...] g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"dw-testbed\" -DVERSION=\"0.0.43j\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_UIO_H=1 -I. -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include -O2 -fno-strict-aliasing -pipe -I/usr/local/include -Wno-non-virtual-dtor -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wall -MT libDw_fltk_a-fltkflatview.o -MD -MP -MF .deps/libDw_fltk_a-fltkflatview.Tpo -c -o libDw_fltk_a-fltkflatview.o `test -f 'fltkflatview.cc' || echo './'`fltkflatview.cc In file included from fltkflatview.hh:9, from fltkflatview.cc:23: fltkviewbase.hh:25: error: 'time_t' does not name a type fltkviewbase.hh:26: error: 'time_t' does not name a type *** Error code 1 Stop in /home/chris/Storage/Programming/dillo/dw2-cur/dw. *** Error code 1 Stop in /home/chris/Storage/Programming/dillo/dw2-cur. Christopher

2 3

Linksys NSLU2 ARM XScale success report [FWD: Dillo f15 Compatibility List dillo2]
by corvid＠lavabit.com Aug. 25, 2008

Aug. 25, 2008

Holger Paradies wrote: > Hello > succesfully compiled and running dillo2 > cvs20080825 > -build_triplet = armv5tel-unknown-linux-gnu > on linksys-nslu2 266MHZ 32MB RAM > (native build) > debian-lenny_arm gcc version 4.3.1 (Debian 4.3.1-2) > kernel 2.6.25-2-ixp4xx > > and running via ssh -X > > > also success on Debian-Etch x86 > > Greetings Holger

1 0

Re: Broken links on www-site
by jcid＠dillo.org Aug. 19, 2008

Aug. 19, 2008

On Tue, Aug 19, 2008 at 07:58:06PM +0300, Henri Salo wrote: > On Tue, Aug 19, 2008 at 12:21:56PM -0400, Jorge Arellano Cid wrote: > > Good, if you want to help us, welcome aboard! > > > > Please give a read to the just updated: > > > > http://www.dillo.org/8years.html > > > > and update the wiki. In case of doubt, just ask. > > > > BTW, corvid is about to patch that page along these lines: > > > > Jorge.- > > I have been lurking around in mailing lists for a while if you haven't > already noticed so I have read that link already. It was written this morning! > I have also tested > some patches, but I didn't have anything to say about those. I don't > actually like Wiki{pedia,media} anymore, but I can do exception for > Dillo-project. :-) > For you information there are users who would like test dillo2 using > snapshots from CVS. Should we make proper builds and guides for them? No. I'd prefer them to test the next release. Once it's made, packages are welcomed. -- Cheers Jorge.-

1 0

a list of what dillo2 runs on
by jcid＠dillo.org Aug. 19, 2008

Aug. 19, 2008

On Tue, Aug 19, 2008 at 01:36:34AM +0000, corvid wrote: > All right, I came up with: > > * Dillo is a > <a href='http://www.dillo.org/Compatibility.html'>multi-platform</a> > graphical web browser known for its speed and small size. > * Dillo is written in C and C++. > * Dillo is based on <a href='http://www.fltk.org'>FLTK2</a>, the Fast Light > ToolKit. > * Dillo is free software made available under the terms of the GNU General > Public License. > * Dillo strives to be friendly both to users and developers. > * Dillo helps web authors to comply with web standards by using the > <a href='http://www.dillo.org/help/bug_meter.html'>bug meter</a>. OK. (please state GPL3). BTW, I just wrote and updated the "8 years" page: http://www.dillo.org/8years.html -- Cheers Jorge.-

2 2

towards a consistent UI
by Johannes.Hofmann＠gmx.de Aug. 18, 2008

Aug. 18, 2008

Hi, I really like the way Ctrl-l now just selects the current URL in normal mode avoiding a dialog window. In fullscreen mode however, the short switch to normal mode to enter the new URL requires a complete redraw of the page contents. Also the contents "jumps" down for the time the location bar is shown. This can be distracting. Do we really want to kill all uses of dialog windows? We still have "Search the Web" anyway. Also the location of the "IMG ON/OFF" button seems a bit arbitrary. How could a consistent user interface of dillo look like? Here is my proposal - just to start the discussion: * Everything is accessible via the menubar and via keyboard shortcuts. The shortcuts are shown behind the menu entries. * All shortcuts are configurable. * No more img on/off button. One can use a menubar entry or keyboard shortcut instead. * The "Search the Web" button should be just as all the other buttons ("Back", "Forw" ...) and be configurable of course. Perhaps a single config option like: panel_buttons="back, forw, home, reload, save, stop, book" * The "HTML bugs" button in the status bar is ok. It shows the bug-state of the current page. * "Search the Web" opens the start page of the selected search engine (e.g. google.com) and selects the search text field. I'm not sure about that, but it avoids the dialog window and it makes clear to which search engine the query is sent. The additional page load for the empty search page is only required once - then it's cached. * In fullscreen mode "Ctrl-l" opens a dialog window again. Any better solution? Cheers, Johannes

2 2

Dillo in OSX
by higuita7＠yahoo.co.uk Aug. 15, 2008

Aug. 15, 2008

Hi again Found the problem... had some old fltk includes in /usr/local and was installing the cvs to /usr ... so dillo was mixing both includes and breaking the compile. its fixed now, thanks for the help, specially Johannes :) higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

4 4

Please help me on this...
by jcid＠dillo.org Aug. 14, 2008

Aug. 14, 2008

Hi there, Looking to a future dillo2 release for the public, I was wondering about the main drive behind dillo2. I mean, in this years of Facebook, WebKit, Flash, propietary video codecs, etc. what's the main point behind dillo2? From the objectives: 1.- The democratization of internet information access. 2.- Personal security and privacy. 3.- High software efficiency. The first one is interesting to analyze along the lines that dillo allows to search for tons of information spread through the Internet using low HW requirements and low bandwidth as a dialup. This is reassuring as dillo efectively enables information access to any person under such constraints. The second one is partly attained by not writing to HD and by a non-existent scripting support. The third one is the one to brag about. ;-) Since some time, the thought that enabling dillo2 as a help browser could also bring local information (i.e. in HD) closer to the user came as a powerful one. Having an app. that pops-up in a second and that's quick, responsive and easy to use is certainly a strong drive for a person in search of information (that's why I'd like to see it inside Debian as a help system). In the near future, I'd like to have CSS and proper floating text rendering (DIV element), plus an API as a help browser. There're countries where paying Universitary studies is the state's burden. If a citizen doesn't want to study there, it's a choice. I think the same may happen with dillo, once people know about it, they can choose to use it or not. While thinking about it, these comments surprised me: "Slashdot | What Do You Want On Future Browsers?" http://tech.slashdot.org/article.pl?sid=08/06/30/1845201 (yes, give them a read!) (They're talking from a full featured Firefox basis. I don't know how may of them would like to use something like dillo) Behind a project like ours, there're two communities: developers and users. The main factor to push forward the project is developers and their motivations (in a commercial environment what pushes the development is the money invested and the profit margins/strategy sought). That's why I'm asking you to help me with your views, needs visions on the future of dillo2 these days. With regard to the user community, I'd love to have some feedback from them, but I guess we need to release dillo2 first! :-) -- Cheers Jorge.-

4 4

Dillo in OSX
by Johannes.Hofmann＠gmx.de Aug. 11, 2008

Aug. 11, 2008

-------- Original-Nachricht -------- > Datum: Mon, 11 Aug 2008 03:32:15 +0100 > Von: higuita <higuita(a)GMX.net> > An: "Johannes Hofmann" <Johannes.Hofmann(a)gmx.de> > Betreff: Re: [Dillo-dev] Dillo in OSX > Hi > > On Sun, 10 Aug 2008 11:36:08 +0200, "Johannes Hofmann" > <Johannes.Hofmann(a)gmx.de> wrote: > > Hm, maybe some stale fltk2 header files? > > i clean up the root dw2 folder and done a new cvs up && autogen.sh && > configure ... but still it failled > > > You could try to add -E to the failing g++ call above to check the > > preprocessed sources. > > in a command line, i added the -E and it build successful > (no error)... > if i force success on that g++ command, i can continue and > build dillo successful and dillo seems to work fine > > bad fltk install? broken compiler? > should i totally remove the dillo2 and do a totally new checkout? > > :) > > thanks in advance for the help I suspect it is somehow related to your fltk2 installation. Perhaps you have one from your distribution and a self compiled version at the same time? Johannes -- GMX Kostenlose Spiele: Einfach online spielen und Spa? haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/61691…

1 0

Dillo in OSX
by higuita7＠yahoo.co.uk Aug. 10, 2008

Aug. 10, 2008

Hi On Mon, 4 Aug 2008 18:50:17 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Great, committed. > I works, dillo2 runs native in Leopard > There are several glitches but it's quite a good start. 8-) humm... if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"dw-testbed\" -DVERSION=\"0.0.43j\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_UIO_H=1 -I. -I. -I/usr/local/include -I/usr/include/freetype2 -Wno-non-virtual-dtor -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wall -MT libDw_fltk_a-fltkmisc.o -MD -MP -MF ".deps/libDw_fltk_a-fltkmisc.Tpo" -c -o libDw_fltk_a-fltkmisc.o `test -f 'fltkmisc.cc' || echo './'`fltkmisc.cc; \ then mv -f ".deps/libDw_fltk_a-fltkmisc.Tpo" ".deps/libDw_fltk_a-fltkmisc.Po"; else rm -f ".deps/libDw_fltk_a-fltkmisc.Tpo"; exit 1; fi fltkmisc.cc: In function 'void dw::fltk::misc::warpPointer(int, int)': fltkmisc.cc:45: error: 'warp_mouse' is not a member of 'fltk' make[1]: *** [libDw_fltk_a-fltkmisc.o] Error 1 make[1]: Leaving directory `/home/higuita/build/dillo2/dw2/dw' make: *** [all-recursive] Error 1 i'm using the latest svn from fltk and from dillo... i'm using slamd64 (slackware 64bits) thanks higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

1 0

Re: patch: form controls outside of forms
by jcid＠dillo.org Aug. 6, 2008

Aug. 6, 2008

On Sun, Jul 20, 2008 at 07:38:56PM +0000, corvid wrote: > *remind* *remind* In absence of comment, I decided to commit it. -- Cheers Jorge.-

1 0

Dillo in OSX
by jcid＠dillo.org Aug. 5, 2008

Aug. 5, 2008

Hi Johannes, When trying to compile dillo2 in OSX, FLTK2 compiles OK, dw's fltkviewbase.hh needs an time.h include and I get this error: isc.Tpo -c -o libDw_fltk_a-fltkmisc.o `test -f 'fltkmisc.cc' || echo './'`fltkmisc.cc fltkmisc.cc: In function 'int dw::fltk::misc::screenWidth()': fltkmisc.cc:34: error: 'xdisplay' is not a member of 'fltk' fltkmisc.cc:34: error: 'xscreen' is not a member of 'fltk' fltkmisc.cc:34: error: 'DisplayWidth' was not declared in this scope fltkmisc.cc: In function 'int dw::fltk::misc::screenHeight()': fltkmisc.cc:39: error: 'xdisplay' is not a member of 'fltk' fltkmisc.cc:39: error: 'xscreen' is not a member of 'fltk' fltkmisc.cc:39: error: 'DisplayHeight' was not declared in this scope fltkmisc.cc: In function 'void dw::fltk::misc::warpPointer(int, int)': fltkmisc.cc:44: error: 'xdisplay' is not a member of 'fltk' fltkmisc.cc:44: error: 'None' was not declared in this scope fltkmisc.cc:45: error: 'xdisplay' is not a member of 'fltk' fltkmisc.cc:45: error: 'xscreen' is not a member of 'fltk' fltkmisc.cc:45: error: 'RootWindow' was not declared in this scope fltkmisc.cc:46: error: 'XWarpPointer' was not declared in this scope make[1]: *** [libDw_fltk_a-fltkmisc.o] Error 1 make: *** [all-recursive] Error 1 Do you know the proper solution for this? -- Cheers Jorge.-

2 2

[patch] Another selection redraw fix
by Johannes.Hofmann＠gmx.de July 30, 2008

July 30, 2008

Hi, attached is another selection redraw related fix. Again, when selecting text a too large area was redrawn. Cheers, Johannes PS: This is a resend. The original mail probabely got lost.

2 1

[corvid@lavabit.com: Re: patch: form controls outside of forms]
by jcid＠dillo.org July 30, 2008

July 30, 2008

Hi, After the WearLab outage (web site, email, ssh, cvs, mailing list, smoke signals...), let's try to resume from where we were. Jeremy: please review the "form controls outside of forms" patch (to commit afterwards). Michal wrote: > Some nice fable, had to do something regarding this :). Which one?! *please* 8-) Evrerybody: Does anybody know what happened with the WearLab? -- Cheers Jorge.-

2 1

[patch] reduce redraw overhead when selecting text
by Johannes.Hofmann＠gmx.de July 30, 2008

July 30, 2008

Hi, here is a small bugfix that reduces the area that gets redrawn when selecting text. The improvement is mostly noticable when running dillo in a remote X11 session. Cheers, Johannes

2 1