- Dillo-dev - lists.mailman3.com

Feature Request

by Beartooth＠swva.net

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. -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 8, 2008

Feature Request

by Johannes.Hofmann＠gmx.de

On Sat, Nov 08, 2008 at 04:19:19PM -0500, me at swva wrote: > On Sat, 8 Nov 2008, Johannes Hofmann wrote: > >> Hi, >> >> On Sat, Nov 08, 2008 at 03:40:08PM -0500, me at swva wrote: >>> >>> Dillo, alone of all browsers I know, cannot handle "www.site.xyz.com," >>> by simply converting it on the fly to "http://www.site.xyz.com" >> >> It works fine for me. >> Do you have an example where it doesn't work for you? >> What version of dillo are you using? > > Iirc, it has *always* done this to me, on all machines, for years out of > mind, on all URLs. > > 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]# 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. If you enter "google.com" in the location bar and hit return it doesn't go to google?

Nov. 8, 2008

Feature Request

by Beartooth＠swva.net

On Sat, 8 Nov 2008, Johannes Hofmann wrote: > Hi, > > On Sat, Nov 08, 2008 at 03:40:08PM -0500, me at swva wrote: >> >> Dillo, alone of all browsers I know, cannot handle "www.site.xyz.com," >> by simply converting it on the fly to "http://www.site.xyz.com" > > It works fine for me. > Do you have an example where it doesn't work for you? > What version of dillo are you using? Iirc, it has *always* done this to me, on all machines, for years out of mind, on all URLs. 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]# -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 8, 2008

Feature Request

by Johannes.Hofmann＠gmx.de

Hi, On Sat, Nov 08, 2008 at 03:40:08PM -0500, me at swva wrote: > > Dillo, alone of all browsers I know, cannot handle "www.site.xyz.com," > by simply converting it on the fly to "http://www.site.xyz.com" It works fine for me. Do you have an example where it doesn't work for you? What version of dillo are you using? Cheers, Johannes

Nov. 8, 2008

Feature Request

by Beartooth＠swva.net

Dillo, alone of all browsers I know, cannot handle "www.site.xyz.com," by simply converting it on the fly to "http://www.site.xyz.com" Is there some reason why not? Could it be implemented, or has it been, in the next release? I use Dillo by default, because it's fast and safe, and also more convenient to c&p from (by a country mile, if the URL is very long) than my email, in case I hit a site that it doesn't handle, but that I want a closer look at; or in case I want to bookmark it, or keep it open, in some other browser. Getting hung up on the absence of "http://" is a large, buzzing fly in that ointment. -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 8, 2008

Pending issues

by corvid＠lavabit.com

Johannes wrote: > On Sat, Nov 08, 2008 at 04:31:41PM +0000, corvid wrote: > > patch: middle-click submits in new window/tab > > (This last one had been sent directly to Jorge. > > It's a cheap way to get some degree of > > pages-remember-form-data without having to, > > you know, actually remember form data.) > > Hey that's clever! I already thought about actually implementing > pages-remember-form-data... I wouldn't want to stand in the way of that :) Where do you think form data would fit best? In the history list? (nav stack would require a lot of digging around to clear upon reload, and the cache is low-level and full of images) > A problem may be how to communicate that feature to the user. Quite true.

Nov. 8, 2008

rebased patch: print numeric addresses instead of pointer

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 *bump* ;) Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkV4Q0ACgkQoPmwNWhsaZZgxwCgmF6KnAmGgHrckPYHMkGScLsE xPgAnjNFE4UzuAN1t6tDmgHCXcblGocq =Cd16 -----END PGP SIGNATURE-----

Nov. 8, 2008

Pending issues

by Johannes.Hofmann＠gmx.de

On Sat, Nov 08, 2008 at 04:31:41PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Nov 08, 2008 at 02:49:35PM +0000, corvid wrote: > > > Jorge, is there any chance of my various > > > patches getting looked at in the near > > > future? I feel reluctant to start playing > > > with css until then. > > > > Oh, which ones besided the "view source" one? > > patch: click elsewhere on page, fltk widget loses focus > > patch: prefs.vw_fontname as fltk ui's default font > > patch: middle-click submits in new window/tab > (This last one had been sent directly to Jorge. > It's a cheap way to get some degree of > pages-remember-form-data without having to, > you know, actually remember form data.) Hey that's clever! I already thought about actually implementing pages-remember-form-data... A problem may be how to communicate that feature to the user. Cheers, Johannes

Nov. 8, 2008

Pending issues

by corvid＠lavabit.com

Jorge wrote: > On Sat, Nov 08, 2008 at 02:49:35PM +0000, corvid wrote: > > Jorge, is there any chance of my various > > patches getting looked at in the near > > future? I feel reluctant to start playing > > with css until then. > > Oh, which ones besided the "view source" one? patch: click elsewhere on page, fltk widget loses focus patch: prefs.vw_fontname as fltk ui's default font patch: middle-click submits in new window/tab (This last one had been sent directly to Jorge. It's a cheap way to get some degree of pages-remember-form-data without having to, you know, actually remember form data.)

Nov. 8, 2008

Pending issues

by jcid＠dillo.org

On Sat, Nov 08, 2008 at 02:49:35PM +0000, corvid wrote: > Jorge, is there any chance of my various > patches getting looked at in the near > future? I feel reluctant to start playing > with css until then. Oh, which ones besided the "view source" one? -- Cheers Jorge.-

Nov. 8, 2008

patch: savefile url name

by corvid＠lavabit.com

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...

Nov. 8, 2008

Pending issues

by corvid＠lavabit.com

Jorge, is there any chance of my various patches getting looked at in the near future? I feel reluctant to start playing with css until then.

Nov. 8, 2008

Pending issues

by jcid＠dillo.org

