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

Future of dillo2
by jcid＠dillo.org May 13, 2008

May 13, 2008

Hi there, This question: > What do you think of reviving use of the bug tracker > for the various little things that are easy to forget about? brings about a bigger topic: the future of dillo2. The goals of the project are: 1.- The democratization of internet information access 2.- Personal security and privacy 3.- High software efficiency I believe the key to achieving them are: a.- A larger development team. b.- A user community finding it useful. The vitality and development pace of the project are highly related to a). Point b), has been strong in the past; this is: judging from the received email feedback: http://www.dillo.org/emails.txt and from some surveys like: > On Sat, Aug 25, 2007 at 03:28:55AM +0200, Diego . wrote: > > DesktopLinux.com has published the results of its anual (desktop)linux poll > > The interesting thing is in the 3rd question: Which web browsers do you > > frequently use on your Linux desktop(s)? > > > > > http://www.desktoplinux.com/cgi-bin/survey/survey.cgi?view=archive&id=08132… > > > > The interesting thing is that a frozen project have enough users to win > > over 3 fully developed browsers :) (optimistic without cure) Point a) is key because it directly relates to the pace with which we pursue the moving target of Web browsing. Point b) is very important because if we end up with a browser that only a few people are willing to use, there's no point in it besides personal motivations. So: * Objective 1, is the result of a) and b). * Objective 2, needs the work of a). * Objective 3, is mainly achieved! How do we do it? i. - Increase the development team by adding 6+ new developers. ii.- Getting more involved with other projects. We could: * Attract new developers with a dillo2 release, leveraging the excellent documentation that we have. * Planning for CSS, floating objects and TABS. (this are important features to a nice browsing experience) * Coordinate with FLTK2, DSL (Damn small linux) and other lightweight distros, Debian installer team, MINIX3, etc. I don't want to miss the opportunity to thank the team for the excellent work during these months. Without you dillo2 wouldn't be so close to a release. Now, we need to plan, grow the number of developers, and bring dillo2 closer to its goals. These are just my views on the subject. Please share your thoughts, ideas and plans in this thread, so we can agree on a plan for the future. -- Cheers Jorge.-

8 22

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'
by onepoint＠starurchin.org May 11, 2008

May 11, 2008

If you navigate to a page with a '<meta http-equiv="Content-Type" ...' in the head element then any anchor in the URL is ignored. (This breaks my local cinema's web page because it puts listings and film descriptions on the same page and links them with anchors.) I think the reason is that the meta element forces the page to be reloaded by Nav_push() and this does not call a_Nav_expect_done(). Unfortunately a_Nav_expect_done() is responsible for calling a_UIcmd_set_scroll_by_fragment(), so any page pulled in by Nav_push() does not scroll to the anchor. Any ideas how to fix this? I having a hard time getting my head around this bit of the code. Regards, Jeremy Henty

4 16

dillo-fltk on x86_64
by 4winter＠informatik.uni-hamburg.de May 2, 2008

May 2, 2008

-----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. 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. 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). 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? 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 iD8DBQFID6/ToPmwNWhsaZYRApgwAJsENlC0vsniya14RBTU8yrXVVjVyACff2HD GLM/iKxXf3UjBA6+GFOSE78= =JuDE -----END PGP SIGNATURE-----

5 19

[patch]: FtlkListResource select callbacks
by onepoint＠starurchin.org May 1, 2008

May 1, 2008

This is a first cut at making FltkListResource work properly. The resource maintains a hash of its items' selected status, the MultiBrowser widget gets a callback that updates the hash and isSelected() looks up the hash for the answer. It's the same technique I used for FltkOptionMenuResource , where the FLTK widgets are linked to their resources by user_data() and callback arguments. I added equals() and hashValue() methods to Items so they could be hash keys, and implemented an object::Object wrapper class for boolean values to be the hash values. The wrapper class is inside FltkListResource , though it could easily move to lout::object IMHO. The patch also enables the ListResource widget in test/dw-ui-test . Unfortunately it's still a little buggy. Specifying multiple selected items initially doesn't work right: they are all selected in the resource but only one is selected on the FLTK widget. Things also go out of sync when you select a group item: any previously selected item is unselected in the widget but not in the resource. I'll look into these further. Comments are welcome! Regards, Jeremy Henty

