- Dillo-dev - lists.mailman3.com

a list of what dillo2 runs on

by ljmoore＠wightman.ca

On Tue, Aug 26, 2008 at 05:52:43PM +0000, corvid wrote: > Christopher Illies wrote: > > On Mon, Aug 25, 2008 at 04:14:34PM +0000, corvid wrote: > > > I wonder whether we could get someone for each system who > > > would have the responsibility (or, let's say "_glory_" :) > > > of responding to "Hey, we changed [some configuration stuff] > > > in the latest CVS. Does it work fine on your system?" messages. > > > > I can take that part for FreeBSD for now and will respond when such > > messages are posted to this list. Also, I can do a fresh compile every > > two weeks or so. > > Cool! > > My system isn't representative of any mainstream (debian on a m68k ) but will download from cvs, compile and soforth when prompted. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- People who think they know everything are a great annoyance to those of us who do. Isaac Asimov

Nov. 20, 2008

Feature Request

by jcid＠dillo.org

On Tue, Nov 18, 2008 at 10:32:13AM -0500, me at swva wrote: > On Tue, 18 Nov 2008, Jorge Arellano Cid wrote: > >> >> On Fri, Nov 14, 2008 at 01:21:17PM -0500, me at swva wrote: >>>> >>>> The URL viewer is taken from .mailcap. When set properly, it >>>> works (at least here it works with Ubuntu 8.04.1, so it's not an >>>> alpine issue). >>> >>> OK, good; but you're over my head. I don't find anything named >>> .mailcap on my machine. Neither does my search function. >>> >>> Since I've been running Pine for years, I have a .pinerc rather >>> than an .alpinerc; but I don't find anything like what you say there, >>> either. >> >> You can create it in your home account. >> >> nano -w ~/.mailcap >> >> then put the long line there, and see what happens. > > I did, and it didn't; but I may have the long line wrong, since it's > formatted into two here. I tried it (on my own machine here, not the > remote one yet) both with and without a space between the backslash and > "test=test" (having done c&p on the two pieces). Are there really > supposed to be two spaces between the last semicolon and "nametemplate"? The backslash doesn't go in the line. It's a convention to mark a single line when split in two. The .mailcap should go in the same machine where alpine runs. -- Cheers Jorge.-

Nov. 18, 2008

Feature Request

by Beartooth＠swva.net

On Tue, 18 Nov 2008, Jorge Arellano Cid wrote: > > On Fri, Nov 14, 2008 at 01:21:17PM -0500, me at swva wrote: >>> >>> The URL viewer is taken from .mailcap. When set properly, it >>> works (at least here it works with Ubuntu 8.04.1, so it's not an >>> alpine issue). >> >> OK, good; but you're over my head. I don't find anything >> named .mailcap on my machine. Neither does my search function. >> >> Since I've been running Pine for years, I have a .pinerc >> rather than an .alpinerc; but I don't find anything like what you >> say there, either. > > You can create it in your home account. > > nano -w ~/.mailcap > > then put the long line there, and see what happens. I did, and it didn't; but I may have the long line wrong, since it's formatted into two here. I tried it (on my own machine here, not the remote one yet) both with and without a space between the backslash and "test=test" (having done c&p on the two pieces). Are there really supposed to be two spaces between the last semicolon and "nametemplate"? >>> If you have something like this in your mailcap: >>> (all in one line) >>> >>> text/html; /usr/local/bin/dillo -l -f '%s'; description=HTML Text; \ >>> test=test -n "$DISPLAY"; nametemplate=%s.html >>> >>> it works with dillo1. >> >> About now, I should probably mention that I do my email >> different ways from different addresses. The main one is remote. >> It does open links that include "http://" -- in dillo *here*, not >> on the remote machine -- but not ones without. The same is also >> true when I run Alpine against the address I'm using at this >> moment. > > Probably you use something like: > > ssh -X <remote_machine> > > it should work OK. > I'll try that next. >>> Something like: >>> >>> text/html; /usr/local/bin/dillo -l -f -x XID '%s'; description=HTML Text; \ >>> test=test -n "$DISPLAY"; nametemplate=%s.html >> >> I'm guessing that I should c&p that into my .pinerc >> somewhere, or into the interface Alpine gives me by typing M > S >> > C (Main menu to Setup to Configure); but I don't know where. [....] >> Now you're way to Helen Gone over my head. Sorry. > > Never mind, just try the .mailcap suggestion above. -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 18, 2008

Feature Request

by jcid＠dillo.org

On Fri, Nov 14, 2008 at 01:21:17PM -0500, me at swva wrote: > On Tue, 11 Nov 2008, Jorge Arellano Cid wrote: > [...] >> I ended installing alpine here to check this issue. >> >> The URL viewer is taken from .mailcap. When set properly, it >> works (at least here it works with Ubuntu 8.04.1, so it's not an >> alpine issue). > > OK, good; but you're over my head. I don't find anything > named .mailcap on my machine. Neither does my search function. > > Since I've been running Pine for years, I have a .pinerc > rather than an .alpinerc; but I don't find anything like what > you say there, either. You can create it in your home account. nano -w ~/.mailcap then put the long line there, and see what happens. >> If you have something like this in your mailcap: >> (all in one line) >> >> text/html; /usr/local/bin/dillo -l -f '%s'; description=HTML Text; \ >> test=test -n "$DISPLAY"; nametemplate=%s.html >> >> it works with dillo1. > > About now, I should probably mention that I do my email different ways > from different addresses. The main one is remote. It does open links that > include "http://" -- in dillo *here*, not on the remote machine -- but > not ones without. The same is also true when I run Alpine against the > address I'm using at this moment. Probably you use something like: ssh -X <remote_machine> it should work OK. >> Something like: >> >> text/html; /usr/local/bin/dillo -l -f -x XID '%s'; description=HTML Text; \ >> test=test -n "$DISPLAY"; nametemplate=%s.html > > I'm guessing that I should c&p that into my .pinerc somewhere, or into > the interface Alpine gives me by typing M > S > C (Main menu to Setup to > Configure); but I don't know where. > >> makes dillo1 exit, so it doesn't work. >> Reason: XID should be a number containing a window ID, where dillo should >> embed itself, not a literal string! > > Now you're way to Helen Gone over my head. Sorry. Never mind, just try the .mailcap suggestion above. -- Cheers Jorge.-

Nov. 18, 2008

RE: what dillo2 runs on.

by CHalbersma.12＠westminster-mo.edu

I've been able to get dillo2 to compile and run on a Damn Small Linux box. Obviously you need to compile fltk2 first but dillo2 seems to run although it does have some troubles. As soon as I find them I hope to be able to post a DSL package. CRH On Mon, Aug 18, 2008 at 02:24:21AM +0000, corvid wrote: > I want to get the status of everything in order to update > http://www.dillo.org/Compatibility.html for dillo2. > > Linux x86 - works > DragonFlyBSD - works > > Linux x86-64 - Justus was and is making snapshots, but I don't know whether > he uses them much. > Solaris 10 - Justus reported that it was running, but I believe it was just > a quick test. > OSX - Jorge reports that it works but is currently flaky. > > *BSD - Some of the mailing list traffic in October was devoted to getting > them working. Presumably it would have been mentioned here if they > had stopped working since, but... > > other - no idea. > > Looking back at what I just wrote, let me clarify that I meant that > dillo2-on-osx is flaky, not that Jorge is flaky :) > Debian Linux m68k works (cvs 14 Nov 2008) -- Qne's mind, once stretched by a new idea, never regains its original dimensions. -Oliver Wendell Holmes

Nov. 17, 2008

a list of what dillo2 runs on

by hparad＠web.de

hi tested dillo 2.0 on debian-arm on Linksys Nslu2 (without ssl) there is also a debian_arm package based on the sources from Andreas with some changes at http://hparadies.homepage.t-online.de/ Gruss Holger

Nov. 17, 2008

a list of what dillo2 runs on

by james＠bsdgroup.org

On Sun, Nov 16, 2008 at 09:30:48PM +0100, Johannes Hofmann wrote: > On Sun, Nov 16, 2008 at 09:23:56AM -0800, bf wrote: > > > > > > > > --- On Sun, 11/16/08, Larry Moore <ljmoore(a)wightman.ca> wrote: > > > > > From: Larry Moore <ljmoore(a)wightman.ca> > > > Subject: Re: [Dillo-dev] a list of what dillo2 runs on > > > To: dillo-dev(a)dillo.org > > > Date: Sunday, November 16, 2008, 7:27 AM > > > On Mon, Aug 18, 2008 at 02:24:21AM +0000, corvid wrote: > > > > I want to get the status of everything in order to > > > update > > > > http://www.dillo.org/Compatibility.html for dillo2. > > > > > > > > Linux x86 - works > > > > DragonFlyBSD - works > > > > > > > > Linux x86-64 - Justus was and is making snapshots, but > > > I don't know whether > > > > he uses them much. > > > > Solaris 10 - Justus reported that it was running, but > > > I believe it was just > > > > a quick test. > > > > OSX - Jorge reports that it works but is currently > > > flaky. > > > > > > > > *BSD - Some of the mailing list traffic in October was > > > devoted to getting > > > > them working. Presumably it would have been > > > mentioned here if they > > > > had stopped working since, but... > > > > > > > > Both the release tarball and recent CVS snapshots build and run without any > > apparent problems on FreeBSD 7-STABLE i386 (and probably other versions as > > well ... ). The new dillo will be included in FreeBSD Ports soon: it has > > been delayed owing to the Ports freeze before the release of FreeBSD > > 6.4/7.1, and to some confusion among Ports maintainers about who was going > > to be responsible for it. You can find a proposed Port at: > > > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/128139 > > > > Presumably NetBSD will put it in pkgsrc soon: > > > > http://pkgsrc.se/wip/dillo2 > > It's in cvs already: > http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/www/dillo/Makefile > > Cheers, > Johannes OpenBSD also has the new dillo in it's ports tree along with fltk2. -- James Turner BSD Group Consulting http://www.bsdgroup.org

Nov. 16, 2008

a list of what dillo2 runs on

by Johannes.Hofmann＠gmx.de

On Sun, Nov 16, 2008 at 09:23:56AM -0800, bf wrote: > > > > --- On Sun, 11/16/08, Larry Moore <ljmoore(a)wightman.ca> wrote: > > > From: Larry Moore <ljmoore(a)wightman.ca> > > Subject: Re: [Dillo-dev] a list of what dillo2 runs on > > To: dillo-dev(a)dillo.org > > Date: Sunday, November 16, 2008, 7:27 AM > > On Mon, Aug 18, 2008 at 02:24:21AM +0000, corvid wrote: > > > I want to get the status of everything in order to > > update > > > http://www.dillo.org/Compatibility.html for dillo2. > > > > > > Linux x86 - works > > > DragonFlyBSD - works > > > > > > Linux x86-64 - Justus was and is making snapshots, but > > I don't know whether > > > he uses them much. > > > Solaris 10 - Justus reported that it was running, but > > I believe it was just > > > a quick test. > > > OSX - Jorge reports that it works but is currently > > flaky. > > > > > > *BSD - Some of the mailing list traffic in October was > > devoted to getting > > > them working. Presumably it would have been > > mentioned here if they > > > had stopped working since, but... > > > > > Both the release tarball and recent CVS snapshots build and run without any > apparent problems on FreeBSD 7-STABLE i386 (and probably other versions as > well ... ). The new dillo will be included in FreeBSD Ports soon: it has > been delayed owing to the Ports freeze before the release of FreeBSD > 6.4/7.1, and to some confusion among Ports maintainers about who was going > to be responsible for it. You can find a proposed Port at: > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/128139 > > Presumably NetBSD will put it in pkgsrc soon: > > http://pkgsrc.se/wip/dillo2 It's in cvs already: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/www/dillo/Makefile Cheers, Johannes

Nov. 16, 2008

a list of what dillo2 runs on

by bf2006a＠yahoo.com

--- On Sun, 11/16/08, Larry Moore <ljmoore(a)wightman.ca> wrote: > From: Larry Moore <ljmoore(a)wightman.ca> > Subject: Re: [Dillo-dev] a list of what dillo2 runs on > To: dillo-dev(a)dillo.org > Date: Sunday, November 16, 2008, 7:27 AM > On Mon, Aug 18, 2008 at 02:24:21AM +0000, corvid wrote: > > I want to get the status of everything in order to > update > > http://www.dillo.org/Compatibility.html for dillo2. > > > > Linux x86 - works > > DragonFlyBSD - works > > > > Linux x86-64 - Justus was and is making snapshots, but > I don't know whether > > he uses them much. > > Solaris 10 - Justus reported that it was running, but > I believe it was just > > a quick test. > > OSX - Jorge reports that it works but is currently > flaky. > > > > *BSD - Some of the mailing list traffic in October was > devoted to getting > > them working. Presumably it would have been > mentioned here if they > > had stopped working since, but... > > Both the release tarball and recent CVS snapshots build and run without any apparent problems on FreeBSD 7-STABLE i386 (and probably other versions as well ... ). The new dillo will be included in FreeBSD Ports soon: it has been delayed owing to the Ports freeze before the release of FreeBSD 6.4/7.1, and to some confusion among Ports maintainers about who was going to be responsible for it. You can find a proposed Port at: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/128139 Presumably NetBSD will put it in pkgsrc soon: http://pkgsrc.se/wip/dillo2 so that it will be available there and on DragonFlyBSD. Ditto for OpenBSD: http://www.mail-archive.com/ports@openbsd.org/msg19098.html (follow-up messages include a patch for machines without ipv6 that you may want to consider) but as they have fewer resources and are cautious about adopting software, it may be a bit longer. Regards, b.

Nov. 16, 2008

a list of what dillo2 runs on

by nikai＠nikai.net

* Larry Moore <ljmoore(a)wightman.ca>: > On Mon, Aug 18, 2008 at 02:24:21AM +0000, corvid wrote: > > I want to get the status of everything in order to update > > http://www.dillo.org/Compatibility.html for dillo2. Linux ppc (Gentoo) is working nicely at my place, see http://bugs.gentoo.org/show_bug.cgi?id=242774 Thanks a lot for this excellent browser! Cheers, Nicolas Kaiser

Nov. 16, 2008

a list of what dillo2 runs on

by ljmoore＠wightman.ca

On Mon, Aug 18, 2008 at 02:24:21AM +0000, corvid wrote: > I want to get the status of everything in order to update > http://www.dillo.org/Compatibility.html for dillo2. > > Linux x86 - works > DragonFlyBSD - works > > Linux x86-64 - Justus was and is making snapshots, but I don't know whether > he uses them much. > Solaris 10 - Justus reported that it was running, but I believe it was just > a quick test. > OSX - Jorge reports that it works but is currently flaky. > > *BSD - Some of the mailing list traffic in October was devoted to getting > them working. Presumably it would have been mentioned here if they > had stopped working since, but... > > other - no idea. > > Looking back at what I just wrote, let me clarify that I meant that > dillo2-on-osx is flaky, not that Jorge is flaky :) > Debian Linux m68k works (cvs 14 Nov 2008) -- Qne's mind, once stretched by a new idea, never regains its original dimensions. -Oliver Wendell Holmes

Nov. 16, 2008

Strange mouse/keyboard issues

by theman＠eradman.com

On 15:30 Fri 14 Nov , James Turner wrote: > > The second issue involves running dillo with dwm in one tag then > switching to another tag and then back again. This time keystrokes seem > to get lost. To fix this problem I have to toggle the dwm meta key (in > my case this is the windows key, but it could be ctrl or alt instead). > > Has anyone else seen similar issues? Thanks. I'm using Dillo 2.0 with dwm-5.2 without any such issue. -- Eric Radman | http://eradman.com

Nov. 15, 2008

Strange mouse/keyboard issues

by james＠bsdgroup.org

Hello everyone, I have two somewhat similar issues related to dillo and losing keyboard/mouse focus. This could be an issue with fltk2. The first involves mouse clicks registering on different buttons. When running e17 if you start dillo in one virtual screen then switch to another and then back again, when you a user tried to click the back button instead the forward/home button was highlighted. The problem was fixed by forcing the dillo window to redraw. The second issue involves running dillo with dwm in one tag then switching to another tag and then back again. This time keystrokes seem to get lost. To fix this problem I have to toggle the dwm meta key (in my case this is the windows key, but it could be ctrl or alt instead). Has anyone else seen similar issues? Thanks. -- James Turner BSD Group Consulting http://www.bsdgroup.org

Nov. 14, 2008

Feature Request

by Beartooth＠swva.net

On Tue, 11 Nov 2008, Jorge Arellano Cid wrote: [...] > I ended installing alpine here to check this issue. > > The URL viewer is taken from .mailcap. When set properly, it > works (at least here it works with Ubuntu 8.04.1, so it's not an > alpine issue). OK, good; but you're over my head. I don't find anything named .mailcap on my machine. Neither does my search function. Since I've been running Pine for years, I have a .pinerc rather than an .alpinerc; but I don't find anything like what you say there, either. > If you have something like this in your mailcap: > (all in one line) > > text/html; /usr/local/bin/dillo -l -f '%s'; description=HTML Text; \ > test=test -n "$DISPLAY"; nametemplate=%s.html > > it works with dillo1. About now, I should probably mention that I do my email different ways from different addresses. The main one is remote. It does open links that include "http://" -- in dillo *here*, not on the remote machine -- but not ones without. The same is also true when I run Alpine against the address I'm using at this moment. > Something like: > > text/html; /usr/local/bin/dillo -l -f -x XID '%s'; description=HTML Text; \ > test=test -n "$DISPLAY"; nametemplate=%s.html I'm guessing that I should c&p that into my .pinerc somewhere, or into the interface Alpine gives me by typing M > S > C (Main menu to Setup to Configure); but I don't know where. > makes dillo1 exit, so it doesn't work. > Reason: XID should be a number containing a window ID, where dillo should > embed itself, not a literal string! Now you're way to Helen Gone over my head. Sorry. > Note: dillo2 will work with the flawed parameter because as it can't > embed itself yet, the parameter is blithely ignored! :-) -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 14, 2008

more css progress

by Johannes.Hofmann＠gmx.de

Hi, the dillo-css-prototype is now able to parse a user stylesheet from ~/.dillo/style.css if it exists. This allows to modify the appearance in various ways. Currently I have the following in my ~/.dillo/style.css: body {margin-left: 10mm; margin-top: 10mm; background-color: #F5F5F5;} :link {color: gray !important; text-decoration: none; font-weight: bolder; } :visited {color: olive !important; text-decoration: none; font-weight: bolder; } Note that I'm no designer so the result may hurt your eyes! Cheers, Johannes

Nov. 13, 2008

css progress

by Johannes.Hofmann＠gmx.de

Hi, I just pushed my latest changes to the css prototype repository. The css parser from dillo-0.8.0-css-3 is now integrated and working. The user agent style is parsed from a char buffer (see CssContext::buildUserAgentStyle() in css.cc). Of course the code is still full of bugs and missing stuff, but it shows that things basically work as expected. This is starting to be fun! Cheers, Johannes

Nov. 12, 2008

experimental patch: Re: dillo2 wrapping Chinese

by furaisanjin＠gmail.com

2008/11/12 corvid <corvid(a)lavabit.com>: > What happens to the tables? > (It's hard for me to tell when something is bad > since the characters are just shapes to me.) Here are 2 png pictures when I visit http://ja.wikipedia.org This is from original dillo2.0. http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/1-02b9e.… Red surrounded part has a long line without line break and it doesn't fit on page width. This is from modified dillo2.0. http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/2.png Blue surrounded part is table and rows are really narrow. Regards, furaisanjin

Nov. 12, 2008

experimental patch: Re: dillo2 wrapping Chinese

by corvid＠lavabit.com

furaisanjin wrote: > 2008/11/12 corvid <corvid(a)lavabit.com>: > > dillo people: It turns out that dillo handles Chinese quite badly because the > > text doesn't contain whitespace (BUG 827). It looks like Japanese is that > > way as well. > > Yes, dillo doesn't handle Japanese either when a line is long and > doesn't have break on it. > > I modified html_process_word so that each Japanese word is added by > addText. In this way appearance is better but sometimes table looks > bad. What happens to the tables? (It's hard for me to tell when something is bad since the characters are just shapes to me.)

Nov. 12, 2008

experimental patch: Re: dillo2 wrapping Chinese

by furaisanjin＠gmail.com

Hello corvid, 2008/11/12 corvid <corvid(a)lavabit.com>: > dillo people: It turns out that dillo handles Chinese quite badly because the > text doesn't contain whitespace (BUG 827). It looks like Japanese is that > way as well. Yes, dillo doesn't handle Japanese either when a line is long and doesn't have break on it. I modified html_process_word so that each Japanese word is added by addText. In this way appearance is better but sometimes table looks bad. Regards, furaisanjin

Nov. 11, 2008

experimental patch: Re: dillo2 wrapping Chinese

by corvid＠lavabit.com

dillo people: It turns out that dillo handles Chinese quite badly because the text doesn't contain whitespace (BUG 827). It looks like Japanese is that way as well. 1) People using East Asian languages: Does this do roughly the right thing? I've read that there are picky rules about certain individual characters, but I just mean in general here. 2) Thoughts on optimization are welcomed. littlebat: For some reason, I was thinking that whitespace was required between words in dillo, but I misremembered. littlebat wrote: > Hi, > Thanks for the work on Dillo. > > I think it isn't a good idea to resolve long chinese line wrapping > problem by inserting space after punctuation mark("?" or "?" or "?", > etc..). > > Here is a "Dillo2 Wrap Long Chinese Line Test" page: > http://www.learndiary.com/en/dillo2-wrap-long-chinese-line-test.htm . > Open it with Firefox or IE, then open it with Dillo2, You will see the > different of wrapping long chinese line between them. > > Note, unlike english, there is no space between Chinese characters. So, > it should be wrapped after any Chinese character which has reached the > end of a line. I don't know the technique detail about this, but, I > think, let the Chinese characters function as (english) commas or > periods is a good idea, so, a new line can be started after any Chinese > charcter which character has reached the end of a line. > > littlebat > > http://www.learndiary.com/en/ > > > corvid wrote: > >Would it make things better or worse than it is now if I inserted a > >space when encountering a "?" or "?" so that dillo would know > >that it can wrap there? If that doesn't show up properly, > >I mean the characters that function as commas and periods. > > > >(I'm trying to think of something simple that will at least help you > > somewhat without having to make big changes right now :) > > I realize that it _should_ be able to wrap after most CJK characters, > > but...) > > > >It could be worse because > >1) Those spaces would still be there if you were copying and pasting > > the text to something else. > >2) If you wanted to search a page for "text?text", you would have to > > enter "text? text" with a space in there.

Nov. 11, 2008

Feature Request

by jcid＠dillo.org

On Sun, Nov 09, 2008 at 10:27:11AM -0500, me at swva wrote: > On Sun, 9 Nov 2008, Jorge Arellano Cid wrote: > >>> I don't thing it will be that hard to get FLTK & Dillo2 into Fedora, >>> the thing is that no one did it till now :). (And I ma pretty busy at >>> work & uni :) ). >> >> Thanks a lot for the explanation! >> >> Although it may be difficult to get a FLTK2 package in the distro >> because FLTK2 doesn't have a stable release yet. I mean, if policies >> mandate not to include alpha or beta libraries, we're out... >> >> It'd be good to know this (for Fedora, Ubuntu and Debian at least). >> That way we can ask the FLTK team about their schedule plans. > > I hate to be taking up so much time from people I know are working so > hard already, but let me ask just one more : should I be taking this up > with Alpine people? Or is one of you going to do that? (You could > certainly do it a lot better.) Or have you determined that the trouble is > in Fedora and not in Alpine? I ended installing alpine here to check this issue. The URL viewer is taken from .mailcap. When set properly, it works (at least here it works with Ubuntu 8.04.1, so it's not an alpine issue). If you have something like this in your mailcap: (all in one line) text/html; /usr/local/bin/dillo -l -f '%s'; description=HTML Text; \ test=test -n "$DISPLAY"; nametemplate=%s.html it works with dillo1. Something like: text/html; /usr/local/bin/dillo -l -f -x XID '%s'; description=HTML Text; \ test=test -n "$DISPLAY"; nametemplate=%s.html makes dillo1 exit, so it doesn't work. Reason: XID should be a number containing a window ID, where dillo should embed itself, not a literal string! Note: dillo2 will work with the flawed parameter because as it can't embed itself yet, the parameter is blithely ignored! :-) HTH. -- Cheers Jorge.-

Nov. 11, 2008

the Http_must_use_proxy change in CVS

by jcid＠dillo.org

On Tue, Nov 11, 2008 at 12:00:29AM +0000, corvid wrote: > Is something missing? I miss some rest! :-) > It gives me a warning because we're sending it a char* now. My fault, this is a bug! I was working on an old patch and made the mistake. David: the problem was that the no_proxy preference had whitespace around the equal sign in dillorc. The current CVS extends the parser to accept this syntax. Please test and send feedback. The other patch "worked" by chance ;). -- Cheers Jorge.-

Nov. 11, 2008

Greetings! -- With Patches :-)

by jcid＠dillo.org

On Mon, Nov 10, 2008 at 11:09:16AM -0800, J.C. Roberts wrote: > On Mon, 10 Nov 2008 15:08:43 -0300 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > [...] > > This raises an interesting issue. > > > > It may be necessary to add "ui_font_factor" to dillorc. > > > > With the patch "as is" things get broken here. The popup menus > > get incomplete titles. > > > > By this I assume you mean the text with the new/larger font size in the > title/label on the popup menus does not fit within the provided space? Yes. > [...] > I remember reading in the fltk docs about a member function to > calculate X,Y size but since dillo is my first adventure into fltk, I > simply cannot recall the function name. --It's one of those "I know I > saw it... but where the heck did I see it?" type of things. ;-) measure(). IIRC, used in: the progress widgets, the download dpi, others. > > Looking at the result, I realized my personal preference is to > > have smaller fonts in the UI, than in rendered pages. This led me > > to the "ui_font_factor" solution. > > > > CVS has now a similar patch that doesn't scale the font > > (submitted by corvid some time ago). > > > > It'd be good to have a patch that takes all the UI elements > > into account. Unfortunately, a patch that scales UI fonts may > > also need to scale the UI panel and this could take some effort. > > > > Scaling the UI font without scaling the UI panel may be easier, > > and also serve the purpose. > > > > Keeping the UI usable/readable across a multitude of systems and > configurations is a different problem than keeping the displayed web > pages usable/readable. It's best to address each problem individually, > rather than lumping them together. That's what I meant. > Though it would be a serious change, and require a lot of patching, I > think the best solution is to have a two pronged approach: > > 1.) Font Factor (scaling) > 2.) Font Size > > If only Font_Size is stated, it would be used verbatim. > If only Font_Factor is stated, it would scale the font. > if both were stated, Font_Factor would take precedence. > > This would give you prefs for: > > vw_font_name > vw_font_size > vw_font_factor > > ui_font_name > ui_font_size > ui_font_factor Looks OK. Code for handling those extra prefs is OK. Lots of code to recalculate widget sizes to acomodate larger fonts in the UI is not the goal. Simple code that solves the problem is welcomed. > Ummm... with all due respect, I think the currently used "fontname" in > the prefs is against the coding conventions stated on the dillo site. > Of course, it really doesn't matter to a compiler, but if I'm going to > dig into augmenting this code, I need to know the "right" (TM)(C)(R) > way to fix it. :-) Sorry, I don't understand. -- Cheers Jorge.-

Nov. 11, 2008

the Http_must_use_proxy change in CVS

by corvid＠lavabit.com

Is something missing? It gives me a warning because we're sending it a char* now.

Nov. 11, 2008

Re: patch: middle-click submits in new window/tab

by corvid＠lavabit.com

Jorge wrote: > Corvid: please explain me a bit about: > > * The patch changes from "Activate" to "Clicked" signal. Partly because it was a click that's passing button stuff, and partly because I may want to experiment with sending right-click through someday for a form menu. > * It also seems to change the logic in DilloHtmlInput::activate() > - it makes me wonder whether pressing enter on other form widgets > may submit. text/password/isindex can, but textarea won't (no connectActivate). > + fix gcc error and re-submit a patch. I guess I'll go back and make a little thing for the button state to live in as well.

Nov. 10, 2008

Re: patch: middle-click submits in new window/tab

by jcid＠dillo.org

On Mon, Nov 10, 2008 at 07:01:21PM +0100, Johannes Hofmann wrote: > On Mon, Nov 10, 2008 at 02:36:48PM -0300, Jorge Arellano Cid wrote: > > On Mon, Oct 20, 2008 at 02:49:41PM +0000, corvid wrote: > > > I could say that it was for the sake of consistency with link behavior, > > > but really it was because it seemed like a dilloishly simple way > > > to get the equivalent of pages-remember-form-data. > > > > The consistency part is a strong argument. > > > > Also interesting is the way we can have a workaround to > > remember form data, before a more usual way of handling it is > > implemented. > > > > > > > > (But: who will ever discover that it exists or recognize what it > > > makes possible?) > > > > It may be stated in the FAQ. > > > > > > > 1) fltkui: it might be better to stuff all of the button event stuff > > > into a bag like fltkviewbase/layout do with EventButton. It certainly > > > looks nicer having something like a shift mask hidden away in a nice > > > tidy box, but I wasn't sure that it was actually worth doing. > > > > Hmm, I'd say if it's going to be a definitive patch, it's > > worth the effort. > > > > > 2) form: carrying around buttonNo+shifted for a long time > > > is not pleasing, but oh well. > > > > Agreed. > > > > > > Now that Johannes is interested in implementing FORM "memory", > > I'd say it can be stored in an URL/form-data array. I haven't > > checked how other browsers (e.g. FF) solve the problem of privacy > > (aka. when it's desirable to remember data), but most probably a > > quick look will shed some light. > > > > BTW, I can't compile the patch here because: > > > > make[2]: Entering directory `/home/jcid/C/Dillo/d2/dillo2-cur/test' > > form.cc: In member function 'void form::Form::addButtonResource(const char*, > > dw::core::ui::ButtonResource*, const char*)': > > form.cc:241: error: cannot allocate an object of abstract type > > 'form::Form::FormClickedReceiver' > > form.hh:124: note: because the following virtual functions are pure within > > 'form::Form::FormClickedReceiver': > > ../dw/ui.hh:338: note: virtual void > > dw::core::ui::ButtonResource::ClickedReceiver::clicked(dw::core::ui::ButtonReso > > urce*, int, int) > > make[2]: *** [form.o] Error 1 > > make[2]: Leaving directory `/home/jcid/C/Dillo/d2/dillo2-cur/test' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/jcid/C/Dillo/d2/dillo2-cur' > > > > > > > > BTW2: > > > > * The patch changes from "Activate" to "Clicked" signal. > > * It also seems to change the logic in DilloHtmlInput::activate() > > - it makes me wonder whether pressing enter on other form widgets > > may submit. > > > > Anyway, it'd be good if you can coordinate with Johannes and decide what > > approach to take, and send a new patch for it. I'd prefer Johannes to keep > > working in the CSS front, and you to make the definitive patch, but this > > is for you guys to decide. > > I won't start on any new stuff (other than CSS) in the near future. > Currently I'm trying to convert the table code to the new style > handling which is a bit hairy but there are no major obstacles yet. > > And I really like the middle-click to submit thing. So I don't have > a lot of motivation to implement real form data remembering anyway. Great! Corvid: please explain me a bit about: * The patch changes from "Activate" to "Clicked" signal. * It also seems to change the logic in DilloHtmlInput::activate() - it makes me wonder whether pressing enter on other form widgets may submit. + fix gcc error and re-submit a patch. -- Cheers Jorge.-

Nov. 10, 2008

Greetings! -- With Patches :-)

by list-jcr＠designtools.org

On Mon, 10 Nov 2008 15:08:43 -0300 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > [...] > > The first is to fix an over-sight in the following post/patch > > posted to this mailing list: > > http://article.gmane.org/gmane.comp.web.dillo.devel/6248 > > > > The above patch does not take into consideration font size, so > > the result can be microscopic/unreadable fonts. I've added the > > code to scale the font in the same way as you scale other fonts > > in dillo. Though I've read enough of the dillo docs and code to > > grasp the basics of formatting, I'm unsure if my formatting of > > the continuation (split line) is "correct" according to your > > standards. > > > > There are other places in the dillo UI where font handling is > > still incorrect and can result in unreadable fonts. Some of this > > is the fault of fltk, since as far as I know there is no ~/.gtkrc > > equivalent to set defaults for the tool kit. With luck, I'll find > > and fix them. > > This raises an interesting issue. > > It may be necessary to add "ui_font_factor" to dillorc. > > With the patch "as is" things get broken here. The popup menus > get incomplete titles. > By this I assume you mean the text with the new/larger font size in the title/label on the popup menus does not fit within the provided space? I saw this behavior as well. The fact things work without the patch is really a matter of luck, and not a matter of correctness. The correct way to deal with it is to always calculate the size of the text string (with the specified font), and adjust the size of the label/title accordingly. I remember reading in the fltk docs about a member function to calculate X,Y size but since dillo is my first adventure into fltk, I simply cannot recall the function name. --It's one of those "I know I saw it... but where the heck did I see it?" type of things. ;-) > Looking at the result, I realized my personal preference is to > have smaller fonts in the UI, than in rendered pages. This led me > to the "ui_font_factor" solution. > > CVS has now a similar patch that doesn't scale the font > (submitted by corvid some time ago). > > It'd be good to have a patch that takes all the UI elements > into account. Unfortunately, a patch that scales UI fonts may > also need to scale the UI panel and this could take some effort. > > Scaling the UI font without scaling the UI panel may be easier, > and also serve the purpose. > Keeping the UI usable/readable across a multitude of systems and configurations is a different problem than keeping the displayed web pages usable/readable. It's best to address each problem individually, rather than lumping them together. Though it would be a serious change, and require a lot of patching, I think the best solution is to have a two pronged approach: 1.) Font Factor (scaling) 2.) Font Size If only Font_Size is stated, it would be used verbatim. If only Font_Factor is stated, it would scale the font. if both were stated, Font_Factor would take precedence. This would give you prefs for: vw_font_name vw_font_size vw_font_factor ui_font_name ui_font_size ui_font_factor Ummm... with all due respect, I think the currently used "fontname" in the prefs is against the coding conventions stated on the dillo site. Of course, it really doesn't matter to a compiler, but if I'm going to dig into augmenting this code, I need to know the "right" (TM)(C)(R) way to fix it. :-) > > > Unfortunately, I screwed up pasting my > > email address in the "submitter" section due to the fact that > > dillo doesn't actually copy selected text in a form (i.e. with > > the select/paste of the plain old X Window System). If you want > > to correct the submitter on the bug to my email address, it would > > be appreciated. There was no way I could correct it myself. > > > > On all popup menus in dillo, you have a non-typical and > > non-functional "label" (or better said "title") on the displayed > > popup menu. This was my first adventute into fltk, but according > > to the fltk2 docs, if you set the "label" of the popup menu to > > NULL, the "label" will not be shown. You can do it one of two > > ways, (1) setting the lable to NULL in the instantiation of the > > class or (2) using the ->label() member function to set the label > > to NULL. I opted for the former because it's more clean than the > > latter. > > I like those menu title labels in place. They even help me! > They also help newcomers to grasp Dillo's UI. > > Does anybody else feel like those labels are better out? > (if YES, a preference may be added) > Having an option might work, but I'm typically against having knobs just for the sake of having knobs. Keeping things simple and usable is far more important, and this includes keeping the code simple. I tend to follow the path of least surprise. :-) Since I cannot think of another application which has a label/title on Right-Click popup menus, I think having them would surprise new users more than not having them. By having label/title bars on menus, you're treating them like windows, and hence, the behavior is non-typical, inconsistent and unexpected. As for *my* personal opinion, I hate label/title bars since (to me) they serve no purpose. I'm actually running the cwm window manager so even windows don't waste space on unnecessary, non-functional title bars. > > Though there were "Accelerator" key bindings in the labels > > (such as "&PAGE OPTIONS" to get enable win32 meun-ish "<ALT>-P" > > activation), they don't actually work since the popup menu type > > ("POPUP123") means they are completely hidden until activated by > > the mouse buttons. > > There's a FLTK STR on this. > Bummer! It would be sweet if we could activate the popups throught he keyboard. Hopefully this will get fixed. > > There is still a popup menu placement issue (annoyance) with > > the Bug Meter when running dillo in full screen (or to the bottom > > edge of your screen) but it seems to be caused by the fltk > > "remember last selected" option. It does not properly realize the > > bottom edge of the screen/window, so some popup menu options are > > off-screen and you need a mouse-wheel movement to access them. > > This may be a bug in FLTK, but I'm not sure. > > BTW, it's good to see new developers around. Please check a bit > the latest activity in dillo-dev and you'll find other FLTK/UI > issues waiting for a patch. Thanks. I'll try to read the archives a bit more. -- J.C. Roberts

Nov. 10, 2008

Greetings! -- With Patches :-)