Hi there, For those of you that wrote me willing to join the project as developers, and to the older ones too ;), here's a pending list of simple matters that need patches. Just in case! 1.- Check the "pending issues" dillo thread in FLTK' site: http://fltk.org/newsgroups.php?gfltk.general+T (search for "dillo") there you'll find a few and some hints too. 2.- CLI From dillo1: $ dillo1 --help Usage: dillo [OPTIONS] [URL|FILE]... Options: -x, --xid XID Open first Dillo window in an existing GtkSocket which window ID is XID (decimal). -v, --version Display version info and exit. -h, --help Display this help text and exit. -f, --fullwindow Start in full window mode: hide address bar, navigation buttons, menu, and status bar. -l, --local Don't follow links for this URL(s). -g, -geometry GEO Set initial window position where GEO is <width>x<height>{+-}<x>{+-}<y> -D, --debug-rendering Draw additionaly several lines in a web page, representing its structure. For debugging. URL URL to browse. FILE Local FILE to vie We need to mimic this. The only complex point is XID option. We don't yet know how to do window embedding by XID with FLTK2. Asking in FLTK general may help. I hope this gets somebody started. /me goes back, to CSS. -- Cheers Jorge.-

Nov. 8, 2008

Few more dillo issues

by sandshrew＠gmail.com

Issues: 1) ssl dpi looping when entering: http://www.elitehackers.info/forums 2) logging into kde forum (forum.kde.org) and gmail (which I reported earlier) doesn't seem to work for same reasons. I guess there should be much more similar cases.

Nov. 8, 2008

Re: css prototype on freehg.org

by Johannes.Hofmann＠gmx.de

Hi, On Fri, Nov 07, 2008 at 11:36:21AM -0300, Jorge Arellano Cid wrote: > Hi, > > We've been arranging some CSS things behind the scenes > with Johannes (he'll forward some past mails here soon). > > > On Fri, Oct 31, 2008 at 05:00:54PM +0100, Johannes Hofmann wrote: > > Hi Jorge, > > > > I just created a repository > > http://freehg.org/u/jh33/dillo-css-prototype/ > > > > freehg.org is a free mercurial hosting service. > > This gives access to the newest version of the css prototyping work. > > Also you can check whether you like mercurial. > > > > To get a copy of the repository call > > > > hg clone http://freehg.org/u/jh33/dillo-css-prototype/ > > > > and start hacking. You can commit locally using > > > > hg commit > > OK, I'll make some patches with Hg once I grasp how this > distributed model works. > > On the current code, basically it looks OK to me. i.e. we can > continue working from that basis (having in mind that it's still > in a flux state and that a validation is pending on whether the > model is able to handle the current functionality in html.cc). > > My main comment is that the code needs more comments! :) Agreed. I started to add comments (visible in the hg repo). > > Accurate comments are written when the code is developed (every > detail is in the brain then). I've tried in the past to develop > first and comment later, and found it only works OK for small > code projects. > > As with CSS we don't have a main expert (yet), the team will be > trying to understand and develop at the same time, and thus > comments are very necessary. Even something like "I don't know > how to implement this part" helps! > > I'd suggest to use the same format that's in css.cc. e.g. > > /** \todo dummy only */ > > with a view to integrate it smoothly with doxygen docs. in the > future. > > > Some specific examples: > > 1.- What do these functions do? > - style0() > - startElement() > - endElement() > > 2.- On memory handling, there are some places with: > > // html->styleEngine->style () = > // Style::create (HT2LT(html), &style_attrs); > // old_style->unref (); > > or > > // (html->styleEngine->style ())->unref (); > > Why are they commented and left in the code? Is proper > memory handling pending, is there a design decision to be > made before getting rid of them? They can be deleted. I will do that. The idea is that in html.cc no styles are created anymore. Instead only the style handed out by styleEngine is used. > > 3.- With regard, for instance, to font_factor and visited link > color. Do they belong to buildUserAgentStyle() or > buildUserStyle() or elsewhere? I think the userAgentStyle should contain the defaults, the userStyle can override those. We can create the userStyle from what's in dillorc or - once we have a CSS parser - we could parse a user defined custom stylesheet as it is possible in other browsers. > > 4.- strdup/free should be dStrdup/dFree > (Please let me use this extremely simple case to make my > first Hg patch :-) > Great. You could also create a repo on freehg.org were you can publish your work. We could then pull from each other. Or we send patches to the list and someone integrates them. > > I know this was just a prototype for the CSS implementation > idea, but considering that we don't have any better, and that we > agreed on it, now it has attained the status of "official CSS > merge effort". ;-) > > From now comments are paramount, and we may eventually get to > a dw-like quality docs in the future. Yes, let's take dw as an example. The documentation is really good there. > > > Bottom line: Great, let's get started! Excellent. Here's my todo list: * Adjust CssProperty::Value. As Sebastian has stated "CssValue (is) a union, which represents values exactly in the way they have been parsed" In addition to the values from style.hh it must be able to hold relative values (e.g. "bolder" for font weights). The translation to actual values is then done in StyleEngine::apply (). * Add support for pseudo classes and use it to change the color of visited links in Html_tag_open_a(). * Transform the rest of html.cc, table.cc, and form.cc to use styleEngine instead of creating styles itself. * Port the CSS parser code from dillo-0.8.0-css-3. Any help or comments are welcome! Make sure to have a look at dillo-0.8.0-css-3 as it contains a lot of useful code! Cheers, Johannes

Nov. 7, 2008

[jcid@dillo.org: Re: css prototype on freehg.org]

by Johannes.Hofmann＠gmx.de

