- Dillo-dev - lists.mailman3.com

Another Solaris fix.

by Mail.com Janke

Pulled CVS today -- Did bug 415 re-occur in current source or did I pull it wrong? In bm_srv12.c need something like: #ifndef PF_LOCAL #define PF_LOCAL PF_UNIX #endif Other than that the version in CVS compiles OK. --Mike -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup

March 7, 2003

How soon is Dillo to have download progress indication?

by Albert Wagner

How soon is Dillo expected to have some sort of download progress indicator? My primary use of a browser is searching for and downloading software.

March 6, 2003

Re: [Dillo-dev] Two branches?

by John Bradford

> > > Why don't we have a branch more like the Linux kernel? > > > > > > I would _love_ to have a cvs branch that had every bit of > > > developmental code in it so that we can see what's happening: > > > > To be honest, I would prefer not to use CVS at all, but instead just > > have a list of patches in unified diff format on the Dillo website, > > with a note saying which version they were made against. > > > > That way, everybody can apply whatever combination of patches they > > want to quickly and easily, and you can unapply a patch just using -R. > > > > Unified diff format makes it easier to apply patches against code that > > has already been modified. > > > > > Even though it will be _very_ unstable. > > > My theory is, if it is good enough for a screenshot, it's good enough > > > for the 'developmental' branch. > > > > > > This would also mean that the developer's personal trees will be > > > better sync'ed > > > > Having a separate development branch does create a fair amount of > > work, keeping the two in sync. > > > > John. > > I'm keen to either or both ideas. :) > > I'm a newbie to all this really, so I don't know too > much about serious advantages and disadvantages but I'm > in it primarily to enjoy myself and a fast-changing > unstable branch sounds like it could be fun. The decision is really up to Jorge :-). > Update on the issues John pointed out: > > 1. Disapearing list bullets. -- Solved, I'll make code > available if you are interested. Yes please. > But i'm busy at the moment. > > 2. List items other than the first in the list are > displayed slightly too far to the right. -- I've found > that Dw_widget_size_allocate is being called with an > extra +5 for the x coordinate of those list items. I > don't yet know why. > > 3. maximizing in FVWM2 -- I haven't looked into it at > all yet. > > > I'd like to have in my personal copy of Dillo two > features that have been available for Dillo in the past > but never made their way into CVS and were not > maintained: > > 1. Basic Authentication -- so I can use dillo > with the CUPS web interface. > > 2. Outside Html Source Viewer -- I'd rather > dillo spawn vim. Has anybody else noticed that when displaying very long lines in the source viewer, occasionally the arrows which indicate wrapped lines overlap the last letter on each screen line? > When I get a chance, I'll make the old patches and > probably some others available on my website. John.

March 6, 2003

Re: [Dillo-dev] Two branches?

by John Bradford

> Why don't we have a branch more like the Linux kernel? > > I would _love_ to have a cvs branch that had every bit of > developmental code in it so that we can see what's happening: To be honest, I would prefer not to use CVS at all, but instead just have a list of patches in unified diff format on the Dillo website, with a note saying which version they were made against. That way, everybody can apply whatever combination of patches they want to quickly and easily, and you can unapply a patch just using -R. Unified diff format makes it easier to apply patches against code that has already been modified. > Even though it will be _very_ unstable. > My theory is, if it is good enough for a screenshot, it's good enough > for the 'developmental' branch. > > This would also mean that the developer's personal trees will be > better sync'ed Having a separate development branch does create a fair amount of work, keeping the two in sync. John.

March 6, 2003

Two branches?

by TheStar

Why don't we have a branch more like the Linux kernel? I would _love_ to have a cvs branch that had every bit of developmental code in it so that we can see what's happening: gtk2 with pango tabs floating tables support <-- especially this one cut & paste support Even though it will be _very_ unstable. My theory is, if it is good enough for a screenshot, it's good enough for the 'developmental' branch. This would also mean that the developer's personal trees will be better sync'ed Of course, I'm just thinking, as I always do ;) I have yet to code... (A bit of python ;) )