by corvid＠lavabit.com

Jorge wrote: > On Sun, Nov 09, 2008 at 12:16:42PM -0800, J.C. Roberts wrote: > > On all popup menus in dillo, you have a non-typical and > > non-functional "label" (or better said "title") on the displayed > > popup menu. This was my first adventute into fltk, but according > > to the fltk2 docs, if you set the "label" of the popup menu to > > NULL, the "label" will not be shown. You can do it one of two > > ways, (1) setting the lable to NULL in the instantiation of the > > class or (2) using the ->label() member function to set the label > > to NULL. I opted for the former because it's more clean than the > > latter. > > I like those menu title labels in place. They even help me! > They also help newcomers to grasp Dillo's UI. > > Does anybody else feel like those labels are better out? > (if YES, a preference may be added) I think I like having the labels.

Nov. 10, 2008

Greetings! -- With Patches :-)

by corvid＠lavabit.com

Jon wrote: > On Mon, 10 Nov 2008 04:59:50 +0000 "corvid" wrote: > > > > With GTK, you can control many aspects of the toolkit such as font > > > names/sizes on all applications through the system-wide or > > > user-level .gtkrc files. > > > > I wonder whether this is why dillo has historically used > > prefs.font_factor instead of a prefs.fontsize (where FontSizes in > > html.cc would be generated from it). > > This is actually boils down to a "personal preference" issue. Some > people believe it's a good thing for a web page to have fonts of > multiple sizes. Being that I can be somewhat difficult, I disagree > strongly, and think all text should be rendered in the exact same font > size... --But of course, that's *my* "personal preference." :-) > > For example, header tags in HTML (i.e. H1, H2, H3, ...) typically use a > larger font. If the dillo developers used prefs.fontsize, the result > would be what *I* like, namely all fonts would be forced to use the > exact same size. > > By using prefs.font_factor, the dillo developers made a wise choice > because it both prevents web developers from using microscopic font > sizes but still allows for variations in font size within a web page. Right, what I meant here is prefs.fontsize as the default as well as umm...h4, iirc, and then figuring out what h1-3,5-6 should be based on that value.

