- Dillo-dev - lists.mailman3.com

[patch]: html.cc: DilloHtmlInput::connectTo()
by onepoint＠starurchin.org May 30, 2008

May 30, 2008

This implements DilloHtmlInput::connectTo() which is called by DilloHtmlForm::addInput and connects the input to the form. This is another API milestone: now only DilloHtmlForm methods access DilloHtmlForm::form_receiver . We are nearly done with the DilloHtmlForm API, there only a few locations left that directly access DilloHtmlForm data members. Regards,

2 2

[patch]: html.cc: remove DilloHtmlInput::widget
by onepoint＠starurchin.org May 30, 2008

May 30, 2008

It turns out that the embed and widget members of the DilloHtmlInput class are always the same, so we can remove widget. Patch attached. Regards, Jeremy Henty

2 1

[patch]: html.cc: DilloHtmlForm::getRadioInput()
by onepoint＠starurchin.org May 30, 2008

May 30, 2008

This refactors code that looks for a radio input with a given name into a new method DilloHtmlForm::getRadioInput() . This marks a DilloHtmlForm API milestone: now only DilloHtmlForm member functions access the inputs data member. Everything else that needs to get an input from a form goes through the API. Regards, Jeremy Henty

2 1

[patch]: html.cc: remove MSG_HTML and rename Html_msg() to DilloHtml::message()
by onepoint＠starurchin.org May 30, 2008

May 30, 2008

Self-explanatory, I hope. This is a useful bit of yak-shaving to prepare for more refactoring of form handling code. The reasons for removing MSG_HTML are: * It doesn't belong in msg.h since it can only work when used in http.cc . * It's a UI function not a debugging function like the other MSG_* so it's misleading for it to look similar to the MSG_* macros. * Using it has no advantage over simply calling the function that it wraps. * It's fragile because it requires html to be in scope and have the right value. Regards, Jeremy Henty

2 1

Re: patch: cache Data allocation
by jcid＠dillo.org May 29, 2008

May 29, 2008

On Thu, May 29, 2008 at 05:51:02PM +0000, corvid wrote: > This is to make my unref()s cleaner. > As it was in the prototype code, I would always unref at IOClose time. > This made the reference count negative for file not found, which I didn't > like. I could've tested for GotHeader, but it seemed more natural to > test for data before unref()ing data. I'd prefer GotHeader because that's what Cache_process_queue() tests for, and thus Data doesn't become an implicit flag. > I think it's all right for me to put that Cache_process_queue(entry) inside > an entry->Data test -- at least I couldn't find anything bad happening. BTW, funny as it may seem, I don't yet know what data unref you're talking about! :-) -- Cheers Jorge.-

2 1

[patch]: simplify a_Html_form_event_handler()
by onepoint＠starurchin.org May 29, 2008

May 29, 2008

The a_Html_form_event_handler() function displays an amusing anti-pattern (which I wish I knew the name of) where it's not given enough data and has to go searching for the missing information. Specifically, it gets a pointer to the DilloHtml of the page, but not not the DilloHtmlForm that submitted it, so it has to search the form list of the DilloHtml to find the form. This patch passes the DilloHtmlForm to the handler and adds a pointer from the DilloHtmlForm to the DilloHtml , so the handler can now directly access the form and the html without messing around. Regards, Jeremy Henty

2 3

[patch]: convert Html_submit_form2() to DilloHtmlForm::buildQueryUrl()
by onepoint＠starurchin.org May 29, 2008

May 29, 2008

The function Html_submit_form2() does two jobs rolled into one: most of its code creates a url from a DilloHtmlForm and a few lines push the url to a DilloHtml . This patch takes advantage of the fact that Html_submit_form2() is only called from a_Html_form_event_handler() ; it moves the url push out into the caller and the rest of the code into a new method "DilloUrl *DilloHtmlForm::buildQueryUrl()". This separates concerns nicely: the DilloHtmlForm creates the url and a_Html_form_event_handler() pushes it to the DilloHtml . We're getting close to having a proper API for DilloHtmlForm , unfortunately some of the remaining code is very messy. I'll do the rest of the easy stuff and then summarise what's left. Regards, Jeremy Henty

2 1

Previous patches a la camelCase
by onepoint＠starurchin.org May 29, 2008

May 29, 2008

In case Jorge prefers them, here are revised versions of today's patches with camelCased method names. Regards, Jeremy Henty

2 1

[patch]: html.cc: change Html_add_input() to HtmlForm::add_input()
by onepoint＠starurchin.org May 29, 2008