2 2

[patch] ignore SIGPIPE
by Johannes.Hofmann＠gmx.de April 30, 2008

April 30, 2008

Hello, this patch avoids exits on SIGPIPE. Currently this is only observed on DragonFly, but dillo1 had this too. Cheers, Johannes

2 1

[patch] cleanup iterator fix
by Johannes.Hofmann＠gmx.de April 30, 2008

April 30, 2008

Hi, now I noticed, that there is a more elegant way to create an iterator that is winded forward until its end. This restores symmetry between DeepIterator::next() and DeepIterator::prev(). Cheers, Johannes

2 1

[patch] two more tiny memory leaks
by Johannes.Hofmann＠gmx.de April 30, 2008

April 30, 2008

Hi, two more small leaks in dw2 found by valgrind. Cheers, Johannes

2 1

start on image maps (dw-part)
by Johannes.Hofmann＠gmx.de April 30, 2008

April 30, 2008

Hi, just to let you know, I just started with client side image maps (the dw-part). Below is an initial implementation of ImageMapsList. This is not yet ready at all, but perhaps someone might want have a look. Cheers, Johannes diff -r 877bbc03146b -r ebc6de688732 dw/image.cc --- a/dw/image.cc Thu Apr 17 22:14:42 2008 +0200 +++ b/dw/image.cc Mon Apr 21 21:03:51 2008 +0200 @@ -25,12 +25,44 @@ namespace dw { +ImageMapsList::ImageMap::ImageMap () +{ + shapesAndLinks = new container::typed::List <ShapeAndLink> (true); +} + +void ImageMapsList::ImageMap::add (core::Shape *shape, int link) { + ShapeAndLink *shapeAndLink = new ShapeAndLink (); + shapeAndLink->shape = shape; + shapeAndLink->link = link; + shapesAndLinks->append (shapeAndLink); +} + +int ImageMapsList::ImageMap::link (int x, int y) { + container::typed::Iterator <ShapeAndLink> it; + int link = -1; + + for (it = shapesAndLinks->iterator (); it.hasNext (); ) { + ShapeAndLink *shapeAndLink = it.getNext (); + + if (shapeAndLink->shape->isPointWithin (x, y)) { + link = shapeAndLink->link; + break; + } + } + + return link; +} + ImageMapsList::ImageMapsList () { + imageMaps = new container::typed::HashTable <object::Object, ImageMap> + (true, true); + currentMap = NULL; } ImageMapsList::~ImageMapsList () { + delete imageMaps; } /** @@ -42,6 +74,8 @@ ImageMapsList::~ImageMapsList () */ void ImageMapsList::startNewMap (object::Object *key) { + currentMap = new ImageMap (); + imageMaps->put (key, currentMap); } /** @@ -52,6 +86,7 @@ void ImageMapsList::startNewMap (object: */ void ImageMapsList::addShapeToCurrentMap (core::Shape *shape, int link) { + currentMap->add (shape, link); } // ---------------------------------------------------------------------- diff -r 877bbc03146b -r ebc6de688732 dw/image.hh --- a/dw/image.hh Thu Apr 17 22:14:42 2008 +0200 +++ b/dw/image.hh Mon Apr 21 21:03:51 2008 +0200 @@ -22,6 +22,27 @@ namespace dw { */ class ImageMapsList { +private: + class ImageMap: public object::Object { + private: + class ShapeAndLink: public object::Object { + public: + core::Shape *shape; + int link; + }; + + container::typed::List <ShapeAndLink> *shapesAndLinks; + public: + ImageMap (); + ~ImageMap (); + + void add (core::Shape *shape, int link); + int link (int x, int y); + }; + + container::typed::HashTable <object::Object, ImageMap> *imageMaps; + ImageMap *currentMap; + public: ImageMapsList (); ~ImageMapsList ();

3 20

patch: motionNotify and LEAVE
by corvid＠lavabit.com April 30, 2008

April 30, 2008

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.

2 3

[PATCH]: call widget->layout_damage() from FltkWidgetView::allocateFltkWidget
by onepoint＠starurchin.org April 30, 2008

April 30, 2008

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

2 3