Nov. 10, 2008

Greetings! -- With Patches :-)

by jcid＠dillo.org

On Sun, Nov 09, 2008 at 12:16:42PM -0800, J.C. Roberts wrote: > Hi list, > > I guess the best way to show up on a development list is with > patches, so I've attached two of them. The diffs were created > against cvs with: Good! Welcome aboard. > [...] > The first is to fix an over-sight in the following post/patch > posted to this mailing list: > http://article.gmane.org/gmane.comp.web.dillo.devel/6248 > > The above patch does not take into consideration font size, so > the result can be microscopic/unreadable fonts. I've added the > code to scale the font in the same way as you scale other fonts > in dillo. Though I've read enough of the dillo docs and code to > grasp the basics of formatting, I'm unsure if my formatting of > the continuation (split line) is "correct" according to your > standards. > > There are other places in the dillo UI where font handling is > still incorrect and can result in unreadable fonts. Some of this > is the fault of fltk, since as far as I know there is no ~/.gtkrc > equivalent to set defaults for the tool kit. With luck, I'll find > and fix them. This raises an interesting issue. It may be necessary to add "ui_font_factor" to dillorc. With the patch "as is" things get broken here. The popup menus get incomplete titles. Looking at the result, I realized my personal preference is to have smaller fonts in the UI, than in rendered pages. This led me to the "ui_font_factor" solution. CVS has now a similar patch that doesn't scale the font (submitted by corvid some time ago). It'd be good to have a patch that takes all the UI elements into account. Unfortunately, a patch that scales UI fonts may also need to scale the UI panel and this could take some effort. Scaling the UI font without scaling the UI panel may be easier, and also serve the purpose. > The second patch is for BUG #832 --If I read things correctly, > I'm supposed to file a bug report first, assign it to myself, and > then send in patches. Yeah, but we haven't been strict on that. > Unfortunately, I screwed up pasting my > email address in the "submitter" section due to the fact that > dillo doesn't actually copy selected text in a form (i.e. with > the select/paste of the plain old X Window System). If you want > to correct the submitter on the bug to my email address, it would > be appreciated. There was no way I could correct it myself. > > On all popup menus in dillo, you have a non-typical and > non-functional "label" (or better said "title") on the displayed > popup menu. This was my first adventute into fltk, but according > to the fltk2 docs, if you set the "label" of the popup menu to > NULL, the "label" will not be shown. You can do it one of two > ways, (1) setting the lable to NULL in the instantiation of the > class or (2) using the ->label() member function to set the label > to NULL. I opted for the former because it's more clean than the > latter. I like those menu title labels in place. They even help me! They also help newcomers to grasp Dillo's UI. Does anybody else feel like those labels are better out? (if YES, a preference may be added) > Though there were "Accelerator" key bindings in the labels > (such as "&PAGE OPTIONS" to get enable win32 meun-ish "<ALT>-P" > activation), they don't actually work since the popup menu type > ("POPUP123") means they are completely hidden until activated by > the mouse buttons. There's a FLTK STR on this. > There is still a popup menu placement issue (annoyance) with > the Bug Meter when running dillo in full screen (or to the bottom > edge of your screen) but it seems to be caused by the fltk > "remember last selected" option. It does not properly realize the > bottom edge of the screen/window, so some popup menu options are > off-screen and you need a mouse-wheel movement to access them. This may be a bug in FLTK, but I'm not sure. BTW, it's good to see new developers around. Please check a bit the latest activity in dillo-dev and you'll find other FLTK/UI issues waiting for a patch. -- Cheers Jorge.-