May 29, 2008

This changes the Html_add_input() function to an HtmlForm::add_input() method. As before I'm submitting this as a "change diff" + "move diff" to make it easier to review. Reviewers please tell me if it makes things harder instead! Regards, Jeremy Henty

2 1

[patch]: html.cc: change Html_make_multipart_boundary() to DilloHtmlForm::make_multipart_boundary()
by onepoint＠starurchin.org May 28, 2008

May 28, 2008

More of the same. I'll hold off sending any more patches until these three have been reviewed. (Especially since I just remembered Jorge will probably want to camelCase the method names. D'oh!) Regards, Jeremy Henty

1 0

[patch]: html.cc: rename Html_build_query_data() to DilloHtmlForm::build_query_data()
by onepoint＠starurchin.org May 28, 2008

May 28, 2008

Does what it says on the tin! There's no "move diff" for this one due to declaration order dependencies. I expect the move will happen after the functions that access DilloHtmlInput internals are converted to DilloHtmlInput methods. Regards, Jeremy Henty

1 0

html.cc: convert Html_*_reset functions to methods
by onepoint＠starurchin.org May 28, 2008

May 28, 2008

This changes Html_reset_form() to DilloHtmlForm::reset() and Html_reset_input() to DilloHtmlInput::reset() . It's part of the plan to move code that accesses DilloHtmlForm and DilloHtmlInput internals into methods and make the internals private. The patch is in two parts: the first makes the changes and the second moves the new methods to the right place in the file. If I roll the changes and the move into one then "diff" gets confused and creates an unreadable monster of a patch. I'd recommend feeding the two attachments to patch separately; it might do the right thing given the whole message in one go, but then again it might not. Comments are welcome. There are several other functions in html.cc that are really just methods in disguise and are future targets for the same treatment as Html_reset_form() and Html_reset_input() get here. Regards, Jeremy Henty

2 2

html.cc: small tweak for consistency and debugging
by onepoint＠starurchin.org May 27, 2008

May 27, 2008

This renames a local variable from "size" to "nf". This is consistent with the names of similar local variables elsewhere in the file and also ensures that the _MSG statement will compile if debugging is enabled. Jeremy Henty

1 0

Re: (working) prototype of charset decoding in cache.c
by jcid＠dillo.org May 27, 2008

May 27, 2008

