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

ListResources: version 3
by onepoint＠starurchin.org 06 May '08

06 May '08

I am attaching two patches that get ListResource selection working properly, ie. you can click items as you wish and FltkListResource::isSelected() will now return the correct value. The first patch is my previous selection patch, unchanged. The second is a small fix that I proposed in the lout::misc::StringBuffer fix thread: it makes FltkListResource::addItem call Widget::set_selected() on fltk::Item widgets, and the call to Menu::set_item() becomes conditional on a virtual boolean hook that defaults to false, but is redefined to true in FltkOptionMenuResource() . The second patch looks bigger than it really is: most of it is just reindenting a block of code that moved inside an "if" statement. (And diff doesn't help by insisting on choosing an unnecessarily complicated set of changes.) It's not a pretty hack, but it's simple and I am wary of making deeper changes until I understand the code better. Please comment, Jeremy Henty

4 5

Q: should we select option groups
by onepoint＠starurchin.org 06 May '08

06 May '08

FLTK allows both Choice and MultiBrowsers to select group items as well as normal leaf items. The Dillo Selection widget currently ignores selected group items, which could be confusing if a user selects a group and expects the application to do something about it. On the other hand the HTML 4 spec[1] reads as though only options and not option groups can be selected, though it does not say so explicitly. What should Dillo do about this? [1] http://www.htmlhelp.com/reference/html40/forms/select.html

1 0

patch: dialog.cc window deletion
by corvid＠lavabit.com 06 May '08

06 May '08

Using the crude tool of top(1), I learned that viewing the source of a 500K file meant losing 500K down the drain. - If I give the text to the TextDisplay's initial buffer, it knows that it owns it. - Window::destroy() doesn't delete. The header comment in fltk/src/Window.cxx says it's some sort of 'hide' function: "Hides the window and also deletes all window system information about the window, and thus returns it back to the state it was in before the first show(). It is harmless to call this if the window is already destroyed." - And while I was in there, I threw in some callback(window_close_cb, ...)s for closing windows using the window mgr instead of a button.

2 1

[patch]: FltkListResource::sizeRequest()
by onepoint＠starurchin.org 05 May '08

05 May '08

Currently FltkListResource::sizeRequest() is a stub with some hardwired values that are not very useful. This patch replaces it with something more appropriate (closely following the existing implementation of FltkOptionMenuResource::sizeRequest() ). Comments are welcome, Jeremy Henty

1 0

[BUG]: html.cc: broken Dlist iteration
by onepoint＠starurchin.org 05 May '08

05 May '08

Html_build_query_data() and Html_make_multipart_boundary() iterate over a Dlist while destructively modifying it *and* recalculating the list length each time, so the iteration terminates prematurely. This makes Html_build_query_data() mangle the result when an input returns multiple values: half of the values get attached to the next input! This patch fixes the problem by caching the length of the list before modifying it so that the entire list is processed. Regards, Jeremy Henty

2 1

[patch]: select multiple
by onepoint＠starurchin.org 05 May '08

05 May '08

This patch implements the MULTIPLE attribute for SELECT elements. It's small but it depends on the various patches and bugfixes I have already posted. Please comment. Regards, Jeremy Henty

1 0

[BUG]: lout::misc::StringBuffer::clear() does not invalidate the string
by onepoint＠starurchin.org 03 May '08

03 May '08

Well, *that* was a bit of a wild goose chase! Remember I complained of selection problems in ListResources? It was nothing of the kind. Instead test/dw-ui-test was spuriously reporting that things were still selected when everything was in fact unselected. And the cause was a bug in lout::misc::Stringbuffer ! lout::misc::StringBuffer::clear() omits to invalidate the internal cached string, so if you call lout::misc::StringBuffer::getChars() (which updates the cached string and marks it as valid), then lout::misc::StringBuffer::clear() and then *immediately* call lout::misc::StringBuffer::getChars() again, you get the contents of the StringBuffer before you cleared it (because the cached value has not been invalidated), instead of the empty string. D'oh! One-liner patch attached. Regards, Jeremy Henty

3 4

dillo-fltk on x86_64
by 4winter＠informatik.uni-hamburg.de 02 May '08

02 May '08

-----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]: take 2: FtlkListResource
by onepoint＠starurchin.org 01 May '08

01 May '08

Since Johannes' criticisms were (IIRC) mostly about my patch's complexity I hope he will look at a new patch that sticks to my original approach but is a lot simpler. I realised that if the user_data() of the Menu Widget items stored the index of the Item instead of the Item itself then FltkListResource could store the selections by index in a misc::SimpleVector<bool>. This means there is no need to wrap bools in object::Object pointers and no need to add instance methods to Items to make them Hashable. Most of the scaffolding of the previous patch just disappears (the line count decreases by a third). I don't want to dismiss Johannes' alternative suggestion out of hand, but I still think my approach has a lot going for it and I'd like people to have a chance to criticise my best shot at it. Comments are welcome! Jeremy Henty

2 1

[patch]: FtlkListResource select callbacks
by onepoint＠starurchin.org 01 May '08

01 May '08

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