----- Forwarded message from Jorge Arellano Cid <jcid(a)dillo.org> ----- Date: Thu, 6 Nov 2008 14:05:33 -0300 From: Jorge Arellano Cid <jcid(a)dillo.org> To: Johannes Hofmann <Johannes.Hofmann(a)gmx.de> Subject: Re: css prototype on freehg.org On Thu, Nov 06, 2008 at 05:31:34PM +0100, Johannes Hofmann wrote: > > > > I'm currently reviewing the CSS work you uploaded! > > > > On Fri, Oct 31, 2008 at 05:00:54PM +0100, Johannes Hofmann wrote: > > > Hi Jorge, > > > > > > I just created a repository > > > http://freehg.org/u/jh33/dillo-css-prototype/ > > > > > > freehg.org is a free mercurial hosting service. > > > This gives access to the newest version of the css prototyping work. > > > Also you can check whether you like mercurial. > > > > Hmm, that's another topic that needs a resolution: > > to git or to hg? > > Featurewise there is hardly a difference. I prefer mercurial because > of it's nice and simple ui. > Just recently there was the same discussion for DragonFlyBSD: > http://leaf.dragonflybsd.org/mailarchive/kernel/2008-10/msg00144.html Yes, I also like simple UIs. > > [...] > > Do you have a recommended quick-start guide? > > http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart > > and a bit longer: > > http://www.selenic.com/mercurial/wiki/index.cgi/Tutorial > > and a lot longer: > > http://hgbook.red-bean.com/hgbook.html Thanks. > > > > > I didn't send this to the list, because I want to be sure that you > > > are ok with this step. > > > > Which one, the mercurial or the CSS code? > > Both. Publishing CSS prototype in a separate repository. For now the Hg repository is OK. I'm yet to grasp the distributed workflow model. It seems our old CVS needs an update. > > > > As far as CSS, after the first review it looks OK, and > > seems the way to go. I'm going more in depth now to try to > > understand how it works and fits in the plan. > > Great. Please keep in mind that the current work tries to find a > proper interface between CSS stuff and the code in html.cc. > It needs to be verified that the concept covers all the edge cases. > One is probabely the table code that stores a separate > table_cell_style on the stack. > Is this to hold cell properties that were set in the <table> or <tr> > tags? I'll check. Most probably that's the case though. e.g. bgcolor. OK, once I've grasped the concept, I'll tell you what I find. > > > Also the CSS prototype contains some code from dillo-0.8.0-css-3 > > > that doesn't have license headers. Can you contact Sebastian to ask > > > if it is ok to use stuff from his prototype? > > > > I have an email from him (long time ago) where he advocates > > on making the CSS prototype code more visible from the website, > > to attract developers. He also said he was working on floating objects! > > > > I'll try to contact him and see what's up with him... > > > > As from his email, and conversations we had long ago, > > I believe it's quite safe to use the code. > > Great. It seems to contain a pretty complete CSS parser. > > Cheers, > Johannes > > PS: We should probabely take this discussion to the list. It's a bit > quiet there. What do You think? Sure, feel free to forward the thread (or relevant parts). -- Cheers Jorge.- ----- End forwarded message -----

Nov. 7, 2008

Re: css prototype on freehg.org

by jcid＠dillo.org

Hi, We've been arranging some CSS things behind the scenes with Johannes (he'll forward some past mails here soon). On Fri, Oct 31, 2008 at 05:00:54PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > I just created a repository > http://freehg.org/u/jh33/dillo-css-prototype/ > > freehg.org is a free mercurial hosting service. > This gives access to the newest version of the css prototyping work. > Also you can check whether you like mercurial. > > To get a copy of the repository call > > hg clone http://freehg.org/u/jh33/dillo-css-prototype/ > > and start hacking. You can commit locally using > > hg commit OK, I'll make some patches with Hg once I grasp how this distributed model works. On the current code, basically it looks OK to me. i.e. we can continue working from that basis (having in mind that it's still in a flux state and that a validation is pending on whether the model is able to handle the current functionality in html.cc). My main comment is that the code needs more comments! :) Accurate comments are written when the code is developed (every detail is in the brain then). I've tried in the past to develop first and comment later, and found it only works OK for small code projects. As with CSS we don't have a main expert (yet), the team will be trying to understand and develop at the same time, and thus comments are very necessary. Even something like "I don't know how to implement this part" helps! I'd suggest to use the same format that's in css.cc. e.g. /** \todo dummy only */ with a view to integrate it smoothly with doxygen docs. in the future. Some specific examples: 1.- What do these functions do? - style0() - startElement() - endElement() 2.- On memory handling, there are some places with: // html->styleEngine->style () = // Style::create (HT2LT(html), &style_attrs); // old_style->unref (); or // (html->styleEngine->style ())->unref (); Why are they commented and left in the code? Is proper memory handling pending, is there a design decision to be made before getting rid of them? 3.- With regard, for instance, to font_factor and visited link color. Do they belong to buildUserAgentStyle() or buildUserStyle() or elsewhere? 4.- strdup/free should be dStrdup/dFree (Please let me use this extremely simple case to make my first Hg patch :-) I know this was just a prototype for the CSS implementation idea, but considering that we don't have any better, and that we agreed on it, now it has attained the status of "official CSS merge effort". ;-) From now comments are paramount, and we may eventually get to a dw-like quality docs in the future. Bottom line: Great, let's get started! -- Cheers Jorge.-

Nov. 7, 2008

Dillo too fast?

by jcid＠dillo.org

Hi, On Fri, Nov 07, 2008 at 09:06:57AM +0100, Thomas Orgis wrote: > Did anyone else encounter this from google? > Not sure if this is something specific in dillo's network behaviour... > > > We're sorry... > > > ... but your query looks similar to automated requests from a > > computer virus or spyware application. To protect our users, > > we can't process your request right now. I've been using Dillo with google for years, and hit that message yesterday for the first time. It made sense to me because the rejected query was just an email address, which looks like a spammer's check. > > It's at least the second time I got this now, after issuing a > search, seeing that there was a typo, resissuing. > It is not that rare that this happens, but it is rare that > google slaps me in the face for it > ... and I _think_ it has been dillo before, too. But not sure. > > Anyhow, does someone know what is behind that "virus check"? > > > If you're continually receiving this error, you may be able to resolve the problem by deleting your Google cookie and > > revisiting Google. For browser-specific instructions, please consult your browser's online support center. > > Hm... I don't have any cookie from 'em. Perhaps that is the key? I don't think so, here it had worked perfectly w/o cookies for a long time. -- Cheers Jorge.-

Nov. 7, 2008

Dillo too fast?

by onepoint＠starurchin.org

On Fri, Nov 07, 2008 at 09:06:57AM +0100, Thomas Orgis wrote: > Did anyone else encounter this from google? Yes. A few months ago Google locked me out of all blogspot.com sites with the same message. It lasted about a day and then stopped. I had not done anything to change my browsing software or habits for ages. I have always assumed they tweaked their spyware detection, screwed it up and started generating lots of false positives, then reverted the change. It certainly didn't have anything to do with my browsers. Regards, Jeremy Henty