Hi, On Fri, May 02, 2008 at 08:02:14PM +0000, corvid wrote: > I've been playing around with this now and then over the past few months > when I haven't had anything else going on. I've been running on it for > a day or so without incident, but I haven't gone through it with a > fine-toothed comb because I know there will be changes. > > It's 35K, so I realize I'm in little danger of hearing back too quickly :) > Besides, I know you said you have some nbsp thing that needs attention... I've made a second review over the code, and it doesn't look that bad to me. This is, the decoding in cache, even the stuffed cache-entry; if it can be isolated/tidied in the future better. The part that looks inconvenient to me is the charset choosing dialog. I'd prefer Dillo do this automatically. There's no need to try to recognize every charset in the world, but just a few "most used" ones like koi8-r. BTW, UTF-8 has become the preferred solution. The idea is that we can leave space for a expandable function just in case. BTW, there's an improved version of the data guesser in the ftp dpi. Please send me a koi8-r encoded page to test (or just let me know how to find it with google :). IIRC you sent me an explanation message on what this patch was for and remaining issues. I can't find it :(. Please resend it to me. > > There are plenty of issues. Going in order through the diff: > > - *_get_content_type(). I searched for some Russian text files where a > charset is given in the HTTP header. None of them were regarded as > text by the old test for ascii chars. > Maybe the way to go is to have tests for more filetypes and treat > unknown as text. Checking for all possible charsets would be no fun, > anyway. (Tests for more filetypes might be needed for file uploading, > as well.) The problem with "unknown as text" is that some HTTP servers send downloadable files as text. It is quite practical in this case to get a download dialog from dillo, intead of a binary rendering (especially for newbies). That's why the current data guesser is conservative. The data guesser can be improved. e.g. taking ASCCI control characters as a strong indication of a binary, and their absence as a text hint. I can give it a look after you send me the files. > - CacheEntry_t now has a horrifying amount of junk in it. Maybe it > would be good to pull out about half of it into some sort of Data thing. It's stuffed but still understandable. If it can be tidied in a second pass, better. > o TypeSet to be set from Meta or a user dialog. Meta can set it once; > the dialog can set it repeatedly. I'd like to avoid that dialog if possible. > o UTF8Data (LocalData?) that's been translated. cache.c has a lot of > "entry->UTF8Data ? entry->UTF8Data : entry->Data" in it now that > perhaps should be hidden behind something. Yes. > o DataReaders reference count. UTF8Data is destroyed when not needed. > o CharsetDecoder > > - a_Cache_unref_buf, a_Capi_unref_buf, a_Nav_unref_buf all just to > provide notification that the view source window isn't reading it anymore. > Ugh. Not pretty, but tolerable. I'm thinking along the line of getting the core of the patch committed and then polish the rough edges. > - a_Cache_[gs]et_content_type and capi and nav. Ugh again. > I don't know whether there's a timing issue with changing decoders > due to a meta tag at the same time that a view source window is being > opened. Yes there is. Simple to solve by allowing view source after parsing the HEAD element only. > (Why content-type and not charset? I find switching to text/plain to > use findtext on the source to be useful.) Sorry, I don't understand the question. > - Decode_charset() no longer free()s its input. This inconsistency would > be an excellent source of bugs, so it would probably be good to make it so > that none of the decoders free input. Yes, this is a must. Consistency should be our goal/horizon/friend/helper. :-) -- Cheers Jorge.-

2 6

[patch]: html.cc: DilloHtmlForm::getCurrentInput()
by onepoint＠starurchin.org May 27, 2008

May 27, 2008

This refactors DilloHtmlForm code into a new "inline DilloHtmlInput *getCurrentInput()" method. It's just like the earlier patch that created DilloHtml::getCurrentForm() . Comments are welcome, although I hope it is uncontroversial. Regards, Jeremy Henty

2 4

an experiment in widget coloring
by corvid＠lavabit.com May 27, 2008

May 27, 2008

I saw a page that reminded me that the matter of when to have light text vs. dark text on widgets was not decided. earlier discussion: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-February/003760.html trimmed-down bit of the page I saw: <form> <table bgcolor="#F8C473"> <tr><td> <input type="submit" value="I can hardly see the text"> </table> </form>

1 0

[patch]: html.cc cleanup: DilloHtml::currentForm()
by onepoint＠starurchin.org May 26, 2008

May 26, 2008

This patch adds a DilloHtml::currentForm() method and uses it to refactor wherever possible. This reduces the number of instances of the "foo->size() - 1" idiom in html.cc from 23 to 13! Regards, Jeremy Henty

3 8

[patch] dw2 memory reduction
by Johannes.Hofmann＠gmx.de May 26, 2008

May 26, 2008

Hi, attached is patch to reduce the memory usage of dw2: * Styles are now reused if they are equal. This brings down the number of Style objects on the mysql page from around 180000 to 23000 and reduces memory usage by about 25M at the cost of an additional HashTable. Maybe the hash table should be part of fltkplatform as the hash tables for Color and Font? There would be even more sharing of styles possible, if x_link would not be part of style. On the other hand about 3M for styles on the huge mysql page is pretty ok. * Size of struct Word is reduced by 4 integers by using shorts. I know that this is questionable, but I think in the case of struct Word that can be allocated a lot it is worth the hassle. Please check whether my assumption that space lengths and word lengths can be stored in shorts are valid in general. * SimpleVector no longer preallocates memory if it's not necessary. This actually saves some megabytes here! With these changes memory usage on the mysql page is 179M here. Cheers, Johannes

3 8

Fuzzing dillo
by 4winter＠informatik.uni-hamburg.de May 26, 2008

May 26, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi :) I was playing around with Michal Zalewskis html fuzzer 'mangle' trying to crash dillo and succeeded :). Furthermore I was able to reduce the ~100k page that was triggering a NULL pointer dereferencing to three tags (see the attached page). Some digging around (html.cc is a monster ^^) revealed that style_attrs.setBorderColor ( Color::createShaded(HT2LT(html), style_attrs.backgroundColor->getColor())); in Html_tag_open_table was failing due to the fact that style_attrs.backgroundColor was NULL. Html_tag_open_select sets the backgroundColor to NULL and this is inherited by the table tag since it's a child of the select tag. Greping through the code shows that there are at least two other functions that set backgroundColor (and color) to NULL (Html_tag_open_input and Html_tag_open_isindex) and twelve locations calling getColor() on either color or backgroundColor. I have no idea how to _properly_ fix this issue. Furthermore I'd suggest to break down html.cc into several files. It is about 6000 lines long (-> hard to dig into) and it takes gcc roughly five seconds to compile on my box. 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 iD8DBQFIOUmmoPmwNWhsaZYRAprIAJ9X9HSzc4Isx+NyFWxlfSFPrwj/VACdF8GD x67scPvD6FCrOezl69NbaHA= =z0iv -----END PGP SIGNATURE-----