Nov. 10, 2008

Re: patch: middle-click submits in new window/tab

by Johannes.Hofmann＠gmx.de

On Mon, Nov 10, 2008 at 02:36:48PM -0300, Jorge Arellano Cid wrote: > On Mon, Oct 20, 2008 at 02:49:41PM +0000, corvid wrote: > > I could say that it was for the sake of consistency with link behavior, > > but really it was because it seemed like a dilloishly simple way > > to get the equivalent of pages-remember-form-data. > > The consistency part is a strong argument. > > Also interesting is the way we can have a workaround to > remember form data, before a more usual way of handling it is > implemented. > > > > > (But: who will ever discover that it exists or recognize what it > > makes possible?) > > It may be stated in the FAQ. > > > > 1) fltkui: it might be better to stuff all of the button event stuff > > into a bag like fltkviewbase/layout do with EventButton. It certainly > > looks nicer having something like a shift mask hidden away in a nice > > tidy box, but I wasn't sure that it was actually worth doing. > > Hmm, I'd say if it's going to be a definitive patch, it's > worth the effort. > > > 2) form: carrying around buttonNo+shifted for a long time > > is not pleasing, but oh well. > > Agreed. > > > Now that Johannes is interested in implementing FORM "memory", > I'd say it can be stored in an URL/form-data array. I haven't > checked how other browsers (e.g. FF) solve the problem of privacy > (aka. when it's desirable to remember data), but most probably a > quick look will shed some light. > > BTW, I can't compile the patch here because: > > make[2]: Entering directory `/home/jcid/C/Dillo/d2/dillo2-cur/test' > form.cc: In member function 'void form::Form::addButtonResource(const char*, > dw::core::ui::ButtonResource*, const char*)': > form.cc:241: error: cannot allocate an object of abstract type > 'form::Form::FormClickedReceiver' > form.hh:124: note: because the following virtual functions are pure within > 'form::Form::FormClickedReceiver': > ../dw/ui.hh:338: note: virtual void > dw::core::ui::ButtonResource::ClickedReceiver::clicked(dw::core::ui::ButtonReso > urce*, int, int) > make[2]: *** [form.o] Error 1 > make[2]: Leaving directory `/home/jcid/C/Dillo/d2/dillo2-cur/test' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/jcid/C/Dillo/d2/dillo2-cur' > > > > BTW2: > > * The patch changes from "Activate" to "Clicked" signal. > * It also seems to change the logic in DilloHtmlInput::activate() > - it makes me wonder whether pressing enter on other form widgets > may submit. > > Anyway, it'd be good if you can coordinate with Johannes and decide what > approach to take, and send a new patch for it. I'd prefer Johannes to keep > working in the CSS front, and you to make the definitive patch, but this > is for you guys to decide. I won't start on any new stuff (other than CSS) in the near future. Currently I'm trying to convert the table code to the new style handling which is a bit hairy but there are no major obstacles yet. And I really like the middle-click to submit thing. So I don't have a lot of motivation to implement real form data remembering anyway. Cheers, Johannes

Nov. 10, 2008

Greetings! -- With Patches :-)