Nov. 7, 2008

Dillo too fast?

by thomas-forum＠orgis.org

Did anyone else encounter this from google? Not sure if this is something specific in dillo's network behaviour... > We're sorry... > ... but your query looks similar to automated requests from a computer virus or spyware application. To protect our users, > we can't process your request right now. It's at least the second time I got this now, after issuing a search, seeing that there was a typo, resissuing. It is not that rare that this happens, but it is rare that google slaps me in the face for it ... and I _think_ it has been dillo before, too. But not sure. Anyhow, does someone know what is behind that "virus check"? > If you're continually receiving this error, you may be able to resolve the problem by deleting your Google cookie and > revisiting Google. For browser-specific instructions, please consult your browser's online support center. Hm... I don't have any cookie from 'em. Perhaps that is the key? Alrighty then, Thomas.

Nov. 7, 2008

Another mention of Dillo-2

by onepoint＠starurchin.org

"Dillo 2.0 is fast, but limited" http://www.linux.com/feature/151983 Summary: "It's *fast*, even faster than Dillo-1, but too limited to be of use to much people.". It singles out lack of JavaScript, pointing out that most business sites need it (although I'd imagine most business sites would need full SSL support too). Jeremy Henty

Nov. 6, 2008

Repost: D_SUN_LEN cleanup (and a typo fix)

by jcid＠dillo.org