4 10

patch: http_proxyuser preference
by corvid＠lavabit.com May 26, 2008

May 26, 2008

After I sent the preferences mail yesterday, I found that I overlooked one. The headers look good, but I have no way to test it for real.

2 1

patch: goodbye to use_oblique and transient_dialogs
by corvid＠lavabit.com May 26, 2008

May 26, 2008

It's nice to get to delete things, and especially preferences, since they have a natural tendency to grow and grow and grow.

2 1

remaining preferences
by corvid＠lavabit.com May 26, 2008

May 26, 2008

# Dicache is where the Decompressed Images are cached (not the original ones). # If you have a lot of memory and a slow CPU, use YES, otherwise use NO use_dicache The code always behaves like use_dicache=NO /* * Unrefs the counter of a dicache entry, and _if_ no DwImage is acessing * this buffer, then we call Dicache_free to do the dirty job. */ void a_Dicache_unref(const DilloUrl *Url, int version) { DICacheEntry *entry; if ((entry = Dicache_get_entry_version(Url, version))) { /*if (--entry->RefCount == 0 && (entry->next || !prefs.use_dicache)) {*/ if (--entry->RefCount == 0) { Dicache_remove(Url, version); } } } Perhaps this was done for a reason. # If you prefer oblique over italic fonts, uncoment next line use_oblique FLTK doesn't know about oblique. I don't know whether anybody cares enough to change that. I don't. # Show tooltip popup for images? # Note: We use the "title" attribute and not "alt". # More info at: http://bugzilla.mozilla.org/show_bug.cgi?id=25537 show_tooltip I did the easy part of tooltips long ago, but I haven't been able to care enough to want to do the fltk part. # Set this to YES, if you want to limit the word wrap width to the vieport # width (may be useful for iPAQ) limit_text_width It doesn't do anything. I don't think it's ever done anything. It sure would be nice if it did something. But I don't have the expertise to change that. # Here you can choose to hide some widgets of the dillo panel... show_menubar Not currently used. Meaningless with the current panel-cycling with right click on the search button (which I imagine is not going to be the permanent way to do that). # Enabling this will restrain OpenUrl and FindText, but may be required # for the ION window manager. transient_dialogs from fltk::Window::child_of(): Tell the system that this window will not have an icon, it will dissappear and reappear when \a parent is iconized or shown, and it is forced to always be above \a parent. On X this is called a "Transient window", and Windows calls this a "overlapping child". \a parent is different than the parent(), which must be zero. (and down in fltk::CreatedWindow::create, there's a if (window->child_of() && window->child_of()->shown()) XSetTransientForHint(xdisplay, x->xid, window->child_of()->i->xid);) If Justus gets rid of the dialogs, obviously the pref can be removed. Enabling this means making our own dialogs for message(), choice(), input(). # When filling forms, our default behaviour is to submit on enterpress, # but only when there's a single text entry (to avoid incomplete submits). # OTOH, if you have to fill the same form lots of times, you may find # useful to keep away from the mouse by forcing enter to submit. enterpress_forces_submit The code currently always submits on enter. I like it that way and didn't realize that it wasn't supposed to.

3 7

[BUG]: Redirect to previous page + Reload crashes
by onepoint＠starurchin.org May 25, 2008

May 25, 2008

Dillo crashes as follows: * Point Dillo at http://starurchin.org:8080/dillo/here * Click the "There" link. Dillo is redirected back to the "Here" page. * Click the "Reload" button. * Dillo crashes inside a_Nav_reload() (nav.c) at the line "if (URL_FLAGS(url) & URL_Post) {" because url is NULL. I noticed this a few weeks ago but only just found a simple way to trigger it. Any ideas why this is happening? Regards, Jeremy Henty

3 6

Q: why does Nav_stack_clean() free the data and Nav_stack_truncate() not?
by onepoint＠starurchin.org May 25, 2008

May 25, 2008

While reviewing nav.c to figure out the reload crash bug I noticed something that seems inconsistent: both Nav_stack_truncate() and Nav_stack_clean() remove items from the navigation stack, yet Nav_stack_truncate() does not free the data it removes and Nav_stack_clean() does. Is this a bug? If not, what haven't I understood? Regards, Jeremy Henty