by list-jcr＠designtools.org

On Mon, 10 Nov 2008 04:59:50 +0000 "corvid" <corvid(a)lavabit.com> wrote: > > With GTK, you can control many aspects of the toolkit such as font > > names/sizes on all applications through the system-wide or > > user-level .gtkrc files. > > I wonder whether this is why dillo has historically used > prefs.font_factor instead of a prefs.fontsize (where FontSizes in > html.cc would be generated from it). This is actually boils down to a "personal preference" issue. Some people believe it's a good thing for a web page to have fonts of multiple sizes. Being that I can be somewhat difficult, I disagree strongly, and think all text should be rendered in the exact same font size... --But of course, that's *my* "personal preference." :-) For example, header tags in HTML (i.e. H1, H2, H3, ...) typically use a larger font. If the dillo developers used prefs.fontsize, the result would be what *I* like, namely all fonts would be forced to use the exact same size. By using prefs.font_factor, the dillo developers made a wise choice because it both prevents web developers from using microscopic font sizes but still allows for variations in font size within a web page. The fonts used in the dillo user interface (menus and such), are a different beast. The older dillo (pre 2.0) used GTK which allows the user to configure user interface fonts. With the new dillo ( > 2.0), the new FLTK graphic toolkit does not allow (as far as I know) for system/user wide configuration. This means the hard coded UI fonts are stuck at the specified sizes. -- J.C. Roberts

Nov. 10, 2008

Re: patch: middle-click submits in new window/tab

by jcid＠dillo.org

On Mon, Oct 20, 2008 at 02:49:41PM +0000, corvid wrote: > I could say that it was for the sake of consistency with link behavior, > but really it was because it seemed like a dilloishly simple way > to get the equivalent of pages-remember-form-data. The consistency part is a strong argument. Also interesting is the way we can have a workaround to remember form data, before a more usual way of handling it is implemented. > > (But: who will ever discover that it exists or recognize what it > makes possible?) It may be stated in the FAQ. > 1) fltkui: it might be better to stuff all of the button event stuff > into a bag like fltkviewbase/layout do with EventButton. It certainly > looks nicer having something like a shift mask hidden away in a nice > tidy box, but I wasn't sure that it was actually worth doing. Hmm, I'd say if it's going to be a definitive patch, it's worth the effort. > 2) form: carrying around buttonNo+shifted for a long time > is not pleasing, but oh well. Agreed. Now that Johannes is interested in implementing FORM "memory", I'd say it can be stored in an URL/form-data array. I haven't checked how other browsers (e.g. FF) solve the problem of privacy (aka. when it's desirable to remember data), but most probably a quick look will shed some light. BTW, I can't compile the patch here because: make[2]: Entering directory `/home/jcid/C/Dillo/d2/dillo2-cur/test' form.cc: In member function 'void form::Form::addButtonResource(const char*, dw::core::ui::ButtonResource*, const char*)': form.cc:241: error: cannot allocate an object of abstract type 'form::Form::FormClickedReceiver' form.hh:124: note: because the following virtual functions are pure within 'form::Form::FormClickedReceiver': ../dw/ui.hh:338: note: virtual void dw::core::ui::ButtonResource::ClickedReceiver::clicked(dw::core::ui::ButtonReso urce*, int, int) make[2]: *** [form.o] Error 1 make[2]: Leaving directory `/home/jcid/C/Dillo/d2/dillo2-cur/test' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jcid/C/Dillo/d2/dillo2-cur' BTW2: * The patch changes from "Activate" to "Clicked" signal. * It also seems to change the logic in DilloHtmlInput::activate() - it makes me wonder whether pressing enter on other form widgets may submit. Anyway, it'd be good if you can coordinate with Johannes and decide what approach to take, and send a new patch for it. I'd prefer Johannes to keep working in the CSS front, and you to make the definitive patch, but this is for you guys to decide. -- Cheers Jorge.-

Nov. 10, 2008

patch: prefs.vw_fontname as fltk ui's default font

by jcid＠dillo.org

On Wed, Oct 22, 2008 at 05:27:42PM +0200, Johannes Hofmann wrote: > On Wed, Oct 22, 2008 at 02:27:23PM +0000, corvid wrote: > > I was changing the font in a few more places that > > can take arbitrary user text -- and then having > > to change it for neighbouring things so that > > the difference isn't too jarring -- and I reached > > the point where it seemed like it may be best > > just to change the font for everything. > > > > I like it! > We could also remove the places where the font has been set already. Committed. > PS: In case someone needs it we could add a ui font option in dillorc > and default to fw_fontname. An ui_font_factor may be necessary. More in a next post... -- Cheers Jorge.-

Nov. 10, 2008

patch: click elsewhere on page, fltk widget loses focus

by jcid＠dillo.org

On Sun, Oct 19, 2008 at 12:33:05PM +0000, corvid wrote: > {my usual dw disclaimer}, but it's been working just fine so far. Committed. -- Cheers Jorge.-

Nov. 10, 2008

Greetings! -- With Patches :-)