On Wed, Nov 05, 2008 at 02:26:48PM +0000, Jeremy Henty wrote: > > This is a repost of three tidy-up patches that have been left hanging > without resolution. Please comment. > > 1. Remove unused D_SUN_LEN declarations from DPIs. (The DPIs connect > to their sockets with accept() which doesn't use D_SUN_LEN.) > > 2. Use D_SUN_LEN whenever calling connect() on a struct sockaddr_un. > (Some of the calls already did this, this patch makes all of them > do so.) > > 3. Update a GPL reference in a comment from version 2 to version 3. Committed! -- Cheers Jorge.-

Nov. 5, 2008

Repost: D_SUN_LEN cleanup (and a typo fix)

by onepoint＠starurchin.org

This is a repost of three tidy-up patches that have been left hanging without resolution. Please comment. 1. Remove unused D_SUN_LEN declarations from DPIs. (The DPIs connect to their sockets with accept() which doesn't use D_SUN_LEN.) 2. Use D_SUN_LEN whenever calling connect() on a struct sockaddr_un. (Some of the calls already did this, this patch makes all of them do so.) 3. Update a GPL reference in a comment from version 2 to version 3. Regards, Jeremy Henty

Nov. 5, 2008

Re: Interested in joining dillo project

by jcid＠dillo.org

On Fri, Oct 31, 2008 at 11:43:35PM +0100, PHELIZOT Yvan wrote: > Hi, > > That me again. And i have a lot of questions: > About management: > * Does we have a functionnalities/features list? We had one inside the funding initiative in the past. It was purposedly removed from the web site because it was not updated (obsolete), and because the funding effort yielded no results. You can still find some info here: http://www.dillo.org/funding/funding.html (go to "Technical Overview"). > For example, i have > seen that png and jpeg are not supported, so does it included in the > file...? That's false. Where did you find that misinformation? > * Is there a task list? to know what to do and with which priority > > Dev : > * How many developpers, testers, ... work on the project? Please check the website. "Current Plans", "Authors", etc. > Software: > * Does the software has a "quirk" mode? Something akin, give read to dillorc. w3c_plus_heuristics=YES -- Cheers Jorge.-

Nov. 5, 2008

[patch]: fix the download GUI resize bug

by onepoint＠starurchin.org

On Thu, Oct 30, 2008 at 05:32:58PM -0300, Jorge Arellano Cid wrote: > On Thu, Oct 30, 2008 at 07:17:27PM +0000, Jeremy Henty wrote: > > ... if I write a FLTK2 app with a scrolled list of buttons that > > delete themselves when pressed then I *do* get redisplay problems: > > the deleted buttons don't disappear. And the fix is to tell the > > scroll to redraw itself. > > Committed. Good! I'm glad something useful came out of this. > Yes, the example program showed exactly what I was getting here. > This looks like a bug in FLTK2 (AFAIU, the scroll group should take > care of its background when an item is removed). IIRC I've sometimes had to manually tell a widget to update/redraw itself and I thought this was a deliberate policy from the FLTK devs. I'll send them my example and ask. Regards, Jeremy Henty

Oct. 30, 2008

[patch]: fix the download GUI resize bug

by jcid＠dillo.org

On Thu, Oct 30, 2008 at 07:17:27PM +0000, Jeremy Henty wrote: > On Thu, Oct 30, 2008 at 02:54:57PM -0300, Jorge Arellano Cid wrote: > > > The test that fails here is: > > > > - load the dillo downloads page > > - download a tarball > > - download another > > - resize the window to 1.25 the height of both download panels > > - Once both are done, press done in the lower panel > > > > then I get the panel drawn over the old one (like a shadow). > > I cannot reproduce this at all!!! But if I write a FLTK2 app with a > scrolled list of buttons that delete themselves when pressed then I > *do* get redisplay problems: the deleted buttons don't disappear. And > the fix is to tell the scroll to redraw itself. I guess that's > because the scroll is responsible for the blank space left behind when > the button disappears. It would be interesting to know if this patch > fails the test. (I've also attached the FLTK2 app. If you comment > out the redraw() call in the callback you'll see that the bottom > button does not disappear after clicking any button, even though the > list has actually shrunk.) Committed. Yes, the example program showed exactly what I was getting here. This looks like a bug in FLTK2 (AFAIU, the scroll group should take care of its background when an item is removed). -- Cheers Jorge.-

Oct. 30, 2008

reduce warnings with gcc-4.3 [PATCH]

by jcid＠dillo.org

On Thu, Oct 30, 2008 at 07:10:34PM +0100, Thomas Orgis wrote: > Am Thu, 30 Oct 2008 14:37:37 -0300 > schrieb Jorge Arellano Cid <jcid(a)dillo.org>: > > > Does this produce the same warning? > > > > assert (i >= 0 && this->num - i > 0); > > That seems to be silent with gcc-4.3.1 ... I won't guarantee anything for gcc-4.3.2, though. > But I'll upgrade to that one in the next weeks for sure and will let you know. > For now this looks like a fine fix to make dillo2 compiler warning free! Committed. -- Cheers Jorge.-

Oct. 30, 2008

[patch]: fix the download GUI resize bug

by onepoint＠starurchin.org

On Thu, Oct 30, 2008 at 02:54:57PM -0300, Jorge Arellano Cid wrote: > The test that fails here is: > > - load the dillo downloads page > - download a tarball > - download another > - resize the window to 1.25 the height of both download panels > - Once both are done, press done in the lower panel > > then I get the panel drawn over the old one (like a shadow). I cannot reproduce this at all!!! But if I write a FLTK2 app with a scrolled list of buttons that delete themselves when pressed then I *do* get redisplay problems: the deleted buttons don't disappear. And the fix is to tell the scroll to redraw itself. I guess that's because the scroll is responsible for the blank space left behind when the button disappears. It would be interesting to know if this patch fails the test. (I've also attached the FLTK2 app. If you comment out the redraw() call in the callback you'll see that the bottom button does not disappear after clicking any button, even though the list has actually shrunk.) Regards, Jeremy Henty

Oct. 30, 2008

css

by Johannes.Hofmann＠gmx.de

Hi, On Fri, Oct 24, 2008 at 03:09:53PM -0300, Jorge Arellano Cid wrote: ** snip ** > > I currently think about a class that looks more or less like StyleAttrs > > together with a map indicating which of it's values are actually set. > > One can then start with a basic style and apply any number of > > objects of this new class according to the order of precedence. > > Applying here means overriding those values that are set according > > to the map. > > Where/how would attribute values be stored? We will probabely need a new class that holds the attributes, but after looking at the dillo-0.8.0-css3 code I decided to go with just the "style", "id", and "class" attributes for now. Attached patch implements something between step 2 and 3 of my css proposal. There are a lot of loose ends (e.g. memory management) but it's a start. Check the end of css.cc. Here the user-agent style is filled. In html.cc Html_tag_open_a() shows how StyleEngine is intended to be used. Note that StyleEngine::apply() currently only supports a limited number of attributes. I think html.cc will become a lot simpler. Cheers, Johannes PS: I had attached the patch, but that was blocked by the list. So here is a link instead: http://www.ecademix.com/JohannesHofmann/tmp/css_prototype.dillo2

Oct. 30, 2008

reduce warnings with gcc-4.3 [PATCH]

by thomas-forum＠orgis.org

Am Thu, 30 Oct 2008 14:37:37 -0300 schrieb Jorge Arellano Cid <jcid(a)dillo.org>: > Does this produce the same warning? > > assert (i >= 0 && this->num - i > 0); That seems to be silent with gcc-4.3.1 ... I won't guarantee anything for gcc-4.3.2, though. But I'll upgrade to that one in the next weeks for sure and will let you know. For now this looks like a fine fix to make dillo2 compiler warning free! Alrighty then, Thomas.

Oct. 30, 2008

[patch]: fix the download GUI resize bug

by jcid＠dillo.org

On Thu, Oct 30, 2008 at 05:36:42PM +0000, Jeremy Henty wrote: > On Thu, Oct 30, 2008 at 09:49:23AM -0300, Jorge Arellano Cid wrote: > > > Here, with the unpatched code, the download dpi resizes without > > problems when narrowing the window (fltk-r6403), and labels are > > widened too. > > OK, I am embarrassed. There certainly *used* to be the problem I > described but it has gone. I thought I had checked that but I > obviously didn't. Apologies. We, human beans, make mistakes by definition! :-) > However, it is definitely weird to set the window's resizable to > something that is not a child of the window. Also, to my eye the > resizing seems smoother when the resizable is the scrollgroup. > Without the patch the contents seem to jiggle sideways more as the > width changes. > > > And more, the unpatched code responds to clicking "done" by > > removing the corresponding item (when alone and when in a list). > > The patched code, here, sometimes doesn't remove the widget when > > clicking "done", and others leaves a background with the > > to-be-removed item as a window shadow (partial remove). > > Strange, I deliberately tested clicking "done" (both with one download > and several downloads) before submitting and I saw no problems. What > happens if you call relayout() on the widget instead of resize()? > (patch attached) Same problem... :( The test that fails here is: - load the dillo downloads page - download a tarball - download another - resize the window to 1.25 the height of both download panels - Once both are done, press done in the lower panel then I get the panel drawn over the old one (like a shadow). -- Cheers Jorge.-

Oct. 30, 2008

reduce warnings with gcc-4.3 [PATCH]

by jcid＠dillo.org

On Fri, Oct 24, 2008 at 08:44:14PM +0200, Thomas Orgis wrote: > The build of dillo with gcc-4.3 spills out quite some warning messages. > > I propose attached patch to fix these. Most are about all these loops > without body: gcc suggested to change > > for(i=0; i<42; ++i); > > to > > for(i=0; i<42; ++i) ; > > ...or append "{}", alternatively. > I decided for the subtle space insertion... not sure if I particulary > like it, but it makes the compile more silent. > > Other warnings are about logical and arithmetical expressions with fewer > than recommened parentheses. > I suggest people having a close look at these changes... > I _think_ I got it right;-) > Committed! > Then at last, there's an unresolved warning: > > dillo2-cvs/dw$ LANG=C make textblock.o > g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -march=pentium-m -O3 -Wall -W -Wno-unused-parameter -MT textblock.o -MD -MP -MF .deps/textblock.Tpo -c -o textblock.o textblock.cc > ../lout/misc.hh: In member function 'void dw::Textblock::addLine(int, bool)': > ../lout/misc.hh:161: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > mv -f .deps/textblock.Tpo .deps/textblock.Po > > It's about this assert: > > inline T* getRef (int i) { > if (BOUND_CHECKING) > assert (i >= 0 && i < this->num); > return array + i; > } > > Ideas to please gcc with this assert? I am not sure what to think of this. I have gcc-4.2.4 here. Does this produce the same warning? assert (i >= 0 && this->num - i > 0); -- Cheers Jorge.-

Oct. 30, 2008

[patch]: fix the download GUI resize bug

by onepoint＠starurchin.org

On Thu, Oct 30, 2008 at 09:49:23AM -0300, Jorge Arellano Cid wrote: > Here, with the unpatched code, the download dpi resizes without > problems when narrowing the window (fltk-r6403), and labels are > widened too. OK, I am embarrassed. There certainly *used* to be the problem I described but it has gone. I thought I had checked that but I obviously didn't. Apologies. However, it is definitely weird to set the window's resizable to something that is not a child of the window. Also, to my eye the resizing seems smoother when the resizable is the scrollgroup. Without the patch the contents seem to jiggle sideways more as the width changes. > And more, the unpatched code responds to clicking "done" by > removing the corresponding item (when alone and when in a list). > The patched code, here, sometimes doesn't remove the widget when > clicking "done", and others leaves a background with the > to-be-removed item as a window shadow (partial remove). Strange, I deliberately tested clicking "done" (both with one download and several downloads) before submitting and I saw no problems. What happens if you call relayout() on the widget instead of resize()? (patch attached) I'm using fltk2-r6403, gcc-4.1.2 and running on Linux. Regards, Jeremy Henty

Oct. 30, 2008

Q: D_SUN_LEN , dpi programs and socket programming

by onepoint＠starurchin.org

On Thu, Oct 30, 2008 at 09:29:55AM -0300, Jorge Arellano Cid wrote: > On Wed, Oct 29, 2008 at 08:46:28PM +0000, Jeremy Henty wrote: > > On Wed, Oct 29, 2008 at 01:28:20PM -0300, Jorge Arellano Cid wrote: > > > > > > Given that IO/dpi.c uses both without (reported) problems, > > > it'd be good to have everyone use D_SUN_LEN. > > > > So I think the code is correct and we should just remove the > > unused D_SUN_LEN definitions. Patch attached. > > OK, but I was talking about connect(). Patch attached. Also, all uses of bind() already use D_SUN_LEN. Incidentally, does anyone know why there is no analog of D_SUN_LEN for connect()-ing to a struct sockaddr_in? The struct has a sin_path member just as struct sockaddr_un has a sun_path , so what is the difference? (I'm new to the C socket API.) Regards, Jeremy Henty