2 3

Profiling works!
by onepoint＠starurchin.org May 24, 2008

May 24, 2008

I added -pg to LDFLAGS, CFLAGS and CXXFLAGS and dillo generated a nice gmon.prof ! However, it puts it in /tmp (perhaps that's why it didn't seem to be working). Dillo also dumps its core to /tmp when it crashes, perhaps for the same reason? Regards, Jeremy Henty

2 2

patch: trim Local_Buf
by corvid＠lavabit.com May 24, 2008

May 24, 2008

3 2

Uncluttering dillo, part II: the findbar
by 4winter＠informatik.uni-hamburg.de May 24, 2008

May 24, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey everyone :) attached is a patch that transforms dillos find in page dialog box into a firefox style toolbar. There are some issues that I cannot put my finger on... see the comments in the event handler. Maybe there's some magic about fltks event model that I did not fully understand... then again it might be fltks fault. Anyway, I'd be happy for some hints. Jorge, could you update your coding conventions with respect to c++ specific language features? 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 iD8DBQFIM0pmoPmwNWhsaZYRAi1VAJwO/e+JWmCoMsjOF/hYuF4X1DUOWwCePB96 +X++Veu0Gyv854m0TxSwI7Q= =rc5Z -----END PGP SIGNATURE-----

4 9

memory statistics
by Johannes.Hofmann＠gmx.de May 23, 2008

May 23, 2008

Hi, to see which part of dillo consumes which amount of memory, I hacked together a version of dlib.c that counts memory that was allocated via dMalloc(). A malloc_tag allows to assign the mallocs to specific parts in the code. In the patch below I use malloc_tag = 1 for cache stuff, malloc_tag = 2 for text strings that are passed dw2 and malloc_tag = 0 for everything else. It's fun to see how memory get's allocated and free'd while loading. Here is the output once the huge mysql manual page is loaded: ====> malloc size 5185114 26967623 6602392 0 So that's 6M for text strings, 26M cache and 5M other. Of course there is also all the dw2 stuff that is not taken into account here. BTW, textblock delete's the text strings that are allocated using malloc(). That's not allowed and might cause unexpected behaviour on some platforms. Cheers, Johannes

3 10

patch: free parse data
by corvid＠lavabit.com May 23, 2008

May 23, 2008

Johannes had suggested freeing Local_Buf when parsing was completed...

2 1

RFC: human interface guidelines
by 4winter＠informatik.uni-hamburg.de May 21, 2008

May 21, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey everyone :) I was thinking about improving the dillo experience by adding some functionality / shortcuts people have come to expect. But what people expect is influenced by their background, their choice of desktop environment and platform. We could pick one / some user interface guideline(s) ([1] lists some) and try to adhere to it / them. Or we could pick one popular browser and copy its 'feel'. Attached are two patches mapping 'reload' to F5 and 'help' to F1. Let me know what you think of them and the whole interface thing. Justus 1: http://en.wikipedia.org/wiki/Human_Interface_Guidelines - -- 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 iD8DBQFIM0jvoPmwNWhsaZYRAveJAJ9ROk+E0VWLzK6G99qcTlpNjeB5igCeJ7r9 Grz4wtWQ+BIEbWrIY8PDCFg= =JnX2 -----END PGP SIGNATURE-----

2 1

[patch] minor memory reduction
by Johannes.Hofmann＠gmx.de May 21, 2008

May 21, 2008

Hi, attached is a small patch to improve memory usage. It creates a single word for a sequence of spaces in PRE mode instead of one word per character. The second part is just a minor simplification. Cheers, Johannes

2 4

Uncluttering dillos UI - getting rid of the dialog boxes
by 4winter＠informatik.uni-hamburg.de May 21, 2008

May 21, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey everyone :) somewhere deep inside the "Future of Dillo" monster thread I suggested to get rid of the location dialog box but Johannes pointed out that this breaks the fullscreen mode. So, here is my proposed solution: * on ctrl-l: focus location bar * if in fullscreen mode: temporarily show toolbars until the user pressed enter I am not familiar with the fltk event model, so I just hijacked the existing event handler which works reasonably well. It would be nice to also capture any "on-blur" events, but I could use some hints (the fltk2 documentation only mentions 6 WHEN_* events, though some googling suggests that there might be UNFOCUS events... uh?). Anyway, the patch is attached. let me know what you think. 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 iD8DBQFILd5xoPmwNWhsaZYRApqEAJ9glSSkR3Q9oU0BmmUf9/ErG/ItfwCfVs5M asgEwaQAMk4ggsfzO2toTc0= =MHCi -----END PGP SIGNATURE-----

