#include
From sandshrew at gmail.com Mon Jun 22 16:12:07 2009
From: sandshrew at gmail.com (Tomas R)
Date: Mon Jun 22 16:13:00 2009
Subject: [Dillo-dev] dillo 2.1
Message-ID: <20090622171207.18d7c924@ubuntu>
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
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.
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).
4) Black on black, white on white...
http://www.nma-fallout.com/forum/viewtopic.php?t=42776&start=2660&sid=a5712379bdb845ed64a2dfdca10509ea
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).
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.
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?
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.
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.
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?
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...
PS: how to install dillo 2.1 claws-mail plugin?
--
Brain: an apparatus with which we think we think. - A. Bierce
From jcid at dillo.org Mon Jun 22 18:17:38 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Mon Jun 22 18:17:54 2009
Subject: [Dillo-dev] trimming system includes
In-Reply-To: <20090622140228.GB4493@local.gobigwest.com>
References: <20090620153956.GS8031@local.gobigwest.com>
<20090621160806.GC6003@dillo.org>
<20090621165744.GA98409@blob.baaderstrasse.com>
<20090622020801.GZ8031@local.gobigwest.com>
<20090622055840.GA854@blob.baaderstrasse.com>
<20090622140228.GB4493@local.gobigwest.com>
Message-ID: <20090622161738.GC3876@dillo.org>
On Mon, Jun 22, 2009 at 02:02:28PM +0000, corvid wrote:
> Johannes wrote:
> > On Mon, Jun 22, 2009 at 02:08:01AM +0000, corvid wrote:
> > > Johannes wrote:
> > > > I'm all for it and will be happy to test it on DragonFly BSD.
> > >
> > > Does this come reasonably close to compiling?
> >
> > Works just fine here.
>
> Well, if it works for Johannes... :)
Good. Please commit so people can test from the repo.
> Anyway, I looked through the cvs archive a little, and it was interesting
> to see the prehistoric origins of some of this stuff, dating as far back
> as gzilla presumably. One is unavoidably reminded of how a living thing
> today bears the mark of billions of years of evolutionary past.
Maybe the original designers didn't have enough time to remove
or polish the rough edges, henceforth leaving the hybrid creature
on its own to do the job! :-)
--
Cheers
Jorge.-
From jcid at dillo.org Mon Jun 22 18:20:32 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Mon Jun 22 18:20:46 2009
Subject: [Dillo-dev] dillo-2.1.tar.bz2
In-Reply-To: <5e9a80350906220532n13da9915vbeb50d67949568fc@mail.gmail.com>
References: <20090617214502.GD10602@dillo.org>
<20090617220022.GE10602@dillo.org>
<5e9a80350906180136v4310720cp13d57a3df5be9abf@mail.gmail.com>
<20090618195629.GD3626@dillo.org>
<5e9a80350906181420p6bfb25a0jeed504a11cfbc64b@mail.gmail.com>
<20090619022906.GG8013@dillo.org> <20090619174452.GA7648@dillo.org>
<20090619232035.GC26421@dillo.org>
<20090620135127.GA5510@dillo.org>
<5e9a80350906220532n13da9915vbeb50d67949568fc@mail.gmail.com>
Message-ID: <20090622162032.GD3876@dillo.org>
On Mon, Jun 22, 2009 at 02:32:11PM +0200, Michal Nowak wrote:
> On Sat, Jun 20, 2009 at 3:51 PM, Jorge Arellano Cid wrote:
> > On Fri, Jun 19, 2009 at 07:20:35PM -0400, Jorge Arellano Cid wrote:
> >> On Fri, Jun 19, 2009 at 01:44:52PM -0400, Jorge Arellano Cid wrote:
> >> > On Thu, Jun 18, 2009 at 10:29:06PM -0400, Jorge Arellano Cid wrote:
> >> > > [...]
> >> > > ? WARNING: Please don't make the packages yet, I've got a last minute
> >> > > security vulnerability email, so maybe the tarball will change
> >> > > once more (the last). I'll try to have this solved tomorrow in the
> >> > > morning.
> >> >
> >> > ? OK, the last tarball was just uploaded (rc3) and it will
> >> > be announced tomorrow in the morning. It has a patch
> >> > for malformed PNG images.
> >> >
> >> > ? Please make the respective packages and let me know
> >> > when ready to link them from the downloads page.
> >>
> >> ? BTW, the announcement will be on Saturday 20's morning
> >> (UTC - 4). So there's still some time to finish the packages.
> >> Please make sure you have the last tarball by checking the
> >> signature, and let me know to update the linking page.
> >
> >
> > ?OK, the dillo-2.1 release announcement was submitted
> > to freshmeat and the download page updated with the URLs
> > of the latest packages.
> >
> > ?AFAIS everything is OK. Now I have to go out so if there's
> > something missing in the website, please let Corvid or Johannes
> > know here in dillo-dev.
> >
> > ?Great, let's hope for a good reception!
> >
> > --
> > ?Cheers
> > ?Jorge.-
> >
> > _______________________________________________
> > Dillo-dev mailing list
> > Dillo-dev@dillo.org
> > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
> >
>
> FYI
>
> Static Fedora-11 i586 & x86-64 packages:
>
> http://mnowak.fedorapeople.org/dillo2/static/F-11/
Good. It's linked from the downloads page.
--
Cheers
Jorge.-
From jcid at dillo.org Mon Jun 22 18:28:29 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Mon Jun 22 18:28:46 2009
Subject: [Dillo-dev] form widgets, ascent/descent
In-Reply-To: <20090621183648.GA1739@blob.baaderstrasse.com>
References: <20090604181143.GA1688@local.gobigwest.com>
<20090606223436.GF8570@dillo.org>
<20090621174734.GW8031@local.gobigwest.com>
<20090621183648.GA1739@blob.baaderstrasse.com>
Message-ID: <20090622162829.GE3876@dillo.org>
On Sun, Jun 21, 2009 at 08:36:48PM +0200, Johannes Hofmann wrote:
> On Sun, Jun 21, 2009 at 05:47:34PM +0000, corvid wrote:
> > Jorge wrote:
> > > On Thu, Jun 04, 2009 at 06:11:43PM +0000, corvid wrote:
> > > > I was playing around in dw, and noticed that,
> > > > whereas form widgets normally like to put
> > > > much of their height into descent, when style
> > > > sets the height, Textblock::calcWidgetSize()
> > > > puts it all into ascent.
> > > >
> > > > I checked firefox and saw that their form widgets ascend.
> > > >
> > > > If we made everything ascend and just put font->descent
> > > > into the descent, it would make life simpler.
> > > > Or, nearly. I guess there is RELIEF_Y_THICKNESS, but I
> > > > could almost ignore that...
> > >
> > > Not knowing exactly about the details, I'd be very careful
> > > in changing ascents, descents and friends because the may
> > > interfere with correct handling of CSS.
> > >
> > > If you're sure it's OK to do it, even considering the "details"
> > > (e.g. reliefs, spacings, paddings), then why not.
> >
> > Our details when it comes to form controls don't seem to be
> > exactly right to begin with, so I'm not making anything worse.
> > Little patch:
>
> > diff -r 9a913c474271 dw/fltkui.cc
> > --- a/dw/fltkui.cc Sun Jun 21 12:19:13 2009 -0400
> > +++ b/dw/fltkui.cc Sun Jun 21 17:22:14 2009 +0000
> > @@ -697,10 +697,10 @@ void FltkMultiLineTextResource::sizeRequ
> > (int)::fltk::getwidth ("n", 1) * numCols +
> > 2 * RELIEF_X_THICKNESS;
> > requisition->ascent =
> > - font->ascent + RELIEF_Y_THICKNESS;
> > + RELIEF_Y_THICKNESS + font->ascent +
> > + (font->ascent + font->descent) * (numRows - 1);
> > requisition->descent =
> > font->descent +
> > - (font->ascent + font->descent) * (numRows - 1) +
> > RELIEF_Y_THICKNESS;
> > } else {
> > requisition->width = 1;
> > @@ -1310,9 +1310,9 @@ void FltkListResource::sizeRequest (core
> > * options, at the cost of showing too much whitespace at times.
> > */
> > requisition->width = getMaxStringWidth() + 24;
> > - requisition->ascent = font->ascent + 2;
> > - requisition->descent = font->descent + 3 +
> > - (rows - 1) * (font->ascent + font->descent + 1);
> > + requisition->ascent = font->ascent + 2 +
> > + (rows - 1) * (font->ascent + font->descent + 1);
> > + requisition->descent = font->descent + 3;
> > } else {
> > requisition->width = 1;
> > requisition->ascent = 1;
>
> +1 from me.
> I can't see why this was handled different before.
>
OK, please commit.
--
Cheers
Jorge.-
From Johannes.Hofmann at gmx.de Mon Jun 22 18:49:06 2009
From: Johannes.Hofmann at gmx.de (Johannes Hofmann)
Date: Mon Jun 22 18:50:50 2009
Subject: [Dillo-dev] dillo 2.1
In-Reply-To: <20090622171207.18d7c924@ubuntu>
References: <20090622171207.18d7c924@ubuntu>
Message-ID: <20090622164836.GA59439@blob.baaderstrasse.com>
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=a5712379bdb845ed64a2dfdca10509ea
> 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:
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
From corvid at lavabit.com Mon Jun 22 19:24:28 2009
From: corvid at lavabit.com (corvid)
Date: Mon Jun 22 19:27:28 2009
Subject: [Dillo-dev] dillo 2.1
In-Reply-To: <20090622164836.GA59439@blob.baaderstrasse.com>
References: <20090622171207.18d7c924@ubuntu>
<20090622164836.GA59439@blob.baaderstrasse.com>
Message-ID: <20090622172428.GC4493@local.gobigwest.com>
Johannes wrote:
> On Mon, Jun 22, 2009 at 05:12:07PM +0300, Tomas R wrote:
> > 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.
Yeah, everything works for me because I have a real shortage of fonts,
so 99.9999% of text is shown in DejaVu fonts.
> > 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.
I'm not aware of anything in the HTML spec on it, at least.
> > 3) UPPERCASE letters should be used in the File menu to define keyboard
> > shortcuts, because now L looks like I (Open url... ctrl+l)
I'll look into this.
> > 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.
I still find visited text to be hard to read, but I know I should
break down and get a new display...
From sandshrew at gmail.com Mon Jun 22 20:53:08 2009
From: sandshrew at gmail.com (Tomas Rimkus)
Date: Mon Jun 22 20:54:38 2009
Subject: [Dillo-dev] dillo 2.1
In-Reply-To: <20090622164836.GA59439@blob.baaderstrasse.com>
References: <20090622171207.18d7c924@ubuntu>
<20090622164836.GA59439@blob.baaderstrasse.com>
Message-ID: <20090622185308.GA13793@lan-84-240-35-19.skynet.lt>
On Mon, Jun 22, 2009 at 06:49:06PM +0200, Johannes Hofmann wrote:
> 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.
>
I see.
> > 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.
The account is just few clicks away ;)
> > 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.
>
I guess, that's a honeypot for spambots.
> > 4) Black on black, white on white...
> > http://www.nma-fallout.com/forum/viewtopic.php?t=42776&start=2660&sid=a5712379bdb845ed64a2dfdca10509ea
> > 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:
>
>
> I.e. body is immediately closed. But there is tons of other bugs on
> this page.
I see. I'll try to contact the admin and see if I can fix some of the bugs.
> > 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.
>
Sounds good :)
> > 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.
>
Sure. Some of the blocks marked in red:
http://img20.imageshack.us/img20/2749/ubuntuforums.png
http://img20.imageshack.us/img20/6066/ubuntuforums1.png
> > 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.
>
I've checked opera, firefox, midori and chromium (aka google chrome under
BSD license) browsers. None of them act like that.
> > 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.
>
Yup, the one with multiple tabs. I just use my WM's shortcut for closing the
window.
> >
> > 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.
Ok, I'll try.
From corvid at lavabit.com Mon Jun 22 20:51:55 2009
From: corvid at lavabit.com (corvid)
Date: Mon Jun 22 20:54:54 2009
Subject: [Dillo-dev] dillo 2.1
In-Reply-To: <20090622172428.GC4493@local.gobigwest.com>
References: <20090622171207.18d7c924@ubuntu>
<20090622164836.GA59439@blob.baaderstrasse.com>
<20090622172428.GC4493@local.gobigwest.com>
Message-ID: <20090622185155.GG4493@local.gobigwest.com>
I wrote:
> Johannes wrote:
> > On Mon, Jun 22, 2009 at 05:12:07PM +0300, Tomas R wrote:
> > > 3) UPPERCASE letters should be used in the File menu to define keyboard
> > > shortcuts, because now L looks like I (Open url... ctrl+l)
>
> I'll look into this.
Hmm, I thought you were saying that this was new behaviour, but I
see the old code worked that way as well. You give the shortcut
to fltk and it draws it however it wants to draw it.
Oh, maybe your UI font used to be a serif font...
It is currently hardcoded to use font_sans_serif
(the reason being that whatever default UI font fltk picked out
for us was reasonably likely to have worse unicode coverage
than the fonts we set in dillorc), but there has been talk
of adding prefs for UI font and fontsize -- which I'd be
willing to do.
From sandshrew at gmail.com Mon Jun 22 21:49:05 2009
From: sandshrew at gmail.com (Tomas Rimkus)
Date: Mon Jun 22 21:50:34 2009
Subject: [Dillo-dev] dillo 2.1
In-Reply-To: <20090622164836.GA59439@blob.baaderstrasse.com>
References: <20090622171207.18d7c924@ubuntu>
<20090622164836.GA59439@blob.baaderstrasse.com>
Message-ID: <20090622194905.GA15843@lan-84-240-35-19.skynet.lt>
> > 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 :)
>
It seems this requires patching fltk -> http://www.mail-archive.com/fltk@easysw.com/msg05658.html
From Johannes.Hofmann at gmx.de Mon Jun 22 21:57:35 2009
From: Johannes.Hofmann at gmx.de (Johannes Hofmann)
Date: Mon Jun 22 22:01:03 2009
Subject: [Dillo-dev] dillo 2.1
In-Reply-To: <20090622194905.GA15843@lan-84-240-35-19.skynet.lt>
References: <20090622171207.18d7c924@ubuntu>
<20090622164836.GA59439@blob.baaderstrasse.com>
<20090622194905.GA15843@lan-84-240-35-19.skynet.lt>
Message-ID: <20090622195735.GA61775@blob.baaderstrasse.com>
On Mon, Jun 22, 2009 at 10:49:05PM +0300, Tomas Rimkus wrote:
> > > 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 :)
> >
>
> It seems this requires patching fltk -> http://www.mail-archive.com/fltk@easysw.com/msg05658.html
This just means, that fltk does not support that out of the box. It
would certainly be possible to implement it in dillo by overriding
the default fltk tab drawing code.
Cheers,
Johannes
From sandshrew at gmail.com Mon Jun 22 22:01:12 2009
From: sandshrew at gmail.com (Tomas Rimkus)
Date: Mon Jun 22 22:02:41 2009
Subject: [Dillo-dev] dillo 2.1]
Message-ID: <20090622200112.GB15843@lan-84-240-35-19.skynet.lt>
Accidentally sent to corvid only. Forwarding to dillo-dev.
> > > 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.
>
> I still find visited text to be hard to read, but I know I should
> break down and get a new display...
>
I wonder if you are the only dillo user with old display... BTW, I am using
pretty new LCD display and still find it hard to read.
From Johannes.Hofmann at gmx.de Tue Jun 23 13:16:05 2009
From: Johannes.Hofmann at gmx.de (Johannes Hofmann)
Date: Tue Jun 23 13:17:53 2009
Subject: [Dillo-dev] css font-size and nested tables
Message-ID: <20090623111603.GA68774@blob.baaderstrasse.com>
Hi,
trying to find the reason for the tiny fonts in gmail, I found the
following:
is rendered with the same font size in both lines in firefox,
konqueror, and opera.
Can someone enlighten me why the nested does not decrease the
font size again in the second line?
If I change the CSS to act on instead of | it works as
expected.
Cheers,
Johannes
From Johannes.Hofmann at gmx.de Tue Jun 23 13:37:11 2009
From: Johannes.Hofmann at gmx.de (Johannes Hofmann)
Date: Tue Jun 23 13:39:02 2009
Subject: [Dillo-dev] css font-size and nested tables
In-Reply-To: <20090623111603.GA68774@blob.baaderstrasse.com>
References: <20090623111603.GA68774@blob.baaderstrasse.com>
Message-ID: <20090623113711.GA39176@blob.baaderstrasse.com>
Oh well. Just found this here:
http://developer.mozilla.org/En/Fixing_Table_Inheritance_in_Quirks_Mode
Not sure whether I want to do anything about it.
Adding quirks in browsers just causes web developers to add quirks to
fix them and so on...
Cheers,
Johannes
On Tue, Jun 23, 2009 at 01:16:05PM +0200, Johannes Hofmann wrote:
> Hi,
>
> trying to find the reason for the tiny fonts in gmail, I found the
> following:
>
>
>
>
>
>
>
>
>
>
>
>
> is rendered with the same font size in both lines in firefox,
> konqueror, and opera.
> Can someone enlighten me why the nested | does not decrease the
> font size again in the second line?
>
> If I change the CSS to act on instead of | it works as
> expected.
>
> Cheers,
> Johannes
>
> _______________________________________________
> Dillo-dev mailing list
> Dillo-dev@dillo.org
> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
From sandshrew at gmail.com Tue Jun 23 16:13:29 2009
From: sandshrew at gmail.com (Tomas R)
Date: Tue Jun 23 16:14:23 2009
Subject: [Dillo-dev] css font-size and nested tables
In-Reply-To: <20090623113711.GA39176@blob.baaderstrasse.com>
References: <20090623111603.GA68774@blob.baaderstrasse.com>
<20090623113711.GA39176@blob.baaderstrasse.com>
Message-ID: <20090623171329.0ffc13e6@ubuntu>
On Tue, 23 Jun 2009 13:37:11 +0200
Johannes Hofmann wrote:
> Oh well. Just found this here:
>
> http://developer.mozilla.org/En/Fixing_Table_Inheritance_in_Quirks_Mode
>
> Not sure whether I want to do anything about it.
> Adding quirks in browsers just causes web developers to add quirks to
> fix them and so on...
>
For now, as a workaround font_min_size could be set to 10-12 by
default (anything lower than 10 is unreadable), but not sure how this
will effect some websites, where text is intentionally hidden by
setting its size to negative or very low value.
From sandshrew at gmail.com Tue Jun 23 16:13:56 2009
From: sandshrew at gmail.com (Tomas R)
Date: Tue Jun 23 16:14:49 2009
Subject: [Dillo-dev] dillo 2.1
In-Reply-To: <20090622195735.GA61775@blob.baaderstrasse.com>
References: <20090622171207.18d7c924@ubuntu>
<20090622164836.GA59439@blob.baaderstrasse.com>
<20090622194905.GA15843@lan-84-240-35-19.skynet.lt>
<20090622195735.GA61775@blob.baaderstrasse.com>
Message-ID: <20090623171356.6b8ba450@ubuntu>
One more thing that I forgot to mention in the first message is text
wrapping in textareas. By default unlike all the popular browsers dillo
does not wrap text in textareas. Actually discussion about this was
started in this mailing list some time ago but unexpectedly finished
after corvid pointed out that according to the standards it's up to the
browser to decide whether to wrap text or not. Maybe, if someone thinks
it's better when text is not wrapped, this could be made optional?
Would it be easy to implement this setting with fltk?
From jcid at dillo.org Tue Jun 23 17:01:28 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Tue Jun 23 17:01:43 2009
Subject: [Dillo-dev] css font-size and nested tables
In-Reply-To: <20090623113711.GA39176@blob.baaderstrasse.com>
References: <20090623111603.GA68774@blob.baaderstrasse.com>
<20090623113711.GA39176@blob.baaderstrasse.com>
Message-ID: <20090623150128.GC3600@dillo.org>
On Tue, Jun 23, 2009 at 01:37:11PM +0200, Johannes Hofmann wrote:
> Oh well. Just found this here:
>
> http://developer.mozilla.org/En/Fixing_Table_Inheritance_in_Quirks_Mode
>
> Not sure whether I want to do anything about it.
> Adding quirks in browsers just causes web developers to add quirks to
> fix them and so on...
Well, it's a quirk...
and we already have the font_min_size to tackle the problem.
I'd prefer to focus our scarce development time into issues
deemed high priority (e.g. the column rendering in textblock).
--
Cheers
Jorge.-
From Johannes.Hofmann at gmx.de Tue Jun 23 17:07:06 2009
From: Johannes.Hofmann at gmx.de (Johannes Hofmann)
Date: Tue Jun 23 17:08:51 2009
Subject: [Dillo-dev] css font-size and nested tables
In-Reply-To: <20090623171329.0ffc13e6@ubuntu>
References: <20090623111603.GA68774@blob.baaderstrasse.com>
<20090623113711.GA39176@blob.baaderstrasse.com>
<20090623171329.0ffc13e6@ubuntu>
Message-ID: <20090623150705.GA55437@blob.baaderstrasse.com>
On Tue, Jun 23, 2009 at 05:13:29PM +0300, Tomas R wrote:
> On Tue, 23 Jun 2009 13:37:11 +0200
> Johannes Hofmann wrote:
>
> > Oh well. Just found this here:
> >
> > http://developer.mozilla.org/En/Fixing_Table_Inheritance_in_Quirks_Mode
> >
> > Not sure whether I want to do anything about it.
> > Adding quirks in browsers just causes web developers to add quirks to
> > fix them and so on...
> >
>
> For now, as a workaround font_min_size could be set to 10-12 by
> default (anything lower than 10 is unreadable), but not sure how this
> will effect some websites, where text is intentionally hidden by
> setting its size to negative or very low value.
To simulate the behaviour of other browsers, you can add
table, caption {font-size: medium}
to your ~/.dillo/style.css for now.
Maybe we should add this to the FAQ?
Cheers,
Johannes
From jcid at dillo.org Tue Jun 23 22:01:24 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Tue Jun 23 22:01:41 2009
Subject: [Dillo-dev] Re: Dillo 2.1 questions
In-Reply-To: <4A3F7A2F.8000509@student.ethz.ch>
References: <4A3F7A2F.8000509@student.ethz.ch>
Message-ID: <20090623200124.GA11865@dillo.org>
Hi,
On Mon, Jun 22, 2009 at 02:33:51PM +0200, Donjan Rodic wrote:
> Hello Jorge
>
> First off, Dillo 2.1 is awesome. It got exactly the features I hoped for
Good!
> and isn't noticably more resource hungry.
In fact it has half the memory footprint of the dillo1 series.
http://www.dillo.org/memory.html
> Too bad it doesn't support column layouts in CSS yet... can we expect
> this in the next release?
I hope!
The column layout problem is mainly a lack of implementation
of floating elements in the textblock. it is one of the top priorities
for the next release (if not the topmost).
We'll work on it and try to fix it. We're yet to find out
how much work it will be.
> One thing I can't figure out are the available keybinding commands. For
> example, how would I call "scroll-one-screen-up", which I'd like to bind
> to Space. Similar to how Space scrolls one screen down.
> Also "open-link-in-new-tab" to "left-mouse-click"...
> I couldn't find any documentation on such commands, except for the keys
> listed in .dillo/keysrc.
You should have an installation-wide keysrc file along with dillorc.
If not, just read http://www.dillo.org/keysrc.
AFAIS, we haven't included that keybinding, but will probably
exist in the source repository soon.
Maybe: coarse-scroll-down, coarse-scroll-up,
fine-scroll-down, fine-scroll-up
> Another topic: is the adblock.txt in the .dillo folder supposed to work?
> Is there any recent documentation on this?
No, AFAIK it isn't in the release.
I'd really like to have it in the next release though.
--
Cheers
Jorge.-
From jcid at dillo.org Tue Jun 23 23:18:57 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Tue Jun 23 23:19:13 2009
Subject: [Dillo-dev] dillo 2.1
In-Reply-To: <20090622172428.GC4493@local.gobigwest.com>
References: <20090622171207.18d7c924@ubuntu>
<20090622164836.GA59439@blob.baaderstrasse.com>
<20090622172428.GC4493@local.gobigwest.com>
Message-ID: <20090623211857.GC11865@dillo.org>
On Mon, Jun 22, 2009 at 05:24:28PM +0000, corvid wrote:
> Johannes wrote:
> > On Mon, Jun 22, 2009 at 05:12:07PM +0300, Tomas R wrote:
> > > [...]
> > > 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.
>
> I'm not aware of anything in the HTML spec on it, at least.
Dillo shows pages already in memory in visited color. That way
you can easily tell an in-memory link from one that's yet to be
downloaded. This is very useful when switching from online to
offline mode (e.g. dialup).
IOW those links are rendered as visited because they're cached.
In the same page (answers section), unvisited links are
rendered as such.
--
Cheers
Jorge.-
From jcid at dillo.org Tue Jun 23 23:49:29 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Tue Jun 23 23:49:45 2009
Subject: [Dillo-dev] dillo-2.1.tar.bz2
In-Reply-To: <5e9a80350906180127q9994cd4gc60d5bf8a4dfbb67@mail.gmail.com>
References: <20090616180954.GD4239@dillo.org>
<64a208ca0906161234t7480693dx9b798233040870a@mail.gmail.com>
<20090616201059.GE4239@dillo.org>
<20090616211822.GB5061@assam.Belkin> <4A3812C4.4040207@pobox.com>
<5e9a80350906170611ib21c986va4b83b06b7a29a7a@mail.gmail.com>
<20090617190217.GB10602@dillo.org>
<5e9a80350906180127q9994cd4gc60d5bf8a4dfbb67@mail.gmail.com>
Message-ID: <20090623214929.GD11865@dillo.org>
On Thu, Jun 18, 2009 at 10:27:20AM +0200, Michal Nowak wrote:
> On Wed, Jun 17, 2009 at 9:02 PM, Jorge Arellano Cid wrote:
> > [...]
> > ?In a nutshell (from my point of view):
> >
> > ? * fltk2 is not officially released, and maybe never will.
> > ? * dillo2 uses fltk2, and this creates pressure to package it.
> > ? * Distros have a policy against statically-linked binaries.
>
> Definitely agree. The first and the second one can be somehow
> sorted out and fltk2 pushed to distribution, the last one is blocker.
>
> [...]
> You greatly outlined the problems with having Dillo-2 in distribution;
> the problem is FLTK2. While watching at "changes" in FLTK2 snapshots
> I can't thing that the development is stalled or even stopped.
You surely refer to the 1.3 series because FLTK2 is quite
stalled.
e.g. (nov 2008 version against current)
diff -pru fltk-2.0.x-r6525 fltk-2.0.x-r6786|less
/* Only whitespace and an email address change here! */
FLTK-1.3 is the active one
(a fact recognized by Bill Spitzak).
>
> I understand that my proposal won't be popular but switching from
> FLTK2 is necessary - we hardly have FLTK2 in distributions (read: no
> Dillo-2 in distribution) and that's shortening our user base.
I agree on the shortened user base, but the proposal to switch
to FLTK-1.3 is the probable course of action.
> How hard it would be to rewrite/port Dillo-2 to FLTK-1.3?
>
> (I see that the speed of v1.3 development is nothing exciting, but
> from what I read months ago they at least plan to have a release
> ever.)
This branch has advanced a lot. It has less open bugs than
FLTK-2.0 [1], an active set of developers, and they've devoted
plenty of time to good documentation.
> While looking at the devel cycle of Dillo - two releases per year -
> I believe this porting should be mid-term goal. Unless we wanna
> spend another year out of mainstream distributions. (And frankly:
> even with Dillo-2 based on FLTK-1.3 we are quite far from Dillo-2
> in distribution...)
Some months ago I had long emails with FLTK developers
regarding this point. FLTK-1.3 may have a release in the middle
of 2009 and they may even consider a compatibility layer for
FLTK-2.0 apps (for them, it would be a most appealing assset to
have FLTK-2.0 apps. compile with FLTK-1.3 painlessly).
Now, given the effort estimation by corvid, I'd go with a
native port as soon as FLTK-1.3 is released (unless the
compatibility layer is there, or porting turns out to be a major
endeavour). If they succeed in an official release, chances are
we'll have FLTK-1.3 in distros when we finish our port.
BTW, their advice is to wait for the first release and then
decide what to do.
[1] http://fltk.org/roadmap.php
--
Cheers
Jorge.-
From jcid at dillo.org Wed Jun 24 00:06:03 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Wed Jun 24 00:06:20 2009
Subject: [Dillo-dev] dillo 2.1]
In-Reply-To: <20090622200112.GB15843@lan-84-240-35-19.skynet.lt>
References: <20090622200112.GB15843@lan-84-240-35-19.skynet.lt>
Message-ID: <20090623220603.GG11865@dillo.org>
On Mon, Jun 22, 2009 at 11:01:12PM +0300, Tomas Rimkus wrote:
>
> Accidentally sent to corvid only. Forwarding to dillo-dev.
>
> > > > 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.
> >
> > I still find visited text to be hard to read, but I know I should
> > break down and get a new display...
> >
>
> I wonder if you are the only dillo user with old display... BTW, I am using
> pretty new LCD display and still find it hard to read.
OK, we also had readability concerns but we agreed that it was
enough. OTOH some people bashed the old design as prehistoric!
After all it's a matter of taste.
Usability is a different thing. Maybe you need higher contrast
to see clearly (I suffer with white backgrounds). Do you find
this one better to read [1]?
What do other people think about the new web design?
Aesthetically and from a readability point of view.
Please comment.
[1] http://www.dillo.org/test/website/dillo2.2.html
--
Cheers
Jorge.-
From corvid at lavabit.com Wed Jun 24 01:05:07 2009
From: corvid at lavabit.com (corvid)
Date: Wed Jun 24 01:08:09 2009
Subject: [Dillo-dev] dillo 2.1]
In-Reply-To: <20090623220603.GG11865@dillo.org>
References: <20090622200112.GB15843@lan-84-240-35-19.skynet.lt>
<20090623220603.GG11865@dillo.org>
Message-ID: <20090623230507.GJ6014@local.gobigwest.com>
Jorge wrote:
> On Mon, Jun 22, 2009 at 11:01:12PM +0300, Tomas Rimkus wrote:
> >
> > Accidentally sent to corvid only. Forwarding to dillo-dev.
> >
> > > > > 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.
> > >
> > > I still find visited text to be hard to read, but I know I should
> > > break down and get a new display...
> > >
> >
> > I wonder if you are the only dillo user with old display... BTW, I am using
> > pretty new LCD display and still find it hard to read.
>
> OK, we also had readability concerns but we agreed that it was
> enough. OTOH some people bashed the old design as prehistoric!
>
> After all it's a matter of taste.
> Usability is a different thing. Maybe you need higher contrast
> to see clearly (I suffer with white backgrounds). Do you find
> this one better to read [1]?
>
> What do other people think about the new web design?
> Aesthetically and from a readability point of view.
> Please comment.
>
>
> [1] http://www.dillo.org/test/website/dillo2.2.html
The test page's visited text is easier for me to read than
the home page's visited text.
Does anyone know what the contemporary way is to show the information
in Plans.html? I remember ball.gif being ubiquitous in html in 1995 --
in stratigraphy it is regarded as a valuable 'index fossil', often found
together with a variety of brightly-colored line.gifs and blink tags --
but I don't know what to do about it.
From corvid at lavabit.com Wed Jun 24 02:20:54 2009
From: corvid at lavabit.com (corvid)
Date: Wed Jun 24 02:24:02 2009
Subject: [Dillo-dev] patch: a binding for stop
In-Reply-To: <20090529193803.GR6001@local.gobigwest.com>
References: <20090506144645.GG6255@local.gobigwest.com>
<20090506153231.GB6113@dillo.org>
<20090506154731.GE29980@omphalos.singularity>
<20090527142256.GH6001@local.gobigwest.com>
<20090528144057.GA3663@dillo.org>
<20090529023904.GP6001@local.gobigwest.com>
<20090529155317.GB5026@dillo.org>
<20090529193803.GR6001@local.gobigwest.com>
Message-ID: <20090624002054.GK6014@local.gobigwest.com>
How about if we just don't give it any default binding:
-------------- next part --------------
diff -r 2367c730f679 src/keys.cc
--- a/src/keys.cc Tue Jun 23 21:33:46 2009 +0200
+++ b/src/keys.cc Wed Jun 24 00:14:17 2009 +0000
@@ -90,6 +90,7 @@ static const KeyBinding_t default_keys[]
{ "bookmarks" , KEYS_BOOKMARKS , fltk::CTRL , 'b' },
{ "fullscreen" , KEYS_FULLSCREEN , fltk::CTRL , fltk::SpaceKey },
{ "reload" , KEYS_RELOAD , fltk::CTRL , 'r' },
+ { "stop" , KEYS_STOP , 0 , 0 },
{ "hide-panels" , KEYS_HIDE_PANELS , 0 , fltk::EscapeKey },
{ "file-menu" , KEYS_FILE_MENU , fltk::ALT , 'f' },
{ "close-all" , KEYS_CLOSE_ALL , fltk::ALT , 'q' },
@@ -115,12 +116,14 @@ void Keys::init()
// Fill our key bindings list
bindings = dList_new(32);
for (uint_t i = 0; i < sizeof(default_keys) / sizeof(KeyBinding_t); i++) {
- node = dNew(KeyBinding_t, 1);
- node->name = dStrdup(default_keys[i].name);
- node->cmd = default_keys[i].cmd;
- node->modifier = default_keys[i].modifier;
- node->key = default_keys[i].key;
- dList_insert_sorted(bindings, node, nodeByKeyCmp);
+ if (default_keys[i].key) {
+ node = dNew(KeyBinding_t, 1);
+ node->name = dStrdup(default_keys[i].name);
+ node->cmd = default_keys[i].cmd;
+ node->modifier = default_keys[i].modifier;
+ node->key = default_keys[i].key;
+ dList_insert_sorted(bindings, node, nodeByKeyCmp);
+ }
}
}
diff -r 2367c730f679 src/keys.hh
--- a/src/keys.hh Tue Jun 23 21:33:46 2009 +0200
+++ b/src/keys.hh Wed Jun 24 00:14:17 2009 +0000
@@ -29,6 +29,7 @@ typedef enum {
KEYS_BOOKMARKS,
KEYS_FULLSCREEN,
KEYS_RELOAD,
+ KEYS_STOP,
KEYS_HIDE_PANELS,
KEYS_FILE_MENU,
KEYS_CLOSE_ALL,
diff -r 2367c730f679 src/ui.cc
--- a/src/ui.cc Tue Jun 23 21:33:46 2009 +0200
+++ b/src/ui.cc Wed Jun 24 00:14:17 2009 +0000
@@ -789,6 +789,9 @@ int UI::handle(int event)
ret = 1;
} else if (cmd == KEYS_RELOAD) {
a_UIcmd_reload(a_UIcmd_get_bw_by_widget(this));
+ ret = 1;
+ } else if (cmd == KEYS_STOP) {
+ a_UIcmd_stop(a_UIcmd_get_bw_by_widget(this));
ret = 1;
} else if (cmd == KEYS_FULLSCREEN) {
panelmode_cb_i();
From corvid at lavabit.com Wed Jun 24 07:13:51 2009
From: corvid at lavabit.com (corvid)
Date: Wed Jun 24 07:17:02 2009
Subject: [Dillo-dev] patch: viewport keybindings
Message-ID: <20090624051351.GM6014@local.gobigwest.com>
Here is an idea for viewport keybindings.
It just builds a SimpleVector once and lets all of the viewports point to it,
which I think goes against the dillo/dw boundary rules, but we'll see how
the general idea goes over...
-------------- next part --------------
diff -r 3d9d1d3d838e dw/fltkviewport.cc
--- a/dw/fltkviewport.cc Mon Jun 22 20:27:04 2009 +0000
+++ b/dw/fltkviewport.cc Wed Jun 24 04:57:17 2009 +0000
@@ -59,6 +59,7 @@ FltkViewport::FltkViewport (int x, int y
gadgets =
new container::typed::List >
(true);
+ bindings = NULL;
}
FltkViewport::~FltkViewport ()
@@ -282,57 +283,55 @@ int FltkViewport::handle (int event)
case ::fltk::KEY:
/* tell fltk we want to receive these KEY events as SHORTCUT */
- switch (::fltk::event_key()) {
- case PageUpKey:
- case PageDownKey:
- case SpaceKey:
- case DownKey:
- case UpKey:
- case RightKey:
- case LeftKey:
- case HomeKey:
- case EndKey:
- return 0;
- }
- break;
+ return 0;
case ::fltk::SHORTCUT:
- switch (::fltk::event_key()) {
- case PageUpKey:
- case 'b':
- case 'B':
- scroll (0, -vscrollbar->pagesize ());
- return 1;
-
- case PageDownKey:
- case SpaceKey:
- scroll (0, vscrollbar->pagesize ());
- return 1;
-
- case DownKey:
- scroll (0, (int) vscrollbar->linesize ());
- return 1;
-
- case UpKey:
- scroll (0, (int) -vscrollbar->linesize ());
- return 1;
-
- case RightKey:
- scroll ((int) hscrollbar->linesize (), 0);
- return 1;
-
- case LeftKey:
- scroll ((int) -hscrollbar->linesize (), 0);
- return 1;
-
- case HomeKey:
- scrollTo (scrollX, 0);
- return 1;
-
- case EndKey:
- scrollTo (scrollX, canvasHeight); /* gets adjusted in scrollTo () */
- return 1;
- }
+ { int shortcut = ::fltk::event_key() |
+ (::fltk::event_state() & (::fltk::SHIFT | ::fltk::CTRL |
+ ::fltk::ALT | ::fltk::META));
+ int len = bindings->size();
+
+ for (int i = 0; i < len; i++) {
+ Keybinding *b = bindings->getRef(i);
+
+ if (shortcut == b->shortcut) {
+
+ switch (b->cmd) {
+ case SCREEN_UP_CMD:
+ scroll (0, -vscrollbar->pagesize ());
+ return 1;
+
+ case SCREEN_DOWN_CMD:
+ scroll (0, vscrollbar->pagesize ());
+ return 1;
+
+ case LINE_DOWN_CMD:
+ scroll (0, (int) vscrollbar->linesize ());
+ return 1;
+
+ case LINE_UP_CMD:
+ scroll (0, (int) -vscrollbar->linesize ());
+ return 1;
+
+ case RIGHT_CMD:
+ scroll ((int) hscrollbar->linesize (), 0);
+ return 1;
+
+ case LEFT_CMD:
+ scroll ((int) -hscrollbar->linesize (), 0);
+ return 1;
+
+ case TOP_CMD:
+ scrollTo (scrollX, 0);
+ return 1;
+
+ case BOTTOM_CMD:
+ scrollTo (scrollX, canvasHeight); /* adjusted in scrollTo () */
+ return 1;
+ }
+ }
+ }
+ }
}
return FltkWidgetView::handle (event);
diff -r 3d9d1d3d838e dw/fltkviewport.hh
--- a/dw/fltkviewport.hh Mon Jun 22 20:27:04 2009 +0000
+++ b/dw/fltkviewport.hh Wed Jun 24 04:57:17 2009 +0000
@@ -15,6 +15,12 @@ class FltkViewport: public FltkWidgetVie
{
public:
enum GadgetOrientation { GADGET_VERTICAL, GADGET_HORIZONTAL };
+ enum KeyCommand {SCREEN_UP_CMD, SCREEN_DOWN_CMD, LINE_UP_CMD,
+ LINE_DOWN_CMD, LEFT_CMD, RIGHT_CMD, TOP_CMD, BOTTOM_CMD};
+ struct Keybinding {
+ KeyCommand cmd;
+ int shortcut;
+ };
private:
enum { SCROLLBAR_THICKNESS = 15 };
@@ -24,6 +30,7 @@ private:
int dragScrolling, dragX, dragY;
::fltk::Scrollbar *vscrollbar, *hscrollbar;
+ lout::misc::SimpleVector *bindings;
GadgetOrientation gadgetOrientation[4];
container::typed::List > *gadgets;
@@ -68,6 +75,8 @@ public:
void setGadgetOrientation (bool hscrollbarVisible, bool vscrollbarVisible,
GadgetOrientation gadgetOrientation);
void addGadget (::fltk::Widget *gadget);
+ inline void setKeybindings(lout::misc::SimpleVector *bindings)
+ {this->bindings = bindings;};
};
} // namespace fltk
diff -r 3d9d1d3d838e src/keys.cc
--- a/src/keys.cc Mon Jun 22 20:27:04 2009 +0000
+++ b/src/keys.cc Wed Jun 24 04:57:17 2009 +0000
@@ -98,7 +98,17 @@ static const KeyBinding_t default_keys[]
{ "forward" , KEYS_FORWARD , fltk::SHIFT , fltk::BackSpaceKey },
{ "forward" , KEYS_FORWARD , 0 , '.' },
{ "goto" , KEYS_GOTO , fltk::CTRL , 'l' },
- { "home" , KEYS_HOME , fltk::CTRL , 'h' }
+ { "home" , KEYS_HOME , fltk::CTRL , 'h' },
+ { "screen-up" , KEYS_SCREEN_UP , 0 , fltk::PageUpKey },
+ { "screen-up" , KEYS_SCREEN_UP , 0 , 'b' },
+ { "screen-down" , KEYS_SCREEN_DOWN , 0 , fltk::PageDownKey },
+ { "screen-down" , KEYS_SCREEN_DOWN , 0 , fltk::SpaceKey },
+ { "line-up" , KEYS_LINE_UP , 0 , fltk::UpKey },
+ { "line-down" , KEYS_LINE_DOWN , 0 , fltk::DownKey },
+ { "left" , KEYS_LEFT , 0 , fltk::LeftKey },
+ { "right" , KEYS_RIGHT , 0 , fltk::RightKey },
+ { "top" , KEYS_TOP , 0 , fltk::HomeKey },
+ { "bottom" , KEYS_BOTTOM , 0 , fltk::EndKey },
};
static Dlist *bindings;
@@ -256,6 +266,26 @@ int Keys::getShortcut(KeysCommand_t cmd)
return node->modifier + node->key;
}
return 0;
+}
+
+/*
+ * Given a keys command, return a list of all shortcuts for it, or NULL
+ * if there are none.
+ */
+Dlist *Keys::getShortcuts(KeysCommand_t cmd)
+{
+ int len = dList_length(bindings);
+ Dlist *ret = NULL;
+
+ for (int i = 0; i < len; i++) {
+ KeyBinding_t *node = (KeyBinding_t*)dList_nth_data(bindings, i);
+ if (cmd == node->cmd) {
+ if (!ret)
+ ret = dList_new(4);
+ dList_append(ret, INT2VOIDP(node->modifier + node->key));
+ }
+ }
+ return ret;
}
/*
diff -r 3d9d1d3d838e src/keys.hh
--- a/src/keys.hh Mon Jun 22 20:27:04 2009 +0000
+++ b/src/keys.hh Wed Jun 24 04:57:17 2009 +0000
@@ -12,6 +12,7 @@
#ifndef __KEYS_HH__
#define __KEYS_HH__
+#include "../dlib/dlib.h"
typedef enum {
KEYS_INVALID = -1,
@@ -35,7 +36,15 @@ typedef enum {
KEYS_BACK,
KEYS_FORWARD,
KEYS_GOTO,
- KEYS_HOME
+ KEYS_HOME,
+ KEYS_SCREEN_UP,
+ KEYS_SCREEN_DOWN,
+ KEYS_LINE_UP,
+ KEYS_LINE_DOWN,
+ KEYS_LEFT,
+ KEYS_RIGHT,
+ KEYS_TOP,
+ KEYS_BOTTOM
} KeysCommand_t;
class Keys {
@@ -52,6 +61,7 @@ public:
static void parse(FILE *fp);
static KeysCommand_t getKeyCmd(void);
static int getShortcut(KeysCommand_t cmd);
+ static Dlist *getShortcuts(KeysCommand_t cmd);
};
diff -r 3d9d1d3d838e src/uicmd.cc
--- a/src/uicmd.cc Mon Jun 22 20:27:04 2009 +0000
+++ b/src/uicmd.cc Wed Jun 24 04:57:17 2009 +0000
@@ -34,6 +34,7 @@
#include "history.h"
#include "msg.h"
#include "prefs.h"
+#include "keys.hh"
#include "dw/fltkviewport.hh"
@@ -386,12 +387,59 @@ void a_UIcmd_send_event_to_tabs_by_wid(i
}
/*
+ * Return the key bindings that are relevant to the viewport.
+ */
+static lout::misc::SimpleVector
+ * UIcmd_get_viewport_bindings()
+{
+ typedef struct {
+ KeysCommand_t keys_cmd;
+ FltkViewport::KeyCommand dw_cmd;
+ } mapping_t;
+
+ const mapping_t map[] = {
+ {KEYS_SCREEN_UP, FltkViewport::SCREEN_UP_CMD},
+ {KEYS_SCREEN_DOWN, FltkViewport::SCREEN_DOWN_CMD},
+ {KEYS_LINE_UP, FltkViewport::LINE_UP_CMD},
+ {KEYS_LINE_DOWN, FltkViewport::LINE_DOWN_CMD},
+ {KEYS_LEFT, FltkViewport::LEFT_CMD},
+ {KEYS_RIGHT, FltkViewport::RIGHT_CMD},
+ {KEYS_TOP, FltkViewport::TOP_CMD},
+ {KEYS_BOTTOM, FltkViewport::BOTTOM_CMD},
+ };
+
+ lout::misc::SimpleVector *ret =
+ new lout::misc::SimpleVector (16);
+
+ for (uint_t i = 0; i < (sizeof(map)/sizeof(mapping_t)); i++) {
+ Dlist *shortcuts = Keys::getShortcuts(map[i].keys_cmd);
+
+ if (shortcuts) {
+ FltkViewport::Keybinding binding;
+ int len = dList_length(shortcuts);
+
+ binding.cmd = map[i].dw_cmd;
+ for (int j = 0; j < len; j++) {
+ binding.shortcut = VOIDP2INT(dList_nth_data(shortcuts, j));
+
+ ret->increase();
+ ret->set(ret->size() - 1, binding);
+ }
+ dList_free(shortcuts);
+ }
+ }
+ return ret;
+}
+
+/*
* Create a new UI and its associated BrowserWindow data structure.
* Use style from v_ui. If non-NULL it must be of type UI*.
*/
BrowserWindow *a_UIcmd_browser_window_new(int ww, int wh,
uint32_t xid, const void *vbw)
{
+ static lout::misc::SimpleVector *viewportBindings
+ = NULL;
BrowserWindow *old_bw = (BrowserWindow*)vbw;
BrowserWindow *new_bw = NULL;
Window *win;
@@ -444,6 +492,9 @@ BrowserWindow *a_UIcmd_browser_window_ne
viewport->setBufferedDrawing (true);
else
viewport->setBufferedDrawing (false);
+ if (!viewportBindings)
+ viewportBindings = UIcmd_get_viewport_bindings();
+ viewport->setKeybindings(viewportBindings);
layout->attachView (viewport);
new_ui->set_render_layout(*viewport);
From newman.x at gmail.com Wed Jun 24 11:03:26 2009
From: newman.x at gmail.com (Michal Nowak)
Date: Wed Jun 24 11:04:23 2009
Subject: [Dillo-dev] [PATCH] warning: ignoring
=?utf-8?q?return_value_of_=E2=80=98int_?=
=?utf-8?b?Y2hkaXIoY29uc3QgY2hhciop4oCZ?=
Message-ID: <20090624090326.GA2865@assam.Belkin>
gcc-4.4.0-4.i586
HG tip:
newman src $ make | grep -i warning
[...]
paths.cc: In static member function ?static void Paths::init()?:
paths.cc:38: warning: ignoring return value of ?int chdir(const char*)?, declared with attribute warn_unused_result
With the patch dillo-guard-chdir.patch no warning. But this
patch alone won't have any effect, all MSG(...) from
Paths::init() won't write anything to output due to
prefs.show_msg not being set to TRUE at that moment. Patch
dillo-use-MSG-asap.patch moves a_Prefs_init()
before Paths::init() is called. Hope it's not breaking
anything.
Tested
- setting non-existing directory instead of /tmp
- Dillo won't crash on start, basic browsing works
--
Regards,
Michal Nowak
-------------- next part --------------
diff -r 95b8ea81632a src/paths.cc
--- a/src/paths.cc Wed Jun 24 08:16:33 2009 +0200
+++ b/src/paths.cc Wed Jun 24 10:50:28 2009 +0200
@@ -32,10 +32,15 @@
{
char *path;
struct stat st;
+ int rc = 0;
dFree(oldWorkingDir);
oldWorkingDir = dGetcwd();
- chdir("/tmp");
+ rc = chdir("/tmp");
+ if (rc == -1) {
+ MSG("paths: error changing directory to /tmp: %s\n",
+ dStrerror(errno));
+ }
path = dStrconcat(dGethomedir(), "/.dillo", NULL);
if (stat(path, &st) == -1) {
-------------- next part --------------
diff -r 95b8ea81632a src/dillo.cc
--- a/src/dillo.cc Wed Jun 24 08:16:33 2009 +0200
+++ b/src/dillo.cc Wed Jun 24 10:50:28 2009 +0200
@@ -258,15 +258,15 @@
}
dFree(opt_argv);
+ // set the default values for the preferences
+ a_Prefs_init();
+
// create ~/.dillo if not present
Paths::init();
// initialize default key bindings
Keys::init();
- // set the default values for the preferences
- a_Prefs_init();
-
// parse dillorc
if ((fp = Paths::getPrefsFP(PATHS_RC_PREFS))) {
PrefsParser::parse(fp);
From Johannes.Hofmann at gmx.de Wed Jun 24 14:24:41 2009
From: Johannes.Hofmann at gmx.de (Johannes Hofmann)
Date: Wed Jun 24 14:26:44 2009
Subject: [Dillo-dev] dillo 2.1
In-Reply-To: <20090622171207.18d7c924@ubuntu>
References: <20090622171207.18d7c924@ubuntu>
Message-ID: <20090624122441.GA4368@blob.baaderstrasse.com>
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
> 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.
> 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).
> 4) Black on black, white on white...
> http://www.nma-fallout.com/forum/viewtopic.php?t=42776&start=2660&sid=a5712379bdb845ed64a2dfdca10509ea
> 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).
> 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.
hg tip now has support for color definitions of the form
rgb(255,255,255).
Please give it a try.
Cheers,
Johannes
From sandshrew at gmail.com Wed Jun 24 16:24:05 2009
From: sandshrew at gmail.com (Tomas R)
Date: Wed Jun 24 16:25:01 2009
Subject: [Dillo-dev] dillo 2.1
In-Reply-To: <20090624122441.GA4368@blob.baaderstrasse.com>
References: <20090622171207.18d7c924@ubuntu>
<20090624122441.GA4368@blob.baaderstrasse.com>
Message-ID: <20090624172405.4353fae7@ubuntu>
On Wed, 24 Jun 2009 14:24:41 +0200
Johannes Hofmann wrote:
> hg tip now has support for color definitions of the form
> rgb(255,255,255).
>
> Please give it a try.
>
Thanks. It seems to work ok.
I have also tried the patch which makes text wrapping work in textareas
( http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-April/006267.html ).
The text does wrap but it doesn't automatically scroll down. Maybe the
patch could be committed with some adjustments?
--
Brain: an apparatus with which we think we think. - A. Bierce
From corvid at lavabit.com Wed Jun 24 16:50:17 2009
From: corvid at lavabit.com (corvid)
Date: Wed Jun 24 16:53:22 2009
Subject: [Dillo-dev] patch: save bookmark segfault when dpis not found
Message-ID: <20090624145017.GN6014@local.gobigwest.com>
A new one seen in the bugtracker...
a_Bookmarks_chat_add() sets URL to NULL, so it needs to be handled.
Anyway, the reason this is interesting is that I had always figured
the URL_*() macros were protecting against a NULL URL, when really
they protect against NULL fields in URLs.
-------------- next part --------------
diff -r 3d9d1d3d838e src/capi.c
--- a/src/capi.c Mon Jun 22 20:27:04 2009 +0000
+++ b/src/capi.c Wed Jun 24 14:39:46 2009 +0000
@@ -583,7 +583,7 @@ void a_Capi_ccc(int Op, int Branch, int
a_UIcmd_set_msg(conn->bw,
"ERROR: can't start dpid daemon "
"(URL scheme = '%s')!",
- URL_SCHEME(conn->url));
+ conn->url ? URL_SCHEME(conn->url) : "");
/* finish conn */
Capi_conn_unref(conn);
dFree(Info);
From jcid at dillo.org Wed Jun 24 17:50:54 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Wed Jun 24 17:51:10 2009
Subject: [Dillo-dev] patch: save bookmark segfault when dpis not found
In-Reply-To: <20090624145017.GN6014@local.gobigwest.com>
References: <20090624145017.GN6014@local.gobigwest.com>
Message-ID: <20090624155054.GA3858@dillo.org>
On Wed, Jun 24, 2009 at 02:50:17PM +0000, corvid wrote:
> A new one seen in the bugtracker...
>
> a_Bookmarks_chat_add() sets URL to NULL, so it needs to be handled.
>
> Anyway, the reason this is interesting is that I had always figured
> the URL_*() macros were protecting against a NULL URL, when really
> they protect against NULL fields in URLs.
Right.
Please commit (with changelog entry) and update the
bug track entry as "done".
--
Cheers
Jorge.-
From jcid at dillo.org Wed Jun 24 18:00:44 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Wed Jun 24 18:01:01 2009
Subject: [Dillo-dev] patch: a binding for stop
In-Reply-To: <20090624002054.GK6014@local.gobigwest.com>
References: <20090506144645.GG6255@local.gobigwest.com>
<20090506153231.GB6113@dillo.org>
<20090506154731.GE29980@omphalos.singularity>
<20090527142256.GH6001@local.gobigwest.com>
<20090528144057.GA3663@dillo.org>
<20090529023904.GP6001@local.gobigwest.com>
<20090529155317.GB5026@dillo.org>
<20090529193803.GR6001@local.gobigwest.com>
<20090624002054.GK6014@local.gobigwest.com>
Message-ID: <20090624160044.GB3858@dillo.org>
On Wed, Jun 24, 2009 at 12:20:54AM +0000, corvid wrote:
> How about if we just don't give it any default binding:
Committed.
--
Cheers
Jorge.-
From jcid at dillo.org Wed Jun 24 18:20:11 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Wed Jun 24 18:26:22 2009
Subject: [Dillo-dev] [PATCH] warning: ignoring return value of ???int
chdir(const char*)???
In-Reply-To: <20090624090326.GA2865@assam.Belkin>
References: <20090624090326.GA2865@assam.Belkin>
Message-ID: <20090624162011.GC3858@dillo.org>
On Wed, Jun 24, 2009 at 11:03:26AM +0200, Michal Nowak wrote:
> gcc-4.4.0-4.i586
>
> HG tip:
>
> newman src $ make | grep -i warning
> [...]
> paths.cc: In static member function ???static void Paths::init()???:
> paths.cc:38: warning: ignoring return value of ???int chdir(const char*)???, declared with attribute warn_unused_result
>
> With the patch dillo-guard-chdir.patch no warning. But this
> patch alone won't have any effect, all MSG(...) from
> Paths::init() won't write anything to output due to
> prefs.show_msg not being set to TRUE at that moment. Patch
> dillo-use-MSG-asap.patch moves a_Prefs_init()
> before Paths::init() is called. Hope it's not breaking
> anything.
>
> Tested
> - setting non-existing directory instead of /tmp
> - Dillo won't crash on start, basic browsing works
Committed.
There're also:
cookies.c:90: warning: ignoring return value of 'write',
cookies.c:249: warning: ignoring return value of 'fgets',
dpid.c:754: warning: ignoring return value of 'write'
bookmarks.c:696: warning: ignoring return value of 'system'
bookmarks.c:698: warning: ignoring return value of 'system'
cookies.c:188: warning: ignoring return value of 'write'
cookies.c:276: warning: ignoring return value of 'fgets'
cookies.c:341: warning: ignoring return value of 'fgets'
cookies.c:428: warning: ignoring return value of 'ftruncate'
cookies.c:1234: warning: ignoring return value of 'fgets'
datauri.c:283: warning: ignoring return value of 'chdir'
ftp.c:280: warning: ignoring return value of 'chdir'
Can you please make a patch for those too?
--
Cheers
Jorge.-
From jcid at dillo.org Wed Jun 24 19:48:28 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Wed Jun 24 19:48:55 2009
Subject: [Dillo-dev] patch: viewport keybindings
In-Reply-To: <20090624051351.GM6014@local.gobigwest.com>
References: <20090624051351.GM6014@local.gobigwest.com>
Message-ID: <20090624174828.GD3858@dillo.org>
On Wed, Jun 24, 2009 at 05:13:51AM +0000, corvid wrote:
> Here is an idea for viewport keybindings.
>
> It just builds a SimpleVector once and lets all of the viewports point to it,
> which I think goes against the dillo/dw boundary rules, but we'll see how
> the general idea goes over...
>
Well, that's one way to do it...
I'm more inclined to have an scrolling keys enum in
fltkviewport.hh, and to export another scrollTo() function that
receives them as parameter. Then we can catch the shortcut in
UI::handle(), and map between KEYS_* and the enum in a function
like a_UIcmd_set_scroll_xy().
That avoids stepping over the dillo/dw boundaries.
--
Cheers
Jorge.-
From jcid at dillo.org Wed Jun 24 20:38:17 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Wed Jun 24 20:38:45 2009
Subject: [Dillo-dev] dillo 2.1]
In-Reply-To: <20090623230507.GJ6014@local.gobigwest.com>
References: <20090622200112.GB15843@lan-84-240-35-19.skynet.lt>
<20090623220603.GG11865@dillo.org>
<20090623230507.GJ6014@local.gobigwest.com>
Message-ID: <20090624183817.GE3858@dillo.org>
On Tue, Jun 23, 2009 at 11:05:07PM +0000, corvid wrote:
> Jorge wrote:
> > On Mon, Jun 22, 2009 at 11:01:12PM +0300, Tomas Rimkus wrote:
> > >
> > > Accidentally sent to corvid only. Forwarding to dillo-dev.
> > >
> > > > > > 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.
> > > >
> > > > I still find visited text to be hard to read, but I know I should
> > > > break down and get a new display...
> > > >
> > >
> > > I wonder if you are the only dillo user with old display... BTW, I am using
> > > pretty new LCD display and still find it hard to read.
> >
> > OK, we also had readability concerns but we agreed that it was
> > enough. OTOH some people bashed the old design as prehistoric!
> >
> > After all it's a matter of taste.
> > Usability is a different thing. Maybe you need higher contrast
> > to see clearly (I suffer with white backgrounds). Do you find
> > this one better to read [1]?
> >
> > What do other people think about the new web design?
> > Aesthetically and from a readability point of view.
> > Please comment.
> >
> >
> > [1] http://www.dillo.org/test/website/dillo2.2.html
>
> The test page's visited text is easier for me to read than
> the home page's visited text.
Funny how it's the reverse effect for me! :-)
Please test:
:visited {color: #403090 !important}
and
:visited {color: #603060 !important}
on http://www.dillo.org/ and FAQ.
I prefer the first one because it fits the palette better.
--
Cheers
Jorge.-
From corvid at lavabit.com Wed Jun 24 20:59:00 2009
From: corvid at lavabit.com (corvid)
Date: Wed Jun 24 21:02:00 2009
Subject: [Dillo-dev] dillo 2.1]
In-Reply-To: <20090624183817.GE3858@dillo.org>
References: <20090622200112.GB15843@lan-84-240-35-19.skynet.lt>
<20090623220603.GG11865@dillo.org>
<20090623230507.GJ6014@local.gobigwest.com>
<20090624183817.GE3858@dillo.org>
Message-ID: <20090624185900.GP6014@local.gobigwest.com>
Jorge wrote:
> On Tue, Jun 23, 2009 at 11:05:07PM +0000, corvid wrote:
> > Jorge wrote:
> > > On Mon, Jun 22, 2009 at 11:01:12PM +0300, Tomas Rimkus wrote:
> > > >
> > > > Accidentally sent to corvid only. Forwarding to dillo-dev.
> > > >
> > > > > > > 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.
> > > > >
> > > > > I still find visited text to be hard to read, but I know I should
> > > > > break down and get a new display...
> > > > >
> > > >
> > > > I wonder if you are the only dillo user with old display... BTW, I am using
> > > > pretty new LCD display and still find it hard to read.
> > >
> > > OK, we also had readability concerns but we agreed that it was
> > > enough. OTOH some people bashed the old design as prehistoric!
> > >
> > > After all it's a matter of taste.
> > > Usability is a different thing. Maybe you need higher contrast
> > > to see clearly (I suffer with white backgrounds). Do you find
> > > this one better to read [1]?
> > >
> > > What do other people think about the new web design?
> > > Aesthetically and from a readability point of view.
> > > Please comment.
> > >
> > >
> > > [1] http://www.dillo.org/test/website/dillo2.2.html
> >
> > The test page's visited text is easier for me to read than
> > the home page's visited text.
>
> Funny how it's the reverse effect for me! :-)
>
>
> Please test:
>
> :visited {color: #403090 !important}
>
> and
>
> :visited {color: #603060 !important}
>
> on http://www.dillo.org/ and FAQ.
>
> I prefer the first one because it fits the palette better.
First one is easier.
From jcid at dillo.org Wed Jun 24 21:06:52 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Wed Jun 24 21:07:08 2009
Subject: [Dillo-dev] dillo 2.1]
In-Reply-To: <20090624185900.GP6014@local.gobigwest.com>
References: <20090622200112.GB15843@lan-84-240-35-19.skynet.lt>
<20090623220603.GG11865@dillo.org>
<20090623230507.GJ6014@local.gobigwest.com>
<20090624183817.GE3858@dillo.org>
<20090624185900.GP6014@local.gobigwest.com>
Message-ID: <20090624190652.GH3858@dillo.org>
On Wed, Jun 24, 2009 at 06:59:00PM +0000, corvid wrote:
> Jorge wrote:
> > On Tue, Jun 23, 2009 at 11:05:07PM +0000, corvid wrote:
> > > Jorge wrote:
> > > > On Mon, Jun 22, 2009 at 11:01:12PM +0300, Tomas Rimkus wrote:
> > > > >
> > > > > Accidentally sent to corvid only. Forwarding to dillo-dev.
> > > > >
> > > > > > > > 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.
> > > > > >
> > > > > > I still find visited text to be hard to read, but I know I should
> > > > > > break down and get a new display...
> > > > > >
> > > > >
> > > > > I wonder if you are the only dillo user with old display... BTW, I am using
> > > > > pretty new LCD display and still find it hard to read.
> > > >
> > > > OK, we also had readability concerns but we agreed that it was
> > > > enough. OTOH some people bashed the old design as prehistoric!
> > > >
> > > > After all it's a matter of taste.
> > > > Usability is a different thing. Maybe you need higher contrast
> > > > to see clearly (I suffer with white backgrounds). Do you find
> > > > this one better to read [1]?
> > > >
> > > > What do other people think about the new web design?
> > > > Aesthetically and from a readability point of view.
> > > > Please comment.
> > > >
> > > >
> > > > [1] http://www.dillo.org/test/website/dillo2.2.html
> > >
> > > The test page's visited text is easier for me to read than
> > > the home page's visited text.
> >
> > Funny how it's the reverse effect for me! :-)
> >
> >
> > Please test:
> >
> > :visited {color: #403090 !important}
> >
> > and
> >
> > :visited {color: #603060 !important}
> >
> > on http://www.dillo.org/ and FAQ.
> >
> > I prefer the first one because it fits the palette better.
>
> First one is easier.
Is it good enough for you?
--
Cheers
Jorge.-
From corvid at lavabit.com Wed Jun 24 22:04:53 2009
From: corvid at lavabit.com (corvid)
Date: Wed Jun 24 22:07:54 2009
Subject: [Dillo-dev] patch: save bookmark segfault when dpis not found
In-Reply-To: <20090624155054.GA3858@dillo.org>
References: <20090624145017.GN6014@local.gobigwest.com>
<20090624155054.GA3858@dillo.org>
Message-ID: <20090624200453.GR6014@local.gobigwest.com>
Jorge wrote:
> On Wed, Jun 24, 2009 at 02:50:17PM +0000, corvid wrote:
> > A new one seen in the bugtracker...
> >
> > a_Bookmarks_chat_add() sets URL to NULL, so it needs to be handled.
> >
> > Anyway, the reason this is interesting is that I had always figured
> > the URL_*() macros were protecting against a NULL URL, when really
> > they protect against NULL fields in URLs.
>
> Right.
>
> Please commit (with changelog entry) and update the
> bug track entry as "done".
The entry is also partly about the fact that the dpis aren't working
with their deb package. Perhaps something is broken in it with
sysconfdir changing.
From jcid at dillo.org Wed Jun 24 23:53:23 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Thu Jun 25 00:13:07 2009
Subject: [Dillo-dev] dillo 2.1]
In-Reply-To: <20090624185900.GP6014@local.gobigwest.com>
References: <20090622200112.GB15843@lan-84-240-35-19.skynet.lt>
<20090623220603.GG11865@dillo.org>
<20090623230507.GJ6014@local.gobigwest.com>
<20090624183817.GE3858@dillo.org>
<20090624185900.GP6014@local.gobigwest.com>
Message-ID: <20090624215323.GI3858@dillo.org>
On Wed, Jun 24, 2009 at 06:59:00PM +0000, corvid wrote:
> Jorge wrote:
> > On Tue, Jun 23, 2009 at 11:05:07PM +0000, corvid wrote:
> > > Jorge wrote:
> > > > On Mon, Jun 22, 2009 at 11:01:12PM +0300, Tomas Rimkus wrote:
> > > > >
> > > > > Accidentally sent to corvid only. Forwarding to dillo-dev.
> > > > >
> > > > > > > > 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.
> > > > > >
> > > > > > I still find visited text to be hard to read, but I know I should
> > > > > > break down and get a new display...
> > > > > >
> > > > >
> > > > > I wonder if you are the only dillo user with old display... BTW, I am using
> > > > > pretty new LCD display and still find it hard to read.
> > > >
> > > > OK, we also had readability concerns but we agreed that it was
> > > > enough. OTOH some people bashed the old design as prehistoric!
> > > >
> > > > After all it's a matter of taste.
> > > > Usability is a different thing. Maybe you need higher contrast
> > > > to see clearly (I suffer with white backgrounds). Do you find
> > > > this one better to read [1]?
> > > >
> > > > What do other people think about the new web design?
> > > > Aesthetically and from a readability point of view.
> > > > Please comment.
> > > >
> > > >
> > > > [1] http://www.dillo.org/test/website/dillo2.2.html
> > >
> > > The test page's visited text is easier for me to read than
> > > the home page's visited text.
> >
> > Funny how it's the reverse effect for me! :-)
> >
> >
> > Please test:
> >
> > :visited {color: #403090 !important}
> >
> > and
> >
> > :visited {color: #603060 !important}
> >
> > on http://www.dillo.org/ and FAQ.
> >
> > I prefer the first one because it fits the palette better.
>
> First one is easier.
Committed.
--
Cheers
Jorge.-
From jcid at dillo.org Thu Jun 25 00:12:50 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Thu Jun 25 00:13:14 2009
Subject: [Dillo-dev] [marcio.ccamargo@gmail.com: Thank u!]
Message-ID: <20090624221250.GJ3858@dillo.org>
Hi,
:)
--
Cheers
Jorge.-
-------------- next part --------------
An embedded message was scrubbed...
From: marcio
Subject: Thank u!
Date: Wed, 24 Jun 2009 18:41:39 -0300
Size: 2251
Url: /pipermail/attachments/20090624/49a79f9b/attachment.mht
From newman.x at gmail.com Thu Jun 25 20:36:45 2009
From: newman.x at gmail.com (Michal Nowak)
Date: Thu Jun 25 19:37:12 2009
Subject: [Dillo-dev] [PATCH] warning: ignoring return value of ???int
chdir(const char*)???
In-Reply-To: <20090624162011.GC3858@dillo.org>
References: <20090624090326.GA2865@assam.Belkin>
<20090624162011.GC3858@dillo.org>
Message-ID: <20090625183644.GA2779@assam.lab.eng.brq.redhat.com>
On Wed, Jun 24, 2009 at 12:20:11PM -0400, Jorge Arellano Cid wrote:
> On Wed, Jun 24, 2009 at 11:03:26AM +0200, Michal Nowak wrote:
> > gcc-4.4.0-4.i586
> >
> > HG tip:
> >
> > newman src $ make | grep -i warning
> > [...]
> > paths.cc: In static member function ???static void Paths::init()???:
> > paths.cc:38: warning: ignoring return value of ???int chdir(const char*)???, declared with attribute warn_unused_result
> >
> > With the patch dillo-guard-chdir.patch no warning. But this
> > patch alone won't have any effect, all MSG(...) from
> > Paths::init() won't write anything to output due to
> > prefs.show_msg not being set to TRUE at that moment. Patch
> > dillo-use-MSG-asap.patch moves a_Prefs_init()
> > before Paths::init() is called. Hope it's not breaking
> > anything.
> >
> > Tested
> > - setting non-existing directory instead of /tmp
> > - Dillo won't crash on start, basic browsing works
>
> Committed.
>
>
> There're also:
>
> cookies.c:90: warning: ignoring return value of 'write',
> cookies.c:249: warning: ignoring return value of 'fgets',
> dpid.c:754: warning: ignoring return value of 'write'
> bookmarks.c:696: warning: ignoring return value of 'system'
> bookmarks.c:698: warning: ignoring return value of 'system'
> cookies.c:188: warning: ignoring return value of 'write'
> cookies.c:276: warning: ignoring return value of 'fgets'
> cookies.c:341: warning: ignoring return value of 'fgets'
> cookies.c:428: warning: ignoring return value of 'ftruncate'
> cookies.c:1234: warning: ignoring return value of 'fgets'
> datauri.c:283: warning: ignoring return value of 'chdir'
> ftp.c:280: warning: ignoring return value of 'chdir'
>
> Can you please make a patch for those too?
Attaching the patch.
But few comments first.
cookies.c:
+ rc = fgets(line, LINE_MAXLEN, stream);
+ if (!rc) {
+ MSG("Cookies: Error while reading rule from cookiesrc\n");
+ /* (Partially) corrupted file? Skip this unreadable line */
+ continue;
+ }
The idea was to read all the lines with rules and skip those
unreadable, so we have the rules before and after the unreadable
part. But - can something like this happen? And will it in reality
perform like I expect in the code?
Another quirk I found is that I always receive one this line
at Dillo start:
Cookies: Error while reading rule from cookiesrc
I guess there's some problem with EOF handling.
>
> --
> Cheers
> Jorge.-
>
Michal
> _______________________________________________
> Dillo-dev mailing list
> Dillo-dev@dillo.org
> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
--
Regards,
Michal Nowak
-------------- next part --------------
diff -r 97f3d9265b00 ChangeLog
--- a/ChangeLog Wed Jun 24 12:12:42 2009 -0400
+++ b/ChangeLog Thu Jun 25 20:00:05 2009 +0200
@@ -12,6 +12,9 @@
Added the "nop" keybinding (nop = NO_OPERATION; cancels a default hook).
Patches: place (AKA corvid)
+- Check chdir() return code in Paths::init.
+ - Reduced 'warning: ignoring return value of ...'
+ - Removed return from a_Nav_unref_buf()
+ - Do not build proto.c (file is empty); GCC warning
Patch: Michal Nowak
-----------------------------------------------------------------------------
diff -r 97f3d9265b00 dpi/bookmarks.c
--- a/dpi/bookmarks.c Wed Jun 24 12:12:42 2009 -0400
+++ b/dpi/bookmarks.c Thu Jun 25 20:00:05 2009 +0200
@@ -687,15 +687,30 @@
"grep -i \"href\" %s | "
"sed -e 's// /' -e 's/<.*$//' >> %s";
Dstr *dstr = dStr_new("");
+ int rc = 0;
if (access(BmFile, F_OK) != 0) {
OldBmFile = dStrconcat(dGethomedir(), "/.dillo/bookmarks.html", NULL);
if (access(OldBmFile, F_OK) == 0) {
dStr_sprintf(dstr, cmd1, BmFile);
- system(dstr->str);
+ if (dstr->str) {
+ rc = system(dstr->str);
+ if (rc == 127)
+ MSG("Bookmarks: /bin/sh could not be executed\n");
+ else if (rc == -1)
+ MSG("Bookmarks: process creation failure: %s\n",
+ dStrerror(errno));
+ }
dStr_sprintf(dstr, cmd2, OldBmFile, BmFile);
- system(dstr->str);
+ if (dstr->str) {
+ rc = system(dstr->str);
+ if (rc == 127)
+ MSG("Bookmarks: /bin/sh could not be executed\n");
+ else if (rc == -1)
+ MSG("Bookmarks: process creation failure: %s\n",
+ dStrerror(errno));
+ }
dStr_free(dstr, TRUE);
dFree(OldBmFile);
}
diff -r 97f3d9265b00 dpi/cookies.c
--- a/dpi/cookies.c Wed Jun 24 12:12:42 2009 -0400
+++ b/dpi/cookies.c Thu Jun 25 20:00:05 2009 +0200
@@ -179,13 +179,19 @@
{
FILE *F_in;
int fd;
+ int rc = 0;
if ((F_in = fopen(filename, mode)) == NULL) {
/* Create the file */
fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
if (fd != -1) {
- if (init_str)
- write(fd, init_str, strlen(init_str));
+ if (init_str) {
+ rc = write(fd, init_str, strlen(init_str));
+ if (rc == -1) {
+ MSG("Cookies: Could not write initial string to file %s: %s\n",
+ filename, dStrerror(errno));
+ }
+ }
close(fd);
MSG("Created file: %s\n", filename);
@@ -224,6 +230,7 @@
CookieData_t *cookie;
char *filename;
char line[LINE_MAXLEN];
+ void *rc = NULL;
#ifndef HAVE_LOCKF
struct flock lck;
#endif
@@ -273,7 +280,12 @@
/* Get all lines in the file */
while (!feof(file_stream)) {
line[0] = '\0';
- fgets(line, LINE_MAXLEN, file_stream);
+ rc = fgets(line, LINE_MAXLEN, file_stream);
+ if (!rc) {
+ MSG("Cookies: Error while reading rule from cookiesrc\n");
+ /* (Partially) corrupted file? Skip this unreadable line */
+ continue;
+ }
/* Remove leading and trailing whitespaces */
dStrstrip(line);
@@ -338,7 +350,12 @@
/* Get all lines in the file */
while (!feof(old_cookies_file_stream)) {
line[0] = '\0';
- fgets(line, LINE_MAXLEN, old_cookies_file_stream);
+ rc = fgets(line, LINE_MAXLEN, old_cookies_file_stream);
+ if (!rc) {
+ MSG("Cookies: Error while reading rule from cookiesrc\n");
+ /* (Partially) corrupted file? Skip this unreadable line */
+ continue;
+ }
/* Remove leading and trailing whitespaces */
dStrstrip(line);
@@ -413,6 +430,7 @@
static void Cookies_save_and_free()
{
int i, fd;
+ int rc = 0;
CookieNode *node;
CookieData_t *cookie;
@@ -425,7 +443,9 @@
rewind(file_stream);
fd = fileno(file_stream);
- ftruncate(fd, 0);
+ rc = ftruncate(fd, 0);
+ if (rc == -1)
+ MSG("Cookies: Truncate file stream failed: %s\n", dStrerror(errno));
fprintf(file_stream, "%s", cookies_txt_header_str);
/* Iterate cookies per domain, saving and freeing */
@@ -1218,6 +1238,7 @@
char domain[LINE_MAXLEN];
char rule[LINE_MAXLEN];
int i, j;
+ void *rc = NULL;
bool_t enabled = FALSE;
/* Get a file pointer */
@@ -1231,7 +1252,12 @@
/* Get all lines in the file */
while (!feof(stream)) {
line[0] = '\0';
- fgets(line, LINE_MAXLEN, stream);
+ rc = fgets(line, LINE_MAXLEN, stream);
+ if (!rc) {
+ MSG("Cookies: Error while reading rule from cookiesrc\n");
+ /* (Partially) corrupted file? Skip this unreadable line */
+ continue;
+ }
/* Remove leading and trailing whitespaces */
dStrstrip(line);
diff -r 97f3d9265b00 dpi/datauri.c
--- a/dpi/datauri.c Wed Jun 24 12:12:42 2009 -0400
+++ b/dpi/datauri.c Thu Jun 25 20:00:05 2009 +0200
@@ -275,12 +275,18 @@
{
char *dpip_tag = NULL, *cmd = NULL, *url = NULL, *mime_type;
unsigned char *data;
+ int rc = 0;
size_t data_size = 0;
/* Initialize the SockHandler */
sh = sock_handler_new(STDIN_FILENO, STDOUT_FILENO, 8*1024);
- chdir("/tmp");
+ rc = chdir("/tmp");
+ if (rc == -1) {
+ MSG("paths: error changing directory to /tmp: %s\n",
+ dStrerror(errno));
+ }
+
/* Read the dpi command from STDIN */
dpip_tag = sock_handler_read(sh);
diff -r 97f3d9265b00 dpi/ftp.c
--- a/dpi/ftp.c Wed Jun 24 12:12:42 2009 -0400
+++ b/dpi/ftp.c Thu Jun 25 20:00:05 2009 +0200
@@ -267,6 +267,7 @@
{
char *dpip_tag = NULL, *cmd = NULL, *url = NULL, *url2 = NULL;
int nb;
+ int rc = 0;
char *p, *d_cmd;
/* Debugging with a command line argument */
@@ -277,7 +278,12 @@
sh = sock_handler_new(STDIN_FILENO, STDOUT_FILENO, 8*1024);
/* wget may need to write a temporary file... */
- chdir("/tmp");
+ rc = chdir("/tmp");
+ if (rc == -1) {
+ MSG("paths: error changing directory to /tmp: %s\n",
+ dStrerror(errno));
+ }
+
/* Read the dpi command from STDIN */
if (!dpip_tag)
diff -r 97f3d9265b00 dpid/dpid.c
--- a/dpid/dpid.c Wed Jun 24 12:12:42 2009 -0400
+++ b/dpid/dpid.c Thu Jun 25 20:00:05 2009 +0200
@@ -721,6 +721,7 @@
{
static char *DpiBye_cmd = NULL;
int i, dpi_socket;
+ int rc = 0;
struct sockaddr_un dpi_addr;
struct sockaddr_un sa;
size_t sun_path_len, addr_len;
@@ -751,7 +752,10 @@
ERRMSG("stop_active_dpis", "connect", errno);
MSG_ERR("%s\n", dpi_addr.sun_path);
}
- (void) write(dpi_socket, DpiBye_cmd, strlen(DpiBye_cmd));
+ rc = write(dpi_socket, DpiBye_cmd, strlen(DpiBye_cmd));
+ if (rc == -1)
+ MSG("stop_active_dpis: Error on sending BYE command: %s\n",
+ dStrerror(errno));
a_Misc_close_fd(dpi_socket);
}
}
diff -r 97f3d9265b00 src/IO/Makefile.am
--- a/src/IO/Makefile.am Wed Jun 24 12:12:42 2009 -0400
+++ b/src/IO/Makefile.am Thu Jun 25 20:00:05 2009 +0200
@@ -8,7 +8,6 @@
mime.h \
about.c \
Url.h \
- proto.c \
http.c \
dpi.c \
IO.c \
diff -r 97f3d9265b00 src/cookies.c
--- a/src/cookies.c Wed Jun 24 12:12:42 2009 -0400
+++ b/src/cookies.c Thu Jun 25 20:00:05 2009 +0200
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "msg.h"
#include "IO/Url.h"
@@ -80,13 +81,19 @@
{
FILE *F_in;
int fd;
+ int rc = 0;
if ((F_in = fopen(filename, "r")) == NULL) {
/* Create the file */
fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
if (fd != -1) {
- if (init_str)
- write(fd, init_str, strlen(init_str));
+ if (init_str) {
+ rc = write(fd, init_str, strlen(init_str));
+ if (rc == -1) {
+ MSG("Cookies: Could not write initial string to file %s: %s\n",
+ filename, dStrerror(errno));
+ }
+ }
close(fd);
MSG("Cookies: Created file: %s\n", filename);
@@ -233,6 +240,7 @@
char rule[LINE_MAXLEN];
int i, j;
bool_t enabled = FALSE;
+ void *rc = NULL;
/* Get a file pointer */
filename = dStrconcat(dGethomedir(), "/.dillo/cookiesrc", NULL);
@@ -245,7 +253,12 @@
/* Get all lines in the file */
while (!feof(stream)) {
line[0] = '\0';
- fgets(line, LINE_MAXLEN, stream);
+ rc = fgets(line, LINE_MAXLEN, stream);
+ if (!rc) {
+ MSG("Cookies: Error while reading rule from cookiesrc\n");
+ /* (Partially) corrupted file? Skip this unreadable line */
+ continue;
+ }
/* Remove leading and trailing whitespaces */
dStrstrip(line);
diff -r 97f3d9265b00 src/nav.c
--- a/src/nav.c Wed Jun 24 12:12:42 2009 -0400
+++ b/src/nav.c Thu Jun 25 20:00:05 2009 +0200
@@ -597,5 +597,5 @@
*/
void a_Nav_unref_buf(const DilloUrl *Url)
{
- return a_Capi_unref_buf(Url);
+ a_Capi_unref_buf(Url);
}
From corvid at lavabit.com Thu Jun 25 21:20:27 2009
From: corvid at lavabit.com (corvid)
Date: Thu Jun 25 21:23:28 2009
Subject: [Dillo-dev] [PATCH] warning: ignoring return value of ???int
chdir(const char*)???
In-Reply-To: <20090625183644.GA2779@assam.lab.eng.brq.redhat.com>
References: <20090624090326.GA2865@assam.Belkin>
<20090624162011.GC3858@dillo.org>
<20090625183644.GA2779@assam.lab.eng.brq.redhat.com>
Message-ID: <20090625192027.GV6014@local.gobigwest.com>
Michal wrote:
> cookies.c:
> + rc = fgets(line, LINE_MAXLEN, stream);
> + if (!rc) {
> + MSG("Cookies: Error while reading rule from cookiesrc\n");
> + /* (Partially) corrupted file? Skip this unreadable line */
> + continue;
> + }
>
> The idea was to read all the lines with rules and skip those
> unreadable, so we have the rules before and after the unreadable
> part. But - can something like this happen? And will it in reality
> perform like I expect in the code?
>
> Another quirk I found is that I always receive one this line
> at Dillo start:
>
> Cookies: Error while reading rule from cookiesrc
>
> I guess there's some problem with EOF handling.
I think I would just loop while the return from fgets() > 0
and then give an error if ferror(stream) is nonzero.
From jcid at dillo.org Sat Jun 27 04:43:04 2009
From: jcid at dillo.org (Jorge Arellano Cid)
Date: Sat Jun 27 04:43:22 2009
Subject: [Dillo-dev] [PATCH] warning: ignoring return value of ???int
chdir(const char*)???
In-Reply-To: <20090625192027.GV6014@local.gobigwest.com>
References: <20090624090326.GA2865@assam.Belkin>
<20090624162011.GC3858@dillo.org>
<20090625183644.GA2779@assam.lab.eng.brq.redhat.com>
<20090625192027.GV6014@local.gobigwest.com>
Message-ID: <20090627024304.GJ13779@dillo.org>
On Thu, Jun 25, 2009 at 07:20:27PM +0000, corvid wrote:
> Michal wrote:
> > cookies.c:
> > + rc = fgets(line, LINE_MAXLEN, stream);
> > + if (!rc) {
> > + MSG("Cookies: Error while reading rule from cookiesrc\n");
> > + /* (Partially) corrupted file? Skip this unreadable line */
> > + continue;
> > + }
> >
> > The idea was to read all the lines with rules and skip those
> > unreadable, so we have the rules before and after the unreadable
> > part. But - can something like this happen? And will it in reality
> > perform like I expect in the code?
> >
> > Another quirk I found is that I always receive one this line
> > at Dillo start:
> >
> > Cookies: Error while reading rule from cookiesrc
> >
> > I guess there's some problem with EOF handling.
>
> I think I would just loop while the return from fgets() > 0
> and then give an error if ferror(stream) is nonzero.
Committed with modifications.
Please check it.
--
Cheers
Jorge.-
From jorl17.8 at gmail.com Tue Jun 30 23:43:26 2009
From: jorl17.8 at gmail.com (=?ISO-8859-1?Q?Jo=E3o?= Ricardo =?ISO-8859-1?Q?Louren=E7o?=)
Date: Tue Jun 30 23:55:18 2009
Subject: [Dillo-dev] Feels good to be free. Close-tab button.
Message-ID: <1246398206.13209.105.camel@jorl17-laptop>
Well, I promised I would report to you when I got more free time. Guess
what, I'm on vacation! Getting free time from my own personal projects
finally lets me take a closer look at Dillo. I am sorry for being away
for such a long time, though.
I would like to contribute to one area that I have contributed
previously -- the close-tab button. It isn't critical, I know, but, for
now, it's the best I can do. The idea now is to finally have a button in
each tab.
It is tough, but I am getting somewhere. The 'initial' drawing part is
done, but I have had to make some small changes to some virtual
functions, and also changing non-virtual functions and finding a way to
'enable' them in the code.
It's pretty hackish right now, but I have managed to print the button
and am now starting to handle all the events and different button states
(clicked, over, etcetera).
I'll keep you updated!
Jo?o
| | |