March 6, 2003

Re: [Dillo-dev] freezing of dillo.0.7.0

by Jorge Arellano Cid

On Wed, 5 Mar 2003, robert w hall wrote: > In article <Pine.LNX.4.44.0303051147440.397-100000(a)infinity.cl>, Jorge > Arellano Cid <jcid(a)softhome.net> writes > > [...] > > Yes, the Linux kernel had a bug and it was fixed. > > > > Linux >= 2.4.9 => No problem. > no - see below > > > >> I originally compiled dillo0.6.6 against slack 7, kernel 2.4.5 (IIRC, or > >> even 2.2.18) with no problems. However dillo0.7.0 does freeze, > > NB > >even when > >> compiled against the headers for, and run under, kernel 2.4.19. > > so 2.4.19 + slack 7 + dillo 0.7.0 'ne marche pas' > > BUT it > >> compiles and runs ok when compiled under slack8.1, with the same headers > >> and kernel. > > There are more things in Heaven and Earth... Please test the latest CVS code and tell us how it goes. Cheers Jorge.-

March 6, 2003

Re: [Dillo-dev] More bugfixes

by Sebastian Geerken

On Tue, Mar 04, Jorge Arellano Cid wrote: > Sebastian: Please review BUG#424, Keith says it's a trivial fix. Yes, this is correct. Committed. > Ah, can anyone reproduce/not_reproduce bug 406? I can't. I've tried severals ways to circumvent the internationalization, but could not confirm this bug. Sebastian

March 5, 2003

Re: [Dillo-dev] freezing of dillo.0.7.0

by robert w hall

In article <Pine.LNX.4.44.0303051147440.397-100000(a)infinity.cl>, Jorge Arellano Cid <jcid(a)softhome.net> writes > > >On Thu, 27 Feb 2003, robert w hall wrote: > >> Is the description of the 'freezing' of dillo given in the README an >> uptodate description of the problem. This implies that it is a kernel >> version effect... > > Yes, the Linux kernel had a bug and it was fixed. > > Linux >= 2.4.9 => No problem. no - see below > >> I originally compiled dillo0.6.6 against slack 7, kernel 2.4.5 (IIRC, or >> even 2.2.18) with no problems. However dillo0.7.0 does freeze, NB >even when >> compiled against the headers for, and run under, kernel 2.4.19. so 2.4.19 + slack 7 + dillo 0.7.0 'ne marche pas' > BUT it >> compiles and runs ok when compiled under slack8.1, with the same headers >> and kernel. There are more things in Heaven and Earth... -- robert w hall

March 5, 2003

Alternative toolbar icons

by Jorge Arellano Cid

Hi there! I just updated the Icons page (the toolbar alternatives) (BUG#410). Go give it a look! Cheers Jorge.-

March 5, 2003

Re: a vulnerability in dillo

by Ivan Popov

Hello Jorge, thanks for your answer! On Wed, 5 Mar 2003, Jorge Arellano Cid wrote: > Probably (soon) socket file descriptors will reside in > /tmp/dillo and use temporary filenames, or something akin (this My first reaction is - who would be responsible for creating that /tmp/dillo? The first user? probably not. root at host startup? not a good idea to rely on the host admin to be able to run a program. May be something like /tmp/dillo-<truly-random-chars>/ per dillo instance, then you are rather safe against tampering but you have to make your bookmark server aware of possible parallel server accessing the same bookmarks. I would suggest not to rely on a common name all dillo instances of the same user would share. Then it would be 1. widely known and open to tampering 2. not working across different hosts anyway, as you need a server process per host, while bookmarks file may be shared between hosts. Just in case - I am glad you do not try to put sockets in/under homedirs. 1. the underlying filesystems may not support that 2. there is a hardcoded (in the specification) limit on the path name length of a unix socket - it breaks on some setups with homedirs deep in the filetree I mention it as it is a fairly often mistake of different software with unix sockets, to put sockets under the user's homedir. Best regards and thanks for dillo! -- Ivan

March 5, 2003