3 10

Keyboard shortcuts & fullscreen button
by 4winter＠informatik.uni-hamburg.de May 21, 2008

May 21, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The UI constructor creates a button for the fullscreen mode, but it is not added to anything: // Make the full screen button (to be attached to the viewport later) // TODO: attach to the viewport FullScreen = new HighlightButton(0,0,15,15); [...] Any idea why this was postponed? Should it be enabled now? Also I noticed, that the way events are handled is somewhat lax with respect to modifier keys. The code just checks if ctrl is pressed, not if ctrl but none of the other modifiers are pressed. This makes ctrl-l equivalent with ctrl-shift-alt-l. I'd like to hear your opinions, is this a bug or a feature? 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 iD8DBQFILwMvoPmwNWhsaZYRAmHYAJ49XUO6F6mBTG+CbWAzfN5yknkrKgCfQOjB QzlODEtqUdlztUo6tHuluUE= =hCHy -----END PGP SIGNATURE-----

2 3

Horizontal scrolling
by 4winter＠informatik.uni-hamburg.de May 19, 2008

May 19, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Huhu there :) attached is a tiny patch that enables the horizontal scrolling of the content of the main dillo widget. Unfortunately fltk supports this up to now (r6129) only on OSX. I do have a patch for fltk that enables this on x11, let's see if I can slip it in ;) 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 iD8DBQFIL0tNoPmwNWhsaZYRAmE+AJ9LN79iT4/nyt1JWJYt7BP1PYcFlQCeLV/g BRZ6xTrW7ER5rbDm7V5E1Hk= =SWKS -----END PGP SIGNATURE-----

2 1

website FAQ update
by corvid＠lavabit.com May 19, 2008

May 19, 2008

I made http://www.dillo.org/FAQ.corvid.html The old FAQ is still at http://www.dillo.org/FAQ.html for now. So if you have comments/find mistakes/whatever....

3 10

[patch] dillo and huge pages
by Johannes.Hofmann＠gmx.de May 19, 2008

May 19, 2008

Hi, to test how dillo behaves on huge pages, I downloaded the mysql manual as a single html page: http://downloads.mysql.com/docs/refman-5.1-en.html.tar.gz With this page I noticed that the drawRegion in FltkViewBase can grow pretty large which slows down loading the page. Attached patch limits the size of the drawRegion to 16 rectangles. With this patch (and HUGE_FILESIZE in cache.c increased to 16M) dillo works pretty well on this huge page. Better than dillo1 and firefox! One problem is that clicking on anchor links (to anchors within the page) reloads the page which take some time. Also memory usage gets pretty high (250M with images disabled). I'm experimenting with reducing the size of struct Word in textblock.hh by moving the highlight stuff out of struct Word and into Textblock. This brings memory usage down to 199M. However, I don't know the highlighting stuff enough to be sure I don't break anything. This probabely falls into the "premature optimization" category anyway. Cheers, Johannes

2 2

patch: dw configure args: rtfl and doublebuffer
by corvid＠lavabit.com May 19, 2008

May 19, 2008