Oct. 30, 2008

[patch]: fix the download GUI resize bug

by jcid＠dillo.org

On Wed, Oct 29, 2008 at 09:16:07PM +0000, Jeremy Henty wrote: > On Wed, Oct 29, 2008 at 01:38:14PM -0300, Jorge Arellano Cid wrote: > > On Wed, Oct 29, 2008 at 02:28:48PM +0000, Jeremy Henty wrote: > > > > > > There's a bug in the downloads GUI that stops the download items > > > resizing when the window does. The resizable of the window should > > > be the scrollgroup, not the packedgroup. Fixing this means we > > > don't need to explicitly resize the scrollgroup after removing an > > > item (because the window has already resized it) so I took that > > > out. Patch attached. > > > > Oh, please excuse me not understanding what the bug is and how to > > reproduce it. Please explain with apples and pears! :-) > > OK, fruit 'n' veg coming up! :-) > > Symptom: > > If you change the width of the download GUI window its contents do not > respond. This is annoying because (a) if you narrow the window to > save space then it truncates its contents at the right-hand side > rather than gracefully resizing them, and (b) if you widen the window > hoping that it will make the display more legible by widening the text > labels etc. then nothing happens. It's an easy bug to miss because > the result is not obviously wrong, just poor and inconvenient. Once > you've seen the correct behaviour the improvement is obvious. I still don't get it... Here, with the unpatched code, the download dpi resizes without problems when narrowing the window (fltk-r6403), and labels are widened too. And more, the unpatched code responds to clicking "done" by removing the corresponding item (when alone and when in a list). The patched code, here, sometimes doesn't remove the widget when clicking "done", and others leaves a background with the to-be-removed item as a window shadow (partial remove). I'm baffled. > Cause: > > FLTK's resize mechanism is controlled by the resizable members of the > Group widgets. This is a pointer to the child of the group widget > which the group should resize when its own size changes. The > downloads GUI is buggy because it sets the resizable widget of the > Window to be the PackedGroup that contains the download items, which > is wrong because the PackedGroup is *not* a child of the Window, it's > a child of the the ScrollGroup (which is in turn a child of the > Window). The result is that the contents of the Window don't resize > at all, except when the code tries to work around the bug by > explicitly calling resize(). > > > Fix: > > The code should make the ScrollGroup the resizable widget of the > Window. (The ScrollGroup then properly resizes the PackedGroup > without any further changes. I think this is because its type is set > to VERTICAL.) This makes the width of the ScrollGroup (and hence the > PackedGroup too) follow the width of the Window in a way that is > beautiful to behold. :-) Now we don't need to explicitly resize the > any of the widgets because FLTK does it all automatically whenever the > width of the Window changes, so the call to resize() should be > deleted. -- Cheers Jorge.-

Oct. 30, 2008

Q: D_SUN_LEN , dpi programs and socket programming

by jcid＠dillo.org

On Wed, Oct 29, 2008 at 08:46:28PM +0000, Jeremy Henty wrote: > On Wed, Oct 29, 2008 at 01:28:20PM -0300, Jorge Arellano Cid wrote: > > On Wed, Oct 29, 2008 at 12:24:03PM +0000, Jeremy Henty wrote: > > > > > > Shouldn't we delete the definition of D_SUN_LEN from the dpi > > > programs since they don't use it? Or maybe they should use it? > > > Which? > > > > Given that IO/dpi.c uses both without (reported) problems, it'd be > > good to have everyone use D_SUN_LEN. > > Actually, I think I was confused. The accept() man page says > > The addrlen argument is a value-result argument: it should > initially contain the size of the structure pointed to by addr; on > return it will contain the actual length (in bytes) of the address > returned. > > So passing sizeof(struct sockarr_un) to accept() is correct. Indeed, > passing D_SUN_LUN(&address) could be disastrous because address is > uninitialised (since we expect accept() to fill it in). So I think > the code is correct and we should just remove the unused D_SUN_LEN > definitions. Patch attached. OK, but I was talking about connect(). -- Cheers Jorge.-