by corvid＠lavabit.com

Jon wrote: > "corvid" wrote: > > Jon wrote: > Also, there's no mention on "MList.html" on if we're supposed to reply > to sender as well as the mailing list, or just reply to the list? The convention is just to send to the list. > > > The above patch does not take into consideration font size, so the > > > result can be microscopic/unreadable fonts. I've added the code to > > > scale the font in the same way as you scale other fonts in dillo. > > > > I had considered it, but didn't know whether I should. I ended up > > leaving it alone, reasoning that at least it would be no worse than > > before. Why was it causing them to be microscopic? > > It's a resolution issue. A 14 point font on *my* system is microscopic > and the cause is running extremely high resolutions. Okay, so it was already microscopic. I thought maybe I had made things worse somehow. > With GTK, you can control many aspects of the toolkit such as font > names/sizes on all applications through the system-wide or > user-level .gtkrc files. I wonder whether this is why dillo has historically used prefs.font_factor instead of a prefs.fontsize (where FontSizes in html.cc would be generated from it).

Nov. 10, 2008

Greetings! -- With Patches :-)

by list-jcr＠designtools.org

First of all, sorry about the long lines. I'm working on a fresh OS install with an entirely new (to me) email client. With luck, I should have it configured properly now. Also, there's no mention on "MList.html" on if we're supposed to reply to sender as well as the mailing list, or just reply to the list? On Sun, 9 Nov 2008 22:34:42 +0000 "corvid" <corvid(a)lavabit.com> wrote: > Jon wrote: > > I guess the best way to show up on a development list is with > > patches, > > Yes! People who arrive with "I want to help!" but without patches > rarely ever show up again. > There's a big difference between wanting to help and helping. :-) > > There was no mention on the site about the preferred diff format > > It's mentioned in developer.html and cvs.html. > I blatantly missed it, twice. Unfortunately, I've run out of good excuses today, so you'll need to chalk up the mistake to not paying enough attention. I will admit that while reading cvs.html, I questioned, and to a degree, discounted, the instructions given since (to me) it makes little sense to maintain multiple copies of the source tree. > > The first is to fix an over-sight in the following post/patch > > posted to this mailing list: > > http://article.gmane.org/gmane.comp.web.dillo.devel/6248 > > > > The above patch does not take into consideration font size, so the > > result can be microscopic/unreadable fonts. I've added the code to > > scale the font in the same way as you scale other fonts in dillo. > > I had considered it, but didn't know whether I should. I ended up > leaving it alone, reasoning that at least it would be no worse than > before. Why was it causing them to be microscopic? It's a resolution issue. A 14 point font on *my* system is microscopic and the cause is running extremely high resolutions. If you run really high resolutions (i.e. greater than 1600x1000, 1600,1280), finding microscopic fonts on some applications is a partially self-inflicted wound, but the real cause is developers not realizing they have no control over display hardware, instaled fonts, or system configurations. --Web site developers are absolutely notorious for this mistake, but applications developers also make it. It was a pleasure to see dillo handles the web page font size problem by providing scaling of fonts. Of course, every application will need a "default" font and "default" font size, but both font and size must be configurable by the user or the program will be unusable on many systems. Dillo is no exception, uses a default font size of 14 points, and worse, it's hard coded in a number of places in the source. I'll look into this as time allows. There are also similar font size issues with the "X of Y images," "X KB" size, and the labels of tabs, since all of them use fonts *smaller* than 14 points. I'll try to look into them as well. Though some would claim that fashion is my only conscience, :-) improving the font handling in dillo will make sure the program is usable on a much wider number of system types and configurations. Also, font handling is actually a very important issue for the visually impaired due to their use of screen readers (magnifiers), and specialized hardware. With GTK, you can control many aspects of the toolkit such as font names/sizes on all applications through the system-wide or user-level .gtkrc files. If there is a user/system equivalent for controlling FLTK globally, I haven't found it yet. --If you know of something similar for FLTK, please drop-kick me in the direction of the proper documentation. :-) Kind Regards, Jon -- J.C. Roberts

Nov. 10, 2008

Greetings! -- With Patches :-)

by corvid＠lavabit.com

Jon wrote: > I guess the best way to show up on a development list is with patches, Yes! People who arrive with "I want to help!" but without patches rarely ever show up again. > There was no mention on the site about the preferred diff format It's mentioned in developer.html and cvs.html. > The first is to fix an over-sight in the following post/patch posted to this mailing list: > http://article.gmane.org/gmane.comp.web.dillo.devel/6248 > > The above patch does not take into consideration font size, so the result can be microscopic/unreadable fonts. I've added the code to scale the font in the same way as you scale other fonts in dillo. I had considered it, but didn't know whether I should. I ended up leaving it alone, reasoning that at least it would be no worse than before. Why was it causing them to be microscopic?

Nov. 9, 2008

Greetings! -- With Patches :-)

by list-jcr＠designtools.org

Hi list, I guess the best way to show up on a development list is with patches, so I've attached two of them. The diffs were created against cvs with: $ cd /home/jcr/dillo-src/dillo2 $ cvs -d$CVS_DILLO diff -u There was no mention on the site about the preferred diff format, but since I found a few patches in the list archives using "universal" I figured it was the safest bet. Though I've read the docs on dillo.org about submitting bug reports first, and then patches, the first of the patches below is to a feature that has not yet been committed. The first is to fix an over-sight in the following post/patch posted to this mailing list: http://article.gmane.org/gmane.comp.web.dillo.devel/6248 The above patch does not take into consideration font size, so the result can be microscopic/unreadable fonts. I've added the code to scale the font in the same way as you scale other fonts in dillo. Though I've read enough of the dillo docs and code to grasp the basics of formatting, I'm unsure if my formatting of the continuation (split line) is "correct" according to your standards. There are other places in the dillo UI where font handling is still incorrect and can result in unreadable fonts. Some of this is the fault of fltk, since as far as I know there is no ~/.gtkrc equivalent to set defaults for the tool kit. With luck, I'll find and fix them. The second patch is for BUG #832 --If I read things correctly, I'm supposed to file a bug report first, assign it to myself, and then send in patches. Unfortunately, I screwed up pasting my email address in the "submitter" section due to the fact that dillo doesn't actually copy selected text in a form (i.e. with the select/paste of the plain old X Window System). If you want to correct the submitter on the bug to my email address, it would be appreciated. There was no way I could correct it myself. On all popup menus in dillo, you have a non-typical and non-functional "label" (or better said "title") on the displayed popup menu. This was my first adventute into fltk, but according to the fltk2 docs, if you set the "label" of the popup menu to NULL, the "label" will not be shown. You can do it one of two ways, (1) setting the lable to NULL in the instantiation of the class or (2) using the ->label() member function to set the label to NULL. I opted for the former because it's more clean than the latter. Though there were "Accelerator" key bindings in the labels (such as "&PAGE OPTIONS" to get enable win32 meun-ish "<ALT>-P" activation), they don't actually work since the popup menu type ("POPUP123") means they are completely hidden until activated by the mouse buttons. There is still a popup menu placement issue (annoyance) with the Bug Meter when running dillo in full screen (or to the bottom edge of your screen) but it seems to be caused by the fltk "remember last selected" option. It does not properly realize the bottom edge of the screen/window, so some popup menu options are off-screen and you need a mouse-wheel movement to access them. Anyhow, I hope this helps. Kind Regards, Jon Index: src/dillo.cc =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/dillo.cc,v retrieving revision 1.15 diff -u -r1.15 dillo.cc --- src/dillo.cc 10 Oct 2008 20:39:34 -0000 1.15 +++ src/dillo.cc 9 Nov 2008 19:43:45 -0000 @@ -21,9 +21,10 @@ #include <stdio.h> #include <unistd.h> #include <stdlib.h> +#include <math.h> /* for rint() */ #include <time.h> #include <signal.h> - +#include <fltk/Font.h> #include <fltk/Window.h> #include <fltk/TabGroup.h> #include <fltk/run.h> @@ -108,6 +109,16 @@ // WORKAROUND: sometimes the default pager triggers redraw storms fltk::TabGroup::default_pager(fltk::PAGER_SHRINK); + // Fix UI Fonts + fltk::Font *dfont = fltk::font(prefs.vw_fontname, 0); + if (dfont) { + fltk::Widget::default_style->textfont(dfont); + fltk::Widget::default_style->textsize( + (int) rint(14.0 * prefs.font_factor)); + fltk::Widget::default_style->labelfont(dfont); + } + + // Create a new UI/bw pair BrowserWindow *bw = a_UIcmd_browser_window_new(0, 0, NULL); Index: src/menu.cc =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/menu.cc,v retrieving revision 1.23 diff -u -r1.23 menu.cc --- src/menu.cc 22 Oct 2008 18:05:38 -0000 1.23 +++ src/menu.cc 9 Nov 2008 19:43:46 -0000 @@ -308,7 +308,7 @@ if (!pm) { Item *i; - pm = new PopupMenu(0,0,0,0,"&PAGE OPTIONS"); + pm = new PopupMenu(0,0,0,0,NULL); pm->begin(); i = new Item("View page Source"); i->callback(Menu_view_page_source_cb); @@ -360,7 +360,7 @@ popup_url = a_Url_dup(url); if (!pm) { Item *i; - pm = new PopupMenu(0,0,0,0,"&LINK OPTIONS"); + pm = new PopupMenu(0,0,0,0,NULL); //pm->callback(Menu_link_cb, url); pm->begin(); i = new Item("Open Link in New Window"); @@ -404,7 +404,7 @@ if (!pm) { Item *i; - pm = new PopupMenu(0,0,0,0,"&IMAGE OPTIONS"); + pm = new PopupMenu(0,0,0,0,NULL); pm->begin(); i = new Item("Isolate Image"); i->callback(Menu_open_url_cb); @@ -478,10 +478,10 @@ new Divider(); i = new Item("Exit Dillo", ALT+'q', filemenu_cb, (void*)"ed"); pm->type(PopupMenu::POPUP123); + pm->label(wid->visible() ? NULL : "File"); pm->end(); } - pm->label(wid->visible() ? NULL : "File"); a_Timeout_add(0.0, Menu_popup_cb2, (void *)pm); } @@ -498,7 +498,7 @@ popup_url = a_Url_dup(url); if (!pm) { Item *i; - pm = new PopupMenu(0,0,0,0,"&BUG METER OPTIONS"); + pm = new PopupMenu(0,0,0,0,NULL); pm->begin(); i = new Item("Validate URL with W3C"); i->callback(Menu_bugmeter_validate_w3c_cb); @@ -536,9 +536,9 @@ dFree(history_list); if (direction == -1) { - pm = new PopupMenu(0,0,0,0, "&PREVIOUS PAGES"); + pm = new PopupMenu(0,0,0,0,NULL); } else { - pm = new PopupMenu(0,0,0,0, "&FOLLOWING PAGES"); + pm = new PopupMenu(0,0,0,0,NULL); } // Get a list of URLs for this popup