I saw in the bug tracker that --disable-rtfl still turns on rtfl msgs. Did some reading. The third argument to AC_ARG_ENABLE is always run if the option was specified, regardless of the value. If the option is not specified, the fourth argument is run. --disable-FEATURE just becomes --enable-FEATURE=no. (I'll send a separate patch to Jorge to allow compilation with rtfl.)

2 1

Bug that aborts Dillo
by jcid＠dillo.org May 18, 2008

May 18, 2008

Hi there, I reviewed my personal notes on dillo segfaults and all of them but one are fixed now. This is: BUG: http://episteme.arstechnica.com/groupee/forums/a/tpc/f/96509133 /m/151006647731/r/264004847731 Aborts dillo. If you wget that URL to a local file, it's easier to debug because the problem is with a requested image. A negative number is propagated down from image.cc:199 #13 0x0807d083 in dw::Image::sizeAllocateImpl (this=0x81eca98,allocation=0xbfc69fb8) at image.cc:201 (gdb) p *allocation $4 = {x = 366, y = 941, width = 3, ascent = 2, descent = 1} (gdb) p dx $5 = 8 (gdb) p dy $6 = 26607 (gdb) allocation->width - dx = -5. from there width=-5 wreaks havoc. Please someone more seasoned in the (dx,dy) offsets give it a look. -- Cheers Jorge.-

2 2

Dillo freeze
by jcid＠dillo.org May 17, 2008

May 17, 2008

Hi there, Dillo freezes on this page: http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.6.tar.bz2.sign Dillo bug or FLTK2? -- Cheers Jorge.-

3 6

patch: some more window deletion
by corvid＠lavabit.com May 16, 2008

May 16, 2008

I thought I was going to have to remove the viewport from the UI because both UI and layout would want to delete it, but it appears that TopGroup gets informed of the deletion and everything turns out fine.

2 1

tabs - what are they?
by Johannes.Hofmann＠gmx.de May 15, 2008

May 15, 2008

Hi, while thinking about tabs I realized that I'm not really sure what they are. * On the one hand they could be implemented just as a GUI alternative to multiple bowser windows. * On the other hand they could be something like temporary bookmarks that are easily accessible e.g. via buttons below the panel. That way one would only need one layout and view. The only issue here would be that one would expect a separate navigation stack for each "tab". What do you think? Cheers, Johannes

2 2

Future of dillo2
by 4winter＠informatik.uni-hamburg.de May 13, 2008

May 13, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Diego wrote: >> With my recent patch (dpid-cleanup-and-DPIPATH.dillo2) one can use the >> attached script to run dillo in-tree which is nice if you just want to >> try it out but should also be useful for development purposes (easily >> manage different branches without the need to install them somewhere). > > The patch seems good to me, but i have not look it very deep or test it. Some more testing turned out that it's not enough to add another path to search for dpis. With no dpidrc fill_services_list fails: [dpid]: dpid.c:467: fill_services_list: Fatal error [dpid]: - Can't find the directory for dpis. This seems very non-plugin-like to me. What's the point in being able to have dpis in ~/.dillo/... but to actually use them you have to add them to your ~/.dillo/dpidrc. I mean it's okay up to this point, but consider you have one custom dpi in ~/.dillo/... : * in order to use it you have to create a custom dpidrc too * judging by a quick look at dpid.c/register_service I'd say that you have to copy the content of the system wide dpidrc file too since your custom one takes preference over the system wide one * now there's a package installed containing one more dpi. It might be doable to update the system wide dpidrc via a post-install script within the package (though thats error prone, you have to remove your entries on package removal etc.) * but what about the custom dpircs? You cannot have the post-install script modify those as well (well, you could, but naaa) > The idea is that each dpi can have its own files in its directory > (preferences, data, cache files ... ). I could go with preferences and data files, but caching feels like a no-no to me since on most installations the user is unable to write into those directories. 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 iD8DBQFIKgZ9oPmwNWhsaZYRAjL+AJ9SjhWBUNh5WcO51GkJLaqtDyjFEwCeMQkz jkTcvl8xIbP3EedZP8T72fc= =xAX5 -----END PGP SIGNATURE-----

1 0

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

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

May 13, 2008

On Mon, May 12, 2008 at 10:30:14PM +0000, corvid wrote: > > On Mon, May 12, 2008 at 09:35:46PM +0000, corvid wrote: > > > > http://www.dillo.org/Plans.html > > > > > > Did you commit/make/whatever it? > > > I thought "What changed?" and looked at a cached version, > > > and didn't see any differences. > > > > Not much here AFAIR the form elements and the rewrite of tables > > have now a green ball (finished). > > > > The bulk of it is adding what "should" be added. :-) > > I see the problem now. > > You didn't update the alt tags :) Yes! Now they're updated, and the extra items added, some sorting made and it looks more like what we have. I believe if we can complete the high priority items and stabilize the code we'd have a release candidate in our hands. If Sebastian completes the floating objects in textblock, that'd be great for the release, because dillo2 would show much better rendering in DIV-based and TABLE-based pages Comments? -- Cheers Jorge.-

1 0

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

May 13, 2008

On Mon, May 12, 2008 at 11:40:41PM +0200, Diego . wrote: > 2008/5/12 Jorge Arellano Cid <jcid(a)dillo.org>: > > > On Mon, May 12, 2008 at 03:51:42PM -0400, Jorge Arellano Cid wrote: > > > [...] > > > I'll try to update some pages in the site as soon as I find > > > some time. > > > > Just updated: > > > > http://www.dillo.org/cvs.html > > > > with directions on how to get dillo running. Developers, > > packagers, and experienced user should be pointed here. > > > > Somebody please check the directions work. :-P > > > > I doubt about the "exit" command, but i have not test the directions. "exit" is used as "logout" to get out of root. > and: > > > > http://www.dillo.org/Plans.html > > > > There is a line not updated under the "Current Plans for dillo2" text: > "--updated February 2007" > > It can be confusing. Ooops. Fixed. -- Cheers Jorge.-

1 0

Daily builds and tests / 0install feeds / PIE
by 4winter＠informatik.uni-hamburg.de May 11, 2008

May 11, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey hey :) I setup two boxes (one x86 running Debian lenny, one x86_64 running Ubuntu Hardy) to build daily snapshots of dillo2 (and fltk2). Tarballs, logs and screenshots are located at https://winter.gotdns.org/~teythoon/build/dillo2/ [suggestions for more interesting screenshots are welcome, like some testcases...] I also created a 0install feed (see http://0install.net/) for those daily builds. If you are on a "not that outdated" linux distribution (think of the libraries) on either x86 or x86_64 you can start dillo by running $ 0launch https://winter.gotdns.org/~teythoon/build/0feeds/dillo-fltk.xml If there is some interest in this I will try to make the builds more general (linking against older/more general versions of the required libraries etc). 0install feeds require programs to be position independent. Not like - -fpic or -pie but they should work where ever they and their files lie within the virtual file system. This is mostly true for dillo. dpid is located via PATH but the location to the dpis is (somewhat) hardcoded into the dpirc. So I went into dpid.c/register_all and poked around. Attached is a patch that allows me to specify an additional location for dpis via the environment variable DPIPATH. I also reorganized the code somewhat to minimize code duplication and I removed usr_srv_num since it was unused. Please let me know what you think :) 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 iD8DBQFIJw6poPmwNWhsaZYRAj4hAJ4rmvSQPPnHiGFQMXaTAGw3wg4JOQCeM9M3 oT6YvhD/s1ncdMQqAMifxgA= =NxaA -----END PGP SIGNATURE-----