Oct. 30, 2008

[patch]: update the GPL version in the openssl exception clause

by onepoint＠starurchin.org

There is a license exception in src/dpi/https.c to link to OpenSSL without following the terms of the GPL. Unfortunately the clause refers to GPL version 2, when everything else has been updated to version 3. Oops! Patch attached. Jeremy Henty

Oct. 30, 2008

[patch]: fix the download GUI resize bug

by onepoint＠starurchin.org

On Wed, Oct 29, 2008 at 01:38:14PM -0300, Jorge Arellano Cid wrote: > On Wed, Oct 29, 2008 at 02:28:48PM +0000, Jeremy Henty wrote: > > > > There's a bug in the downloads GUI that stops the download items > > resizing when the window does. The resizable of the window should > > be the scrollgroup, not the packedgroup. Fixing this means we > > don't need to explicitly resize the scrollgroup after removing an > > item (because the window has already resized it) so I took that > > out. Patch attached. > > Oh, please excuse me not understanding what the bug is and how to > reproduce it. Please explain with apples and pears! :-) OK, fruit 'n' veg coming up! :-) Symptom: If you change the width of the download GUI window its contents do not respond. This is annoying because (a) if you narrow the window to save space then it truncates its contents at the right-hand side rather than gracefully resizing them, and (b) if you widen the window hoping that it will make the display more legible by widening the text labels etc. then nothing happens. It's an easy bug to miss because the result is not obviously wrong, just poor and inconvenient. Once you've seen the correct behaviour the improvement is obvious. Cause: FLTK's resize mechanism is controlled by the resizable members of the Group widgets. This is a pointer to the child of the group widget which the group should resize when its own size changes. The downloads GUI is buggy because it sets the resizable widget of the Window to be the PackedGroup that contains the download items, which is wrong because the PackedGroup is *not* a child of the Window, it's a child of the the ScrollGroup (which is in turn a child of the Window). The result is that the contents of the Window don't resize at all, except when the code tries to work around the bug by explicitly calling resize(). Fix: The code should make the ScrollGroup the resizable widget of the Window. (The ScrollGroup then properly resizes the PackedGroup without any further changes. I think this is because its type is set to VERTICAL.) This makes the width of the ScrollGroup (and hence the PackedGroup too) follow the width of the Window in a way that is beautiful to behold. :-) Now we don't need to explicitly resize the any of the widgets because FLTK does it all automatically whenever the width of the Window changes, so the call to resize() should be deleted. Apples and pears enough? :-) :-) Regards, Jeremy Henty

Oct. 29, 2008

Q: D_SUN_LEN , dpi programs and socket programming

by onepoint＠starurchin.org

On Wed, Oct 29, 2008 at 01:28:20PM -0300, Jorge Arellano Cid wrote: > On Wed, Oct 29, 2008 at 12:24:03PM +0000, Jeremy Henty wrote: > > > > Shouldn't we delete the definition of D_SUN_LEN from the dpi > > programs since they don't use it? Or maybe they should use it? > > Which? > > Given that IO/dpi.c uses both without (reported) problems, it'd be > good to have everyone use D_SUN_LEN. Actually, I think I was confused. The accept() man page says The addrlen argument is a value-result argument: it should initially contain the size of the structure pointed to by addr; on return it will contain the actual length (in bytes) of the address returned. So passing sizeof(struct sockarr_un) to accept() is correct. Indeed, passing D_SUN_LUN(&address) could be disastrous because address is uninitialised (since we expect accept() to fill it in). So I think the code is correct and we should just remove the unused D_SUN_LEN definitions. Patch attached. Jeremy Henty

Oct. 29, 2008

[patch]: fix the download GUI resize bug

by jcid＠dillo.org

On Wed, Oct 29, 2008 at 02:28:48PM +0000, Jeremy Henty wrote: > > There's a bug in the downloads GUI that stops the download items > resizing when the window does. The resizable of the window should be > the scrollgroup, not the packedgroup. Fixing this means we don't need > to explicitly resize the scrollgroup after removing an item (because > the window has already resized it) so I took that out. Patch > attached. Oh, please excuse me not understanding what the bug is and how to reproduce it. Please explain with apples and pears! :-) (yes, I get the explicit resize is strange) -- Cheers Jorge.-

Oct. 29, 2008

Q: D_SUN_LEN , dpi programs and socket programming

by jcid＠dillo.org

On Wed, Oct 29, 2008 at 12:24:03PM +0000, Jeremy Henty wrote: > > The bookmarks and cookies dpis define D_SUN_LEN but don't use it. > D_SUN_LEN is used elsewhere by dillo (when calling connect()) and dpid > (when calling bind()), but all the dpi programs call accept() with > sizeof(struct sockaddr_un) instead of D_SUN_LEN(address). Shouldn't > we delete the definition of D_SUN_LEN from the dpi programs since they > don't use it? Or maybe they should use it? Which? Given that IO/dpi.c uses both without (reported) problems, it'd be good to have everyone use D_SUN_LEN. That way we can filed test easily by changing the macro definition. Maybe there're systems where this still matters. -- Cheers Jorge.-

Oct. 29, 2008

[patch]: fix the download GUI resize bug

by Johannes.Hofmann＠gmx.de

