dillo 2.1
by Johannes.Hofmann＠gmx.de
Hi Tomas,
On Mon, Jun 22, 2009 at 05:12:07PM +0300, Tomas R wrote:
> Been testing dillo 2.1 for some time and would like to share my
> experience.
>
> It's really great to see some basic css support (appearance of most if
> not all websites has improved alot), properly resized images,
> redirection and basic authentication working now :)
>
> Anyway, even dillo improved alot recently there still seems to be some
> issues. Here are some I've noticed after testing this release for few
> days:
> Rendering
> 1) ubuntu.lt
> Not sure if it's dillo fault or website's malformed stylesheet, but
> with default dillo settings some of the lithuanian characters are not
> displayed. This can be fixed by just adding "* {font-family:
> serif !important}" to the style.css. Here is a pic with some of the
> places where letters are missing marked in red:
> http://img4.imageshack.us/img4/2227/ubuntult.png
I guess the problem is that the font simply does not contain those
glyphs. There are some rules how this case should be handled, but
dillo does not implement them currently.
> 2) gmail
> It's nice that login works now, but with default dillo settings the
> size of most of the text is 1px. This can be partially fixed by adding
> font_min_size to dillorc, but it's obviously a dillo bug as this
> doesn't happen with links-hacked.
I don't have a gmail account, so I can't reproduce it, but
there seems to be a general bug in the CSS code that makes fonts
smaller than in other browsers.
> 3) google
> What's with the textarea in the top left corner of the page? And just
> for information: signing out doesn't work because it requires basic
> javascript support (works with links-hacked).
That textarea is in the google page. It's just hidden due to a
"display: none" CSS directive which is not supported yet by dillo.
Actually I'd like to know the reason why it is there before
hiding it.
> 4) Black on black, white on white...
> http://www.nma-fallout.com/forum/viewtopic.php?t=42776&start=2660&sid=a5712…
> For some reason black font color is used here and we get black text on
> black background in some posts (doesn't happen with links-hacked).
Oh. This is just horrible HTML / CSS, it's full of bugs!
The reason for black on black is:
<body bgcolor="#000000" text="#C0C0C0" link="#33CC00" vlink="#33CC00" />
I.e. body is immediately closed. But there is tons of other bugs on
this page.
> http://www.acetoneteam.org/
> Background color is not set here and if we have "body
> {background-color: white}" rule in our style.css file, we get white
> text on white background.
dillo does not handle color definitions of the form rgb(255,255,255)
yet. I guess we can fix that.
> 5) http://ubuntuforums.org/showthread.php?p=6592005
> What's with the PINK blocks? If that's more of a "feature" then a bug,
> can the color be changed by using some css rule?
I can't find pink blocks on that page. Where exactly do you see
them? Maybe post a screenshot.
> 6) http://www.binaryworld.skynet.lt/DUK.html
> If we use one link with fragment identifier in the page, all the others
> are marked as visited too.
Not sure how this should be handled correctly. Someone will have to
check the specs.
> 7) Authentication
> Basic authentication does work now, but at first the server displays a
> message saying "wrong credentials or browser doesn't
> understand how to supply the credentials" and only then a window
> pops up asking for the credentials...
>
> UI
> 1) Positioning the tab close button on the top RIGHT corner of the
> browser isn't a good thing because:
> a) The distance between the most commonly used buttons and the tab
> close button is pretty big (especially when widescreen monitors are
> pretty common nowadays);
> b) It only allows closing the active tab;
> I think it would be much better if all tabs had close buttons or at
> least the button was placed near the last tab.
Agreed. Patch welcome :)
> 2) Trivial but... because the setting to enable/disable image loading
> now is in the wrench menu it is two clicks away instead of one as it
> used to be in dillo 2.0. Maybe css settings could be left where they are
> now, but the setting for enabling/disabling images could be moved where
> it was in dillo 2.0?
> 3) UPPERCASE letters should be used in the File menu to define keyboard
> shortcuts, because now L looks like I (Open url... ctrl+l)
> 4) Don't you think "Are you sure you want to close the browser?"
> message is pretty annoying?
Which one exactly? When exiting dillo with multiple tabs/windows
open?
I don't think dillo asks a lot for confirmation, but I normally use
multiple Ctrl-q's to close all tabs and windows and quit.
>
> Other:
> It seems whoever designed the new website theme has no idea what
> READABILITY means... It looks like someone just used some stupid online
> color picker, which just picks some similar colors to the one user
> chooses. The old website looked MUCH MUCH better. Imho, it's a
> regression...
Hm I like the new design, but I agree that readability might be a problem.
Let's see what other say.
>
> PS: how to install dillo 2.1 claws-mail plugin?
Just install claws and the dillo plugin from source or packages
depending on your distribution.
Then make sure that dillo-2.1 is the dillo binary in your PATH.
Cheers,
Johannes
16 years, 2 months
Feature Request
by jcid＠dillo.org
On Sat, Nov 08, 2008 at 10:58:43PM +0100, Michal Nowak wrote:
> me at swva wrote:
>>
>> I think I'm being unclear, in two ways.
>>
>>>> Just to check, I did this as root :
>>>>
>>>> [root@Hbsk2 btth]# rpm -q dillo
>>>> dillo-0.8.6-7.fc9.i386
>>>> [root@Hbsk2 btth]# yum update dillo
>> ^^^^^^^^^^^^^^^^
>>>> Loaded plugins: refresh-packagekit
>>>> updates-newkey | 2.3 kB 00:00
>>>> updates | 2.6 kB 00:00
>>>> fedora | 2.4 kB 00:00
>>>> Setting up Update Process
>>>> No Packages marked for Update
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> [root@Hbsk2 btth]#
>>
>> On Sat, 8 Nov 2008, Johannes Hofmann wrote:
>>
>>> dillo-0.8.6 is no longer supported and you should consider to
>>> upgrade to dillo-2.0.
>>> But nevertheless for me it also works with dillo-0.8.6.
>>
>> For those who run other OSs, what the emphasized lines mean is the
>> 0.8.6 is what Fedora has, period. (I run F9, the latest release.) Any
>> idea why it's so far behind?? I didn't realize 1.0 had become official,
>> let alone 2.0
>>
>
> That's life. In Fedora, nor even Rawhide, isn't Dillo v2.0. Two reasons:
>
> 1) No one packed FLTK 2.x, check repository there's still 1.1.9.
> 2) Because of (1) no Dillo 2.
>
> Although Fedora is usually fresh, in case of Dillo it's still on Dillo
> 0.8.6 mainline. Feel free to file bug (bugzilla.redhat.com) against
> Dillo and Package Review for FLTK2, but be aware that having unstable
> FLTK 2.x in Fedora might be quite fight. (Believe me I am Fedora
> packager.)
Dillo2 doesn't need an FLTK2 package installed!
It can be statically linked in. One package, that's it.
(this is the default BTW).
Now, if distros need to also provide source packages by policy,
then that's a different story.
Please clarify me because I've read that complaint a few times,
and don't yet know whether it's my fault not making the statical
linking clear enough to packagers, or if there's a packaging
policy issue I don't know of. :)
--
Cheers
Jorge.-
16 years, 10 months
Future of dillo2
by Johannes.Hofmann＠gmx.de
Hi Sebastian,
On Sun, May 04, 2008 at 08:30:32PM +0200, Sebastian Geerken wrote:
> Hi,
>
> just if you were courious: I'm still living and will continue working
> on dillo.
That's fantastic!
>
> On Sun, Apr 20, Jorge Arellano Cid wrote:
> > [...]
> > We could:
> >
> > * Attract new developers with a dillo2 release,
> > leveraging the excellent documentation that we have.
>
> We have:
>
> - extensive documentations on the critical parts of dillo, expecially
> on Dw,
> - a prototype for CSS, and
> - some more documents and prototypes on future ideas, including
> scripting and graphical plugins.
>
> These should be copied on the web sever, and there should be a
> prominent note on the web site linking to a new delevolers' section.
> (Since attracting developers has high priority, this is what a visitor
> should notice first.)
>
> For those not listening to dillo-dev, it is important to know that
> dillo is still an active project.
>
> > * Planning for CSS, floating objects and TABS.
> > (this are important features to a nice browsing experience)
>
> Just FYI: I've started a bit on floats. Jorge, I once told you that it
> would take a week; actually it is a bit more complicated, nevertheless
> it is not a big job like CSS.
>
> > * Coordinate with FLTK2, DSL (Damn small linux) and other
> > lightweight distros, Debian installer team, MINIX3, etc.
>
> Perhaps we can find there other "lightweight zealots". :-)
>
> Sebastian
>
> P.S. I'll soon review the changes regarding redrawing and related.
> When working on floats, I noticed that the redraw optimization after
> resizes does not work fully correctly, there are situations where only
> a explicit redraw (e.g. hide and show window) makes size changes
> visible.
I've seen this too but can't reproduce it consistently.
Cheers,
Johannes
>
> P.P.S. In the doxygen documentation, there are two lists,
> html/bug.html and html/todo.html (generated from the \bug and \todo
> tags), with open issues. Furthermore, some problems are described in
> html/fltk-problems.html.
>
>
> _______________________________________________
> Dillo-dev mailing list
> Dillo-dev(a)dillo.org
> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
17 years, 4 months
Connection problems on Mac OS X 10.6.7
by rf.opensource＠gmail.com
Well after 2 days of chasing the non-connection bug, I'm still not
successful in locating the bug. But first a few points:
1. Mac-Fltk 1.3 indeed contains code for "select"ing socket events. I found
this myself and later Manolo verified it. The comment that Jorge mentioned
is a leftover, but the code is there. In fact it runs in a pthread, and the
whole system wouldn't work without it anyway.
2. So I'm now convinced the problem is somewhere in Dillo. Here is what I
have nailed it down to so far:
It seems to me that the problem might have to do with "repush". I run the
program as: $src/dillo | grep Nav_, and I can get no connection regardless
of the websites until I enter a URL that forces a repush. I have a list of
websites that do not entice a repush (some of the times):
www.yahoo.com,
www.google.com,
http://www.maketemplate.com/htmlgenerator/htmlout.php
autos.yahoo.com,
and as long as I keep entering any of these addresses after a fresh start
and I don't see a repush message in terminal, I will get nothing in my tabs.
As soon as I enter a URL that does entice a repush, the whole system works,
including the previous blocked tabs. If later on again a tab doesn't load
up, I can make the system work by opening other tabs and entering URLs until
a repush happens.
So, what is this repush business? And do you think it can have anything to
do with the bug I'm seeing?
By the way, the busy wait issue seems to be a different bug and just happens
to coincide. No matter which website I enter, the first tab (whether I enter
URL manually or on command line) never connects and always forces a busy
wait. As soon as I open another tab and enter any URL, regardless of whether
it will do a repush and open the clog or not, the busy-wait ends.
P.S. In my opinion (and ignoring this pesky bug) the single most important
feature lacking in dillo is support for floating elements. As soon as we
have it, dillo is as good as NetSurf (http://www.netsurf-browser.org/) in
functionality with half the memory footprint. As far as I can tell NetSurf
is the current champ of low resource + good enough functionality, while IMHO
dillo has more potential.
-Reza
On Fri, May 27, 2011 at 7:11 PM, reza farivar <rf.opensource(a)gmail.com>wrote:
>
>
> On Fri, May 27, 2011 at 3:53 PM, Jorge Arellano Cid <jcid(a)dillo.org>wrote:
>
>> On Fri, May 27, 2011 at 03:25:32PM -0500, reza farivar wrote:
>> > On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid(a)dillo.org>
>> wrote:
>> >
>> > > On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote:
>> > > > On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson <
>> > > obeythepenguin(a)gmail.com
>> > > > > wrote:
>> > > >
>> > > > > On Fri, 27 May 2011 13:38:43 -0400, reza farivar <
>> > > rf.opensource(a)gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > Yes. Well, the only plugin I could see is the save button on the
>> > > panel,
>> > > > >> and
>> > > > >> it can successfully navigate the filesystem and save a page
>> correctly.
>> > > > >>
>> > > > >
>> > > > > That one isn't a plugin, actually. Does the bookmarks button
>> work?
>> > > > >
>> > > > > Yes, bookmarks work. (This is a bit of strange implementation of
>> > > bookmarks,
>> > > > no? took me a bit to find out difference of section and item)
>> > >
>> > > Good!
>> > >
>> > > If you can see the html page from the bookmarks, it means the
>> > > whole dpi framework is working on Mac; they communicate using
>> > > sockets.
>> > >
>> > > So it seems the main thing pending is socket support in fl_wait
>> > > for Mac (see my previous email).
>> > >
>> >
>> > Yes, I also think it's the source of this problem (see my other email).
>> >
>> > But what really perplexes me is that this happens only when I enter a
>> URL
>> > manually. When I follow links from one page to another it never happens.
>> Are
>> > you guys using different (FLTK) functions when opening a new page or
>> > following a links (whether in the same tab or in a new tab)?
>>
>> No, but when you hit ENTER, FLTK has a chance to queue events
>> and zero-wait timeouts for the widget callback and necessary
>> stuff. OTOH, clicking a link goes another path (inside dillo).
>>
>> Can you point me to parts of code for either of these two code paths?
> Filename / line number should suffice.
>
>
>>
>> > And it seems that as Dillo "warms up" I get less of this problem...
>>
>> Timimg issues are moody.
>> e.g. Have you tried dillo listening a good mp3? :-)
>>
>> BTW, good you asked Manolo G.
>> (FWIW, FLTK2 has code for socket events in Mac).
>>
>> --
>> Cheers
>> Jorge.-
>>
>> _______________________________________________
>> Dillo-dev mailing list
>> Dillo-dev(a)dillo.org
>> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
>>
>
>
14 years, 3 months
patch: close windows from menubar
by jcid＠dillo.org
On Fri, Oct 10, 2008 at 04:13:01PM +0200, Johannes Hofmann wrote:
> On Thu, Oct 09, 2008 at 04:26:02PM -0400, Jorge Arellano Cid wrote:
> > On Wed, Oct 08, 2008 at 05:04:29PM +0200, Joerg Sonnenberger wrote:
> > > On Wed, Oct 08, 2008 at 03:32:42PM +0100, Jeremy Henty wrote:
> > > > On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote:
> > > >
> > > > > ... why would you want dillo1 and dillo2 at the same time.
> > > >
> > > > I don't know. But when you start saying "No-one could *possibly* want
> > > > to do that, so let's stop supporting it" then you are riding for a
> > > > fall. Why make ourselves hostages to fortune? Why not make *sure* we
> > > > avoid the problem rather than gambling that we've second-guessed our
> > > > entire user base? Murphy's law applies, so play it safe unless
> > > > there's a compelling reason not to.
> > >
> > > You are adding the overhead of changing user behavior though. The claws
> > > backend might be a good reason, frankly it is the only one I see so far.
> >
> > OK, just checked Debian and Ubuntu and both have the dillo
> > viewer plugin for sylpheed with a dependency on the plain "dillo"
> > package.
> >
> > Looking around in the FLTK docs, there's this function:
> >
> > CreatedWindow::set_xid()
> >
> > It looks promising. Unfortunately I haven't found a full
> > code example to make it work.
> >
> > If somebody knows how to use it, it'd be simple to make a "drop
> > in" replacement for dillo1, and avoid the problems discussed in
> > this thread.
>
> I think it's supposed to work more or less like in attached test program.
> When called with a (decimal) window id (from xlsclients) it draws a small
> but visible frame on that window.
> I don't know why it doesn't work correctly. Probabely some more
> setup necessary...
Dejan L. sent me this code as an example:
http://www.dillo.org/test/gnash.cc
ufortunately I can't get to make something that works with it.
--
Cheers
Jorge.-
16 years, 11 months
Re: Option to define external link handler
by Kevin Koster
Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote:
> The solution with the new design would involve:
>
> 1) Open a "gemini:" link
> 2) The request is routed to the gemini: dpi handler (like now)
> 3) The gemini plugin returns the .gmi file as-is as an HTTP response,
> instead of converting it to HTML
> 4) The .gmi mime type matches a rewrite rule and is rewritten into HTML
> in the SED node.
>
> Now, if we open a .gmi via HTTP:
>
> 1) Open a "https:" link
> 2) The request is routed to the usual HTTP/IO/TLS chain
> 3) The HTTP server returns the .gmi file as-is as an HTTP response.
> 4) The .gmi mime type matches a rewrite rule, and is rewritten into HTML
> in the SED node.
>
> Notice that the HTTP content can be compressed. So, for example, this
> simple rewrite script:
>
> #!/bin/sh
> sed 's_www.youtube.com_inv.vern.cc_g'
>
> Would only work well in the SED node *after* the HTTP content is
> uncompressed and the headers removed. The rewrite rules should indicate
> in which position of the chain they apply.
This mechanism might suit an idea I've had to do remote downscaling
of extremely large images, which are increasingly being included in
web pages. The script would send a list of URLs in all <img> tags
within the HTML to a remote server (eg. on a VPS), or ideally just
the ones for large image files, then rewrite the URLs in the HTML
to point to the remote server where the converted images are
available over HTTP/S.
Or a deeper approach would be to apply the same approach as this
rewrite engine to binary content as well, and have Dillo do it
transparently via 'rewrite'/convert rules for image MIME types.
Then the HTML would stay the same and Dillo would trigger a command
that requested a downscaled image from the converter server instead
of the original image's server. That would be more elegant, but
expands the scope of your proposed system a little.
Maybe since it still requires a remote Web server this problem
would be better solved via a Web proxy (I did look into Squid
before, but drowned in confusing documentation). But I just thought
I'd mention it as an example of a more complex usage for this
proposed rewrite system.
1 year, 2 months
--xid option
by Johannes.Hofmann＠gmx.de
On Tue, May 19, 2009 at 08:24:14PM +0200, Johannes Hofmann wrote:
> On Tue, May 19, 2009 at 01:34:56PM -0400, Jorge Arellano Cid wrote:
> > On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote:
> > > On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote:
> > > > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote:
> > > > > Hi,
> > > > >
> > > > > attached patch tries to implement the missing --xid option that is
> > > > > used to embed dillo into the claws mailer.
> > > > > The right way to do this would probabely be to implement the
> > > > > complete XEMBED protocol which is also mentioned in
> > > > > doc/fltk-problems.doc.
> > > > > However a simple XReparentWindow() seems to work more or less here.
> > > > > Please test.
> > > >
> > > > It seems like you forgot to commit xembed.{hh,cc} to the repo.
> > > > e.g. hg add xembed.hh xembed.cc
> > >
> > > Oh yes. Should be fixed now.
> > > Btw. I managed to install the claws mail client including the dillo
> > > plugin and it seems to work fine now with dillo2. That's why I just
> > > committed the xembed stuff.
> >
> > This is very good.
> >
> > I'll have to dig for the sylpheed contact to let them know.
> > Does anybody here know the email?
>
> I already contacted them on irc (#claws on freenode).
> It would be good if this get's some testing as there seems to be
> some interaction with the WM in use. I now tested it successful
> on dwm, twm, and fvwm.
> Also there are probabely more elegant ways to do it, but
> for now I think it's better than nothing.
More testing showed that the current implementation has severe
problems.
The thing is that the window manager that I use (dwm) is one of the
few non-reparenting WMs. Most others reparent new windows and that
can create races with the reparentin we do.
There also seems to be a problem with keyboard events in that case.
Is there anyone on the list with in-depth X11 knowledge who could
help with the xembed stuff?
Cheers,
Johannes
>
> Cheers,
> Johannes
16 years, 3 months
DPI infrastructure patches (3rd try)
by darkspirit5000＠gmail.com
Excuse me the triple mail. I am very sorry for the problems this mail causes
Hello and great work.
Here i resend 2 patches related to DPI infrastructure.
The first patch (dpid_services_support.diff) add the service concept to dpid
(like docs sugest) so DPIs names are not related to services names asked by
dillo, more than a DPI can serve a service and various DPIs can be installed
to serve one service.
The patch add new configuration lines in dpidrc, but can work without
changes in dpidrc. (backward compatible)
The lines in dpidrc have the form: service_name=ending_part_of_path_to_DPI
User DPIs are preferred to system DPIs.
Example:
bookmarks=/bookmarks.dpi
cookies=cookies/cookies.dpi
downloads=downloads/downloads.dpi
file=file/file.dpi
ftp=ftp/ftp.filter.dpi
https=https/https.filter.dpi
data=datauri/datauri.filter.dpi
hello=hello/hello.filter.dpi
service names ending in '*' match a service asked by dillo starting with the
text before the '*' and that not match other service names
Example:
car=car.dpi
cab=cab.dpi
ca*=a.dpi
a.dpi is used only if dillo ask for a service that start with ca but is not
car or cab
To test the patch add next line to dpidrc:
test=hello/hello.filter.dpi
and use the url
dpi:/test/
The second path (proto_services.diff) removes ad-hoc bindings for protocols
DPIs in dillo. It uses services for protocols handled externaly (internal
protocols: http and about; external: file, ftp, https and data). With this 2
features a protocol DPI (mms:, ed2k:, ...) can be programed without changes
to dillo.
The service names have the form proto.protocol_name. The lines below must be
added to dpidrc and dpid need to be patched with first path
(dpid_services_support.diff) so protocols works as before. (NOT backward
compatible)
proto.file=file/file.dpi
proto.ftp=ftp/ftp.filter.dpi
proto.https=https/https.filter.dpi
proto.data=datauri/datauri.filter.dpi
With the next line not handled protocols can return an error, a page to
download new DPIs or search new protocol DPIs in dillo page using a DPI:
proto.*=proto/unknown.filter.dpi
This scrip mimics dillo operation
#!/bin/sh
# read dillo open url command
read -d'>' dpip_tag
echo "<dpi cmd='send_status_message' msg='ERROR: unsupported protocol' '>"
I have rediscover the dpid bug (without and with pach) that ignore a DPI
installed in user and system DPI_dirs at the same time. It is not solved so
care about it.
Diego.
----------- dpid_services_support.diff
---------------------------------------------------------
diff -pru dillo2/dpid/dpid.c g/dpid/dpid.c
--- dillo2/dpid/dpid.c 2007-10-14 02:09:40.000000000 +0200
+++ g/dpid/dpid.c 2007-11-24 18:19:36.000000000 +0100
@@ -23,6 +23,7 @@
#include <sys/stat.h>
#include <sys/wait.h>
#include <unistd.h>
+#include <ctype.h>
#include "dpid_common.h"
#include "dpid.h"
#include "dpi.h"
@@ -138,6 +139,20 @@ void free_plugin_list(struct dp **dpi_at
*dpi_attr_list_ptr = NULL;
}
+/*! Free memory used by the services list
+ */
+void free_services_list(Dlist *s_list)
+{
+ int i = 0;
+ struct service *s;
+
+ for (i=0; i < dList_length(s_list) ; i++) {
+ s = dList_nth_data(s_list, i);
+ dFree(s->name);
+ }
+// dList_free(s_list);
+}
+
/*! \todo
* Remove terminator and est_terminator unless we really want to clean up
* on abnormal exit.
@@ -409,6 +424,145 @@ int register_all(struct dp **attlist)
return (snum);
}
+/*
+ * Compare two FileInfo pointers
+ * This function is used for sorting directories
+ */
+static int services_alpha_comp(const struct service *s1, const struct
service *s2)
+{
+ int t;
+
+ t=strcmp(s1->name, s2->name);
+ if (t>0)
+ return -1;
+ else if (t<0)
+ return 1;
+
+ return 0;
+}
+
+/*! Add services reading a dpidrc
file
+ * each non empty or commented line has the
form
+ * service =
path_relative_to_dpidir
+ *
\Return:
+ * \li Returns number of available services on
success
+ * \li -1 on
failure
+
*/
+int fill_services_list(struct dp **attlist, int numdpis, Dlist
*services_list)
+{
+ FILE *dpidrc_stream;
+ char *line = NULL;
+ int line_num = 0;
+ char *p;
+ char *service, *path;
+ int i;
+ struct service *s;
+ char *user_dpidir = NULL, *sys_dpidir = NULL, *dpidrc = NULL;
+
+ user_dpidir = dStrconcat(dGethomedir(), "/", dotDILLO_DPI, NULL);
+ if (access(user_dpidir, F_OK) == -1) {
+ /* no dpis in user's space */
+ dFree(user_dpidir);
+ user_dpidir = NULL;
+ }
+ dpidrc = dStrconcat(dGethomedir(), "/", dotDILLO_DPIDRC, NULL);
+ if (access(dpidrc, F_OK) == -1) {
+ dFree(dpidrc);
+ dpidrc = dStrdup(DPIDRC_SYS);
+ if (access(dpidrc, F_OK) == -1) {
+ dFree(dpidrc);
+ dpidrc = NULL;
+ }
+ }
+ if (!dpidrc || (sys_dpidir = get_dpi_dir(dpidrc)) == NULL)
+ sys_dpidir = NULL;
+
+ if (!user_dpidir && !sys_dpidir) {
+ ERRMSG("fill_services_list", "Fatal error ", 0);
+ fprintf(stderr, "\n - Can't find the directory for dpis.\n");
+ exit(1);
+ }
+
+ if ((dpidrc_stream = fopen(dpidrc, "r")) == NULL) {
+ ERRMSG("fill_services_list", "popen failed", errno);
+ dFree(dpidrc);
+ dFree(sys_dpidir);
+ dFree(user_dpidir);
+ return (-1);
+ }
+
+ /* dpidrc parser loop */
+ while ((line = dGetline(dpidrc_stream)) != NULL) {
+ i++;
+ /* ignore start spaces, commented and empty lines */
+ dStrstrip(line);
+ if (*line == '#' || *line == '\0')
+ continue;
+
+ service = line;
+ if ((path = strchr(line, '=')) == NULL) {
+ printf("malformed line in %s at %d: \'=\' not found\n", dpidrc,
line_num);
+ continue;
+ }
+ *path = '\0';
+ path++;
+
+ dStrstrip(service);
+ /* check that service name do not contains spaces */
+ if (strchr(service, ' ') != NULL) {
+ printf("malformed line in %s at %d: service contains spaces\n",
dpidrc, i);
+ continue;
+ }
+ if (strlen(service) < 2) {
+ printf("malformed line in %s at %d: service name too sort\n",
dpidrc, i);
+ continue;
+ }
+ /* ignore dpi_dir silently */
+ if (strcmp(service, "dpi_dir") == 0)
+ continue;
+
+ dStrstrip(path);
+ /* process quotes */
+ if (*path == '\"' || *path == '\'') {
+ p = strrchr(path + 1, *path);
+ if (p == NULL) {
+ printf("malformed line in %s at %d: unpaired \'%c\'\n", dpidrc,
i, *path);
+ continue;
+ } else if (p[1] != '\0') {
+ printf("malformed line in %s at %d: garbage after \'%c\'\n",
dpidrc, i, *path);
+ continue;
+ }
+ path++;
+ }
+
+ s = dNew(struct service, 1);
+ /* init services list entry */
+ s->name = dStrdup(service);
+ s->dp_index = -1;
+
+ dList_append(services_list, s);
+ /* search the dpi for a service by its path */
+ for (i = 0; i < numdpis; i++)
+ if ((p = strstr((*attlist)[i].path, path)) && *(p - 1) == '/' &&
+ strlen(p) == strlen(path))
+ break;
+ /* if the dpi exist bind service and dpi */
+ if (i < numdpis)
+ s->dp_index = i;
+ dFree(line);
+ }
+ fclose(dpidrc_stream);
+
+ dList_sort(services_list, (dCompareFunc)services_alpha_comp);
+
+ dFree(dpidrc);
+ dFree(sys_dpidir);
+ dFree(user_dpidir);
+
+ return (dList_length(services_list));
+}
+
+
/*! Initialise the service request socket
* \Return:
* \li Number of sockets (1 == success)
@@ -668,11 +822,13 @@ int register_all_cmd(char *sockdir)
stop_active_dpis(dpi_attr_list, numdpis);
rm_dpi_sockets(dpi_attr_list, numdpis);
free_plugin_list(&dpi_attr_list, numdpis);
+ free_services_list(services_list);
numdpis = 0;
numsocks = 1; /* the srs socket */
FD_ZERO(&sock_set);
FD_SET(srs, &sock_set);
numdpis = register_all(&dpi_attr_list);
+ fill_services_list(&dpi_attr_list, numdpis, services_list);
numsocks = init_all_dpi_sockets(dpi_attr_list, sockdir);
return (numdpis);
}
@@ -697,6 +853,20 @@ char *get_message(int sock, char *dpi_ta
return (msg);
}
+int service_match(const struct service *A, const char *B)
+{
+ int A_len, B_len, len;
+
+ A_len = strlen(A->name);
+ B_len = strlen(B);
+ len = MAX (A_len, B_len);
+
+ if (A->name[A_len - 1] == '*')
+ len = A_len - 1;
+
+ return(dStrncasecmp(A->name, B, len));
+}
+
/*!
* Send socket path that matches dpi_id to client
*/
@@ -705,12 +875,18 @@ void send_sockpath(int sock, char *dpi_t
int i;
char *dpi_id;
char *d_cmd;
+ struct service *serv;
dReturn_if_fail((dpi_id = get_message(sock, dpi_tag)) != NULL);
- for (i = 0; i < numdpis; i++)
- if (strstr(dpi_attr_list[i].id, dpi_id))
- break;
+ serv = dList_find_custom(services_list, dpi_id,
(dCompareFunc)service_match);
+
+ if (serv == NULL || (i = serv->dp_index) == -1)
+ for (i = 0; i < numdpis; i++)
+ if (!strncmp(dpi_attr_list[i].id, dpi_id,
+ dpi_attr_list[i].id - strchr(dpi_attr_list[i].id, '.')))
+ break;
+
if (i < numdpis) {
/* found */
if (access(dpi_attr_list[i].path, F_OK) == -1) {
diff -pru dillo2/dpid/dpid.h g/dpid/dpid.h
--- dillo2/dpid/dpid.h 2007-10-07 00:36:34.000000000 +0200
+++ g/dpid/dpid.h 2007-11-24 18:17:14.000000000 +0100
@@ -45,6 +45,13 @@ struct dp {
int filter;
};
+/*! bind dpi with service
+ */
+struct service {
+ char *name;
+ int dp_index;
+};
+
/*! Number of available plugins */
int numdpis;
@@ -54,6 +61,9 @@ int numsocks;
/*! State information for each plugin. */
struct dp *dpi_attr_list;
+/*! service served for each plugin */
+Dlist *services_list;
+
/*! Set of sockets watched for connections */
fd_set sock_set;
@@ -70,6 +80,8 @@ void free_dpi_attr(struct dp *dpi_attr);
void free_plugin_list(struct dp **dpi_attr_list_ptr, int numdpis);
+void free_services_list(Dlist *s_list);
+
enum file_type get_file_type(char *file_name);
int get_dpi_attr(char *dpi_dir, char *service, struct dp *dpi_attr);
@@ -78,6 +90,10 @@ int register_service(struct dp *dpi_attr
int register_all(struct dp **attlist);
+static int services_alpha_comp(const struct service *s1, const struct
service *s2);
+
+int fill_services_list(struct dp **attlist, int numdpis, Dlist
*services_list);
+
int init_srs_socket(char *sockdir);
int init_dpi_socket(struct dp *dpi_attr, char *sockdir);
@@ -98,6 +114,8 @@ int register_all_cmd(char *sockdir);
char *get_message(int sock, char *dpi_tag);
+int service_match(const struct service *A, const char *B);
+
void send_sockpath(int sock, char * dpi_tag, struct dp *dpi_attr_list);
#endif
diff -pru dillo2/dpid/main.c g/dpid/main.c
--- dillo2/dpid/main.c 2007-10-07 00:36:34.000000000 +0200
+++ g/dpid/main.c 2007-11-24 18:17:14.000000000 +0100
@@ -228,6 +228,7 @@ int main(void)
fd_set selected_set;
dpi_attr_list = NULL;
+ services_list = NULL;
//daemon(0,0); /* Use 0,1 for feedback */
/* todo: call setsid() ?? */
@@ -258,6 +259,11 @@ int main(void)
exit(1);
}
+ /* Init services list */
+ services_list = dList_new(8);
+ /* And get server list */
+ fill_services_list(&dpi_attr_list, numdpis, services_list);
+
/* Remove any sockets that may have been leftover from a crash */
cleanup(sockdir);
/* Initialise sockets */
---------- proto_services.diff -----------------------------------------
diff -pru dillo2/src/capi.c f/src/capi.c
--- dillo2/src/capi.c 2007-11-17 15:18:37.000000000 +0100
+++ f/src/capi.c 2007-11-21 04:35:22.000000000 +0100
@@ -240,8 +240,12 @@ static int Capi_dpi_verify_request(Dillo
static int Capi_url_uses_dpi(DilloUrl *url, char **server_ptr)
{
char *p, *server = NULL, *url_str = URL_STR(url);
+ Dstr *tmp;
- if (dStrncasecmp(url_str, "dpi:/", 5) == 0) {
+ if ((dStrncasecmp(url_str, "http:", 5) == 0) ||
+ (dStrncasecmp(url_str, "about:", 6) == 0)) {
+ /* Doing nothing returns 0 (url not uses dpi) and server = NULL */
+ } else if (dStrncasecmp(url_str, "dpi:/", 5) == 0) {
/* dpi prefix, get this server's name */
if ((p = strchr(url_str + 5, '/')) != NULL) {
server = dStrndup(url_str + 5, (uint_t)(p - url_str - 5));
@@ -252,16 +256,11 @@ static int Capi_url_uses_dpi(DilloUrl *u
dFree(server);
server = dStrdup("bookmarks");
}
-
- } else if (dStrncasecmp(url_str, "ftp:/", 5) == 0) {
- server = dStrdup("ftp");
-
- } else if (dStrncasecmp(url_str, "https:/", 7) == 0) {
- server = dStrdup("https");
- } else if (dStrncasecmp(url_str, "file:", 5) == 0) {
- server = dStrdup("file");
- } else if (dStrncasecmp(url_str, "data:", 5) == 0) {
- server = dStrdup("datauri");
+ } else if ((p = strchr(url_str, ':')) != NULL) {
+ tmp = dStr_new("proto.");
+ dStr_append_l(tmp, url_str, p - url_str);
+ server = tmp->str;
+ dStr_free(tmp, 0);
}
return ((*server_ptr = server) ? 1 : 0);
17 years, 9 months
FreeHG performance
by dillo-dev＠toykeeper.net
* Jeremy Henty <onepoint(a)starurchin.org> wrote:
> Looks good, but I think Dillo would have to migrate
> away from Mercurial to use it.
After using hg for the past couple years and bzr for about a
year, I've found bzr to be an upgrade. I still use both on a
regular basis, but no longer choose hg for any new projects.
The main differences to be aware of are:
- Branches are directories instead of labels. Each directory
has only one "head", and you switch between branches with
"cd". Merging is done like "cd trunk ; bzr merge ../my-bugfix".
- There are a lot of plugins available to extend functionality
in various ways. A couple I recommend are bzr-gtk ("bzr vis"
is a nice way to browse history) and bzr-bisect (helps
isolate where bugs were introduced).
- It has a concept of a main line of development, and
meaningful version numbers. Merges are always explicit, even
when hg would merge in-line. This makes feature branches
more useful.
That last one probably requires a little more explanation. Say
you branch from trunk at r100 to add a feature. It requires some
major changes, so you break everything while refactoring and
spend a few revisions getting it all working again. It takes 10
revisions total. So, you send the changes upstream. They like
it. They merge it... And nobody else checked anything in while
you were working. Now (in hg) trunk is at r110, with your new
feature. And the revision graph ends up being a straight line,
so there's no evidence a merge occurred. If anyone tries to use
r101 through r109, they'll find that it's all broken.
The way bzr handles it is you submit 10 revisions, and when
merged, trunk bumps up to r101. The revision graph shows a
branch off to the side with 10 changes (r100.1.1 through
r100.1.10) and a merge at the end (r101), and the trunk contains
only non-broken versions.
It makes more sense to me.
> They use bzr, and although they integrate with some other
> VCSs, mercurial isn't one of them.
It's a one-time conversion, instead of the two-way conduit they
support for subversion. I tried it just now (using
bzr-fastimport) and it worked. The new branch is in my "junk"
folder (launchpad equivalent of /tmp/) if anyone wants to try it:
bzr branch lp:~toykeeper/+junk/dillo
Personally, the main thing I find annoying about bzr is that it's
not the easiest thing to type. I use "alias b=bzr" in my shell
to fix that.
-- Scott
16 years, 7 months
Feature Request
by akemnade＠tzi.de
On Sun, 9 Nov 2008 09:38:11 +0100
Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote:
> On Sat, Nov 08, 2008 at 04:40:01PM -0500, me at swva wrote:
> >
> > I think I'm being unclear, in two ways.
> >
> >>> Just to check, I did this as root :
> >>>
> >>> [root@Hbsk2 btth]# rpm -q dillo
> >>> dillo-0.8.6-7.fc9.i386
> >>> [root@Hbsk2 btth]# yum update dillo
> > ^^^^^^^^^^^^^^^^
> >>> Loaded plugins: refresh-packagekit
> >>> updates-newkey | 2.3 kB 00:00
> >>> updates | 2.6 kB 00:00
> >>> fedora | 2.4 kB 00:00
> >>> Setting up Update Process
> >>> No Packages marked for Update
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>> [root@Hbsk2 btth]#
> >
> > On Sat, 8 Nov 2008, Johannes Hofmann wrote:
> >
> >> dillo-0.8.6 is no longer supported and you should consider to
> >> upgrade to dillo-2.0.
> >> But nevertheless for me it also works with dillo-0.8.6.
> >
> > For those who run other OSs, what the emphasized lines mean is the 0.8.6
> > is what Fedora has, period. (I run F9, the latest release.) Any idea why
> > it's so far behind?? I didn't realize 1.0 had become official, let alone
> > 2.0
> >
> >> If you enter "google.com" in the location bar and hit return
> >> it doesn't go to google?
> >
> > It does indeed. I'm putting this badly.
> >
> > I run Alpine 2.0; it is set to launch the default browser, which is
> > dillo -- and URLs in emails are what I use a default browser for.
> >
> > Does this mean something in my Alpine settings (and my Pine 4.64
> > settings, which it took over) is wrong? My Fedora default browser setting
> > is simply "dillo %s"; my Alpine setting is something I'll have to dig
> > for, as it's buried way deep.
>
> I don't know what Alpine exactly does, but if I do
> dillo google.com
> on the command line, it works fine with both dillo 2.0 and 0.8.6.
>
The interesting question here is which 0.8.6? the official one or the
inofficial dillo-i18n one? At least debian does not ship the official one.
If that's about the dillo-i18n stuff (and not reproducable with official
dillo), then the problem
should go to the corresponding team.
Greetings
Andreas Kemnade
16 years, 10 months