Nov. 9, 2008

Feature Request

by Beartooth＠swva.net

On Sun, 9 Nov 2008, Jorge Arellano Cid wrote: >> I don't thing it will be that hard to get FLTK & Dillo2 into >> Fedora, the thing is that no one did it till now :). (And I ma >> pretty busy at work & uni :) ). > > Thanks a lot for the explanation! > > Although it may be difficult to get a FLTK2 package in the distro > because FLTK2 doesn't have a stable release yet. I mean, if > policies mandate not to include alpha or beta libraries, we're > out... > > It'd be good to know this (for Fedora, Ubuntu and Debian at > least). That way we can ask the FLTK team about their schedule > plans. I hate to be taking up so much time from people I know are working so hard already, but let me ask just one more : should I be taking this up with Alpine people? Or is one of you going to do that? (You could certainly do it a lot better.) Or have you determined that the trouble is in Fedora and not in Alpine? -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 9, 2008

Feature Request

by Beartooth＠swva.net

On Sun, 9 Nov 2008, Andreas Kemnade wrote: > The interesting question here is which 0.8.6? the official one or > the inofficial dillo-i18n one? At least debian does not ship the > official one. If that's about the dillo-i18n stuff (and not > reproducable with official dillo), then the problem should go to > the corresponding team. Definitely the official. Fedora offers both, and I always choose against the one with the funny name -- one more topic that life is too short to learn all about. -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 9, 2008

Feature Request

by Beartooth＠swva.net

On Sun, 9 Nov 2008, Johannes Hofmann wrote: >> I run Alpine 2.0; it is set to launch the default browser, which is >> dillo -- and URLs in emails are what I use a default browser for. >> >> Does this mean something in my Alpine settings (and my Pine 4.64 >> settings, which it took over) is wrong? My Fedora default browser setting >> is simply "dillo %s"; my Alpine setting is something I'll have to dig >> for, as it's buried way deep. > > I don't know what Alpine exactly does, but if I do > dillo google.com > on the command line, it works fine with both dillo 2.0 and 0.8.6. Yes, that looked normal; here, fwiw, are the messages : [btth@Hbsk2 ~]$ dillo google.com Gtk-WARNING **: Failed to load module "libgnomebreakpad.so": libgnomebreakpad.so: cannot open shared object file: No such file or directory Nav_open_url: Url=>about:splash< Nav_open_url: Url=>http://google.com< Type check: [Srv: text/html Det: text/html] Type check: [Srv: text/html; charset=UTF-8 Det: text/html] Nav_open_url: Url=>http://www.google.com/< Type check: [Srv: text/html; charset=ISO-8859-1 Det: text/html] Type check: [Srv: image/gif Det: image/gif] Dillo: normal exit! [btth@Hbsk2 ~]$ -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 9, 2008

Feature Request

by jcid＠dillo.org

On Sun, Nov 09, 2008 at 01:12:01PM +0100, Michal Nowak wrote: > Jorge Arellano Cid wrote: >> On Sat, Nov 08, 2008 at 10:58:43PM +0100, Michal Nowak wrote: >>> me at swva wrote: >>>> I think I'm being unclear, in two ways. >>>> >>>>>> Just to check, I did this as root : >>>>>> >>>>>> [root@Hbsk2 btth]# rpm -q dillo >>>>>> dillo-0.8.6-7.fc9.i386 >>>>>> [root@Hbsk2 btth]# yum update dillo >>>> ^^^^^^^^^^^^^^^^ >>>>>> Loaded plugins: refresh-packagekit >>>>>> updates-newkey | 2.3 kB 00:00 >>>>>> updates | 2.6 kB 00:00 >>>>>> fedora | 2.4 kB 00:00 >>>>>> Setting up Update Process >>>>>> No Packages marked for Update >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> [root@Hbsk2 btth]# >>>> On Sat, 8 Nov 2008, Johannes Hofmann wrote: >>>> >>>>> dillo-0.8.6 is no longer supported and you should consider to >>>>> upgrade to dillo-2.0. >>>>> But nevertheless for me it also works with dillo-0.8.6. >>>> For those who run other OSs, what the emphasized lines mean is >>>> the 0.8.6 is what Fedora has, period. (I run F9, the latest >>>> release.) Any idea why it's so far behind?? I didn't realize 1.0 >>>> had become official, let alone 2.0 >>>> >>> That's life. In Fedora, nor even Rawhide, isn't Dillo v2.0. Two reasons: >>> >>> 1) No one packed FLTK 2.x, check repository there's still 1.1.9. >>> 2) Because of (1) no Dillo 2. >>> >>> Although Fedora is usually fresh, in case of Dillo it's still on >>> Dillo 0.8.6 mainline. Feel free to file bug (bugzilla.redhat.com) >>> against Dillo and Package Review for FLTK2, but be aware that having >>> unstable FLTK 2.x in Fedora might be quite fight. (Believe me I am >>> Fedora packager.) >> >> Dillo2 doesn't need an FLTK2 package installed! >> It can be statically linked in. One package, that's it. >> (this is the default BTW). >> > > Sure I am aware of that, but wrt Fedora, it's something neat forbidden > > https://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy > > unless necessary (and this is not the case). > >> Now, if distros need to also provide source packages by policy, >> then that's a different story. >> > > Correct. FLTK can't just be present in compile time, somehow, toolchain > has to be clear and for everyone from day0. > >> Please clarify me because I've read that complaint a few times, >> and don't yet know whether it's my fault not making the statical >> linking clear enough to packagers, or if there's a packaging >> policy issue I don't know of. :) >> > > From my POV, in distros we don't want static built packages; security > flaws in linked-in libraries is the main concern. One has to rebuild all > apps with those libraries, not just the library (obvious). > > I don't thing it will be that hard to get FLTK & Dillo2 into Fedora, the > thing is that no one did it till now :). (And I ma pretty busy at work & > uni :) ). Thanks a lot for the explanation! Although it may be difficult to get a FLTK2 package in the distro because FLTK2 doesn't have a stable release yet. I mean, if policies mandate not to include alpha or beta libraries, we're out... It'd be good to know this (for Fedora, Ubuntu and Debian at least). That way we can ask the FLTK team about their schedule plans. -- Cheers Jorge.-

Nov. 9, 2008

rebased patch: print numeric addresses instead of pointer

by jcid＠dillo.org

On Sat, Nov 08, 2008 at 07:57:17PM +0100, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > *bump* > > ;) Justus Committed with minor changes. -- Cheers Jorge.-

Nov. 9, 2008

patch: savefile url name

by jcid＠dillo.org

On Sat, Nov 08, 2008 at 03:10:22PM +0000, corvid wrote: > Anyway, here's a patch that I've had sitting around for a while. > > I have a bad habit of hitting space to page down when the > Location field still has focus, which would break things > when trying to save... Committed. I seem to recall there was a problem with not taking the URL from the location bar. It may be from dillo1 days though... The patch was committed to check it in practice. -- Cheers Jorge.-

Nov. 9, 2008

Feature Request

by newman.x＠gmail.com

Jorge Arellano Cid wrote: > On Sat, Nov 08, 2008 at 10:58:43PM +0100, Michal Nowak wrote: >> me at swva wrote: >>> I think I'm being unclear, in two ways. >>> >>>>> Just to check, I did this as root : >>>>> >>>>> [root@Hbsk2 btth]# rpm -q dillo >>>>> dillo-0.8.6-7.fc9.i386 >>>>> [root@Hbsk2 btth]# yum update dillo >>> ^^^^^^^^^^^^^^^^ >>>>> Loaded plugins: refresh-packagekit >>>>> updates-newkey | 2.3 kB 00:00 >>>>> updates | 2.6 kB 00:00 >>>>> fedora | 2.4 kB 00:00 >>>>> Setting up Update Process >>>>> No Packages marked for Update >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> [root@Hbsk2 btth]# >>> On Sat, 8 Nov 2008, Johannes Hofmann wrote: >>> >>>> dillo-0.8.6 is no longer supported and you should consider to >>>> upgrade to dillo-2.0. >>>> But nevertheless for me it also works with dillo-0.8.6. >>> For those who run other OSs, what the emphasized lines mean is the >>> 0.8.6 is what Fedora has, period. (I run F9, the latest release.) Any >>> idea why it's so far behind?? I didn't realize 1.0 had become official, >>> let alone 2.0 >>> >> That's life. In Fedora, nor even Rawhide, isn't Dillo v2.0. Two reasons: >> >> 1) No one packed FLTK 2.x, check repository there's still 1.1.9. >> 2) Because of (1) no Dillo 2. >> >> Although Fedora is usually fresh, in case of Dillo it's still on Dillo >> 0.8.6 mainline. Feel free to file bug (bugzilla.redhat.com) against >> Dillo and Package Review for FLTK2, but be aware that having unstable >> FLTK 2.x in Fedora might be quite fight. (Believe me I am Fedora >> packager.) > > Dillo2 doesn't need an FLTK2 package installed! > It can be statically linked in. One package, that's it. > (this is the default BTW). > Sure I am aware of that, but wrt Fedora, it's something neat forbidden https://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy unless necessary (and this is not the case). > Now, if distros need to also provide source packages by policy, > then that's a different story. > Correct. FLTK can't just be present in compile time, somehow, toolchain has to be clear and for everyone from day0. > Please clarify me because I've read that complaint a few times, > and don't yet know whether it's my fault not making the statical > linking clear enough to packagers, or if there's a packaging > policy issue I don't know of. :) > From my POV, in distros we don't want static built packages; security flaws in linked-in libraries is the main concern. One has to rebuild all apps with those libraries, not just the library (obvious). I don't thing it will be that hard to get FLTK & Dillo2 into Fedora, the thing is that no one did it till now :). (And I ma pretty busy at work & uni :) ). Michal

