This start to seem like spam. Sorry.
I have upload to my page unfinished code for a prefs dpi and my first
screenshot :). The patch do not change dillo code, but need dillo code to
compile. (dpi lib).
The page is:
http://personales.ya.com/darkspirit/
If i get time i will try to post some docs about mime code for
dillo(unfinished, unpublished, break, etc) and questions about internals of
dillo.
Diego.
Hi,
On Sat, Sep 15, 2007 at 05:36:25AM -0700, j murphy wrote:
> Jorge:
> I hope that you and your collaborators are
> well, and that your plans for releasing the new dillo
> are still on track.
Yes, still on track.
> Despite the work being done on
> other lightweight browsers like hv3 and Twibright
> Labs' Links, I still prefer to use dillo,
:-)
> and I need
> it for use on some of my older, slower machines that
> have less memory, and are too slow with Firefox or
> Opera. I'm writing to share with you a few problems
> that I have noticed with dillo 0.8.6:
I'll answer them below, but please just notice that the main
problem we face now is lack of time from the main developers; we
know about bugs, and have development plans, but we have no time
or funds to quit our jobs and devote 100% to Dillo.
>
> 1)I often use a browser with tor ( https://tor.eff.org
> ) and privoxy ( http://www.privoxy.org )for secure
> browsing, and I was using dillo in this way, until I
> noticed (through some of the useful diagnostics at
> https://torcheck.xenobite.eu ) that dillo doesn't
> route https traffic through my web proxy correctly --
> instead it seems to establish a direct connection,
> bypassing the proxy, despite the http_proxy setting in
> my dillorc file. Normal http traffic seems to be
> handled correctly. Does the user need to set a
> separate proxy for https traffic? Or does the proxy
> handling in dillo have a bug?
Dillo's https support is basic. It uses wget for this. You can
set a proxy for wget and it should work.
> 2)Also, I've had some trouble with dillo's
> https.filter.dpi, which often sends an error message
> stating that it can't verify a certificate repeatedly,
> and sometimes launches multiple instances of itself
> when attempting to connect to the same website
> securely. This can occasionally lead to crashes in
> which https.filter.dpi.core is dumped, and
> occasionally brings down the browser as well. I
> realize that this information is somewhat vague, but
> if you'd like me to send a coredump next time it
> occurs, I'll do so.
Sad fact: it's a known bug.
No need to send the core. The problem is that currently there's
no cache for asking for a certificate, so a page with multiple
https resources (e.g. images) asks several times for the same
certificate flooding the communication socket.
>
> 3)The fltk downloader has one irritating glitch: when
> attempting to save a file, if the user to change the
> directory into which the file will be saved, the file
> name is cleared, requiring the user to type it in
> again, which wastes a lot of time.
Yes! This one has bitten me too.
This is the default behaviuor of that FLTK dialog. If I find
some time and a simple way to change that, I'll fix it.
>
> 4)When dillo is closed, many of the dpis that were
> spawned during a dillo session remain as zombie
> processes, when they ought to be terminated along with
> the parent dillo process. I realize that file
> downloads may have to be handled carefully, and may
> sometimes be required to remain open until completion,
> even after the parent dillo is closed, but it seems to
> me that no useful purpose is served by having the
> other dpis remain after dillo is closed.
dpidc stop
That command tells them to quit. If they remain, that's a bug.
>
> 5)With the latest snapshots of fltk2 on my machine,
> the downloader doesn't refresh itself properly when
> multiple files are being downloaded. For instance, a
> user starts one download, and the downloader gui is
> spawned with a progress tracking entry in the
> downloader gui for that particular download. Then the
> user starts another download, but the progress
> tracking entry for this second download, and for
> subsequent downloads, is not displayed properly: it's
> somehow underneath the first entry, and partially
> obscured by it, so that control of the download or
> tracking of it's progress isn't possible.
Yes I noticed this too. This simple problems hopefully will
be tackled by an interested developer when the code is released
(before the end of September. Cross your fingers.).
> I hope that this information will help you to improve
> your new version of dillo, if these problems have not
> already been addressed. If I can help, please let me
> know. (Of course I'm a scientist, and not really a
> developer, so don't expect miracles.)
Yes, your bug report is concise and self explaining. Thanks
for it. I wish I had the resources to work hands on in it now.
--
Cheers
Jorge.-
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)
Surely a thawn will increase the dillo users. what about a 1%?
The results from less to more
Does not apply 0.1 %
Netscape 0.1 %
Safari 0.2 %
Other (please tell us) 0.3 %
Flock 0.3 %
Galeon 0.4 %
Dillo 0.6 %
Seamonkey 1.7 %
Epiphany 2.3 %
Mozilla 3.7 %
Text-based browser (Lynx, Links, ELinks, etc.) 4.3 %
Opera 11.9 %
Konqueror 13.7 %
Firefox (aka Iceweasel) 59.6 %
Are there news about dillo development?
Diego.