On Wed, Oct 29, 2008 at 02:28:48PM +0000, Jeremy Henty wrote: > > There's a bug in the downloads GUI that stops the download items > resizing when the window does. The resizable of the window should be > the scrollgroup, not the packedgroup. Fixing this means we don't need > to explicitly resize the scrollgroup after removing an item (because > the window has already resized it) so I took that out. Patch > attached. Looks good to me! Cheers, Johannes > > Regards, > > Jeremy Henty > >>From 0e241cbce318768aa8ad8f7715b80dbb3a38a6f3 Mon Sep 17 00:00:00 2001 > From: Jeremy Henty <onepoint(a)starurchin.org> > Date: Wed, 29 Oct 2008 14:14:58 +0000 > Subject: [PATCH] Fix the download GUI resize behaviour. > > --- > dpi/downloads.cc | 5 +---- > 1 files changed, 1 insertions(+), 4 deletions(-) > > diff --git a/dpi/downloads.cc b/dpi/downloads.cc > index d2f3a54..b88deed 100644 > --- a/dpi/downloads.cc > +++ b/dpi/downloads.cc > @@ -1029,9 +1029,6 @@ void DLWin::del(int n_item) > > // Remove the widget from the scroll group > mPG->remove(dl_item->get_widget()); > - // Resize the scroll group > - mPG->resize(mWin->w(), 1); > - > mDList->del(n_item); > delete(dl_item); > } > @@ -1093,7 +1090,7 @@ DLWin::DLWin(int ww, int wh) { > mScroll->end(); > mScroll->type(ScrollGroup::VERTICAL); > mWin->end(); > - mWin->resizable(mPG); > + mWin->resizable(mScroll); > mWin->callback(dlwin_esc_cb, NULL); > mWin->show(); > > -- > 1.6.0.2 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Oct. 29, 2008

reduce warnings with gcc-4.3 [PATCH]

by Johannes.Hofmann＠gmx.de

On Tue, Oct 28, 2008 at 11:38:25PM +0000, corvid wrote: > Thomas wrote: > > Then at last, there's an unresolved warning: > > > > dillo2-cvs/dw$ LANG=C make textblock.o > > g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -march=pentium-m -O3 -Wall -W -Wno-unused-parameter -MT textblock.o -MD -MP -MF .deps/textblock.Tpo -c -o textblock.o textblock.cc > > ../lout/misc.hh: In member function 'void dw::Textblock::addLine(int, bool)': > > ../lout/misc.hh:161: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > > mv -f .deps/textblock.Tpo .deps/textblock.Po > > > > It's about this assert: > > > > inline T* getRef (int i) { > > if (BOUND_CHECKING) > > assert (i >= 0 && i < this->num); > > return array + i; > > } > > > > Ideas to please gcc with this assert? I am not sure what to think of this. > > I was hoping that someone who knows about these things would > reply, but no such luck. Does it matter if you put the > argument into a variable before calling getRef()? > > I don't really see what would be special about one particular > instance of something->getRef(something->size() - n) > when it encountered others earlier without protest, > why it would (seemingly) remember that it was given (this->num - n) > this one time... The problem might be that due to inlining this becomes: assert (this->num - 1 >= 0 && this->num - 1 < this->num); Which looks odd to the compiler. I have no idea how to silence gcc. Perhaps we should just ignore that warning.... Cheers, Johannes

Oct. 29, 2008

[patch]: fix the download GUI resize bug

by onepoint＠starurchin.org

There's a bug in the downloads GUI that stops the download items resizing when the window does. The resizable of the window should be the scrollgroup, not the packedgroup. Fixing this means we don't need to explicitly resize the scrollgroup after removing an item (because the window has already resized it) so I took that out. Patch attached. Regards, Jeremy Henty

Oct. 29, 2008

Q: D_SUN_LEN , dpi programs and socket programming

by onepoint＠starurchin.org

The bookmarks and cookies dpis define D_SUN_LEN but don't use it. D_SUN_LEN is used elsewhere by dillo (when calling connect()) and dpid (when calling bind()), but all the dpi programs call accept() with sizeof(struct sockaddr_un) instead of D_SUN_LEN(address). Shouldn't we delete the definition of D_SUN_LEN from the dpi programs since they don't use it? Or maybe they should use it? Which? Regards, Jeremy Henty

Oct. 29, 2008

reduce warnings with gcc-4.3 [PATCH]

by corvid＠lavabit.com

Thomas wrote: > Then at last, there's an unresolved warning: > > dillo2-cvs/dw$ LANG=C make textblock.o > g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -march=pentium-m -O3 -Wall -W -Wno-unused-parameter -MT textblock.o -MD -MP -MF .deps/textblock.Tpo -c -o textblock.o textblock.cc > ../lout/misc.hh: In member function 'void dw::Textblock::addLine(int, bool)': > ../lout/misc.hh:161: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > mv -f .deps/textblock.Tpo .deps/textblock.Po > > It's about this assert: > > inline T* getRef (int i) { > if (BOUND_CHECKING) > assert (i >= 0 && i < this->num); > return array + i; > } > > Ideas to please gcc with this assert? I am not sure what to think of this. I was hoping that someone who knows about these things would reply, but no such luck. Does it matter if you put the argument into a variable before calling getRef()? I don't really see what would be special about one particular instance of something->getRef(something->size() - n) when it encountered others earlier without protest, why it would (seemingly) remember that it was given (this->num - n) this one time...

Oct. 29, 2008

Hello!

by corvid＠lavabit.com

> and maybe find-as-you-type searching. You can get most of find-as-you-type for (nearly) free by taking the ReturnKey test out of Findbar::search_cb2() and changing the when() in Findbar::Findbar to something like WHEN_CHANGED. I seem to recall that there are times when this alone doesn't do quite what you might want, but I don't remember the details.

Oct. 29, 2008

dillo 2.0 on NetBSD/SPARC

by jcid＠dillo.org

Hi, FYI > Hi, > > here is a short success report: > I have compiled and tested dillo 2.0 on a Sun Ultra 1 machine with SPARC > V9 CPU running NetBSD 4.0.1 and it works (including SSL support). > > > Best regards, > > Michael Baeuerle -- Cheers Jorge.-

Oct. 28, 2008

[michael.baeuerle@stz-e.de: dillo 2.0 on NetBSD/SPARC]

by jcid＠dillo.org

Hi, FYI. -- Cheers Jorge.-

Oct. 28, 2008

patch: print numeric addresses instead of pointer

by 4winter＠informatik.uni-hamburg.de

Skipped content of type multipart/mixed

Oct. 28, 2008