Nov. 9, 2008

Feature Request

by jcid＠dillo.org

On Sat, Nov 08, 2008 at 10:58:43PM +0100, Michal Nowak wrote: > me at swva wrote: >> >> I think I'm being unclear, in two ways. >> >>>> Just to check, I did this as root : >>>> >>>> [root@Hbsk2 btth]# rpm -q dillo >>>> dillo-0.8.6-7.fc9.i386 >>>> [root@Hbsk2 btth]# yum update dillo >> ^^^^^^^^^^^^^^^^ >>>> Loaded plugins: refresh-packagekit >>>> updates-newkey | 2.3 kB 00:00 >>>> updates | 2.6 kB 00:00 >>>> fedora | 2.4 kB 00:00 >>>> Setting up Update Process >>>> No Packages marked for Update >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> [root@Hbsk2 btth]# >> >> On Sat, 8 Nov 2008, Johannes Hofmann wrote: >> >>> dillo-0.8.6 is no longer supported and you should consider to >>> upgrade to dillo-2.0. >>> But nevertheless for me it also works with dillo-0.8.6. >> >> For those who run other OSs, what the emphasized lines mean is the >> 0.8.6 is what Fedora has, period. (I run F9, the latest release.) Any >> idea why it's so far behind?? I didn't realize 1.0 had become official, >> let alone 2.0 >> > > That's life. In Fedora, nor even Rawhide, isn't Dillo v2.0. Two reasons: > > 1) No one packed FLTK 2.x, check repository there's still 1.1.9. > 2) Because of (1) no Dillo 2. > > Although Fedora is usually fresh, in case of Dillo it's still on Dillo > 0.8.6 mainline. Feel free to file bug (bugzilla.redhat.com) against > Dillo and Package Review for FLTK2, but be aware that having unstable > FLTK 2.x in Fedora might be quite fight. (Believe me I am Fedora > packager.) Dillo2 doesn't need an FLTK2 package installed! It can be statically linked in. One package, that's it. (this is the default BTW). Now, if distros need to also provide source packages by policy, then that's a different story. Please clarify me because I've read that complaint a few times, and don't yet know whether it's my fault not making the statical linking clear enough to packagers, or if there's a packaging policy issue I don't know of. :) -- Cheers Jorge.-

Nov. 9, 2008

Feature Request

by akemnade＠tzi.de

On Sun, 9 Nov 2008 09:38:11 +0100 Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > On Sat, Nov 08, 2008 at 04:40:01PM -0500, me at swva wrote: > > > > I think I'm being unclear, in two ways. > > > >>> Just to check, I did this as root : > >>> > >>> [root@Hbsk2 btth]# rpm -q dillo > >>> dillo-0.8.6-7.fc9.i386 > >>> [root@Hbsk2 btth]# yum update dillo > > ^^^^^^^^^^^^^^^^ > >>> Loaded plugins: refresh-packagekit > >>> updates-newkey | 2.3 kB 00:00 > >>> updates | 2.6 kB 00:00 > >>> fedora | 2.4 kB 00:00 > >>> Setting up Update Process > >>> No Packages marked for Update > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> [root@Hbsk2 btth]# > > > > On Sat, 8 Nov 2008, Johannes Hofmann wrote: > > > >> dillo-0.8.6 is no longer supported and you should consider to > >> upgrade to dillo-2.0. > >> But nevertheless for me it also works with dillo-0.8.6. > > > > For those who run other OSs, what the emphasized lines mean is the 0.8.6 > > is what Fedora has, period. (I run F9, the latest release.) Any idea why > > it's so far behind?? I didn't realize 1.0 had become official, let alone > > 2.0 > > > >> If you enter "google.com" in the location bar and hit return > >> it doesn't go to google? > > > > It does indeed. I'm putting this badly. > > > > I run Alpine 2.0; it is set to launch the default browser, which is > > dillo -- and URLs in emails are what I use a default browser for. > > > > Does this mean something in my Alpine settings (and my Pine 4.64 > > settings, which it took over) is wrong? My Fedora default browser setting > > is simply "dillo %s"; my Alpine setting is something I'll have to dig > > for, as it's buried way deep. > > I don't know what Alpine exactly does, but if I do > dillo google.com > on the command line, it works fine with both dillo 2.0 and 0.8.6. > The interesting question here is which 0.8.6? the official one or the inofficial dillo-i18n one? At least debian does not ship the official one. If that's about the dillo-i18n stuff (and not reproducable with official dillo), then the problem should go to the corresponding team. Greetings Andreas Kemnade

Nov. 9, 2008

Feature Request

by Johannes.Hofmann＠gmx.de

On Sat, Nov 08, 2008 at 04:40:01PM -0500, me at swva wrote: > > I think I'm being unclear, in two ways. > >>> Just to check, I did this as root : >>> >>> [root@Hbsk2 btth]# rpm -q dillo >>> dillo-0.8.6-7.fc9.i386 >>> [root@Hbsk2 btth]# yum update dillo > ^^^^^^^^^^^^^^^^ >>> Loaded plugins: refresh-packagekit >>> updates-newkey | 2.3 kB 00:00 >>> updates | 2.6 kB 00:00 >>> fedora | 2.4 kB 00:00 >>> Setting up Update Process >>> No Packages marked for Update > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> [root@Hbsk2 btth]# > > On Sat, 8 Nov 2008, Johannes Hofmann wrote: > >> dillo-0.8.6 is no longer supported and you should consider to >> upgrade to dillo-2.0. >> But nevertheless for me it also works with dillo-0.8.6. > > For those who run other OSs, what the emphasized lines mean is the 0.8.6 > is what Fedora has, period. (I run F9, the latest release.) Any idea why > it's so far behind?? I didn't realize 1.0 had become official, let alone > 2.0 > >> If you enter "google.com" in the location bar and hit return >> it doesn't go to google? > > It does indeed. I'm putting this badly. > > I run Alpine 2.0; it is set to launch the default browser, which is > dillo -- and URLs in emails are what I use a default browser for. > > Does this mean something in my Alpine settings (and my Pine 4.64 > settings, which it took over) is wrong? My Fedora default browser setting > is simply "dillo %s"; my Alpine setting is something I'll have to dig > for, as it's buried way deep. I don't know what Alpine exactly does, but if I do dillo google.com on the command line, it works fine with both dillo 2.0 and 0.8.6.

Nov. 9, 2008

Feature Request

by newman.x＠gmail.com

me at swva wrote: > > I think I'm being unclear, in two ways. > >>> Just to check, I did this as root : >>> >>> [root@Hbsk2 btth]# rpm -q dillo >>> dillo-0.8.6-7.fc9.i386 >>> [root@Hbsk2 btth]# yum update dillo > ^^^^^^^^^^^^^^^^ >>> Loaded plugins: refresh-packagekit >>> updates-newkey | 2.3 kB 00:00 >>> updates | 2.6 kB 00:00 >>> fedora | 2.4 kB 00:00 >>> Setting up Update Process >>> No Packages marked for Update > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> [root@Hbsk2 btth]# > > On Sat, 8 Nov 2008, Johannes Hofmann wrote: > >> dillo-0.8.6 is no longer supported and you should consider to >> upgrade to dillo-2.0. >> But nevertheless for me it also works with dillo-0.8.6. > > For those who run other OSs, what the emphasized lines mean is the > 0.8.6 is what Fedora has, period. (I run F9, the latest release.) Any > idea why it's so far behind?? I didn't realize 1.0 had become official, > let alone 2.0 > That's life. In Fedora, nor even Rawhide, isn't Dillo v2.0. Two reasons: 1) No one packed FLTK 2.x, check repository there's still 1.1.9. 2) Because of (1) no Dillo 2. Although Fedora is usually fresh, in case of Dillo it's still on Dillo 0.8.6 mainline. Feel free to file bug (bugzilla.redhat.com) against Dillo and Package Review for FLTK2, but be aware that having unstable FLTK 2.x in Fedora might be quite fight. (Believe me I am Fedora packager.) Feel free to use mines with SSL enabled (no guarantee at all), both F10. http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/dillo/dillo-2.0-1.i386.rpm http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/fltk/fltk2-2.0.x.r6403-0.1.i3… But you'll probably have more luck with those: http://www.hyperborea.org/software/dillo/rpms/ Enjoy. >> If you enter "google.com" in the location bar and hit return >> it doesn't go to google? > > It does indeed. I'm putting this badly. > > I run Alpine 2.0; it is set to launch the default browser, which is > dillo -- and URLs in emails are what I use a default browser for. > > Does this mean something in my Alpine settings (and my Pine 4.64 > settings, which it took over) is wrong? My Fedora default browser > setting is simply "dillo %s"; my Alpine setting is something I'll have > to dig for, as it's buried way deep. > Might be here interesting whether Dillo2 cooperates nicely with alpine, let us know. Michal

Nov. 8, 2008