1 0

[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

[patch]: dillo2 configure.in update for latest GNU m4
by onepoint＠starurchin.org May 10, 2008

May 10, 2008

I just updated my auto* tools including GNU m4 and the dillo2 build broke because "AC_SUBST(src doc)" complains that "src doc" is not a valid shell tag. I guess that the macro used to split at spaces and iterate over the result whereas the new version no longer does so. Anyway, replacing "AC_SUBST(src doc)" with "AC_SUBST(src)" and "AC_SUBST(doc)" seems to fix things. Patch attached. Please comment. Jeremy Henty

2 2

does RGBA work for you?
by corvid＠lavabit.com May 9, 2008

May 9, 2008

(I'd seen that there was talk on the fltk forums recently about RGBA and images ending up with the wrong dimensions, but that's not my problem.) If you uncomment RGBA in test/dw_images_scaled.cc, does dragging the window around cause part of it to turn pinkish? (I'll attach a diff, even though it's not exactly difficult.) I had started by hacking up the dillo side to send RGBA, and it worked fairly well in general for images where every pixel is either completely opaque or completely transparent. Gradients didn't seem to work too well, and often these pink/red regions were showing up. So far it seems as if the value of green relative to the value of alpha is what can make it particularly lose its mind, but that's probably wrong. You know how first impressions are... I followed it down to fltk/src/x11/Image.cxx, by which point it had been transformed to ARGB which looked about right to me. Then there's lots of xrender and transforms and things I don't know anything about. I tried some setcolor and fillrect in FltkImgbuf::draw(), but it didn't seem to matter, so I guess that's not my problem... If the question is "Why bother?", dillo2/src/png.c currently just mixes in whatever the background color is the first time we see an image on the page.

2 2

Render to image
by kfa＠gmx.net May 8, 2008

May 8, 2008

Hi @, First of all, thanks guys for doing this great project :) Wondered if I could ask for a few pointers before digging my way through the source to see if I could do the following: I'm thinking of using Dillo as a rendering engine inside of another project. All I need is having it render offscreen to an image object of some kind, producing a click map for the links would be an added advantage. I know how to do this with Mozilla but that is such a heavyweight beast. I don't need any network code as well, all input material (html and media files) woud be provided by the enclosing application. Does anyone have a hint on where to start looking, which files / classes / libs out of the dillo package I would need for this? Thanks, Klaus

2 2